From alex.pinto78 at hotmail.com Sat Jan 1 04:56:53 2011 From: alex.pinto78 at hotmail.com (Alex Pinto) Date: Sat, 1 Jan 2011 21:56:53 +1100 Subject: What sflow software - Manage Engine Net flow analyzer or Plixer Scrutinizer with Analyzer Message-ID: Hi everyone, we currently are looking at sflow options for a commercial collector and analyzer. The core use is for visibility on our network, for quickly detecting source / destination IP addresses, ie where the traffic is going and where is it coming from, the type of traffic would be interesting also but to be honest all which really matters is source / destination. The requirement of the sflow software is to give us options and data very quickly in the event of a DDOS attack so mitigation can occur quickly once we understand what?s happening on the network. The last thing we want is for the software not to work under a DDOS (too much data) thus leaving us blind upon an attack. The quicker the software can report on issues, the quicker we can do something about it. Our current routers are fully sflow capable and both export nicely to both packages. Our findings so far Manage Engine Net flow analyzer has both a Linux and windows version, the software is very light and seems to perform very fast, although light on additional features such as custom reporting, and alerting / in depth packet information. The concern is this software too simple, will it work under heavy load? Based on our needs Manage Engine Net flow costs $2000.00 Plixer Scrutinizer ? based on windows the software seems resource intensive but has a MASSIVE amount of extra visibility built into the software including automatic alerts, that being said the software does seem extremely more complex to configure and understand, reports seem to take longer to produce and the information doesn?t seem to be reported as quickly. (ie lags by minutes or so compared to Manage Engine) Based on our needs Plixer Scrutinizer Costs $4000.00 Does anyone have any real life experience on either package the cost different between the two packages doesn?t worry us, it?s all about selecting the correct package knowing the one time we need to access the flow information and get it quick that the package we choose preforms quickly and works. I?d also like to hear from anyone else using another commercial solution, which they would recommend. Thanks in advance Alex From jakemichaelwilson at gmail.com Sat Jan 1 06:12:39 2011 From: jakemichaelwilson at gmail.com (Jake Wilson) Date: Sat, 1 Jan 2011 12:12:39 +0000 (UTC) Subject: What sflow software - Manage Engine Net flow analyzer or =?utf-8?b?UGxpeGVyCVNjcnV0aW5pemVy?= with Analyzer References: Message-ID: Alex Pinto hotmail.com> writes: > > > Hi everyone, we currently are looking at sflow options for a commercial collector and analyzer. The core > use is for visibility on our network, for quickly detecting source / destination IP addresses, ie where > the traffic is going and where is it coming from, the type of traffic would be interesting also but to be > honest all which really matters is source / destination. > > The requirement of the sflow software is to give us options and data very quickly in the event of a DDOS attack > so mitigation can occur quickly once we understand what?s happening on the network. The last thing we > want is for the software not to work under a DDOS (too much data) thus leaving us blind upon an attack. The > quicker the software can report on issues, the quicker we can do something about it. > Our current routers are fully sflow capable and both export nicely to both packages. > > Our findings so far > > Manage Engine Net flow analyzer has both a Linux and windows version, the software is very light and seems to > perform very fast, although light on additional features such as custom reporting, and alerting / in > depth packet information. The concern is this software too simple, will it work under heavy load? > Based on our needs Manage Engine Net flow costs $2000.00 > > Plixer Scrutinizer ? based on windows the software seems resource intensive but has a MASSIVE amount of > extra visibility built into the software including automatic alerts, that being said the software does > seem extremely more complex to configure and understand, reports seem to take longer to produce and the > information doesn?t seem to be reported as quickly. (ie lags by minutes or so compared to Manage Engine) > Based on our needs Plixer Scrutinizer Costs $4000.00 > > Does anyone have any real life experience on either package the cost different between the two packages > doesn?t worry us, it?s all about selecting the correct package knowing the one time we need to access > the flow information and get it quick that the package we choose preforms quickly and works. > > I?d also like to hear from anyone else using another commercial solution, which they would recommend. > > Thanks in advance > > Alex > Hi Alex, Scrutinizer saves 100% of the raw NetFlow data just like Wireshark. Most collectors only keep what is in the tuple (e.g. src/dest IP, port, interface, protocol, autonomous system and few other fields). This makes the interface faster. If you export MAC address or VLANs, Scrutinizer will allow you to filter (and report in the next version) on these fields. Filtering and reporting is very important in traffic analysis. We feel that the ability to Include/Exclude on any combination of fields is a must. ManageEngine can't do this. Scrutinizer saves much more flow data in the roll ups (up to 100K) than ManageEngine (e.g. ~1K) therefore the tables are much larger and slower to query in Scrutinizer although more accurate especially over time. I'm surprised that reports lag by minutes. Here are some things to check: * is the router/switch sending > 3000 flows/second? * is the scrutinizer server under powered? * is antivirus running (it shouldn't be scanning the scrutinizer directory) Did you see page 2 of this pdf: http://www.plixer.com/files/scrutinizer_netflow_challenge.pdf Does this help? Jake Wilson plixer.com From peter.phaal at gmail.com Sat Jan 1 11:12:12 2011 From: peter.phaal at gmail.com (Peter Phaal) Date: Sat, 1 Jan 2011 09:12:12 -0800 Subject: What sflow software - Manage Engine Net flow analyzer or Plixer Scrutinizer with Analyzer In-Reply-To: References: Message-ID: <84295BE4-7470-49A7-84E2-E33734B0FC95@gmail.com> sFlowTrend is free for up to five routers and should meet your requirement to quickly see top flows: http://inmon.com/products/sFlowTrend.php sFlowTrend is InMon's entry level product, if you need more features you might want to try sFlowTrend-Pro or Traffic Sentinel. When selecting an sFlow analyzer, it is important to understand the sFlow architecture and the functional requirements it places on the analyzer - many products are principally netflow analyzers and do a poor job with sFlow http://blog.sflow.com/2009/05/choosing-sflow-analyzer.html Peter On Jan 1, 2011, at 2:56 AM, Alex Pinto wrote: > > Hi everyone, we currently are looking at sflow options for a commercial collector and analyzer. The core use is for visibility on our network, for quickly detecting source / destination IP addresses, ie where the traffic is going and where is it coming from, the type of traffic would be interesting also but to be honest all which really matters is source / destination. > > The requirement of the sflow software is to give us options and data very quickly in the event of a DDOS attack so mitigation can occur quickly once we understand what?s happening on the network. The last thing we want is for the software not to work under a DDOS (too much data) thus leaving us blind upon an attack. The quicker the software can report on issues, the quicker we can do something about it. > Our current routers are fully sflow capable and both export nicely to both packages. > > Our findings so far > > Manage Engine Net flow analyzer has both a Linux and windows version, the software is very light and seems to perform very fast, although light on additional features such as custom reporting, and alerting / in depth packet information. The concern is this software too simple, will it work under heavy load? > Based on our needs Manage Engine Net flow costs $2000.00 > > Plixer Scrutinizer ? based on windows the software seems resource intensive but has a MASSIVE amount of extra visibility built into the software including automatic alerts, that being said the software does seem extremely more complex to configure and understand, reports seem to take longer to produce and the information doesn?t seem to be reported as quickly. (ie lags by minutes or so compared to Manage Engine) > Based on our needs Plixer Scrutinizer Costs $4000.00 > > Does anyone have any real life experience on either package the cost different between the two packages doesn?t worry us, it?s all about selecting the correct package knowing the one time we need to access the flow information and get it quick that the package we choose preforms quickly and works. > > I?d also like to hear from anyone else using another commercial solution, which they would recommend. > > Thanks in advance > > Alex From ahsan.tariq11 at gmail.com Sat Jan 1 11:38:12 2011 From: ahsan.tariq11 at gmail.com (Ahsan Tariq) Date: Sat, 1 Jan 2011 22:38:12 +0500 Subject: Unusual BGP nexthop Message-ID: Hi folks. I am working on a project for which I am using the bgp routing tables from routeviews and their update traces. In some update traces from routviews I noticed that the nexthop field is set to: 255.255.255.255 Is this a valid nexthop ? Is their any meaning or significance to this nexthop ? Any help would be appreciated. Thanks Ahsan Tariq From graham at g-rock.net Sat Jan 1 21:33:46 2011 From: graham at g-rock.net (Graham Wooden) Date: Sat, 01 Jan 2011 21:33:46 -0600 Subject: The tale of a single MAC Message-ID: Hi there, I encountered an interesting issue today and I found it so bizarre ? so I thought I would share it. I brought online a spare server to help offload some of the recent VMs that I have been deploying. Around the same time this new machine (we?ll call it Server-B) came online, another machine which has been online for about a year now stopped responding to our monitoring (and we?ll name this Server-A). I logged into the switch and saw that the machine that stopped responding was in the same VLAN as this newly deployed, and then quickly noticed that Server-A?s MAC address was now on Server-B?s switch port. ?What the ...? was my initial response. I went ahead and moved Server-B?s to another VLAN, updated the switchport, cleared the ARP, and Server-A came back to life. Happy new year to me. So ? here is the interesting part... Both servers are HP Proliant DL380 G4s, and both of their NIC1 and NIC2 MACs addresses are exactly the same. Not spoofd and the OS drivers are not mucking with them ... They?re burned-in ? I triple checked them in their respective BIOS screen. I acquired these two machines at different times and both were from the grey market. The ?What the ...? is sitting fresh in my mind ... How can this be? In the last 15 years of being in IT, I have never encountered a ?burned-in? duplicated MACs across two physically different machines. What are the odds, that HP would dup?d them and that both would eventually end up at my shop? Or maybe this type of thing isn?t big of deal... ? -graham From ops.lists at gmail.com Sat Jan 1 21:40:38 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sun, 2 Jan 2011 09:10:38 +0530 Subject: The tale of a single MAC In-Reply-To: References: Message-ID: I've seen duplicate MAC addresses but only on no name made in china NICs installed on cheap (assembled from parts) PCs at a school computer lab. On Sun, Jan 2, 2011 at 9:03 AM, Graham Wooden wrote: > > In the last 15 years of being in IT, I have never encountered a ?burned-in? > duplicated MACs across two physically different machines. ?What are the > odds, that HP would dup?d them and that both would eventually end up at my > shop? ?Or maybe this type of thing isn?t big of deal... ? -- Suresh Ramasubramanian (ops.lists at gmail.com) From ios.run at gmail.com Sat Jan 1 21:53:51 2011 From: ios.run at gmail.com (Raul Rodriguez) Date: Sat, 1 Jan 2011 19:53:51 -0800 Subject: The tale of a single MAC In-Reply-To: References: Message-ID: Seen this on six-figure gateways. -RR On 1/1/11, Suresh Ramasubramanian wrote: > I've seen duplicate MAC addresses but only on no name made in china > NICs installed on cheap (assembled from parts) PCs at a school > computer lab. > > On Sun, Jan 2, 2011 at 9:03 AM, Graham Wooden wrote: >> >> In the last 15 years of being in IT, I have never encountered a >> ?burned-in? >> duplicated MACs across two physically different machines. ?What are the >> odds, that HP would dup?d them and that both would eventually end up at my >> shop? ?Or maybe this type of thing isn?t big of deal... ? > > > > -- > Suresh Ramasubramanian (ops.lists at gmail.com) > > -- Sent from my mobile device From bruns at 2mbit.com Sat Jan 1 21:59:16 2011 From: bruns at 2mbit.com (Brielle Bruns) Date: Sat, 01 Jan 2011 20:59:16 -0700 Subject: The tale of a single MAC In-Reply-To: References: Message-ID: <4D1FF814.50306@2mbit.com> On 1/1/11 8:33 PM, Graham Wooden wrote: > So ? here is the interesting part... Both servers are HP Proliant DL380 G4s, > and both of their NIC1 and NIC2 MACs addresses are exactly the same. Not > spoofd and the OS drivers are not mucking with them ... They?re burned-in ? > I triple checked them in their respective BIOS screen. I acquired these two > machines at different times and both were from the grey market. The ?What > the ...? is sitting fresh in my mind ... How can this be? From the same grey market supplier? I know HP has a disc they put out which updates all the firmware/bios in a specific server model, its not too far fetched that a vendor might have a modified version that also either purposely or accidentally changes the MAC address. Off the top of my head, I'm not sure where the MAC is stored - maybe an eeprom or a portion of the bios flash. Or, it could be botched flashing that blew away the portion of memory where that was stored and the system defaulted to a built in value. Excellent example is, IIRC, the older sparc stuff, where the ethernet cards didn't have MAC addresses as part of the card, but were stored in non-volatile or battery backed memory. Memory goes poof, and you'll have problems. Some WRT54G/WAP54Gs suffer from the same problem when throwing third party firmware on there. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From rdobbins at arbor.net Sat Jan 1 21:56:35 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Sun, 2 Jan 2011 03:56:35 +0000 Subject: The tale of a single MAC In-Reply-To: References: Message-ID: <5FF1A47E-A831-420F-9681-88599F6F7982@arbor.net> On Jan 2, 2011, at 10:33 AM, Graham Wooden wrote: > What are the odds, that HP would dup?d them and that both would eventually end up at my shop? There may be some setting you're overlooking or a bug which needs an update to fix, or you may simply have purchased HP ProLiant *cases*, rather than actual *servers*. ;> Note that search engine results for 'proliant dl380 duplicate mac' returns multiple links. ------------------------------------------------------------------------ Roland Dobbins // Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay From adrian at creative.net.au Sat Jan 1 22:13:43 2011 From: adrian at creative.net.au (Adrian Chadd) Date: Sun, 2 Jan 2011 12:13:43 +0800 Subject: The tale of a single MAC In-Reply-To: References: Message-ID: <20110102041343.GA15111@skywalker.creative.net.au> So along simlar lines, Ubiquiti sell routerstation pro boards with sequential MAC addresses. The trouble is they've allocated a single MAC for the first port - the second ethernet port (also attached to the bridge) doesn't get a second MAC. So in a purchase of a few hundred boards, we had plenty that were sequential. Since the FreeBSD driver allocated MAC+1 to the second NIC, this caused duplcate MAC addresses and this caused hilarity to ensue. The "fix" was to just get this company to apply for some MAC space and then use -that- on the second NIC and the bridge interfaces. Ah, vendors.. :-) Adrian On Sat, Jan 01, 2011, Graham Wooden wrote: > Hi there, > > I encountered an interesting issue today and I found it so bizarre ? so I > thought I would share it. > > I brought online a spare server to help offload some of the recent VMs that > I have been deploying. Around the same time this new machine (we?ll call it > Server-B) came online, another machine which has been online for about a > year now stopped responding to our monitoring (and we?ll name this > Server-A). I logged into the switch and saw that the machine that stopped > responding was in the same VLAN as this newly deployed, and then quickly > noticed that Server-A?s MAC address was now on Server-B?s switch port. > ?What the ...? was my initial response. > > I went ahead and moved Server-B?s to another VLAN, updated the switchport, > cleared the ARP, and Server-A came back to life. Happy new year to me. > > So ? here is the interesting part... Both servers are HP Proliant DL380 G4s, > and both of their NIC1 and NIC2 MACs addresses are exactly the same. Not > spoofd and the OS drivers are not mucking with them ... They?re burned-in ? > I triple checked them in their respective BIOS screen. I acquired these two > machines at different times and both were from the grey market. The ?What > the ...? is sitting fresh in my mind ... How can this be? > > In the last 15 years of being in IT, I have never encountered a ?burned-in? > duplicated MACs across two physically different machines. What are the > odds, that HP would dup?d them and that both would eventually end up at my > shop? Or maybe this type of thing isn?t big of deal... ? > > -graham > > > -- - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support - - $24/pm+GST entry-level VPSes w/ capped bandwidth charges available in WA - From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sat Jan 1 22:33:24 2011 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sun, 2 Jan 2011 15:03:24 +1030 Subject: The tale of a single MAC In-Reply-To: <4D1FF814.50306@2mbit.com> References: <4D1FF814.50306@2mbit.com> Message-ID: <20110102150324.627b891c@opy.nosense.org> On Sat, 01 Jan 2011 20:59:16 -0700 Brielle Bruns wrote: > On 1/1/11 8:33 PM, Graham Wooden wrote: > > So ? here is the interesting part... Both servers are HP Proliant DL380 G4s, > > and both of their NIC1 and NIC2 MACs addresses are exactly the same. Not > > spoofd and the OS drivers are not mucking with them ... They?re burned-in ? > > I triple checked them in their respective BIOS screen. I acquired these two > > machines at different times and both were from the grey market. The ?What > > the ...? is sitting fresh in my mind ... How can this be? > > > From the same grey market supplier? > > I know HP has a disc they put out which updates all the firmware/bios in > a specific server model, its not too far fetched that a vendor might > have a modified version that also either purposely or accidentally > changes the MAC address. Off the top of my head, I'm not sure where the > MAC is stored - maybe an eeprom or a portion of the bios flash. Or, it > could be botched flashing that blew away the portion of memory where > that was stored and the system defaulted to a built in value. > > Excellent example is, IIRC, the older sparc stuff, where the ethernet > cards didn't have MAC addresses as part of the card, but were stored in > non-volatile or battery backed memory. This was actually the intended way to use "MAC" addresses, to used as host addresses rather than as individual interface addresses, according to the following paper - "48-bit Absolute Internet and Ethernet Host Numbers" Yogan K. Dalal and Robert S. Printis, July 1981 http://ethernethistory.typepad.com/papers/HostNumbers.pdf That paper also discusses why 48 bits were chosen as the size, despite "Ethernet systems" being limited to 1024 hosts. I think things evolved into MAC per NIC because when add-in NICs were invented there wasn't any appropriate non-volatile storage on the host to store the address. Regards, mark. From bmanning at vacation.karoshi.com Sat Jan 1 22:43:10 2011 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sun, 2 Jan 2011 04:43:10 +0000 Subject: The tale of a single MAC In-Reply-To: <20110102150324.627b891c@opy.nosense.org> References: <4D1FF814.50306@2mbit.com> <20110102150324.627b891c@opy.nosense.org> Message-ID: <20110102044310.GA20694@vacation.karoshi.com.> i have seen dups in 3com, dell, and hp kit over the years. the best was moving mac addresses btwn 802,3 and 802.5 cards. --bill On Sun, Jan 02, 2011 at 03:03:24PM +1030, Mark Smith wrote: > On Sat, 01 Jan 2011 20:59:16 -0700 > Brielle Bruns wrote: > > > On 1/1/11 8:33 PM, Graham Wooden wrote: > > > So - here is the interesting part... Both servers are HP Proliant DL380 G4s, > > > and both of their NIC1 and NIC2 MACs addresses are exactly the same. Not > > > spoofd and the OS drivers are not mucking with them ... They9re burned-in - > > > I triple checked them in their respective BIOS screen. I acquired these two > > > machines at different times and both were from the grey market. The 3What > > > the ...2 is sitting fresh in my mind ... How can this be? > > > > > > From the same grey market supplier? > > > > I know HP has a disc they put out which updates all the firmware/bios in > > a specific server model, its not too far fetched that a vendor might > > have a modified version that also either purposely or accidentally > > changes the MAC address. Off the top of my head, I'm not sure where the > > MAC is stored - maybe an eeprom or a portion of the bios flash. Or, it > > could be botched flashing that blew away the portion of memory where > > that was stored and the system defaulted to a built in value. > > > > Excellent example is, IIRC, the older sparc stuff, where the ethernet > > cards didn't have MAC addresses as part of the card, but were stored in > > non-volatile or battery backed memory. > > This was actually the intended way to use "MAC" addresses, to used as > host addresses rather than as individual interface addresses, according > to the following paper - > > "48-bit Absolute Internet and Ethernet Host Numbers" > Yogan K. Dalal and Robert S. Printis, July 1981 > http://ethernethistory.typepad.com/papers/HostNumbers.pdf > > That paper also discusses why 48 bits were chosen as the size, despite > "Ethernet systems" being limited to 1024 hosts. > > I think things evolved into MAC per NIC because when add-in NICs > were invented there wasn't any appropriate non-volatile storage on the > host to store the address. > > Regards, > mark. > From graham at g-rock.net Sat Jan 1 22:44:47 2011 From: graham at g-rock.net (Graham Wooden) Date: Sat, 01 Jan 2011 22:44:47 -0600 Subject: The tale of a single MAC In-Reply-To: <5FF1A47E-A831-420F-9681-88599F6F7982@arbor.net> Message-ID: No - these are Genuine HP Servers. Both servers have the latest BIOSs and firmware applied to the board as well as cards. The search results that I have seen didn't apply to the actual bios, rather to guest Oss mucking or teamming. On 1/1/11 9:56 PM, "Dobbins, Roland" wrote: > > On Jan 2, 2011, at 10:33 AM, Graham Wooden wrote: > >> What are the odds, that HP would dup?d them and that both would eventually >> end up at my shop? > > > There may be some setting you're overlooking or a bug which needs an update to > fix, or you may simply have purchased HP ProLiant *cases*, rather than actual > *servers*. > > ;> > > Note that search engine results for 'proliant dl380 duplicate mac' returns > multiple links. > > ------------------------------------------------------------------------ > Roland Dobbins // > > Most software today is very much like an Egyptian pyramid, with millions > of bricks piled on top of each other, with no structural integrity, but > just done by brute force and thousands of slaves. > > -- Alan Kay > > From graham at g-rock.net Sat Jan 1 22:47:38 2011 From: graham at g-rock.net (Graham Wooden) Date: Sat, 01 Jan 2011 22:47:38 -0600 Subject: The tale of a single MAC In-Reply-To: <4D1FF814.50306@2mbit.com> Message-ID: Two different suppliers - one was out of Wisconsin (I believe; it's been some time), and the other of Phoenix for the most recent batch. I have lots and lots of HP server gear - and never encountered such bizarre issue. On 1/1/11 9:59 PM, "Brielle Bruns" wrote: > On 1/1/11 8:33 PM, Graham Wooden wrote: >> So ? here is the interesting part... Both servers are HP Proliant DL380 G4s, >> and both of their NIC1 and NIC2 MACs addresses are exactly the same. Not >> spoofd and the OS drivers are not mucking with them ... They?re burned-in ? >> I triple checked them in their respective BIOS screen. I acquired these two >> machines at different times and both were from the grey market. The ?What >> the ...? is sitting fresh in my mind ... How can this be? > > > From the same grey market supplier? > > I know HP has a disc they put out which updates all the firmware/bios in > a specific server model, its not too far fetched that a vendor might > have a modified version that also either purposely or accidentally > changes the MAC address. Off the top of my head, I'm not sure where the > MAC is stored - maybe an eeprom or a portion of the bios flash. Or, it > could be botched flashing that blew away the portion of memory where > that was stored and the system defaulted to a built in value. > > Excellent example is, IIRC, the older sparc stuff, where the ethernet > cards didn't have MAC addresses as part of the card, but were stored in > non-volatile or battery backed memory. Memory goes poof, and you'll > have problems. Some WRT54G/WAP54Gs suffer from the same problem when > throwing third party firmware on there. From ianh at ianh.net.au Sun Jan 2 00:00:49 2011 From: ianh at ianh.net.au (Ian Henderson) Date: Sun, 2 Jan 2011 17:00:49 +1100 Subject: The tale of a single MAC In-Reply-To: References: Message-ID: On 02/01/2011, at 2:33 PM, Graham Wooden wrote: > I encountered an interesting issue today and I found it so bizarre ? so I > thought I would share it. Had a fun one with D-Link ADSL modems a few years ago. The MAC address used to source PPPoE frames from the ADSL interface was the same in a batch of modems. This wasn't a problem when using our wholesaler's ATM based DSLAMs, but when we moved users to our own Ethernet based systems, we ran into some fun. The DSLAMs were configured to rewrite the user MAC address into a constructed address including their DSLAM port and PVC details toward the BRAS. Even though this rewrite was occurring correctly, within a single DSLAM unit two users with the same real MAC address would have five minutes of connectivity each, alternating between the two ports. Rgds, - I. From sethm at rollernet.us Sun Jan 2 00:56:24 2011 From: sethm at rollernet.us (Seth Mattinen) Date: Sat, 01 Jan 2011 22:56:24 -0800 Subject: The tale of a single MAC In-Reply-To: References: Message-ID: <4D202198.4070506@rollernet.us> On 1/1/11 7:33 PM, Graham Wooden wrote: > > So ? here is the interesting part... Both servers are HP Proliant DL380 G4s, > and both of their NIC1 and NIC2 MACs addresses are exactly the same. Not > spoofd and the OS drivers are not mucking with them ... They?re burned-in ? > I triple checked them in their respective BIOS screen. I acquired these two > machines at different times and both were from the grey market. The ?What > the ...? is sitting fresh in my mind ... How can this be? > > In the last 15 years of being in IT, I have never encountered a ?burned-in? > duplicated MACs across two physically different machines. What are the > odds, that HP would dup?d them and that both would eventually end up at my > shop? Or maybe this type of thing isn?t big of deal... ? > None of the HP servers I have contain duplicate MAC addresses. (I just looked through all the iLO2 cards to make sure I wasn't lying.) I'll send you some details offlist. ~Seth From graham at g-rock.net Sun Jan 2 07:22:33 2011 From: graham at g-rock.net (Graham Wooden) Date: Sun, 02 Jan 2011 07:22:33 -0600 Subject: The tale of a single MAC In-Reply-To: <4D202198.4070506@rollernet.us> Message-ID: Hey Seth, thanks for the reply. I don't use the iLO port, so I didn't look at it's MAC within the BIOS, however my issue isn't that the MACs are the same within a physical machine. They're different, just like all the other HP gear ... It's that I have two machines that the MACs are identical. Like Server-A's NIC1 matches Server-B's NIC1 ... And the same goes for NIC2. Heck, maybe even their iLO matches too. I just re-read my post and I can see where maybe I didn't explain it properly. Yesterday was a long day ... I guess it's not that big of deal now, I resolved it rather quickly by putting Server-B on another VLAN. On 1/2/11 12:56 AM, "Seth Mattinen" wrote: > On 1/1/11 7:33 PM, Graham Wooden wrote: >> >> So ? here is the interesting part... Both servers are HP Proliant DL380 G4s, >> and both of their NIC1 and NIC2 MACs addresses are exactly the same. Not >> spoofd and the OS drivers are not mucking with them ... They?re burned-in ? >> I triple checked them in their respective BIOS screen. I acquired these two >> machines at different times and both were from the grey market. The ?What >> the ...? is sitting fresh in my mind ... How can this be? >> >> In the last 15 years of being in IT, I have never encountered a ?burned-in? >> duplicated MACs across two physically different machines. What are the >> odds, that HP would dup?d them and that both would eventually end up at my >> shop? Or maybe this type of thing isn?t big of deal... ? >> > > > None of the HP servers I have contain duplicate MAC addresses. (I just > looked through all the iLO2 cards to make sure I wasn't lying.) I'll > send you some details offlist. > > ~Seth > From smb at cs.columbia.edu Sun Jan 2 07:50:42 2011 From: smb at cs.columbia.edu (Steven Bellovin) Date: Sun, 2 Jan 2011 08:50:42 -0500 Subject: The tale of a single MAC In-Reply-To: <20110102150324.627b891c@opy.nosense.org> References: <4D1FF814.50306@2mbit.com> <20110102150324.627b891c@opy.nosense.org> Message-ID: <00B62A16-1B89-4CD6-ACEF-588B6334EECD@cs.columbia.edu> On Jan 1, 2011, at 11:33 24PM, Mark Smith wrote: > On Sat, 01 Jan 2011 20:59:16 -0700 > Brielle Bruns wrote: > >> On 1/1/11 8:33 PM, Graham Wooden wrote: >>> So here is the interesting part... Both servers are HP Proliant DL380 G4s, >>> and both of their NIC1 and NIC2 MACs addresses are exactly the same. Not >>> spoofd and the OS drivers are not mucking with them ... They?re burned-in >>> I triple checked them in their respective BIOS screen. I acquired these two >>> machines at different times and both were from the grey market. The ?What >>> the ...? is sitting fresh in my mind ... How can this be? >> >> >> From the same grey market supplier? >> >> I know HP has a disc they put out which updates all the firmware/bios in >> a specific server model, its not too far fetched that a vendor might >> have a modified version that also either purposely or accidentally >> changes the MAC address. Off the top of my head, I'm not sure where the >> MAC is stored - maybe an eeprom or a portion of the bios flash. Or, it >> could be botched flashing that blew away the portion of memory where >> that was stored and the system defaulted to a built in value. >> >> Excellent example is, IIRC, the older sparc stuff, where the ethernet >> cards didn't have MAC addresses as part of the card, but were stored in >> non-volatile or battery backed memory. > > This was actually the intended way to use "MAC" addresses, to used as > host addresses rather than as individual interface addresses, according > to the following paper - > > "48-bit Absolute Internet and Ethernet Host Numbers" > Yogan K. Dalal and Robert S. Printis, July 1981 > http://ethernethistory.typepad.com/papers/HostNumbers.pdf Yup. > > That paper also discusses why 48 bits were chosen as the size, despite > "Ethernet systems" being limited to 1024 hosts. > > I think things evolved into MAC per NIC because when add-in NICs > were invented there wasn't any appropriate non-volatile storage on the > host to store the address. > On really old Sun gear, the MAC address was stored on a separate ROM chip; if the motherboard was replaced, you'd just move the ROM chip to the new board. I'm not sure what you mean, though, when you say "when add-in NICs were invented" -- the Ethernet cards I used in 1982 plugged into Unibus slots on our VAXen, so that goes back quite a ways... --Steve Bellovin, http://www.cs.columbia.edu/~smb From eric at tow.com Sun Jan 2 08:36:58 2011 From: eric at tow.com (Eric Tow) Date: Sun, 2 Jan 2011 09:36:58 -0500 Subject: The tale of a single MAC In-Reply-To: References: Message-ID: About 11-12 years ago, we ghosted Compaq Prosignia 330? desktops with Intel NICs. When we ghosted them, some of the desktops ended up with the same MAC addresses on the NICs. It turned out that there were two different models of Intel NICs in the desktops and ghosting the desktop with the second type of NIC resulted in the MAC address from the original Ghost computer put on that computer. Updating the NIC driver resolved the issue. Eric From rsm at fast-serv.com Sun Jan 2 08:53:40 2011 From: rsm at fast-serv.com (Randy McAnally) Date: Sun, 2 Jan 2011 09:53:40 -0500 Subject: The tale of a single MAC In-Reply-To: References: Message-ID: <20110102145137.M49586@fast-serv.com> ---------- Original Message ----------- From: Graham Wooden > Hi there, > > I encountered an interesting issue today and I found it so bizarre ? > so I thought I would share it. > > I brought online a spare server to help offload some of the recent > VMs that I have been deploying. Around the same time this new > machine (we?ll call it Server-B) came online, another machine which > has been online for about a year now stopped responding to our > monitoring (and we?ll name this Server-A). I logged into the switch > and saw that the machine that stopped responding was in the same > VLAN as this newly deployed, and then quickly noticed that Server- > A?s MAC address was now on Server-B?s switch port. ?What the ...? > was my initial response. > Fresh OS install from scratch or did you load an image from an existing server? What make/model of on-board NICs? -- Randy M. From smb at cs.columbia.edu Sun Jan 2 09:17:24 2011 From: smb at cs.columbia.edu (Steven Bellovin) Date: Sun, 2 Jan 2011 10:17:24 -0500 Subject: The tale of a single MAC In-Reply-To: References: Message-ID: <179429F8-1D2F-49E9-B932-4631FCEDA8D2@cs.columbia.edu> I should note -- this isn't that surprising. The IPv6 stateless autoconfig RFCs have always assumed that this could happen, which is why duplicate address detection is mandatory. From graham at g-rock.net Sun Jan 2 09:22:22 2011 From: graham at g-rock.net (=?utf-8?B?R1AgV29vZGVu?=) Date: Sun, 02 Jan 2011 09:22:22 -0600 Subject: =?utf-8?B?UmU6IFRoZSB0YWxlIG9mIGEgc2luZ2xlIE1BQw==?= Message-ID: <20110102152225.A91ABFF80D3@sociald.mobis.leasedminds.com> Fresh install and the NICs are Broadcom b57 10/100/1000, I believe. ----- Reply message ----- From: "Randy McAnally" Date: Sun, Jan 2, 2011 8:53 am Subject: The tale of a single MAC To: "Graham Wooden" , ---------- Original Message ----------- From: Graham Wooden > Hi there, > > I encountered an interesting issue today and I found it so bizarre ? > so I thought I would share it. > > I brought online a spare server to help offload some of the recent > VMs that I have been deploying. Around the same time this new > machine (we?ll call it Server-B) came online, another machine which > has been online for about a year now stopped responding to our > monitoring (and we?ll name this Server-A). I logged into the switch > and saw that the machine that stopped responding was in the same > VLAN as this newly deployed, and then quickly noticed that Server- > A?s MAC address was now on Server-B?s switch port. ?What the ...? > was my initial response. > Fresh OS install from scratch or did you load an image from an existing server? What make/model of on-board NICs? -- Randy M. From franck at genius.com Sun Jan 2 15:24:03 2011 From: franck at genius.com (Franck Martin) Date: Mon, 3 Jan 2011 10:24:03 +1300 (FJST) Subject: The tale of a single MAC In-Reply-To: Message-ID: <22889272.17.1294003174222.JavaMail.franck@franck-martins-macbook-pro.local> In the early 90's a friend of mine got a box of 10 HP cards with all the same MAC address. ----- Original Message ----- From: "Graham Wooden" To: nanog at nanog.org Sent: Sunday, 2 January, 2011 4:33:46 PM Subject: The tale of a single MAC Hi there, I encountered an interesting issue today and I found it so bizarre ? so I thought I would share it. I brought online a spare server to help offload some of the recent VMs that I have been deploying. Around the same time this new machine (we?ll call it Server-B) came online, another machine which has been online for about a year now stopped responding to our monitoring (and we?ll name this Server-A). I logged into the switch and saw that the machine that stopped responding was in the same VLAN as this newly deployed, and then quickly noticed that Server-A?s MAC address was now on Server-B?s switch port. ?What the ...? was my initial response. From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sun Jan 2 16:15:54 2011 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Mon, 3 Jan 2011 08:45:54 +1030 Subject: The tale of a single MAC In-Reply-To: <00B62A16-1B89-4CD6-ACEF-588B6334EECD@cs.columbia.edu> References: <4D1FF814.50306@2mbit.com> <20110102150324.627b891c@opy.nosense.org> <00B62A16-1B89-4CD6-ACEF-588B6334EECD@cs.columbia.edu> Message-ID: <20110103084554.6421c76c@opy.nosense.org> Hi, On Sun, 2 Jan 2011 08:50:42 -0500 Steven Bellovin wrote: > > On Jan 1, 2011, at 11:33 24PM, Mark Smith wrote: > > > On Sat, 01 Jan 2011 20:59:16 -0700 > > Brielle Bruns wrote: > > > >> On 1/1/11 8:33 PM, Graham Wooden wrote: > >> > >> Excellent example is, IIRC, the older sparc stuff, where the ethernet > >> cards didn't have MAC addresses as part of the card, but were stored in > >> non-volatile or battery backed memory. > > > > This was actually the intended way to use "MAC" addresses, to used as > > host addresses rather than as individual interface addresses, according > > to the following paper - > > > > "48-bit Absolute Internet and Ethernet Host Numbers" > > Yogan K. Dalal and Robert S. Printis, July 1981 > > http://ethernethistory.typepad.com/papers/HostNumbers.pdf > > Yup. > > > > That paper also discusses why 48 bits were chosen as the size, despite > > "Ethernet systems" being limited to 1024 hosts. > > > > I think things evolved into MAC per NIC because when add-in NICs > > were invented there wasn't any appropriate non-volatile storage on the > > host to store the address. > > > On really old Sun gear, the MAC address was stored on a separate ROM chip; if the > motherboard was replaced, you'd just move the ROM chip to the new board. > > I'm not sure what you mean, though, when you say "when add-in NICs were > invented" -- the Ethernet cards I used in 1982 plugged into Unibus slots > on our VAXen, so that goes back quite a ways... > More that as add-in cards supplied their own "storage" for the MAC address, rather than expecting it from the host (e.g. something like MAC addresses set by init scripts at boot or the ROM chip you mentioned on Suns), this has now evolved into an expected model of a MAC address tightly bound to an Ethernet interface and supplied by the Ethernet interface e.g. by an add-in board if one is added. Now that this model as been around for a long time, people find it a bit strange when MAC addresses aren't as tightly bound to a NIC/Ethernet interface. This is all speculation on my part though, I'd be curious if the reasons are different. When I first read that paper, it was really quite surprising that "MAC" addresses were designed to be more general host addresses/identifiers that were also to be used as Ethernet addresses. One example they talk about is using them as unique host identifiers when sharing files via floppy disk. Regards, mark. From mikea at mikea.ath.cx Sun Jan 2 16:26:54 2011 From: mikea at mikea.ath.cx (mikea) Date: Sun, 2 Jan 2011 16:26:54 -0600 Subject: The tale of a single MAC In-Reply-To: References: Message-ID: <20110102222654.GA42531@mikea.ath.cx> On Sat, Jan 01, 2011 at 09:33:46PM -0600, Graham Wooden wrote: > Hi there, > > I encountered an interesting issue today and I found it so bizarre ? so I > thought I would share it. > > I brought online a spare server to help offload some of the recent VMs that > I have been deploying. Around the same time this new machine (we?ll call it > Server-B) came online, another machine which has been online for about a > year now stopped responding to our monitoring (and we?ll name this > Server-A). I logged into the switch and saw that the machine that stopped > responding was in the same VLAN as this newly deployed, and then quickly > noticed that Server-A?s MAC address was now on Server-B?s switch port. > ?What the ...? was my initial response. > > I went ahead and moved Server-B?s to another VLAN, updated the switchport, > cleared the ARP, and Server-A came back to life. Happy new year to me. > > So ? here is the interesting part... Both servers are HP Proliant DL380 G4s, > and both of their NIC1 and NIC2 MACs addresses are exactly the same. Not > spoofd and the OS drivers are not mucking with them ... They?re burned-in ? > I triple checked them in their respective BIOS screen. I acquired these two > machines at different times and both were from the grey market. The ?What > the ...? is sitting fresh in my mind ... How can this be? > > In the last 15 years of being in IT, I have never encountered a ?burned-in? > duplicated MACs across two physically different machines. What are the > odds, that HP would dup?d them and that both would eventually end up at my > shop? Or maybe this type of thing isn?t big of deal... ? We got a batch of NICS that had duplicate MACs in several pallets of IBM desktops, about 15 years back. We noticed this only when two of the machines were shipped to the same field office location. I've heard other state agencies talk about the same sort of problem with IBM and several other vendors. -- Mike Andrews, W5EGO mikea at mikea.ath.cx Tired old sysadmin From smb at cs.columbia.edu Sun Jan 2 16:38:54 2011 From: smb at cs.columbia.edu (Steven Bellovin) Date: Sun, 2 Jan 2011 17:38:54 -0500 Subject: The tale of a single MAC In-Reply-To: <20110103084554.6421c76c@opy.nosense.org> References: <4D1FF814.50306@2mbit.com> <20110102150324.627b891c@opy.nosense.org> <00B62A16-1B89-4CD6-ACEF-588B6334EECD@cs.columbia.edu> <20110103084554.6421c76c@opy.nosense.org> Message-ID: On Jan 2, 2011, at 5:15 54PM, Mark Smith wrote: > Hi, > > On Sun, 2 Jan 2011 08:50:42 -0500 > Steven Bellovin wrote: > >> >> On Jan 1, 2011, at 11:33 24PM, Mark Smith wrote: >> >>> On Sat, 01 Jan 2011 20:59:16 -0700 >>> Brielle Bruns wrote: >>> >>>> On 1/1/11 8:33 PM, Graham Wooden wrote: > > > >>>> >>>> Excellent example is, IIRC, the older sparc stuff, where the ethernet >>>> cards didn't have MAC addresses as part of the card, but were stored in >>>> non-volatile or battery backed memory. >>> >>> This was actually the intended way to use "MAC" addresses, to used as >>> host addresses rather than as individual interface addresses, according >>> to the following paper - >>> >>> "48-bit Absolute Internet and Ethernet Host Numbers" >>> Yogan K. Dalal and Robert S. Printis, July 1981 >>> http://ethernethistory.typepad.com/papers/HostNumbers.pdf >> >> Yup. >>> >>> That paper also discusses why 48 bits were chosen as the size, despite >>> "Ethernet systems" being limited to 1024 hosts. >>> >>> I think things evolved into MAC per NIC because when add-in NICs >>> were invented there wasn't any appropriate non-volatile storage on the >>> host to store the address. >>> >> On really old Sun gear, the MAC address was stored on a separate ROM chip; if the >> motherboard was replaced, you'd just move the ROM chip to the new board. >> >> I'm not sure what you mean, though, when you say "when add-in NICs were >> invented" -- the Ethernet cards I used in 1982 plugged into Unibus slots >> on our VAXen, so that goes back quite a ways... >> > > More that as add-in cards supplied their own "storage" for the MAC > address, rather than expecting it from the host (e.g. something like > MAC addresses set by init scripts at boot or the ROM chip you > mentioned on Suns), this has now evolved into an expected model of a > MAC address tightly bound to an Ethernet interface and supplied by the > Ethernet interface e.g. by an add-in board if one is added. Now that > this model as been around for a long time, people find it a bit strange > when MAC addresses aren't as tightly bound to a NIC/Ethernet interface. > This is all speculation on my part though, I'd be curious if the > reasons are different. > > When I first read that paper, it was really quite surprising that "MAC" > addresses were designed to be more general host addresses/identifiers > that were also to be used as Ethernet addresses. One example they talk > about is using them as unique host identifiers when sharing files via > floppy disk. > If you read the XNS specs, you'll see that they liked 64-bit addresses -- a 16-bit network number and a 48-bit host address. In other words, they had id/locator separation... --Steve Bellovin, http://www.cs.columbia.edu/~smb From corey at sequestered.net Sun Jan 2 19:39:00 2011 From: corey at sequestered.net (Corey Quinn) Date: Sun, 2 Jan 2011 17:39:00 -0800 Subject: The tale of a single MAC In-Reply-To: <22889272.17.1294003174222.JavaMail.franck@franck-martins-macbook-pro.local> References: <22889272.17.1294003174222.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <1B9985A3-5F00-47FE-BCB3-265A673C9C71@sequestered.net> On Jan 2, 2011, at 1:24 PM, Franck Martin wrote: > In the early 90's a friend of mine got a box of 10 HP cards with all the same MAC address. In my early days of network admining, a coworker told me a (apocryphal) story of 3com shipping a batch of 80K cards with identical MAC addresses, which they then had to recall. Unfortunately a cursory Google turns up nothing, so I suppose he was either misinformed or pulling my leg. -- Corey Quinn / KB1JWQ From tme at americafree.tv Sun Jan 2 20:00:02 2011 From: tme at americafree.tv (Marshall Eubanks) Date: Sun, 2 Jan 2011 21:00:02 -0500 Subject: The tale of a single MAC In-Reply-To: <1B9985A3-5F00-47FE-BCB3-265A673C9C71@sequestered.net> References: <22889272.17.1294003174222.JavaMail.franck@franck-martins-macbook-pro.local> <1B9985A3-5F00-47FE-BCB3-265A673C9C71@sequestered.net> Message-ID: On Jan 2, 2011, at 8:39 PM, Corey Quinn wrote: > > On Jan 2, 2011, at 1:24 PM, Franck Martin wrote: > >> In the early 90's a friend of mine got a box of 10 HP cards with all the same MAC address. > > In my early days of network admining, a coworker told me a (apocryphal) story of 3com shipping a batch of 80K cards with identical MAC addresses, which they then had to recall. > > Unfortunately a cursory Google turns up nothing, so I suppose he was either misinformed or pulling my leg. > I have also heard such stories, again from the '90s. Can cause odd failure modes. Regards Marshall > -- Corey Quinn / KB1JWQ > > > From shrdlu at deaddrop.org Sun Jan 2 21:31:53 2011 From: shrdlu at deaddrop.org (Lynda) Date: Sun, 02 Jan 2011 19:31:53 -0800 Subject: The tale of a single MAC In-Reply-To: References: <22889272.17.1294003174222.JavaMail.franck@franck-martins-macbook-pro.local> <1B9985A3-5F00-47FE-BCB3-265A673C9C71@sequestered.net> Message-ID: <4D214329.1060701@deaddrop.org> On 1/2/2011 6:00 PM, Marshall Eubanks wrote: > On Jan 2, 2011, at 8:39 PM, Corey Quinn wrote: > >> >> On Jan 2, 2011, at 1:24 PM, Franck Martin wrote: >>> In the early 90's a friend of mine got a box of 10 HP cards with >>> all the same MAC address. >> In my early days of network admining, a coworker told me a >> (apocryphal) story of 3com shipping a batch of 80K cards with >> identical MAC addresses, which they then had to recall. >> Unfortunately a cursory Google turns up nothing, so I suppose he >> was either misinformed or pulling my leg. > I have also heard such stories, again from the '90s. Can cause odd > failure modes. Google does NOT know all. I was there. I have had to deal with a building full of such wickedness. I administered DNS (in my copious spare time) for two subdomains, and managed the network in the building (a not inconsiderable /22, and also in my spare time), and started getting frantic calls from people who were getting knocked off the network because their machine had the same MAC address as another. I had trouble believing it at first, but after dealing with five of them (all Gateways, and yes, all with the same MAC address), I directed the local sysadmins to disable the nic that came with them, and to replace it with a spare. I understand that there were 30,000 of them, all with the same address. My guess is that you'll never find it on Google, since it happened around 1993-4 or so. -- A picture is worth 10K words -- but only those to describe the picture. Hardly any sets of 10K words can be adequately described with pictures. From rdobbins at arbor.net Sun Jan 2 22:31:57 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Mon, 3 Jan 2011 04:31:57 +0000 Subject: The tale of a single MAC In-Reply-To: <4D214329.1060701@deaddrop.org> References: <22889272.17.1294003174222.JavaMail.franck@franck-martins-macbook-pro.local> <1B9985A3-5F00-47FE-BCB3-265A673C9C71@sequestered.net> <4D214329.1060701@deaddrop.org> Message-ID: <78D2B812-4565-44DD-A465-CAE95C1FDD38@arbor.net> On Jan 3, 2011, at 10:31 AM, Lynda wrote: > My guess is that you'll never find it on Google, since it happened around 1993-4 or so. I remember that there were several high-profile instances of duplicate MAC addresses being burnt into NICs during the 1990s - once every 2-3 years, IIRC. And those were just the ones that were discussed publicly. Not to mention the old ARCNet NICs, which all came set to the same ARCNet address by default (one changed the address assignment via DIP switches on the cards themselves). ;> ------------------------------------------------------------------------ Roland Dobbins // Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay From joseph.prasad at gmail.com Mon Jan 3 00:03:36 2011 From: joseph.prasad at gmail.com (Joseph Prasad) Date: Sun, 2 Jan 2011 22:03:36 -0800 Subject: Wikileaks, Friend or Foe? Message-ID: A very good interview with John Young on Russia Today. http://www.youtube.com/watch?v=oMRUiB_8tTc ------- mentioned in the interview------ http://cryptome.org/ http://en.wikipedia.org/wiki/Cypherpunks *--------------------------------* *The only power people exert over us, is the power we allow them to exert.* * * *http://www.projectcensored.org/* * * *http://www.thenewamerican.com/* *--------------------------------* * * From swmike at swm.pp.se Mon Jan 3 00:05:24 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 3 Jan 2011 07:05:24 +0100 (CET) Subject: The tale of a single MAC In-Reply-To: <78D2B812-4565-44DD-A465-CAE95C1FDD38@arbor.net> References: <22889272.17.1294003174222.JavaMail.franck@franck-martins-macbook-pro.local> <1B9985A3-5F00-47FE-BCB3-265A673C9C71@sequestered.net> <4D214329.1060701@deaddrop.org> <78D2B812-4565-44DD-A465-CAE95C1FDD38@arbor.net> Message-ID: On Mon, 3 Jan 2011, Dobbins, Roland wrote: > I remember that there were several high-profile instances of duplicate > MAC addresses being burnt into NICs during the 1990s - once every 2-3 > years, IIRC. And those were just the ones that were discussed publicly. D-Link shipped NAT-boxes around 2003-2004 or so with identical MAC addresses (and a "clone your PC mac address to the WAN interface"-functionality). I checked my then employer ADSL network and 5% of the customer ports had the same MAC address, D-Link support alledgedly said something about the MAC address not being "unique enough" and directed their customers to the cloning functionality to "solve" the problem. -- Mikael Abrahamsson email: swmike at swm.pp.se From daniel.dib at reaper.nu Mon Jan 3 03:40:02 2011 From: daniel.dib at reaper.nu (Daniel Dib) Date: Mon, 3 Jan 2011 10:40:02 +0100 Subject: The tale of a single MAC In-Reply-To: References: <22889272.17.1294003174222.JavaMail.franck@franck-martins-macbook-pro.local> <1B9985A3-5F00-47FE-BCB3-265A673C9C71@sequestered.net> <4D214329.1060701@deaddrop.org> <78D2B812-4565-44DD-A465-CAE95C1FDD38@arbor.net> Message-ID: <000301cbab2a$35b91810$a12b4830$@dib@reaper.nu> On Mon, jan 03, 2011 at 07:05:24, Mikael Abrahamsson wrote: > Subject: Re: The tale of a single MAC > > On Mon, 3 Jan 2011, Dobbins, Roland wrote: > > > I remember that there were several high-profile instances of > duplicate > > MAC addresses being burnt into NICs during the 1990s - once every > > 2-3 years, IIRC. And those were just the ones that were discussed > publicly. > > D-Link shipped NAT-boxes around 2003-2004 or so with identical MAC > addresses (and a "clone your PC mac address to the WAN interface"- > functionality). I checked my then employer ADSL network and 5% of the > customer ports had the same MAC address, D-Link support alledgedly > said something about the MAC address not being "unique enough" and > directed their customers to the cloning functionality to "solve" the problem. > > -- > Mikael Abrahamsson email: swmike at swm.pp.se Years ago D-link and Linksys and maybe other vendors used the source MAC of 00:00:00:00:00:00 which isn't very nice and could cause interesting issues. At my current job we used to have a routine to find these MACs and tell the users to change to a valid address. From nanog at jima.tk Mon Jan 3 08:41:59 2011 From: nanog at jima.tk (Jima) Date: Mon, 03 Jan 2011 08:41:59 -0600 Subject: The tale of a single MAC In-Reply-To: References: Message-ID: <4D21E037.7070204@jima.tk> On 01/01/2011 09:33 PM, Graham Wooden wrote: > In the last 15 years of being in IT, I have never encountered a ?burned-in? > duplicated MACs across two physically different machines. What are the > odds, that HP would dup?d them and that both would eventually end up at my > shop? Or maybe this type of thing isn?t big of deal... ? Out of curiosity, have you checked if there's a sticker on the board with the MAC address(es)? I know a lot of vendors do that. Jima From mailinglists at expresswebsystems.com Mon Jan 3 09:45:45 2011 From: mailinglists at expresswebsystems.com (Express Web Systems) Date: Mon, 3 Jan 2011 09:45:45 -0600 Subject: The tale of a single MAC In-Reply-To: References: Message-ID: <00de01cbab5d$49479f90$dbd6deb0$@com> One interesting aside to all of this... HP Lefthand SAN actually licenses the SAN/IQ software off of the NIC1 MAC address. I can't help but wonder if the MAC address is set to that specific address to possibly get around that (perhaps a leaked license or something). If nothing else... You can license both boxes with the same license of SAN/IQ, just don't put them in the same cluster. ;) Tom From jaitken at aitken.com Mon Jan 3 11:02:00 2011 From: jaitken at aitken.com (Jeff Aitken) Date: Mon, 3 Jan 2011 17:02:00 +0000 Subject: Router only speaks IGP in BGP network In-Reply-To: <4D15F72A.4060401@kenweb.org> References: <201012251636.32869.mtinka@globaltransit.net> <4D15F72A.4060401@kenweb.org> Message-ID: <20110103170200.GA51454@eagle.aitken.com> On Sat, Dec 25, 2010 at 08:52:42AM -0500, ML wrote: > If you're only redistributing 10 prefixes into OSPF? Problem? I know I'm a little late to this thread, but figured I'd point out one reason why this can be very dangerous: In IOS, you use a route-map to control redistribution between protocols. For example, if you want to redist just those BGP prefixes tagged with a specific community into OSPF, you will probably configure something that looks like this: route-map bgp-to-ospf permit 10 match community $COMMUNITY ! route-map bgp-to-ospf deny 20 ! router ospf $PID redistribute bgp $ASN subnets route-map bgp-to-ospf Now, consider the following failure scenarios: 1. Someone typo's a BGP config elsewhere in your network and attaches $COMMUNITY to a whole bunch more routes... say, all 350k being sent by your upstream provider. *oops* 2. An engineer thinks that there's something wrong with the redistribution and decides to temporarily disable it as part of the troubleshooting process. He types the following: conf t router ospf $PID no redistribute bgp $ASN subnets route-map bgp-to-ospf *boom* He just dumped all BGP routes into OSPF, due to the way IOS parses the command: it removes the route-map but leaves the redistribution intact. To be fair, Cisco does provide you with tools to mitigate this risk (see the "redistribute maximum-prefix" command) but the point is that this is a fairly easy mistake to make. At the end of the day, the reason that many folks advise against the redistribution of BGP into an IGP is that it sets the stage for a seemingly insignificant mistake to cause a not-so-insignificant outage. --Jeff From ken at sizone.org Mon Jan 3 12:04:55 2011 From: ken at sizone.org (Ken Chase) Date: Mon, 3 Jan 2011 13:04:55 -0500 Subject: sudden low spam levels? Message-ID: <20110103180455.GS12141@sizone.org> I have two independent mailservers, and two other customers that run their own servers, all largely unrelated infrastructures and target domains, suddenly experiencing low levels of spam. Total emails/day dropping from some 175,000-250,000ish to 50-75,000ish (legit mail in the 2-5,000 per day, yes I have some high spam:legit customers...). 3 days in a row now at least, at quick glance. Did someone set up them the bomb? /kc -- Ken Chase - ken at heavycomputing.ca - +1 416 897 6284 - Toronto CANADA Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W. From rsm at fast-serv.com Mon Jan 3 12:09:59 2011 From: rsm at fast-serv.com (Randy McAnally) Date: Mon, 3 Jan 2011 13:09:59 -0500 Subject: sudden low spam levels? In-Reply-To: <20110103180455.GS12141@sizone.org> References: <20110103180455.GS12141@sizone.org> Message-ID: <20110103180754.M97523@fast-serv.com> ---------- Original Message ----------- From: Ken Chase To: nanog at nanog.org Sent: Mon, 3 Jan 2011 13:04:55 -0500 Subject: sudden low spam levels? > I have two independent mailservers, and two other customers that run > their own servers, all largely unrelated infrastructures and target > domains, suddenly experiencing low levels of spam. > > Total emails/day dropping from some 175,000-250,000ish to 50-75, > 000ish (legit mail in the 2-5,000 per day, yes I have some high > spam:legit customers...). 3 days in a row now at least, at quick glance. > > Did someone set up them the bomb? > We filter spam for over 2000 domains and I don't see any noticeable drop in payload. I have noticed that over the past few months greylisting has become MUCH more effective than it used to be... looks like spam delivery is moving more from snowshoe infrastructure towards botnets. -- Randy M. www.FastServ.com From scott at doc.net.au Mon Jan 3 13:04:37 2011 From: scott at doc.net.au (Scott Howard) Date: Mon, 3 Jan 2011 11:04:37 -0800 Subject: sudden low spam levels? In-Reply-To: <20110103180455.GS12141@sizone.org> References: <20110103180455.GS12141@sizone.org> Message-ID: On Mon, Jan 3, 2011 at 10:04 AM, Ken Chase wrote: > I have two independent mailservers, and two other customers that run their > own > servers, all largely unrelated infrastructures and target domains, suddenly > experiencing low levels of spam. > There's definitely been a drop-off in spam levels over the past week, which comes on top of a general drop over the past few months. Although far from a great indicator of global levels, the following two graphs give a good idea on what's happening on a relative basis : Past Month - http://www.spamcop.net/spamgraph.shtml?spammonth Past Year - http://www.spamcop.net/spamgraph.shtml?spamyear The numbers for December are especially unusual, as with Christmas coming it's normally one of the higher months for spam. The drop-off since September is mainly due to the closure of spamit.com(Pharma spam referal company), although I haven't seen any reports of what's caused the drop-off in the past week or so. Scott. From tme at americafree.tv Mon Jan 3 13:39:44 2011 From: tme at americafree.tv (Marshall Eubanks) Date: Mon, 3 Jan 2011 14:39:44 -0500 Subject: sudden low spam levels? In-Reply-To: References: <20110103180455.GS12141@sizone.org> Message-ID: On Jan 3, 2011, at 2:04 PM, Scott Howard wrote: > On Mon, Jan 3, 2011 at 10:04 AM, Ken Chase wrote: > >> I have two independent mailservers, and two other customers that run their >> own >> servers, all largely unrelated infrastructures and target domains, suddenly >> experiencing low levels of spam. >> > > There's definitely been a drop-off in spam levels over the past week, which > comes on top of a general drop over the past few months. > According the to Symantec "December 2010 State of Spam & Phishing Report", spam is reducing http://www.spamfighter.com/News-15570-Spam-Volume-Continues-to-Decrease-Symantec.htm I have seen various reports relating this to the taking down of this or that botnet (see, e.g., http://www.eweek.com/c/a/Security/Botnet-Holiday-Spam-Levels-Drop-for-Christmas-566115/ ) but I would take that with a big grain of salt. Regards Marshall > Although far from a great indicator of global levels, the following two > graphs give a good idea on what's happening on a relative basis : > Past Month - http://www.spamcop.net/spamgraph.shtml?spammonth > Past Year - http://www.spamcop.net/spamgraph.shtml?spamyear > > The numbers for December are especially unusual, as with Christmas coming > it's normally one of the higher months for spam. > > The drop-off since September is mainly due to the closure of > spamit.com(Pharma spam referal company), although I haven't seen any > reports of what's > caused the drop-off in the past week or so. > > Scott. > From msergeant at messagelabs.com Mon Jan 3 13:50:32 2011 From: msergeant at messagelabs.com (Matt Sergeant) Date: Mon, 03 Jan 2011 14:50:32 -0500 Subject: sudden low spam levels? In-Reply-To: <20110103180455.GS12141@sizone.org> References: <20110103180455.GS12141@sizone.org> Message-ID: <4D222888.8010005@messagelabs.com> Ken Chase wrote: > I have two independent mailservers, and two other customers that run their own > servers, all largely unrelated infrastructures and target domains, suddenly > experiencing low levels of spam. > > Total emails/day dropping from some 175,000-250,000ish to 50-75,000ish (legit > mail in the 2-5,000 per day, yes I have some high spam:legit customers...). 3 > days in a row now at least, at quick glance. > > Did someone set up them the bomb? > Something killed off RuStock at Xmas. Matt. ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From ml-nanog090304q at elcsplace.com Mon Jan 3 17:35:47 2011 From: ml-nanog090304q at elcsplace.com (Ted Cooper) Date: Tue, 04 Jan 2011 09:35:47 +1000 Subject: sudden low spam levels? In-Reply-To: <20110103180455.GS12141@sizone.org> References: <20110103180455.GS12141@sizone.org> Message-ID: <4D225D53.9020805@elcsplace.com> On 04/01/11 04:04, Ken Chase wrote: > I have two independent mailservers, and two other customers that run their own > servers, all largely unrelated infrastructures and target domains, suddenly > experiencing low levels of spam. Connection and rejection counts have been going bonkers of late for me. I run filters for a number of small businesses so I don't see huge amounts of traffic, but it's usually fairly regular in volume of mail and rejected attempts. Leading up to the 21nd of December, it was fairly level but low at 60-90% normal volume of rejections per day, then the 22nd went to 200% followed by a low of 30-50% normal for 23-29th. On the 30th through the 1st of Jan, the Storm? bot went nuts and rejections went to at least 500% normal (entirely on cheap checks - HELO, rDNS). After that, I had to go double check the mail servers were actually running all the time as rejection counts hit 2-10% normal. I haven't seen an obvious Storm bot type connection since. Did someone kill the botnet? Or have the the virus writers finally decided to chance tack? Or have they hunted out all the servers that reject every single attempt and no longer send to them? The only thing I can be certain of, is that they'll be back and my spam levels will be back to normal sometime soon. From jayfar at jayfar.com Mon Jan 3 17:42:57 2011 From: jayfar at jayfar.com (Jay Farrell) Date: Mon, 3 Jan 2011 18:42:57 -0500 Subject: sudden low spam levels? In-Reply-To: <4D225D53.9020805@elcsplace.com> References: <20110103180455.GS12141@sizone.org> <4D225D53.9020805@elcsplace.com> Message-ID: I noticed a substantial drop in spam in my gmail account in recent days, from several hundred a day to maybe a hundred. Ironically, gmail filtered this thread to my spam folder. Cheers, Jayfar From oberman at es.net Mon Jan 3 23:00:53 2011 From: oberman at es.net (Kevin Oberman) Date: Mon, 03 Jan 2011 21:00:53 -0800 Subject: The tale of a single MAC In-Reply-To: Your message of "Mon, 03 Jan 2011 08:45:54 +1030." <20110103084554.6421c76c@opy.nosense.org> Message-ID: <20110104050053.256391CC16@ptavv.es.net> > Date: Mon, 3 Jan 2011 08:45:54 +1030 > From: Mark Smith > > Hi, > > On Sun, 2 Jan 2011 08:50:42 -0500 > Steven Bellovin wrote: > > > > > On Jan 1, 2011, at 11:33 24PM, Mark Smith wrote: > > > > > On Sat, 01 Jan 2011 20:59:16 -0700 > > > Brielle Bruns wrote: > > > > > >> On 1/1/11 8:33 PM, Graham Wooden wrote: > > > > > >> > > >> Excellent example is, IIRC, the older sparc stuff, where the ethernet > > >> cards didn't have MAC addresses as part of the card, but were stored in > > >> non-volatile or battery backed memory. > > > > > > This was actually the intended way to use "MAC" addresses, to used as > > > host addresses rather than as individual interface addresses, according > > > to the following paper - > > > > > > "48-bit Absolute Internet and Ethernet Host Numbers" > > > Yogan K. Dalal and Robert S. Printis, July 1981 > > > http://ethernethistory.typepad.com/papers/HostNumbers.pdf > > > > Yup. > > > > > > That paper also discusses why 48 bits were chosen as the size, despite > > > "Ethernet systems" being limited to 1024 hosts. > > > > > > I think things evolved into MAC per NIC because when add-in NICs > > > were invented there wasn't any appropriate non-volatile storage on the > > > host to store the address. > > > > > On really old Sun gear, the MAC address was stored on a separate ROM chip; if the > > motherboard was replaced, you'd just move the ROM chip to the new board. > > > > I'm not sure what you mean, though, when you say "when add-in NICs were > > invented" -- the Ethernet cards I used in 1982 plugged into Unibus slots > > on our VAXen, so that goes back quite a ways... > > > > More that as add-in cards supplied their own "storage" for the MAC > address, rather than expecting it from the host (e.g. something like > MAC addresses set by init scripts at boot or the ROM chip you > mentioned on Suns), this has now evolved into an expected model of a > MAC address tightly bound to an Ethernet interface and supplied by the > Ethernet interface e.g. by an add-in board if one is added. Now that > this model as been around for a long time, people find it a bit strange > when MAC addresses aren't as tightly bound to a NIC/Ethernet interface. > This is all speculation on my part though, I'd be curious if the > reasons are different. > > When I first read that paper, it was really quite surprising that "MAC" > addresses were designed to be more general host addresses/identifiers > that were also to be used as Ethernet addresses. One example they talk > about is using them as unique host identifiers when sharing files via > floppy disk. My Ethernet experience goes back before VAXen and the DEUNA to the original DIX Ethernet 3Com and InterLAN cards. They had the MAC in a ROM on the card set. (Yes, they were 2 card sets with a top of the card ribbon cable between them.) Don't confuse this with the REALLY old Ethernet V1 3Com and Wang 1 and 10 Mbps Ethernet, which I did not personally deal with. I worked with early Ethernet on quite a few systems and the only one I ever ran into that implemented the single per-system hardware MAC was Sun, though others (notably Digital, SGI and Xerox) would re-write all MACs with a single value derived from the network address (DECnet or XNS) at boot time. I seem to remember that Tektronix systems also did this before they bought the rights to the CMU TCP-IP stack and moved to IP. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From tariq198487 at hotmail.com Tue Jan 4 00:00:27 2011 From: tariq198487 at hotmail.com (Tarig Ahmed) Date: Tue, 4 Jan 2011 09:00:27 +0300 Subject: Router only speaks IGP in BGP network In-Reply-To: <20110103170200.GA51454@eagle.aitken.com> References: <201012251636.32869.mtinka@globaltransit.net> <4D15F72A.4060401@kenweb.org> <20110103170200.GA51454@eagle.aitken.com> Message-ID: On Jan 3, 2011, at 8:02 PM, Jeff Aitken wrote: > On Sat, Dec 25, 2010 at 08:52:42AM -0500, ML wrote: >> If you're only redistributing 10 prefixes into OSPF? Problem? > > I know I'm a little late to this thread, but figured I'd point out one > reason why this can be very dangerous: > > In IOS, you use a route-map to control redistribution between > protocols. > For example, if you want to redist just those BGP prefixes tagged > with a > specific community into OSPF, you will probably configure something > that > looks like this: > > route-map bgp-to-ospf permit 10 > match community $COMMUNITY > ! > route-map bgp-to-ospf deny 20 > ! > router ospf $PID > redistribute bgp $ASN subnets route-map bgp-to-ospf > > > Now, consider the following failure scenarios: > > 1. Someone typo's a BGP config elsewhere in your network and attaches > $COMMUNITY to a whole bunch more routes... say, all 350k being sent > by your > upstream provider. *oops* > > 2. An engineer thinks that there's something wrong with the > redistribution > and decides to temporarily disable it as part of the troubleshooting > process. He types the following: > > conf t > router ospf $PID > no redistribute bgp $ASN subnets route-map bgp-to-ospf > > *boom* > > He just dumped all BGP routes into OSPF, due to the way IOS parses the > command: it removes the route-map but leaves the redistribution > intact. > To be fair, Cisco does provide you with tools to mitigate this risk > (see > the "redistribute maximum-prefix" command) but the point is that > this is > a fairly easy mistake to make. > > At the end of the day, the reason that many folks advise against the > redistribution of BGP into an IGP is that it sets the stage for a > seemingly > insignificant mistake to cause a not-so-insignificant outage. > > > --Jeff > > > This is an interesting point. But why cisco *no* command does not remove the redistribute , I think it should do. Thanks From mmzinyi at yahoo.com Tue Jan 4 01:04:14 2011 From: mmzinyi at yahoo.com (jacob miller) Date: Mon, 3 Jan 2011 23:04:14 -0800 (PST) Subject: Software For Telcos Message-ID: <360440.86064.qm@web39502.mail.mud.yahoo.com> Hi, I have been wondering what type of Software do top telcos use. The tracking of Customer circuits to ensure that from marketing,sales,accounts and technical department everything to do with the circuits has to be tracked. Anyone with any help in regards to top software that can be used to run such a telco to ensure that world class service is obtained will be crucial. Regards, Jacob From iljitsch at muada.com Tue Jan 4 05:29:48 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 4 Jan 2011 12:29:48 +0100 Subject: 2010 IPv4 (and IPv6) Address Use Report Message-ID: <49A2BD30-5F17-40FA-A862-FF8C7496DAE0@muada.com> [ (Non-cross)posted to NANOG, PPML, RIPE IPv6 wg, Dutch IPv6 TF. ] On the web: IPv4: http://www.bgpexpert.com/addrspace2010.php IPv6: http://www.bgpexpert.com/addrspace-ipv6-2010.php The IPv4 one is included below: 2010 IPv4 Address Use Report As of January 1, 2011, the number of unused IPv4 addresses is 495.66 million. Exactly a year earlier, the number of available addresses was 721.06 million. So we collectively used up 225.4 million addresses in 2010. 35 of the 256 the /8s that make up the IPv4 address space have the status "reserved". 0 and 127 have special meaning and can't be used for normal purposes. 224 - 239 are used for multicast and 240 - 255 are "reserved for future use". With only about two years worth of IPv4 addresses remaining on the shelves, it would seem that that future is here now, but unfortunately, pretty much all operating systems balk at using a "reserved" address. So unreserving those addresses means upgrading EVERY system connected to the Internet. If we're going to do that, we may as well skip those reserved IPv4 addresses and upgrade to IPv6. Last but not least, there's block 10, which is the largest of the three address blocks set aside for private use. The others, 172.16.0.0/12 and 192.168.0.0/16, don't show up as reserved, but are obviously not available for regular use. This makes the total number of usable IPv4 addresses is (256 - 35) * 2^24 - 2^20 - 2^16 = 3706.65 million addresses. The "IANA global pool" consists of 7 /8s (117.44 million) are still unused (unallocated): 39/8, 102/8, 103/8, 104/8, 106/8, 179/8 and 185/8. But there's also a lot of unused space hiding in the "allocated" and "legacy" categories. Each RIR publishes a list of address blocks further delegated to ISPs or end users every day on their FTP servers. If we add up all those blocks, this comes out to 3210.99 million addresses. So the total number of usable-but-unused IPv4 addresses is 3706.65 - 3210.99 = 495.66 million. Going back to the IANA global pool, these are the changes over the past year: Delegated Blocks +/- 2010 to/status AfriNIC 3 +1 APNIC 42 +8 ARIN 35 +4 LACNIC 8 +2 RIPE NCC 34 +4 LEGACY 92 UNALLOCATED 7 -19 There is an agreement between IANA and the RIRs that each RIR will get one of the last five /8s. APNIC has been getting two /8s every three months like clockwork in 2010. If this continues, they'll be getting numbers 7 and 6 later this month, and then the final distribution will look like this: Delegated Blocks +/- 2010 to/status AfriNIC 4 APNIC 45 ARIN 36 LACNIC 9 RIPE NCC 35 LEGACY 92 UNALLOCATED - At this point, it becomes very interesting what the status of the legacy space is, exactly. The legacy blocks are each "administered" by one of the RIRs, but does that mean that that RIR is free to further delegate that space to ISPs and end users? There are 146.92 million unused addresses in legacy space, including 16.65 million returned by Interop a few months ago. This is the used versus unused address space administered by each RIR: Legacy Allocated total unused total unused AfriNIC 33.55 24.85 50.33 27.06 APNIC 100.66 22.32 704.64 44.38 ARIN 654.31 60.55 587.20 56.21 LACNIC - - 134.22 37.39 RIPE NCC 67.11 5.77 570.43 67.38 IANA 671.09 16.65 - - AfriNIC used up 8.95 million addresses last year. So their current unused allocated space is good for another three years (if nothing changes) and their final /8 is worth another almost two years. If they get to use their legacy space, that buys them another 2.5 years. So unless IPv4 address use really takes off in Africa, AfriNIC will be handing out addresses for at least three or four years. APNIC is at the opposite end of the spectrum, using up no less than 126.22 million new IPv4 addresses last year. Even if they get to use the legacy space they administer on top of three of the last seven /8s and, it's hard to see how APNIC can avoid having to tell people "no" before the year is out. However, there is a caveat: in the 2010 APNIC records, there is 6.65 million addresses worth of space that isn't in the 2011 records. Part of this is address space returned to APNIC. In other cases, an address block delegated in a previous year expands or shrinks retroactively. Depending on what the underlying reason for these changes is, the actual rate at which APNIC and the other RIRs are giving out address space may be different from what it seems to be at first glance. ARIN, LACNIC, and the RIPE NCC used up 54.55, 17.29, and 75.45 million addresses, respectively, in 2010. However, ARIN saw 27.24 million addresses returned, including the 16.65 million from Interop, which is administered in the ARIN records even though the IANA list doesn't reflect this. For AfriNIC, LACNIC and the RIPE NCC the numbers of addresses that came back were 0.31, 0.22, and 22.62 million, respectively. With respect to running out of addresses, it's important to realize that the Pareto principle (the 80/20 rule) applies: out of the 7686 address blocks given out last year, only 392 (5 percent) were blocks larger than 100,000 addresses, but those were responsible for 82 percent of the address space given out. Even when the RIRs are no longer able to give out those large blocks, they may still be able to fulfill the requests for address blocks smaller than 10,000 addresses. Last year, 6425 such blocks were given out, totaling 14.03 million addresses. It really only takes a single address to be in the content business; it's the ISPs that need a continuous supply of new addresses to connect new customers. So the address shortages looming beyond the summer will hit ISPs and their broadband/mobile customers first and foremost, and the content industry to a much lesser degree. The top 15 IPv4 address holding countries: 2011-01-01 2010-01-01 Increase Country 1 - US 1519.53 M 1495.13 M 1.6% United States 2 - CN 277.64 M 232.45 M 19.4% China 3 - JP 186.82 M 177.15 M 5.5% Japan 4 - EU 151.80 M 149.48 M 1.6% Multi-country in Europe 5 (6) KR 103.50 M 77.77 M 33.1% Korea 6 (5) DE 91.61 M 86.51 M 5.9% Germany 7 (9) GB 82.25 M 74.18 M 10.9% United Kingdom 8 - CA 79.53 M 76.96 M 3.3% Canada 9 - FR 79.29 M 75.54 M 5.0% France 10 - AU 49.10 M 39.77 M 23.5% Australia 11 - BR 40.24 M 33.95 M 18.5% Brazil 12 - IT 37.14 M 33.50 M 10.9% Italy 13 - RU 34.66 M 28.47 M 21.7% Russia 14 - TW 31.93 M 27.10 M 17.8% Taiwan 15 (19) IN 28.70 M 19.42 M 47.8% India Because the US holds so much space, the increase of 25 million addresses seems small, but that's still more than 10% of the address space given out in 2010. China's growth is slowing down a little at 45 million addresses last year compared to 50 million in 2009. But other countries in Asia are picking up the slack and then some: Korea keeps using up large amounts of address space, and India is now also picking up the pace. The US now has 47.3% of the address space in use, down from 50.1% a year ago. The other countries in the top 15 collectively hold 39.7%, up from 38%. That leaves 13% for the rest of the world, up from 12%. Note that I slightly changed the way addresses are counted: previously, all the legacy blocks that didn't have an RIR listed were assumed to be used 100%. But with the return of most of the Interop block this is no longer the case: although ARIN isn't listed as administering the 45/8 block, they actually are and only have 45.0.0.0/15 listed as in use. From takashi at cpqd.com.br Tue Jan 4 05:34:53 2011 From: takashi at cpqd.com.br (Takashi Tome) Date: Tue, 4 Jan 2011 09:34:53 -0200 Subject: RES: Software For Telcos Message-ID: Hi Jacob, Generally, top telcos use software made by top telco's software vendors... of course :-) Say in other words, top telco's equipment vendors have their own sw team or third-party suppliers. Equipment vendors are Alcatel, Lucent (ex-AT&T), Ericsson, Nokia, etc. You can see at those companies' web site to check. Which kind of software: - system and service management; - CRM; - switching, IMS, etc; - billing; and so on. Hope it works. Takashi Tome takashi at cpqd.com.br www.cpqd.com.br -----Mensagem original----- De: jacob miller [mailto:mmzinyi at yahoo.com] Enviada em: ter?a-feira, 4 de janeiro de 2011 05:04 Para: nanog at nanog.org Assunto: Software For Telcos Hi, I have been wondering what type of Software do top telcos use. The tracking of Customer circuits to ensure that from marketing,sales,accounts and technical department everything to do with the circuits has to be tracked. Anyone with any help in regards to top software that can be used to run such a telco to ensure that world class service is obtained will be crucial. Regards, Jacob From carlosm3011 at gmail.com Tue Jan 4 06:26:49 2011 From: carlosm3011 at gmail.com (Carlos Martinez-Cagnazzo) Date: Tue, 4 Jan 2011 10:26:49 -0200 Subject: Software For Telcos In-Reply-To: <360440.86064.qm@web39502.mail.mud.yahoo.com> References: <360440.86064.qm@web39502.mail.mud.yahoo.com> Message-ID: What I've seen in my experience is mostly custom-developed software, sometimes developed in-house, sometimes outsourced and sometimes both. I don't know of many off-the-shelf packages out there. There are of course many "vertical" off-the-shelf apps. For example: billing systems, network management/monitoring systems, payroll systems, CRMs, etc. Many times there is a lot of work to be done in the area of system integration as there is a significant effort involved in getting these vertical systems talking to each other. cheers, Carlos On Tue, Jan 4, 2011 at 5:04 AM, jacob miller wrote: > Hi, > > I have been wondering what type of Software do top telcos use. > > The tracking of Customer circuits to ensure that from marketing,sales,accounts and technical department everything to do with the circuits has to be tracked. > > Anyone with any help in regards to top software that can be used to run such a telco to ensure that world class service is obtained will be crucial. > > Regards, > Jacob > > > > > > > > -- -- ========================= Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net ========================= From akmal_shahbaz at yahoo.com Tue Jan 4 06:38:19 2011 From: akmal_shahbaz at yahoo.com (Akmal Shahbaz) Date: Tue, 4 Jan 2011 04:38:19 -0800 (PST) Subject: How many legitimate cases when Origin AS in BGP announcement changed by another AS? In-Reply-To: Message-ID: <602626.85859.qm@web56003.mail.re3.yahoo.com> Hi I am looking for example routing policies when any AS receiving BGP advertisement changes Origin AS in BGP AS set attribute to remove the received AS number and puts its own AS number.[legitimate cases] 1. customer AS advertises the prefix however provider AS announce the aggregate(super prefix) shall put it's AS number in the BGP announcement.It may or may not suppress the customer BGP announcement based on multihoming.Well, we may say this is not a change in origin AS but new BGP announcement. 2.Can it happen in the case of private/public peering ? 3.ASes managed by same organization? 4.Are there cases it can be done for sub prefix or exact prefix announcement forwarding? Thank you. Akmal PhD Student MMLAB,SNU,Korea --- On Tue, 1/4/11, nanog-request at nanog.org wrote: From: nanog-request at nanog.org Subject: NANOG Digest, Vol 36, Issue 7 To: nanog at nanog.org Date: Tuesday, January 4, 2011, 12:00 PM Send NANOG mailing list submissions to ??? nanog at nanog.org To subscribe or unsubscribe via the World Wide Web, visit ??? https://mailman.nanog.org/mailman/listinfo/nanog or, via email, send a message with subject or body 'help' to ??? nanog-request at nanog.org You can reach the person managing the list at ??? nanog-owner at nanog.org When replying, please edit your Subject line so it is more specific than "Re: Contents of NANOG digest..." Today's Topics: ???1. Re: Router only speaks IGP in BGP network (Tarig Ahmed) ???2. Software For Telcos (jacob miller) ???3. 2010 IPv4 (and IPv6) Address Use Report (Iljitsch van Beijnum) ???4. RES: Software For Telcos (Takashi Tome) ---------------------------------------------------------------------- Message: 1 Date: Tue, 4 Jan 2011 09:00:27 +0300 From: Tarig Ahmed Subject: Re: Router only speaks IGP in BGP network To: Jeff Aitken Cc: nanog at nanog.org Message-ID: Content-Type: text/plain; charset="us-ascii"; format=flowed; delsp=yes On Jan 3, 2011, at 8:02 PM, Jeff Aitken wrote: > On Sat, Dec 25, 2010 at 08:52:42AM -0500, ML wrote: >> If you're only redistributing 10 prefixes into OSPF? Problem? > > I know I'm a little late to this thread, but figured I'd point out one > reason why this can be very dangerous: > > In IOS, you use a route-map to control redistribution between? > protocols. > For example, if you want to redist just those BGP prefixes tagged? > with a > specific community into OSPF, you will probably configure something? > that > looks like this: > >? ? route-map bgp-to-ospf permit 10 >? ???match community $COMMUNITY >? ? ! >? ? route-map bgp-to-ospf deny 20 >? ? ! >? ? router ospf $PID >? ???redistribute bgp $ASN subnets route-map bgp-to-ospf > > > Now, consider the following failure scenarios: > > 1. Someone typo's a BGP config elsewhere in your network and attaches > $COMMUNITY to a whole bunch more routes... say, all 350k being sent? > by your > upstream provider.? *oops* > > 2. An engineer thinks that there's something wrong with the? > redistribution > and decides to temporarily disable it as part of the troubleshooting > process.? He types the following: > >? ? conf t >? ? router ospf $PID >? ? no redistribute bgp $ASN subnets route-map bgp-to-ospf > > *boom* > > He just dumped all BGP routes into OSPF, due to the way IOS parses the > command: it removes the route-map but leaves the redistribution? > intact. > To be fair, Cisco does provide you with tools to mitigate this risk? > (see > the "redistribute maximum-prefix" command) but the point is that? > this is > a fairly easy mistake to make. > > At the end of the day, the reason that many folks advise against the > redistribution of BGP into an IGP is that it sets the stage for a? > seemingly > insignificant mistake to cause a not-so-insignificant outage. > > > --Jeff > > > This is an interesting point. But why cisco *no* command does not remove the redistribute , I think? it should do. Thanks ------------------------------ Message: 2 Date: Mon, 3 Jan 2011 23:04:14 -0800 (PST) From: jacob miller Subject: Software For Telcos To: nanog at nanog.org Message-ID: <360440.86064.qm at web39502.mail.mud.yahoo.com> Content-Type: text/plain; charset=us-ascii Hi, I have been wondering what type of Software do top telcos use. The tracking of Customer circuits to ensure that from marketing,sales,accounts and technical department everything to do with the circuits has to be tracked. Anyone with any help in regards to top software that can be used to run such a telco to ensure that world class service is obtained will be crucial. Regards, Jacob ? ? ? ------------------------------ Message: 3 Date: Tue, 4 Jan 2011 12:29:48 +0100 From: Iljitsch van Beijnum Subject: 2010 IPv4 (and IPv6) Address Use Report To: NANOG list Message-ID: <49A2BD30-5F17-40FA-A862-FF8C7496DAE0 at muada.com> Content-Type: text/plain; charset=us-ascii [ (Non-cross)posted to NANOG, PPML, RIPE IPv6 wg, Dutch IPv6 TF. ] On the web: IPv4: http://www.bgpexpert.com/addrspace2010.php IPv6: http://www.bgpexpert.com/addrspace-ipv6-2010.php The IPv4 one is included below: 2010 IPv4 Address Use Report As of January 1, 2011, the number of unused IPv4 addresses is 495.66 million. Exactly a year earlier, the number of available addresses was 721.06 million. So we collectively used up 225.4 million addresses in 2010. 35 of the 256 the /8s that make up the IPv4 address space have the status "reserved". 0 and 127 have special meaning and can't be used for normal purposes. 224 - 239 are used for multicast and 240 - 255 are "reserved for future use". With only about two years worth of IPv4 addresses remaining on the shelves, it would seem that that future is here now, but unfortunately, pretty much all operating systems balk at using a "reserved" address. So unreserving those addresses means upgrading EVERY system connected to the Internet. If we're going to do that, we may as well skip those reserved IPv4 addresses and upgrade to IPv6. Last but not least, there's block 10, which is the largest of the three address blocks set aside for private use. The others, 172.16.0.0/12 and 192.168.0.0/16, don't show up as reserved, but are obviously not available for regular use. This makes the total number of usable IPv4 addresses is (256 - 35) * 2^24 - 2^20 - 2^16 = 3706.65 million addresses. The "IANA global pool" consists of 7 /8s (117.44 million) are still unused (unallocated): 39/8, 102/8, 103/8, 104/8, 106/8, 179/8 and 185/8. But there's also a lot of unused space hiding in the "allocated" and "legacy" categories. Each RIR publishes a list of address blocks further delegated to ISPs or end users every day on their FTP servers. If we add up all those blocks, this comes out to 3210.99 million addresses. So the total number of usable-but-unused IPv4 addresses is 3706.65 - 3210.99 = 495.66 million. Going back to the IANA global pool, these are the changes over the past year: Delegated? ? Blocks? +/- 2010 to/status AfriNIC? ? ? ? ???3?????+1 APNIC? ? ? ? ? ? 42?????+8 ARIN? ? ? ? ? ???35?????+4 LACNIC? ? ? ? ? ? 8?????+2 RIPE NCC? ? ? ???34?????+4 LEGACY? ? ? ? ???92 UNALLOCATED? ? ???7??? -19 There is an agreement between IANA and the RIRs that each RIR will get one of the last five /8s. APNIC has been getting two /8s every three months like clockwork in 2010. If this continues, they'll be getting numbers 7 and 6 later this month, and then the final distribution will look like this: Delegated? ? Blocks? +/- 2010 to/status AfriNIC? ? ? ? ???4 APNIC? ? ? ? ? ? 45 ARIN? ? ? ? ? ???36 LACNIC? ? ? ? ? ? 9 RIPE NCC? ? ? ???35 LEGACY? ? ? ? ???92 UNALLOCATED? ? ???- At this point, it becomes very interesting what the status of the legacy space is, exactly. The legacy blocks are each "administered" by one of the RIRs, but does that mean that that RIR is free to further delegate that space to ISPs and end users? There are 146.92 million unused addresses in legacy space, including 16.65 million returned by Interop a few months ago. This is the used versus unused address space administered by each RIR: ? ? ? ? ? ? ? ? ? ? Legacy? ? ? ? ? Allocated ? ? ? ? ? ? ? ???total???unused? ???total???unused AfriNIC? ? ? ? ???33.55? ? 24.85? ???50.33? ? 27.06 APNIC? ? ? ? ? ? 100.66? ? 22.32? ? 704.64? ? 44.38 ARIN? ? ? ? ? ???654.31? ? 60.55? ? 587.20? ? 56.21 LACNIC? ? ? ? ? ? ? -? ? ? ? -? ? ? 134.22? ? 37.39 RIPE NCC? ? ? ? ? 67.11? ???5.77? ? 570.43? ? 67.38 IANA? ? ? ? ? ???671.09? ? 16.65? ? ???-? ? ? ? - AfriNIC used up 8.95 million addresses last year. So their current unused allocated space is good for another three years (if nothing changes) and their final /8 is worth another almost two years. If they get to use their legacy space, that buys them another 2.5 years. So unless IPv4 address use really takes off in Africa, AfriNIC will be handing out addresses for at least three or four years. APNIC is at the opposite end of the spectrum, using up no less than 126.22 million new IPv4 addresses last year. Even if they get to use the legacy space they administer on top of three of the last seven /8s and, it's hard to see how APNIC can avoid having to tell people "no" before the year is out. However, there is a caveat: in the 2010 APNIC records, there is 6.65 million addresses worth of space that isn't in the 2011 records. Part of this is address space returned to APNIC. In other cases, an address block delegated in a previous year expands or shrinks retroactively. Depending on what the underlying reason for these changes is, the actual rate at which APNIC and the other RIRs are giving out address space may be different from what it seems to be at first glance. ARIN, LACNIC, and the RIPE NCC used up 54.55, 17.29, and 75.45 million addresses, respectively, in 2010. However, ARIN saw 27.24 million addresses returned, including the 16.65 million from Interop, which is administered in the ARIN records even though the IANA list doesn't reflect this. For AfriNIC, LACNIC and the RIPE NCC the numbers of addresses that came back were 0.31, 0.22, and 22.62 million, respectively. With respect to running out of addresses, it's important to realize that the Pareto principle (the 80/20 rule) applies: out of the 7686 address blocks given out last year, only 392 (5 percent) were blocks larger than 100,000 addresses, but those were responsible for 82 percent of the address space given out. Even when the RIRs are no longer able to give out those large blocks, they may still be able to fulfill the requests for address blocks smaller than 10,000 addresses. Last year, 6425 such blocks were given out, totaling 14.03 million addresses. It really only takes a single address to be in the content business; it's the ISPs that need a continuous supply of new addresses to connect new customers. So the address shortages looming beyond the summer will hit ISPs and their broadband/mobile customers first and foremost, and the content industry to a much lesser degree. The top 15 IPv4 address holding countries: ? ? ? ? ? ? ? ? 2011-01-01???2010-01-01? ? Increase? Country 1? ???-? ???US? ? 1519.53 M? ? 1495.13 M? ? ???1.6%???United States 2? ???-? ???CN? ???277.64 M? ???232.45 M? ? ? 19.4%???China 3? ???-? ???JP? ???186.82 M? ???177.15 M? ? ???5.5%???Japan 4? ???-? ???EU? ???151.80 M? ???149.48 M? ? ???1.6%???Multi-country in Europe 5? ? (6)? ? KR? ???103.50 M? ? ? 77.77 M? ? ? 33.1%???Korea 6? ? (5)? ? DE? ? ? 91.61 M? ? ? 86.51 M? ? ???5.9%???Germany 7? ? (9)? ? GB? ? ? 82.25 M? ? ? 74.18 M? ? ? 10.9%???United Kingdom 8? ???-? ???CA? ? ? 79.53 M? ? ? 76.96 M? ? ???3.3%???Canada 9? ???-? ???FR? ? ? 79.29 M? ? ? 75.54 M? ? ???5.0%???France? ? ? 10? ? -? ???AU? ? ? 49.10 M? ? ? 39.77 M? ? ? 23.5%???Australia 11? ? -? ???BR? ? ? 40.24 M? ? ? 33.95 M? ? ? 18.5%???Brazil 12? ? -? ???IT? ? ? 37.14 M? ? ? 33.50 M? ? ? 10.9%???Italy 13? ? -? ???RU? ? ? 34.66 M? ? ? 28.47 M? ? ? 21.7%???Russia 14? ? -? ???TW? ? ? 31.93 M? ? ? 27.10 M? ? ? 17.8%???Taiwan 15???(19)???IN? ? ? 28.70 M? ? ? 19.42 M? ? ? 47.8%???India Because the US holds so much space, the increase of 25 million addresses seems small, but that's still more than 10% of the address space given out in 2010. China's growth is slowing down a little at 45 million addresses last year compared to 50 million in 2009. But other countries in Asia are picking up the slack and then some: Korea keeps using up large amounts of address space, and India is now also picking up the pace. The US now has 47.3% of the address space in use, down from 50.1% a year ago. The other countries in the top 15 collectively hold 39.7%, up from 38%. That leaves 13% for the rest of the world, up from 12%. Note that I slightly changed the way addresses are counted: previously, all the legacy blocks that didn't have an RIR listed were assumed to be used 100%. But with the return of most of the Interop block this is no longer the case: although ARIN isn't listed as administering the 45/8 block, they actually are and only have 45.0.0.0/15 listed as in use. ------------------------------ Message: 4 Date: Tue, 4 Jan 2011 09:34:53 -0200 From: "Takashi Tome" Subject: RES: Software For Telcos To: Message-ID: ??? Content-Type: text/plain;??? charset="iso-8859-1" Hi Jacob, Generally, top telcos use software made by top telco's software vendors... of course? :-) Say in other words, top telco's equipment vendors have their own sw team or third-party suppliers. Equipment vendors are Alcatel, Lucent (ex-AT&T), Ericsson, Nokia, etc. You can see at those companies' web site to check. Which kind of software: - system and service management; - CRM; - switching, IMS, etc; - billing; and so on. Hope it works. Takashi Tome takashi at cpqd.com.br www.cpqd.com.br -----Mensagem original----- De: jacob miller [mailto:mmzinyi at yahoo.com] Enviada em: ter?a-feira, 4 de janeiro de 2011 05:04 Para: nanog at nanog.org Assunto: Software For Telcos Hi, I have been wondering what type of Software do top telcos use. The tracking of Customer circuits to ensure that from marketing,sales,accounts and technical department everything to do with the circuits has to be tracked. Anyone with any help in regards to top software that can be used to run such a telco to ensure that world class service is obtained will be crucial. Regards, Jacob ? ? ? ------------------------------ _______________________________________________ NANOG mailing list NANOG at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog End of NANOG Digest, Vol 36, Issue 7 ************************************ From randy at psg.com Tue Jan 4 07:48:53 2011 From: randy at psg.com (Randy Bush) Date: Tue, 04 Jan 2011 22:48:53 +0900 Subject: RES: Software For Telcos In-Reply-To: References: Message-ID: > Generally, top telcos use software made by top telco's software > vendors... of course :-) in my miniscule experience, they have large masses of engineers with unrequited NIH and roll their own as much as possible. after all, who could make something suitable for their oh so special needs. randy From takashi at cpqd.com.br Tue Jan 4 08:04:51 2011 From: takashi at cpqd.com.br (Takashi Tome) Date: Tue, 4 Jan 2011 12:04:51 -0200 Subject: RES: RES: Software For Telcos Message-ID: HAHA! Good joke! That was true some 30 years ago... Actually, I think the problem is quite different. Big telco's network is a very complex thing - well, you all can say, Internet is too... But if we see some "similar" business like aircraft-defense and professional video market, we see some similarities: there are a lot of tricks and "non-documented standards" that make those software a kind of mistery for foreigners. Put in other words, software knowledge is not enough, you must have a deep understanding of that business and the history of the system itself... Takashi -----Mensagem original----- De: Randy Bush [mailto:randy at psg.com] Enviada em: ter?a-feira, 4 de janeiro de 2011 11:49 Para: Takashi Tome Cc: NANOG Operators' Group Assunto: Re: RES: Software For Telcos > Generally, top telcos use software made by top telco's software > vendors... of course :-) in my miniscule experience, they have large masses of engineers with unrequited NIH and roll their own as much as possible. after all, who could make something suitable for their oh so special needs. randy From tariq198487 at hotmail.com Tue Jan 4 08:09:08 2011 From: tariq198487 at hotmail.com (Tarig Ahmed) Date: Tue, 4 Jan 2011 06:09:08 -0800 Subject: How many legitimate cases when Origin AS in BGP announcement changed by another AS? In-Reply-To: <602626.85859.qm@web56003.mail.re3.yahoo.com> References: <602626.85859.qm@web56003.mail.re3.yahoo.com> Message-ID: Hi Last week I faced a case like this in an african NREN. This NREN provides Internet and Academic traffic to thier members, but there are some members leases a layer 3 VPN from local ISP in order to get to thier NREN POPs. Engineers of this NREN desided for some reseans to use eBGP from thier POPs to this VPN, and to use OSPF from the VPN to thier members (member routers do not support BGP). In this case the route will originate form the ISP which not actually posses those prefixes. No upstream will accept this unless the NREN removes the local ISP ASN and announce new fresh routes, and this which actually happened with aggregate and suppress-map cisco commands. I hope this a legitmate case. Thanks Tarig Yassin Ahmed On Jan 4, 2011, at 4:38 AM, Akmal Shahbaz wrote: > Hi > > I am looking for example routing policies when any AS receiving BGP > advertisement changes Origin AS in BGP AS set attribute to remove > the received AS number and puts its own AS number.[legitimate cases] > > 1. customer AS advertises the prefix however provider AS announce > the aggregate(super prefix) shall put it's AS number in the BGP announcement.It > may or may not suppress the customer BGP announcement based on > multihoming.Well, we may say this is not a change in origin AS but > new BGP announcement. > > 2.Can it happen in the case of private/public peering ? > > 3.ASes managed by same organization? > > 4.Are there cases it can be done for sub prefix or exact prefix > announcement forwarding? > > > Thank you. > > Akmal > PhD Student > MMLAB,SNU,Korea > > > --- On Tue, 1/4/11, nanog-request at nanog.org request at nanog.org> wrote: > > From: nanog-request at nanog.org > Subject: NANOG Digest, Vol 36, Issue 7 > To: nanog at nanog.org > Date: Tuesday, January 4, 2011, 12:00 PM > > Send NANOG mailing list submissions to > nanog at nanog.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mailman.nanog.org/mailman/listinfo/nanog > or, via email, send a message with subject or body 'help' to > nanog-request at nanog.org > > You can reach the person managing the list at > nanog-owner at nanog.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of NANOG digest..." > > > Today's Topics: > > 1. Re: Router only speaks IGP in BGP network (Tarig Ahmed) > 2. Software For Telcos (jacob miller) > 3. 2010 IPv4 (and IPv6) Address Use Report (Iljitsch van Beijnum) > 4. RES: Software For Telcos (Takashi Tome) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 4 Jan 2011 09:00:27 +0300 > From: Tarig Ahmed > Subject: Re: Router only speaks IGP in BGP network > To: Jeff Aitken > Cc: nanog at nanog.org > Message-ID: > Content-Type: text/plain; charset="us-ascii"; format=flowed; delsp=yes > > > > > On Jan 3, 2011, at 8:02 PM, Jeff Aitken wrote: > >> On Sat, Dec 25, 2010 at 08:52:42AM -0500, ML wrote: >>> If you're only redistributing 10 prefixes into OSPF? Problem? >> >> I know I'm a little late to this thread, but figured I'd point out >> one >> reason why this can be very dangerous: >> >> In IOS, you use a route-map to control redistribution between >> protocols. >> For example, if you want to redist just those BGP prefixes tagged >> with a >> specific community into OSPF, you will probably configure something >> that >> looks like this: >> >> route-map bgp-to-ospf permit 10 >> match community $COMMUNITY >> ! >> route-map bgp-to-ospf deny 20 >> ! >> router ospf $PID >> redistribute bgp $ASN subnets route-map bgp-to-ospf >> >> >> Now, consider the following failure scenarios: >> >> 1. Someone typo's a BGP config elsewhere in your network and attaches >> $COMMUNITY to a whole bunch more routes... say, all 350k being sent >> by your >> upstream provider. *oops* >> >> 2. An engineer thinks that there's something wrong with the >> redistribution >> and decides to temporarily disable it as part of the troubleshooting >> process. He types the following: >> >> conf t >> router ospf $PID >> no redistribute bgp $ASN subnets route-map bgp-to-ospf >> >> *boom* >> >> He just dumped all BGP routes into OSPF, due to the way IOS parses >> the >> command: it removes the route-map but leaves the redistribution >> intact. >> To be fair, Cisco does provide you with tools to mitigate this risk >> (see >> the "redistribute maximum-prefix" command) but the point is that >> this is >> a fairly easy mistake to make. >> >> At the end of the day, the reason that many folks advise against the >> redistribution of BGP into an IGP is that it sets the stage for a >> seemingly >> insignificant mistake to cause a not-so-insignificant outage. >> >> >> --Jeff >> >> >> > > This is an interesting point. > But why cisco *no* command does not remove the redistribute , I think > it should do. > > Thanks > > > > ------------------------------ > > Message: 2 > Date: Mon, 3 Jan 2011 23:04:14 -0800 (PST) > From: jacob miller > Subject: Software For Telcos > To: nanog at nanog.org > Message-ID: <360440.86064.qm at web39502.mail.mud.yahoo.com> > Content-Type: text/plain; charset=us-ascii > > Hi, > > I have been wondering what type of Software do top telcos use. > > The tracking of Customer circuits to ensure that from > marketing,sales,accounts and technical department everything to do > with the circuits has to be tracked. > > Anyone with any help in regards to top software that can be used to > run such a telco to ensure that world class service is obtained will > be crucial. > > Regards, > Jacob > > > > > > > > > > ------------------------------ > > Message: 3 > Date: Tue, 4 Jan 2011 12:29:48 +0100 > From: Iljitsch van Beijnum > Subject: 2010 IPv4 (and IPv6) Address Use Report > To: NANOG list > Message-ID: <49A2BD30-5F17-40FA-A862-FF8C7496DAE0 at muada.com> > Content-Type: text/plain; charset=us-ascii > > [ (Non-cross)posted to NANOG, PPML, RIPE IPv6 wg, Dutch IPv6 TF. ] > > On the web: > > IPv4: http://www.bgpexpert.com/addrspace2010.php > IPv6: http://www.bgpexpert.com/addrspace-ipv6-2010.php > > The IPv4 one is included below: > > > 2010 IPv4 Address Use Report > > As of January 1, 2011, the number of unused IPv4 addresses is 495.66 > million. Exactly a year earlier, the number of available addresses > was 721.06 million. So we collectively used up 225.4 million > addresses in 2010. > > 35 of the 256 the /8s that make up the IPv4 address space have the > status "reserved". 0 and 127 have special meaning and can't be used > for normal purposes. 224 - 239 are used for multicast and 240 - 255 > are "reserved for future use". With only about two years worth of > IPv4 addresses remaining on the shelves, it would seem that that > future is here now, but unfortunately, pretty much all operating > systems balk at using a "reserved" address. So unreserving those > addresses means upgrading EVERY system connected to the Internet. If > we're going to do that, we may as well skip those reserved IPv4 > addresses and upgrade to IPv6. Last but not least, there's block 10, > which is the largest of the three address blocks set aside for > private use. The others, 172.16.0.0/12 and 192.168.0.0/16, don't > show up as reserved, but are obviously not available for regular use. > > This makes the total number of usable IPv4 addresses is (256 - 35) * > 2^24 - 2^20 - 2^16 = 3706.65 million addresses. The "IANA global > pool" consists of 7 /8s (117.44 million) are still unused > (unallocated): 39/8, 102/8, 103/8, 104/8, 106/8, 179/8 and 185/8. > But there's also a lot of unused space hiding in the "allocated" and > "legacy" categories. Each RIR publishes a list of address blocks > further delegated to ISPs or end users every day on their FTP > servers. If we add up all those blocks, this comes out to 3210.99 > million addresses. So the total number of usable-but-unused IPv4 > addresses is 3706.65 - 3210.99 = 495.66 million. > > Going back to the IANA global pool, these are the changes over the > past year: > > Delegated Blocks +/- 2010 > to/status > > AfriNIC 3 +1 > APNIC 42 +8 > ARIN 35 +4 > LACNIC 8 +2 > RIPE NCC 34 +4 > LEGACY 92 > UNALLOCATED 7 -19 > > There is an agreement between IANA and the RIRs that each RIR will > get one of the last five /8s. APNIC has been getting two /8s every > three months like clockwork in 2010. If this continues, they'll be > getting numbers 7 and 6 later this month, and then the final > distribution will look like this: > > Delegated Blocks +/- 2010 > to/status > > AfriNIC 4 > APNIC 45 > ARIN 36 > LACNIC 9 > RIPE NCC 35 > LEGACY 92 > UNALLOCATED - > > At this point, it becomes very interesting what the status of the > legacy space is, exactly. The legacy blocks are each "administered" > by one of the RIRs, but does that mean that that RIR is free to > further delegate that space to ISPs and end users? There are 146.92 > million unused addresses in legacy space, including 16.65 million > returned by Interop a few months ago. This is the used versus unused > address space administered by each RIR: > > Legacy Allocated > total unused total unused > AfriNIC 33.55 24.85 50.33 27.06 > APNIC 100.66 22.32 704.64 44.38 > ARIN 654.31 60.55 587.20 56.21 > LACNIC - - 134.22 37.39 > RIPE NCC 67.11 5.77 570.43 67.38 > IANA 671.09 16.65 - - > > AfriNIC used up 8.95 million addresses last year. So their current > unused allocated space is good for another three years (if nothing > changes) and their final /8 is worth another almost two years. If > they get to use their legacy space, that buys them another 2.5 > years. So unless IPv4 address use really takes off in > Africa, AfriNIC will be handing out addresses for at least three or > four years. > > APNIC is at the opposite end of the spectrum, using up no less than > 126.22 million new IPv4 addresses last year. Even if they get to use > the legacy space they administer on top of three of the last seven / > 8s and, it's hard to see how APNIC can avoid having to tell people > "no" before the year is out. However, there is a caveat: in the 2010 > APNIC records, there is 6.65 million addresses worth of space that > isn't in the 2011 records. Part of this is address space returned to > APNIC. In other cases, an address block delegated in a previous year > expands or shrinks retroactively. Depending on what the underlying > reason for these changes is, the actual rate at which APNIC and the > other RIRs are giving out address space may be different from what > it seems to be at first glance. > > ARIN, LACNIC, and the RIPE NCC used up 54.55, 17.29, and 75.45 > million addresses, respectively, in 2010. However, ARIN saw 27.24 > million addresses returned, including the 16.65 million from > Interop, which is administered in the ARIN records even though the > IANA list doesn't reflect this. For AfriNIC, LACNIC and the RIPE NCC > the numbers of addresses that came back were 0.31, 0.22, and 22.62 > million, respectively. > > With respect to running out of addresses, it's important to realize > that the Pareto principle (the 80/20 rule) applies: out of the 7686 > address blocks given out last year, only 392 (5 percent) were blocks > larger than 100,000 addresses, but those were responsible for 82 > percent of the address space given out. Even when the RIRs > are no longer able to give out those large blocks, they may still be > able to fulfill the requests for address blocks smaller than 10,000 > addresses. Last year, 6425 such blocks were given out, totaling > 14.03 million addresses. It really only takes a single address to be > in the content business; it's the ISPs that need a continuous supply > of new addresses to connect new customers. So the address shortages > looming beyond the summer will hit ISPs and their broadband/mobile > customers first and foremost, and the content industry to a much > lesser degree. > > The top 15 IPv4 address holding countries: > > 2011-01-01 2010-01-01 Increase Country > > 1 - US 1519.53 M 1495.13 M 1.6% United States > 2 - CN 277.64 M 232.45 M 19.4% China > 3 - JP 186.82 M 177.15 M 5.5% Japan > 4 - EU 151.80 M 149.48 M 1.6% Multi-country > in Europe > 5 (6) KR 103.50 M 77.77 M 33.1% Korea > 6 (5) DE 91.61 M 86.51 M 5.9% Germany > 7 (9) GB 82.25 M 74.18 M 10.9% United Kingdom > 8 - CA 79.53 M 76.96 M 3.3% Canada > 9 - FR 79.29 M 75.54 M 5.0% France > 10 - AU 49.10 M 39.77 M 23.5% Australia > 11 - BR 40.24 M 33.95 M 18.5% Brazil > 12 - IT 37.14 M 33.50 M 10.9% Italy > 13 - RU 34.66 M 28.47 M 21.7% Russia > 14 - TW 31.93 M 27.10 M 17.8% Taiwan > 15 (19) IN 28.70 M 19.42 M 47.8% India > > Because the US holds so much space, the increase of 25 million > addresses seems small, but that's still more than 10% of the address > space given out in 2010. China's growth is slowing down a little at > 45 million addresses last year compared to 50 million in 2009. But > other countries in Asia are picking up the slack and then some: > Korea keeps using up large amounts of address space, and India is > now also picking up the pace. The US now has 47.3% of the address > space in use, down from 50.1% a year ago. The other countries in the > top 15 collectively hold 39.7%, up from 38%. That leaves 13% for the > rest of the world, up from 12%. > > Note that I slightly changed the way addresses are counted: > previously, all the legacy blocks that didn't have an RIR listed > were assumed to be used 100%. But with the return of most of the > Interop block this is no longer the case: although ARIN isn't listed > as administering the 45/8 block, they actually are and only have 45.0.0.0/15 > listed as in use. > > > ------------------------------ > > Message: 4 > Date: Tue, 4 Jan 2011 09:34:53 -0200 > From: "Takashi Tome" > Subject: RES: Software For Telcos > To: > Message-ID: > > > Content-Type: text/plain; charset="iso-8859-1" > > Hi Jacob, > > Generally, top telcos use software made by top telco's software > vendors... of course :-) > > Say in other words, top telco's equipment vendors have their own sw > team or third-party suppliers. Equipment vendors are Alcatel, Lucent > (ex-AT&T), Ericsson, Nokia, etc. You can see at those companies' web > site to check. > > Which kind of software: > - system and service management; > - CRM; > - switching, IMS, etc; > - billing; > and so on. > > Hope it works. > > Takashi Tome > takashi at cpqd.com.br > www.cpqd.com.br > > > -----Mensagem original----- > De: jacob miller [mailto:mmzinyi at yahoo.com] > Enviada em: ter?a-feira, 4 de janeiro de 2011 05:04 > Para: nanog at nanog.org > Assunto: Software For Telcos > > > Hi, > > I have been wondering what type of Software do top telcos use. > > The tracking of Customer circuits to ensure that from > marketing,sales,accounts and technical department everything to do > with the circuits has to be tracked. > > Anyone with any help in regards to top software that can be used to > run such a telco to ensure that world class service is obtained will > be crucial. > > Regards, > Jacob > > > > > > > > > > > ------------------------------ > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > https://mailman.nanog.org/mailman/listinfo/nanog > > End of NANOG Digest, Vol 36, Issue 7 > ************************************ > > > > > From geoincidents at nls.net Tue Jan 4 08:59:59 2011 From: geoincidents at nls.net (Geo.) Date: Tue, 4 Jan 2011 09:59:59 -0500 Subject: contact request In-Reply-To: Message-ID: Does anyone have a contact for ATT Network operations that handles or can help with the Cleveland Ohio area ATT network? George Roettger Netlink Services From daryl at introspect.net Tue Jan 4 09:04:19 2011 From: daryl at introspect.net (Daryl G. Jurbala) Date: Tue, 4 Jan 2011 10:04:19 -0500 Subject: RES: RES: Software For Telcos In-Reply-To: References: Message-ID: <9BE8304B-C0DF-4C6A-95E0-049C5272D0A8@introspect.net> On Jan 4, 2011, at 9:04 AM, Takashi Tome wrote: [snip] > Put in other words, software knowledge is not enough, you must have a deep understanding of that business and the history of the system itself... [snip] This is the case 100% of the time, regardless of how many "top" developers/coders think otherwise. Regardless of market segment. The last "top telco" I dealt with enough to get a feeling for their systems was using PeopleSoft and a gaggle of the things that come along with it: $200/hr PeopleSoft consultants. They also had a walled off fiefdom in engineering that no one else could touch except for maybe a few select people in the NOC using Rational Rose which contained all of the engineering docs and much of the information the NOC really needed to troubleshoot anything of substance (I'm remembering an incident where I had a circuit down from them with no light on my end, yet the NOC kept arguing that they had a link on their end......turned out they were looking at their copper port and didn't realize it went through some other box, which has completely unmonitored ports, to turn it into single mode fiber to send across the city to me and only engineering had the documentation to show this). I'm not saying that I'd be the right person to even make the initial design document for a large telco management system, but I can tell you that once you've seen how it's currently being done you'll realize that many of them don't appear to have the right person either. Just in my small (meaning millions of minutes a day, not 10s of millions) voip business, we've not been able to find much off the shelf software at any price that would help with much of anything short of your standard generic business type apps. We're using a combination of open source packages, some lightly modified, and some internally developed software. Its not optimal, and I think it would break at even 5x our current head count, but there isn't enough of a business case to go to some roll-your-own-with-consultants-base-app like PeopleSoft or SAP. From william.allen.simpson at gmail.com Tue Jan 4 09:10:24 2011 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Tue, 04 Jan 2011 10:10:24 -0500 Subject: sudden low spam levels? In-Reply-To: References: <20110103180455.GS12141@sizone.org> <4D225D53.9020805@elcsplace.com> Message-ID: <4D233860.1050305@gmail.com> On 1/3/11 6:42 PM, Jay Farrell wrote: > I noticed a substantial drop in spam in my gmail account in recent days, > from several hundred a day to maybe a hundred. Ironically, gmail filtered > this thread to my spam folder. > Yes, I found these messages my gmail spam today, too. Lately, gmail has been regularly flagging NANOG as spam, particularly the end of week CIDR and BGP reports. From Valdis.Kletnieks at vt.edu Tue Jan 4 09:17:44 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 04 Jan 2011 10:17:44 -0500 Subject: Software For Telcos In-Reply-To: Your message of "Mon, 03 Jan 2011 23:04:14 PST." <360440.86064.qm@web39502.mail.mud.yahoo.com> References: <360440.86064.qm@web39502.mail.mud.yahoo.com> Message-ID: <6016.1294154264@localhost> On Mon, 03 Jan 2011 23:04:14 PST, jacob miller said: > The tracking of Customer circuits to ensure that from marketing, sales, > accounts and technical department everything to do with the circuits has to be > tracked. Reading the NANOG archives will find enough examples of top telcos that *never* managed to correctly bill for a T-1 that it's safe to assume that quite often, such tracking does not, in fact, actually happen. > Anyone with any help in regards to top software that can be used to run such > a telco to ensure that world class service is obtained will be crucial. World class service? Usually provided by the non-top telcos, and used as a marketing feature. World class service doesn't come from software, it comes from corporate culture. Software doesn't make you hold your customers hostage in a peering dispute, management decisions do that. And most customers don't think being held hostage is world class service - and only top telcos have enough customers to make a peering displute feasible. (Long-time readers can probably think of enough examples to run out of examples to count on the fingers of one hand, even in base 3 ;) And at one time, there were plenty of small companies that made their living based on providing world-class service. You wanted some special one-off setup? No problem, their CFO and CTO would drive over and discuss pricing and terms - which usually included "and if it crashes at 2AM, call me on my cell". You wanted to discuss a config change on 10 minutes notice at 11PM on a Friday, no problem. (What ever happened to those companies, anyhow?) Hypothesis: The actual quality of service delivered is inversely proportional to the ability of the provider to deploy off-the-shelf enterprise-class software. If you can afford it, but your service is still generic enough to use COTS software, you're not delivering world-class service. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From cat at reptiles.org Tue Jan 4 10:03:22 2011 From: cat at reptiles.org (Cat Okita) Date: Tue, 4 Jan 2011 11:03:22 -0500 (EST) Subject: RES: RES: Software For Telcos In-Reply-To: References: Message-ID: On Tue, 4 Jan 2011, Takashi Tome wrote: > That was true some 30 years ago... That's still true today. There's an insane amount of in-house stuff still kicking around, for various reasons, some reasonable, some not so much. > Actually, I think the problem is quite different. Big telco's network is > a very complex thing - well, you all can say, Internet is too... > But if we see some "similar" business like aircraft-defense and > professional video market, we see some similarities: there are a lot > of tricks and "non-documented standards" that make those software a kind > of mistery for foreigners. Put in other words, software knowledge is > not enough, you must have a deep understanding of that business and the > history of the system itself... I believe that would be the intersection of COTS and NIH ... "Yup, we're using $SOFTWARE, but we have a few in-house customizations..." cheers! ========================================================================== "A cat spends her life conflicted between a deep, passionate and profound desire for fish and an equally deep, passionate and profound desire to avoid getting wet. This is the defining metaphor of my life right now." From bortzmeyer at nic.fr Tue Jan 4 10:05:10 2011 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 4 Jan 2011 17:05:10 +0100 Subject: How many legitimate cases when Origin AS in BGP announcement changed by another AS? In-Reply-To: <602626.85859.qm@web56003.mail.re3.yahoo.com> References: <602626.85859.qm@web56003.mail.re3.yahoo.com> Message-ID: <20110104160510.GA936@nic.fr> On Tue, Jan 04, 2011 at 04:38:19AM -0800, Akmal Shahbaz wrote a message of 443 lines which said: > I am looking for example routing policies when any AS receiving BGP > advertisement changes Origin AS in BGP AS set attribute to remove > the received AS number and puts its own AS number.[legitimate cases] When the old origin AS was a private one? Today, with 32bits AS, everyone should have a public AS number but, in the real world, some people do BGP with private AS that the upstream provider has to change. From akmal_shahbaz at yahoo.com Tue Jan 4 10:22:35 2011 From: akmal_shahbaz at yahoo.com (Akmal Shahbaz) Date: Tue, 4 Jan 2011 08:22:35 -0800 (PST) Subject: How many legitimate cases when Origin AS in BGP announcement changed by another AS? In-Reply-To: <20110104160510.GA936@nic.fr> Message-ID: <781056.91735.qm@web56007.mail.re3.yahoo.com> >>When the old origin AS was a private one? NO.Even when old origin AS is not private one. Don't you think private/pubic AS won't matter in case of provider aggregation? Thanks Akmal --- On Tue, 1/4/11, Stephane Bortzmeyer wrote: From: Stephane Bortzmeyer Subject: Re: How many legitimate cases when Origin AS in BGP announcement changed by another AS? To: "Akmal Shahbaz" Cc: nanog at nanog.org Date: Tuesday, January 4, 2011, 4:05 PM On Tue, Jan 04, 2011 at 04:38:19AM -0800, Akmal Shahbaz wrote a message of 443 lines which said: > I am looking for example routing policies when any AS receiving BGP > advertisement changes Origin AS in BGP AS set attribute to remove > the received AS number and puts its own AS number.[legitimate cases] When the old origin AS was a private one? Today, with 32bits AS, everyone should have a public AS number but, in the real world, some people do BGP with private AS that the upstream provider has to change. From bortzmeyer at nic.fr Tue Jan 4 10:27:39 2011 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 4 Jan 2011 17:27:39 +0100 Subject: How many legitimate cases when Origin AS in BGP announcement changed by another AS? In-Reply-To: <781056.91735.qm@web56007.mail.re3.yahoo.com> References: <20110104160510.GA936@nic.fr> <781056.91735.qm@web56007.mail.re3.yahoo.com> Message-ID: <20110104162739.GA3745@nic.fr> On Tue, Jan 04, 2011 at 08:22:35AM -0800, Akmal Shahbaz wrote a message of 44 lines which said: > >>When the old origin AS was a private one? > NO.Even when old origin AS is not private one. You misunderstood me. I replied to your query "When is it legitimate to change an origin AS?" by adding a possibility you did not mention: "When the origin AS is a private one". From richard.barnes at gmail.com Tue Jan 4 10:30:43 2011 From: richard.barnes at gmail.com (Richard Barnes) Date: Tue, 4 Jan 2011 11:30:43 -0500 Subject: 2010 IPv4 (and IPv6) Address Use Report In-Reply-To: <49A2BD30-5F17-40FA-A862-FF8C7496DAE0@muada.com> References: <49A2BD30-5F17-40FA-A862-FF8C7496DAE0@muada.com> Message-ID: Also, for a slightly more average-person-friendly view, see Iljitsch's article in Ars Technica: On Tue, Jan 4, 2011 at 6:29 AM, Iljitsch van Beijnum wrote: > [ (Non-cross)posted to NANOG, PPML, RIPE IPv6 wg, Dutch IPv6 TF. ] > > On the web: > > IPv4: http://www.bgpexpert.com/addrspace2010.php > IPv6: http://www.bgpexpert.com/addrspace-ipv6-2010.php > > The IPv4 one is included below: > > > 2010 IPv4 Address Use Report > > As of January 1, 2011, the number of unused IPv4 addresses is 495.66 million. Exactly a year earlier, the number of available addresses was 721.06 million. So we collectively used up 225.4 million addresses in 2010. > > 35 of the 256 the /8s that make up the IPv4 address space have the status "reserved". 0 and 127 have special meaning and can't be used for normal purposes. 224 - 239 are used for multicast and 240 - 255 are "reserved for future use". With only about two years worth of IPv4 addresses remaining on the shelves, it would seem that that future is here now, but unfortunately, pretty much all operating systems balk at using a "reserved" address. So unreserving those addresses means upgrading EVERY system connected to the Internet. If we're going to do that, we may as well skip those reserved IPv4 addresses and upgrade to IPv6. Last but not least, there's block 10, which is the largest of the three address blocks set aside for private use. The others, 172.16.0.0/12 and 192.168.0.0/16, don't show up as reserved, but are obviously not available for regular use. > > This makes the total number of usable IPv4 addresses is (256 - 35) * 2^24 - 2^20 - 2^16 = 3706.65 million addresses. The "IANA global pool" consists of 7 /8s (117.44 million) are still unused (unallocated): 39/8, 102/8, 103/8, 104/8, 106/8, 179/8 and 185/8. But there's also a lot of unused space hiding in the "allocated" and "legacy" categories. Each RIR publishes a list of address blocks further delegated to ISPs or end users every day on their FTP servers. If we add up all those blocks, this comes out to 3210.99 million addresses. So the total number of usable-but-unused IPv4 addresses is 3706.65 - 3210.99 = 495.66 million. > > Going back to the IANA global pool, these are the changes over the past year: > > Delegated ? ?Blocks ?+/- 2010 > to/status > > AfriNIC ? ? ? ? ? 3 ? ? ?+1 > APNIC ? ? ? ? ? ?42 ? ? ?+8 > ARIN ? ? ? ? ? ? 35 ? ? ?+4 > LACNIC ? ? ? ? ? ?8 ? ? ?+2 > RIPE NCC ? ? ? ? 34 ? ? ?+4 > LEGACY ? ? ? ? ? 92 > UNALLOCATED ? ? ? 7 ? ? -19 > > There is an agreement between IANA and the RIRs that each RIR will get one of the last five /8s. APNIC has been getting two /8s every three months like clockwork in 2010. If this continues, they'll be getting numbers 7 and 6 later this month, and then the final distribution will look like this: > > Delegated ? ?Blocks ?+/- 2010 > to/status > > AfriNIC ? ? ? ? ? 4 > APNIC ? ? ? ? ? ?45 > ARIN ? ? ? ? ? ? 36 > LACNIC ? ? ? ? ? ?9 > RIPE NCC ? ? ? ? 35 > LEGACY ? ? ? ? ? 92 > UNALLOCATED ? ? ? - > > At this point, it becomes very interesting what the status of the legacy space is, exactly. The legacy blocks are each "administered" by one of the RIRs, but does that mean that that RIR is free to further delegate that space to ISPs and end users? There are 146.92 million unused addresses in legacy space, including 16.65 million returned by Interop a few months ago. This is the used versus unused address space administered by each RIR: > > ? ? ? ? ? ? ? ? ? ?Legacy ? ? ? ? ?Allocated > ? ? ? ? ? ? ? ? total ? unused ? ? total ? unused > AfriNIC ? ? ? ? ? 33.55 ? ?24.85 ? ? 50.33 ? ?27.06 > APNIC ? ? ? ? ? ?100.66 ? ?22.32 ? ?704.64 ? ?44.38 > ARIN ? ? ? ? ? ? 654.31 ? ?60.55 ? ?587.20 ? ?56.21 > LACNIC ? ? ? ? ? ? ?- ? ? ? ?- ? ? ?134.22 ? ?37.39 > RIPE NCC ? ? ? ? ?67.11 ? ? 5.77 ? ?570.43 ? ?67.38 > IANA ? ? ? ? ? ? 671.09 ? ?16.65 ? ? ? - ? ? ? ?- > > AfriNIC used up 8.95 million addresses last year. So their current unused allocated space is good for another three years (if nothing changes) and their final /8 is worth another almost two years. If they get to use their legacy space, that buys them another 2.5 years. So unless IPv4 address use really takes off in Africa, AfriNIC will be handing out addresses for at least three or four years. > > APNIC is at the opposite end of the spectrum, using up no less than 126.22 million new IPv4 addresses last year. Even if they get to use the legacy space they administer on top of three of the last seven /8s and, it's hard to see how APNIC can avoid having to tell people "no" before the year is out. However, there is a caveat: in the 2010 APNIC records, there is 6.65 million addresses worth of space that isn't in the 2011 records. Part of this is address space returned to APNIC. In other cases, an address block delegated in a previous year expands or shrinks retroactively. Depending on what the underlying reason for these changes is, the actual rate at which APNIC and the other RIRs are giving out address space may be different from what it seems to be at first glance. > > ARIN, LACNIC, and the RIPE NCC used up 54.55, 17.29, and 75.45 million addresses, respectively, in 2010. However, ARIN saw 27.24 million addresses returned, including the 16.65 million from Interop, which is administered in the ARIN records even though the IANA list doesn't reflect this. For AfriNIC, LACNIC and the RIPE NCC the numbers of addresses that came back were 0.31, 0.22, and 22.62 million, respectively. > > With respect to running out of addresses, it's important to realize that the Pareto principle (the 80/20 rule) applies: out of the 7686 address blocks given out last year, only 392 (5 percent) were blocks larger than 100,000 addresses, but those were responsible for 82 percent of the address space given out. Even when the RIRs are no longer able to give out those large blocks, they may still be able to fulfill the requests for address blocks smaller than 10,000 addresses. Last year, 6425 such blocks were given out, totaling 14.03 million addresses. It really only takes a single address to be in the content business; it's the ISPs that need a continuous supply of new addresses to connect new customers. So the address shortages looming beyond the summer will hit ISPs and their broadband/mobile customers first and foremost, and the content industry to a much lesser degree. > > The top 15 IPv4 address holding countries: > > ? ? ? ? ? ? ? ?2011-01-01 ? 2010-01-01 ? ?Increase ?Country > > 1 ? ? - ? ? US ? ?1519.53 M ? ?1495.13 M ? ? ? 1.6% ? United States > 2 ? ? - ? ? CN ? ? 277.64 M ? ? 232.45 M ? ? ?19.4% ? China > 3 ? ? - ? ? JP ? ? 186.82 M ? ? 177.15 M ? ? ? 5.5% ? Japan > 4 ? ? - ? ? EU ? ? 151.80 M ? ? 149.48 M ? ? ? 1.6% ? Multi-country in Europe > 5 ? ?(6) ? ?KR ? ? 103.50 M ? ? ?77.77 M ? ? ?33.1% ? Korea > 6 ? ?(5) ? ?DE ? ? ?91.61 M ? ? ?86.51 M ? ? ? 5.9% ? Germany > 7 ? ?(9) ? ?GB ? ? ?82.25 M ? ? ?74.18 M ? ? ?10.9% ? United Kingdom > 8 ? ? - ? ? CA ? ? ?79.53 M ? ? ?76.96 M ? ? ? 3.3% ? Canada > 9 ? ? - ? ? FR ? ? ?79.29 M ? ? ?75.54 M ? ? ? 5.0% ? France > 10 ? ?- ? ? AU ? ? ?49.10 M ? ? ?39.77 M ? ? ?23.5% ? Australia > 11 ? ?- ? ? BR ? ? ?40.24 M ? ? ?33.95 M ? ? ?18.5% ? Brazil > 12 ? ?- ? ? IT ? ? ?37.14 M ? ? ?33.50 M ? ? ?10.9% ? Italy > 13 ? ?- ? ? RU ? ? ?34.66 M ? ? ?28.47 M ? ? ?21.7% ? Russia > 14 ? ?- ? ? TW ? ? ?31.93 M ? ? ?27.10 M ? ? ?17.8% ? Taiwan > 15 ? (19) ? IN ? ? ?28.70 M ? ? ?19.42 M ? ? ?47.8% ? India > > Because the US holds so much space, the increase of 25 million addresses seems small, but that's still more than 10% of the address space given out in 2010. China's growth is slowing down a little at 45 million addresses last year compared to 50 million in 2009. But other countries in Asia are picking up the slack and then some: Korea keeps using up large amounts of address space, and India is now also picking up the pace. The US now has 47.3% of the address space in use, down from 50.1% a year ago. The other countries in the top 15 collectively hold 39.7%, up from 38%. That leaves 13% for the rest of the world, up from 12%. > > Note that I slightly changed the way addresses are counted: previously, all the legacy blocks that didn't have an RIR listed were assumed to be used 100%. But with the return of most of the Interop block this is no longer the case: although ARIN isn't listed as administering the 45/8 block, they actually are and only have 45.0.0.0/15 listed as in use. > From sethm at rollernet.us Tue Jan 4 11:10:46 2011 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 04 Jan 2011 09:10:46 -0800 Subject: sudden low spam levels? In-Reply-To: <4D233860.1050305@gmail.com> References: <20110103180455.GS12141@sizone.org> <4D225D53.9020805@elcsplace.com> <4D233860.1050305@gmail.com> Message-ID: <4D235496.9050305@rollernet.us> On 1/4/11 7:10 AM, William Allen Simpson wrote: > On 1/3/11 6:42 PM, Jay Farrell wrote: >> I noticed a substantial drop in spam in my gmail account in recent days, >> from several hundred a day to maybe a hundred. Ironically, gmail filtered >> this thread to my spam folder. >> > Yes, I found these messages my gmail spam today, too. Lately, gmail has > been regularly flagging NANOG as spam, particularly the end of week > CIDR and BGP reports. > Not being a gmail user this may be a stupid question: can't you whitelist things in gmail? The ratio of spam/ham on NANOG is pretty good. ~Seth From iljitsch at muada.com Tue Jan 4 11:21:06 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 4 Jan 2011 18:21:06 +0100 Subject: 2010 IPv4 (and IPv6) Address Use Report In-Reply-To: References: <49A2BD30-5F17-40FA-A862-FF8C7496DAE0@muada.com> Message-ID: On 4 jan 2011, at 17:30, Richard Barnes wrote: > Also, for a slightly more average-person-friendly view, see Iljitsch's > article in Ars Technica: > I would never dare call NANOG members average. :-) Iljitsch From theghost101 at gmail.com Tue Jan 4 11:21:13 2011 From: theghost101 at gmail.com (Danijel) Date: Tue, 4 Jan 2011 18:21:13 +0100 Subject: sudden low spam levels? In-Reply-To: <4D235496.9050305@rollernet.us> References: <20110103180455.GS12141@sizone.org> <4D225D53.9020805@elcsplace.com> <4D233860.1050305@gmail.com> <4D235496.9050305@rollernet.us> Message-ID: On Tue, Jan 4, 2011 at 18:10, Seth Mattinen wrote: > > Not being a gmail user this may be a stupid question: can't you > whitelist things in gmail? The ratio of spam/ham on NANOG is pretty good. > > Yes, you can, done it a while ago as some messages were going to spam for me also, even few from this thread would go to spam if not for filtering. From richard.barnes at gmail.com Tue Jan 4 11:23:00 2011 From: richard.barnes at gmail.com (Richard Barnes) Date: Tue, 4 Jan 2011 12:23:00 -0500 Subject: 2010 IPv4 (and IPv6) Address Use Report In-Reply-To: References: <49A2BD30-5F17-40FA-A862-FF8C7496DAE0@muada.com> Message-ID: Certainly not. I was thinking more if people wanted something to pass on to management, marketing, mother, etc.... --Richard On Tue, Jan 4, 2011 at 12:21 PM, Iljitsch van Beijnum wrote: > On 4 jan 2011, at 17:30, Richard Barnes wrote: > >> Also, for a slightly more average-person-friendly view, see Iljitsch's >> article in Ars Technica: >> > > I would never dare call NANOG members average. ?:-) > > Iljitsch From surfer at mauigateway.com Tue Jan 4 11:56:52 2011 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 4 Jan 2011 09:56:52 -0800 Subject: RES: Software For Telcos Message-ID: <20110104095652.2F894A6D@resin14.mta.everyone.net> -----Mensagem original----- De: jacob miller [mailto:mmzinyi at yahoo.com] I have been wondering what type of Software do top telcos use. The tracking of Customer circuits to ensure that from marketing,sales,accounts and technical department everything to do with the circuits has to be tracked. Anyone with any help in regards to top software that can be used to run such a telco to ensure that world class service is obtained will be crucial. -------------------------------------------------------------- For a while I was at one that originally had 750K phone lines (now around 500K) and about 100K DSL subs in addition to the leased-line and other types of customers. In the NOC, many different vendor's EMSs reported into Netcool. For example, Fujitsu's Netsmart watched and managed the fiber plant and sent any alarms up to Netcool. When the NOCites saw the red tomato on the big board, they'd go into Netsmart and do the detail work before sending it up to Tier 2 folks. There were many different systems that did the above, including SAM for the Alcatel 7x50 routers. On the other side of the house: PeopleSoft CRM. But if not designed correctly from the start it can become a real mess. Same for Netcool. Don't piecemeal them. Do the design *then* do the implementation. Some CxO-type managers like to try to do those things in parallel to 'synergize' efforts and save money. They don't really understand why the engineering part takes so long. Finally, GOOD LUCK with a telco in today's environment... --- takashi at cpqd.com.br wrote: From: "Takashi Tome" Say in other words, top telco's equipment vendors have their own sw team or third-party suppliers. Equipment vendors are Alcatel, Lucent (ex-AT&T), Ericsson, Nokia, etc. You can see at those companies' web site to check. ------------------------------------------- Alcatel and Lucent are one and the same since a few years ago. scott From dmm at 1-4-5.net Mon Jan 3 09:27:19 2011 From: dmm at 1-4-5.net (David Meyer) Date: Mon, 3 Jan 2011 07:27:19 -0800 Subject: [NANOG-announce] Reminder: NANOG 51 registration fees change from the standard fee to the late fee on 01/08/2010 Message-ID: Register now! See you in Miami. Dave (for the NANOG PC) -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce From nanog at velocity.net Tue Jan 4 13:53:05 2011 From: nanog at velocity.net (nanog at velocity.net) Date: Tue, 4 Jan 2011 14:53:05 -0500 Subject: Verizon DSL Transport Contact? Message-ID: <712ffc5aa87a56c165dac04136322c0c.squirrel@www.velocity.net> Hello NANOG, Excuse me if I've missed something, but I cannot seem to get to the proper Verizon tech to get this corrected. We're an ISP in Erie, PA who "leases" Verizon DSL service. Verizon then drops this service on an ATM PVC on a DS3 that we terminate into our own gear. The current problem is that every evening between 6 and 10 pm localtime (think residential peak hours) we get packet loss (1-30%) to several DSL customers. The customers call complaining that browsing is slow and that they lose packets and cannot play games, watch Netflix, etc. There are other customers that ride the same DS3s that do not experience any packet loss. The physical DS3s are not taking errors and are well under 50% capacity during the problem period. The problem DSL circuits come from a few different COs here, ERIEPAXW and ERIEPAXS at least. All I can assume is that the DS3/OC3/etc that transports this data from some point to ERIEPAXM (where we connect via DS3) gets full. The problem goes away after 10pm and crops back up the next day. Sometimes it lasts 15 minutes, sometimes all 4 hours. I have detailed logs and locations of the circuits to provide to a Verizon tech if needed. Thanks, Velocity.Net From dylan.ebner at crlmed.com Tue Jan 4 15:05:26 2011 From: dylan.ebner at crlmed.com (Dylan Ebner) Date: Tue, 4 Jan 2011 21:05:26 +0000 Subject: Experiences with Comcast Ethernet Message-ID: <017265BF3B9640499754DD48777C3D206AA8E9ADAA@MBX9.EXCHPROD.USA.NET> My company has about 2 dozen Comcast business cable accounts at satellite offices around the Midwest. We are looking at adding an additional ISP to the mix and we are thinking of purchasing an Ethernet circuit from Comcast in an attempt to increase performance on those connections by keeping all the traffic within Comcast's network. Comcast, of course, has assured us this will result in "noticeable" speed increases for those accounts. I am more weary. Does anyone have any experience with Comcast's ethernet offerings? How reliable are they? Do Comcast cable connections see a significant performance improvement? Dylan Ebner, Network Engineer Consulting Radiologists, Ltd. 1221 Nicollet Mall, Minneapolis, MN 55403 ph. 612.573.2236 fax. 612.573.2250 dylan.ebner at crlmed.com www.consultingradiologists.com From dhubbard at dino.hostasaurus.com Tue Jan 4 15:10:27 2011 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Tue, 4 Jan 2011 16:10:27 -0500 Subject: Experiences with Comcast Ethernet Message-ID: With the way their peering is these days, that probably would result in a huge improvement; we have complaints all over the northeast from comcast users who are getting poor connectivity to websites we host as a result of the overloaded Comcast->Level3 links and nothing we can do about it even though we both share a non-Level3 provider since Comcast wants the traffic to head out the bad links. David > -----Original Message----- > From: Dylan Ebner [mailto:dylan.ebner at crlmed.com] > Sent: Tuesday, January 04, 2011 4:05 PM > To: North American Network Operators Group > Subject: Experiences with Comcast Ethernet > > My company has about 2 dozen Comcast business cable accounts > at satellite offices around the Midwest. We are looking at > adding an additional ISP to the mix and we are thinking of > purchasing an Ethernet circuit from Comcast in an attempt to > increase performance on those connections by keeping all the > traffic within Comcast's network. Comcast, of course, has > assured us this will result in "noticeable" speed increases > for those accounts. I am more weary. Does anyone have any > experience with Comcast's ethernet offerings? How reliable > are they? Do Comcast cable connections see a significant > performance improvement? > > Dylan Ebner, Network Engineer > Consulting Radiologists, Ltd. > 1221 Nicollet Mall, Minneapolis, MN 55403 > ph. 612.573.2236 fax. 612.573.2250 > dylan.ebner at crlmed.com > www.consultingradiologists.com > > > From dylan.ebner at crlmed.com Tue Jan 4 15:18:36 2011 From: dylan.ebner at crlmed.com (Dylan Ebner) Date: Tue, 4 Jan 2011 21:18:36 +0000 Subject: Experiences with Comcast Ethernet In-Reply-To: References: Message-ID: <017265BF3B9640499754DD48777C3D206AA8E9ADBD@MBX9.EXCHPROD.USA.NET> That is what we see too. Our connections are used 24/7 and we need lots of download speed so the price/performance is great. Except between 9pm and 1am when the links are saturated. Dylan Ebner, Network Engineer Consulting Radiologists, Ltd. 1221 Nicollet Mall, Minneapolis, MN 55403 ph. 612.573.2236 fax. 612.573.2250 dylan.ebner at crlmed.com www.consultingradiologists.com -----Original Message----- From: David Hubbard [mailto:dhubbard at dino.hostasaurus.com] Sent: Tuesday, January 04, 2011 3:10 PM To: North American Network Operators Group Subject: RE: Experiences with Comcast Ethernet With the way their peering is these days, that probably would result in a huge improvement; we have complaints all over the northeast from comcast users who are getting poor connectivity to websites we host as a result of the overloaded Comcast->Level3 links and nothing we can do about it even though we both share a non-Level3 provider since Comcast wants the traffic to head out the bad links. David > -----Original Message----- > From: Dylan Ebner [mailto:dylan.ebner at crlmed.com] > Sent: Tuesday, January 04, 2011 4:05 PM > To: North American Network Operators Group > Subject: Experiences with Comcast Ethernet > > My company has about 2 dozen Comcast business cable accounts > at satellite offices around the Midwest. We are looking at > adding an additional ISP to the mix and we are thinking of > purchasing an Ethernet circuit from Comcast in an attempt to > increase performance on those connections by keeping all the > traffic within Comcast's network. Comcast, of course, has > assured us this will result in "noticeable" speed increases > for those accounts. I am more weary. Does anyone have any > experience with Comcast's ethernet offerings? How reliable > are they? Do Comcast cable connections see a significant > performance improvement? > > Dylan Ebner, Network Engineer > Consulting Radiologists, Ltd. > 1221 Nicollet Mall, Minneapolis, MN 55403 > ph. 612.573.2236 fax. 612.573.2250 > dylan.ebner at crlmed.com > www.consultingradiologists.com > > > From tagno25 at gmail.com Tue Jan 4 16:31:16 2011 From: tagno25 at gmail.com (Philip Dorr) Date: Tue, 4 Jan 2011 16:31:16 -0600 Subject: sudden low spam levels? In-Reply-To: References: <20110103180455.GS12141@sizone.org> <4D225D53.9020805@elcsplace.com> <4D233860.1050305@gmail.com> <4D235496.9050305@rollernet.us> Message-ID: On Tue, Jan 4, 2011 at 11:21 AM, Danijel wrote: > On Tue, Jan 4, 2011 at 18:10, Seth Mattinen wrote: > >> >> Not being a gmail user this may be a stupid question: can't you >> whitelist things in gmail? The ratio of spam/ham on NANOG is pretty good. >> >> > Yes, you can, done it a while ago as some messages were going to spam for me > also, even few from this thread would go to spam if not for filtering. > And When it does that it at the top of the message it says "Due to a filter you created, this message was not sent to Spam. Edit Filters" From brent at servuhome.net Tue Jan 4 19:24:34 2011 From: brent at servuhome.net (Brent Jones) Date: Tue, 4 Jan 2011 17:24:34 -0800 Subject: Experiences with Comcast Ethernet In-Reply-To: <017265BF3B9640499754DD48777C3D206AA8E9ADAA@MBX9.EXCHPROD.USA.NET> References: <017265BF3B9640499754DD48777C3D206AA8E9ADAA@MBX9.EXCHPROD.USA.NET> Message-ID: On Tue, Jan 4, 2011 at 1:05 PM, Dylan Ebner wrote: > My company has about 2 dozen Comcast business cable accounts at satellite offices around the Midwest. We are looking at adding an additional ISP to the mix and we are thinking of purchasing an Ethernet circuit from Comcast in an attempt to increase performance on those connections by keeping all the traffic within Comcast's network. ?Comcast, of course, has assured us this will result in "noticeable" speed increases for those accounts. I am more weary. Does anyone have any experience with Comcast's ethernet offerings? How reliable are they? Do Comcast cable connections see a significant performance improvement? > > Dylan Ebner, Network Engineer > We have a segment on Comcast Ethernet. We use it for other purposes, just point to point for our needs, but it has been relatively stable. However, we ordered 1Gbit, and we do use a full 1Gbit, for the first few months performance was nowhere near 1Gbit until they upgraded some equipment internally, but speeds have been stable, and reliability good. Note, Comcast Ethernet runs on their fiber network, which sometimes uses aerial lines, I've heard of others having some disconnects when poles get hit and stuff. -- Brent Jones brent at servuhome.net From bclark at spectraaccess.com Tue Jan 4 19:39:40 2011 From: bclark at spectraaccess.com (Bret Clark) Date: Tue, 04 Jan 2011 20:39:40 -0500 Subject: Experiences with Comcast Ethernet In-Reply-To: References: <017265BF3B9640499754DD48777C3D206AA8E9ADAA@MBX9.EXCHPROD.USA.NET> Message-ID: <4D23CBDC.3080301@spectraaccess.com> > On Tue, Jan 4, 2011 at 1:05 PM, Dylan Ebner wrote: >> My company has about 2 dozen Comcast business cable accounts at satellite offices around the Midwest. We are looking at adding an additional ISP to the mix and we are thinking of purchasing an Ethernet circuit from Comcast in an attempt to increase performance on those connections by keeping all the traffic within Comcast's network. Comcast, of course, has assured us this will result in "noticeable" speed increases for those accounts. I am more weary. Does anyone have any experience with Comcast's ethernet offerings? How reliable are they? Do Comcast cable connections see a significant performance improvement? >> >> Dylan Ebner, Network Engineer >> It will only help if the performance issues are related to the Comcast Internet peering connections, otherwise you'll see no difference if the issues are related to congestion occurring on the coax connections from the optical nodes that services each coax feed through neighborhoods and business. This is simple over-utilization that (at least in our neck of the woods) is becoming more and more a problem as Comcast saturates there networks with too many connections...there is only so much bandwidth a coax line can handle! I suspect your performance issues are related to the latter. Bret From streiner at cluebyfour.org Tue Jan 4 15:42:51 2011 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Tue, 4 Jan 2011 16:42:51 -0500 (EST) Subject: Experiences with Comcast Ethernet In-Reply-To: References: <017265BF3B9640499754DD48777C3D206AA8E9ADAA@MBX9.EXCHPROD.USA.NET> Message-ID: On Tue, 4 Jan 2011, Brent Jones wrote: > Note, Comcast Ethernet runs on their fiber network, which sometimes > uses aerial lines, I've heard of others having some disconnects when > poles get hit and stuff. That's not really specific to Comcast. Aerial fiber runs are very common in many places, and have pros and cons, just like underground fiber. jms From rzheng at gmail.com Tue Jan 4 20:02:23 2011 From: rzheng at gmail.com (Richard Zheng) Date: Tue, 4 Jan 2011 16:02:23 -1000 Subject: online backup software vendor Message-ID: Hi, We are looking at providing backup services for our customers. It should have software running on our servers with SAN attached to it and client software running on windows or mac. Anyone knows some good vendors? Thanks! Richard From Bryan.Welch at arrisi.com Tue Jan 4 20:19:08 2011 From: Bryan.Welch at arrisi.com (Welch, Bryan) Date: Tue, 4 Jan 2011 18:19:08 -0800 Subject: online backup software vendor In-Reply-To: References: Message-ID: Should look at Commvault cloud services solution. We run it here internally and like them very much. Bryan -----Original Message----- From: Richard Zheng [mailto:rzheng at gmail.com] Sent: Tuesday, January 04, 2011 6:02 PM To: nanog at nanog.org Subject: online backup software vendor Hi, We are looking at providing backup services for our customers. It should have software running on our servers with SAN attached to it and client software running on windows or mac. Anyone knows some good vendors? Thanks! Richard From ryan.finnesey at HarrierInvestments.com Tue Jan 4 21:25:04 2011 From: ryan.finnesey at HarrierInvestments.com (Ryan Finnesey) Date: Tue, 4 Jan 2011 19:25:04 -0800 Subject: FAA - ASDI servers In-Reply-To: References: Message-ID: <6EFFEFBAC68377459A2E972105C759EC0342B54C@EXVBE005-2.exch005intermedia.net> Is anyone on the list from the FAA? I am trying to find out if we can connect to the ASDI servers via IPv6. Cheers Ryan From morrowc.lists at gmail.com Tue Jan 4 21:31:57 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 4 Jan 2011 22:31:57 -0500 Subject: FAA - ASDI servers In-Reply-To: <6EFFEFBAC68377459A2E972105C759EC0342B54C@EXVBE005-2.exch005intermedia.net> References: <6EFFEFBAC68377459A2E972105C759EC0342B54C@EXVBE005-2.exch005intermedia.net> Message-ID: On Tue, Jan 4, 2011 at 10:25 PM, Ryan Finnesey wrote: > Is anyone on the list from the FAA? ?I am trying to find out if we can > connect to the ASDI servers via IPv6. vacuum tubes don't do ipv6. From ryan.finnesey at HarrierInvestments.com Tue Jan 4 21:39:03 2011 From: ryan.finnesey at HarrierInvestments.com (Ryan Finnesey) Date: Tue, 4 Jan 2011 19:39:03 -0800 Subject: FAA - ASDI servers In-Reply-To: References: <6EFFEFBAC68377459A2E972105C759EC0342B54C@EXVBE005-2.exch005intermedia.net> Message-ID: <6EFFEFBAC68377459A2E972105C759EC0342B54D@EXVBE005-2.exch005intermedia.net> Very true but why the reference to vacuum tubes? -----Original Message----- From: christopher.morrow at gmail.com [mailto:christopher.morrow at gmail.com] On Behalf Of Christopher Morrow Sent: Tuesday, January 04, 2011 10:32 PM To: Ryan Finnesey Cc: nanog at nanog.org Subject: Re: FAA - ASDI servers On Tue, Jan 4, 2011 at 10:25 PM, Ryan Finnesey wrote: > Is anyone on the list from the FAA? ?I am trying to find out if we can > connect to the ASDI servers via IPv6. vacuum tubes don't do ipv6. From morrowc.lists at gmail.com Tue Jan 4 21:49:34 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 4 Jan 2011 22:49:34 -0500 Subject: FAA - ASDI servers In-Reply-To: <6EFFEFBAC68377459A2E972105C759EC0342B54D@EXVBE005-2.exch005intermedia.net> References: <6EFFEFBAC68377459A2E972105C759EC0342B54C@EXVBE005-2.exch005intermedia.net> <6EFFEFBAC68377459A2E972105C759EC0342B54D@EXVBE005-2.exch005intermedia.net> Message-ID: On Tue, Jan 4, 2011 at 10:39 PM, Ryan Finnesey wrote: > Very true but why the reference to vacuum tubes? sadly it was an FAA computer system joke. > -----Original Message----- > From: christopher.morrow at gmail.com [mailto:christopher.morrow at gmail.com] On Behalf Of Christopher Morrow > Sent: Tuesday, January 04, 2011 10:32 PM > To: Ryan Finnesey > Cc: nanog at nanog.org > Subject: Re: FAA - ASDI servers > > On Tue, Jan 4, 2011 at 10:25 PM, Ryan Finnesey wrote: >> Is anyone on the list from the FAA? ?I am trying to find out if we can >> connect to the ASDI servers via IPv6. > > vacuum tubes don't do ipv6. > From jmenerick at netsuite.com Tue Jan 4 21:50:43 2011 From: jmenerick at netsuite.com (Menerick, John) Date: Tue, 4 Jan 2011 19:50:43 -0800 Subject: FAA - ASDI servers In-Reply-To: References: <6EFFEFBAC68377459A2E972105C759EC0342B54C@EXVBE005-2.exch005intermedia.net> <6EFFEFBAC68377459A2E972105C759EC0342B54D@EXVBE005-2.exch005intermedia.net>, Message-ID: <10CD0A2672F6814A988052F37D8D6755063751EE2C@corpmail2007.corp.netledger.com> Every joke has a bit of truth. For instance, until recently (last 10 years?), O'hare's traffic controllers relied upon vacuum tube technology to perform their job. ________________________________________ From: Christopher Morrow [morrowc.lists at gmail.com] Sent: Tuesday, January 04, 2011 7:49 PM To: Ryan Finnesey Cc: nanog at nanog.org Subject: Re: FAA - ASDI servers On Tue, Jan 4, 2011 at 10:39 PM, Ryan Finnesey wrote: > Very true but why the reference to vacuum tubes? sadly it was an FAA computer system joke. > -----Original Message----- > From: christopher.morrow at gmail.com [mailto:christopher.morrow at gmail.com] On Behalf Of Christopher Morrow > Sent: Tuesday, January 04, 2011 10:32 PM > To: Ryan Finnesey > Cc: nanog at nanog.org > Subject: Re: FAA - ASDI servers > > On Tue, Jan 4, 2011 at 10:25 PM, Ryan Finnesey wrote: >> Is anyone on the list from the FAA? I am trying to find out if we can >> connect to the ASDI servers via IPv6. > > vacuum tubes don't do ipv6. > NOTICE: This email and any attachments may contain confidential and proprietary information of NetSuite Inc. and is for the sole use of the intended recipient for the stated purpose. Any improper use or distribution is prohibited. If you are not the intended recipient, please notify the sender; do not review, copy or distribute; and promptly delete or destroy all transmitted information. Please note that all communications and information transmitted through this email system may be monitored by NetSuite or its agents and that all incoming email is automatically scanned by a third party spam and filtering service. From morrowc.lists at gmail.com Tue Jan 4 22:07:17 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 4 Jan 2011 23:07:17 -0500 Subject: FAA - ASDI servers In-Reply-To: <10CD0A2672F6814A988052F37D8D6755063751EE2C@corpmail2007.corp.netledger.com> References: <6EFFEFBAC68377459A2E972105C759EC0342B54C@EXVBE005-2.exch005intermedia.net> <6EFFEFBAC68377459A2E972105C759EC0342B54D@EXVBE005-2.exch005intermedia.net> <10CD0A2672F6814A988052F37D8D6755063751EE2C@corpmail2007.corp.netledger.com> Message-ID: On Tue, Jan 4, 2011 at 10:50 PM, Menerick, John wrote: > Every joke has a bit of truth. ?For instance, until recently (last 10 years?), O'hare's traffic controllers relied upon vacuum tube technology to perform their job. yea, I was really referring to the ATC part of the FAA I suppose... I'm not sure it's still true, but every time I hear it come up in conversation (I bet owen delong would actually know...or rs) there is a bit of: "Well, we could migrate to something NOT VT based, but that'd take 3+ years and ... we have other priorities and ... " wash/rinse/repeat... On a serious note though: (note this is the first hit in google searches for 'adsi server faa') seems to have all manner of information on it about the systems in question. They seem to mention VPN services, I suspect there isn't v6 access, I would have read the requirements doc, but they wanted to send it to me as a .doc file... uhm, this is the 21st century could we distribute this in some sort of cross-platform manner? like txt ? or pdf? (though I hesitate to suggest pdf, what with the adobe pwnage consistently ongoing these days) -chris (not a pilot, not even on tv) From oberman at es.net Tue Jan 4 22:11:48 2011 From: oberman at es.net (Kevin Oberman) Date: Tue, 04 Jan 2011 20:11:48 -0800 Subject: FAA - ASDI servers In-Reply-To: Your message of "Tue, 04 Jan 2011 22:49:34 EST." Message-ID: <20110105041148.DE0951CC3E@ptavv.es.net> > Date: Tue, 4 Jan 2011 22:49:34 -0500 > From: Christopher Morrow > > On Tue, Jan 4, 2011 at 10:39 PM, Ryan Finnesey > wrote: > > Very true but why the reference to vacuum tubes? > > sadly it was an FAA computer system joke. But, since the "F" stands for Federal, if it is still up in two years, it must be reachable by IPv6. Today, the odds are pretty slim as almost no federal systems are reachable by IPv6. It will be an interesting two years for a lot of federal IT folks as the mandate is from the OMB who can pull a budget for non-compliance. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From morrowc.lists at gmail.com Tue Jan 4 22:27:51 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 4 Jan 2011 23:27:51 -0500 Subject: Experiences with Comcast Ethernet In-Reply-To: <017265BF3B9640499754DD48777C3D206AA8E9ADAA@MBX9.EXCHPROD.USA.NET> References: <017265BF3B9640499754DD48777C3D206AA8E9ADAA@MBX9.EXCHPROD.USA.NET> Message-ID: On Tue, Jan 4, 2011 at 4:05 PM, Dylan Ebner wrote: > My company has about 2 dozen Comcast business cable accounts at satellite offices around the > Midwest. We are looking at adding an additional ISP to the mix and we are thinking of purchasing an you are looking at an additional ISP, like multihoming your offices? or 'you need more pipe in the offices'? > Ethernet circuit from Comcast in an attempt to increase performance on those connections by keeping > all > the traffic within Comcast's network. ?Comcast, of course, has assured us this will result in "noticeable" If you bought an L2 ethernet link from 'office' to 'somewhere' why would speed be better? The previous question I asked (clarifying question) aims to help disambiguate this some... o If you buy a gig link to Comcast's IP network (with IP services from Comcast) that's one thing (then all, you hope) offices on the same network are 'faster'. You won't be crossing any of the (potentially) problematic isp peering links other folk have mentioned. o If you are buying ethernet transoprt to connect the offices together in a large vpls/mpls domain you'll probably be better off speed wise (unless there is drastically higher latency or loss) vs the existing links you have to comcast's IP network. (note also the VPLS/MPLS domain doesnt' imply external connectivity, necessarily) o If you are buying ethernet transport to link the offices to an external peering/ISP partner/provider then whatever happens on Comcast's IP network is immaterial (mostly) to this part of your network. -Chris > speed increases for those accounts. I am more weary. Does anyone have any experience with > Comcast's > ethernet offerings? How reliable are they? Do Comcast cable connections see a significant > performance improvement? > > Dylan Ebner, Network Engineer > Consulting Radiologists, Ltd. > 1221 Nicollet Mall, Minneapolis, MN 55403 > ph. 612.573.2236 ? ? fax. 612.573.2250 > dylan.ebner at crlmed.com > www.consultingradiologists.com > > From oberman at es.net Tue Jan 4 22:35:48 2011 From: oberman at es.net (Kevin Oberman) Date: Tue, 04 Jan 2011 20:35:48 -0800 Subject: NIST IPv6 document Message-ID: <20110105043548.BC01B1CC3E@ptavv.es.net> NIST has released SP800-119, "Guidelines for the Secure Deployment of IPv6". While I don't agree with everything in it, it is an excellent overview of IPv6, differences from IPv4, and security advice. While the title sounds like a security document, the security implications are only a part of it. I've not finished reading it, but my first reaction is that this is a good source of information. Well written, fairly detailed (at 188 pages) with lots of references. The PDF is available at: http://csrc.nist.gov/publications/nistpubs/800-119/sp800-119.pdf -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From ryan.finnesey at HarrierInvestments.com Tue Jan 4 22:52:32 2011 From: ryan.finnesey at HarrierInvestments.com (Ryan Finnesey) Date: Tue, 4 Jan 2011 20:52:32 -0800 Subject: FAA - ASDI servers In-Reply-To: References: <6EFFEFBAC68377459A2E972105C759EC0342B54C@EXVBE005-2.exch005intermedia.net><6EFFEFBAC68377459A2E972105C759EC0342B54D@EXVBE005-2.exch005intermedia.net><10CD0A2672F6814A988052F37D8D6755063751EE2C@corpmail2007.corp.netledger.com> Message-ID: <6EFFEFBAC68377459A2E972105C759EC0342B557@EXVBE005-2.exch005intermedia.net> Yes I did read the VPN document before posting to the group but it does not give any IP address information and the e-mail address within the document is bouncing. -----Original Message----- From: christopher.morrow at gmail.com [mailto:christopher.morrow at gmail.com] On Behalf Of Christopher Morrow Sent: Tuesday, January 04, 2011 11:07 PM To: Menerick, John Cc: Ryan Finnesey; nanog at nanog.org Subject: Re: FAA - ASDI servers On Tue, Jan 4, 2011 at 10:50 PM, Menerick, John wrote: > Every joke has a bit of truth. ?For instance, until recently (last 10 years?), O'hare's traffic controllers relied upon vacuum tube technology to perform their job. yea, I was really referring to the ATC part of the FAA I suppose... I'm not sure it's still true, but every time I hear it come up in conversation (I bet owen delong would actually know...or rs) there is a bit of: "Well, we could migrate to something NOT VT based, but that'd take 3+ years and ... we have other priorities and ... " wash/rinse/repeat... On a serious note though: (note this is the first hit in google searches for 'adsi server faa') seems to have all manner of information on it about the systems in question. They seem to mention VPN services, I suspect there isn't v6 access, I would have read the requirements doc, but they wanted to send it to me as a .doc file... uhm, this is the 21st century could we distribute this in some sort of cross-platform manner? like txt ? or pdf? (though I hesitate to suggest pdf, what with the adobe pwnage consistently ongoing these days) -chris (not a pilot, not even on tv) From owen at delong.com Tue Jan 4 22:49:41 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 4 Jan 2011 20:49:41 -0800 Subject: FAA - ASDI servers In-Reply-To: <10CD0A2672F6814A988052F37D8D6755063751EE2C@corpmail2007.corp.netledger.com> References: <6EFFEFBAC68377459A2E972105C759EC0342B54C@EXVBE005-2.exch005intermedia.net> <6EFFEFBAC68377459A2E972105C759EC0342B54D@EXVBE005-2.exch005intermedia.net>, <10CD0A2672F6814A988052F37D8D6755063751EE2C@corpmail2007.corp.netledger.com> Message-ID: <861EAC5B-6DA9-4C79-8B8B-D0EA4983EED6@delong.com> Most controllers still do. I haven't seen any flat-panel displays yet in any of the ARTCCs, TRACONs, or Towers I've visited. Admittedly, it's been a couple of years, so, they might have changed, but, I tend to doubt they've changed all those displays that quickly. Owen On Jan 4, 2011, at 7:50 PM, Menerick, John wrote: > Every joke has a bit of truth. For instance, until recently (last 10 years?), O'hare's traffic controllers relied upon vacuum tube technology to perform their job. > > ________________________________________ > From: Christopher Morrow [morrowc.lists at gmail.com] > Sent: Tuesday, January 04, 2011 7:49 PM > To: Ryan Finnesey > Cc: nanog at nanog.org > Subject: Re: FAA - ASDI servers > > On Tue, Jan 4, 2011 at 10:39 PM, Ryan Finnesey > wrote: >> Very true but why the reference to vacuum tubes? > > sadly it was an FAA computer system joke. > >> -----Original Message----- >> From: christopher.morrow at gmail.com [mailto:christopher.morrow at gmail.com] On Behalf Of Christopher Morrow >> Sent: Tuesday, January 04, 2011 10:32 PM >> To: Ryan Finnesey >> Cc: nanog at nanog.org >> Subject: Re: FAA - ASDI servers >> >> On Tue, Jan 4, 2011 at 10:25 PM, Ryan Finnesey wrote: >>> Is anyone on the list from the FAA? I am trying to find out if we can >>> connect to the ASDI servers via IPv6. >> >> vacuum tubes don't do ipv6. >> > > NOTICE: This email and any attachments may contain confidential and proprietary information of NetSuite Inc. and is for the sole use of the intended recipient for the stated purpose. Any improper use or distribution is prohibited. If you are not the intended recipient, please notify the sender; do not review, copy or distribute; and promptly delete or destroy all transmitted information. Please note that all communications and information transmitted through this email system may be monitored by NetSuite or its agents and that all incoming email is automatically scanned by a third party spam and filtering service. From ryan.finnesey at HarrierInvestments.com Tue Jan 4 22:57:03 2011 From: ryan.finnesey at HarrierInvestments.com (Ryan Finnesey) Date: Tue, 4 Jan 2011 20:57:03 -0800 Subject: FAA - ASDI servers In-Reply-To: <20110105041148.DE0951CC3E@ptavv.es.net> References: Your message of "Tue, 04 Jan 2011 22:49:34 EST." <20110105041148.DE0951CC3E@ptavv.es.net> Message-ID: <6EFFEFBAC68377459A2E972105C759EC0342B558@EXVBE005-2.exch005intermedia.net> Can they simply extend the mandate? We need to setup new connectivity to the FFA and was hoping to go IPv6 right out of the gate. Cheers Ryan -----Original Message----- From: Kevin Oberman [mailto:oberman at es.net] Sent: Tuesday, January 04, 2011 11:12 PM To: Christopher Morrow Cc: Ryan Finnesey; nanog at nanog.org Subject: Re: FAA - ASDI servers > Date: Tue, 4 Jan 2011 22:49:34 -0500 > From: Christopher Morrow > > On Tue, Jan 4, 2011 at 10:39 PM, Ryan Finnesey > wrote: > > Very true but why the reference to vacuum tubes? > > sadly it was an FAA computer system joke. But, since the "F" stands for Federal, if it is still up in two years, it must be reachable by IPv6. Today, the odds are pretty slim as almost no federal systems are reachable by IPv6. It will be an interesting two years for a lot of federal IT folks as the mandate is from the OMB who can pull a budget for non-compliance. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From nanog at deman.com Tue Jan 4 23:01:59 2011 From: nanog at deman.com (Michael DeMan) Date: Tue, 4 Jan 2011 21:01:59 -0800 Subject: FAA - ASDI servers In-Reply-To: <6EFFEFBAC68377459A2E972105C759EC0342B558@EXVBE005-2.exch005intermedia.net> References: Your message of "Tue, 04 Jan 2011 22:49:34 EST." <20110105041148.DE0951CC3E@ptavv.es.net> <6EFFEFBAC68377459A2E972105C759EC0342B558@EXVBE005-2.exch005intermedia.net> Message-ID: Is that the FFA or the FAA? On Jan 4, 2011, at 8:57 PM, Ryan Finnesey wrote: > Can they simply extend the mandate? We need to setup new connectivity > to the FFA and was hoping to go IPv6 right out of the gate. > Cheers > Ryan > > > -----Original Message----- > From: Kevin Oberman [mailto:oberman at es.net] > Sent: Tuesday, January 04, 2011 11:12 PM > To: Christopher Morrow > Cc: Ryan Finnesey; nanog at nanog.org > Subject: Re: FAA - ASDI servers > >> Date: Tue, 4 Jan 2011 22:49:34 -0500 >> From: Christopher Morrow >> >> On Tue, Jan 4, 2011 at 10:39 PM, Ryan Finnesey >> wrote: >>> Very true but why the reference to vacuum tubes? >> >> sadly it was an FAA computer system joke. > > But, since the "F" stands for Federal, if it is still up in two years, > it must be reachable by IPv6. Today, the odds are pretty slim as almost > no federal systems are reachable by IPv6. It will be an interesting two > years for a lot of federal IT folks as the mandate is from the OMB who > can pull a budget for non-compliance. > -- > R. Kevin Oberman, Network Engineer > Energy Sciences Network (ESnet) > Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) > E-mail: oberman at es.net Phone: +1 510 486-8634 > Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 > From adam at leff.co Tue Jan 4 23:09:36 2011 From: adam at leff.co (Adam Leff) Date: Wed, 5 Jan 2011 00:09:36 -0500 Subject: FAA - ASDI servers In-Reply-To: <861EAC5B-6DA9-4C79-8B8B-D0EA4983EED6@delong.com> References: <6EFFEFBAC68377459A2E972105C759EC0342B54C@EXVBE005-2.exch005intermedia.net> <6EFFEFBAC68377459A2E972105C759EC0342B54D@EXVBE005-2.exch005intermedia.net> <10CD0A2672F6814A988052F37D8D6755063751EE2C@corpmail2007.corp.netledger.com> <861EAC5B-6DA9-4C79-8B8B-D0EA4983EED6@delong.com> Message-ID: <638738528208619096@unknownmsgid> The new Potomac Consolidated TRACON in Warrenton, VA is relatively new and has the newer equipment with flat-screen scopes, touch-screen radio/phone controls, etc. It is an impressive facility. Adam On Jan 4, 2011, at 23:56, Owen DeLong wrote: > Most controllers still do. I haven't seen any flat-panel displays yet in any of the > ARTCCs, TRACONs, or Towers I've visited. Admittedly, it's been a couple of > years, so, they might have changed, but, I tend to doubt they've changed all > those displays that quickly. > > Owen > > On Jan 4, 2011, at 7:50 PM, Menerick, John wrote: > >> Every joke has a bit of truth. For instance, until recently (last 10 years?), O'hare's traffic controllers relied upon vacuum tube technology to perform their job. >> >> ________________________________________ >> From: Christopher Morrow [morrowc.lists at gmail.com] >> Sent: Tuesday, January 04, 2011 7:49 PM >> To: Ryan Finnesey >> Cc: nanog at nanog.org >> Subject: Re: FAA - ASDI servers >> >> On Tue, Jan 4, 2011 at 10:39 PM, Ryan Finnesey >> wrote: >>> Very true but why the reference to vacuum tubes? >> >> sadly it was an FAA computer system joke. >> >>> -----Original Message----- >>> From: christopher.morrow at gmail.com [mailto:christopher.morrow at gmail.com] On Behalf Of Christopher Morrow >>> Sent: Tuesday, January 04, 2011 10:32 PM >>> To: Ryan Finnesey >>> Cc: nanog at nanog.org >>> Subject: Re: FAA - ASDI servers >>> >>> On Tue, Jan 4, 2011 at 10:25 PM, Ryan Finnesey wrote: >>>> Is anyone on the list from the FAA? I am trying to find out if we can >>>> connect to the ASDI servers via IPv6. >>> >>> vacuum tubes don't do ipv6. >>> >> >> NOTICE: This email and any attachments may contain confidential and proprietary information of NetSuite Inc. and is for the sole use of the intended recipient for the stated purpose. Any improper use or distribution is prohibited. If you are not the intended recipient, please notify the sender; do not review, copy or distribute; and promptly delete or destroy all transmitted information. Please note that all communications and information transmitted through this email system may be monitored by NetSuite or its agents and that all incoming email is automatically scanned by a third party spam and filtering service. > > From merike at doubleshotsecurity.com Tue Jan 4 23:13:58 2011 From: merike at doubleshotsecurity.com (Merike Kaeo) Date: Tue, 4 Jan 2011 21:13:58 -0800 Subject: FAA - ASDI servers In-Reply-To: <6EFFEFBAC68377459A2E972105C759EC0342B558@EXVBE005-2.exch005intermedia.net> References: Your message of "Tue, 04 Jan 2011 22:49:34 EST." <20110105041148.DE0951CC3E@ptavv.es.net> <6EFFEFBAC68377459A2E972105C759EC0342B558@EXVBE005-2.exch005intermedia.net> Message-ID: I've pinged someone offline who may have a contact. Will let you know offline if I do and connect you. I had some peripheral insight a few years ago when I did some work with Boeing. Even had a hand at editing some ARINC standards. The airline industry was umm....interesting :) Suffice to say the guy I was working with at Boeing was pushing hard for v6 capability within ARINC and this was 2007. Keep fingers crossed. - merike On Jan 4, 2011, at 8:57 PM, Ryan Finnesey wrote: > Can they simply extend the mandate? We need to setup new connectivity > to the FFA and was hoping to go IPv6 right out of the gate. > Cheers > Ryan > > > -----Original Message----- > From: Kevin Oberman [mailto:oberman at es.net] > Sent: Tuesday, January 04, 2011 11:12 PM > To: Christopher Morrow > Cc: Ryan Finnesey; nanog at nanog.org > Subject: Re: FAA - ASDI servers > >> Date: Tue, 4 Jan 2011 22:49:34 -0500 >> From: Christopher Morrow >> >> On Tue, Jan 4, 2011 at 10:39 PM, Ryan Finnesey >> wrote: >>> Very true but why the reference to vacuum tubes? >> >> sadly it was an FAA computer system joke. > > But, since the "F" stands for Federal, if it is still up in two years, > it must be reachable by IPv6. Today, the odds are pretty slim as almost > no federal systems are reachable by IPv6. It will be an interesting two > years for a lot of federal IT folks as the mandate is from the OMB who > can pull a budget for non-compliance. > -- > R. Kevin Oberman, Network Engineer > Energy Sciences Network (ESnet) > Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) > E-mail: oberman at es.net Phone: +1 510 486-8634 > Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 > From jsw at inconcepts.biz Wed Jan 5 00:15:25 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Wed, 5 Jan 2011 01:15:25 -0500 Subject: NIST IPv6 document In-Reply-To: <20110105043548.BC01B1CC3E@ptavv.es.net> References: <20110105043548.BC01B1CC3E@ptavv.es.net> Message-ID: On Tue, Jan 4, 2011 at 11:35 PM, Kevin Oberman wrote: > The PDF is available at: I notice that this document, in its nearly 200 pages, makes only casual mention of ARP/NDP table overflow attacks, which may be among the first real DoS challenges production IPv6 networks, and equipment vendors, have to resolve. Some platforms have far worse failure modes than others when subjected to such an attack, and information on this subject is not widely-available. Unless operators press their vendors for information, and more knobs, to deal with this problem, we may all be waiting for some group like "Anonymous" to take advantage of this vulnerability in IPv6 networks with large /64 subnets configured on LANs; at which point we may all find ourselves scrambling to request knobs, or worse, redesigning and renumbering our LANs. RFC5157 does not touch on this topic at all, and that is the sole reference I see in the NIST publication to scanning attacks. I continue to believe that a heck of a lot of folks are missing the boat on this issue, including some major equipment vendors. It has been pointed out to me that I should have been more vocal when IPv6 was still called IPng, but in 16 years, there has been nothing done about this problem other than water-cooler talk. I suspect that will continue to be the case until those of us who have configured our networks carefully are having a laugh at the networks who haven't. However, until that time, it's also been pointed out to me that customers will expect /64 LANs, and not offering it may put networks at a competitive disadvantage. Vendor solutions are needed before scanning IPv6 LANs becomes a popular way to inconvenience (at best) or disable (at worst) service providers and their customers. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From owen at delong.com Wed Jan 5 01:25:50 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 4 Jan 2011 23:25:50 -0800 Subject: FAA - ASDI servers In-Reply-To: References: <6EFFEFBAC68377459A2E972105C759EC0342B54C@EXVBE005-2.exch005intermedia.net> <6EFFEFBAC68377459A2E972105C759EC0342B54D@EXVBE005-2.exch005intermedia.net> <10CD0A2672F6814A988052F37D8D6755063751EE2C@corpmail2007.corp.netledger.com> Message-ID: On Jan 4, 2011, at 8:07 PM, Christopher Morrow wrote: > On Tue, Jan 4, 2011 at 10:50 PM, Menerick, John wrote: >> Every joke has a bit of truth. For instance, until recently (last 10 years?), O'hare's traffic controllers relied upon vacuum tube technology to perform their job. > > yea, I was really referring to the ATC part of the FAA I suppose... er... so was he... Tower, Tracon, ARTCC are all part of ATC. If you ever want to discuss the ATC system in detail, feel free to ask. (Commercial, AIrplane Single Engine Land, Instrument Airplane). I have lots of time working with ATC and have spent time in towers, TRACONs and ARTCCs talking to them about what they do. > I'm not sure it's still true, but every time I hear it come up in > conversation (I bet owen delong would actually know...or rs) there is > a bit of: > "Well, we could migrate to something NOT VT based, but that'd take 3+ > years and ... we have other priorities and ... " > There are actually advantages for CRT based scopes for ATC purposes. > wash/rinse/repeat... On a serious note though: > > > (note this is the first hit in google searches for 'adsi server faa') > seems to have all manner of information on it about the systems in > question. They seem to mention VPN services, I suspect there isn't v6 > access, I would have read the requirements doc, but they wanted to > send it to me as a .doc file... uhm, this is the 21st century could we > distribute this in some sort of cross-platform manner? like txt ? or > pdf? (though I hesitate to suggest pdf, what with the adobe pwnage > consistently ongoing these days) > Best thing is probably to reach out to the people at: http://www.fly.faa.gov/ASDI/asdidocs/ASDI_Contact_Information_for_ASDI_webpage.pdf And request it. Owen From mohacsi at niif.hu Wed Jan 5 02:31:46 2011 From: mohacsi at niif.hu (Mohacsi Janos) Date: Wed, 5 Jan 2011 09:31:46 +0100 (CET) Subject: NIST IPv6 document In-Reply-To: References: <20110105043548.BC01B1CC3E@ptavv.es.net> Message-ID: Dear Jeff, In my opinion the real challenges already in IPv6 networks the following: SPAM and attacking over IPv6; DoS; track back hosts with privacy enhanced addresses. Do you have some methods in your mind to resolve ARP/ND overflow problem? I think limiting mac address per port on switches both efficient on IPv4 and IPv6. Equivalent of DHCP snooping and Dynamic ARP Inspection should be implemented by the switch vendors.... But remember DHCP snooping et al. implemented in IPv4 after the first serious attacks...Make pressure on your switch vendors.... Janos Mohacsi Head of HBONE+ project Network Engineer, Deputy Director of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 On Wed, 5 Jan 2011, Jeff Wheeler wrote: > On Tue, Jan 4, 2011 at 11:35 PM, Kevin Oberman wrote: >> The PDF is available at: > > I notice that this document, in its nearly 200 pages, makes only > casual mention of ARP/NDP table overflow attacks, which may be among > the first real DoS challenges production IPv6 networks, and equipment > vendors, have to resolve. Some platforms have far worse failure modes > than others when subjected to such an attack, and information on this > subject is not widely-available. > > Unless operators press their vendors for information, and more knobs, > to deal with this problem, we may all be waiting for some group like > "Anonymous" to take advantage of this vulnerability in IPv6 networks > with large /64 subnets configured on LANs; at which point we may all > find ourselves scrambling to request knobs, or worse, redesigning and > renumbering our LANs. > > RFC5157 does not touch on this topic at all, and that is the sole > reference I see in the NIST publication to scanning attacks. > > I continue to believe that a heck of a lot of folks are missing the > boat on this issue, including some major equipment vendors. It has > been pointed out to me that I should have been more vocal when IPv6 > was still called IPng, but in 16 years, there has been nothing done > about this problem other than water-cooler talk. I suspect that will > continue to be the case until those of us who have configured our > networks carefully are having a laugh at the networks who haven't. > However, until that time, it's also been pointed out to me that > customers will expect /64 LANs, and not offering it may put networks > at a competitive disadvantage. > > Vendor solutions are needed before scanning IPv6 LANs becomes a > popular way to inconvenience (at best) or disable (at worst) service > providers and their customers. > > -- > Jeff S Wheeler > Sr Network Operator? /? Innovative Network Concepts > > From rdobbins at arbor.net Wed Jan 5 03:39:32 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 5 Jan 2011 09:39:32 +0000 Subject: NIST IPv6 document In-Reply-To: References: <20110105043548.BC01B1CC3E@ptavv.es.net> Message-ID: <82FEA626-9107-4171-90FF-DDC29849D52C@arbor.net> On Jan 5, 2011, at 1:15 PM, Jeff Wheeler wrote: > I notice that this document, in its nearly 200 pages, makes only casual mention of ARP/NDP table overflow attacks, which may be among > the first real DoS challenges production IPv6 networks, and equipmentvendors, have to resolve. They also only make small mention of DNS- and broadcast-hinted scanning, and none at all of routing-hinted scanning. > It has been pointed out to me that I should have been more vocal when IPv6 was still called IPng, but in 16 years, there has been nothing done > about this problem other than water-cooler talk. Likewise. I never in my wildest dreams thought that such a bag of hurt, with all the problems of IPv4 *plus* its own inherent problems - in *hex*, no less - would end up being adopted. I was sure that the adults would step in, at some point, and get things back on a more sensible footing. Obviously, I'm the biggest idiot on the Internet, and have only my own misplaced faith in the IAB/IETF process to blame, heh. The authors of the document also make only small mention of the dangers of extension header-driven DoS for infrastructure, but at least they mention it, which puts them ahead of most folks in this regard. They also fail to mention the dangers represented by the consonance of the English letters 'B', 'C', 'D', and 'E'. My guess it that billions of USD in outages, misconfigurations, and avoidable security incidents will result from verbal miscommunication of these letters, yet another reason why adopting a hexadecimal numbering scheme was foolish in the extreme. Ah, well, no use crying over spilt milk. The document itself is a good tutorial on IPv6, and it's great that the authors did indeed touch upon these security concerns, but the security aspect as a whole is seemingly deliberately understated, which does a disservice to the lay reader. One can only imagine that there were non-technical considerations which came into play. ------------------------------------------------------------------------ Roland Dobbins // Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay From rdobbins at arbor.net Wed Jan 5 03:47:03 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 5 Jan 2011 09:47:03 +0000 Subject: NIST IPv6 document In-Reply-To: <82FEA626-9107-4171-90FF-DDC29849D52C@arbor.net> References: <20110105043548.BC01B1CC3E@ptavv.es.net> <82FEA626-9107-4171-90FF-DDC29849D52C@arbor.net> Message-ID: <02520E7D-CA17-4D1C-A697-1D660A2F9E99@arbor.net> On Jan 5, 2011, at 4:39 PM, Dobbins, Roland wrote: > They also only make small mention of DNS- and broadcast-hinted scanning, and none at all of routing-hinted scanning. I meant to include, ' . . . and the strain that this hinted scanning will place on the DNS and routing/switching infrastructure.' ------------------------------------------------------------------------ Roland Dobbins // Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay From tshaw at oitc.com Wed Jan 5 05:25:34 2011 From: tshaw at oitc.com (TR Shaw) Date: Wed, 5 Jan 2011 06:25:34 -0500 Subject: FAA - ASDI servers In-Reply-To: References: <6EFFEFBAC68377459A2E972105C759EC0342B54C@EXVBE005-2.exch005intermedia.net> <6EFFEFBAC68377459A2E972105C759EC0342B54D@EXVBE005-2.exch005intermedia.net> <10CD0A2672F6814A988052F37D8D6755063751EE2C@corpmail2007.corp.netledger.com> Message-ID: <7DF2F5C7-F02C-460F-969C-0F9E8D159F41@oitc.com> On Jan 4, 2011, at 11:07 PM, Christopher Morrow wrote: > On Tue, Jan 4, 2011 at 10:50 PM, Menerick, John wrote: >> Every joke has a bit of truth. For instance, until recently (last 10 years?), O'hare's traffic controllers relied upon vacuum tube technology to perform their job. > > yea, I was really referring to the ATC part of the FAA I suppose... > I'm not sure it's still true, but every time I hear it come up in > conversation (I bet owen delong would actually know...or rs) there is > a bit of: > "Well, we could migrate to something NOT VT based, but that'd take 3+ > years and ... we have other priorities and ... " > > wash/rinse/repeat... On a serious note though: > > > (note this is the first hit in google searches for 'adsi server faa') > seems to have all manner of information on it about the systems in > question. They seem to mention VPN services, I suspect there isn't v6 > access, I would have read the requirements doc, but they wanted to > send it to me as a .doc file... uhm, this is the 21st century could we > distribute this in some sort of cross-platform manner? like txt ? or > pdf? (though I hesitate to suggest pdf, what with the adobe pwnage > consistently ongoing these days) There is a federal directive that has been in place for a number of years that requires IPV6 support for all new IT contracts/systems and also a directive to all federal agencies to support IPV6 by 2008 (See http://ipv6.com/articles/general/US_Government_IPv6.htm ) Tom From leen at consolejunkie.net Wed Jan 5 05:34:44 2011 From: leen at consolejunkie.net (Leen Besselink) Date: Wed, 05 Jan 2011 12:34:44 +0100 Subject: NIST IPv6 document In-Reply-To: <82FEA626-9107-4171-90FF-DDC29849D52C@arbor.net> References: <20110105043548.BC01B1CC3E@ptavv.es.net> <82FEA626-9107-4171-90FF-DDC29849D52C@arbor.net> Message-ID: <4D245754.2000406@consolejunkie.net> On 01/05/2011 10:39 AM, Dobbins, Roland wrote: > > The document itself is a good tutorial on IPv6, and it's great that the authors did indeed touch upon these security concerns, but the security aspect as a whole is seemingly deliberately understated, which does a disservice to the lay reader. One can only imagine that there were non-technical considerations which came into play. That almost sounds like a conspiracy theory, let me know when it shows up on Wikileaks. :-) I think it's better to show what is broken and let vendors fix it, then to look the other way. The only people I know actively and openly working on creating tests to find and report bugs in IPv6 protocols and software is the "THC-IPV6"-project by "van Hauser". Here is an old presentation from 2005 from him: http://media.ccc.de/browse/congress/2005/22C3-772-en-attacking_ipv6.html http://events.ccc.de/congress/2005/fahrplan/attachments/642-vh_thcipv6_attackccc05presentation.pdf Most is still possible and not fixed to this date. And his site: http://www.thc.org/thc-ipv6 He did a new presentation at 27c3 in december 2010: http://events.ccc.de/congress/2010/Fahrplan/events/3957.en.html A video and slides should show up on the list soon: http://media.ccc.de/tags/27c3.html (because of audio transcoding issues some videos are not online right now, if you ask me nicely I could mail a link for the video from before they took it down) Have a nice day, Leen Besselink. From rs at seastrom.com Wed Jan 5 05:36:25 2011 From: rs at seastrom.com (Robert E. Seastrom) Date: Wed, 05 Jan 2011 06:36:25 -0500 Subject: FAA - ASDI servers In-Reply-To: <7DF2F5C7-F02C-460F-969C-0F9E8D159F41@oitc.com> (TR Shaw's message of "Wed, 5 Jan 2011 06:25:34 -0500") References: <6EFFEFBAC68377459A2E972105C759EC0342B54C@EXVBE005-2.exch005intermedia.net> <6EFFEFBAC68377459A2E972105C759EC0342B54D@EXVBE005-2.exch005intermedia.net> <10CD0A2672F6814A988052F37D8D6755063751EE2C@corpmail2007.corp.netledger.com> <7DF2F5C7-F02C-460F-969C-0F9E8D159F41@oitc.com> Message-ID: <86d3ob37ly.fsf@seastrom.com> TR Shaw writes: > There is a federal directive that has been in place for a number of > years that requires IPV6 support for all new IT contracts/systems > and also a directive to all federal agencies to support IPV6 by 2008 > (See http://ipv6.com/articles/general/US_Government_IPv6.htm ) And conveniently it's even getting more traction than GOSIP did. I think there have been some federal directives to balance the budget too. Point being that a PDF of such a directive is worth the paper it is written on if people are inclined to just figure out a way around it. (for those who are lucky or young enough to not remember: http://en.wikipedia.org/wiki/GOSIP ) -r From tagno25 at gmail.com Wed Jan 5 06:02:38 2011 From: tagno25 at gmail.com (Philip Dorr) Date: Wed, 5 Jan 2011 06:02:38 -0600 Subject: NIST IPv6 document In-Reply-To: <4D245754.2000406@consolejunkie.net> References: <20110105043548.BC01B1CC3E@ptavv.es.net> <82FEA626-9107-4171-90FF-DDC29849D52C@arbor.net> <4D245754.2000406@consolejunkie.net> Message-ID: On Wed, Jan 5, 2011 at 5:34 AM, Leen Besselink wrote: > He did a new presentation at 27c3 in december 2010: > > http://events.ccc.de/congress/2010/Fahrplan/events/3957.en.html > > A video and slides should show up on the list soon: > > http://media.ccc.de/tags/27c3.html > > (because of audio transcoding issues some videos are not online right > now, if you ask me nicely I could mail a link for the video from before > they took it down) That talk is available on Youtube by the official account http://www.youtube.com/watch?v=c7hq2q4jQYw From caleb.tennis at gmail.com Wed Jan 5 06:03:14 2011 From: caleb.tennis at gmail.com (Caleb Tennis) Date: Wed, 5 Jan 2011 07:03:14 -0500 Subject: online backup software vendor In-Reply-To: References: Message-ID: <7907971F-D64E-4E13-8189-E44058005534@gmail.com> I highly recommend looking at Crashplan Pro. We use it for some of our customers and it works great, and the pricing is very reasonable. On Jan 4, 2011, at 9:02 PM, Richard Zheng wrote: > Hi, > > We are looking at providing backup services for our customers. It should > have software running on our servers with SAN attached to it and client > software running on windows or mac. Anyone knows some good vendors? > > Thanks! > Richard From rcarpen at network1.net Wed Jan 5 06:20:48 2011 From: rcarpen at network1.net (Randy Carpenter) Date: Wed, 5 Jan 2011 07:20:48 -0500 (EST) Subject: online backup software vendor In-Reply-To: <7907971F-D64E-4E13-8189-E44058005534@gmail.com> Message-ID: <2112103944.264.1294230048045.JavaMail.root@zimbra.network1.net> The original poster is looking for software that can be hosted locally, which Crashplan is not as far as I can tell. I am also looking for something that can be hosted locally. The only one we have been able to find is Vembu StoreGrid. Our experience with Vembu has ranged from abysmal to horrific. I would highly recommend *not* looking at them. I had not heard of the Commvault solution. We'll have to look into that. I also be grateful for any other options that people are using. thanks, -Randy -- | Randy Carpenter | Vice President, IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (419)739-9240, x1 ---- ----- Original Message ----- > I highly recommend looking at Crashplan Pro. We use it for some of our > customers and it works great, and the pricing is very reasonable. > > On Jan 4, 2011, at 9:02 PM, Richard Zheng wrote: > > > Hi, > > > > We are looking at providing backup services for our customers. It > > should > > have software running on our servers with SAN attached to it and > > client > > software running on windows or mac. Anyone knows some good vendors? > > > > Thanks! > > Richard From jsw at inconcepts.biz Wed Jan 5 06:21:19 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Wed, 5 Jan 2011 07:21:19 -0500 Subject: NIST IPv6 document In-Reply-To: References: <20110105043548.BC01B1CC3E@ptavv.es.net> Message-ID: On Wed, Jan 5, 2011 at 3:31 AM, Mohacsi Janos wrote: > ? ? ? ?Do you have some methods in your mind to resolve ARP/ND overflow > problem? I think limiting mac address per port on switches both efficient on > IPv4 and IPv6. Equivalent of DHCP snooping and Dynamic ARP Inspection should > be implemented by the switch vendors.... But remember DHCP snooping et al. > implemented in IPv4 after the first serious attacks...Make pressure on your > switch vendors.... Equipment vendors, and most operators, seem to be silent on this issue, not wishing to admit it is a serious problem, which would seem to be a required step before addressing it. Without more knobs on switches or routers, I believe there are only two possible solutions for production networks today: 1) do not configure /64 LANs, and instead, configure smaller subnets which will reduce the impact of scanning attacks This is not desirable, as customers may be driven to expect a /64, or even believe it is necessary for proper functioning. I brought this up with a colleague recently, who simply pointed to the RFC and said, "that's the way you have to do it." Unfortunately, configuring the network the way the standard says, and accepting the potential DoS consequences, will likely be less acceptable to customers than not offering them /64 LAN subnets. This is a foolish position and will not last long once reality sets in, unless vendors provide more knobs. 2) use link-local addressing on LANs, and static addressing to end hosts. This prevents a subset of attacks originated from "the Internet," by making it impossible for NDP to be initiated by scanning activity; but again, is not what customers will expect. It may have operational disadvantages with broken user-space software, is not easy for customers to configure, and does not permit easy porting of addresses among host machines. It requires much greater configuration effort, is likely not possible by way of DHCP. It also does not solve NDP table overflow attacks initiated by a compromised host on the LAN, which makes it a half-way solution. The knobs/features required to somewhat-mitigate the impact of an NDP table overflow attack are, at minimum: * keep NDP/ARP entry alive based on normal traffic flow, do not expire a host that is exchanging traffic + this is not the case with some major platforms, it surprised me to learn who does not do this + may require data plane changes on some boxes to inform control plane of on-going traffic from active addresses * have configurable per-interface limits for NDP/ARP resource consumption, to prevent attack on one interface/LAN from impacting all interfaces on a router + basically no one has this capability + typically requires only control plane modifications * have configurable minimum per-interface NDP/ARP resource reservation + typically requires only control plane modifications * have per-interface policer for NDP/ARP traffic to prevent control plane from becoming overwhelmed + because huge subnets may increase the frequency of scanning attacks, and breaking one interface by reaching a policer limit is much better than breaking the whole box if it runs out of CPU, or breaking NDP/ARP function on the whole box if whole-box policer is reached * learn new ARP/NDP entry when new transit traffic comes from a host on the LAN + even if NDP function is impared on the LAN due to on-going scan attack + again, per-interface limitations must be honored to protect whole box from breaking from one misconfigured / malicious LAN host * have sane defaults for all and allow all to be modified as-needed I am sure we can all agree that, as IPv6 deployment increases, many unimagined security issues may appear and be dealt with. This is one that a lot of smart people agree is a serious design flaw in any IPv6 network where /64 LANs are used, and yet, vendors are not doing anything about it. If customers don't express this concern to them, they won't do anything about it until it becomes a popular DoS attack. In addition, if you design your network around /64 LANs, and especially if you take misguided security-by-obscurity advice and randomize your host addresses so they can't be found in a practical time by scanning, you may have a very difficult time if the ultimate solution to this must be to change the typical subnet size from /64 to something that can fit within a practical NDP/ARP table. Deploying /64 networks because customers demand it and your competitors are doing it is understandable. Doing it "because it's the standard" is very stupid. Anyone doing that on, for example, SONET interfaces or point-to-point Ethernet VLANs in their infrastructure, is making a bad mistake. Doing it toward CE routers, the sort that have an IPv4 /30, is even more foolish; and many major ISPs already know this and are using small subnets such as /126 or /124. If you are still reading, but do not have any idea what I'm talking about, ask yourself these questions: 1) do I know what happens when my router's ARP table gets 100% full? 2) do I know what happens to my ARP/NDP functionality if my router receives a 20k PPS random scan towards an attached IPv6 subnet? will it eat all my CPU and drop my BGP, or just make it impossible to learn new ARP/NDP entries? will it eventually allow old entries to expire such that they perhaps cannot be re-learnt? 3) am I deploying IPv6 in a way that is vulnerable to a trivial attack method? 4) will my network design need fundamental change if my equipment vendor does not add necessary knobs? This is a very serious problem which our industry is actively ignoring, hoping it will just go away. If you are in the group who believes it is a non-issue, I urge you to take your head out of the sand. If you are waiting for your vendor to add more knobs or come up with a magic solution, stop clapping your hands and saying "I believe in fairies," and express your concern to your vendor sales channel. If you are a black-hat script kiddie, please go ahead and start scanning attacks now, while IPv6 largely does not matter and dual-stack infrastructure is somewhat limited (although there will be some spill-over to IPv4 on dual-stack boxes) to motivate change. Finally, if you operate a major IXP with a /64 peering LAN, please explain why this is in any way better than operating the same LAN with a subnet similar in size to its existing IPv4 subnets, e.g. a /120. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From rdobbins at arbor.net Wed Jan 5 06:29:48 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 5 Jan 2011 12:29:48 +0000 Subject: NIST IPv6 document In-Reply-To: References: <20110105043548.BC01B1CC3E@ptavv.es.net> Message-ID: On Jan 5, 2011, at 7:21 PM, Jeff Wheeler wrote: > please explain why this is in any way better than operating the same LAN with a subnet similar in size to its existing IPv4 subnets, e.g. a /120. Using /64s is insane because a) it's unnecessarily wasteful (no lectures on how large the space is, I know, and reject that argument out of hand) and b) it turns the routers/switches into sinkholes. ------------------------------------------------------------------------ Roland Dobbins // Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay From marmata at gmail.com Wed Jan 5 06:36:47 2011 From: marmata at gmail.com (Marco Matarazzo) Date: Wed, 5 Jan 2011 13:36:47 +0100 Subject: online backup software vendor In-Reply-To: <2112103944.264.1294230048045.JavaMail.root@zimbra.network1.net> References: <7907971F-D64E-4E13-8189-E44058005534@gmail.com> <2112103944.264.1294230048045.JavaMail.root@zimbra.network1.net> Message-ID: On Wed, Jan 5, 2011 at 1:20 PM, Randy Carpenter wrote: > > The original poster is looking for software that can be hosted locally, > which Crashplan is not as far as I can tell. I am also looking for something > that can be hosted locally. The only one we have been able to find is Vembu > StoreGrid. Our experience with Vembu has ranged from abysmal to horrific. I > would highly recommend *not* looking at them. > > I had not heard of the Commvault solution. We'll have to look into that. > > I'm using i365 eVault (www.i365.com) which is an locally hosted solution, with the usual bell and whistles (deduplication, asynchronous mirroring of the storage pool, agents for Exchange/SQL/Oracle/Linux/VMware etc.) and priced right. Did not use Commvault or StoreGrid so can't really compare, but never had any problem with i365! Cheers, ]\/[arco -- I'm Winston Wolf, I solve problems. From Neil.Robst at ioko.com Wed Jan 5 06:40:32 2011 From: Neil.Robst at ioko.com (Neil Robst) Date: Wed, 5 Jan 2011 12:40:32 +0000 Subject: online backup software vendor In-Reply-To: References: <7907971F-D64E-4E13-8189-E44058005534@gmail.com> <2112103944.264.1294230048045.JavaMail.root@zimbra.network1.net> Message-ID: <7A57DCAA71129142A6EF9C0074D38A8F33DCA8BEC9@INTCL1EX01.uk.ioko365.com> Asigra? http://www.asigra.com/ Regards, Neil -----Original Message----- From: Marco Matarazzo [mailto:marmata at gmail.com] Sent: 05 January 2011 12:37 To: Randy Carpenter Cc: nanog at nanog.org Subject: Re: online backup software vendor On Wed, Jan 5, 2011 at 1:20 PM, Randy Carpenter wrote: > > The original poster is looking for software that can be hosted locally, > which Crashplan is not as far as I can tell. I am also looking for something > that can be hosted locally. The only one we have been able to find is Vembu > StoreGrid. Our experience with Vembu has ranged from abysmal to horrific. I > would highly recommend *not* looking at them. > > I had not heard of the Commvault solution. We'll have to look into that. > > I'm using i365 eVault (www.i365.com) which is an locally hosted solution, with the usual bell and whistles (deduplication, asynchronous mirroring of the storage pool, agents for Exchange/SQL/Oracle/Linux/VMware etc.) and priced right. Did not use Commvault or StoreGrid so can't really compare, but never had any problem with i365! Cheers, ]\/[arco -- I'm Winston Wolf, I solve problems. From caleb.tennis at gmail.com Wed Jan 5 07:00:28 2011 From: caleb.tennis at gmail.com (Caleb Tennis) Date: Wed, 5 Jan 2011 08:00:28 -0500 Subject: online backup software vendor In-Reply-To: <2112103944.264.1294230048045.JavaMail.root@zimbra.network1.net> References: <2112103944.264.1294230048045.JavaMail.root@zimbra.network1.net> Message-ID: <29D8FAEE-6BA5-44B9-B6CC-90D2647DF7EE@gmail.com> Absolutely it can be hosted locally, we run the server software in our data center and our customers are clients who connect to it for backup. In fact, the server software is free to download and install. Code42, the makers, also run their own "hosted" version, which you may be seeing. Make sure you're looking at Crashplan PRO, and not just Crashplan. We considered Vembu early on as well, but opted for Crashplan instead. It works quite well - the main downside against some of the others is it doesn't support application level backup - it's purely filesystem based. Thus, you can't do things like backup individual Exchange accounts or SQL databases, which some people want. On Jan 5, 2011, at 7:20 AM, Randy Carpenter wrote: > > The original poster is looking for software that can be hosted locally, which Crashplan is not as far as I can tell. I am also looking for something that can be hosted locally. The only one we have been able to find is Vembu StoreGrid. Our experience with Vembu has ranged from abysmal to horrific. I would highly recommend *not* looking at them. > > I had not heard of the Commvault solution. We'll have to look into that. > > I also be grateful for any other options that people are using. > > thanks, > -Randy > > -- > | Randy Carpenter > | Vice President, IT Services > | Red Hat Certified Engineer > | First Network Group, Inc. > | (419)739-9240, x1 > ---- > > ----- Original Message ----- >> I highly recommend looking at Crashplan Pro. We use it for some of our >> customers and it works great, and the pricing is very reasonable. >> >> On Jan 4, 2011, at 9:02 PM, Richard Zheng wrote: >> >>> Hi, >>> >>> We are looking at providing backup services for our customers. It >>> should >>> have software running on our servers with SAN attached to it and >>> client >>> software running on windows or mac. Anyone knows some good vendors? >>> >>> Thanks! >>> Richard From jloiacon at csc.com Wed Jan 5 07:35:00 2011 From: jloiacon at csc.com (Joe Loiacono) Date: Wed, 5 Jan 2011 08:35:00 -0500 Subject: FAA - ASDI servers In-Reply-To: <6EFFEFBAC68377459A2E972105C759EC0342B54C@EXVBE005-2.exch005intermedia.net> References: <6EFFEFBAC68377459A2E972105C759EC0342B54C@EXVBE005-2.exch005intermedia.net> Message-ID: Note that the NIST IPv6 document Kevin pointed to, in the acknowledgements section, includes the following individual who assisted: Trung Nguyen, FAA Joe From: "Ryan Finnesey" To: Date: 01/04/2011 10:25 PM Subject: RE: FAA - ASDI servers Is anyone on the list from the FAA? I am trying to find out if we can connect to the ASDI servers via IPv6. Cheers Ryan From mikea at mikea.ath.cx Wed Jan 5 08:07:56 2011 From: mikea at mikea.ath.cx (mikea) Date: Wed, 5 Jan 2011 08:07:56 -0600 Subject: FAA - ASDI servers In-Reply-To: <86d3ob37ly.fsf@seastrom.com> References: <6EFFEFBAC68377459A2E972105C759EC0342B54C@EXVBE005-2.exch005intermedia.net> <6EFFEFBAC68377459A2E972105C759EC0342B54D@EXVBE005-2.exch005intermedia.net> <10CD0A2672F6814A988052F37D8D6755063751EE2C@corpmail2007.corp.netledger.com> <7DF2F5C7-F02C-460F-969C-0F9E8D159F41@oitc.com> <86d3ob37ly.fsf@seastrom.com> Message-ID: <20110105140756.GA50972@mikea.ath.cx> On Wed, Jan 05, 2011 at 06:36:25AM -0500, Robert E. Seastrom wrote: > > TR Shaw writes: > > > There is a federal directive that has been in place for a number of > > years that requires IPV6 support for all new IT contracts/systems > > and also a directive to all federal agencies to support IPV6 by 2008 > > (See http://ipv6.com/articles/general/US_Government_IPv6.htm ) > > And conveniently it's even getting more traction than GOSIP did. > > I think there have been some federal directives to balance the budget > too. Point being that a PDF of such a directive is worth the paper it > is written on if people are inclined to just figure out a way around it. > > (for those who are lucky or young enough to not remember: > http://en.wikipedia.org/wiki/GOSIP ) Bad cess to you for that! I thought I had recycled those neurons, but it turns out I hadn't. I suppose that cautionary tales are necessary, and GOSIP certainly is one. -- Mike Andrews, W5EGO mikea at mikea.ath.cx Tired old sysadmin From iljitsch at muada.com Wed Jan 5 08:39:04 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 5 Jan 2011 15:39:04 +0100 Subject: NIST IPv6 document In-Reply-To: References: <20110105043548.BC01B1CC3E@ptavv.es.net> Message-ID: <7BA6E87C-7CAD-44DD-BBC1-58DDADD458D5@muada.com> On 5 jan 2011, at 13:21, Jeff Wheeler wrote: > customers may be driven to expect a /64, or > even believe it is necessary for proper functioning. RFC 3513 says: For all unicast addresses, except those that start with binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format. Nobody has been able or willing to tell why that's in there, though. All the same, beware of the anycast addresses if you want to use a smaller block for point-to-point and for LANs, you break stateless autoconfig and very likely terminally confuse DHCPv6 if your prefix length isn't /64. > This is one > that a lot of smart people agree is a serious design flaw in any IPv6 > network where /64 LANs are used It's not a design flaw, it's an implementation flaw. The same one that's in ARP (or maybe RFC 894 wasn't published on april first by accident after all). And the internet managed to survive. A (relatively) easy way to avoid this problem is to either use a stateful firewall that only allows internally initiated sessions, or a filter that lists only addresses that are known to be in use. > and yet, vendors are not doing anything about it. Then don't give them your business. And maybe a nice demonstration on stage at a NANOG meeting will help a bit? > In addition, if you design your network around /64 LANs, and > especially if you take misguided security-by-obscurity advice and > randomize your host addresses so they can't be found in a practical > time by scanning, you may have a very difficult time if the ultimate > solution to this must be to change the typical subnet size from /64 to > something that can fit within a practical NDP/ARP table. Sparse subnets in IPv6 are a feature, not a bug. They're not going to go away. From dylan.ebner at crlmed.com Wed Jan 5 08:45:26 2011 From: dylan.ebner at crlmed.com (Dylan Ebner) Date: Wed, 5 Jan 2011 14:45:26 +0000 Subject: Experiences with Comcast Ethernet In-Reply-To: <4D23CBDC.3080301@spectraaccess.com> References: <017265BF3B9640499754DD48777C3D206AA8E9ADAA@MBX9.EXCHPROD.USA.NET> <4D23CBDC.3080301@spectraaccess.com> Message-ID: <017265BF3B9640499754DD48777C3D206AA8E9B0AD@MBX9.EXCHPROD.USA.NET> This is what we worry about as well. Right now, when the complaints start coming in, we can usually trace the problem to a comcast -> level3 -> qwest issue. Our big concern is we start seeing over subscription on the nodes (we have dealt with this in the past) and our problems start all over again. Dylan Ebner, Network Engineer Consulting Radiologists, Ltd. 1221 Nicollet Mall, Minneapolis, MN 55403 ph. 612.573.2236 fax. 612.573.2250 dylan.ebner at crlmed.com www.consultingradiologists.com -----Original Message----- From: Bret Clark [mailto:bclark at spectraaccess.com] Sent: Tuesday, January 04, 2011 7:40 PM To: nanog at nanog.org Subject: Re: Experiences with Comcast Ethernet > On Tue, Jan 4, 2011 at 1:05 PM, Dylan Ebner wrote: >> My company has about 2 dozen Comcast business cable accounts at satellite offices around the Midwest. We are looking at adding an additional ISP to the mix and we are thinking of purchasing an Ethernet circuit from Comcast in an attempt to increase performance on those connections by keeping all the traffic within Comcast's network. Comcast, of course, has assured us this will result in "noticeable" speed increases for those accounts. I am more weary. Does anyone have any experience with Comcast's ethernet offerings? How reliable are they? Do Comcast cable connections see a significant performance improvement? >> >> Dylan Ebner, Network Engineer >> It will only help if the performance issues are related to the Comcast Internet peering connections, otherwise you'll see no difference if the issues are related to congestion occurring on the coax connections from the optical nodes that services each coax feed through neighborhoods and business. This is simple over-utilization that (at least in our neck of the woods) is becoming more and more a problem as Comcast saturates there networks with too many connections...there is only so much bandwidth a coax line can handle! I suspect your performance issues are related to the latter. Bret From jbates at brightok.net Wed Jan 5 09:04:08 2011 From: jbates at brightok.net (Jack Bates) Date: Wed, 05 Jan 2011 09:04:08 -0600 Subject: NIST IPv6 document In-Reply-To: References: <20110105043548.BC01B1CC3E@ptavv.es.net> Message-ID: <4D248868.70705@brightok.net> On 1/5/2011 6:29 AM, Dobbins, Roland wrote: > > Using /64s is insane because a) it's unnecessarily wasteful (no > lectures on how large the space is, I know, and reject that argument > out of hand) and b) it turns the routers/switches into sinkholes. > Except someone was kind enough to develop a protocol that requires /64 to work. So then there is the SLAAC question. When might it be used? With routers, I usually don't use SLAAC. The exception is end user networks, which makes using SLAAC + DHCPv6-PD extremely dangerous for my edge routers. DHCPv6 IA_TA + DHCPv6-PD would be more sane, predictable, and filterable (and support longer than /64) thought my current edge layout can't support this (darn legacy IOS). I would love a dynamic renumbering scheme for routers, but until all routing protocols (especially iBGP) support shifting from one prefix to the next without a problem, it's a lost cause and manual renumbering is still required. Things like abstracting the router id from the transport protocol would be nice. I could be wrong, but I think ISIS is about it for protocols that won't complain. All that said, routers should be /126 or similar for links, with special circumstances and layouts for customer edge. For server subnets, I actually prefer leaving it /64 and using SLAAC with token assignments. This is easily mitigated with ACLs to filter any packets that don't fall within the range I generally use for the tokens, with localized exceptions for non-token devices which haven't been fully initialized yet (ie, stay behind stateful firewall until I've changed my IP to prefix::0-2FF). I haven't tried it, but I highly suspect it would fail, but it would be nice to use SLAAC with longer than /64. Jack From harbor235 at gmail.com Wed Jan 5 09:08:50 2011 From: harbor235 at gmail.com (harbor235) Date: Wed, 5 Jan 2011 10:08:50 -0500 Subject: IRSCP Message-ID: I was curious if anyone has heard off or is playing around with Intelligent Route Service Control Point? Looks like there are some trials going on and it has potential to centralize routing descsions as well as a DDOS mitigation tool, thoughts? harbor235 ;} From randy at psg.com Wed Jan 5 09:09:13 2011 From: randy at psg.com (Randy Bush) Date: Thu, 06 Jan 2011 00:09:13 +0900 Subject: vmware recover a 4.0 boot with a 4.1 cd In-Reply-To: Message-ID: borked vmware boot, reset says no opsys found. it's a 4.0 system. can i do recovery (saving vmfs) using 4.1 cd, or must i use 4.0? randy From regnauld at nsrc.org Wed Jan 5 09:15:53 2011 From: regnauld at nsrc.org (Phil Regnauld) Date: Wed, 5 Jan 2011 16:15:53 +0100 Subject: vmware recover a 4.0 boot with a 4.1 cd In-Reply-To: References: Message-ID: <20110105151549.GN4613@macbook.catpipe.net> Randy Bush (randy) writes: > borked vmware boot, reset says no opsys found. it's a 4.0 system. > > can i do recovery (saving vmfs) using 4.1 cd, or must i use 4.0? Yes, it will work for accessing the vmfs, at the very least. Phil From jlewis at lewis.org Wed Jan 5 10:26:57 2011 From: jlewis at lewis.org (Jon Lewis) Date: Wed, 5 Jan 2011 11:26:57 -0500 (EST) Subject: AltDB? In-Reply-To: References: Message-ID: [moved to nanog as it seems a far more appropriate forum than cisco-nsp] On Wed, 5 Jan 2011, Jose Madrid wrote: > Anyone here use AltDB? It seems their servers have been down for two days. > I have emailed their admin alias but have gotten nothing. Anyone? > > whois -h whois.altdb.net 199.48.252.0 > [Querying whois.altdb.net] > [Unable to connect to remote host] Can anyone from Level3 say how this will impact customer BGP filters. Will L3 keep working with the last data sync they got from altdb? I'm guessing if whatever the problem is with altdb isn't fixed soon, those who use it as their IRR will need to re-publish all their objects in another IRR DB and have any transit providers who build filters based on IRR data update their profiles to use object data from the IRR DB to which they moved their records. I'd been thinking about moving from altdb to ARIN's but hadn't had sufficient motivation. www.altdb.net is reachable, but the whois server is not. Even altdb queries run from http://www.altdb.net/ fail. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From rcarpen at network1.net Wed Jan 5 10:49:41 2011 From: rcarpen at network1.net (Randy Carpenter) Date: Wed, 5 Jan 2011 11:49:41 -0500 (EST) Subject: online backup software vendor In-Reply-To: Message-ID: <1723843025.330.1294246181209.JavaMail.root@zimbra.network1.net> Does anyone have any comments on any of these solutions being easily managed for end users? We need something that is easy for the customers to install and configure, and is centrally managed. It would also be very nice if it could be fully branded (the one thing that Vembu does well) thanks, -Randy -- | Randy Carpenter | Vice President, IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (419)739-9240, x1 ---- ----- Original Message ----- > On Wed, Jan 5, 2011 at 5:40 AM, Neil Robst > wrote: > > > > Asigra? > > > > http://www.asigra.com/ > > > > Regards, > > Neil > > > > I have hands on experience with Asigra and would recommend it. > > JP From jsw at inconcepts.biz Wed Jan 5 10:49:47 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Wed, 5 Jan 2011 11:49:47 -0500 Subject: NIST IPv6 document In-Reply-To: <7BA6E87C-7CAD-44DD-BBC1-58DDADD458D5@muada.com> References: <20110105043548.BC01B1CC3E@ptavv.es.net> <7BA6E87C-7CAD-44DD-BBC1-58DDADD458D5@muada.com> Message-ID: On Wed, Jan 5, 2011 at 9:39 AM, Iljitsch van Beijnum wrote: >> that a lot of smart people agree is a serious design flaw in any IPv6 >> network where /64 LANs are used > > It's not a design flaw, it's an implementation flaw. The same one that's in ARP (or maybe RFC 894 wasn't published on april first by accident after all). And the internet managed to survive. It appears you want to have a semantic argument. I could grant that, and every point in my message would still stand. However, given that the necessary knobs to protect the network with /64 LANs do not exist on any platform today, vendors are not talking about whether or not they may in the future, and that no implementation with /64 LANs connected to the Internet, or any other routed network which may have malicious or compromised hosts, "design flaw" is correct. This is a much smaller issue with IPv4 ARP, because routers generally have very generous hardware ARP tables in comparison to the typical size of an IPv4 subnet. You seem to think the issue is generating NDP NS. While that is a part of the problem, even if a router can generate NS at an unlimited rate (say, by implementing it in hardware) it cannot store an unlimited number of entries. The failure modes of routers that have a full ARP or NDP table obviously vary, but it is never a good thing. In addition, the high-rate NS inquiries will be received by some or all of the hosts on the LAN, consuming their resources and potentially congesting the LAN. Further, if the router's NDP implementation depends on tracking the status of "incomplete" on-going inquiries, the available resource for this can very easily be used up, preventing the router from learning about new neighbors (or worse.) If it does not depend on that, and blindly learns any entry heard from the LAN, then its NDP table can be totally filled by any compromised / malicious host on the LAN, again, breaking the router. Either way is bad. This is a fundamentally different and much larger problem than those experienced with ARP precisely because the typical subnet size is now, quite literally, seventy-quadrillion times as large as the typical IPv4 subnet. On Wed, Jan 5, 2011 at 9:39 AM, Iljitsch van Beijnum wrote: > A (relatively) easy way to avoid this problem is to either use a stateful firewall that only allows internally initiated sessions, or a filter that lists only addresses that are known to be in use. It would certainly be nice to have a stateful firewall on every single LAN connection. Were there high-speed, stateful firewalls in 1994? Perhaps the IPng folks had this solution in mind, but left it out of the standards process. No doubt they all own stock in SonicWall and are eagerly awaiting the day when "Anonymous" takes down a major ISP every day with a simple attack that has been known to exist, but not addressed, for many years. You must also realize that the stateful firewall has the same problems as the router. It must include a list of allocated IPv6 addresses on each subnet in order to be able to ignore other traffic. While this can certainly be accomplished, it would be much easier to simply list those addresses in the router, which would avoid the expense of any product typically called a "stateful firewall." In either case, you are now maintaining a list of valid addresses for every subnet on the router, and disabling NDP for any other addresses. I agree with you, this knob should be offered by vendors in addition to my list of possible vendor solutions. On Wed, Jan 5, 2011 at 9:39 AM, Iljitsch van Beijnum wrote: > Sparse subnets in IPv6 are a feature, not a bug. They're not going to go away. I do not conceptually disagree with sparse subnets. With the equipment limitations of today, they are a plan to fail. Let's hope that all vendors catch up to this before malicious people/groups. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From bpfankuch at cpgreeley.com Wed Jan 5 10:56:38 2011 From: bpfankuch at cpgreeley.com (Blake Pfankuch) Date: Wed, 5 Jan 2011 09:56:38 -0700 Subject: online backup software vendor In-Reply-To: <1723843025.330.1294246181209.JavaMail.root@zimbra.network1.net> References: <1723843025.330.1294246181209.JavaMail.root@zimbra.network1.net> Message-ID: <01759D50DC387C45A018FE1817CE27D77EA33F6F3A@CPExchange1.cpgreeley.com> Asigra is a great product, however branding isn?t possible from what I know of the solution. We use Asigra through a partner, and when well managed it is a GREAT solution, however it can easily spin out of control if someone doesn't keep on top of it. Randy if you are looking for a little more hands on information with Asigra, feel free to contact me off list and I can arrange a better demo. -----Original Message----- From: Randy Carpenter [mailto:rcarpen at network1.net] Sent: Wednesday, January 05, 2011 9:50 AM To: jake pollmann Cc: Neil Robst; nanog at nanog.org Subject: Re: online backup software vendor Does anyone have any comments on any of these solutions being easily managed for end users? We need something that is easy for the customers to install and configure, and is centrally managed. It would also be very nice if it could be fully branded (the one thing that Vembu does well) thanks, -Randy -- | Randy Carpenter | Vice President, IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (419)739-9240, x1 ---- ----- Original Message ----- > On Wed, Jan 5, 2011 at 5:40 AM, Neil Robst > wrote: > > > > Asigra? > > > > http://www.asigra.com/ > > > > Regards, > > Neil > > > > I have hands on experience with Asigra and would recommend it. > > JP From matthew at corp.crocker.com Wed Jan 5 10:59:06 2011 From: matthew at corp.crocker.com (Matthew S. Crocker) Date: Wed, 5 Jan 2011 11:59:06 -0500 (EST) Subject: online backup software vendor In-Reply-To: Message-ID: <706299929.23571.1294246746384.JavaMail.root@zimbra1.crocker.com> We use Ahsay online backup server (http://www.ahsay.com/jsp/en/home/index.jsp). I've been very happy with it. ----- Original Message ----- > From: "Richard Zheng" > To: nanog at nanog.org > Sent: Tuesday, January 4, 2011 9:02:23 PM > Subject: online backup software vendor > Hi, > > We are looking at providing backup services for our customers. It > should > have software running on our servers with SAN attached to it and > client > software running on windows or mac. Anyone knows some good vendors? > > Thanks! > Richard -- Matthew S. Crocker President Crocker Communications, Inc. PO BOX 710 Greenfield, MA 01302-0710 http://www.crocker.com P: 413-746-2760 From joelja at bogus.com Wed Jan 5 11:04:39 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Wed, 05 Jan 2011 09:04:39 -0800 Subject: NIST IPv6 document In-Reply-To: References: <20110105043548.BC01B1CC3E@ptavv.es.net> <7BA6E87C-7CAD-44DD-BBC1-58DDADD458D5@muada.com> Message-ID: <4D24A4A7.7080208@bogus.com> On 1/5/11 8:49 AM, Jeff Wheeler wrote: > On Wed, Jan 5, 2011 at 9:39 AM, Iljitsch van Beijnum wrote: >>> that a lot of smart people agree is a serious design flaw in any IPv6 >>> network where /64 LANs are used >> >> It's not a design flaw, it's an implementation flaw. The same one that's in ARP (or maybe RFC 894 wasn't published on april first by accident after all). And the internet managed to survive. > > It appears you want to have a semantic argument. I could grant that, > and every point in my message would still stand. However, given that > the necessary knobs to protect the network with /64 LANs do not exist > on any platform today, vendors are not talking about whether or not > they may in the future, and that no implementation with /64 LANs > connected to the Internet, or any other routed network which may have > malicious or compromised hosts, "design flaw" is correct. > > This is a much smaller issue with IPv4 ARP, because routers generally > have very generous hardware ARP tables in comparison to the typical > size of an IPv4 subnet. no it isn't, if you've ever had your juniper router become unavailable because the arp policer caused it to start ignoring updates, or seen systems become unavailable due to an arp storm you'd know that you can abuse arp on a rather small subnet. > You seem to think the issue is generating NDP > NS. While that is a part of the problem, even if a router can > generate NS at an unlimited rate (say, by implementing it in hardware) > it cannot store an unlimited number of entries. The failure modes of > routers that have a full ARP or NDP table obviously vary, but it is > never a good thing. In addition, the high-rate NS inquiries will be > received by some or all of the hosts on the LAN, consuming their > resources and potentially congesting the LAN. Further, if the > router's NDP implementation depends on tracking the status of > "incomplete" on-going inquiries, the available resource for this can > very easily be used up, preventing the router from learning about new > neighbors (or worse.) If it does not depend on that, and blindly > learns any entry heard from the LAN, then its NDP table can be totally > filled by any compromised / malicious host on the LAN, again, breaking > the router. Either way is bad. > > This is a fundamentally different and much larger problem than those > experienced with ARP precisely because the typical subnet size is now, > quite literally, seventy-quadrillion times as large as the typical > IPv4 subnet. > > On Wed, Jan 5, 2011 at 9:39 AM, Iljitsch van Beijnum wrote: >> A (relatively) easy way to avoid this problem is to either use a stateful firewall that only allows internally initiated sessions, or a filter that lists only addresses that are known to be in use. > > It would certainly be nice to have a stateful firewall on every single > LAN connection. Were there high-speed, stateful firewalls in 1994? > Perhaps the IPng folks had this solution in mind, but left it out of > the standards process. No doubt they all own stock in SonicWall and > are eagerly awaiting the day when "Anonymous" takes down a major ISP > every day with a simple attack that has been known to exist, but not > addressed, for many years. > > You must also realize that the stateful firewall has the same problems > as the router. It must include a list of allocated IPv6 addresses on > each subnet in order to be able to ignore other traffic. While this > can certainly be accomplished, it would be much easier to simply list > those addresses in the router, which would avoid the expense of any > product typically called a "stateful firewall." In either case, you > are now maintaining a list of valid addresses for every subnet on the > router, and disabling NDP for any other addresses. I agree with you, > this knob should be offered by vendors in addition to my list of > possible vendor solutions. > > On Wed, Jan 5, 2011 at 9:39 AM, Iljitsch van Beijnum wrote: >> Sparse subnets in IPv6 are a feature, not a bug. They're not going to go away. > > I do not conceptually disagree with sparse subnets. With the > equipment limitations of today, they are a plan to fail. Let's hope > that all vendors catch up to this before malicious people/groups. > From jsw at inconcepts.biz Wed Jan 5 11:07:44 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Wed, 5 Jan 2011 12:07:44 -0500 Subject: AltDB? In-Reply-To: References: Message-ID: On Wed, Jan 5, 2011 at 11:26 AM, Jon Lewis wrote: >> Anyone here use AltDB? It seems their servers have been down for two days. > Can anyone from Level3 say how this will impact customer BGP filters. Will > L3 keep working with the last data sync they got from altdb? ?I'm guessing Since Level3 updates their prefix-lists at least daily, and integrates new ALTDB updates at least daily, and the ALTDB has been down for over a day, obviously it will not affect your Level3 prefix-lists in the near-term. If Level3 decided to stop honoring ALTDB objects, say, because ALTDB was never fixed, I imagine you would find it necessary to re-publish your objects or Level3 would stop honoring your routes. > I'd been thinking about moving from altdb to ARIN's but hadn't had > sufficient motivation. I emailed ARIN yesterday to ask if their IRR database has any authentication support (other than mail-from) yet. I haven't seen any reply from ARIN yet, but my guess is they still have no useful authentication mechanism. I would rather depend on an IRR database that can't process updates for a few days per year, than use one where a malicious party could alter or erase all of my objects at any time. I would like to note that RADB had route6: support in about 2004 or so, if my memory serves me; while the ARIN database did not accept route6 objects until about a year ago. So it is not exactly a high priority for ARIN. Note also that Level3 has an IRR database, so you could use theirs if you want to. I don't prefer to use a transit provider database if I can use a "neutral" one, but sometimes I would rather not pay the (entirely reasonable) fee for the MERIT RADB. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From craigp at tozz.net Wed Jan 5 11:09:00 2011 From: craigp at tozz.net (Craig Pierantozzi) Date: Wed, 5 Jan 2011 10:09:00 -0700 Subject: AltDB? In-Reply-To: References: Message-ID: <94F3F129-608E-46EC-B157-CC23CAA47454@tozz.net> On Jan 5, 2011, at 9:26 AM, Jon Lewis wrote: [snip] > Can anyone from Level3 say how this will impact customer BGP filters. Will L3 keep working with the last data sync they got from altdb? Yes, Level 3 will continue to use the last data mirrored and archived. New filters are not pushed daily, they are only pushed when things change. Archives are here in case people want to know what the latest was: regards From jrhett at netconsonance.com Wed Jan 5 11:11:33 2011 From: jrhett at netconsonance.com (Jo Rhett) Date: Wed, 5 Jan 2011 09:11:33 -0800 Subject: reporting physical plant damage to AT&T? In-Reply-To: <20101125221131.417681CC0C@ptavv.es.net> References: <20101125221131.417681CC0C@ptavv.es.net> Message-ID: <0319E7F7-5BDE-4F4A-B858-6A028C7F3051@netconsonance.com> On Nov 25, 2010, at 2:11 PM, Kevin Oberman wrote: > Have you tried 611 (from an AT&T land-line phone)? Many people don't have one. I haven't had one for over 12 years now, nor have any of my employers for the last 8 years. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jay at prolexic.com Wed Jan 5 11:15:32 2011 From: jay at prolexic.com (Jay Coley) Date: Wed, 05 Jan 2011 17:15:32 +0000 Subject: AltDB? In-Reply-To: <94F3F129-608E-46EC-B157-CC23CAA47454@tozz.net> References: <94F3F129-608E-46EC-B157-CC23CAA47454@tozz.net> Message-ID: <4D24A734.3000807@jcoley.net> On 05/01/2011 17:09, Craig Pierantozzi wrote: > On Jan 5, 2011, at 9:26 AM, Jon Lewis wrote: > > [snip] > >> Can anyone from Level3 say how this will impact customer BGP filters. Will L3 keep working with the last data sync they got from altdb? > > Yes, Level 3 will continue to use the last data mirrored and archived. New filters are not pushed daily, they are only pushed when things change. > > Archives are here in case people want to know what the latest was: > > regards > So has anyone had any contact from ALTDB as to what's going on? Thanks! --J From jsw at inconcepts.biz Wed Jan 5 11:19:16 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Wed, 5 Jan 2011 12:19:16 -0500 Subject: NIST IPv6 document In-Reply-To: <4D24A4A7.7080208@bogus.com> References: <20110105043548.BC01B1CC3E@ptavv.es.net> <7BA6E87C-7CAD-44DD-BBC1-58DDADD458D5@muada.com> <4D24A4A7.7080208@bogus.com> Message-ID: On Wed, Jan 5, 2011 at 12:04 PM, Joel Jaeggli wrote: > no it isn't, if you've ever had your juniper router become unavailable > because the arp policer caused it to start ignoring updates, or seen > systems become unavailable due to an arp storm you'd know that you can > abuse arp on a rather small subnet. These conditions can only be triggered by malicious hosts on the LAN. With IPv6, it can be triggered by scanning attacks originated from "the Internet." No misconfiguration or compromised machine on your network is necessary. This is why it is a fundamentally different, and much larger, problem. Since you seem confused about the basic nature of this issue, I will explain it for you in more detail: IPv4) I can scan your v4 subnet, let's say it's a /24, and your router might send 250 ARP requests and may even add 250 "incomplete" entries to its ARP table. This is not a disaster for that LAN, or any others. No big deal. I can also intentionally send a large amount of traffic to unused v4 IPs on the LAN, which will be handled as unknown-unicast and sent to all hosts on the LAN via broadcasting, but many boxes already have knobs for this, as do many switches. Not good, but also does not affect any other interfaces on the router. IPv6) I can scan your v6 /64 subnet, and your router will have to send out NDP NS for every host I scan. If it requires "incomplete" entries in its table, I will use them all up, and NDP learning will be broken. Typically, this breaks not just on that interface, but on the entire router. This is much worse than the v4/ARP sitation. I trust you will understand the depth of this problem once you realize that no device has enough memory to prevent these attacks without knobs that make various compromises available via configuration. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From regnauld at nsrc.org Wed Jan 5 11:26:30 2011 From: regnauld at nsrc.org (Phil Regnauld) Date: Wed, 5 Jan 2011 18:26:30 +0100 Subject: NIST IPv6 document In-Reply-To: References: <20110105043548.BC01B1CC3E@ptavv.es.net> <7BA6E87C-7CAD-44DD-BBC1-58DDADD458D5@muada.com> <4D24A4A7.7080208@bogus.com> Message-ID: <20110105172629.GB4613@macbook.catpipe.net> Jeff Wheeler (jsw) writes: > > IPv4) [...] > Not good, but also does not affect any other interfaces on the router. You're assuming that all routing devices have per-interface ARP tables. > IPv6) > Typically, this breaks not just on that interface, but on the entire > router. This is much worse than the v4/ARP sitation. Inverse assumption here. Doesn't change much to the case scenario you've put forward as a cause to the problem, but still wanted to point it out. Cheers, Phil From nanog at hostleasing.net Wed Jan 5 11:26:52 2011 From: nanog at hostleasing.net (Randy Epstein) Date: Wed, 5 Jan 2011 12:26:52 -0500 Subject: AltDB? In-Reply-To: <4D24A734.3000807@jcoley.net> References: <94F3F129-608E-46EC-B157-CC23CAA47454@tozz.net> <4D24A734.3000807@jcoley.net> Message-ID: <057301cbacfd$bf89bed0$3e9d3c70$@net> >So has anyone had any contact from ALTDB as to what's going on? >Thanks! >--J I just got off the phone with Steve Rubin. He restarted it 45 minutes ago and it's back up. Regards, Randy From jbates at brightok.net Wed Jan 5 11:31:48 2011 From: jbates at brightok.net (Jack Bates) Date: Wed, 05 Jan 2011 11:31:48 -0600 Subject: NIST IPv6 document In-Reply-To: References: <20110105043548.BC01B1CC3E@ptavv.es.net> <7BA6E87C-7CAD-44DD-BBC1-58DDADD458D5@muada.com> <4D24A4A7.7080208@bogus.com> Message-ID: <4D24AB04.3030803@brightok.net> On 1/5/2011 11:19 AM, Jeff Wheeler wrote: > IPv6) I can scan your v6 /64 subnet, and your router will have to send > out NDP NS for every host I scan. If it requires "incomplete" entries > in its table, I will use them all up, and NDP learning will be broken. > Typically, this breaks not just on that interface, but on the entire > router. This is much worse than the v4/ARP sitation. > I haven't checked of late for v6, but I'd expect the same NDP security we have for ARP these days, which reduces the need to even send unsolicited ND requests. In this day and age, sending unsolicited neighbor requests from a router seems terribly broken. Even with SLAAC, one could quickly design a model that doesn't require unsolicited ND from the router to find the remove computer. This could possibly utilize DAD checks or even await the first packet from the node (similar to how we fill our MAC forwarding tables in switches, and not all switches will broadcast when a MAC is unknown). Jack From jared at puck.nether.net Wed Jan 5 11:31:45 2011 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 5 Jan 2011 12:31:45 -0500 Subject: AltDB? In-Reply-To: <4D24A734.3000807@jcoley.net> References: <94F3F129-608E-46EC-B157-CC23CAA47454@tozz.net> <4D24A734.3000807@jcoley.net> Message-ID: <816AB912-14CF-4028-853A-F0BE77D2EB09@puck.nether.net> On Jan 5, 2011, at 12:15 PM, Jay Coley wrote: > On 05/01/2011 17:09, Craig Pierantozzi wrote: >> On Jan 5, 2011, at 9:26 AM, Jon Lewis wrote: >> >> [snip] >> >>> Can anyone from Level3 say how this will impact customer BGP filters. Will L3 keep working with the last data sync they got from altdb? >> >> Yes, Level 3 will continue to use the last data mirrored and archived. New filters are not pushed daily, they are only pushed when things change. >> >> Archives are here in case people want to know what the latest was: >> >> regards >> > > So has anyone had any contact from ALTDB as to what's going on? I don't know, but I'd like to make a suggestion that most people will just reject, .. but ... 1) If ARIN doesn't provide the level of authentication you desire, as an ARIN member you should send a note to ppml each day until it's available, or make a proposal to improve it. Last time around, it wasn't very exciting for many people. 2) If you DEPEND on something for your business, it may just be "worth it" to: a) pay RADB who operates professionally b) use your ISP provided IRR (eg: NTT, level3, savvis, etc) You are less likely to encounter business issues due to the mirroring/latency etc of RADB -> YourISP or ALTDB -> YourISP if you use them as you have a direct business relationship. They may even prefer their objects over the RADB seen ones. - Jared From richard.barnes at gmail.com Wed Jan 5 11:36:40 2011 From: richard.barnes at gmail.com (Richard Barnes) Date: Wed, 5 Jan 2011 12:36:40 -0500 Subject: NIST IPv6 document In-Reply-To: References: <20110105043548.BC01B1CC3E@ptavv.es.net> <7BA6E87C-7CAD-44DD-BBC1-58DDADD458D5@muada.com> <4D24A4A7.7080208@bogus.com> Message-ID: > IPv6) I can scan your v6 /64 subnet, and your router will have to send > out NDP NS for every host I scan. ?If it requires "incomplete" entries > in its table, I will use them all up, and NDP learning will be broken. > ?Typically, this breaks not just on that interface, but on the entire > router. ?This is much worse than the v4/ARP sitation. I'm guessing you're referring to this paragraph of RFC 4861: " When a node has a unicast packet to send to a neighbor, but does not know the neighbor's link-layer address, it performs address resolution. For multicast-capable interfaces, this entails creating a Neighbor Cache entry in the INCOMPLETE state and transmitting a Neighbor Solicitation message targeted at the neighbor. The solicitation is sent to the solicited-node multicast address corresponding to the target address. " It's worth noting that nothing in this paragraph is normative (there's no RFC 2119 language), so implementations are free to ignore it. I haven't read the NIST document, but it wouldn't conflict with the RFC if they recommended ignoring this paragraph and just relying on the ND cache they already have when a packet arrives. --Richard From jabley at hopcount.ca Wed Jan 5 11:39:21 2011 From: jabley at hopcount.ca (Joe Abley) Date: Wed, 5 Jan 2011 12:39:21 -0500 Subject: AltDB? In-Reply-To: <816AB912-14CF-4028-853A-F0BE77D2EB09@puck.nether.net> References: <94F3F129-608E-46EC-B157-CC23CAA47454@tozz.net> <4D24A734.3000807@jcoley.net> <816AB912-14CF-4028-853A-F0BE77D2EB09@puck.nether.net> Message-ID: <1C8F2F01-28C8-4547-93FC-9C4DD332C0A4@hopcount.ca> On 2011-01-05, at 12:31, Jared Mauch wrote: > 2) If you DEPEND on something for your business, it may just be "worth it" to: > a) pay RADB who operates professionally > b) use your ISP provided IRR (eg: NTT, level3, savvis, etc) I generally recommend that people use the RIPE database, regardless of location. The main reason for that used to be that they supported IPv6 policy attributes before anybody else did, but that's quite possibly no longer a useful discriminator. If you ever have ambitions to announce a route to a peer in Europe, having objects in the RIPE db can also help avoid annoyance. Joe From charles at knownelement.com Wed Jan 5 11:41:31 2011 From: charles at knownelement.com (Charles N Wyble) Date: Wed, 05 Jan 2011 09:41:31 -0800 Subject: reporting physical plant damage to AT&T? In-Reply-To: <0319E7F7-5BDE-4F4A-B858-6A028C7F3051@netconsonance.com> References: <20101125221131.417681CC0C@ptavv.es.net> <0319E7F7-5BDE-4F4A-B858-6A028C7F3051@netconsonance.com> Message-ID: <4D24AD4B.6040104@knownelement.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/05/2011 09:11 AM, Jo Rhett wrote: > On Nov 25, 2010, at 2:11 PM, Kevin Oberman wrote: >> Have you tried 611 (from an AT&T land-line phone)? > > Many people don't have one. I haven't had one for over 12 years now, nor have any of my employers for the last 8 years. They have an 877 number that routes to the same people. I was at a client and they were having some sort of telco emergency and obtained the number as part of the resolution process. Here it is: from http://www.att.com/gen/general?pid=1603 Repair Service 1-866-346-1168 or 611 within state 24 hours a day, 7 days a week It's amazing how many people don't know about 611. It's the fastest way to reach clued/capable of paging clued people. > - -- Charles N Wyble (charles at knownelement.com) Systems craftsman for the stars http://www.knownelement.com Mobile: 626 539 4344 Office: 310 929 8793 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNJK1KAAoJEMvvG/TyLEAtWVgP/3jB6bEu3s7whO1ONHDedJYr NVurhbgNu3EZkbzffXb/NLT2OhfIZNPwAYD0P1H7D8KbZRo3fd+OX8f1q2ys/1G4 /3WV2gEyny9K7GJ8xnK6o7oFnaKc0SXVEk/0T4rHZhAsm5Gpjym42ecAbIf40CZr 63TovwrYUOambFY05Do6UWnkzFGghESwWjQyZKJ3YcQ9upwUBgRQ/uYnGL7MqPDR sr31DjzvtX7woAS1ZC4yH7s4QJ+YnURkgcEfMsDNOGqlak47T53JEgE/YaUp8oQp kxw5ppijLN2xmjQMGfzErDuGVlGpGxJq6bWDNLSQnEXZ3MK56DdnhjUfPYKFiBtj qr/C9GW+16uSlcwIFSvl6EOxoiLkqnQ4QW5py2+D0o9P2K0BMkVluNu+9N0ledp7 9NJSV6WaJEJQnOn6AWEBrpwQPeys5VJksac3eAmqB8ftFus8JeYKGiJSlwSAqP0S EVWn3Z/sSVwcIF1rEzR0bR8ha7AX6eZctcXV1cXETsATwf4nKmr9hiq2qB1nW6bU yAJIluvrBoHxZ8ZkbbtHN5VC+E/mdLJiLcs77+e+0kweh+AFzAQ5/rwNl9iHLGjz ZO6y9xp9novJEHrVWIyYw/Dy7WVlw8o+od3S5bmfjEe3+3hIPCeOfOd1CuevVNaX gEKSu2SK41HRhBxeg+OL =oIB0 -----END PGP SIGNATURE----- From jsw at inconcepts.biz Wed Jan 5 11:44:23 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Wed, 5 Jan 2011 12:44:23 -0500 Subject: NIST IPv6 document In-Reply-To: <20110105172629.GB4613@macbook.catpipe.net> References: <20110105043548.BC01B1CC3E@ptavv.es.net> <7BA6E87C-7CAD-44DD-BBC1-58DDADD458D5@muada.com> <4D24A4A7.7080208@bogus.com> <20110105172629.GB4613@macbook.catpipe.net> Message-ID: On Wed, Jan 5, 2011 at 12:26 PM, Phil Regnauld wrote: > Jeff Wheeler (jsw) writes: >> Not good, but also does not affect any other interfaces on the router. > ? ? ? ?You're assuming that all routing devices have per-interface ARP tables. No, Phil, I am assuming that the routing device has a larger ARP table than 250 entries. To be more correct, I am assuming that the routing device has a large enough ARP table that any one subnet could go from 0 ARP entries to 100% ARP entries without using up all the remaining ARP resources on the box. This is usually true. Further, routing devices usually have enough ARP table space that every subnet attached to them could be 100% full of active ARP entries without using up all the ARP resources. This is also often true. To give some figures, a Cisco 3750 "pizza box" layer-3 switch has room for several thousand ARP entries, and I have several with 3000 - 5000 active ARPs. Most people probably do not have more than a /20 worth of subnets for ARPing to a pizza box switch like this, but it does basically work. As we all know, a /64 is a lot more than a few thousand possible addresses. It is more addresses than anyone can store in memory, so state information for "incomplete" can't be tracked in software without creating problems there. Being fully stateless for new neighbor learning is possible and desirable, but a malicious host on the LAN can badly impact the router. This is why per-interface knobs are badly needed. The largest current routing devices have room for about 100,000 ARP/NDP entries, which can be used up in a fraction of a second with a gigabit of malicious traffic flow. What happens after that is the problem, and we need to tell our vendors what knobs we want so we can "choose our own failure mode" and limit damage to one interface/LAN. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From regnauld at nsrc.org Wed Jan 5 11:57:50 2011 From: regnauld at nsrc.org (Phil Regnauld) Date: Wed, 5 Jan 2011 18:57:50 +0100 Subject: NIST IPv6 document In-Reply-To: References: <20110105043548.BC01B1CC3E@ptavv.es.net> <7BA6E87C-7CAD-44DD-BBC1-58DDADD458D5@muada.com> <4D24A4A7.7080208@bogus.com> <20110105172629.GB4613@macbook.catpipe.net> Message-ID: <20110105175749.GF4613@macbook.catpipe.net> Jeff Wheeler (jsw) writes: > are badly needed. The largest current routing devices have room for > about 100,000 ARP/NDP entries, which can be used up in a fraction of a > second with a gigabit of malicious traffic flow. What happens after > that is the problem, and we need to tell our vendors what knobs we > want so we can "choose our own failure mode" and limit damage to one > interface/LAN. Well there are *some* knobs: http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-addrg_bsc_con.html#wp1369018 Not very smart, as it just controls how fast you run out of entries. I haven't read all entries in this thread yet, but I wonder if http://tools.ietf.org/html/draft-jiang-v6ops-nc-protection-01 has been mentioned ? Seems also that this topic has been brought up here a year ago give or take a couple of weeks: http://www.mail-archive.com/nanog at nanog.org/msg18841.html Cheers, Phil From trejrco at gmail.com Wed Jan 5 12:02:22 2011 From: trejrco at gmail.com (TJ) Date: Wed, 5 Jan 2011 13:02:22 -0500 Subject: NIST IPv6 document In-Reply-To: References: <20110105043548.BC01B1CC3E@ptavv.es.net> <7BA6E87C-7CAD-44DD-BBC1-58DDADD458D5@muada.com> <4D24A4A7.7080208@bogus.com> Message-ID: > > IPv4) I can scan your v4 subnet, let's say it's a /24, and your router > might send 250 ARP requests and may even add 250 "incomplete" entries > to its ARP table. This is not a disaster for that LAN, or any others. > No big deal. I can also intentionally send a large amount of traffic > to unused v4 IPs on the LAN, which will be handled as unknown-unicast > and sent to all hosts on the LAN via broadcasting, but many boxes > already have knobs for this, as do many switches. Not good, but also > does not affect any other interfaces on the router. > > IPv6) I can scan your v6 /64 subnet, and your router will have to send > out NDP NS for every host I scan. If it requires "incomplete" entries > in its table, I will use them all up, and NDP learning will be broken. > Typically, this breaks not just on that interface, but on the entire > router. This is much worse than the v4/ARP sitation. > Many would argue that the version of IP is irrelevant, if you are permitting external hosts the ability to scan your internal network in an unrestricted fashion (no stateful filtering or rate limiting) you have already lost, you just might not know it yet. Even granting that, for the sake of argument - it seems like it would not be hard for $vendor to have some sort of "emergency garbage collection" routines within their NDP implementations ... ? /TJ From sthaug at nethelp.no Wed Jan 5 12:09:24 2011 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Wed, 05 Jan 2011 19:09:24 +0100 (CET) Subject: NIST IPv6 document In-Reply-To: <7BA6E87C-7CAD-44DD-BBC1-58DDADD458D5@muada.com> References: <7BA6E87C-7CAD-44DD-BBC1-58DDADD458D5@muada.com> Message-ID: <20110105.190924.74661870.sthaug@nethelp.no> > All the same, beware of the anycast addresses if you want to use a smaller block for point-to-point and for LANs, you break stateless autoconfig and very likely terminally confuse DHCPv6 if your prefix length isn't /64. Breaking stateless autoconfig such that it *cannot* ever work, on my router point-to-point links, is a *feature*. Not a problem. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From jsw at inconcepts.biz Wed Jan 5 12:14:33 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Wed, 5 Jan 2011 13:14:33 -0500 Subject: NIST IPv6 document In-Reply-To: References: <20110105043548.BC01B1CC3E@ptavv.es.net> <7BA6E87C-7CAD-44DD-BBC1-58DDADD458D5@muada.com> <4D24A4A7.7080208@bogus.com> Message-ID: On Wed, Jan 5, 2011 at 1:02 PM, TJ wrote: > Many would argue that the version of IP is irrelevant, if you are permitting > external hosts the ability to scan your internal network in an unrestricted > fashion (no stateful filtering or rate limiting) you have already lost, you How do you propose to rate-limit this scanning traffic? More router knobs are needed. This also does not solve problems with malicious hosts on the LAN. A stateful firewall on every router interface has been suggested already on this thread. It is unrealistic. > Even granting that, for the sake of argument - it seems like it would not be > hard for $vendor to have some sort of "emergency garbage collection" > routines within their NDP implementations ... ? How do you propose the router know what entries are "garbage" and which are needed? Eliminating active, "good" entries to allow for more churn would make the problem much worse, not better. -- Jeff S Wheeler +1-212-981-0607 Sr Network Operator? /? Innovative Network Concepts From sethm at rollernet.us Wed Jan 5 12:23:28 2011 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 05 Jan 2011 10:23:28 -0800 Subject: NIST IPv6 document In-Reply-To: References: <20110105043548.BC01B1CC3E@ptavv.es.net> <7BA6E87C-7CAD-44DD-BBC1-58DDADD458D5@muada.com> <4D24A4A7.7080208@bogus.com> Message-ID: <4D24B720.3060906@rollernet.us> On 1/5/2011 10:02, TJ wrote: > > Many would argue that the version of IP is irrelevant, if you are permitting > external hosts the ability to scan your internal network in an unrestricted > fashion (no stateful filtering or rate limiting) you have already lost, you > just might not know it yet. > Stateful filtering introduces its own set of scaling issues. ~Seth From smb at cs.columbia.edu Wed Jan 5 14:01:42 2011 From: smb at cs.columbia.edu (Steven Bellovin) Date: Wed, 5 Jan 2011 15:01:42 -0500 Subject: sudden low spam levels? In-Reply-To: <20110103180455.GS12141@sizone.org> References: <20110103180455.GS12141@sizone.org> Message-ID: On Jan 3, 2011, at 1:04 55PM, Ken Chase wrote: > I have two independent mailservers, and two other customers that run their own > servers, all largely unrelated infrastructures and target domains, suddenly > experiencing low levels of spam. > > Total emails/day dropping from some 175,000-250,000ish to 50-75,000ish (legit > mail in the 2-5,000 per day, yes I have some high spam:legit customers...). 3 > days in a row now at least, at quick glance. > > Did someone set up them the bomb? See http://krebsonsecurity.com/2011/01/taking-stock-of-rustock/ for a discussion of recent spam level trends. --Steve Bellovin, http://www.cs.columbia.edu/~smb From leo.vegoda at icann.org Wed Jan 5 15:27:30 2011 From: leo.vegoda at icann.org (Leo Vegoda) Date: Wed, 5 Jan 2011 13:27:30 -0800 Subject: 2010 IPv4 (and IPv6) Address Use Report In-Reply-To: <49A2BD30-5F17-40FA-A862-FF8C7496DAE0@muada.com> References: <49A2BD30-5F17-40FA-A862-FF8C7496DAE0@muada.com> Message-ID: <2F0503B5-E7E4-4B91-B5FF-6D4391DC23B7@icann.org> On 4 Jan 2011, at 3:29, Iljitsch van Beijnum wrote: [...] > Note that I slightly changed the way addresses are counted: previously, all the legacy blocks that didn't have an RIR listed were assumed to be used 100%. But with the return of most of the Interop block this is no longer the case: although ARIN isn't listed as administering the 45/8 block, they actually are and only have 45.0.0.0/15 listed as in use. This changed yesterday. ARIN is now listed as the administrator for 45/8. Regards, Leo From brandon.galbraith at gmail.com Wed Jan 5 16:15:43 2011 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Wed, 5 Jan 2011 16:15:43 -0600 Subject: Clearwire/Clear for branch office connectivity? Message-ID: Is anyone using Clearwire/Clear's wireless broadband offering for stationary branch offices/remote equipment monitoring? Looking for results/experiences off-list. We're looking at it for industrial telemetry, and have spoken to people using ATT and VZW who are doing the same, but we wanted to look at Clear as well. Curious as to reliability, link performance, and support quality. Thanks! Brandon -- Brandon Galbraith US Voice: 630.492.0464 From randy at psg.com Wed Jan 5 16:32:47 2011 From: randy at psg.com (Randy Bush) Date: Thu, 06 Jan 2011 07:32:47 +0900 Subject: AltDB? In-Reply-To: <816AB912-14CF-4028-853A-F0BE77D2EB09@puck.nether.net> References: <94F3F129-608E-46EC-B157-CC23CAA47454@tozz.net> <4D24A734.3000807@jcoley.net> <816AB912-14CF-4028-853A-F0BE77D2EB09@puck.nether.net> Message-ID: > 1) If ARIN doesn't provide the level of authentication you desire, as > an ARIN member you should send a note to ppml each day until it's > available this is not address policy. this is ops. surely one does not have to dirty one's self with the ppml list to get an ops fix done in arin. it is not address policy. i have a rumor that arin is delaying and possibly not doing rpki that seems to have been announced on the ppml list (to which i do not subscribe). as it has impact on routing, not address policy, across north america and, in fact the globe, one would think it would be announced and discussed a bit more openly and widely. randy From rdobbins at arbor.net Wed Jan 5 16:44:51 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 5 Jan 2011 22:44:51 +0000 Subject: NIST IPv6 document In-Reply-To: References: <20110105043548.BC01B1CC3E@ptavv.es.net> <7BA6E87C-7CAD-44DD-BBC1-58DDADD458D5@muada.com> <4D24A4A7.7080208@bogus.com> Message-ID: <04F29819-226A-4507-8BCE-C409EC5BFB77@arbor.net> On Jan 6, 2011, at 1:02 AM, TJ wrote: > if you are permitting external hosts the ability to scan your internal network in an unrestricted > fashion DCN aside, how precisely does one define 'internal network' in, say, the context of the production network of a broadband access SP, or hosting/colocation/VPS/IaaS SP? Surely you aren't advocating wedging stateful firewalls into broadband access networks or in front of servers, with all the DoS chokepoint breakage that implies? ------------------------------------------------------------------------ Roland Dobbins // Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay From rdobbins at arbor.net Wed Jan 5 16:45:59 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 5 Jan 2011 22:45:59 +0000 Subject: NIST IPv6 document In-Reply-To: References: <20110105043548.BC01B1CC3E@ptavv.es.net> <7BA6E87C-7CAD-44DD-BBC1-58DDADD458D5@muada.com> <4D24A4A7.7080208@bogus.com> Message-ID: On Jan 6, 2011, at 1:14 AM, Jeff Wheeler wrote: > A stateful firewall on every router interface has been suggested already on this thread. It is unrealistic. It isn't just unrealistic, it's highly undesirable, since it represents an huge DoS state vector. ------------------------------------------------------------------------ Roland Dobbins // Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay From tico-nanog at raapid.net Wed Jan 5 17:18:51 2011 From: tico-nanog at raapid.net (tico) Date: Wed, 5 Jan 2011 17:18:51 -0600 Subject: Clearwire/Clear for branch office connectivity? In-Reply-To: References: Message-ID: <24897c681fd10a86fc9bbcdee8f62272.squirrel@Webmail.WZ-LLP.com> > Is anyone using Clearwire/Clear's wireless broadband offering for > stationary > branch offices/remote equipment monitoring? Looking for > results/experiences > off-list. Curious as to reliability, link performance, and support > quality. Me too! I'd love to hear from anyone that's used it extensively. > Thanks! > Brandon > > -- > Brandon Galbraith > US Voice: 630.492.0464 > From jtk at cymru.com Wed Jan 5 17:46:36 2011 From: jtk at cymru.com (John Kristoff) Date: Wed, 5 Jan 2011 17:46:36 -0600 Subject: Announcing the Community FlowSpec trial Message-ID: <20110105174636.70d11f87@t61p> Friends and colleagues, At NANOG 48 I talked about a community flow-spec service we were looking at trying to make work. This is the idea of using IETF RFC 5575 to pass around flow-based rules, in this case, primarily for dropping unwanted packets. This technology is not as widely deployed as traditional RTBH techniques for a number of reasons. However, we thought perhaps it was widely used enough, or could be, to justify what might be a helpful and free 3rd party feed of flow-spec routes to keep our networks a little bit cleaner. A trial of this feed based on the traditional bogon routes can be had by contacting me directly. We realize the traditional IPv4 reserved, special and unallocated IPv4 bogon address is dwindling. Maybe there is room for some other type of feed, but to justify that, we're looking to see if even enough people would set up this presumably simpler feed to help us and the community get some more experience with multi-hop flow-spec. Details in getting it up and running in your own test networks are here: John From drais at icantclick.org Wed Jan 5 17:58:21 2011 From: drais at icantclick.org (david raistrick) Date: Wed, 5 Jan 2011 18:58:21 -0500 (EST) Subject: Clearwire/Clear for branch office connectivity? In-Reply-To: <24897c681fd10a86fc9bbcdee8f62272.squirrel@Webmail.WZ-LLP.com> References: <24897c681fd10a86fc9bbcdee8f62272.squirrel@Webmail.WZ-LLP.com> Message-ID: On Wed, 5 Jan 2011, tico wrote: >> Is anyone using Clearwire/Clear's wireless broadband offering for > > Me too! I'd love to hear from anyone that's used it extensively. I haven't in a few years (I worked for someone who thought of themselves as a clearwire competitor), but we replaced a bunch of them that customers had, we installed a few of them with our own stickers on them, and we always kept one in the truck for those times we couldn't hit our own networks but we could hit theirs... the gear was generally solid - as long as you could get a good signal. inside datacenters, basements, and telco huts, though, were not places that good signal was often available.... -- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html From Michael.Balasko at cityofhenderson.com Wed Jan 5 18:01:35 2011 From: Michael.Balasko at cityofhenderson.com (Michael Balasko) Date: Thu, 6 Jan 2011 00:01:35 +0000 Subject: Clearwire/Clear for branch office connectivity? In-Reply-To: <24897c681fd10a86fc9bbcdee8f62272.squirrel@Webmail.WZ-LLP.com> References: <24897c681fd10a86fc9bbcdee8f62272.squirrel@Webmail.WZ-LLP.com> Message-ID: <0751AE802CBC614F9FD7D94C2D2580EB0C769A80@COHNTFS21901.ci.henderson.nv.us> My coworker has a total of 6 hours into calling each and every Clear number that is publically facing and has yet to reach a person that even understands the question. We have boiled it down to the Clear business model is designed merely to sell you the generic modem and have a nice day. There appears to be zero interest in their business model to accommodate the enterprise. I really hope I am wrong, and if someone has a number of someone willing to deal with the enterprise customer base PLEASE forward it on. Mike From nathan at atlasnetworks.us Wed Jan 5 18:14:50 2011 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Thu, 6 Jan 2011 00:14:50 +0000 Subject: Clearwire/Clear for branch office connectivity? In-Reply-To: <0751AE802CBC614F9FD7D94C2D2580EB0C769A80@COHNTFS21901.ci.henderson.nv.us> References: <24897c681fd10a86fc9bbcdee8f62272.squirrel@Webmail.WZ-LLP.com> <0751AE802CBC614F9FD7D94C2D2580EB0C769A80@COHNTFS21901.ci.henderson.nv.us> Message-ID: <8C26A4FDAE599041A13EB499117D3C286B3024E9@ex-mb-1.corp.atlasnetworks.us> > There > appears to be zero interest in their business model to accommodate the > enterprise. In my own personal experience, there appears to be zero interest in their business model to accommodate the CUSTOMER. They go on and on about how their frequency-space gives them a competitive advantage, but their network is unreliable and extremely traffic policed (try downloading something. You MIGHT get close to the advertised speed for a few seconds, but you'll spend the next 2 hours browsing at the speed of mud when the traffic policer kicks in. Do it too often, and it seems to stop de-limiting you altogether). As far as I can tell, the issue isn't on the customer-leg, it's on their backhauls and core network. Worse, their customer service is nonexistent, and their cancellation policy is a nightmare (so bad that there's a class action against them - not sure where it's at, haven't checked in a while). I have heard horror stories from their employees, their resellers, and fellow former customers. They're filing/have filed for bankruptcy. How many letters does it take to spell 'broken'? If you have a POTS line at locations where you need a connection, find someone who will sell you dialup, or get 3G service from a cell carrier (careful - 4G Sprint service is provided by Clearwire). You will, sadly, be happier. Nathan (This is my own personal opinion based on my experiences and the experiences directly related to me by others. It does not reflect solid fact or reality. My employer probably thinks my opinion is false - and it may well be.) From fifi at hax.Org Wed Jan 5 18:28:11 2011 From: fifi at hax.Org (Mike Sawicki) Date: Wed, 5 Jan 2011 19:28:11 -0500 Subject: Clearwire/Clear for branch office connectivity? In-Reply-To: References: Message-ID: <20110106002811.GA57622@hax.Org> On Wed, Jan 05, 2011 at 04:15:43PM -0600, Brandon Galbraith wrote: > Is anyone using Clearwire/Clear's wireless broadband offering for stationary > branch offices/remote equipment monitoring? Looking for results/experiences > off-list. We're looking at it for industrial telemetry, and have spoken to > people using ATT and VZW who are doing the same, but we wanted to look at > Clear as well. Curious as to reliability, link performance, and support > quality. > I replaced a 3mbps/768kbps ADSL provisioned through Qwest with Clearwire's home offering. I've been mostly satisfied from a cost/performance standpoint - for $55/mo I get a mostly equal replacement for the DSL as well as service for a second usb dongle for my laptop. I've had to go through an uncomfortable process with their support people on two occasions when their service was booting me off every 3-10 mins. Turns out somehow my home address changed in their system and they decided to treat my home modem as a traveling modem. As others have stated they seemed aloof and lacked access to more than a script and basic tools for troubleshooting. Service has been mostly reliable for me in the Seattle area. Transfer rates are sufficient. -m From ras at e-gerbil.net Wed Jan 5 18:51:10 2011 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Wed, 5 Jan 2011 18:51:10 -0600 Subject: Announcing the Community FlowSpec trial In-Reply-To: <20110105174636.70d11f87@t61p> References: <20110105174636.70d11f87@t61p> Message-ID: <20110106005110.GF38726@gerbil.cluepon.net> On Wed, Jan 05, 2011 at 05:46:36PM -0600, John Kristoff wrote: > Friends and colleagues, > > At NANOG 48 I talked about a community flow-spec service we were > looking at trying to make work. This is the idea of using IETF RFC > 5575 to pass around flow-based rules, in this case, primarily for > dropping unwanted packets. > > This technology is not as widely deployed as traditional RTBH > techniques for a number of reasons. However, we thought perhaps it > was widely used enough, or could be, to justify what might be a > helpful and free 3rd party feed of flow-spec routes to keep our > networks a little bit cleaner. > > A trial of this feed based on the traditional bogon routes can be had > by contacting me directly. We realize the traditional IPv4 reserved, > special and unallocated IPv4 bogon address is dwindling. Maybe there > is room for some other type of feed, but to justify that, we're > looking to see if even enough people would set up this presumably > simpler feed to help us and the community get some more experience > with multi-hop flow-spec. As a word of warning to anyone who wants to deploy this on their Juniper routers (what other router vendors support it? :P), there are some pretty serious performance considerations of which you should be aware. For example, we discovered that on MX routers (with classic I-chip DPCs, the performance should be somewhat better for Trio cards but we haven't fully tested the exact numbers yet), installing as few as a dozen flowspec routes can create firewall filters that use enough SRAM accesses that you will no longer be able to achieve line rate packets/sec. With a few more rules, you may find that your 10GE's will only be able to handle 3-5Mpps instead of the normal 14.8Mpps. When this happens, excess traffic above what the firewall filters can handle will be silently discarded, with no indicaton in SNMP or "show interface" that you're dropping packets (though you may be able to see it in "show pfe statistics traffic" as Info cell drops). I can't tell you what the performance numbers are for other platforms, but anyone thinking about turning on flowspec from a third party source (especially one who may be sending them a large number of rules) should give serious consideration to the potential impact on their network first. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From jgreco at ns.sol.net Wed Jan 5 19:57:28 2011 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 5 Jan 2011 19:57:28 -0600 (CST) Subject: NIST IPv6 document In-Reply-To: <4D24A4A7.7080208@bogus.com> Message-ID: <201101060157.p061vSVd085026@aurora.sol.net> > > This is a much smaller issue with IPv4 ARP, because routers generally > > have very generous hardware ARP tables in comparison to the typical > > size of an IPv4 subnet. > > no it isn't, if you've ever had your juniper router become unavailable > because the arp policer caused it to start ignoring updates, or seen > systems become unavailable due to an arp storm you'd know that you can > abuse arp on a rather small subnet. It may also be worth noting that "typical size of an IPv4 subnet" is a bit of a red herring; a v4 router that's responsible for /16 of directly attached /24's is still able to run into some serious issues. What's more important is the rate at which scanning can occur, which is largely a function of (for a remote attacker) speed of connection to an upstream; this problem is getting worse. A practical lesson is the so-called "Kaminsky DNS vulnerability" (which Kaminsky didn't actually discover - This issue was known back around 2000, at least, but at the time was deemed impractical to exploit due to bandwidth and processing limitations). We do need to be aware that continued increases in the available resources will change the viability of attacks in the future. The switch from IPv4 to IPv6 itself is such a change; it renders random trolling through IP space much less productive. We should not lose sight of the fact that this is generally a very positive feature; calls for packing IPv6 space more tightly serve merely to marginalize that win. We should be figuring out ways to make /64's work optimally, because in ten years everyone's going to have gigabit Internet links and we're going to need all the tricks we can muster to make an attacker's job harder. ... 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 rdobbins at arbor.net Wed Jan 5 20:16:18 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 6 Jan 2011 02:16:18 +0000 Subject: NIST IPv6 document In-Reply-To: <201101060157.p061vSVd085026@aurora.sol.net> References: <201101060157.p061vSVd085026@aurora.sol.net> Message-ID: On Jan 6, 2011, at 8:57 AM, Joe Greco wrote: > The switch from IPv4 to IPv6 itself is such a change; it renders random trolling through IP space much less productive. And renders hinted trolling far more productive/necessary, invariably leading to increased strain on already-brittle/-overloaded DNS, whois, route servers, et. al., not to mention ND/multicast abuse. > We should not lose sight of the fact that this is generally a very positive feature; calls for packing IPv6 space more tightly serve merely to marginalize that win. Far from being a 'win', I believe it's either neutral or a net negative, due to the above implications. If we're looking at a near-future world filled with spimes, where every molecule in every nanomanufactured soda can has its own IPv6 address it uses to communicate via NFC or ZigBee or whatever during the assembly/recycling process, unnecessarily wasting IPv6 space isn't an optimal strategy. The alleged security benefits of sparse IPv6 addressing plans are a canard, IMHO. > We should be figuring out ways to make /64's work optimally, because in ten years everyone's going to have gigabit Internet links and we're > going to need all the tricks we can muster to make an attacker's job harder. These are diametrically-opposed, mutually-exclusive goals, IMHO. All in all, IPv6 is a net security negative. It has all the same problems of IPv4, plus new, IPv6-specific problems - *in hex*. ------------------------------------------------------------------------ Roland Dobbins // Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay From ml at kenweb.org Wed Jan 5 20:38:23 2011 From: ml at kenweb.org (ML) Date: Wed, 05 Jan 2011 21:38:23 -0500 Subject: Problems with removing NAT from a network Message-ID: <4D252B1F.8030506@kenweb.org> I've got a customer that is looking to multihome with upstreams in two POPs. Currently they multihome in one POP and utilize a single edge router for some one to one NAT and some PAT for their users. Before they turn up the BGP peer in the new POP I've advised them to abolish NAT once and for all in order to avoid issues with non-stateful NAT between network edges and possible asymmetric routing of their Internet traffic. The PAT can be removed easily enough. The tricky part is the one-one NAT. They have quite a few systems which have 1918 IPs which they claim "cannot be changed". At least not without some painful rebuilds of criticals systems which have these IPs deeply embedded in their configs. Has anyone here had to fix this kind of problem before? Is there a solution that would allow NAT to offloaded to a smaller device hanging off each edge router that can communicate state between each other in case traffic is asymmetrically routed? From rdobbins at arbor.net Wed Jan 5 20:42:20 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 6 Jan 2011 02:42:20 +0000 Subject: Problems with removing NAT from a network In-Reply-To: <4D252B1F.8030506@kenweb.org> References: <4D252B1F.8030506@kenweb.org> Message-ID: <3DFD6833-78C1-43D2-8074-6C89CFE3F2F3@arbor.net> On Jan 6, 2011, at 9:38 AM, ML wrote: > At least not without some painful rebuilds of criticals systems which have these IPs deeply embedded in their configs. They shouldn't be using IP addresses in configs, they should be using DNS names. Time to bite the bullet and get this fixed prior to their eventual forced migration to IPv6. ------------------------------------------------------------------------ Roland Dobbins // Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay From jsw at inconcepts.biz Wed Jan 5 20:45:12 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Wed, 5 Jan 2011 21:45:12 -0500 Subject: NIST IPv6 document In-Reply-To: <201101060157.p061vSVd085026@aurora.sol.net> References: <4D24A4A7.7080208@bogus.com> <201101060157.p061vSVd085026@aurora.sol.net> Message-ID: On Wed, Jan 5, 2011 at 8:57 PM, Joe Greco wrote: >> > This is a much smaller issue with IPv4 ARP, because routers generally >> > have very generous hardware ARP tables in comparison to the typical >> > size of an IPv4 subnet. >> >> no it isn't, if you've ever had your juniper router become unavailable >> because the arp policer caused it to start ignoring updates, or seen >> systems become unavailable due to an arp storm you'd know that you can >> abuse arp on a rather small subnet. > > It may also be worth noting that "typical size of an IPv4 subnet" is > a bit of a red herring; a v4 router that's responsible for /16 of > directly attached /24's is still able to run into some serious issues. It is uncommon for publicly-addressed LANs to be this large. The reason is simple: relatively few sites still have such an excess of IPv4 addresses that they can use them in such a sparsely-populated manner. Those that do have had twenty years of operational experience with generation after generation of hardware and software, and they have had every opportunity to fully understand the problem (or redesign the relevant portion of their network.) In addition, there is not (any longer) a "standard," and a group of mindless zealots, telling the world that at /16 on your LAN is the only right way to do it. This is, in fact, the case with IPv6 deployments, and will drive what customers demand. To understand the problem, you must first realize that myopic standards-bodies have created it, and either the standards must change, operators must explain to their customers why they are not following the standards, or equipment vendors must provide additional knobs to provide a mitigation mechanism that is an acceptable compromise. Do the advantages of sparse subnets out-weigh the known security detriments, even if good compromise-mechanisms are provided by equipment vendors? "Security by obscurity" is an oft-touted advantage of IPv6 sparse subnets. We all know that anyone with a paypal account can buy a list of a few hundred million email addresses for next to nothing. How long until that is the case with lists of recently-active IPv6 hosts? What portion of attack vectors really depend on scanning hosts that aren't easily found in the DNS, as opposed to vectors depending on a browser click, email attachment, or by simply hammering away at "www.*.com" with common PHP script vulnerabilities? How many people think that massively-sparse-subnets are going to save them money? Where will these cost-efficiencies come from? Why can't you gain that advantage by provisioning, say, 10 times as large a subnet as you think you need, instead of seventy-quadrillion times as large? Is anyone really going to put their Windows Updates off and save money because they are comfortable that their hosts can't be found by random scanning? Is stateless auto-configuration that big a win vs DHCP? Yes, I should have participated in the process in the 1990s. However, just because the bed is already made doesn't mean I am willing to lay my customers in it. These problems can still be fixed before IPv6 is ubiquitous and mission-critical. The easiest fix is to reset the /64 mentality which standards-zealots are clinging to. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From michael at hmsjr.com Wed Jan 5 20:51:23 2011 From: michael at hmsjr.com (Michael Smith) Date: Wed, 5 Jan 2011 21:51:23 -0500 Subject: Problems with removing NAT from a network In-Reply-To: <4D252B1F.8030506@kenweb.org> References: <4D252B1F.8030506@kenweb.org> Message-ID: The devil's in the details (obviously), and someone that reads into the scenario better than me might have a more direct suggestion, but... I'd start by moving the NAT at least one hop into the AS so that routing symmetry can be enforced there. This allows for multi-homing (asymmetric routing at the edge) without (before) dealing with the NAT issue (if there is one at that point). On Jan 5, 2011 9:39 PM, "ML" wrote: I've got a customer that is looking to multihome with upstreams in two POPs. Currently they multihome in one POP and utilize a single edge router for some one to one NAT and some PAT for their users. Before they turn up the BGP peer in the new POP I've advised them to abolish NAT once and for all in order to avoid issues with non-stateful NAT between network edges and possible asymmetric routing of their Internet traffic. The PAT can be removed easily enough. The tricky part is the one-one NAT. They have quite a few systems which have 1918 IPs which they claim "cannot be changed". At least not without some painful rebuilds of criticals systems which have these IPs deeply embedded in their configs. Has anyone here had to fix this kind of problem before? Is there a solution that would allow NAT to offloaded to a smaller device hanging off each edge router that can communicate state between each other in case traffic is asymmetrically routed? From lists at beatmixed.com Wed Jan 5 21:08:51 2011 From: lists at beatmixed.com (Matt Hite) Date: Wed, 5 Jan 2011 19:08:51 -0800 Subject: Problems with removing NAT from a network In-Reply-To: <4D252B1F.8030506@kenweb.org> References: <4D252B1F.8030506@kenweb.org> Message-ID: You didn't mention, but are you introducing a second border router? Is the new upstream circuit from a new provider, or is it a second, redundant circuit to the same provider in a different POP? Does your customer have their own portable address space, or are they using provider address space? I'll make some presumptions: yes, it is a different provider, and no, they don't have their own address space. Based on those guesses/presumptions, I'd push to acquire portable address space. Advertise it to both providers, carve a chunk of that address space off and route it to a firewall(s) to perform border NAT. Migrate old, provider dependent external NAT space to new, portable address space. -M On Wed, Jan 5, 2011 at 6:38 PM, ML wrote: > I've got a customer that is looking to multihome with upstreams in two POPs. > ?Currently they multihome in one POP and utilize a single edge router for > some one to one NAT and some PAT for their users. > > Before they turn up the BGP peer in the new POP I've advised them to abolish > NAT once and for all in order to avoid issues with non-stateful NAT between > network edges and possible asymmetric routing of their Internet traffic. > > The PAT can be removed easily enough. ?The tricky part is the one-one NAT. > They have quite a few systems which have 1918 IPs which they claim "cannot > be changed". At least not without some painful rebuilds of criticals systems > which have these IPs deeply embedded in their configs. > > Has anyone here had to fix this kind of problem before? Is there a solution > that would allow NAT to offloaded to a smaller device hanging off each edge > router that can communicate state between each other in case traffic is > asymmetrically routed? > > From jgreco at ns.sol.net Wed Jan 5 21:08:58 2011 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 5 Jan 2011 21:08:58 -0600 (CST) Subject: NIST IPv6 document In-Reply-To: Message-ID: <201101060308.p0638wha085757@aurora.sol.net> > > The switch from IPv4 to IPv6 itself is such a change; it renders random t= > rolling through IP space much less productive. > > And renders hinted trolling far more productive/necessary, invariably leadi= > ng to increased strain on already-brittle/-overloaded DNS, whois, route ser= > vers, et. al., not to mention ND/multicast abuse. Of course, you *want* them attacking the lower layers, you don't want them attacking the more easily defended higher layers... got an investment in Cisco stock there? :-) But seriously, if your solution is to eliminate sparseness, then you've also just make attacking networks a whole lot easier. > > We should not lose sight of the fact that this is generally a very positi= > ve feature; calls for packing IPv6 space more tightly serve merely to margi= > nalize that win. > > > Far from being a 'win', I believe it's either neutral or a net negative, du= > e to the above implications. Then you need to re-evaluate; I'd much prefer having to protect resources like DNS servers. With a DNS server, I can monitor access trends, or set off excessive query alarms, and I can even write the code to do all that without having to create custom silicon to implement it. One can only imagine how frustrating a $GENERATE must be to a PTR-scanner. Why do we have to repeat all the mistakes of IPv4 in v6? Packing everything densely is an obvious problem with IPv4; we learned early on that having a 48-bit (32 address, 16 port) space to scan made port-scanning easy, attractive, productive, and commonplace. If there are operational problems with IPv6, now's a great time to figure them out and figure out how to make it work well. Re-engineering the protocol at this late hour is unlikely to be productive; it took many years to get IPv6 into the state it is, and if we are going to go and change it all because you don't like sparseness, will it be ready to deploy before 2020? ... 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 rdobbins at arbor.net Wed Jan 5 21:18:52 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 6 Jan 2011 03:18:52 +0000 Subject: NIST IPv6 document In-Reply-To: <201101060308.p0638wha085757@aurora.sol.net> References: <201101060308.p0638wha085757@aurora.sol.net> Message-ID: <8469431D-AD95-4B75-9CDC-9C0176ED8CF9@arbor.net> On Jan 6, 2011, at 10:08 AM, Joe Greco wrote: > Packing everything densely is an obvious problem with IPv4; we learned early on that having a 48-bit (32 address, 16 port) space to scan made > port-scanning easy, attractive, productive, and commonplace. I don't believe that host-/port-scanning is as serious a problem as you seem to think it is, nor do I think that trying to somehow prevent host from being host-/port-scanned has any material benefit in terms of security posture, that's our fundamental disagreement. If I've done what's necessary to secure my hosts/applications, host-/port-scanning isn't going to find anything to exploit (overly-aggressive scanning can be a DoS vector, but there are ways to ameliorate that, too). If I haven't done what's necessary to secure my hosts/applications, one way or another, they *will* end up being exploited - and the faux security-by-obscurity offered by sparse addressing won't matter a bit. This whole focus on sparse addressing is just another way to tout security-by-obscurity. We already know that security-by-obscurity is a fundamentally-flawed concept, so it doesn't make sense to try and keep rationalizing it in various domain-specific instantiations. ------------------------------------------------------------------------ Roland Dobbins // Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay From jgreco at ns.sol.net Wed Jan 5 21:27:14 2011 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 5 Jan 2011 21:27:14 -0600 (CST) Subject: NIST IPv6 document In-Reply-To: Message-ID: <201101060327.p063REnl086015@aurora.sol.net> > > On Wed, Jan 5, 2011 at 8:57 PM, Joe Greco wrote: > >> > This is a much smaller issue with IPv4 ARP, because routers generally > >> > have very generous hardware ARP tables in comparison to the typical > >> > size of an IPv4 subnet. > >> > >> no it isn't, if you've ever had your juniper router become unavailable > >> because the arp policer caused it to start ignoring updates, or seen > >> systems become unavailable due to an arp storm you'd know that you can > >> abuse arp on a rather small subnet. > > > > It may also be worth noting that "typical size of an IPv4 subnet" is > > a bit of a red herring; a v4 router that's responsible for /16 of > > directly attached /24's is still able to run into some serious issues. > > It is uncommon for publicly-addressed LANs to be this large. The > reason is simple: relatively few sites still have such an excess of > IPv4 addresses that they can use them in such a sparsely-populated > manner. Who said anything about sparsely populated? A typical hosting provider might well fit such a general picture. > Those that do have had twenty years of operational experience > with generation after generation of hardware and software, and they > have had every opportunity to fully understand the problem (or > redesign the relevant portion of their network.) No they haven't. I can think of relatively few networks that have survived twenty years, and the ones that I can think of are mostly .edu. Those of us who have been operating IP networks for that length of time probably see both the flaws in IPv4 and IPv6. > In addition, there is not (any longer) a "standard," and a group of > mindless zealots, telling the world that at /16 on your LAN is the > only right way to do it. This is, in fact, the case with IPv6 > deployments, and will drive what customers demand. The concepts behind IPv4 classful addressing were flawed, but not unrealistic given the history. Various pressures existed to force the development of CIDR. It's not clear that those same pressures will force IPv6 to develop smaller networks - but other pressures *might*. I've yet to hear convincing reasons as to why they *should*. > To understand the problem, you must first realize that myopic > standards-bodies have created it, and either the standards must > change, operators must explain to their customers why they are not > following the standards, or equipment vendors must provide additional > knobs to provide a mitigation mechanism that is an acceptable > compromise. Do the advantages of sparse subnets out-weigh the known > security detriments, even if good compromise-mechanisms are provided > by equipment vendors? Quite frankly, as an interested party, I've been following all this for many years, and I am having a little trouble figuring out what you mean by the "known security detriments" in this context. > "Security by obscurity" is an oft-touted advantage of IPv6 sparse > subnets. We all know that anyone with a paypal account can buy a list > of a few hundred million email addresses for next to nothing. How > long until that is the case with lists of recently-active IPv6 hosts? Personally, I expect to see IPv6 privacy extensions become commonly used; it's a fairly comprehensive answer to that issue. > What portion of attack vectors really depend on scanning hosts that > aren't easily found in the DNS, as opposed to vectors depending on a > browser click, email attachment, or by simply hammering away at > "www.*.com" with common PHP script vulnerabilities? I see people scanning our IP space *all* *the* *time*. > How many people think that massively-sparse-subnets are going to save > them money? If it saves me from creeps trawling through our IP space, that's a savings. > Where will these cost-efficiencies come from? Why can't > you gain that advantage by provisioning, say, 10 times as large a > subnet as you think you need, instead of seventy-quadrillion times as > large? Because at ten times as large, they can still trawl. > Is anyone really going to put their Windows Updates off and > save money because they are comfortable that their hosts can't be > found by random scanning? Is stateless auto-configuration that big a > win vs DHCP? > > Yes, I should have participated in the process in the 1990s. However, > just because the bed is already made doesn't mean I am willing to lay > my customers in it. These problems can still be fixed before IPv6 is > ubiquitous and mission-critical. The easiest fix is to reset the /64 > mentality which standards-zealots are clinging to. Think you missed that particular boat a long time ago. The next ship will be departing in a hundred years or so, advance registration for the IPv7 design committee are available over there. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From gbonser at seven.com Wed Jan 5 21:42:25 2011 From: gbonser at seven.com (George Bonser) Date: Wed, 5 Jan 2011 19:42:25 -0800 Subject: NIST IPv6 document In-Reply-To: <8469431D-AD95-4B75-9CDC-9C0176ED8CF9@arbor.net> References: <201101060308.p0638wha085757@aurora.sol.net> <8469431D-AD95-4B75-9CDC-9C0176ED8CF9@arbor.net> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC1321C@RWC-EX1.corp.seven.com> > From: Dobbins, Roland > Sent: Wednesday, January 05, 2011 7:19 PM > To: Nanog Operators' Group > Subject: Re: NIST IPv6 document > > > On Jan 6, 2011, at 10:08 AM, Joe Greco wrote: > > I don't believe that host-/port-scanning is as serious a problem as you > seem to think it is, nor do I think that trying to somehow prevent host > from being host-/port-scanned has any material benefit in terms of > security posture, that's our fundamental disagreement. It will be a problem if people learn they can DoS routers by doing it by maxing out the neighbor table. > If I've done what's necessary to secure my hosts/applications, host- > /port-scanning isn't going to find anything to exploit (overly- > aggressive scanning can be a DoS vector, but there are ways to > ameliorate that, too). I don't think you are understanding the problem. The problem comes from addressing hosts that don't even exist. This causes the router to attempt to find that host. The v6 equivalent of ARP. At some point that table becomes full of entries for hosts that don't exist so there isn't room for hosts that do exist. > This whole focus on sparse addressing is just another way to tout > security-by-obscurity. We already know that security-by-obscurity is a > fundamentally-flawed concept, so it doesn't make sense to try and keep > rationalizing it in various domain-specific instantiations. No, it was designed to accommodate EUI-64 addresses which are to replace MAC-48 addresses at layer2. We currently create an EUI-64 address out of a MAC-48 in many cases during SLAAC but at some point the interfaces will be shipping with EUI-64 addresses. The world is running out of MAC-48 addresses. So at some point the "MAC" address will be the host address and it will be 64-bits long. It has nothing to do with "security by obscurity". From rdobbins at arbor.net Wed Jan 5 21:52:09 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 6 Jan 2011 03:52:09 +0000 Subject: NIST IPv6 document In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC1321C@RWC-EX1.corp.seven.com> References: <201101060308.p0638wha085757@aurora.sol.net> <8469431D-AD95-4B75-9CDC-9C0176ED8CF9@arbor.net> <5A6D953473350C4B9995546AFE9939EE0BC1321C@RWC-EX1.corp.seven.com> Message-ID: On Jan 6, 2011, at 10:42 AM, George Bonser wrote: > It will be a problem if people learn they can DoS routers by doing it by maxing out the neighbor table. I understand this - that's a completely separate issue from the supposed benefits of sparse addressing for endpoint host security. > I don't think you are understanding the problem. I've understood the problem for years, thanks, and have commented on it in other portions of this thread, as well as in may earlier threads around this general set of issues - and it's completely orthogonal to this particular discussion. Or are you saying that you think that the miscreants will simply and contritely abandon host-/port-scanning as a) a host-discovery mechanism and b) as a DoS mechanism if everyone magically adopts sparse addressing? Somehow, I don't think that's very likely. ;> Also, see my previous comments in re the negative implications of hinted scanning. > It has nothing to do with "security by obscurity". You may wish to re-read what Joe was saying - he was positing sparse addressing as a positive good because it will supposedly make it more difficult for attackers to locate endpoints in the first place, i.e., security through obscurity. I think that's an invalid argument. ------------------------------------------------------------------------ Roland Dobbins // Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay From jra at baylink.com Wed Jan 5 21:53:10 2011 From: jra at baylink.com (Jay Ashworth) Date: Wed, 5 Jan 2011 22:53:10 -0500 (EST) Subject: reporting physical plant damage to AT&T? In-Reply-To: <0319E7F7-5BDE-4F4A-B858-6A028C7F3051@netconsonance.com> Message-ID: <7236599.4876.1294285990612.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jo Rhett" > On Nov 25, 2010, at 2:11 PM, Kevin Oberman wrote: > > Have you tried 611 (from an AT&T land-line phone)? > > Many people don't have one. I haven't had one for over 12 years now, > nor have any of my employers for the last 8 years. For what its worth, I *have* tried reporting outside plant damage in GTE FL to Verizon; it's impossible to find anyone who has any clue WTF you're talking about. I call my ex-boss's son, who works there, and ask him to pass it along to his dispatcher as something *he's* seen. Cheers, -- jr 'I realize this doesn't scale' a From morrowc.lists at gmail.com Wed Jan 5 22:06:34 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 5 Jan 2011 23:06:34 -0500 Subject: ARIN and the RPKI (was Re: AltDB?) Message-ID: Sorry for the subject change, it seems now we're talking about something perhaps more relevant to me (security and routing stuff) On Wed, Jan 5, 2011 at 5:32 PM, Randy Bush wrote: > i have a rumor that arin is delaying and possibly not doing rpki that > seems to have been announced on the ppml list (to which i do not I have heard this as well ... the message in the archive is: (arin-announce actually, not ppml) Essentially the note says that Kosters & crew are delaying until Q2-2011 the deployment of RPKI services (nebulous 'other features need to be implemented due to security concerns' is the stated reason) > subscribe). ?as it has impact on routing, not address policy, across > north america and, in fact the globe, one would think it would be > announced and discussed a bit more openly and widely. I agree... so, what is the RPKI for and why should ops/security folks care? (and should we care enough to poke our local ARIN constabulary in the eye with a sharp stick?) I'm of the belief that if we (ops/security folks) feel the need to have a more secure routing infrastructure so we can hope to avoid incidents like: (quick examples, there are many others like these) o AS7007 full-table re-announce + re-originate o ConEdison "hijack" + re-originate o Pakistan/YT hijack + re-originate o "Pilosov/Kapela" hijacks/manipulations o Christmas TurkTelecom leak/hijack o PRC network leakages/hijacks/etc of April 2010 (Note: let's not debate if the above incidents are one/the-other hijack/mistake/etc, the simple fact is traffic was diverted and some better filtering/control would have avoided these failures in our system) We need at least these things to exist: o an accurate mapping of resource (netblock/asn) to authorized-entity (RIR/NIR/LIR/Customer/...) o a system to manage this data for our routing equipment o protocol enhancements that can be used to help propagate the mapping information or at the least help a router programmaticly understand if a resource is being used by the authorized entity o routing software that can digest the enhanced data o routing hardware that won't crumple under the weight of (what seems like) heavier weight routing protocol requirements I believe the lynch-pin in this is the accurate mapping of resources to authorized users, I believe that is supposed to be the RPKI system. I believe that the RPKI will tell me, an end-operator, that 63.0.0.0/9 was handed from IANA to ARIN to UUNET/VerizonBusiness and that this is being properly announced with an Origin-AS of 701. Having the service run by these organizations seems reasonable to me... IANA signs down to the RIR (ARIN in my example) and ARIN signs to VZB who can choose to sign down to their customers if necessary. Today there is a very loose, in all regions not just ARIN's, association with lots of cruft and inaccuracies. The RPKI, operated by RIR's, would provide some solid linkage and authority between resources and owners, it should help to enforce cruft management as well as provide mechanical (and relatively simple) management of the data and associated filtering/etc on devices. There is, of course, some risk with this model and we should take the time to accept/discuss that as well. Danny has had lots of good input on this topic, I'd hope that other folks who've been through longer term ops battles with filtering (jared, shane, charles gucker, rs, ras, ...) and the like can take some time to think about this problem. I'd love it if we could have some reasoned discussion here as well. Finally, everyone should go poke their ARIN corporate representative(s) (or email the BoT or AC folks directly even?) with their thoughts on whether or not the RPKI system and Routing Security are important items for ARIN (as one RIR) to pursue for the health of the Internet and Ops Sanity. The BoT folks are listed at: (with email addresses even!) The AC folks are listed at: -Chris From cb.list6 at gmail.com Wed Jan 5 22:09:08 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Wed, 5 Jan 2011 20:09:08 -0800 Subject: Problems with removing NAT from a network In-Reply-To: <3DFD6833-78C1-43D2-8074-6C89CFE3F2F3@arbor.net> References: <4D252B1F.8030506@kenweb.org> <3DFD6833-78C1-43D2-8074-6C89CFE3F2F3@arbor.net> Message-ID: On Wed, Jan 5, 2011 at 6:42 PM, Dobbins, Roland wrote: > > On Jan 6, 2011, at 9:38 AM, ML wrote: > >> At least not without some painful rebuilds of criticals systems which have these IPs deeply embedded in their configs. > > They shouldn't be using IP addresses in configs, they should be using DNS names. ?Time to bite the bullet and get this fixed prior to their eventual forced migration to IPv6. > Somebody should tell the nytimes.com about this being a bad practice, many of their images are linked to ip addresses directly and will certainly fail in the future (this year, mobile) networks that will use NAT64/DNS64. I am sure users will find other places to view their news when nytimes.com fails to work in these ipv6-only networks. Small summary of the problem of IPv4 literals and how they will break in certain IPv6 environments that will be deployed this year http://groups.google.com/group/ipv4literals Cameron ========= http://groups.google.com/group/tmoipv6beta ========= > ------------------------------------------------------------------------ > Roland Dobbins // > > Most software today is very much like an Egyptian pyramid, with millions > of bricks piled on top of each other, with no structural integrity, but > just done by brute force and thousands of slaves. > > ? ? ? ? ? ? ? ? ? ? ? ? ?-- Alan Kay > > > From randy at psg.com Wed Jan 5 22:16:27 2011 From: randy at psg.com (Randy Bush) Date: Thu, 06 Jan 2011 13:16:27 +0900 Subject: ARIN and the RPKI (was Re: AltDB?) In-Reply-To: References: Message-ID: > We need at least these things to exist: > o an accurate mapping of resource (netblock/asn) to > authorized-entity (RIR/NIR/LIR/Customer/...) > o a system to manage this data for our routing equipment see all the sidr documents in last call to go from i-ds to rfcs. oh, you co-chair sidr :) > o protocol enhancements that can be used to help propagate the > mapping information or at the least help a router programmaticly > understand if a resource is being used by the authorized entity see draft-ietf-sidr-rpki-rtr-07 > o routing software that can digest the enhanced data in test. rumors of going normal release from at least one vendor in q2 > o routing hardware that won't crumple under the weight of (what > seems like) heavier weight routing protocol requirements actually, the formal rpki-based origin-validation stuff is measured to take *less* cpu, a lot less, than ACLs > There is, of course, some risk with this model and we should take the > time to accept/discuss that as well. some guidance toward ameliorating the risks are in . input from ops into all this stuff would be most welcome. randy From gbonser at seven.com Wed Jan 5 22:16:54 2011 From: gbonser at seven.com (George Bonser) Date: Wed, 5 Jan 2011 20:16:54 -0800 Subject: NIST IPv6 document In-Reply-To: References: <201101060308.p0638wha085757@aurora.sol.net><8469431D-AD95-4B75-9CDC-9C0176ED8CF9@arbor.net><5A6D953473350C4B9995546AFE9939EE0BC1321C@RWC-EX1.corp.seven.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC1321E@RWC-EX1.corp.seven.com> > > I've understood the problem for years, thanks, and have commented on it > in other portions of this thread, as well as in may earlier threads > around this general set of issues - and it's completely orthogonal to > this particular discussion. I suppose what confused me was this: " I don't believe that host-/port-scanning is as serious a problem as you seem to think it is, nor do I think that trying to somehow prevent host from being host-/port-scanned has any material benefit in terms of security posture, that's our fundamental disagreement. If I've done what's necessary to secure my hosts/applications, host-/port-scanning isn't going to find anything to exploit (overly-aggressive scanning can be a DoS vector, but there are ways to ameliorate that, too). " I thought the entire notion of actually getting to a host was orthogonal to the discussion as that wasn't the point. It wasn't about exploitation of anything on the host, the discussion was about the act of scanning a network itself being the problem. If network devices can be degraded simply by scanning the network, it is going to become *very* commonplace. But the sets of problems are different for an end user network vs. a service provider network. For a transit link you might disable ND and configure static neighbors which would inoculate that link from such a neighbor table exhaustion attack. For an end network, the problems are different. From jeff-kell at utc.edu Wed Jan 5 22:21:57 2011 From: jeff-kell at utc.edu (Jeff Kell) Date: Wed, 05 Jan 2011 23:21:57 -0500 Subject: NIST IPv6 document In-Reply-To: <8469431D-AD95-4B75-9CDC-9C0176ED8CF9@arbor.net> References: <201101060308.p0638wha085757@aurora.sol.net> <8469431D-AD95-4B75-9CDC-9C0176ED8CF9@arbor.net> Message-ID: <4D254365.2050806@utc.edu> On 1/5/2011 10:18 PM, Dobbins, Roland wrote: > This whole focus on sparse addressing is just another way to tout security-by-obscurity. We already know that security-by-obscurity is a fundamentally-flawed concept, so it doesn't make sense to try and keep rationalizing it in various domain-specific instantiations. I agree. It's not the hosts I'm worried about protecting, it's the potential noise directed at the IPv6 space, intentional/irrational scan or otherwise generated traffic. Still, the idea that "nobody will scan a /64" reminds me of the days when 640K ought to be enough for anybody, 56-bit DES ought to be good enough to never be cracked, 10 megabits was astoundingly fast, a T1 was more than enough commodity, and a 300-baud acoustic coupler was a modern marvel. I hesitate to write anything off to impossibility, having witnessed the 8 to 16 to 32 to 64-bit processor progression :) But perhaps it's time for Moore to rest and we can make assumptions about that impossibility. Scanned or not, IPv6 still presents a "very large" route target. Given the transient / spoofed / backscatter / garbage / scan / script kiddie noise that accidentally lands in my IPv4 space, I shudder to think of the noise level of the many-orders-of-magnitude-greater IPv6 space. And the "depth" of infrastructure at which you can decide the traffic is bogus is much greater with IPv6. Most will end up on the target network anyway, no? Jeff From morrowc.lists at gmail.com Wed Jan 5 22:23:02 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 5 Jan 2011 23:23:02 -0500 Subject: ARIN and the RPKI (was Re: AltDB?) In-Reply-To: References: Message-ID: On Wed, Jan 5, 2011 at 11:16 PM, Randy Bush wrote: >> We need at least these things to exist: >> ? o an accurate mapping of resource (netblock/asn) to >> ? ? authorized-entity (RIR/NIR/LIR/Customer/...) >> ? o a system to manage this data for our routing equipment > > see all the sidr documents in last call to go from i-ds to rfcs. ?oh, > you co-chair sidr :) yes, sorry I should have been more open ... i do co-chair (with sandy murphy) the sidr-wg at the IETF. > >> ? o protocol enhancements that can be used to help propagate the >> ? ? mapping information or at the least help a router programmaticly >> ? ? understand if a resource is being used by the authorized entity > > see draft-ietf-sidr-rpki-rtr-07 > >> ? o routing software that can digest the enhanced data > > in test. ?rumors of going normal release from at least one vendor in q2 > >> ? o routing hardware that won't crumple under the weight of (what >> ? ? seems like) heavier weight routing protocol requirements > > actually, the formal rpki-based origin-validation stuff is measured to > take *less* cpu, a lot less, than ACLs CPU + RAM both parts of the vector matter. (but you knew this) Some of the interesting data would, I think, be good for ops folks to see more openly, things that may actually affect their purchasing and design decisions even! Danny's had some good presentation material about changes in spec/implementations that have altered drastically the update load on devices in actual networks. >> There is, of course, some risk with this model and we should take the >> time to accept/discuss that as well. > > some guidance toward ameliorating the risks are in > . > > input from ops into all this stuff would be most welcome. yes (as the co-chair) yes (as the OP... more input/thought/discussion) and looking at the: it looks like the BoT is due to have a meeting either this week or next? (they seem to always have one in the first week or two of the year?) so again speak up here AND perhaps send a note the BoT or your ARIN Rep's way "now". -Chris From morrowc.lists at gmail.com Wed Jan 5 22:26:21 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 5 Jan 2011 23:26:21 -0500 Subject: Announcing the Community FlowSpec trial In-Reply-To: <20110106005110.GF38726@gerbil.cluepon.net> References: <20110105174636.70d11f87@t61p> <20110106005110.GF38726@gerbil.cluepon.net> Message-ID: On Wed, Jan 5, 2011 at 7:51 PM, Richard A Steenbergen wrote: > On Wed, Jan 05, 2011 at 05:46:36PM -0600, John Kristoff wrote: >> Friends and colleagues, >> >> At NANOG 48 I talked about a community flow-spec service we were >> looking at trying to make work. ?This is the idea of using IETF RFC >> 5575 to pass around flow-based rules, in this case, primarily for >> dropping unwanted packets. > As a word of warning to anyone who wants to deploy this on their Juniper > routers (what other router vendors support it? :P), there are some > pretty serious performance considerations of which you should be aware. > > For example, we discovered that on MX routers (with classic I-chip DPCs, > the performance should be somewhat better for Trio cards but we haven't > fully tested the exact numbers yet), installing as few as a dozen > flowspec routes can create firewall filters that use enough SRAM 'as few as a dozen' - of things like: (forgive the hackery into cisco-ese) deny ip 127.0.0.0 0.255.255.255 any permit ip any any or with port/protocol/flags/sizes/etc ? (can you provide some examples of your dozen-or-so - give folk a starting point in their testing) -chris From rdobbins at arbor.net Wed Jan 5 22:26:12 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 6 Jan 2011 04:26:12 +0000 Subject: NIST IPv6 document In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC1321E@RWC-EX1.corp.seven.com> References: <201101060308.p0638wha085757@aurora.sol.net><8469431D-AD95-4B75-9CDC-9C0176ED8CF9@arbor.net><5A6D953473350C4B9995546AFE9939EE0BC1321C@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1321E@RWC-EX1.corp.seven.com> Message-ID: On Jan 6, 2011, at 11:16 AM, George Bonser wrote: > I thought the entire notion of actually getting to a host was orthogonal to the discussion as that wasn't the point. It wasn't about > exploitation of anything on the host, the discussion was about the act of scanning a network itself being the problem. That's a separate sub-thread. Joe was specifically talking about sparse addressing as a way to keep the attackers from finding end-hosts. My view is that a) nothing will keep the attackers from finding the end-hosts, b) they'll scan, anyways, c) they'd do hinted scanning (DNS/whois/routing tables) which will have its own negative second-order effects, and therefore c) the scanning issue in terms of endpoint security is a red herring. > If network devices can be degraded simply by scanning the network, it is going to become *very* commonplace. They already can be, and it's going to become more commonplace as a DoS attack vector, concur w/you 100%. > But the sets of problems are different for an end user network vs. a service provider network. For a transit link you might disable ND and configure static neighbors which would inoculate that link from such a neighbor table exhaustion attack. If you're using /64s for your p2p links, the router's still been turned into a sinkhole, though. > For an end network, the problems are different. Concur again. ------------------------------------------------------------------------ Roland Dobbins // Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay From rdobbins at arbor.net Wed Jan 5 22:28:54 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 6 Jan 2011 04:28:54 +0000 Subject: NIST IPv6 document In-Reply-To: <4D254365.2050806@utc.edu> References: <201101060308.p0638wha085757@aurora.sol.net> <8469431D-AD95-4B75-9CDC-9C0176ED8CF9@arbor.net> <4D254365.2050806@utc.edu> Message-ID: <8D7D9910-F828-4008-8C7A-7C563F8F31DF@arbor.net> On Jan 6, 2011, at 11:21 AM, Jeff Kell wrote: > I hesitate to write anything off to impossibility, having witnessed the 8 to 16 to 32 to 64-bit processor progression :) Indeed; how quickly we forget, eh? ;> > And the "depth" of infrastructure at which you can decide the traffic is > bogus is much greater with IPv6. /s/can/have the ability to > Most will end up on the target network anyway, no? And that's the real point. ------------------------------------------------------------------------ Roland Dobbins // Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay From rdobbins at arbor.net Wed Jan 5 22:30:45 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 6 Jan 2011 04:30:45 +0000 Subject: ARIN and the RPKI (was Re: AltDB?) In-Reply-To: References: Message-ID: On Jan 6, 2011, at 11:16 AM, Randy Bush wrote: > actually, the formal rpki-based origin-validation stuff is measured to take *less* cpu, a lot less, than ACLs On the platforms which really matter in terms of rPKI, ACLs are handled in hardware, so this is pretty much a wash. Concur on all the other points, however. ------------------------------------------------------------------------ Roland Dobbins // Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay From marka at isc.org Wed Jan 5 22:31:10 2011 From: marka at isc.org (Mark Andrews) Date: Thu, 06 Jan 2011 15:31:10 +1100 Subject: Problems with removing NAT from a network In-Reply-To: Your message of "Wed, 05 Jan 2011 20:09:08 -0800." References: <4D252B1F.8030506@kenweb.org> <3DFD6833-78C1-43D2-8074-6C89CFE3F2F3@arbor.net> Message-ID: <20110106043110.21C96876D21@drugs.dv.isc.org> In message , Came ron Byrne writes: > On Wed, Jan 5, 2011 at 6:42 PM, Dobbins, Roland wrote: > > > > On Jan 6, 2011, at 9:38 AM, ML wrote: > > > >> At least not without some painful rebuilds of criticals systems which ha= > ve these IPs deeply embedded in their configs. > > > > They shouldn't be using IP addresses in configs, they should be using DNS= > names. =A0Time to bite the bullet and get this fixed prior to their eventu= > al forced migration to IPv6. > > > > Somebody should tell the nytimes.com about this being a bad practice, > many of their images are linked to ip addresses directly and will > certainly fail in the future (this year, mobile) networks that will > use NAT64/DNS64. I am sure users will find other places to view their > news when nytimes.com fails to work in these ipv6-only networks. Which is one of the reasons why DS-lite is a better solution for providing legacy access to the IPv4 Internet than NAT64/DNS64. DS-lite only breaks what NAT44 breaks. DS-lite doesn't break new things. > Small summary of the problem of IPv4 literals and how they will break > in certain IPv6 environments that will be deployed this year > http://groups.google.com/group/ipv4literals > > Cameron > =3D=3D=3D=3D=3D=3D=3D=3D=3D > http://groups.google.com/group/tmoipv6beta > =3D=3D=3D=3D=3D=3D=3D=3D=3D > > > ------------------------------------------------------------------------ > > Roland Dobbins // > > > > Most software today is very much like an Egyptian pyramid, with millions > > of bricks piled on top of each other, with no structural integrity, but > > just done by brute force and thousands of slaves. > > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-- Alan Kay > > > > > > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From morrowc.lists at gmail.com Wed Jan 5 22:36:25 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 5 Jan 2011 23:36:25 -0500 Subject: ARIN and the RPKI (was Re: AltDB?) In-Reply-To: References: Message-ID: On Wed, Jan 5, 2011 at 11:30 PM, Dobbins, Roland wrote: > > On Jan 6, 2011, at 11:16 AM, Randy Bush wrote: > >> actually, the formal rpki-based origin-validation stuff is measured to take *less* cpu, a lot less, than ACLs > > On the platforms which really matter in terms of rPKI, ACLs are handled in hardware, so this is pretty much a wash. I think ACLs here means prefix-lists ... or I hope that's what Randy meant? (prefix-lists are still, I believe, handled in the router CPU, and the normal router OS not in hardware) > Concur on all the other points, however. > cool, thanks! -chris > ------------------------------------------------------------------------ > Roland Dobbins // > > Most software today is very much like an Egyptian pyramid, with millions > of bricks piled on top of each other, with no structural integrity, but > just done by brute force and thousands of slaves. > > ? ? ? ? ? ? ? ? ? ? ? ? ?-- Alan Kay > > > From tme at americafree.tv Wed Jan 5 22:44:08 2011 From: tme at americafree.tv (Marshall Eubanks) Date: Wed, 5 Jan 2011 23:44:08 -0500 Subject: Next generation TV over the Internet: This revolution will be televised Message-ID: Lenny Giuliano of Juniper (IETF MBONED co-chair) has written an article in Network World that I thought NANOGers might be interested in : http://www.networkworld.com/news/tech/2011/010511-tech-update-next-gen-tv.html He clearly describes the need for multicast in the upcoming video-centric Internet and how the AMT protocol can help by providing automatic tunnels between unicast-only users and multicast-enabled content, and provides a vision for a Internet "NextGenTV." Regards Marshall From cb.list6 at gmail.com Wed Jan 5 22:47:26 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Wed, 5 Jan 2011 20:47:26 -0800 Subject: Problems with removing NAT from a network In-Reply-To: <20110106043110.21C96876D21@drugs.dv.isc.org> References: <4D252B1F.8030506@kenweb.org> <3DFD6833-78C1-43D2-8074-6C89CFE3F2F3@arbor.net> <20110106043110.21C96876D21@drugs.dv.isc.org> Message-ID: On Wed, Jan 5, 2011 at 8:31 PM, Mark Andrews wrote: > > In message , Came > ron Byrne writes: >> On Wed, Jan 5, 2011 at 6:42 PM, Dobbins, Roland wrote: >> > >> > On Jan 6, 2011, at 9:38 AM, ML wrote: >> > >> >> At least not without some painful rebuilds of criticals systems which ha= >> ve these IPs deeply embedded in their configs. >> > >> > They shouldn't be using IP addresses in configs, they should be using DNS= >> ?names. =A0Time to bite the bullet and get this fixed prior to their eventu= >> al forced migration to IPv6. >> > >> >> Somebody should tell the nytimes.com about this being a bad practice, >> many of their images are linked to ip addresses directly and will >> certainly fail in the future (this year, mobile) networks that will >> use NAT64/DNS64. ?I am sure users will find other places to view their >> news when nytimes.com fails to work in these ipv6-only networks. > > Which is one of the reasons why DS-lite is a better solution for > providing legacy access to the IPv4 Internet than NAT64/DNS64. > DS-lite only breaks what NAT44 breaks. ?DS-lite doesn't break new > things. > Thanks for the tip. But, there are legitimate business reason in various different types of networks for various strategies, thanks for plugging the one your organization makes. I am tired of the IPv6 transition flavor of the day war. The reality for content folks is that there will be IPv4 host, IPv6 hosts, and dual stack hosts. Content needs to be dual-stack to reach everyone the best way (native), but if they lack dual-stack and they use IPv4 literals, they are going to lose eyeballs. End of story. Content folks-- do yourself a favor and follow Roland's advice (also in RFC 1958) and don't use address literals, use names. And, you will notice that the list at http://groups.google.com/group/ipv4literals shows only a few web site, because there are only a few that have this design flaws. If you know others, strengthen your case and add them to the list so that all parties can benefit. Otherwise, it is just a few poorly designed internet services that will be in a rush to fix services when users complain.... or there web pages hits start trending down while their competitors trend up. Cameron >> Small summary of the problem of IPv4 literals and how they will break >> in certain IPv6 environments that will be deployed this year >> http://groups.google.com/group/ipv4literals >> >> Cameron >> =3D=3D=3D=3D=3D=3D=3D=3D=3D >> http://groups.google.com/group/tmoipv6beta >> =3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> > ------------------------------------------------------------------------ >> > Roland Dobbins // >> > >> > Most software today is very much like an Egyptian pyramid, with millions >> > of bricks piled on top of each other, with no structural integrity, but >> > just done by brute force and thousands of slaves. >> > >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-- Alan Kay >> > >> > >> > >> > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 ? ? ? ? ? ? ? ? INTERNET: marka at isc.org > From johnl at iecc.com Wed Jan 5 23:01:30 2011 From: johnl at iecc.com (John Levine) Date: 6 Jan 2011 05:01:30 -0000 Subject: NIST IPv6 document In-Reply-To: <4D254365.2050806@utc.edu> Message-ID: <20110106050130.18520.qmail@joyce.lan> >Still, the idea that "nobody will scan a /64" reminds me of the days >when 640K ought to be enough for anybody, ... We really need to wrap our heads around the orders of magnitude involved here. If you could scan an address every nanosecond, which I think is a reasonable upper bound what with the speed of light and all, it would still take 500 years to scan a /64. Enumerating all the addresses will never be practical. But there's plenty of damage one can do with a much less than thorough enumeration. >And the "depth" of infrastructure at which you can decide the traffic is >bogus is much greater with IPv6. Most will end up on the target network >anyway, no? I get the impression that we're just beginning to figure out all the ways that bad things can happen when friends or foes start using all those addresses. For example, over in the IRTF ASRG list we're arguing about what to do with IP based blacklists and whitelists, since spammers could easily use a unique IP address for every message they ever send. (Please don't argue about that particular issue here, but feel free to do so in the ASRG.) 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 matthew at matthew.at Wed Jan 5 23:10:48 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Wed, 05 Jan 2011 21:10:48 -0800 Subject: Problems with removing NAT from a network In-Reply-To: References: <4D252B1F.8030506@kenweb.org> <3DFD6833-78C1-43D2-8074-6C89CFE3F2F3@arbor.net> <20110106043110.21C96876D21@drugs.dv.isc.org> Message-ID: <4D254ED8.6030006@matthew.at> On 1/5/2011 8:47 PM, Cameron Byrne wrote: > > And, you will notice that the list at > http://groups.google.com/group/ipv4literals shows only a few web site, > because there are only a few that have this design flaws. And the list looks like it does because the list only shows a *few* web sites. Other surveys have shown significantly more cases. ( http://tools.ietf.org/html/draft-wing-behave-http-ip-address-literals-02#appendix-B "An examination of Alexa's top 1 million domains [Alexa] at the end of August, 2009, showed 2.38% of the HTML in their home pages contained IPv4 address literals." And the list looks like is does because the list only shows a few *web sites*. Quite a few network protocols, particularly peer-to-peer protocols, rely on moving around the IP address literals of peers via mechanisms other than DNS. This includes BitTorrent, Adobe's RTMFP, and Skype's proprietary protocol, and every VoIP system using STUN and/or ICE, to name just a few. Once users figure out that none of those will work when they use you as an ISP, they'll find one that's chosen a better transition technology. Also note that DNSSEC end-to-end and DNS64/NAT64 are mutually exclusive. Now that DNSSEC is actually getting some traction, that's just one more reason to chose a different way to transition. Matthew Kaufman From randy at psg.com Wed Jan 5 23:15:38 2011 From: randy at psg.com (Randy Bush) Date: Thu, 06 Jan 2011 14:15:38 +0900 Subject: ARIN and the RPKI (was Re: AltDB?) In-Reply-To: References: Message-ID: >> actually, the formal rpki-based origin-validation stuff is measured >> to take *less* cpu, a lot less, than ACLs > On the platforms which really matter in terms of rPKI, ACLs are > handled in hardware, so this is pretty much a wash. really? it was measured on a GSR. full check on a prefix, 10usec. that's microseconds. as chris pointed out, though, one pays for having the data in the trie, i.e. in ram. but not a lot. randy From jgreco at ns.sol.net Wed Jan 5 23:17:58 2011 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 5 Jan 2011 23:17:58 -0600 (CST) Subject: NIST IPv6 document In-Reply-To: Message-ID: <201101060517.p065Hwsd087410@aurora.sol.net> > > It has nothing to do with "security by obscurity". > > You may wish to re-read what Joe was saying - he was positing sparse addres= > sing as a positive good because it will supposedly make it more difficult f= > or attackers to locate endpoints in the first place, i.e., security through= > obscurity. I think that's an invalid argument. That's not necessarily security through obscurity. A client that just picks a random(*) address in the /64 and sits on it forever could be reasonably argued to be doing a form of security through obscurity. However, that's not the only potential use! A client that initiates each new outbound connection from a different IP address is doing something Really Good. It may help to think of your Internet address plus port number as being just a single quantity in some senses. As it stands with IPv4, when you "see" packets from 12.34.56.78, you pretty much know there's a host or something interesting probably living there. You can then try to probe one of ~64K ports, or better yet, all of them, and you have a good chance of finding something of interest. If you have potentially 80 bits of space to probe (16 bits of ports on each of 64 bits of address), you're making a hell of a jump. If you don't understand the value of such an increase in magnitude, I invite you to switch all your ssh keys to 56 bit. ... 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 randy at psg.com Wed Jan 5 23:24:01 2011 From: randy at psg.com (Randy Bush) Date: Thu, 06 Jan 2011 14:24:01 +0900 Subject: ARIN and the RPKI (was Re: AltDB?) In-Reply-To: References: Message-ID: > I think ACLs here means prefix-lists ... or I hope that's what Randy > meant? sorry. yes, irr based prefix lists. and, sad to say, data which have sucked for 15+ years. i was the poster child for the irr, and it just never took off. [ irr data are pretty bad except for some islands where there is culture of maintining them. and, as it is a global internet, islands don't help much. europe and japan are two islands with better than the average irr data quality. and they have rpki rolling to varied degrees. ] randy From bensons at queuefull.net Wed Jan 5 23:25:28 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Wed, 5 Jan 2011 23:25:28 -0600 Subject: Problems with removing NAT from a network In-Reply-To: <20110106043110.21C96876D21@drugs.dv.isc.org> References: <4D252B1F.8030506@kenweb.org> <3DFD6833-78C1-43D2-8074-6C89CFE3F2F3@arbor.net> <20110106043110.21C96876D21@drugs.dv.isc.org> Message-ID: <4C26BA1C-9346-4FAF-8486-2256B8C87829@queuefull.net> On Jan 5, 2011, at 10:31 PM, Mark Andrews wrote: > > Which is one of the reasons why DS-lite is a better solution for > providing legacy access to the IPv4 Internet than NAT64/DNS64. > DS-lite only breaks what NAT44 breaks. DS-lite doesn't break new > things. > Or just run a dual-stack network, with centralized NAT44, and avoid the headache of tunneling. If you're going to run two protocol families on the end host, and deal with the issues that causes, why require tunneling to make it work? Is it so hard to forward IPv4 packets natively? Cheers, -Benson From owen at delong.com Wed Jan 5 23:25:24 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 5 Jan 2011 21:25:24 -0800 Subject: NIST IPv6 document In-Reply-To: References: <20110105043548.BC01B1CC3E@ptavv.es.net> Message-ID: <4661ED7E-A4DA-4CD4-A7EB-C5B2E615F126@delong.com> Is there any reason we really need to care what size other people use for their Point to Point links? Personally, I think /64 works just fine. I won't criticize anyone for using it. It's what I choose to use. However, if someone else wants to keep track of /112s, /120s, /124s, /126s, or even /127s on their own network, so be it. The protocol allows for all of that. If vendors build stuff that depends on /64, that stuff is technically broken and it's between the network operator and the vendor to get it resolved. Owen On Jan 5, 2011, at 4:29 AM, Dobbins, Roland wrote: > > On Jan 5, 2011, at 7:21 PM, Jeff Wheeler wrote: > >> please explain why this is in any way better than operating the same LAN with a subnet similar in size to its existing IPv4 subnets, e.g. a /120. > > > Using /64s is insane because a) it's unnecessarily wasteful (no lectures on how large the space is, I know, and reject that argument out of hand) and b) it turns the routers/switches into sinkholes. > > ------------------------------------------------------------------------ > Roland Dobbins // > > Most software today is very much like an Egyptian pyramid, with millions > of bricks piled on top of each other, with no structural integrity, but > just done by brute force and thousands of slaves. > > -- Alan Kay > From owen at delong.com Wed Jan 5 23:31:37 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 5 Jan 2011 21:31:37 -0800 Subject: NIST IPv6 document In-Reply-To: <4D248868.70705@brightok.net> References: <20110105043548.BC01B1CC3E@ptavv.es.net> <4D248868.70705@brightok.net> Message-ID: <165A304D-D288-4290-ACB3-A63CD461CAF0@delong.com> On Jan 5, 2011, at 7:04 AM, Jack Bates wrote: > On 1/5/2011 6:29 AM, Dobbins, Roland wrote: >> >> Using /64s is insane because a) it's unnecessarily wasteful (no >> lectures on how large the space is, I know, and reject that argument >> out of hand) and b) it turns the routers/switches into sinkholes. >> > > Except someone was kind enough to develop a protocol that requires /64 to work. So then there is the SLAAC question. When might it be used? > > With routers, I usually don't use SLAAC. The exception is end user networks, which makes using SLAAC + DHCPv6-PD extremely dangerous for my edge routers. DHCPv6 IA_TA + DHCPv6-PD would be more sane, predictable, and filterable (and support longer than /64) thought my current edge layout can't support this (darn legacy IOS). > > I would love a dynamic renumbering scheme for routers, but until all routing protocols (especially iBGP) support shifting from one prefix to the next without a problem, it's a lost cause and manual renumbering is still required. Things like abstracting the router id from the transport protocol would be nice. I could be wrong, but I think ISIS is about it for protocols that won't complain. > > All that said, routers should be /126 or similar for links, with special circumstances and layouts for customer edge. > Why shouldn't I use /64 for links if I want to? I can see why you can say you want /126s, and that's fine, as long as you are willing to deal with the fall-out, your network, your problem, but, why tell me that my RFC-compliant network is somehow wrong? > For server subnets, I actually prefer leaving it /64 and using SLAAC with token assignments. This is easily mitigated with ACLs to filter any packets that don't fall within the range I generally use for the tokens, with localized exceptions for non-token devices which haven't been fully initialized yet (ie, stay behind stateful firewall until I've changed my IP to prefix::0-2FF). I haven't tried it, but I highly suspect it would fail, but it would be nice to use SLAAC with longer than /64. > SLAAC cannot function with longer than /64 because SLAAC depends on prefix + EUI-64 = address. Owen From marka at isc.org Wed Jan 5 23:35:09 2011 From: marka at isc.org (Mark Andrews) Date: Thu, 06 Jan 2011 16:35:09 +1100 Subject: Problems with removing NAT from a network In-Reply-To: Your message of "Wed, 05 Jan 2011 20:47:26 -0800." References: <4D252B1F.8030506@kenweb.org> <3DFD6833-78C1-43D2-8074-6C89CFE3F2F3@arbor.net> <20110106043110.21C96876D21@drugs.dv.isc.org> Message-ID: <20110106053509.4386A878589@drugs.dv.isc.org> In message , Came ron Byrne writes: > On Wed, Jan 5, 2011 at 8:31 PM, Mark Andrews wrote: > > > > In message m>, Came > > ron Byrne writes: > >> On Wed, Jan 5, 2011 at 6:42 PM, Dobbins, Roland wro= > te: > >> > > >> > On Jan 6, 2011, at 9:38 AM, ML wrote: > >> > > >> >> At least not without some painful rebuilds of criticals systems which= > ha= > >> ve these IPs deeply embedded in their configs. > >> > > >> > They shouldn't be using IP addresses in configs, they should be using = > DNS= > >> names. Time to bite the bullet and get this fixed prior to their= > eventu= > >> al forced migration to IPv6. > >> > > >> > >> Somebody should tell the nytimes.com about this being a bad practice, > >> many of their images are linked to ip addresses directly and will > >> certainly fail in the future (this year, mobile) networks that will > >> use NAT64/DNS64. I am sure users will find other places to view their > >> news when nytimes.com fails to work in these ipv6-only networks. > > > > Which is one of the reasons why DS-lite is a better solution for > > providing legacy access to the IPv4 Internet than NAT64/DNS64. > > DS-lite only breaks what NAT44 breaks. DS-lite doesn't break new > > things. > > Thanks for the tip. But, there are legitimate business reason in > various different types of networks for various strategies, Indeed. I just which DS-lite was thought of about the same time as NATPT was. That way network operators would have the code in things like cell phones today rather than the next gen resulting in them being forced to use NAT64 and with that all the additional problems it causes. The network operator is going to be running a big/distributed NAT box of one description or another to share the available IPv4 addresses. It just a matter of which packets its processing. The end choice may come down to which DHCP options the client requests or doesn't. i.e. return DNS64 nameservers if the client doesn't request the DS-lite configuration parameters. > thanks for plugging the one your organization makes. We also ship a DNS64 implementation. > I am tired of the IPv6 > transition flavor of the day war. The reality for content folks is > that there will be IPv4 host, IPv6 hosts, and dual stack hosts. > Content needs to be dual-stack to reach everyone the best way > (native), but if they lack dual-stack and they use IPv4 literals, they > are going to lose eyeballs. End of story. Agreed they will loose eyeballs. HTTP and IPv4 literals is one of the easier problems to be mitigated. Its the rest of the places where IPv4 addresses are passed that causes problems. > Content folks-- do yourself a favor and follow Roland's advice (also > in RFC 1958) and don't use address literals, use names. > > And, you will notice that the list at > http://groups.google.com/group/ipv4literals shows only a few web site, > because there are only a few that have this design flaws. If you know > others, strengthen your case and add them to the list so that all > parties can benefit. Otherwise, it is just a few poorly designed > internet services that will be in a rush to fix services when users > complain.... or there web pages hits start trending down while their > competitors trend up. > > Cameron -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From cb.list6 at gmail.com Wed Jan 5 23:39:30 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Wed, 5 Jan 2011 21:39:30 -0800 Subject: Problems with removing NAT from a network In-Reply-To: <4D254ED8.6030006@matthew.at> References: <4D252B1F.8030506@kenweb.org> <3DFD6833-78C1-43D2-8074-6C89CFE3F2F3@arbor.net> <20110106043110.21C96876D21@drugs.dv.isc.org> <4D254ED8.6030006@matthew.at> Message-ID: On Wed, Jan 5, 2011 at 9:10 PM, Matthew Kaufman wrote: > On 1/5/2011 8:47 PM, Cameron Byrne wrote: >> >> And, you will notice that the list at >> http://groups.google.com/group/ipv4literals shows only a few web site, >> because there are only a few that have this design flaws. > > And the list looks like it does because the list only shows a *few* web > sites. Other surveys have shown significantly more cases. ( > http://tools.ietf.org/html/draft-wing-behave-http-ip-address-literals-02#appendix-B > "An examination of Alexa's top 1 million domains [Alexa] at the end of > August, 2009, showed 2.38% of the HTML in their home pages contained IPv4 > address literals." > > And the list looks like is does because the list only shows a few *web > sites*. Quite a few network protocols, particularly peer-to-peer protocols, I understand my users pretty well, they only go to a few web pages ... its the nature of the net. I assure you, i am not taking any undue risk with regards to web. Try our friendly user trial and give me your feedback, thats why i am running it. > rely on moving around the IP address literals of peers via mechanisms other > than DNS. This includes BitTorrent, Adobe's RTMFP, and Skype's proprietary Ah Skype. According to your web page you work at Skype. Skype is a well known IPv6 spoiler application. In fact, in the IETF and many other circles, Skype is the only app that we can't seem to get to work with IPv6. Are you here to help with that or to tell us that we need to keep IPv4 around indefinitely? In fact, we were just talking about how Skype as a spoiler this morning http://www.ietf.org/mail-archive/web/v6ops/current/msg06837.html Here is a pointer to IPv6-only users who would love to use Skype on IPv6-only handsets. http://talk.maemo.org/showthread.php?t=60320&page=24 Looking at the last post, it looks like they were able to NAT46 Skype to then talk out the NAT64 ... ugly. But serious, get with me off list and lets collaborate. I can help from the networks side, and i am eager to make progress. Skype should not be the IPv6 spoiler app when NEARLY EVERYTHING ELSE WORKS. Read the thread i mentioned, real users, real developers, real network that is IPv6-only. Notice that things generally work, those folks have hacked their way to perhaps even making Skype work. > protocol, and every VoIP system using STUN and/or ICE, to name just a few. > Once users figure out that none of those will work when they use you as an > ISP, they'll find one that's chosen a better transition technology. > Seriously, 95+% of my traffic is web and email, and STUN and ICE don't matter much to grandma as long as m.v6.facebook.com loads. > Also note that DNSSEC end-to-end and DNS64/NAT64 are mutually exclusive. Now > that DNSSEC is actually getting some traction, that's just one more reason > to chose a different way to transition. Strategy is done. Implementation is on-going. 3GPP and IETF joint meeting said dual-stack and IPv6-only + NAT64 are the 2 paths forward for mobile. http://www.3gpp.org/ftp/workshop/2010-03-01_IPv4-to-IPv6_with-IETF/Docs./IPW100060.zip Without going into too much detail, ds-lite does not live in mobile and likely never will. Any solution that requires IPv4 is not strategic. IPv4 addresses simply are not available at the scale of large mobile network operators, public, private, or bogon. Mobile must move to IPv6, and IPv6-only + NAT64 pushes the envelope in ways that dual-stack never has, and hence it just might work to *transition* to v6. As long as dual-stack is around, the app vendors don't have to move and network guys have to dream up hacks to support these legacy apps (CGN ....). Cameron > > Matthew Kaufman > From rdobbins at arbor.net Wed Jan 5 23:44:11 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 6 Jan 2011 05:44:11 +0000 Subject: NIST IPv6 document In-Reply-To: <201101060517.p065Hwsd087410@aurora.sol.net> References: <201101060517.p065Hwsd087410@aurora.sol.net> Message-ID: <296626A2-E477-410C-8B39-FF1B561DBE0B@arbor.net> On Jan 6, 2011, at 12:17 PM, Joe Greco wrote: > If you don't understand the value of such an increase in magnitude, I can count as well as you can, I assure you. > I invite you to switch all your ssh keys to 56 bit. The difference is that if someone compromises/brute-forces one of my ssh keys, he has something of value. OTOH, if he can find my host and send some packets to it, since I've done all the host OS/app/service BCPs, plus I'm enforcing policy via stateless ACLs in hardware-based routers/switches and tcpwrappers on my host, so what? I could care less. ------------------------------------------------------------------------ Roland Dobbins // Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay From jsw at inconcepts.biz Wed Jan 5 23:50:39 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Thu, 6 Jan 2011 00:50:39 -0500 Subject: NIST IPv6 document In-Reply-To: References: <201101060517.p065Hwsd087410@aurora.sol.net> Message-ID: On Thu, Jan 6, 2011 at 12:17 AM, Joe Greco wrote: > However, that's not the only potential use! ?A client that initiates > each new outbound connection from a different IP address is doing > something Really Good. No, Joe, it is not doing anything Good. ?This would require the software being written to make such random address selection, add more entries to the router's NDP table, and it would DoS the box's own router if an outbound scan were initiated from the host machine. Again, you totally fail to understand the problem. ?I should just attach a "facepalm" graphic to my reply and stop bothering with your idiocy, but it is important that as many people as possible understand these issues. ?Every additional person who is expressing concern to their vendors brings us closer to a solution. In addition, if the machine can choose another random IPv6 address in the /64 for each new outgoing connection, it could just as easily source all its outgoing connections from ... a single IPv6 address that does not accept any incoming connections. ?I will grant that this does not prevent "magic packet" attacks against bugs in the machine in kernel space, and that the machine could be the recipient of a DoS attack; but your proposed solution has no advantage in the case of, say, SQL Slammer 6, or other attacks exploiting vulnerabilities in user-space. On Thu, Jan 6, 2011 at 12:25 AM, Owen DeLong wrote: > Is there any reason we really need to care what size other people use for their Point to Point > links? > > Personally, I think /64 works just fine. > > I won't criticize anyone for using it. It's what I choose to use. You should care what size you choose, Owen. ?I would if I was your customer. ?There are several reasons why. ?If you configure a /64 on a point-to-point interface e.g. SONET, some current platforms will bounce any "scan" packets back and forth between the two hosts until the TTL expires, which means an attacker can saturate the point-to-point link with two orders of magnitude less attack traffic than the link capacity. ?This is very bad. Also, if the link is a LAN, you are vulnerable to the ARP/NDP problem. ?This may be a per-interface issue on your box, or it may be a global one. ?In the per-interface case, most likely, the failure mode will be okay; but some vendors (including Juniper?) will eventually expire the ARP/NDP entry even though there is active traffic, and may be unable to re-learn it when needed due to the attack, which would break the link between routers. ?On the other hand, if it's a global issue, it will break NDP on the entire router, affecting all interfaces by whatever the platform's failure mode is. ?Obviously, that is worse. This is why "RFC compliant" is wrong, Owen. ?That a learned, experienced person such as yourself has no clue what the underlying problem is exemplifies my point: much, much more noise needs to be made about this issue. ?A lot of smart people have known about it for years but nothing is being done. Anyone can choose not to use /64 on their point-to-point links with no consequence to their business. ?Customers aren't going to choose another vendor because they are likely never even aware of it. ?The operational problem is that customers will want it on the PE/CE LANs, hosting center LANs, and so on; and right now, if you tell them "we can't do that," they have trouble believing you because the standard says otherwise, and a lot of other networks are currently doing it (because they think they don't have a choice other than to lose potential customers.) However, if you are running /64 instead of something like /124 on your VLANs or SONET circuits between routers, you should change this practice as soon as practical. ?Not doing so once you have been educated about this problem because it is "the standard" is very stupid. ?Pretty much every major transit network has figured this out and are doing it on their interfaces to BGP customers, too, either optionally, by default, or as the only choice. The industry standard must change to be non-hostile toward choosing a smaller subnet size than /64 to give coverage to those of us who do understand what we are doing as we roll out IPv6 to customers. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From jgreco at ns.sol.net Wed Jan 5 23:54:35 2011 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 5 Jan 2011 23:54:35 -0600 (CST) Subject: NIST IPv6 document In-Reply-To: <296626A2-E477-410C-8B39-FF1B561DBE0B@arbor.net> Message-ID: <201101060554.p065sZR6087937@aurora.sol.net> > > On Jan 6, 2011, at 12:17 PM, Joe Greco wrote: > > > If you don't understand the value of such an increase in magnitude, > > I can count as well as you can, I assure you. > > > I invite you to switch all your ssh keys to 56 bit. > > The difference is that if someone compromises/brute-forces one of my ssh ke= > ys, he has something of value. =20 > > OTOH, if he can find my host and send some packets to it, since I've done a= > ll the host OS/app/service BCPs, plus I'm enforcing policy via stateless AC= > Ls in hardware-based routers/switches and tcpwrappers on my host, so what? = > I could care less. Generally speaking, security professionals prefer for there to be more roadblocks rather than fewer. That's why they call it layers of security; occasionally your belt may snap and you may find yourself reliant on the suspenders. The fact that you're confident that your belt is great is only relevant to yourself and any others who are similarly confident in their choice of belt. You start off with the assumption that the knowledge of the host address is not something of value; while I agree that it *shouldn't* be of value, the sad fact of the matter is that we've seen numerous examples of where it *is* of value. I'm starting off with the assumption that knowledge of the host address *might* be something of value. If it isn't, no harm done. If it is, and the address becomes virtually impossible to find, then we've just defeated an attack, and it's hard to see that as anything but positive. ... 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 Wed Jan 5 23:55:59 2011 From: marka at isc.org (Mark Andrews) Date: Thu, 06 Jan 2011 16:55:59 +1100 Subject: Problems with removing NAT from a network In-Reply-To: Your message of "Wed, 05 Jan 2011 21:39:30 -0800." References: <4D252B1F.8030506@kenweb.org> <3DFD6833-78C1-43D2-8074-6C89CFE3F2F3@arbor.net> <20110106043110.21C96876D21@drugs.dv.isc.org> <4D254ED8.6030006@matthew.at> Message-ID: <20110106055559.9C9F687D1C9@drugs.dv.isc.org> In message , Came ron Byrne writes: > As long as dual-stack is around, the app vendors don't have to move > and network guys have to dream up hacks to support these legacy apps > (CGN ....). NAT64 is CGN expecially when it is being implemented by the cellular carriers. > Cameron > > > > > Matthew Kaufman > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From oberman at es.net Thu Jan 6 00:01:42 2011 From: oberman at es.net (Kevin Oberman) Date: Wed, 05 Jan 2011 22:01:42 -0800 Subject: NIST IPv6 document In-Reply-To: Your message of "Wed, 05 Jan 2011 21:27:14 CST." <201101060327.p063REnl086015@aurora.sol.net> Message-ID: <20110106060142.44CC11CC41@ptavv.es.net> > From: Joe Greco > Date: Wed, 5 Jan 2011 21:27:14 -0600 (CST) > > > > > On Wed, Jan 5, 2011 at 8:57 PM, Joe Greco wrote: > > >> > This is a much smaller issue with IPv4 ARP, because routers generally > > >> > have very generous hardware ARP tables in comparison to the typical > > >> > size of an IPv4 subnet. > > >> > > >> no it isn't, if you've ever had your juniper router become unavailable > > >> because the arp policer caused it to start ignoring updates, or seen > > >> systems become unavailable due to an arp storm you'd know that you can > > >> abuse arp on a rather small subnet. > > > > > > It may also be worth noting that "typical size of an IPv4 subnet" is > > > a bit of a red herring; a v4 router that's responsible for /16 of > > > directly attached /24's is still able to run into some serious issues. > > > > It is uncommon for publicly-addressed LANs to be this large. The > > reason is simple: relatively few sites still have such an excess of > > IPv4 addresses that they can use them in such a sparsely-populated > > manner. > > Who said anything about sparsely populated? A typical hosting > provider might well fit such a general picture. > > > Those that do have had twenty years of operational experience > > with generation after generation of hardware and software, and they > > have had every opportunity to fully understand the problem (or > > redesign the relevant portion of their network.) > > No they haven't. I can think of relatively few networks that > have survived twenty years, and the ones that I can think of are > mostly .edu. Those of us who have been operating IP networks for > that length of time probably see both the flaws in IPv4 and IPv6. > > > In addition, there is not (any longer) a "standard," and a group of > > mindless zealots, telling the world that at /16 on your LAN is the > > only right way to do it. This is, in fact, the case with IPv6 > > deployments, and will drive what customers demand. > > The concepts behind IPv4 classful addressing were flawed, but not > unrealistic given the history. Various pressures existed to force > the development of CIDR. It's not clear that those same pressures > will force IPv6 to develop smaller networks - but other pressures > *might*. I've yet to hear convincing reasons as to why they > *should*. > > > To understand the problem, you must first realize that myopic > > standards-bodies have created it, and either the standards must > > change, operators must explain to their customers why they are not > > following the standards, or equipment vendors must provide additional > > knobs to provide a mitigation mechanism that is an acceptable > > compromise. Do the advantages of sparse subnets out-weigh the known > > security detriments, even if good compromise-mechanisms are provided > > by equipment vendors? > > Quite frankly, as an interested party, I've been following all this > for many years, and I am having a little trouble figuring out what > you mean by the "known security detriments" in this context. > > > "Security by obscurity" is an oft-touted advantage of IPv6 sparse > > subnets. We all know that anyone with a paypal account can buy a list > > of a few hundred million email addresses for next to nothing. How > > long until that is the case with lists of recently-active IPv6 hosts? > > Personally, I expect to see IPv6 privacy extensions become commonly > used; it's a fairly comprehensive answer to that issue. > > > What portion of attack vectors really depend on scanning hosts that > > aren't easily found in the DNS, as opposed to vectors depending on a > > browser click, email attachment, or by simply hammering away at > > "www.*.com" with common PHP script vulnerabilities? > > I see people scanning our IP space *all* *the* *time*. > > > How many people think that massively-sparse-subnets are going to save > > them money? > > If it saves me from creeps trawling through our IP space, that's a > savings. > > > Where will these cost-efficiencies come from? Why can't > > you gain that advantage by provisioning, say, 10 times as large a > > subnet as you think you need, instead of seventy-quadrillion times as > > large? > > Because at ten times as large, they can still trawl. > > > Is anyone really going to put their Windows Updates off and > > save money because they are comfortable that their hosts can't be > > found by random scanning? Is stateless auto-configuration that big a > > win vs DHCP? > > > > Yes, I should have participated in the process in the 1990s. However, > > just because the bed is already made doesn't mean I am willing to lay > > my customers in it. These problems can still be fixed before IPv6 is > > ubiquitous and mission-critical. The easiest fix is to reset the /64 > > mentality which standards-zealots are clinging to. > > Think you missed that particular boat a long time ago. > > The next ship will be departing in a hundred years or so, advance > registration for the IPv7 design committee are available over there. Sorry, but IPv7 has come and gone. It was assigned to the TUBA proposal, basically replacing IP with CLNP. IPv8 has also been assigned. (Don't ask as it involved he who must not be named.) I am amazed at the number of folks who seem to think that there is time to change IPv6 is ANY significant way. Indeed, the ship has failed. If you r network is not well along in getting ready for IPv6, you are probably well on you way to being out of business. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From rdobbins at arbor.net Thu Jan 6 00:05:00 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 6 Jan 2011 06:05:00 +0000 Subject: NIST IPv6 document In-Reply-To: <201101060554.p065sZR6087937@aurora.sol.net> References: <201101060554.p065sZR6087937@aurora.sol.net> Message-ID: <1F3A01A3-A244-416E-85D8-74CCBA253AAC@arbor.net> On Jan 6, 2011, at 12:54 PM, Joe Greco wrote: > Generally speaking, security professionals prefer for there to be more roadblocks rather than fewer. The soi-disant security 'professionals' who espouse layering unnecessary multiple, inefficient, illogical, and iatrogenic roadblocks in preference to expending the time and effort to learn enough about *actual* security (in contrast to security theater) to Do Things Right The First Time, aren't worthy of the title and ought to be ignored, IMHO. > If it is, and the address becomes virtually impossible to find, then we've just defeated an attack, and it's hard to see that as anything but positive. If we had some cheese, we could make a ham-and-cheese sandwich, if we had some ham. ;> We must face up to the reality that the endpoint *will be found*, irrespective of the relative sparseness or density of the addressing plan. It will be found via DNS, via narrowing the search scope via examining routing advertisements, via narrowing the search scope via perusing whois, via the attackers simply throwing more of their near-infinite scanning resources (i.e., bots) at these dramatically-reduced search scopes. So, the endpoint will be found, no attack will be prevented, and we end up a) wasting wide swathes of address space for no good reason whilst b) making the routing/switching infrastructure elements far more vulnerable to DoS by turning them into sinkholes. No positive benefits, two negative drawbacks. ------------------------------------------------------------------------ Roland Dobbins // Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay From cb.list6 at gmail.com Thu Jan 6 00:08:35 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Wed, 5 Jan 2011 22:08:35 -0800 Subject: Problems with removing NAT from a network In-Reply-To: <20110106055559.9C9F687D1C9@drugs.dv.isc.org> References: <4D252B1F.8030506@kenweb.org> <3DFD6833-78C1-43D2-8074-6C89CFE3F2F3@arbor.net> <20110106043110.21C96876D21@drugs.dv.isc.org> <4D254ED8.6030006@matthew.at> <20110106055559.9C9F687D1C9@drugs.dv.isc.org> Message-ID: On Wed, Jan 5, 2011 at 9:55 PM, Mark Andrews wrote: > > In message , Came > ron Byrne writes: >> As long as dual-stack is around, the app vendors don't have to move >> and network guys have to dream up hacks to support these legacy apps >> (CGN ....). > > NAT64 is CGN expecially when it is being implemented by the cellular > carriers. > Agreed. And, the NAT44 that 99% of my customer use to today is also a CGN. It's status quo, all v4 flows require state in my network, NAT44 or NAT64. But, NAT64 has an exit strategy. With every new AAAA that comes out, that is one less destination requiring state in my network. Cameron >> Cameron >> >> > >> > Matthew Kaufman >> > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 ? ? ? ? ? ? ? ? INTERNET: marka at isc.org > From rluethje at gmail.com Thu Jan 6 00:14:51 2011 From: rluethje at gmail.com (Robert Luethje) Date: Thu, 6 Jan 2011 01:14:51 -0500 Subject: Holiday Songs References: <4D11B32F.7010202@gmail.com> Message-ID: <008401cbad69$086a0bd0$6401a8c0@knightmareserv> thanks to all who replied, my family really enjoyed it. ----- Original Message ----- From: "JC Dill" Cc: "NANOG list" Sent: Wednesday, December 22, 2010 3:13 AM Subject: Re: Holiday Songs > > > Network Working Group B. Hancock > Request for Comments: 1882 Network-1 Software and Technology, Inc. > Category: Informational December 1995 > > The 12-Days of Technology Before Christmas > > Status of this Memo > > This memo provides information for the Internet community. This memo > does not specify an Internet standard of any kind. Distribution of > this memo is unlimited. > > Discussion > > On the first day of Christmas, technology gave to me: > A database with a broken b-tree (what the hell is a b-tree > anyway?) > > On the second day of Christmas, technology gave to me: > Two transceiver failures (CRC errors? Collisions? What is > going on?) > And a database with a broken b-tree (Rebuild WHAT? It's a > 10GB database!) > > On the third day of Christmas, technology gave to me: > Three French users (who, of course, think they know > everything) > Two transceiver failures (which are now spewing packets all > over the net) > And a database with a broken b-tree (Backup? What backup?) > > On the fourth day of Christmas, technology gave to me: > Four calls for support (playing the same Christmas song over > and over) > Three French users (Why do they like to argue so much over > trivial things?) > Two transceiver failures (How the hell do I know which ones > they are?) > And a database with a broken b-tree (Pointer error? What's a > pointer error?) > > On the fifth day of Christmas, technology gave to me: > Five golden SCSI contacts (Of course they're better than > silver!) > Four support calls (Ever notice how time stands still when on > hold? > Three French users (No, we don't have footpedals on PC's. Why > do you ask?) > Two transceiver failures (If I knew which ones were bad, I > would know which ones to fix!) > And a database with a broken b-tree (Not till next week? Are > you nuts?!?!) > > On the sixth day of Christmas, technology gave to me: > Six games a-playing (On the production network, of course!) > Five golden SCSI contacts (What do you mean "not terminated!") > Four support calls (No, don't transfer me again - do you HEAR? > Damn!) > Three French users (No, you cannot scan in by putting the page > to the screen...) > Two transceiver failures (I can't look at the LEDs - they're > in the ceiling!) > And a database with a broken b-tree (Norway? That's where this > was written?) > > On the seventh day of Christmas, technology gave to me: > Seven license failures (Expired? When?) > Six games a-playing (Please stop tying up the PBX to talk to > each other!) > Five golden SCSI contacts (What do you mean I need "wide" > SCSI?) > Four support calls (At least the Muzak is different this > time...) > Three French Users (Well, monsieur, there really isn't an > "any" key, but...) > Two transceiver failures (SQE? What is that? If I knew I would > set it myself!) > And a database with a broken b-tree (No, I really need to talk > to Lars - NOW!) > > On the eighth day of Christmas, technology gave to me: > Eight MODEMs dialing (Who bought these? They're a security > violation!) > Seven license failures (How many WEEKS to get a license?) > Six games a-playing (What do you mean one pixel per packet on > updates?!?) > Five golden SCSI contacts (Fast SCSI? It's supposed to be > fast, isn't it?) > Four support calls (I already told them that! Don't transfer > me back - DAMN!) > Three French users (No, CTL-ALT-DEL is not the proper way to > end a program) > Two transceiver failures (What do you mean "babbling > transceiver"?) > And a database with a broken b-tree (Does anyone speak English > in Oslo?) > > On the ninth day of Christmas, technology gave to me: > Nine lady executives with attitude (She said do WHAT with the > servers?) > Eight MODEMs dialing (You've been downloading WHAT?) > Seven license failures (We sent the P.O. two months ago!) > Six games a-playing (HOW many people are doing this to the > network?) > Five golden SCSI contacts (What do you mean two have the same > ID?) > Four support calls (No, I am not at the console - I tried that > already.) > Three French users (No, only one floppy fits at a time? Why do > you ask?) > Two transceiver failures (Spare? What spare?) > And a database with a broken b-tree (No, I am trying to find > Lars! L-A-R-S!) > > On the tenth day of Christmas, technology gave to me: > Ten SNMP alerts flashing (What is that Godawful beeping?) > Nine lady executives with attitude (No, it used to be a mens > room? Why?) > Eight MODEMs dialing (What Internet provider? We don't allow > Internet here!) > Seven license failures (SPA? Why are they calling us?) > Six games a-playing (No, you don't need a graphics accelerator > for Lotus! ) > Five golden SCSI contacts (You mean I need ANOTHER cable?) > Four support calls (No, I never needed an account number > before...) > Three French users (When the PC sounds like a cat, it's a head > crash!) > Two transceiver failures (Power connection? What power > connection?) > And a database with a broken b-tree (Restore what index > pointers?) > > On the eleventh day of Christmas, technology gave to me: > Eleven boards a-frying (What is that terrible smell?) > Ten SNMP alerts flashing (What's a MIB, anyway? What's an > extension?) > Nine lady executives with attitude (Mauve? Our computer room > tiles in mauve?) > Eight MODEMs dialing (What do you mean you let your roommate > dial-in?) > Seven license failures (How many other illegal copies do we > have?!?!) > Six games a-playing (I told you - AFTER HOURS!) > Five golden SCSI contacts (If I knew what was wrong, I > wouldn't be calling!) > Four support calls (Put me on hold again and I will slash your > credit rating!) > Three French users (Don't hang your floppies with a magnet > again!) > Two transceiver failures (How should I know if the connector > is bad?) > And a database with a broken b-tree (I already did all of > that!) > > On the twelfth day of Christmas, technology gave to me: > Twelve virtual pipe connections (There's only supposed to be > two!) > Eleven boards a-frying (What a surge suppressor supposed to > do, anyway?) > Ten SNMP alerts flashing (From a distance, it does kinda look > like XMas lights.) > Nine lady executives with attitude (What do you mean aerobics > before backups?) > Eight MODEMs dialing (No, we never use them to connect during > business hours.) > Seven license failures (We're all going to jail, I just know > it.) > Six games a-playing (No, no - my turn, my turn!) > Five golden SCSI contacts (Great, just great! Now it won't > even boot!) > Four support calls (I don't have that package! How did I end > up with you!) > Three French users (I don't care if it is sexy, no more nude > screen backgrounds!) > Two transceiver failures (Maybe we should switch to token > ring...) > And a database with a broken b-tree (No, operator - Oslo, > Norway. We were just talking and were cut off...) > > Security Considerations > > Security issues are not discussed in this memo. > > Author's Address > > Bill Hancock, Ph.D. > Network-1 Software& Technology, Inc. > DFW Research Center > 878 Greenview Dr. > Grand Prairie, TX 75050 > > EMail:hancock at network-1.com > Phone: (214) 606-8200 > > Fax: (214) 606-8220 > > From: > http://www.faqs.org/rfcs/rfc1882.html > > > > > From drc at virtualized.org Thu Jan 6 00:21:03 2011 From: drc at virtualized.org (David Conrad) Date: Wed, 5 Jan 2011 20:21:03 -1000 Subject: AltDB? In-Reply-To: References: <94F3F129-608E-46EC-B157-CC23CAA47454@tozz.net> <4D24A734.3000807@jcoley.net> <816AB912-14CF-4028-853A-F0BE77D2EB09@puck.nether.net> Message-ID: <734B46C1-AE6C-406A-8163-00CFFE942B1B@virtualized.org> On Jan 5, 2011, at 12:32 PM, Randy Bush wrote: > i have a rumor that arin is delaying and possibly not doing rpki that > seems to have been announced on the ppml list (to which i do not > subscribe). I heard about the delay, but not about ARIN possibly not doing RPKI. That would be ... surprising. While I have always had some questions regarding the political (not technical) feasibility of actually deploying secure routing based on the top-down hierarchical model assumed by RPKI, it seems obvious to me that there needs to be a better way to authenticate allocation data other than querying a whois server. RPKI will (would have?) provided this and the actual deployment of RPKI would allow the ops community to gain experience with the technology. > as it has impact on routing, not address policy, across > north america and, in fact the globe, one would think it would be > announced and discussed a bit more openly and widely. The definition of what comes under the "public policy mailing list" umbrella has always been a bit confusing to me. Too bad something like the APNIC SIGs and RIPE Working Groups don't really exist in the ARIN region. Regards, -drc From jsw at inconcepts.biz Thu Jan 6 00:22:36 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Thu, 6 Jan 2011 01:22:36 -0500 Subject: NIST IPv6 document In-Reply-To: <201101060554.p065sZR6087937@aurora.sol.net> References: <296626A2-E477-410C-8B39-FF1B561DBE0B@arbor.net> <201101060554.p065sZR6087937@aurora.sol.net> Message-ID: On Thu, Jan 6, 2011 at 12:54 AM, Joe Greco wrote: > I'm starting off with the assumption that knowledge of the host > address *might* be something of value. ?If it isn't, no harm done. > If it is, and the address becomes virtually impossible to find, then > we've just defeated an attack, and it's hard to see that as anything > but positive. I'm starting off with the assumption that the layer-3 network needs to function for the host machines to be useful. Your position is to just hand any attacker an "off switch" and let them disable any (LAN | router, depending on router failure mode) for which they know the subnet exists, whether or not they know any of its host addresses. This is a little like spending money on man-traps and security guards, but running all your fiber through obvious ducts in a public parking garage. It may be hard to compromise the hosts, but taking them offline is trivial. On Thu, Jan 6, 2011 at 1:01 AM, Kevin Oberman wrote: > I am amazed at the number of folks who seem to think that there is time to > change IPv6 is ANY significant way. Indeed, the ship has failed. If you > r network is not well along in getting ready for IPv6, you are probably > well on you way to being out of business. There are many things that can change very easily. Vendors can add knobs, subnet size can get smaller (it works just fine today, it just isn't "standard"), and so on. A TCP session today looks a lot different than it did in the mid-90s. Now we have things like SYN cookie, window scaling, we even went through the "hurry up and configure TCP MD5 on your BGP just in case." Fixing this problem by deploying subnets as a /120 instead of a /64 is a lot easier than any of those changes to TCP, which all required operating system modifications on one or both sides. How many networks honor ICMP route-record, source routing, or make productive use of redirects (if they have not outright disabled it?) How many networks decided to block all ICMP traffic because some clueless employee told them it was smart? CIDR routing? Do you recall that the TTL field in IP headers was originally not a remaining-hops-count, but actually, a value in seconds (hence "Time To Live")? IPv4, and the things built on top of it, have evolved tremendously, some, all the way to the host network. A lot of this evolution took place before it was common to conduct a credit card transaction over the Internet, at a time when it really was not mission-critical for most operators. IPv6 is still not there, but I agree, we are rapidly approaching that time, and much more than 90% of IPv4 networks have a lot of work to do. It would be good to see LANs smaller than /64 accepted sometime before IPv6 does become widely-deployed to end users. Or some other practical solution to the problems of huge subnet sizes, whatever those solutions may be. My guess is there may be other, very significant, challenges to having huge LAN subnets. This is one we actually know about, but are choosing not to solve. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From jgreco at ns.sol.net Thu Jan 6 00:26:04 2011 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 6 Jan 2011 00:26:04 -0600 (CST) Subject: NIST IPv6 document In-Reply-To: Message-ID: <201101060626.p066Q4ak088421@aurora.sol.net> > On Thu, Jan 6, 2011 at 12:17 AM, Joe Greco wrote: > > However, that's not the only potential use! =A0A client that initiates > > each new outbound connection from a different IP address is doing > > something Really Good. > > No, Joe, it is not doing anything Good. =A0This would require the > software being written to make such random address selection, add more > entries to the router's NDP table, and it would DoS the box's own > router if an outbound scan were initiated from the host machine. > Again, you totally fail to understand the problem. =A0I should just > attach a "facepalm" graphic to my reply and stop bothering with your > idiocy, but it is important that as many people as possible understand > these issues. =A0Every additional person who is expressing concern to > their vendors brings us closer to a solution. A bunch of very smart people have worked on IPv6 for a very long time, and justification for /64's was hashed out at extended length over the period of years. A bunch of clever people have worked on things like 4941, people at places like IBM and Microsoft, people who created actual working implementations of these things. A bunch of experienced people have discussed the operational ins and outs. Including myself. We realize that there are both good and bad aspects to pretty much any issue. I certainly said so about this one. I view IPv6 as a mostly-done deal; no major changes are likely to happen. Too many parties have too much invested in all of this. I'm sorry that you missed out on all of that. But. Calling it "my" idiocy? "Facepalm" graphic? Brilliant discussion technique. If you can't discuss this on the merits and concede that there are other valid points of view, please hang up and go bother someone else. I hear Jim Fleming's available. ... 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 rdobbins at arbor.net Thu Jan 6 00:36:07 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 6 Jan 2011 06:36:07 +0000 Subject: NIST IPv6 document In-Reply-To: <201101060626.p066Q4ak088421@aurora.sol.net> References: <201101060626.p066Q4ak088421@aurora.sol.net> Message-ID: On Jan 6, 2011, at 1:26 PM, Joe Greco wrote: > A bunch of very smart people have worked on IPv6 for a very long time, and justification for /64's was hashed out at extended length > over the period of years. Very smart people can and do come up with bad ideas, and IPv6 is a textbook example of this phenomenon, heh. I certainly bear my share of the responsibility for this state of affairs by not getting involved, and leaving the heavy lifting to others. > Calling it "my" idiocy? "Facepalm" graphic? Concur 100% - I respectfully disagree with you on substantial aspects of the IPv6 situation, and am in substantive agreement with Jeff on most aspects which have been discussed on this thread - but you're *far* from an idiot, heh. You're also entirely correct that we need to ensure that our passions and mutual frustrations don't lead us into ad hominem attacks; security is an area which attracts people of a passionate bent, and it's important that we don't end up in a pointless flame-war. ------------------------------------------------------------------------ Roland Dobbins // Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay From morrowc.lists at gmail.com Thu Jan 6 00:43:23 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 6 Jan 2011 01:43:23 -0500 Subject: AltDB? In-Reply-To: <734B46C1-AE6C-406A-8163-00CFFE942B1B@virtualized.org> References: <94F3F129-608E-46EC-B157-CC23CAA47454@tozz.net> <4D24A734.3000807@jcoley.net> <816AB912-14CF-4028-853A-F0BE77D2EB09@puck.nether.net> <734B46C1-AE6C-406A-8163-00CFFE942B1B@virtualized.org> Message-ID: On Thu, Jan 6, 2011 at 1:21 AM, David Conrad wrote: > On Jan 5, 2011, at 12:32 PM, Randy Bush wrote: >> i have a rumor that arin is delaying and possibly not doing rpki that >> seems to have been announced on the ppml list (to which i do not >> subscribe). > > I heard about the delay, but not about ARIN possibly not doing RPKI. That would be ... surprising. ?While I have always had some questions regarding the political (not technical) feasibility of actually deploying secure routing based on the top-down hierarchical model assumed by RPKI, it seems obvious to me that there needs to be a better way to authenticate allocation data other than querying a whois server. ?RPKI will (would have?) provided this and the actual deployment of RPKI would allow the ops community to gain experience with the technology. pls express this to your local BoT or AC or ARIN Rep... see the other thread. thanks! -Chris From randy at psg.com Thu Jan 6 00:44:46 2011 From: randy at psg.com (Randy Bush) Date: Thu, 06 Jan 2011 15:44:46 +0900 Subject: AltDB? In-Reply-To: <734B46C1-AE6C-406A-8163-00CFFE942B1B@virtualized.org> References: <94F3F129-608E-46EC-B157-CC23CAA47454@tozz.net> <4D24A734.3000807@jcoley.net> <816AB912-14CF-4028-853A-F0BE77D2EB09@puck.nether.net> <734B46C1-AE6C-406A-8163-00CFFE942B1B@virtualized.org> Message-ID: > I heard about the delay, but not about ARIN possibly not doing RPKI. there are arin board members, one in particular i am told, that do not like the rpki. including side contracts to turn the irr pig's ear into a silk purse. randy From ryan.finnesey at HarrierInvestments.com Thu Jan 6 00:46:47 2011 From: ryan.finnesey at HarrierInvestments.com (Ryan Finnesey) Date: Wed, 5 Jan 2011 22:46:47 -0800 Subject: Clearwire/Clear for branch office connectivity? In-Reply-To: References: Message-ID: <6EFFEFBAC68377459A2E972105C759EC0342B635@EXVBE005-2.exch005intermedia.net> We use it for some of our juice bar operations but we buy the service from Sprint. We have been very happy with the service. Cheers Ryan -----Original Message----- From: Brandon Galbraith [mailto:brandon.galbraith at gmail.com] Sent: Wednesday, January 05, 2011 5:16 PM To: nanog at nanog.org Subject: Clearwire/Clear for branch office connectivity? Is anyone using Clearwire/Clear's wireless broadband offering for stationary branch offices/remote equipment monitoring? Looking for results/experiences off-list. We're looking at it for industrial telemetry, and have spoken to people using ATT and VZW who are doing the same, but we wanted to look at Clear as well. Curious as to reliability, link performance, and support quality. Thanks! Brandon -- Brandon Galbraith US Voice: 630.492.0464 From fergdawgster at gmail.com Thu Jan 6 00:47:02 2011 From: fergdawgster at gmail.com (Paul Ferguson) Date: Wed, 5 Jan 2011 22:47:02 -0800 Subject: NIST IPv6 document In-Reply-To: References: <201101060626.p066Q4ak088421@aurora.sol.net> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Jan 5, 2011 at 10:36 PM, Dobbins, Roland wrote: > > On Jan 6, 2011, at 1:26 PM, Joe Greco wrote: > >> A bunch of very smart people have worked on IPv6 for a very long time, >> and justification for /64's was hashed out at extended length over the >> period of years. > > Very smart people can and do come up with bad ideas, and IPv6 is a > textbook example of this phenomenon, heh. I certainly bear my share of > the responsibility for this state of affairs by not getting involved, and > leaving the heavy lifting to others. > As someone who has been immersed in security for many years now, and having previously been very intimately involved in the network ops community for equally many years, I have to agree with Roland here. Just because a lot of smart people have worked on IPv6 for many years does not mean that the security issues have been equally well thought out. I see this as very similar to all IP technology evolution issues -- none of which ever really focused on the dedicated attacker/criminal using the same technology to attack/defraud/hijack/etc. This is not meant as a slight to anyone -- just a realization of looking at security from a real-world perspective. It seems to always have to get "bolted on" as an afterthought, instead of baked-in from the beginning. $.02, - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFNJWVcq1pz9mNUZTMRAtimAJ4xWmqbP4Or5KFnonDW8XtOMMvMjgCcCswk 9JDJXNyDgUV4RnZlfDcBges= =KKZ+ -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson ?Engineering Architecture for the Internet ?fergdawgster(at)gmail.com ?ferg's tech blog: http://fergdawg.blogspot.com/ From jgreco at ns.sol.net Thu Jan 6 00:51:44 2011 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 6 Jan 2011 00:51:44 -0600 (CST) Subject: NIST IPv6 document In-Reply-To: <1F3A01A3-A244-416E-85D8-74CCBA253AAC@arbor.net> Message-ID: <201101060651.p066piXN088758@aurora.sol.net> > On Jan 6, 2011, at 12:54 PM, Joe Greco wrote: > > > Generally speaking, security professionals prefer for there to be more ro= > adblocks rather than fewer. =20 > > The soi-disant security 'professionals' who espouse layering unnecessary mu= > ltiple, inefficient, illogical, and iatrogenic roadblocks in preference to = > expending the time and effort to learn enough about *actual* security (in c= > ontrast to security theater) to Do Things Right The First Time, aren't wort= > hy of the title and ought to be ignored, IMHO. > > > If it is, and the address becomes virtually impossible to find, then we'v= > e just defeated an attack, and it's hard to see that as anything but positi= > ve. > > If we had some cheese, we could make a ham-and-cheese sandwich, if we had s= > ome ham. > > ;> > > We must face up to the reality that the endpoint *will be found*, irrespect= > ive of the relative sparseness or density of the addressing plan. It will = > be found via DNS, via narrowing the search scope via examining routing adve= > rtisements, via narrowing the search scope via perusing whois, via the atta= > ckers simply throwing more of their near-infinite scanning resources (i.e.,= > bots) at these dramatically-reduced search scopes. > > So, the endpoint will be found, no attack will be prevented, and we end up = > a) wasting wide swathes of address space for no good reason whilst b) makin= > g the routing/switching infrastructure elements far more vulnerable to DoS = > by turning them into sinkholes. That's, simply put, a poor argument. And here's why. There are numerous parallels between physical and electronic security. Let's just concede that for a moment. You put up a screen door. I've got a knife. You put up a wood door. I've got steel toed boots. You put up a metal door. I've got a crowbar. You put up a bank vault door. I (can find someone who can get) explosives. The thing is, it may not make a whole heck of a lot of sense to put a screen door on a bank's vault, or a vault door on your front screen porch. Even so, while you can increase the strength of a particular countermeasure, maybe it isn't smart to rely entirely on that one countermeasure, or even two or three countermeasures. A bank may have an armed guard, a silent alarm, video surveillance, bulletproof glass, dye packs in the tills, cash in a timelocked vault, and all sorts of other countermeasures to address specific areas of threat. Not all countermeasures are going to be effective against every threat, and there is no requirement that only one countermeasure be applied towards a given threat. Further, there's no guarantee that the countermeasures are going to be properly installed or appropriate to the task - which seems to be your objection to "soi-disant security 'professionals'" - but on the other hand, in many cases, they *are* properly installed and well considered. To say that "the endpoint *will be found*" is a truism, in the same way that a bank *will* be robbed. You're not trying to guarantee that it will never happen. You're trying to *deter* the bad guys. You want the bad guy to go across the street to the less-well-defended bank across the street. You can't be sure that they'll do that. Someone who has it out for you and your bank will rob your bank (or end up in jail or dead or whatever). But you can scare off the guy who's just looking to score a few thousand in easy cash. Making it harder to scan a network *can* and *does* deter certain classes of attacks. That it doesn't prevent every attack isn't a compelling proof that it doesn't prevent some, and I have to call what you said a poor argument for that reason. ... 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 mpetach at netflight.com Thu Jan 6 01:03:44 2011 From: mpetach at netflight.com (Matthew Petach) Date: Wed, 5 Jan 2011 23:03:44 -0800 Subject: NIST IPv6 document In-Reply-To: <201101060651.p066piXN088758@aurora.sol.net> References: <1F3A01A3-A244-416E-85D8-74CCBA253AAC@arbor.net> <201101060651.p066piXN088758@aurora.sol.net> Message-ID: On Wed, Jan 5, 2011 at 10:51 PM, Joe Greco wrote: >> On Jan 6, 2011, at 12:54 PM, Joe Greco wrote: ... > To say that "the endpoint *will be found*" is a truism, in the same > way that a bank *will* be robbed. ?You're not trying to guarantee that > it will never happen. ?You're trying to *deter* the bad guys. ?You want > the bad guy to go across the street to the less-well-defended bank > across the street. ?You can't be sure that they'll do that. ?Someone > who has it out for you and your bank will rob your bank (or end up > in jail or dead or whatever). ?But you can scare off the guy who's > just looking to score a few thousand in easy cash. > > Making it harder to scan a network *can* and *does* deter certain > classes of attacks. ?That it doesn't prevent every attack isn't a > compelling proof that it doesn't prevent some, and I have to call what > you said a poor argument for that reason. Hi Joe, I think what people are trying to say is that it doesn't matter whether or not your host is easily findable or not, if I can trivially take out your upstream router. With your upstream router out of commission, the findability of your host on the subnet really doesn't matter. Once the router is gone, so is your host, no matter how well hidden on the subnet it was. So, the push here is to prevent the trivial ability to take out the upstream routers, so that the host-level issues will still matter, and be worth discussing. Hope this helps clarify the reason for the overarching concern about the /64 subnet size. Thanks!! Matt > ... 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 rdobbins at arbor.net Thu Jan 6 01:09:38 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 6 Jan 2011 07:09:38 +0000 Subject: NIST IPv6 document In-Reply-To: References: <1F3A01A3-A244-416E-85D8-74CCBA253AAC@arbor.net> <201101060651.p066piXN088758@aurora.sol.net> Message-ID: <965BBCFE-47B6-4F96-A158-FCF0215378C2@arbor.net> On Jan 6, 2011, at 2:03 PM, Matthew Petach wrote: > I think what people are trying to say is that it doesn't matter whether or not your host is easily findable or not, if I can trivially take out your > upstream router. That's part of it - the other part is that the host will be found, irrespective of attempts to 'hide' it. ------------------------------------------------------------------------ Roland Dobbins // Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay From drc at virtualized.org Thu Jan 6 01:12:35 2011 From: drc at virtualized.org (David Conrad) Date: Wed, 5 Jan 2011 21:12:35 -1000 Subject: AltDB? In-Reply-To: References: <94F3F129-608E-46EC-B157-CC23CAA47454@tozz.net> <4D24A734.3000807@jcoley.net> <816AB912-14CF-4028-853A-F0BE77D2EB09@puck.nether.net> <734B46C1-AE6C-406A-8163-00CFFE942B1B@virtualized.org> Message-ID: <0B00C5FF-84B2-436B-8DB1-A1BA7DF90038@virtualized.org> On Jan 5, 2011, at 8:43 PM, Christopher Morrow wrote: > pls express this to your local BoT or AC or ARIN Rep... see the other thread. As I am not an ARIN member nor do I have any ARIN-delegated resources, it isn't clear to me who my local BoT/AC/ARIN Rep might be. However, as I'm aware some of the folks you mention are on NANOG, I suspect they might have seen my comment (FWIW). Regards, -drc From joelja at bogus.com Thu Jan 6 01:42:29 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Wed, 05 Jan 2011 23:42:29 -0800 Subject: NIST IPv6 document In-Reply-To: References: <1F3A01A3-A244-416E-85D8-74CCBA253AAC@arbor.net> <201101060651.p066piXN088758@aurora.sol.net> Message-ID: <4D257265.5000804@bogus.com> On 1/5/11 11:03 PM, Matthew Petach wrote: > On Wed, Jan 5, 2011 at 10:51 PM, Joe Greco wrote: > Hi Joe, > > I think what people are trying to say is that it doesn't matter whether > or not your host is easily findable or not, if I can trivially take out your > upstream router. With your upstream router out of commission, the > findability of your host on the subnet really doesn't matter. Once the > router is gone, so is your host, no matter how well hidden on the > subnet it was. > > So, the push here is to prevent the trivial ability to take out the > upstream routers, so that the host-level issues will still matter, and > be worth discussing. icmp6 rate limiting both reciept and origination is not rocket science. The attack that's being described wasn't exactly dreamed up last week, is as observed not unique to ipv6, and can be mitigated. I'd encourage you to go look at rfc 3756 rfc 4443 and probably elsewhere including, the manual for your router os of choice and possibly your account rep if you don't get the kind of satisfaction you expect. We can probably do better still... > Hope this helps clarify the reason for the overarching concern > about the /64 subnet size. You can still have this problem when you assign a bunch of /112s how many neighbor unreachable entries per interface can your fib hold? > Thanks!! > > Matt > >> ... 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 joelja at bogus.com Thu Jan 6 01:46:06 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Wed, 05 Jan 2011 23:46:06 -0800 Subject: NIST IPv6 document In-Reply-To: References: <201101060626.p066Q4ak088421@aurora.sol.net> Message-ID: <4D25733E.30602@bogus.com> On 1/5/11 10:36 PM, Dobbins, Roland wrote: > > On Jan 6, 2011, at 1:26 PM, Joe Greco wrote: > >> A bunch of very smart people have worked on IPv6 for a very long >> time, and justification for /64's was hashed out at extended >> length over the period of years. > > Very smart people can and do come up with bad ideas, and IPv6 is a > textbook example of this phenomenon, heh. I certainly bear my share > of the responsibility for this state of affairs by not getting > involved, and leaving the heavy lifting to others. The reason for standing on the shoulders of giants should not be to piss on them. From rdobbins at arbor.net Thu Jan 6 01:47:15 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 6 Jan 2011 07:47:15 +0000 Subject: NIST IPv6 document In-Reply-To: <4D257265.5000804@bogus.com> References: <1F3A01A3-A244-416E-85D8-74CCBA253AAC@arbor.net> <201101060651.p066piXN088758@aurora.sol.net> <4D257265.5000804@bogus.com> Message-ID: <124E2841-40A7-45B1-8DFA-92B92F30384C@arbor.net> On Jan 6, 2011, at 2:42 PM, Joel Jaeggli wrote: > icmp6 rate limiting both reciept and origination is not rocket science. But it's *considerably* more complex and has far more potential implications than ICMP rate-limiting in IPv4 (which in and of itself is more complex and has more implications than a lot of folks realize, present company excepted). ------------------------------------------------------------------------ Roland Dobbins // Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay From rdobbins at arbor.net Thu Jan 6 01:50:17 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 6 Jan 2011 07:50:17 +0000 Subject: NIST IPv6 document In-Reply-To: <201101060651.p066piXN088758@aurora.sol.net> References: <201101060651.p066piXN088758@aurora.sol.net> Message-ID: <969A43C1-F11D-425A-B210-1721F893C24B@arbor.net> On Jan 6, 2011, at 1:51 PM, Joe Greco wrote: > There are numerous parallels between physical and electronic security. > Let's just concede that for a moment. I can't, and here's why: 1. In the physical world, attackers run a substantial risk of being caught, and of tangible, severe penalties if that eventuality comes to pass; in the online world, the risk of being caught is nil. 2. In the physical world, attackers have a limited number and variety of resources they can bring to bear; in the online world, the attackers have near-infinite resources, for all practical purposes. 3. In the physical world, the attackers generally don't posses the ability nor the desire to bring the whole neighborhood crashing down around the ears of the defenders; in the online world, they almost always have the ability, and often the desire, to do just that. > Making it harder to scan a network *can* and *does* deter certain classes of attacks. But as I've tried to make clear, a) I don't believe that sparse addressing does in fact make it harder to scan the network, due to hinted scanning via DNS/routing/whois/ND/multicast, b) I believe that pushing the attackers towards hinted scanning will have severe second-order deleterious effects on DNS/network infrastructure/whois, resulting in an overall loss in terms of security posture, and c) I don't believe that attackers will cease pseudo-randomized scanning, and d) I believe that in fact they will throw vastly more resources at both hinted and pseudo-randomized scanning, that they have near-infinite resources at their disposal (with an ever-expanding pool of potential resources to harness), and that the resultant increase in scanning activity will also have severely deleterious second-order effects on the security posture of the Internet as a whole. In short, I'm starting from a substantially different, far more pessimistic set of base premises, and therefore draw a far more negative set of resulting inferences. I don't believe the sky is falling; I believe it's already fallen, and that we're just now starting to come to grips with some of the ramifications of its fall. In my view, an IPv6 Internet is considerably less secure, and inherently less securable, than the present horribly insecure and barely securable IPv4 Internet; furthermore, I believe that many of the supposed 'security' measures being touted for IPv6 are at best placebos, and at worst are iatrogenic in nature. ------------------------------------------------------------------------ Roland Dobbins // Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay From fergdawgster at gmail.com Thu Jan 6 01:52:58 2011 From: fergdawgster at gmail.com (Paul Ferguson) Date: Wed, 5 Jan 2011 23:52:58 -0800 Subject: NIST IPv6 document In-Reply-To: <4D25733E.30602@bogus.com> References: <201101060626.p066Q4ak088421@aurora.sol.net> <4D25733E.30602@bogus.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Jan 5, 2011 at 11:46 PM, Joel Jaeggli wrote: > On 1/5/11 10:36 PM, Dobbins, Roland wrote: >> >> On Jan 6, 2011, at 1:26 PM, Joe Greco wrote: >> >>> A bunch of very smart people have worked on IPv6 for a very long >>> time, and justification for /64's was hashed out at extended >>> length over the period of years. >> >> Very smart people can and do come up with bad ideas, and IPv6 is a >> textbook example of this phenomenon, heh. I certainly bear my share >> of the responsibility for this state of affairs by not getting >> involved, and leaving the heavy lifting to others. > > The reason for standing on the shoulders of giants should not be to piss > on them. > > I sense an unnecessary level of acrimony here. No one is pissing on the work done by the many folks who have spent many years hashing out v6 work. But I think you are missing a larger point -- much of the security community has been summarily dismissed in its concerns along the way. $.02, - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFNJXTUq1pz9mNUZTMRAs9BAKDh1N+BJFgmbROPSIOf+rM5v+Ol1ACbBfcr qXiMOvfkjLtTaQX55I+Sc2U= =aFv3 -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson ?Engineering Architecture for the Internet ?fergdawgster(at)gmail.com ?ferg's tech blog: http://fergdawg.blogspot.com/ From joe at nethead.com Thu Jan 6 02:07:03 2011 From: joe at nethead.com (Joe Hamelin) Date: Thu, 6 Jan 2011 00:07:03 -0800 Subject: Clearwire/Clear for branch office connectivity? In-Reply-To: <6EFFEFBAC68377459A2E972105C759EC0342B635@EXVBE005-2.exch005intermedia.net> References: <6EFFEFBAC68377459A2E972105C759EC0342B635@EXVBE005-2.exch005intermedia.net> Message-ID: Since I'm not with Clearwire anymore (end of contract) I can say that there are people in the core networking that do follow and respond the this list. I can say that their backbone is solid and the people there really do care about the network. If you have serious a backbone issue with Clearwire a message on this list will result in a response.. -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 From tariq198487 at hotmail.com Thu Jan 6 02:21:56 2011 From: tariq198487 at hotmail.com (Tarig Ahmed) Date: Thu, 6 Jan 2011 11:21:56 +0300 Subject: Spamming and ssh attack from a customers Message-ID: hi all I am receiving emails from many servers saying that: this ip (from a customer) is trying to attacking one of our servers. Is it appropriate to filter ssh, telnet, and smtp from my customers, or just forward the message to my customer contact persons? Thanks in advance.. Tarig Yassin Ahmed From jsw at inconcepts.biz Thu Jan 6 02:24:57 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Thu, 6 Jan 2011 03:24:57 -0500 Subject: NIST IPv6 document In-Reply-To: <4D257265.5000804@bogus.com> References: <1F3A01A3-A244-416E-85D8-74CCBA253AAC@arbor.net> <201101060651.p066piXN088758@aurora.sol.net> <4D257265.5000804@bogus.com> Message-ID: On Thu, Jan 6, 2011 at 2:42 AM, Joel Jaeggli wrote: > icmp6 rate limiting both reciept and origination is not rocket science. > The attack that's being described wasn't exactly dreamed up last week, > is as observed not unique to ipv6, and can be mitigated. That does not solve the problem. Your response, like most on this thread, clearly indicates that you do not understand the underlying issue, or how traffic is actually forwarded. Neither IPv6 or IPv4 packets are simply forwarded onto the Ethernet, which is why the ARP/NDP table resource is required; a mapping from layer-3 to layer-2 address is needed. If the table resource for these entries is exhausted, no new mappings can be learned, and bad things happen. Either hosts on the specif interface, or the entire box, can no longer exchange traffic through the router. If an artificial rate-limit on discovery traffic is reached, discovery of mappings will also be impeded, meaning the denial-of-service condition exists and persists until the attack ceases. This may also affect either just that interface, or all interfaces on the router, depending on its failure mode. Rate-limiting discovery traffic still breaks the attached LANs. How badly it breaks them is implementation-specific. It does avoid using up all the router's CPU, but that doesn't help the hosts which can't exchange traffic. Again, depending on the router implementation, the fraction of hosts which cannot exchange traffic may reach 100%, and in effect, the router might as well be down. > You can still have this problem when you assign a bunch of /112s how > many neighbor unreachable entries per interface can your fib hold? You are correct, but the device can hold a significant number of entries compared to the size of a /112 subnet, just like it can hold a significant number of v4 ARP entries compared to a v4 /22 subnet. The difference is, ARP/NDP mappings for one /64 subnet can fill all the TCAM resources of any router that will ever exist. This is why more knobs are needed, and until we have that, the /64 approach is fundamentally broken. Again, until this problem is better-understood, it will not be solved. Right now, there are many vulnerable networks; and in some platforms running a dual-stack configuration, filling up the v6 NDP table will also impact v4 ARP. This means the problem is not confined to a cute beta-test that your customers are just starting to ask about; it will also take out your production v4 network. If you are running a dual-stack network with /64 LANs, you had better start planning. It's not just a problem on the horizon, it's a problem right now for many early-adopters. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From mike-nanog at tiedyenetworks.com Thu Jan 6 02:26:24 2011 From: mike-nanog at tiedyenetworks.com (Mike) Date: Thu, 06 Jan 2011 00:26:24 -0800 Subject: Spamming and ssh attack from a customers In-Reply-To: References: Message-ID: <4D257CB0.5000807@tiedyenetworks.com> On 01/06/2011 12:21 AM, Tarig Ahmed wrote: > hi all > > I am receiving emails from many servers saying that: this ip (from a > customer) is trying to attacking one of our servers. > > Is it appropriate to filter ssh, telnet, and smtp from my customers, or > just forward the message to my customer contact persons? > Depends on your acceptable use policy and terms of service. I would say trying to micromanage the ip protos being used for these attacks is just creating work for you - if they are the source, and you have credible reports, then the customer should be notified and they should commit to resolving the problem. If they won't or aren't able to respond effectively, I would say that (depdning on the who and what of your customer), shutting down the port may be a viable next step. Mike- From tariq198487 at hotmail.com Thu Jan 6 02:43:18 2011 From: tariq198487 at hotmail.com (Tarig Yassin) Date: Thu, 6 Jan 2011 11:43:18 +0300 Subject: FW: Spamming and ssh attack from a customers In-Reply-To: <4D257CB0.5000807@tiedyenetworks.com> References: , <4D257CB0.5000807@tiedyenetworks.com> Message-ID: > Depends on your acceptable use policy and terms of service. > If they won't or aren't able to respond effectively, I would say that (depdning on the who and what of your > customer), shutting down the port may be a viable next step. > Hi mike In our case, the AUP gives us the right to do so, and some customers are not able. Is possible to deligate this issue to them (Through RIRs databeses, emails will be sent to them directly not through us)? without new ASN and BGP requirements? thanks -- Tarig Y. Adam SUIN www.suin.edu.sd > Date: Thu, 6 Jan 2011 00:26:24 -0800 > From: mike-nanog at tiedyenetworks.com > To: nanog at nanog.org > Subject: Re: Spamming and ssh attack from a customers > > On 01/06/2011 12:21 AM, Tarig Ahmed wrote: > > hi all > > > > I am receiving emails from many servers saying that: this ip (from a > > customer) is trying to attacking one of our servers. > > > > Is it appropriate to filter ssh, telnet, and smtp from my customers, or > > just forward the message to my customer contact persons? > > > > Depends on your acceptable use policy and terms of service. I would say > trying to micromanage the ip protos being used for these attacks is just > creating work for you - if they are the source, and you have credible > reports, then the customer should be notified and they should commit to > resolving the problem. If they won't or aren't able to respond > effectively, I would say that (depdning on the who and what of your > customer), shutting down the port may be a viable next step. > > Mike- > > From marka at isc.org Thu Jan 6 03:00:04 2011 From: marka at isc.org (Mark Andrews) Date: Thu, 06 Jan 2011 20:00:04 +1100 Subject: Problems with removing NAT from a network In-Reply-To: Your message of "Wed, 05 Jan 2011 22:08:35 -0800." References: <4D252B1F.8030506@kenweb.org> <3DFD6833-78C1-43D2-8074-6C89CFE3F2F3@arbor.net> <20110106043110.21C96876D21@drugs.dv.isc.org> <4D254ED8.6030006@matthew.at> <20110106055559.9C9F687D1C9@drugs.dv.isc.org> Message-ID: <20110106090004.EBCD887DD06@drugs.dv.isc.org> In message , Came ron Byrne writes: > On Wed, Jan 5, 2011 at 9:55 PM, Mark Andrews wrote: > > > > In message l.com>, Came > > ron Byrne writes: > >> As long as dual-stack is around, the app vendors don't have to move > >> and network guys have to dream up hacks to support these legacy apps > >> (CGN ....). > > > > NAT64 is CGN expecially when it is being implemented by the cellular > > carriers. > > > > Agreed. And, the NAT44 that 99% of my customer use to today is also a CGN. > > It's status quo, all v4 flows require state in my network, NAT44 or NAT64. > > But, NAT64 has an exit strategy. With every new AAAA that comes out, > that is one less destination requiring state in my network. I will give you that it is easy to see with NAT64 when the target space has moved. It also forces you to upgrade all client applications to support IPv6 from the start. Anyway its horses for courses. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From wbachman at leepfrog.com Thu Jan 6 03:05:00 2011 From: wbachman at leepfrog.com (Wes Bachman) Date: Thu, 06 Jan 2011 03:05:00 -0600 Subject: Qwest access problems Message-ID: <1294304700.9685.11.camel@bsa.wesnet.com> Anyone seeing problems with Qwest access circuits this evening? Our AT&T GigE circuit with Qwest LEC has bounced twice. Oddly when I went to check it out from home, my Qwest DSL was down at the exact same time, and appeared to come back up at around the same time. I'm in eastern Iowa. I haven't heard anything from Qwest or AT&T so far, and received no notice of any planned maintenance? -Wes Bachman Leepfrog Technologies, Inc. From marka at isc.org Thu Jan 6 03:11:17 2011 From: marka at isc.org (Mark Andrews) Date: Thu, 06 Jan 2011 20:11:17 +1100 Subject: Spamming and ssh attack from a customers In-Reply-To: Your message of "Thu, 06 Jan 2011 11:21:56 +0300." References: Message-ID: <20110106091117.6D42687E19C@drugs.dv.isc.org> In message , Tarig Ahmed writes: > hi all > > I am receiving emails from many servers saying that: this ip (from a > customer) is trying to attacking one of our servers. > > Is it appropriate to filter ssh, telnet, and smtp from my customers, > or just forward the message to my customer contact persons? I suspect that your customer is compromised and you should put them in a walled garden until they fix the problem. Look at traffic flows first however. > Thanks in advance.. > > Tarig Yassin Ahmed -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From joelja at bogus.com Thu Jan 6 03:32:02 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Thu, 06 Jan 2011 01:32:02 -0800 Subject: NIST IPv6 document In-Reply-To: References: <1F3A01A3-A244-416E-85D8-74CCBA253AAC@arbor.net> <201101060651.p066piXN088758@aurora.sol.net> <4D257265.5000804@bogus.com> Message-ID: <4D258C12.2090907@bogus.com> On 1/6/11 12:24 AM, Jeff Wheeler wrote: > On Thu, Jan 6, 2011 at 2:42 AM, Joel Jaeggli wrote: >> icmp6 rate limiting both reciept and origination is not rocket science. >> The attack that's being described wasn't exactly dreamed up last week, >> is as observed not unique to ipv6, and can be mitigated. > > That does not solve the problem. Your response, like most on this > thread, clearly indicates that you do not understand the underlying > issue, or how traffic is actually forwarded. Neither IPv6 or IPv4 > packets are simply forwarded onto the Ethernet, which is why the > ARP/NDP table resource is required; a mapping from layer-3 to layer-2 > address is needed. You seem hell bent on telling me what I do and don't know. I know how they're created. > If the table resource for these entries is > exhausted, no new mappings can be learned, Which at a minimum is why you want to police the number of nd messages that the device sends and unreachable entries do not simply fill up the nd cache, such that new mappings in fact can be learned because there are free entries. you need to do this on a per subnet basis rather than globally. as in ipv4 policing, global limits will kill the boxes ability to learn new entries everywhere. > and bad things happen. > Either hosts on the specif interface, or the entire box, can no longer > exchange traffic through the router. If an artificial rate-limit on > discovery traffic is reached, discovery of mappings will also be > impeded, meaning the denial-of-service condition exists and persists > until the attack ceases. This may also affect either just that > interface, or all interfaces on the router, depending on its failure > mode. > > Rate-limiting discovery traffic still breaks the attached LANs. How > badly it breaks them is implementation-specific. It does avoid using > up all the router's CPU, but that doesn't help the hosts which can't > exchange traffic. Again, depending on the router implementation, the > fraction of hosts which cannot exchange traffic may reach 100%, and in > effect, the router might as well be down. > >> You can still have this problem when you assign a bunch of /112s how >> many neighbor unreachable entries per interface can your fib hold? > > You are correct, but the device can hold a significant number of > entries compared to the size of a /112 subnet, a /112 is 16 bits. just like it can hold a > significant number of v4 ARP entries compared to a v4 /22 subnet. I've got this lovely ex8208 here, a quick glance as the specs says 100k arp entries per linecard. that requires some sensible configuration from the outset otherwise shooting yourself in the foot with ipv4 is possible. I've done it both deliberately and on accident and I have better rules now. > The > difference is, ARP/NDP mappings for one /64 subnet can fill all the > TCAM resources of any router that will ever exist. the arp mappings for an ipv4 /15 will fill up the device today. > This is why more > knobs are needed, and until we have that, the /64 approach is > fundamentally broken. as with anything sent to into the control plane it needs to be policed there are sensible ways to do that today, they can improve. > Again, until this problem is better-understood, it will not be solved. > Right now, there are many vulnerable networks; and in some platforms > running a dual-stack configuration, filling up the v6 NDP table will > also impact v4 ARP. This means the problem is not confined to a cute > beta-test that your customers are just starting to ask about; it will > also take out your production v4 network. If you are running a > dual-stack network with /64 LANs, you had better start planning. It's > not just a problem on the horizon, it's a problem right now for many > early-adopters. > From owen at delong.com Thu Jan 6 04:20:26 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 6 Jan 2011 02:20:26 -0800 Subject: NIST IPv6 document In-Reply-To: References: <20110105043548.BC01B1CC3E@ptavv.es.net> <7BA6E87C-7CAD-44DD-BBC1-58DDADD458D5@muada.com> Message-ID: <9E037230-A441-4BD9-B07D-1F6AB7ED5090@delong.com> > > On Wed, Jan 5, 2011 at 9:39 AM, Iljitsch van Beijnum wrote: >> A (relatively) easy way to avoid this problem is to either use a stateful firewall that only allows internally initiated sessions, or a filter that lists only addresses that are known to be in use. > > It would certainly be nice to have a stateful firewall on every single > LAN connection. Were there high-speed, stateful firewalls in 1994? > Perhaps the IPng folks had this solution in mind, but left it out of > the standards process. No doubt they all own stock in SonicWall and > are eagerly awaiting the day when "Anonymous" takes down a major ISP > every day with a simple attack that has been known to exist, but not > addressed, for many years. > > You must also realize that the stateful firewall has the same problems Uh, not exactly... > as the router. It must include a list of allocated IPv6 addresses on > each subnet in order to be able to ignore other traffic. While this Uh, no it doesn't. It just needs a list of the hosts which are permitted to receive inbound connections from the outside. That's the whole point of the stateful in stateful firewall... It can dynamically allow outbound sessions and only needs to be open for hosts that are supposed to receive external session initiations. Since that list is relatively small and you probably need to maintain it anyway, I'm not really seeing a problem here. > can certainly be accomplished, it would be much easier to simply list > those addresses in the router, which would avoid the expense of any > product typically called a "stateful firewall." In either case, you > are now maintaining a list of valid addresses for every subnet on the > router, and disabling NDP for any other addresses. I agree with you, > this knob should be offered by vendors in addition to my list of > possible vendor solutions. > Except that routers don't (usually) have the ability to do dynamic outbound filtration which means that you have the scaling problem you've described of having to list every host on the net. If the router does have this ability, then, the router is, by definition, a stateful firewall. > On Wed, Jan 5, 2011 at 9:39 AM, Iljitsch van Beijnum wrote: >> Sparse subnets in IPv6 are a feature, not a bug. They're not going to go away. > > I do not conceptually disagree with sparse subnets. With the > equipment limitations of today, they are a plan to fail. Let's hope > that all vendors catch up to this before malicious people/groups. > There are risks with sparse subnets that have been inadequately addressed for some of their failure modes at this time. I wouldn't go so far as saying they are a plan to fail. In most cases, most networks shouldn't be susceptible to an externally initiated ND attack in the first place because those should mostly be blocked at your border except for hosts that provide services to the larger internet. Owen From owen at delong.com Thu Jan 6 04:29:11 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 6 Jan 2011 02:29:11 -0800 Subject: NIST IPv6 document In-Reply-To: References: <20110105043548.BC01B1CC3E@ptavv.es.net> <7BA6E87C-7CAD-44DD-BBC1-58DDADD458D5@muada.com> <4D24A4A7.7080208@bogus.com> <20110105172629.GB4613@macbook.catpipe.net> Message-ID: On Jan 5, 2011, at 9:44 AM, Jeff Wheeler wrote: > On Wed, Jan 5, 2011 at 12:26 PM, Phil Regnauld wrote: >> Jeff Wheeler (jsw) writes: >>> Not good, but also does not affect any other interfaces on the router. >> You're assuming that all routing devices have per-interface ARP tables. > > No, Phil, I am assuming that the routing device has a larger ARP table > than 250 entries. To be more correct, I am assuming that the routing > device has a large enough ARP table that any one subnet could go from > 0 ARP entries to 100% ARP entries without using up all the remaining > ARP resources on the box. This is usually true. Further, routing > devices usually have enough ARP table space that every subnet attached > to them could be 100% full of active ARP entries without using up all > the ARP resources. This is also often true. But, Jeff, if the router has a bunch of /24s attached to it and you scan them all, the problem is much larger than 250 arp entries. I think that's what Phil was getting at. Owen From regnauld at nsrc.org Thu Jan 6 04:41:17 2011 From: regnauld at nsrc.org (Phil Regnauld) Date: Thu, 6 Jan 2011 11:41:17 +0100 Subject: NIST IPv6 document In-Reply-To: References: <7BA6E87C-7CAD-44DD-BBC1-58DDADD458D5@muada.com> <4D24A4A7.7080208@bogus.com> <20110105172629.GB4613@macbook.catpipe.net> Message-ID: <20110106104112.GD7950@macbook.catpipe.net> Owen DeLong (owen) writes: > > But, Jeff, if the router has a bunch of /24s attached to it and you scan > them all, the problem is much larger than 250 arp entries. > > I think that's what Phil was getting at. And so did Joel. If you've got a crapload of VLANs attached to a box, and you're routing these for customers (say, virtual firewall instances), you'll see this easily. I do understand the argument that sweeping a /64 will mean more L3->L2 lookups for directly connected subnets than in v4, but the problem domain remains the same, and I think it's been already explained here that there are various strategies to mitigate this. Additionnally I believe the size of typical recommended IPv6 space will probably discourage idle scanning, though this may change as the resources available increase, as Joe G. pointed out. If it does not, we'll have to address it if the existing mitigation techniques aren't sufficient. Phil From jsw at inconcepts.biz Thu Jan 6 04:54:47 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Thu, 6 Jan 2011 05:54:47 -0500 Subject: NIST IPv6 document In-Reply-To: <4D258C12.2090907@bogus.com> References: <1F3A01A3-A244-416E-85D8-74CCBA253AAC@arbor.net> <201101060651.p066piXN088758@aurora.sol.net> <4D257265.5000804@bogus.com> <4D258C12.2090907@bogus.com> Message-ID: On Thu, Jan 6, 2011 at 4:32 AM, Joel Jaeggli wrote: > Which at a minimum is why you want to police the number of nd messages > that the device sends and unreachable entries do not simply fill up the > nd cache, such that new mappings in fact can be learned because there Your solution is to break the router (or subnet) with a policer, instead of breaking it with a full table. That is not better; both result in a broken subnet or router. If NDP requires an NDCache with "incomplete" entries to learn new adjacencies, then preventing it from filling up will ... prevent it from learning new adjacencies. Do you see how this is not a solution? > are free entries. you need to do this on a per subnet basis rather than > globally. as in ipv4 policing, global limits will kill the boxes ability > to learn new entries everywhere. Yes, per-subnet/interface limits are absolutely needed, to prevent the entire box from being killed when one subnet/interface becomes impaired. That won't stop attackers from breaking your network, both because one subnet that presumably has production services on it is broken, and because, presumably, the attacker can identify other subnets on the router. Even if not, the problem remains that ... some subnets/interfaces are broken. On Thu, Jan 6, 2011 at 5:20 AM, Owen DeLong wrote: >> You must also realize that the stateful firewall has the same problems > Uh, not exactly... Of course it does. The stateful firewall must either 1) be vulnerable to the same form of NDP attack; or 2) have a list of allocated v6 addresses on the LAN. The reason is simple; a "stateful firewall" is no more able to store a 2**64 table than is a "router." Calling it something different doesn't change the math. If you choose to solve the problem by disabling NDP or allowing NS only for a list of "valid" addresses on the subnet, this can be done by a stateless router just like on a stateful firewall. > Uh, no it doesn't. It just needs a list of the hosts which are permitted > to receive inbound connections from the outside. That's the whole This solution falls apart as soon as there is a compromised host on the LAN, in which case the firewall (or router) NDP table can again be filled completely by that compromised/malicious host. In addition, the "stateful firewall," by virtue of having connection state, does not solve the inbound NDP attack issue. The list of hosts which can result in an NDP NS is whats causes this, and such a list may be present in a stateless router; but in both cases, it needs to be configured. "Stateful firewall" is unfortunately not magic dust that you can sprinkle on any network problem. > Except that routers don't (usually) have the ability to do dynamic outbound > filtration which means that you have the scaling problem you've described > of having to list every host on the net. If the router does have this ability, > then, the router is, by definition, a stateful firewall. As I state above, this capability does not "fix" the problem because the "stateful firewall" can just as easily be subject to DoS. You must have a list of valid v6 hosts on the subnet for your solution to work. > There are risks with sparse subnets that have been inadequately addressed > for some of their failure modes at this time. I wouldn't go so far as saying they > are a plan to fail. In most cases, most networks shouldn't be susceptible > to an externally initiated ND attack in the first place because those should > mostly be blocked at your border except for hosts that provide services > to the larger internet. As you have pointed out, without state information, you can't block this external attack. Even if you have a "stateful firewall," that firewall must itself have a solution for the internally-originated NDP attack. While the problems are slightly different and the internally-originated attack is less likely, both must be solved to ensure a reliable v6 network. The "stateful firewall" only solves half the problem and remains entirely vulnerable to the other half. On Thu, Jan 6, 2011 at 5:29 AM, Owen DeLong wrote: > But, Jeff, if the router has a bunch of /24s attached to it and you scan > them all, the problem is much larger than 250 arp entries. That depends on how many is "a bunch" and how large is the ARP table on the device. A pizza box layer-3 switch, as I have mentioned, easily holds several thousand entries, modern units upwards of 10,000. That's enough room for several v4 /24 networks. No device has enough for one v6 /64 network. In addition, most of the IPs on your typical /24 networks will be in use routinely (in a hosting environment, anyway) which means that a scan really doesn't generate many new WHO-HAS and incomplete entries, because most layer-2 mappings are already known. Those that aren't fit within the cheap router's resource limitations somewhat easily. On Thu, Jan 6, 2011 at 5:41 AM, Phil Regnauld wrote: > ? ? ? ?Additionnally I believe the size of typical recommended IPv6 space will > ? ? ? ?probably discourage idle scanning, though this may change as the resources > ? ? ? ?available increase, as Joe G. pointed out. ?If it does not, we'll have to > ? ? ? ?address it if the existing mitigation techniques aren't sufficient. It may indeed reduce "idle" or random scanning by agents such as worms. However, it will make intentional, DoS-oriented scanning quite popular. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From ingrid at ripe.net Thu Jan 6 06:28:04 2011 From: ingrid at ripe.net (Ingrid Wijte) Date: Thu, 06 Jan 2011 13:28:04 +0100 Subject: New AS Number Blocks allocated to the RIPE NCC Message-ID: <4D25B554.5060107@ripe.net> Dear Colleagues, The RIPE NCC received the following AS Number Blocks from the IANA in January 2011. 56320-57343 57344-58367 197632-198655 You may want to update your records accordingly. Best regards, Ingrid Wijte Registration Services Assistant Manager RIPE NCC From rs at seastrom.com Thu Jan 6 06:34:33 2011 From: rs at seastrom.com (Robert E. Seastrom) Date: Thu, 06 Jan 2011 07:34:33 -0500 Subject: NIST IPv6 document In-Reply-To: <4661ED7E-A4DA-4CD4-A7EB-C5B2E615F126@delong.com> (Owen DeLong's message of "Wed, 5 Jan 2011 21:25:24 -0800") References: <20110105043548.BC01B1CC3E@ptavv.es.net> <4661ED7E-A4DA-4CD4-A7EB-C5B2E615F126@delong.com> Message-ID: <86zkreb486.fsf@seastrom.com> Owen DeLong writes: > Personally, I think /64 works just fine. I continue to believe that the "allocate the /64, configure the /127 as a workaround for the router vendors' unevolved designs" approach, which Igor and I discovered we were in violent agreement on when on a panel a few NANOGs ago, is the right one. With only between 2^34 and 2^35 neocortical neurons in the average human brain (*), perhaps we ought to be engineering for conserving human brain cells rather than IPv6 addresses. That means encoding metadata in the IPv6 address in an easily visible fashion (such as pop aggregation on nybble boundaries) and having a scheme where all subnets are the same size (and just happen to hold an arbitrary number of hosts). -r (*) a figure that is as irrelevant to the current conversation as Roland's grandstanding about rejecting arguments about the vastness of the IPv6 space out of hand). From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Thu Jan 6 07:18:41 2011 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Thu, 6 Jan 2011 23:48:41 +1030 Subject: NIST IPv6 document In-Reply-To: <20110105175749.GF4613@macbook.catpipe.net> References: <20110105043548.BC01B1CC3E@ptavv.es.net> <7BA6E87C-7CAD-44DD-BBC1-58DDADD458D5@muada.com> <4D24A4A7.7080208@bogus.com> <20110105172629.GB4613@macbook.catpipe.net> <20110105175749.GF4613@macbook.catpipe.net> Message-ID: <20110106234841.208007c9@opy.nosense.org> On Wed, 5 Jan 2011 18:57:50 +0100 Phil Regnauld wrote: > Jeff Wheeler (jsw) writes: > > are badly needed. The largest current routing devices have room for > > about 100,000 ARP/NDP entries, which can be used up in a fraction of a > > second with a gigabit of malicious traffic flow. What happens after > > that is the problem, and we need to tell our vendors what knobs we > > want so we can "choose our own failure mode" and limit damage to one > > interface/LAN. > > Well there are *some* knobs: > > http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-addrg_bsc_con.html#wp1369018 > > Not very smart, as it just controls how fast you run out of entries. > > I haven't read all entries in this thread yet, but I wonder if > http://tools.ietf.org/html/draft-jiang-v6ops-nc-protection-01 has been > mentioned ? > The problem fundamentally is the outstanding state while the NS/NA transaction takes place. IPX had big subnets (i.e. /32s out of 80 bit addresses), but as it didn't use a layer 3 to layer 2 address resolution protocol (layer 2 addresses were the layer 3 node addresses), requiring transaction state, it didn't (or wouldn't have) had this issue. I think the answer is to go stateless for the NS/NA transaction, either blindly trusting the received NAs (initially compatible with current NS/NA mechanisms), which reduces the set of nodes that can exploit neighbor cache tables to those onlink, and then eventually moving towards a nonce based verification of received NAs, which in effect carries the NS/NA transaction state within the packet, rather than storing it within the NS'ing node's memory. Going stateless means losing ICMPv6 destination unreachables for non-existent neighbors however (a) vendors aren't implementing those on P2P links already because they switch off ND address resolution, (b) the /127 P2P proposal switches them off because it proposes switching off ND address resolution, and (c) firewalls commonly drop them inbound from the Internet anyway. Other possible options - http://www.ietf.org/mail-archive/web/ipv6/current/msg12400.html > Seems also that this topic has been brought up here a year ago give > or take a couple of weeks: > > http://www.mail-archive.com/nanog at nanog.org/msg18841.html > > > Cheers, > Phil > From nanog at studio442.com.au Thu Jan 6 07:25:07 2011 From: nanog at studio442.com.au (Julien Goodwin) Date: Fri, 07 Jan 2011 00:25:07 +1100 Subject: NIST IPv6 document In-Reply-To: <20110106050130.18520.qmail@joyce.lan> References: <20110106050130.18520.qmail@joyce.lan> Message-ID: <4D25C2B3.9020309@studio442.com.au> On 06/01/11 16:01, John Levine wrote: >> Still, the idea that "nobody will scan a /64" reminds me of the days >> when 640K ought to be enough for anybody, ... > > We really need to wrap our heads around the orders of magnitude > involved here. If you could scan an address every nanosecond, which I > think is a reasonable upper bound what with the speed of light and > all, it would still take 500 years to scan a /64. Enumerating all the > addresses will never be practical. But there's plenty of damage one > can do with a much less than thorough enumeration. I'm probably ruining an interview question from $COMPANYTHATDIDN'THIREME but think just of a 64-bit counter, *if* you had the ability to iterate through 32-bits every second[1] it still takes ~136 years to go all the way through 64 bits. I don't know about you, but that doesn't worry me. At that point it's a straight bandwidth DoS. What makes much more sense is mapping the first /112 or so of a subnet, the last /112 or so, that will catch most static hosts and routers, then if you really want just iterate through the 2^46 valid assigned MAC's[2], much less if you make some assumptions about which OUI's are likely to exist on a subnet[3]. Julien 1: ie, think of a 4.3ish Ghz CPU that can do "i++ and jump to 0" in a single instruction 2: One bit lost for broadcast, one bit for local/global addresses 3: Skipping all unassigned is obvious, but there's a huge amount that will match systems you'll never care about, 2^36 is probably not far off. From jethro.binks at strath.ac.uk Thu Jan 6 07:29:03 2011 From: jethro.binks at strath.ac.uk (Jethro R Binks) Date: Thu, 6 Jan 2011 13:29:03 +0000 (GMT) Subject: The tale of a single MAC In-Reply-To: <00B62A16-1B89-4CD6-ACEF-588B6334EECD@cs.columbia.edu> References: <4D1FF814.50306@2mbit.com> <20110102150324.627b891c@opy.nosense.org> <00B62A16-1B89-4CD6-ACEF-588B6334EECD@cs.columbia.edu> Message-ID: On Sun, 2 Jan 2011, Steven Bellovin wrote: > > This was actually the intended way to use "MAC" addresses, to used as > > host addresses rather than as individual interface addresses, according > > to the following paper - > > > > "48-bit Absolute Internet and Ethernet Host Numbers" > > Yogan K. Dalal and Robert S. Printis, July 1981 > > http://ethernethistory.typepad.com/papers/HostNumbers.pdf > > Yup. > > > > That paper also discusses why 48 bits were chosen as the size, despite > > "Ethernet systems" being limited to 1024 hosts. > > > > I think things evolved into MAC per NIC because when add-in NICs > > were invented there wasn't any appropriate non-volatile storage on the > > host to store the address. > > > On really old Sun gear, the MAC address was stored on a separate ROM > chip; if the motherboard was replaced, you'd just move the ROM chip to > the new board. And I'm sure many will remember that Suns of a certain vintage with multiple ethernet interfaces would use that same "host" MAC address on all those interfaces, unless you weaved some magic in the eeprom to use the (presumably) burned-in MAC address of the interface itself. I have long forgotten precisely what the incantation was now ... Jethro. . . . . . . . . . . . . . . . . . . . . . . . . . Jethro R Binks, Network Manager, Information Services Directorate, University Of Strathclyde, Glasgow, UK The University of Strathclyde is a charitable body, registered in Scotland, number SC015263. From jethro.binks at strath.ac.uk Thu Jan 6 07:35:24 2011 From: jethro.binks at strath.ac.uk (Jethro R Binks) Date: Thu, 6 Jan 2011 13:35:24 +0000 (GMT) Subject: The tale of a single MAC In-Reply-To: <4D214329.1060701@deaddrop.org> References: <22889272.17.1294003174222.JavaMail.franck@franck-martins-macbook-pro.local> <1B9985A3-5F00-47FE-BCB3-265A673C9C71@sequestered.net> <4D214329.1060701@deaddrop.org> Message-ID: On Sun, 2 Jan 2011, Lynda wrote: > Google does NOT know all. I was there. I have had to deal with a > building full of such wickedness. I administered DNS (in my copious > spare time) for two subdomains, and managed the network in the building > (a not inconsiderable /22, and also in my spare time), and started > getting frantic calls from people who were getting knocked off the > network because their machine had the same MAC address as another. > > I had trouble believing it at first, but after dealing with five of them > (all Gateways, and yes, all with the same MAC address), I directed the > local sysadmins to disable the nic that came with them, and to replace > it with a spare. I understand that there were 30,000 of them, all with > the same address. My guess is that you'll never find it on Google, since > it happened around 1993-4 or so. You will now. . . . . . . . . . . . . . . . . . . . . . . . . . Jethro R Binks, Network Manager, Information Services Directorate, University Of Strathclyde, Glasgow, UK The University of Strathclyde is a charitable body, registered in Scotland, number SC015263. From kilobit at gmail.com Thu Jan 6 07:37:32 2011 From: kilobit at gmail.com (bas) Date: Thu, 6 Jan 2011 14:37:32 +0100 Subject: Where to go for connectivity in VA / DC Message-ID: Hi, We've recently opened a POP in northern Virginia. The DC does not have a lot of connectivity options to choose from. So we've ordered dark fiber to Equinix Ashburn DC2, we will light it up with our own DWDM, and pick up connectivity there. We do however need a second point to pick up connectivity for redundancy purposes. (that runway from IAD is pretty scary) Initially we had thought to pick up that connectivity at Coresite K-street. However many of the carriers we use are not available at K-street. What would you guys advise us to go to for lots of connectivity options. Thanks, Bas From jgreco at ns.sol.net Thu Jan 6 08:01:00 2011 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 6 Jan 2011 08:01:00 -0600 (CST) Subject: NIST IPv6 document In-Reply-To: Message-ID: <201101061401.p06E119a096083@aurora.sol.net> > On Wed, Jan 5, 2011 at 10:51 PM, Joe Greco wrote: > >> On Jan 6, 2011, at 12:54 PM, Joe Greco wrote: > ... > > To say that "the endpoint *will be found*" is a truism, in the same > > way that a bank *will* be robbed. =A0You're not trying to guarantee that > > it will never happen. =A0You're trying to *deter* the bad guys. =A0You wa= > nt > > the bad guy to go across the street to the less-well-defended bank > > across the street. =A0You can't be sure that they'll do that. =A0Someone > > who has it out for you and your bank will rob your bank (or end up > > in jail or dead or whatever). =A0But you can scare off the guy who's > > just looking to score a few thousand in easy cash. > > > > Making it harder to scan a network *can* and *does* deter certain > > classes of attacks. =A0That it doesn't prevent every attack isn't a > > compelling proof that it doesn't prevent some, and I have to call what > > you said a poor argument for that reason. > > Hi Joe, > > I think what people are trying to say is that it doesn't matter whether > or not your host is easily findable or not, if I can trivially take out you= > r > upstream router. With your upstream router out of commission, the > findability of your host on the subnet really doesn't matter. Once the > router is gone, so is your host, no matter how well hidden on the > subnet it was. > > So, the push here is to prevent the trivial ability to take out the > upstream routers, so that the host-level issues will still matter, and > be worth discussing. > > Hope this helps clarify the reason for the overarching concern > about the /64 subnet size. I completely understand that issue. However, I feel that this is not a hopeless quagmire. We've frequently run into major problems in IP engineering in the past, and have coped with them with varying degrees of success (smurf and CIDR pop to mind). We've also shown that the underlying protocols and technology are open to tinkering where necessary; consider 802.3az. I basically agree that there may be some issues with the current IPv6 NDP (etc) system. We actually have issues with the current IPv4 ARP system, too (think spoofing etc). However, I think we might be looking at this the wrong way. Instead of vendor knobs to change the IPv6 protocol, which may interfere with both ethernet *and* v6, it seems to me that maybe the problem can be solved just for the ethernet portions of the problem. For example, while there might be a /64's worth of address space on an interface, I'm *pretty* sure that the design goal isn't actually to support all that. Further, a router's need to talk to that network will be isolated to that interface. I wouldn't be too shocked to see the NDP protocol morph a little to allow routers to more easily maintain a neighbor list in local (per-ifc) silicon, rather than in expensive router TCAM, since the best use of TCAM isn't ARP^WNDP anyways. The fact of the matter is that silicon is cheap and getting cheaper. We will see ethernet switches allowing the learning of MAC info for NDP purposes, just as we currently have ethernet switches policing MAC's for IPv4 sanity purposes. Routers will probably need to do some policing of NDP rates, but also we may see better silicon to help with ethernet. There may be ways to fix the *ethernet* /64 issues in IPv6. We could be talking constructively about that. Instead, I'm seeing what seems to me to be dislike of /64's in general. I don't really care to get into arguments about that, that ship sailed long ago, and those who missed the boat fighting it at the time aren't going to get any joy here. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From jgreco at ns.sol.net Thu Jan 6 08:29:10 2011 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 6 Jan 2011 08:29:10 -0600 (CST) Subject: NIST IPv6 document In-Reply-To: <965BBCFE-47B6-4F96-A158-FCF0215378C2@arbor.net> Message-ID: <201101061429.p06ETB7g096271@aurora.sol.net> > On Jan 6, 2011, at 2:03 PM, Matthew Petach wrote: > > I think what people are trying to say is that it doesn't matter whether o= > r not your host is easily findable or not, if I can trivially take out your > > upstream router. A good reason to see if there's a way to solve that (which there is, I'm sure). > That's part of it - the other part is that the host will be found, irrespec= > tive of attempts to 'hide' it. Sorry, but I see this as not grasping a fundamental security concept. You're not trying for DHS/TSA-style all-threats-always-prevented threat elimination. How many times do we have to learn that this isn't a practical goal? You want to make things more difficult for an attacker while providing usability for authorized users. Making a host harder to find (or more specifically to address from remote) is a worthwhile goal. Learn from history. Ten years ago, we *knew* DNS was "weak" due to the ultimate reliance on the transaction ID. There weren't enough bits there to protect a DNS server against certain types of attacks but that were deemed to be impractical at the time; time passes, cpu's got faster, upstream connections got faster, and suddenly some guy "discovers" that he can get a DNS server to do bad things if he floods it. So now our best current practices now have us using more bits, in the form of random source ports, to help out there. Even that's not a comprehensive fix - definitely won't be in another 20 years, when bandwidth, cpu, and pps rates have all seen a factor of 10000 increase again - but it's helpful for the time being. Things like 4941 take that a lot further, and provide enough bits to make both range scanning and scanning via learned addresses less useful techniques. The fact that you might be able to find a host somehow anyways doesn't lessen the value of making it harder for an attacker to find that host to begin with. This is basic security, whether or not you approve of it. You're trying to make it harder for bad guys. There are lots of security techniques that I don't like, too, or may disapprove of for one reason or another. NAT anyone? :-) ... 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 kloch at kl.net Thu Jan 6 08:34:00 2011 From: kloch at kl.net (Kevin Loch) Date: Thu, 06 Jan 2011 09:34:00 -0500 Subject: Where to go for connectivity in VA / DC In-Reply-To: References: Message-ID: <4D25D2D8.5080409@kl.net> bas wrote: > Hi, > > We've recently opened a POP in northern Virginia. > The DC does not have a lot of connectivity options to choose from. > > So we've ordered dark fiber to Equinix Ashburn DC2, we will light it > up with our own DWDM, and pick up connectivity there. > > We do however need a second point to pick up connectivity for > redundancy purposes. (that runway from IAD is pretty scary) > Initially we had thought to pick up that connectivity at Coresite K-street. > However many of the carriers we use are not available at K-street. 8100 Boone Blvd. - Kevin From jbates at brightok.net Thu Jan 6 08:50:06 2011 From: jbates at brightok.net (Jack Bates) Date: Thu, 06 Jan 2011 08:50:06 -0600 Subject: NIST IPv6 document In-Reply-To: <165A304D-D288-4290-ACB3-A63CD461CAF0@delong.com> References: <20110105043548.BC01B1CC3E@ptavv.es.net> <4D248868.70705@brightok.net> <165A304D-D288-4290-ACB3-A63CD461CAF0@delong.com> Message-ID: <4D25D69E.7080301@brightok.net> On 1/5/2011 11:31 PM, Owen DeLong wrote: > Why shouldn't I use /64 for links if I want to? I can see why you can say you want /126s, and that's fine, as long as > you are willing to deal with the fall-out, your network, your problem, but, why tell me that my RFC-compliant network > is somehow wrong? > You can. My problem with that is primarily that using an ACL for the predictable addresses gets messy. Filtering based on ::<1-2> isn't possible in most routers, and an acl to filter every /64 used for a link address is one heck of a long list. > SLAAC cannot function with longer than /64 because SLAAC depends on prefix + EUI-64 = address. It depends on supporting it. EUI-64 address is not required for the globally routed prefixes, and many servers static the token as ::0xxx. Jack From lowen at pari.edu Thu Jan 6 09:10:22 2011 From: lowen at pari.edu (Lamar Owen) Date: Thu, 6 Jan 2011 10:10:22 -0500 Subject: NIST IPv6 document In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC1321C@RWC-EX1.corp.seven.com> References: <201101060308.p0638wha085757@aurora.sol.net> Message-ID: <201101061010.23043.lowen@pari.edu> On Wednesday, January 05, 2011 10:42:25 pm George Bonser wrote: > I don't think you are understanding the problem. The problem comes from > addressing hosts that don't even exist. This causes the router to > attempt to find that host. The v6 equivalent of ARP. At some point > that table becomes full of entries for hosts that don't exist so there > isn't room for hosts that do exist. Ok, perhaps I'm dense, but why is the router going to try to find a host that it already doesn't know based on an unsolicited outside packet? Why is the router trusting the outside's idea of what addresses are active, and why isn't the router dropping packets on the floor destined to hosts on one of its interfaces' local subnets that it doesn't already know about? If the packet is a response to a request from the host, then the router should have seen the outgoing packet (or, in the case of HSRP-teamed routers, all the routers in the standby group should be keeping track of all hosts, etc) and it should already be in the neighbor table. Sounds a bit too much like ATM SVC addressing and the old LANE business for my liking. Like I said, perhaps I'm dense and ignorant and just simply misunderstanding the issue, but I still find it hard to believe that a router would blindly trust an outside address to know about an inside address that is not already in the router's neighbor table. In the case of a server (the only case I can see for such an unsolicited packet), I would think that it would be in the router's neighbor table already, or at least the server's OS should take pains to make sure it's in the neighbor table already! From jbates at brightok.net Thu Jan 6 09:19:10 2011 From: jbates at brightok.net (Jack Bates) Date: Thu, 06 Jan 2011 09:19:10 -0600 Subject: NIST IPv6 document In-Reply-To: <201101060626.p066Q4ak088421@aurora.sol.net> References: <201101060626.p066Q4ak088421@aurora.sol.net> Message-ID: <4D25DD6E.8000708@brightok.net> On 1/6/2011 12:26 AM, Joe Greco wrote: > A bunch of very smart people have worked on IPv6 for a very long > time, and justification for /64's was hashed out at extended length > over the period of years. NDP should have been better designed. It still has the same problems we had with ARP except the address pool has magnified it. Routers should have 1) better methods for keeping ND tables low (and maintaining only valid entries) or 2) better methods for learning valid entries than unsolicited NDP requests. This isn't to say the protocol itself is a waste, but it should have taken in the concerns and developed the mitigation controls necessary as recommendations to the implementers. Jack From bogstad at pobox.com Thu Jan 6 09:23:17 2011 From: bogstad at pobox.com (Bill Bogstad) Date: Thu, 6 Jan 2011 10:23:17 -0500 Subject: NIST IPv6 document In-Reply-To: References: <1F3A01A3-A244-416E-85D8-74CCBA253AAC@arbor.net> <201101060651.p066piXN088758@aurora.sol.net> <4D257265.5000804@bogus.com> <4D258C12.2090907@bogus.com> Message-ID: On Thu, Jan 6, 2011 at 5:54 AM, Jeff Wheeler wrote: > On Thu, Jan 6, 2011 at 5:20 AM, Owen DeLong wrote: >>> You must also realize that the stateful firewall has the same problems >> Uh, not exactly... > > Of course it does. ?The stateful firewall must either 1) be vulnerable > to the same form of NDP attack; or 2) have a list of allocated v6 > addresses on the LAN. ?The reason is simple; a "stateful firewall" is > no more able to store a 2**64 table than is a "router." ?Calling it > something different doesn't change the math. ?If you choose to solve > the problem by disabling NDP or allowing NS only for a list of "valid" > addresses on the subnet, this can be done by a stateless router just > like on a stateful firewall. > >> Uh, no it doesn't. It just needs a list of the hosts which are permitted >> to receive inbound connections from the outside. That's the whole > > This solution falls apart as soon as there is a compromised host on > the LAN, in which case the firewall (or router) NDP table can again be > filled completely by that compromised/malicious host. ?In addition, > the "stateful firewall," by virtue of having connection state, does > not solve the inbound NDP attack issue. ?The list of hosts which can > result in an NDP NS is whats causes this, and such a list may be > present in a stateless router; but in both cases, it needs to be > configured. Err, almost everything falls apart once you allow a compromised/malicious host on the local LAN. If you have circumstances where this may happen on anything like a regular basis, you really need all kinds of control/monitoring of traffic that go far beyond any local NDP overflow issues. Bill Bogstad From tjc at ecs.soton.ac.uk Thu Jan 6 09:23:30 2011 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Thu, 6 Jan 2011 15:23:30 +0000 Subject: NIST IPv6 document In-Reply-To: <201101061010.23043.lowen@pari.edu> References: <201101060308.p0638wha085757@aurora.sol.net> <201101061010.23043.lowen@pari.edu> <55FEB1C7-A37E-4BF5-A712-3B7A260FE482@ecs.soton.ac.uk> Message-ID: On 6 Jan 2011, at 15:10, Lamar Owen wrote: > > Ok, perhaps I'm dense, but why is the router going to try to find a host that it already doesn't know based on an unsolicited outside packet? Why is the router trusting the outside's idea of what addresses are active, and why isn't the router dropping packets on the floor destined to hosts on one of its interfaces' local subnets that it doesn't already know about? > > If the packet is a response to a request from the host, then the router should have seen the outgoing packet (or, in the case of HSRP-teamed routers, all the routers in the standby group should be keeping track of all hosts, etc) and it should already be in the neighbor table. There's some interesting discussion around this point in RFC6018, which discusses the use of greynet monitoring in sparsely populated IPv6 subnets. This approach may be one method to help detect and or mitigate such attacks. Tim From swmike at swm.pp.se Thu Jan 6 09:27:54 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 6 Jan 2011 16:27:54 +0100 (CET) Subject: NIST IPv6 document In-Reply-To: <201101061010.23043.lowen@pari.edu> References: <201101060308.p0638wha085757@aurora.sol.net> <201101061010.23043.lowen@pari.edu> Message-ID: On Thu, 6 Jan 2011, Lamar Owen wrote: > Ok, perhaps I'm dense, but why is the router going to try to find a host > that it already doesn't know based on an unsolicited outside packet? > Why is the router trusting the outside's idea of what addresses are > active, and why isn't the router dropping packets on the floor destined > to hosts on one of its interfaces' local subnets that it doesn't already > know about? Because the standard says it should do that. > If the packet is a response to a request from the host, then the router > should have seen the outgoing packet (or, in the case of HSRP-teamed > routers, all the routers in the standby group should be keeping track of > all hosts, etc) and it should already be in the neighbor table. Are you trying to abolish the end to end principle of the Internet by implementing stateful firewalls in all routers? > Like I said, perhaps I'm dense and ignorant and just simply > misunderstanding the issue, but I still find it hard to believe that a > router would blindly trust an outside address to know about an inside > address that is not already in the router's neighbor table. That's how it's always worked, both for v4 and v6. -- Mikael Abrahamsson email: swmike at swm.pp.se From marcelplug at gmail.com Thu Jan 6 09:37:24 2011 From: marcelplug at gmail.com (Marcel Plug) Date: Thu, 6 Jan 2011 10:37:24 -0500 Subject: NIST IPv6 document In-Reply-To: <4D25DD6E.8000708@brightok.net> References: <201101060626.p066Q4ak088421@aurora.sol.net> <4D25DD6E.8000708@brightok.net> Message-ID: Perhaps we're reaching the point where we can say "We don't need an ND table for a /64 network". If the ethernet MAC is embedded in the IPv6 address, we don't need to discover it because we already know it. If the IPv6 address has been manually configured on a host, perhaps that host should now accept traffic directed to the MAC that the lower 64 bits of the IPv6 address would translate to. Perhaps this idea has been discussed somewhere and discarded for its flaws, but if not, perhaps it should be :-). Marcel (First post by the way, go easy on me :-) On Thu, Jan 6, 2011 at 10:19 AM, Jack Bates wrote: > > On 1/6/2011 12:26 AM, Joe Greco wrote: >> >> A bunch of very smart people have worked on IPv6 for a very long >> time, and justification for /64's was hashed out at extended length >> over the period of years. > > NDP should have been better designed. It still has the same problems we had > with ARP except the address pool has magnified it. > > Routers should have 1) better methods for keeping ND tables low (and > maintaining only valid entries) or 2) better methods for learning valid > entries than unsolicited NDP requests. > > This isn't to say the protocol itself is a waste, but it should have taken > in the concerns and developed the mitigation controls necessary as > recommendations to the implementers. > > > Jack > > From jbates at brightok.net Thu Jan 6 09:44:13 2011 From: jbates at brightok.net (Jack Bates) Date: Thu, 06 Jan 2011 09:44:13 -0600 Subject: NIST IPv6 document In-Reply-To: References: <201101060308.p0638wha085757@aurora.sol.net> <201101061010.23043.lowen@pari.edu> Message-ID: <4D25E34D.7090100@brightok.net> On 1/6/2011 9:27 AM, Mikael Abrahamsson wrote: > On Thu, 6 Jan 2011, Lamar Owen wrote: > >> Ok, perhaps I'm dense, but why is the router going to try to find a >> host that it already doesn't know based on an unsolicited outside >> packet? Why is the router trusting the outside's idea of what >> addresses are active, and why isn't the router dropping packets on the >> floor destined to hosts on one of its interfaces' local subnets that >> it doesn't already know about? > > Because the standard says it should do that. > The standard was broken with arp, and continues to be broken with NDP. Routers should not handle things the same as normal hosts. >> If the packet is a response to a request from the host, then the >> router should have seen the outgoing packet (or, in the case of >> HSRP-teamed routers, all the routers in the standby group should be >> keeping track of all hosts, etc) and it should already be in the >> neighbor table. > > Are you trying to abolish the end to end principle of the Internet by > implementing stateful firewalls in all routers? > Not stateful firewalls. He's referring to neighbor learning based on incoming traffic to the router from the trusted side. ie, I received a packet from the server, so I will add his MAC to my neighbor table. There are many methods for learning MAC addresses, though. DHCP/MAC security with static ARP and other viable options have properly killed this problem in v4 by routers not looking for unknown neighbors. >> Like I said, perhaps I'm dense and ignorant and just simply >> misunderstanding the issue, but I still find it hard to believe that a >> router would blindly trust an outside address to know about an inside >> address that is not already in the router's neighbor table. > > That's how it's always worked, both for v4 and v6. > It's how it works, but not how it should work. In the last years, v4 has seen some nice implementations that specifically are designed (especially for eyeball networks who have vast pools of space) to keep routers from sending unsolicited arp requests and maintaining only a valid pool of mappings. That is how the protocols should have been designed in the first place. Host to Host communications are one thing. Router to host communications should be designed with the idea that the host needs to tell the router who it is, not the router asking. This keeps packets from unknown hosts from causing these table issues. There are also (some of the above designed to do) security measures dealing with local abuse and hijacking, but that is separate issue. This is about resource exhaustion, and policing/ACL isn't the proper fix. Having hosts (in a secure or insecure manner) notify the router of their mapping is the appropriate fix. Protocol wise, insecure is fine, wrapped with an extra layer of security (as security can have multiple implementations). Jack From jbates at brightok.net Thu Jan 6 09:51:27 2011 From: jbates at brightok.net (Jack Bates) Date: Thu, 06 Jan 2011 09:51:27 -0600 Subject: NIST IPv6 document In-Reply-To: References: <201101060626.p066Q4ak088421@aurora.sol.net> <4D25DD6E.8000708@brightok.net> Message-ID: <4D25E4FF.2070205@brightok.net> On 1/6/2011 9:37 AM, Marcel Plug wrote: > Perhaps we're reaching the point where we can say "We don't need an ND > table for a /64 network". If the ethernet MAC is embedded in the IPv6 > address, we don't need to discover it because we already know it. If > the IPv6 address has been manually configured on a host, perhaps that > host should now accept traffic directed to the MAC that the lower 64 > bits of the IPv6 address would translate to. > > Perhaps this idea has been discussed somewhere and discarded for its > flaws, but if not, perhaps it should be :-). > The table itself is fine. I fully support it. The method for generating such a table within a router (separate from standard hosts who only generate tables for who they need to talk to, and unless you allowed forged packets in from remote, shouldn't have an issue) is what is in questions. See my other posts. There have been many implementations, mostly for security reasons, but also helping with this problem by implementing a "router MUST NOT send unsolicited arp requests". It's important that routers learn their table in another fashion. Jack From swmike at swm.pp.se Thu Jan 6 09:52:41 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 6 Jan 2011 16:52:41 +0100 (CET) Subject: NIST IPv6 document In-Reply-To: <4D25E34D.7090100@brightok.net> References: <201101060308.p0638wha085757@aurora.sol.net> <201101061010.23043.lowen@pari.edu> <4D25E34D.7090100@brightok.net> Message-ID: On Thu, 6 Jan 2011, Jack Bates wrote: > Not stateful firewalls. He's referring to neighbor learning based on > incoming traffic to the router from the trusted side. ie, I received a > packet from the server, so I will add his MAC to my neighbor table. > There are many methods for learning MAC addresses, though. DHCP/MAC > security with static ARP and other viable options have properly killed > this problem in v4 by routers not looking for unknown neighbors. When people start to talk about "trusted side" etc, I immediately think firewalls and not plain routing. I don't trust anyone, neither my customers, nor Internet. I guess it might make sense to have the host register address usage (in the SLAAC case) with the router, and the router having a mechanism to broadcast/multicast to everybody that "I lost my state mac/ip table, please re-register" so they can do it again. > It's how it works, but not how it should work. In the last years, v4 has > seen some nice implementations that specifically are designed > (especially for eyeball networks who have vast pools of space) to keep > routers from sending unsolicited arp requests and maintaining only a > valid pool of mappings. In the DHCP case this is easy, yes. I perfer to have only LL on the link towards the customer operated CPE, thus I don't really need to keep lots of ND state per customer. -- Mikael Abrahamsson email: swmike at swm.pp.se From mikevs at xs4all.net Thu Jan 6 09:55:25 2011 From: mikevs at xs4all.net (Miquel van Smoorenburg) Date: Thu, 6 Jan 2011 16:55:25 +0100 Subject: NIST IPv6 document In-Reply-To: References: <1F3A01A3-A244-416E-85D8-74CCBA253AAC@arbor.net> <201101060651.p066piXN088758@aurora.sol.net> <4D257265.5000804@bogus.com> <4D258C12.2090907@bogus.com> Message-ID: <201101061555.p06FtP8w031768@xs8.xs4all.nl> In article you write: >On Thu, Jan 6, 2011 at 4:32 AM, Joel Jaeggli wrote: >> Which at a minimum is why you want to police the number of nd messages >> that the device sends and unreachable entries do not simply fill up the >> nd cache, such that new mappings in fact can be learned because there > >Your solution is to break the router (or subnet) with a policer, >instead of breaking it with a full table. That is not better; both >result in a broken subnet or router. If NDP requires an NDCache with >"incomplete" entries to learn new adjacencies, then preventing it from >filling up will ... prevent it from learning new adjacencies. Do you >see how this is not a solution? If all nodes implemented RFC4620 (IPv6 Node Information Queries), then you could ratelimit ND queries and, when ratelimiting, just regularly (say every few seconds) refresh the neighbor list with a multicast NI Node Addresses Query . In fact a router can still do this, it's just the nodes that do not implement RFC4620 that suffer the most, and perhaps that will serve as an incentive to get RFC4620 implemented on those nodes. Mike. From jbates at brightok.net Thu Jan 6 09:57:20 2011 From: jbates at brightok.net (Jack Bates) Date: Thu, 06 Jan 2011 09:57:20 -0600 Subject: NIST IPv6 document In-Reply-To: References: <201101060308.p0638wha085757@aurora.sol.net> <201101061010.23043.lowen@pari.edu> <4D25E34D.7090100@brightok.net> Message-ID: <4D25E660.4060404@brightok.net> On 1/6/2011 9:52 AM, Mikael Abrahamsson wrote: > In the DHCP case this is easy, yes. > > I perfer to have only LL on the link towards the customer operated CPE, > thus I don't really need to keep lots of ND state per customer. I use RBE and unnumbered vlans in most areas, which keeps some state, but effectively prohibits the problem, as well as other problems. I have vendors curse me for wanting the router to handle the security instead of their DSLAMs, but then their DSLAMs often broke IPv6 with their so called security. Jack From lowen at pari.edu Thu Jan 6 10:16:03 2011 From: lowen at pari.edu (Lamar Owen) Date: Thu, 6 Jan 2011 11:16:03 -0500 Subject: NIST IPv6 document In-Reply-To: References: <201101060308.p0638wha085757@aurora.sol.net> Message-ID: <201101061116.03354.lowen@pari.edu> On Thursday, January 06, 2011 10:27:54 am you wrote: > On Thu, 6 Jan 2011, Lamar Owen wrote: > > Ok, perhaps I'm dense, but why is the router going to try to find a host > > that it already doesn't know based on an unsolicited outside packet? > Because the standard says it should do that. Since when have standards been blindly followed by vendors? If I were an IPv6 router vendor, I'd code up a 'drop the packet if it's destined for an address in a directly attached subnet but that doesn't already have a neighbor table entry ' knob and sell it as a high-priced security add-on to my already bloated product line.... Actually, thinking like a coder, it would be removing the code that punts to neighbor discovery on receipt of an outside-the-destination-subnet packet destined to an address that's not in the neighbor table (and is an address within one of the router's directly attached subnets), and wouldn't require any additional CPU (or hardware punt to neighbor discovery) to implement. Could even be sold as a forwarding performance improvement (for incoming to the subnet packets only, obviously). And then allow an 'icmp-host-unreachable' to either be returned or not, according to the policy of the subnet in question. Standards are written by people, of course, and most paragraphs have reasons to be there; I would find it interesting to hear the rationale for a router filling a slot in its neighbor table for a host that doesn't exist. For that matter, I'd like to see a pointer to which standard that says this so I can read the verbiage myself, as that may have enough explanation to satisfy my curiosity. > > If the packet is a response to a request from the host, then the router > > should have seen the outgoing packet (or, in the case of HSRP-teamed > > routers, all the routers in the standby group should be keeping track of > > all hosts, etc) and it should already be in the neighbor table. > > Are you trying to abolish the end to end principle of the Internet by > implementing stateful firewalls in all routers? Not at all; end to end is fine, but if there is no end to send a packet to, that packet should be dropped and not blindly trusted (since it will be abused for sure) by the router serving the destination subnet, which is the only router that is in a position to know if the endpoint exists or not. Dropping in this case means 'don't punt to discovery for this packet' and isn't blocking, it's just not taking the extra effort to look up something it already doesn't know. Not what I consider a stateful firewall. This reminds me somewhat of some IPv4 routers doing Proxy ARP by default. > > Like I said, perhaps I'm dense and ignorant and just simply > > misunderstanding the issue, but I still find it hard to believe that a > > router would blindly trust an outside address to know about an inside > > address that is not already in the router's neighbor table. > > That's how it's always worked, both for v4 and v6. Sounds like I need to study it in more depth, but I'm still having a hard time seeing why such behavior is a good idea. Time to break out the wireshark laptop and do some SPANning.... and to see if I can find the reference in the RFC's somewhere. Thanks for the info. From jcurran at arin.net Thu Jan 6 10:17:51 2011 From: jcurran at arin.net (John Curran) Date: Thu, 6 Jan 2011 16:17:51 +0000 Subject: ARIN resource certification service update In-Reply-To: References: <94F3F129-608E-46EC-B157-CC23CAA47454@tozz.net> <4D24A734.3000807@jcoley.net> <816AB912-14CF-4028-853A-F0BE77D2EB09@puck.nether.net> Message-ID: <927929DA-B56D-4FF4-A41D-245224939466@corp.arin.net> On Jan 5, 2011, at 5:32 PM, Randy Bush wrote: >> 1) If ARIN doesn't provide the level of authentication you desire, as >> an ARIN member you should send a note to ppml each day until it's >> available > > this is not address policy. this is ops. surely one does not have to > dirty one's self with the ppml list to get an ops fix done in arin. it > is not address policy. > > i have a rumor that arin is delaying and possibly not doing rpki that > seems to have been announced on the ppml list (to which i do not > subscribe). as it has impact on routing, not address policy, across > north america and, in fact the globe, one would think it would be > announced and discussed a bit more openly and widely. Randy - Excellent point; my apologies for not realizing this sooner and posting some information directly for consideration by the NANOG community. Attached is a message from the arin-discuss mailing list which has some more context; please feel free to discuss this on the arin-discuss mailing list or here on NANOG (as appropriate) Thanks! /John Begin forwarded message: > From: John Curran > Date: January 6, 2011 11:08:39 AM EST > To: "George, Wes E [NTK]" > Cc: "arin-discuss at arin.net" > Subject: Re: [arin-discuss] Important Update Regarding Resource Certification > > On Jan 6, 2011, at 9:32 AM, George, Wes E [NTK] wrote: > >> There have been some threads about this on NANOG in the last few days. Can >> we get a bit clearer explanation of what the specific security concerns are >> and why they are delaying things? It may also make sense for someone from >> ARIN to post to NANOG with an explanation as well. If there are security >> concerns, it is something that the community should be aware of in case >> other RIRs or the SIDR WG need to be considering those issues as well. >> >> Thanks, >> Wes George > > George - > > The security concerns are not specificly related to the RPKI > protocol, but inherent implications of any service that might > be heavily relied upon for real-time network operations, i.e. > I don't think it's a SIDR WG matter, but simply part of the > due diligence associated with the service as noted below. > > While the RIRs presently provide services which are used to > support operations (such as WHOIS and Reverse DNS services), > failure of RIR resource certification services could have > some very significant consequences, particularly in the case > of incorrect data as opposed to simply unavailable data. > There are some potential liability implications of operating > such a service that ARIN is presently reviewing in depth. I > need to also note that these issues exist even in the case of > a perfectly secure and operational service, in that an error > by an ISP using ARIN's services (e.g. having entered the wrong > AS number into a ROA for a major customer) could result in > ARIN needing to readily "prove" the integrity of its resource > certification system as well as fidelity of performance against > the operators request. > > This has led ARIN to consider some aspects of its resource > certification design, specifically to mitigate potential risks > in the areas of non-repudiation and multi-party controls. Even > so, the ultimate decision in these matters lies with the ARIN > Board, as there is always going to be residual risk associated > with any operations-related service provided by ARIN (note also > that we have also discussed these issues with the other RIRs, > but as they don't operate in ARIN's highly-litigous region, it > is not necessarily a similar priority for their consideration) > > To the extent that ARIN offering resource certification services > is important to your plans, it would good to express such needs > on the arin-discuss mailing list. This helps us gauge the demand > which obviously is another important factor to be considered in > making the final determination on offering these services. > > We intend to have more detailed information out later this month > once the plans for finalized, but I hope the above information > provides some insight into the process at this point. I will > post this to the NANOG list for the community's information. > > Thanks! > /John > > John Curran > President and CEO > ARIN > > p.s. I'm presently on a Caribbean cruise ship on a bona fide > family vacation, so please recognize that replies may > be deferred to off hours so that my laptop isn't thrown > overboard... ;-) From lowen at pari.edu Thu Jan 6 10:20:29 2011 From: lowen at pari.edu (Lamar Owen) Date: Thu, 6 Jan 2011 11:20:29 -0500 Subject: NIST IPv6 document In-Reply-To: <4D25E4FF.2070205@brightok.net> References: <201101060626.p066Q4ak088421@aurora.sol.net> Message-ID: <201101061120.29754.lowen@pari.edu> On Thursday, January 06, 2011 10:51:27 am Jack Bates wrote: > There have been many implementations, mostly for > security reasons, but also helping with this problem by implementing a > "router MUST NOT send unsolicited arp requests". It's important that > routers learn their table in another fashion. Yeah, that's more succinct than what I said, but I think you're saying the same thing. From Valdis.Kletnieks at vt.edu Thu Jan 6 10:28:56 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 06 Jan 2011 11:28:56 -0500 Subject: NIST IPv6 document In-Reply-To: Your message of "Thu, 06 Jan 2011 07:50:17 GMT." <969A43C1-F11D-425A-B210-1721F893C24B@arbor.net> References: <201101060651.p066piXN088758@aurora.sol.net> <969A43C1-F11D-425A-B210-1721F893C24B@arbor.net> Message-ID: <15350.1294331336@localhost> On Thu, 06 Jan 2011 07:50:17 GMT, "Dobbins, Roland" said: > In my view, an IPv6 Internet is considerably less secure, and inherently less > securable, than the present horribly insecure and barely securable IPv4 > Internet; Playing devil's advocate for a moment... Even if an IPv6 network is 10 times as insecure as a similarly configured IPv4 network, they are both as dust motes in a tornado given the incredibly insecure state of most endpoints on the network. Last I looked, there's a lot less scanning of subnets looking for probably-firewalled-by-default-anyhow systems because it's just so much easier to to whack the systems in a drive-by attack when the system visits a compromised web page... And the "ZOMG they can overflow the ARP/ND/whatever table" is a total red herring - you know damned well that if a script kiddie with a 10K node botnet wants to hose down your network, you're going to be looking at a DDoS, and it really doesn't matter whether it's SYN packets, or ND traffic, or forged ICMP echo-reply mobygrams. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jgreco at ns.sol.net Thu Jan 6 10:44:18 2011 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 6 Jan 2011 10:44:18 -0600 (CST) Subject: NIST IPv6 document In-Reply-To: <969A43C1-F11D-425A-B210-1721F893C24B@arbor.net> Message-ID: <201101061644.p06GiIgr097683@aurora.sol.net> > On Jan 6, 2011, at 1:51 PM, Joe Greco wrote: > > There are numerous parallels between physical and electronic security. > > Let's just concede that for a moment. > > I can't, and here's why: > > 1. In the physical world, attackers run a substantial risk of being caught,= > and of tangible, severe penalties if that eventuality comes to pass; in th= > e online world, the risk of being caught is nil. That's not true, and we see examples of it happening periodically. > 2. In the physical world, attackers have a limited number and variety of re= > sources they can bring to bear; in the online world, the attackers have nea= > r-infinite resources, for all practical purposes. No, they don't. They have a different set of resources. They may be able to fill your transit connections, but they probably cannot cause your line cards to start on fire, or your switches to come unscrewed from the rack, things that real-world attackers can do. In the physical world, attackers have a near-infinite selection of attacks. If I really want into your house, for example, I can get there. It might be by breaking through a door, or by smashing a window, or (my favorite) by taking my Sawzall and a demolition bit and putting a hole through your wall. I can convince your kids that I'm a policeman and there's a bad man in the house. I can sleep with your wife and gain access that way. We see parallels in the online world, different, but vulnerable as well. > 3. In the physical world, the attackers generally don't posses the ability = > nor the desire to bring the whole neighborhood crashing down around the ear= > s of the defenders; in the online world, they almost always have the abilit= > y, and often the desire, to do just that. So? That's a matter of what the goal of the attack is. In the physical world, we do indeed have some attackers who possess the ability and desire to bring whole neighborhoods crashing down; we lost some great real estate about ten years ago in lower Manhattan due to such nutjobs, and suicide bombers are a fact of life in some areas of the world. Electronic attacks are more likely to result in electronic "crashing down" for a variety of reasons, one of which is that overwhelming things electronically is fairly easy and effective, but the flip side to that is that the resulting damage is often just a short-term outage (PayPal, Mastercard, etc., all seem to be back online after recent attacks). The fact that there are some differences between physical and electronic security doesn't mean that there aren't also many parallels. It's probably hard to permanently destroy electronic infrastructure. Certain attacks, such as on the facility (kill the cooling, rapidly toggle the power, etc) might be effective in that sense. It's easier to destroy stuff during a physical attack. So that's different, fine. However, the point of security is still to try to convince a bad guy to go elsewhere, to find an easier target. When he has it out for you, though, it's basically a matter of whether or not he's willing to do what is necessary. That concept works for both the real world and for the online world. > > Making it harder to scan a network *can* and *does* deter certain classes= > of attacks.=20 > > But as I've tried to make clear, a) I don't believe that sparse addressing = > does in fact make it harder to scan the network, due to hinted scanning via= > DNS/routing/whois/ND/multicast, You don't have to believe it. It certainly doesn't make it harder in all cases, either. No amount of randomization will make "www.foobar.com" less readily identifiable with an AAAA pointing at it. But there are other use cases. Consider, for example, /56 allocations to end users on a service provider's network. There'll be no DNS/routing/whois vectors there; there might be ND/multicast vectors of some sort. The point is, though, that the guy with a /56 at the end of a cablemodem will be effectively unscannable if he's using randomly-selected 4941 IP addresses. And getting all righteous about firewall configurations and how he should have a transparent proxying firewall is fine, I agree, but the *real* world is that when his buddy tells him that he's having problems running WoW because of the firewall and he can do ${FOO} to turn it off, he's going to do that, because users are results- oriented in a way that makes all of us groan. So what I am looking for now is for you to explain to me how an end-user with a /56 (or even a /64!) on a cablemodem is not "harder to scan". > b) I believe that pushing the attackers to= > wards hinted scanning will have severe second-order deleterious effects on = > DNS/network infrastructure/whois, resulting in an overall loss in terms of = > security posture, I don't buy that. I believe that things like DNS and whois are natural candidates for additional layers of application level protection, and that application level protection scales more readily than things done closer to the wire. We're already seeing whois services protected by query-rate limits, and there's no reason DNS cannot be protected similarly. > and c) I don't believe that attackers will cease pseudo-r= > andomized scanning, and d) I believe that in fact they will throw vastly mo= > re resources at both hinted and pseudo-randomized scanning, that they have = > near-infinite resources at their disposal (with an ever-expanding pool of p= > otential resources to harness), and that the resultant increase in scanning= > activity will also have severely deleterious second-order effects on the s= > ecurity posture of the Internet as a whole. Fair enough. I see where you're coming from and why you believe that, and it might even become true. On the flip side, however, I would point out that attackers have had vastly more resources made available to them in part *because* IPv4 has been so easily scanned and abused. To be sure, a lot of viruses have spread via e-mail spam and drive-by downloads, and sparse addressing will not prevent script kiddies from banging away on ssh brute force attacks against www.yoursite.com. But there's been a lot of spread through stupidity as well. Further, the sheer magnitude of the task of random scanning means that any actual random scanning of /64 networks will be ineffective; this leaves us to discuss ways to minimize the "pseudo" in pseudo-random scanning, and to see what can be done about hinted scanning. I think there's room for some constructive discussion there. > In short, I'm starting from a substantially different, far more pessimistic= > set of base premises, and therefore draw a far more negative set of result= > ing inferences. I hope you'll understand that I'm trying to get a feel for all of that. > I don't believe the sky is falling; I believe it's already fallen, and that= > we're just now starting to come to grips with some of the ramifications of= > its fall. =20 > > In my view, an IPv6 Internet is considerably less secure, and inherently le= > ss securable, than the present horribly insecure and barely securable IPv4 = > Internet; furthermore, I believe that many of the supposed 'security' measu= > res being touted for IPv6 are at best placebos, and at worst are iatrogenic= > in nature. I don't see that. I see potential issues with ND, for example, but I don't see the potential for things like 4941 as "considerably less secure." Unless you're one of the people who are in favor of running everything through NAT as a form of "firewall", or things like that. I understand the desire there, too, though I think it's horribly broken... ... 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 jbates at brightok.net Thu Jan 6 10:48:57 2011 From: jbates at brightok.net (Jack Bates) Date: Thu, 06 Jan 2011 10:48:57 -0600 Subject: NIST IPv6 document In-Reply-To: <15350.1294331336@localhost> References: <201101060651.p066piXN088758@aurora.sol.net> <969A43C1-F11D-425A-B210-1721F893C24B@arbor.net> <15350.1294331336@localhost> Message-ID: <4D25F279.5000204@brightok.net> On 1/6/2011 10:28 AM, Valdis.Kletnieks at vt.edu wrote: > > And the "ZOMG they can overflow the ARP/ND/whatever table" is a total red > herring - you know damned well that if a script kiddie with a 10K node botnet > wants to hose down your network, you're going to be looking at a DDoS, and it > really doesn't matter whether it's SYN packets, or ND traffic, or forged ICMP > echo-reply mobygrams. > My personal concern is not the intentional DDoS, but the idiotic side effects of unintentional idiocy. Nachi was nicer than Blaster to the host, but it unintentionally DDoS'd many networks that couldn't handle the load. How many morons will scan a /64 out of curiosity? Even if they get bored after 1-2 hours, the effects of such a scan on the ND table could be catastrophic in the protocol's default behavior. How many virus writers will utilize a hinted scan technique, which could still end up scanning thousands of v6 addresses per /64 and following consecutive /64s which likely are handled by the same router? It is not the intentional that we should fear, but the unintentional. Jack From jbates at brightok.net Thu Jan 6 11:17:30 2011 From: jbates at brightok.net (Jack Bates) Date: Thu, 06 Jan 2011 11:17:30 -0600 Subject: NIST IPv6 document In-Reply-To: <201101061644.p06GiIgr097683@aurora.sol.net> References: <201101061644.p06GiIgr097683@aurora.sol.net> Message-ID: <4D25F92A.3070402@brightok.net> On 1/6/2011 10:44 AM, Joe Greco wrote: > On the flip side, however, I would point out that attackers have had vastly > more resources made available to them in part *because* IPv4 has been so > easily scanned and abused. To be sure, a lot of viruses have spread via > e-mail spam and drive-by downloads, and sparse addressing will not prevent > script kiddies from banging away on ssh brute force attacks against > www.yoursite.com. But there's been a lot of spread through stupidity as > well. > A randomly setup ssh server without DNS will find itself brute force attacked. Darknets are setup specifically for detection of scans. One side effect of v6, is determining how best to deploy darknets, as we can't just take one or two blocks to do it anymore. We'll need to interweave the darknets with the production blocks. I wish it was possible via DHCPv6-PD to assign a block minus a sub-block (hey, don't use this /64 in the /48 I gave you). It could be that darknets will have to go and flow analysis is all we'll be left with. Jack From matthew at matthew.at Thu Jan 6 11:18:41 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 06 Jan 2011 09:18:41 -0800 Subject: Problems with removing NAT from a network In-Reply-To: References: <4D252B1F.8030506@kenweb.org> <3DFD6833-78C1-43D2-8074-6C89CFE3F2F3@arbor.net> <20110106043110.21C96876D21@drugs.dv.isc.org> <4D254ED8.6030006@matthew.at> Message-ID: <4D25F971.4090709@matthew.at> On 1/5/2011 9:39 PM, Cameron Byrne wrote: > > I understand my users pretty well, they only go to a few web pages ... > its the nature of the net. I assure you, i am not taking any undue > risk with regards to web. Try our friendly user trial and give me > your feedback, thats why i am running it. I'm not particularly surprised that a mobile client platform has a different access pattern than desktop users... not a whole lot of mobile BitTorrent clients yet, for instance. > > Ah Skype. According to your web page you work at Skype. Skype is a > well known IPv6 spoiler application. In fact, in the IETF and many > other circles, Skype is the only app that we can't seem to get to work > with IPv6. Are you here to help with that or to tell us that we need > to keep IPv4 around indefinitely? Indeed, I work at Skype now and Adobe (developing RTMFP) before that. At this point (because not everyone has IPv6) this class of applications (along with BitTorrent and ICE-using VoIP apps) needs to be able to use your NAT64 to talk to peers that are IPv4-only. To do that, they need to be able to discover your NAT64 even though they're not doing DNS lookups to find the IPv4 addresses of peers. This will take 1) a way to do this and 2) upgrades of the apps to take advantage of it. It is impossible to do #2 until #1 is solved. There's been discussion in BEHAVE about this topic... draft-korhonen-behave-nat64-learn-analysis for instance. I even proposed a solution that wasn't raised in that or previous documents here: http://www.ietf.org/mail-archive/web/behave/current/msg09050.html (which I suppose, since it hasn't been mentioned elsewhere, should be written up as a draft if/when I have some free time) > Skype should not be the IPv6 spoiler app when > NEARLY EVERYTHING ELSE WORKS. Read the thread i mentioned, real > users, real developers, real network that is IPv6-only. Notice that > things generally work, those folks have hacked their way to perhaps > even making Skype work. There's lots of other apps that don't work. Skype is just the squeaky wheel because it is so popular. > > Seriously, 95+% of my traffic is web and email, and STUN and ICE don't > matter much to grandma as long as m.v6.facebook.com loads. See my above comment about how I'm not surprised, given the specific client population. > > As long as dual-stack is around, the app vendors don't have to move > and network guys have to dream up hacks to support these legacy apps > (CGN ....). Dual-stack + NAT44 has a lot fewer unsolved corner cases *and* doesn't require apps to be upgraded to do discovery of the NAT64 prefix(es) (which, for some legacy apps that are no longer under development will never happen). NAT64/DNS64 is an interesting experiment that works for >95% of the web. But it isn't really a solution unless "the web" is all you care about. Matthew Kaufman From cb.list6 at gmail.com Thu Jan 6 12:07:16 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Thu, 6 Jan 2011 10:07:16 -0800 Subject: Problems with removing NAT from a network In-Reply-To: <4D25F971.4090709@matthew.at> References: <4D252B1F.8030506@kenweb.org> <3DFD6833-78C1-43D2-8074-6C89CFE3F2F3@arbor.net> <20110106043110.21C96876D21@drugs.dv.isc.org> <4D254ED8.6030006@matthew.at> <4D25F971.4090709@matthew.at> Message-ID: On Thu, Jan 6, 2011 at 9:18 AM, Matthew Kaufman wrote: > On 1/5/2011 9:39 PM, Cameron Byrne wrote: >> >> I understand my users pretty well, they only go to a few web pages ... >> its the nature of the net. ?I assure you, i am not taking any undue >> risk with regards to web. ?Try our friendly user trial and give me >> your feedback, thats why i am running it. > > I'm not particularly surprised that a mobile client platform has a different > access pattern than desktop users... not a whole lot of mobile BitTorrent > clients yet, for instance. >> >> Ah Skype. ?According to your web page you work at Skype. ?Skype is a >> well known IPv6 spoiler application. ?In fact, in the IETF and many >> other circles, Skype is the only app that we can't seem to get to work >> with IPv6. ?Are you here to help with that or to tell us that we need >> to keep IPv4 around indefinitely? > > Indeed, I work at Skype now and Adobe (developing RTMFP) before that. > > At this point (because not everyone has IPv6) this class of applications > (along with BitTorrent and ICE-using VoIP apps) needs to be able to use your > NAT64 to talk to peers that are IPv4-only. To do that, they need to be able > to discover your NAT64 even though they're not doing DNS lookups to find the > IPv4 addresses of peers. > > This will take 1) a way to do this and 2) upgrades of the apps to take > advantage of it. It is impossible to do #2 until #1 is solved. > > There's been discussion in BEHAVE about this topic... > draft-korhonen-behave-nat64-learn-analysis for instance. I even proposed a > solution that wasn't raised in that or previous documents here: > http://www.ietf.org/mail-archive/web/behave/current/msg09050.html (which I > suppose, since it hasn't been mentioned elsewhere, should be written up as a > draft if/when I have some free time) > Skype is not defined in an IETF RFC, so saying you need an RFC to move forward is bit confusing. There are several methods that just work today, I am all for standards, but a closed platforms generally find ways to progress without or in spite of standards. Skype is a closed platform. >> ?Skype should not be the IPv6 spoiler app when >> NEARLY EVERYTHING ELSE WORKS. ?Read the thread i mentioned, real >> users, real developers, real network that is IPv6-only. ?Notice that >> things generally work, those folks have hacked their way to perhaps >> even making Skype work. > > There's lots of other apps that don't work. Skype is just the squeaky wheel > because it is so popular. > Please make a list and let us know. Otherwise, this is just hand waving like the IPv4 literals sites. I have had people on various mailing list tell me all things they think won't work, but in my own experience and in the experience of my beta users, who are publicly documenting their efforts on the support boards, things work well. Yes, some things don't work due the fact that it is a beta and something don't work due to the fact that it is IPv6-only, but they are not show stoppers for the business. As a user, i have been using IPv6-only on Symbian for 9 months without an issue. The service works as i would expect it to with IPv4, no user perceived differences. Skype is a squeaky wheel, but most (99%) things users do works fine. As mentioned, in mobile, 95+% of the traffic is web and email. And, most "apps", are also just web and email. My advice to Skype is to come up with a solution to work for IPv6-only clients. That is my advice to all apps and all content. IPv6-only clients are an obvious reality in an IPv4 exhausted world. You cannot seriously come to a network operators support mailing list and say that the network guys have to keep investing in network tweaks while you wait for a standards body to solve a problem for your closed non-standard applications. I won't go into my diatribe about why dual-stack is not an obvious choice in mobile, you can check the video of it at the google IPv6 conference in 2010. If you have further questions, i am glad to help you understand and entertain your ideas off list. The main point is the dual-stack and substantially more expensive and the IPv4 part of dual-stack is run out of addresses....private, public, bogon. http://www.youtube.com/watch?v=1GlRgaFriYU#t=15m38s > >> >> Seriously, 95+% of my traffic is web and email, and STUN and ICE don't >> matter much to grandma as long as m.v6.facebook.com loads. > > See my above comment about how I'm not surprised, given the specific client > population. >> >> As long as dual-stack is around, the app vendors don't have to move >> and network guys have to dream up hacks to support these legacy apps >> (CGN ....). > > Dual-stack + NAT44 has a lot fewer unsolved corner cases *and* doesn't > require apps to be upgraded to do discovery of the NAT64 prefix(es) (which, > for some legacy apps that are no longer under development will never > happen). > Dual-stack cost the mobile network operator 2x in the packet core, check the Youtube video. It is not acceptable to ask the network operators to increase their cost by 2x while the apps sit and wait. > NAT64/DNS64 is an interesting experiment that works for >95% of the web. But > it isn't really a solution unless "the web" is all you care about. > Experiment? Yes, the experiment part is over. As i mentioned, we are deploying. The 3GPP has adopted IPv6-Only + NAT64 as an official path nearly a year ago. I have tried to make it clear to folks that upgrading to IPv6 is the only way to ensure your apps and content continue to work as you expected. Otherwise, you traverse NAT64 CGN and some things won't work. The same is true for DS-lite and others, but in different ways. To that end, lets partner up and make Skype work with IPv6. I also assure you, many mobile operators are pursuing this NAT64 path for the same reason I am. Cameron > Matthew Kaufman > > From owen at delong.com Thu Jan 6 12:20:06 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 6 Jan 2011 10:20:06 -0800 Subject: NIST IPv6 document In-Reply-To: <8469431D-AD95-4B75-9CDC-9C0176ED8CF9@arbor.net> References: <201101060308.p0638wha085757@aurora.sol.net> <8469431D-AD95-4B75-9CDC-9C0176ED8CF9@arbor.net> Message-ID: <3B61690A-3D51-4847-87B5-84D7D1949BF3@delong.com> On Jan 5, 2011, at 7:18 PM, Dobbins, Roland wrote: > > On Jan 6, 2011, at 10:08 AM, Joe Greco wrote: > >> Packing everything densely is an obvious problem with IPv4; we learned early on that having a 48-bit (32 address, 16 port) space to scan made >> port-scanning easy, attractive, productive, and commonplace. > > I don't believe that host-/port-scanning is as serious a problem as you seem to think it is, nor do I think that trying to somehow prevent host from being host-/port-scanned has any material benefit in terms of security posture, that's our fundamental disagreement. > You are mistaken... Host scanning followed by port sweeps is a very common threat and still widely practiced in IPv4. > If I've done what's necessary to secure my hosts/applications, host-/port-scanning isn't going to find anything to exploit (overly-aggressive scanning can be a DoS vector, but there are ways to ameliorate that, too). > And there are ways to mitigate ND attacks as well. > If I haven't done what's necessary to secure my hosts/applications, one way or another, they *will* end up being exploited - and the faux security-by-obscurity offered by sparse addressing won't matter a bit. > Sparse addressing is a win for much more than just rendering scanning useless, but, making scanning useless is still a win. Owen From bonomi at mail.r-bonomi.com Thu Jan 6 12:32:11 2011 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Thu, 6 Jan 2011 12:32:11 -0600 (CST) Subject: Verizon DSL Transport Contact? In-Reply-To: <712ffc5aa87a56c165dac04136322c0c.squirrel@www.velocity.net> Message-ID: <201101061832.p06IWBaH068593@mail.r-bonomi.com> From oberman at es.net Thu Jan 6 13:03:30 2011 From: oberman at es.net (Kevin Oberman) Date: Thu, 06 Jan 2011 11:03:30 -0800 Subject: ARIN and the RPKI (was Re: AltDB?) In-Reply-To: Your message of "Thu, 06 Jan 2011 14:24:01 +0900." Message-ID: <20110106190330.4FADA1CC3E@ptavv.es.net> > Date: Thu, 06 Jan 2011 14:24:01 +0900 > From: Randy Bush > > > I think ACLs here means prefix-lists ... or I hope that's what Randy > > meant? > > sorry. yes, irr based prefix lists. and, sad to say, data which have > sucked for 15+ years. i was the poster child for the irr, and it just > never took off. > > [ irr data are pretty bad except for some islands where there is culture > of maintining them. and, as it is a global internet, islands don't > help much. europe and japan are two islands with better than the > average irr data quality. and they have rpki rolling to varied > degrees. ] The day of reasonable accuracy of the IRR ended when UUnet bought ANI. Since ANI actually used the IRR to generate there router configs and ANI was pretty big, people were really forced to register. Curtis had a lot of excellent software that did all sorts of impressive stuff with the IRR, but I guess that all went into the bit bucket when UUnet took over. Very, very sad! -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From trejrco at gmail.com Thu Jan 6 14:09:29 2011 From: trejrco at gmail.com (TJ) Date: Thu, 6 Jan 2011 15:09:29 -0500 Subject: NIST IPv6 document In-Reply-To: <04F29819-226A-4507-8BCE-C409EC5BFB77@arbor.net> References: <20110105043548.BC01B1CC3E@ptavv.es.net> <7BA6E87C-7CAD-44DD-BBC1-58DDADD458D5@muada.com> <4D24A4A7.7080208@bogus.com> <04F29819-226A-4507-8BCE-C409EC5BFB77@arbor.net> Message-ID: On Wed, Jan 5, 2011 at 17:44, Dobbins, Roland wrote: > > On Jan 6, 2011, at 1:02 AM, TJ wrote: > > > if you are permitting external hosts the ability to scan your internal > network in an unrestricted > > fashion > > DCN aside, how precisely does one define 'internal network' in, say, the > context of the production network of a broadband access SP, or > hosting/colocation/VPS/IaaS SP? > In that scenario, "internal" would be the SP's network itself - traffic actually directed to their infrastructure. From randy at psg.com Thu Jan 6 14:16:29 2011 From: randy at psg.com (Randy Bush) Date: Fri, 07 Jan 2011 05:16:29 +0900 Subject: ARIN resource certification service update In-Reply-To: <927929DA-B56D-4FF4-A41D-245224939466@corp.arin.net> References: <94F3F129-608E-46EC-B157-CC23CAA47454@tozz.net> <4D24A734.3000807@jcoley.net> <816AB912-14CF-4028-853A-F0BE77D2EB09@puck.nether.net> <927929DA-B56D-4FF4-A41D-245224939466@corp.arin.net> Message-ID: hi john, sorry to disturb your cruise. as you know, from the get go, the hierarchic nature of the pki has worried the ops folk involved. this is why documents such as draft-ietf-sidr-rpki-origin-ops-00.txt say things such as RPKI-based origin validation has been designed so that, with prudent local routing policies, there is no liability that normal Internet routing is threatened by unprudent deployment of the global RPKI, see Section 5. ... 5. Routing Policy Origin validation based on the RPKI merely marks a received announcement as having an origin which is Validated, Unknown, or Invalid. How this is used in routing is up to the router operator's local policy. See [I-D.pmohapat-sidr-pfx-validate]. Reasonable application of local policy should be designed eliminate the threat of unroutability of prefixes due to ill-advised or incorrect certification policies. As origin validation will be rolled out over years coverage will be spotty for a long time. Hence a normal operator's policy should not be overly strict, perhaps preferring valid announcements and giving very low preference, but still using, invalid announcements. Some may choose to use the large Local-Preference hammer. Others might choose to let AS-Path rule and set their internal metric, which comes after AS-Path in the BGP decision process. Certainly, routing on unknown validity state will be prevalent for a long time. Until the community feels comfortable relying on RPKI data, routing on invalid origin validity, though at a low preference, may be prevalent for a long time. Announcements with valid origins SHOULD be preferred over those with unknown or invalid origins. Announcements with unvalidatable origins SHOULD be preferred over those with invalid origins. Announcements with invalid origins MAY be used, but SHOULD be less preferred than those with valid or unknown. of course, in the US, this will not prevent litigation. nothing will. it's a mental disease. randy From trejrco at gmail.com Thu Jan 6 14:17:07 2011 From: trejrco at gmail.com (TJ) Date: Thu, 6 Jan 2011 15:17:07 -0500 Subject: NIST IPv6 document In-Reply-To: References: <20110105043548.BC01B1CC3E@ptavv.es.net> <7BA6E87C-7CAD-44DD-BBC1-58DDADD458D5@muada.com> <4D24A4A7.7080208@bogus.com> Message-ID: On Wed, Jan 5, 2011 at 13:14, Jeff Wheeler wrote: > On Wed, Jan 5, 2011 at 1:02 PM, TJ wrote: > > Many would argue that the version of IP is irrelevant, if you are > permitting > > external hosts the ability to scan your internal network in an > unrestricted > > fashion (no stateful filtering or rate limiting) you have already lost, > you > > How do you propose to rate-limit this scanning traffic? More router > knobs are needed. This also does not solve problems with malicious > hosts on the LAN. > Off the top of my head, maybe just slow down the generation of new NS attempts when under attack (without impacting the NUD-based NS). > > A stateful firewall on every router interface has been suggested > already on this thread. It is unrealistic. > > > Even granting that, for the sake of argument - it seems like it would not > be > > hard for $vendor to have some sort of "emergency garbage collection" > > routines within their NDP implementations ... ? > > How do you propose the router know what entries are "garbage" and > which are needed? Eliminating active, "good" entries to allow for > more churn would make the problem much worse, not better. Again, off the top of my head, maybe - when under duress - age out the incomplete ND table entries faster. /TJ From jbates at brightok.net Thu Jan 6 14:43:39 2011 From: jbates at brightok.net (Jack Bates) Date: Thu, 06 Jan 2011 14:43:39 -0600 Subject: NIST IPv6 document In-Reply-To: References: <20110105043548.BC01B1CC3E@ptavv.es.net> <7BA6E87C-7CAD-44DD-BBC1-58DDADD458D5@muada.com> <4D24A4A7.7080208@bogus.com> Message-ID: <4D26297B.3060803@brightok.net> On 1/6/2011 2:17 PM, TJ wrote: > Again, off the top of my head, maybe - when under duress - age out the > incomplete ND table entries faster. > Given that the incomplete age is to protect the L2 network from excessive broadcast/multicast, I agree that aging them out fast would be a wiser solution, if you must have it to begin with. It is better to increase traffic loads. I'm still a proponent for removing as needed requests like this, though. It would have been better to send a global "everyone update me" request periodically, even if triggered by an unknown entry, yet limited to only broadcasting once every 10-30 seconds. Given that all requests for an unknown arp/ND entry results in all hosts on the network checking, it only makes sense for all hosts to respond. There may be other concerns, but I'm actually not against all hosts responding via multicast to all other hosts, so that a full mesh can be established ahead of time. The idea of minimizing the table to an as-needed basis should not have continued with IPv6. Special provisions could be handled when dealing with proxy-ND, but I'm not sure that is needed either. Jack From william.allen.simpson at gmail.com Thu Jan 6 14:47:58 2011 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Thu, 06 Jan 2011 15:47:58 -0500 Subject: NIST IPv6 document In-Reply-To: References: <201101060626.p066Q4ak088421@aurora.sol.net> Message-ID: <4D262A7E.9060101@gmail.com> On 1/6/11 1:47 AM, Paul Ferguson wrote: > As someone who has been immersed in security for many years now, and having > previously been very intimately involved in the network ops community for > equally many years, I have to agree with Roland here. Just because a lot of > smart people have worked on IPv6 for many years does not mean that the > security issues have been equally well thought out. > > ... > > This is not meant as a slight to anyone -- just a realization of looking at > security from a real-world perspective. It seems to always have to get > "bolted on" as an afterthought, instead of baked-in from the beginning. > I've not read everything in this thread yet. So, this may have already been mentioned. But Security *was* baked-in from the beginning of IPv6. IT WAS TAKEN OUT! I was one of the original IPng PIPE->SIP->SIPP->IPv6 designers. We knew about *all* of these problems mentioned thus far in this thread. IPsec was originally designed for SIP->SIPP->IPv6, and I back-ported it to IPv4 after IPv6 was hijacked by committee. As to Neighbor Discovery, the original specifications eliminated ARP, DHCP, and OSPF, *and* routers knew all hosts on the local net, *and* both hosts and routers automatically renumbered. Everything that folks have asked for thus far. Google tells me that draft-ietf-sip-discovery-03.txt is still on-line. I've not found my -04, -05, or -06 on-line, so I've occasionally been looking through old backups lately as time allows. Sadly, those systems are long dead, and finding actual systems to read my old data makes the recovery process rather slow. Anyway, don't blame the original designers. We knew what we were doing! Blame the vendors (and their lackeys) that had vested interests in making IPv6 into IPv4 with bigger addresses, and *removing* security. From morrowc.lists at gmail.com Thu Jan 6 15:06:39 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 6 Jan 2011 16:06:39 -0500 Subject: ARIN and the RPKI (was Re: AltDB?) In-Reply-To: <20110106190330.4FADA1CC3E@ptavv.es.net> References: <20110106190330.4FADA1CC3E@ptavv.es.net> Message-ID: On Thu, Jan 6, 2011 at 2:03 PM, Kevin Oberman wrote: >> Date: Thu, 06 Jan 2011 14:24:01 +0900 >> From: Randy Bush >> >> > I think ACLs here means prefix-lists ... or I hope that's what Randy >> > meant? >> >> sorry. ?yes, irr based prefix lists. ?and, sad to say, data which have >> sucked for 15+ years. ?i was the poster child for the irr, and it just >> never took off. >> >> [ irr data are pretty bad except for some islands where there is culture >> ? of maintining them. ?and, as it is a global internet, islands don't >> ? help much. ?europe and japan are two islands with better than the >> ? average irr data quality. ?and they have rpki rolling to varied >> ? degrees. ] > > The day of reasonable accuracy of the IRR ended when UUnet bought > ANI. Since ANI actually used the IRR to generate there router configs s/NI/NS/g > and ANI was pretty big, people were really forced to register. Curtis s/NI/NS/ > had a lot of excellent software that did all sorts of impressive stuff > with the IRR, but I guess that all went into the bit bucket when UUnet > took over. we did require you to email nacr-list@ :) that didn't help? All sed jokes aside, would having attestations that the route you see is part of a block assigned by IANA to ARIN and from ARIN to UUNET and from UUNET to JoesCrabShuckers make sense to you? (and to your router policy provided the router policy engine and code worked) The efficacy of the IRR isn't at question, the ability to assure with some level of reasonableness that the thing you see (and eventually it's path to get to you) is "valid" is what the RPKI system is building toward. -Chris > Very, very sad! (tears were shed) > -- > R. Kevin Oberman, Network Engineer > Energy Sciences Network (ESnet) > Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) > E-mail: oberman at es.net ? ? ? ? ? ? ? ? ?Phone: +1 510 486-8634 > Key fingerprint:059B 2DDF 031C 9BA3 14A4 ?EADA 927D EBB3 987B 3751 > From jbates at brightok.net Thu Jan 6 15:14:24 2011 From: jbates at brightok.net (Jack Bates) Date: Thu, 06 Jan 2011 15:14:24 -0600 Subject: NIST IPv6 document In-Reply-To: <4D262A7E.9060101@gmail.com> References: <201101060626.p066Q4ak088421@aurora.sol.net> <4D262A7E.9060101@gmail.com> Message-ID: <4D2630B0.5030108@brightok.net> On 1/6/2011 2:47 PM, William Allen Simpson wrote: > Google tells me that draft-ietf-sip-discovery-03.txt is still on-line. > I've not found my -04, -05, or -06 on-line, so I've occasionally been > looking through old backups lately as time allows. Sadly, those systems > are long dead, and finding actual systems to read my old data makes the > recovery process rather slow. > " When a host or router needs the location of a target host on the local media, it sends a media multicast solicitation for the location of the host, followed by a media multicast of the original data packet. The target node issues an advertisement which indicates its current reachability. " Umm, so it sends a data packet to everyone instead of waiting and sending a unicast packet? Seems rather insecure if that packet wasn't encrypted, not to mention noisy. In addition, I'd hate to see what happens when more than one packet arrives prior to the target node's advertisement being received. Contrary to my last email (where I didn't consider mobile devices and similar which do have memory restrictions), I agree with the as-needed basis, except for routers. A router should have all necessary information and not just as-needed. One could argue that routers can't process that much data, but given the trends I've seen in IOS and other vendors of refreshing arp every 10s or less, I'm pretty sure they can handle it. To streamline the process and since we are using multicast, hosts can just tell the router multicast address who they are to quickly update all local router ND caches, and could just as easily expire an address from the cache. The usual options we use for securing ARP could still apply in this scenario. Jack From jsw at inconcepts.biz Thu Jan 6 15:21:08 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Thu, 6 Jan 2011 16:21:08 -0500 Subject: NIST IPv6 document In-Reply-To: <86zkreb486.fsf@seastrom.com> References: <20110105043548.BC01B1CC3E@ptavv.es.net> <4661ED7E-A4DA-4CD4-A7EB-C5B2E615F126@delong.com> <86zkreb486.fsf@seastrom.com> Message-ID: On Thu, Jan 6, 2011 at 7:34 AM, Robert E. Seastrom wrote: > I continue to believe that the "allocate the /64, configure the /127 > as a workaround for the router vendors' unevolved designs" approach, As a point of information, I notice that Level3 has deployed without doing this, e.g. they have densely packed /126 subnets which are conceptually identical to /30s for infrastructure and point-to-point. I am still taking your conservative approach, as I see no operational disadvantage to it; but opinions must differ. On Thu, Jan 6, 2011 at 11:28 AM, wrote: > And the "ZOMG they can overflow the ARP/ND/whatever table" is a total red > herring - you know damned well that if a script kiddie with a 10K node botnet > wants to hose down your network, you're going to be looking at a DDoS, and it > really doesn't matter whether it's SYN packets, or ND traffic, or forged ICMP > echo-reply mobygrams. I agree, botnets are large enough to DDoS most things. However, with the current state of ARP/ND table implementations in some major equipment vendors' routers, combined with standards-compliant configuration, it doesn't take a botnet. I could DoS your subnet (or whole router) without a botnet, say, using an IPv6 McDonald's Wi-Fi hotspot. That is very much a legitimate concern. A few hundred packets per second will be enough to cripple some platforms. On Thu, Jan 6, 2011 at 1:20 PM, Owen DeLong wrote: > And there are ways to mitigate ND attacks as well. No, Owen, there aren't. The necessary router knobs do not exist. The "Cisco approach" is currently to police NDP on a per-interface basis (either with per-int or global configuration knob) and break NDP on the interface once that policer is exceeded. This is good (thanks, Cisco) because it limits damage to one subnet; but bad because it exemplifies the severity of the issue: the "Cisco solution" is known to be bad, but is less bad than letting the whole box break. Cisco is not going to come up with a magic knob because there isn't any -- with the current design, you have to pick your failure modes and live with them. That's not good and it is not a Cisco failing by any means, it is a design failing brought on by the standards bodies. I would also like to reply in public to a couple of off-list questions, because the questions are common ones, the answers are not necessarily cut-and-dry (my opinion is only one approach; there are others) and this is the kind of useful discussion needed to address this matter. I will leave out the names of the people asking since they emailed me in private, but I'm sure they won't mind me pasting their questions. Anonymous Questioner: >What do you think about using only link-local ip addresses on the infrastructure links please? I can't think of any potential drawbacks do you? This can be done, but then you don't have a numbered next-hop for routing protocols. That's okay if you re-write it to something else. Note that link-local subnets still have an NDP table, and if that resource is exhausted due to attacks on the router, neighbors with link-local addressing are not immune. link-local scope offers numerous advantages which are mostly out-weighed by more practical concerns, like, how hard it is going to be to convince the average Windows sysadmin to configure his machine to suit such a design, instead of just taking his business elsewhere. Not a problem for enterprise/gov/academia so much, but a problem for service providers. On Thu, Jan 6, 2011 at 3:43 PM, Jack Bates wrote: > Given that the incomplete age is to protect the L2 network from excessive > broadcast/multicast, I agree that aging them out fast would be a wiser I agree that it would be nice to have such a knob. I bet you and I would make different choices about how to use it, which is the whole point of having a knob instead of a fixed value. > I'm still a proponent for removing as needed requests like this, though. It > would have been better to send a global "everyone update me" request > periodically, even if triggered by an unknown entry, yet limited to only > broadcasting once every 10-30 seconds. > Given that all requests for an unknown arp/ND entry results in all hosts on > the network checking, it only makes sense for all hosts to respond. There This isn't a new idea and it has its own set of problems, which are well-understood. IPv6 NS messages are more clever than ARP, though, and are sent to a computed multicast address. This means that the number of hosts which receive the message is minimized. See RFC2461 section 2.3 for the quick introduction. NDP is better than ARP. However, your statement that NDP has all (I'd like to say some) of the same problems as ARP but the increased subnet size has magnified them, is basically correct. NDP does some things a lot better than ARP, but not this. It's important to realize that when this stuff was designed, there were few hardware-based layer-3 routers for IPv4. The biggest networks (Sprint/UUnet/etc) were exchanging a few hundred megabits per second on PNIs and the tier-2 guys had DS3s to IXPs. The network has come a long way in terms of user-base, bandwidth, and sophistication since then. Second Anonymous Questioner: > That is, I don't see why a smart rate-limiting implementation doesn't solve most of it. This is a good question, which I have tried to cover in much earlier posts, perhaps without explaining it effectively. There currently are major vendors shipping IPv6 routers which age out ARP/NDP entries even if they have continuous traffic -- these routers do an occasional ARP/NDP "refresh" even though the neighbor is constantly sending and receiving traffic. For this reason, an attack can trigger your rate-limit and prevent the "refresh" from working. So over a period of time, all hosts attached to the router will stop working. Smarter platforms are still unable to learn about new neighbors when your rate-limit is being triggered. How bad this is depends on the implementation. Finally, any compromised host on the LAN can fill up the NDP table for the interface (which on most platforms, really means fill up the combined NDP/ARP table for the whole box) and either prevent any new neighbor associations, or far worse, cause churn that will disable the entire router and all traffic that needs to transit through it. This is extremely bad, and yet, it is trivial to execute if you have access to a machine on the LAN. >Yes, during this period, lots of unreachables will not be sent, Unreachables are really of no concern. The router staying up, and its interfaces continuing to function correctly, are in question. Actually, they're not so much in question ... because all existing IPv6 routers can be broken with the trivial method we are discussing if /64 subnets are in use. What's implementation-specific is "how broken," but as you can read above, Cisco has given customers a knob to control the damage, but it's very, very far from a complete solution. Unlike Cisco, some other vendors haven't given this the first thought, let alone added a knob; but even Cisco must do more. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From smb at cs.columbia.edu Thu Jan 6 15:31:27 2011 From: smb at cs.columbia.edu (Steven Bellovin) Date: Thu, 6 Jan 2011 16:31:27 -0500 Subject: The FCC on IPv6 Message-ID: <180D67A7-F744-4E5D-8161-3D9C24FD4BDF@cs.columbia.edu> http://hraunfoss.fcc.gov/edocs_public/attachmatch/DOC-303870A1.pdf --Steve Bellovin, http://www.cs.columbia.edu/~smb From matthew at matthew.at Thu Jan 6 15:32:23 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 06 Jan 2011 13:32:23 -0800 Subject: Problems with removing NAT from a network In-Reply-To: References: <4D252B1F.8030506@kenweb.org> <3DFD6833-78C1-43D2-8074-6C89CFE3F2F3@arbor.net> <20110106043110.21C96876D21@drugs.dv.isc.org> <4D254ED8.6030006@matthew.at> <4D25F971.4090709@matthew.at> Message-ID: <4D2634E7.2060502@matthew.at> On 1/6/2011 10:07 AM, Cameron Byrne wrote: > > Skype is not defined in an IETF RFC, so saying you need an RFC to move > forward is bit confusing. I don't see a disconnect at all. Skype also uses TCP and UDP, which are both subjects of RFCs. That said, it doesn't need to be an RFC... just *a reliable way* of discovering the appropriate NAT64 prefix. > There are several methods that just work > today, Of the methods proposed in the survey draft, only one - the one that doesn't require the DNS64 spec or operator to make any changes (making an AAAA lookup for something you know only has an A record) - works but *only if* the mapping scheme is such that it is possible to successfully derive a functional prefix and the scheme from the results of that query. So in other words, *if* the query results in an AAAA where, by inspection, you can guess where you'd need to stuff the IPv4 address bits *and* the resulting address causes the "right" NAT64 (if there's >1) to be used, then you're set. > I am all for standards, but a closed platforms generally find ways to > progress without or in spite of standards. Skype is a closed > platform. No question. And for all you know we might be working on other ways around this problem, but none of them as elegant as a defined specification for how to discover the presence of a NAT64 and the mapping. > >> There's lots of other apps that don't work. Skype is just the squeaky wheel >> because it is so popular. >> > Please make a list and let us know. Otherwise, this is just hand > waving like the IPv4 literals sites. I'll start with "peer to peer connectivity using RTMFP in Flash Player" and "BitTorrent". Both Flash Player and BitTorrent are fairly popular on desktop platforms. I'm sure there's more. > My advice to Skype is to come up with a solution to work for IPv6-only > clients. That is my advice to all apps and all content. IPv6-only > clients are an obvious reality in an IPv4 exhausted world. That's not the problem... the problem is reaching the existing base of IPv4 clients from those IPv6-only clients without making Skype relay all the traffic via servers somewhere, as I'm sure you know. > You cannot seriously come to a network operators support mailing list > and say that the network guys have to keep investing in network tweaks > while you wait for a standards body to solve a problem for your closed > non-standard applications. I've been on this list since approximately the time it was formed, so I'm not coming here to ask for something. Just pointing out what will break. > I also assure you, many mobile operators are pursuing this NAT64 path > for the same reason I am. Randy Bush would encourage his competitors to do just as you've done, I'm sure. Matthew Kaufman From deepak at ai.net Thu Jan 6 16:00:42 2011 From: deepak at ai.net (Deepak Jain) Date: Thu, 6 Jan 2011 17:00:42 -0500 Subject: IPv6 - real vs theoretical problems Message-ID: Please, before you flame out, recognize I know a bit of what I am talking about. You can verify this by doing a search on NANOG archives. My point is to actually engage in an operational discussion on this and not insult (or be insulted). While I understand the theoretical advantages of /64s and /56s and /48s for all kinds of purposes, *TODAY* there are very few folks that are actually using any of them. No typical customer knows what do to do (for the most part) with their own /48, and other than autoconfiguration, there is no particular advantage to a /64 block for a single server -- yet. The left side of the prefix I think people and routers are reasonably comfortable with, it's the "host" side that presents the most challenge. My interest is principally in servers and high availability equipment (routers, etc) and other things that live in POPs and datacenters, so autoconfiguration doesn't even remotely appeal to me for anything. In a datacenter, many of these concerns about having routers fall over exist (high bandwidth links, high power equipment trying to do as many things as it can, etc). Wouldn't a number of problems go away if we just, for now, follow the IPv4 lessons/practices like allocating the number of addresses a customer needs --- say /122s or /120s that current router architectures know how to handle -- to these boxes/interfaces today, while just reserving /64 or /56 spaces for each of them for whenever the magic day comes along where they can be used safely? As far as I can tell, this "crippling" of the address space is completely reversible, it's a reasonable step forward and the only "operational" loss is you can't do all the address jumping and obfuscation people like to talk about... which I'm not sure is a loss. In your enterprise, behind your firewall, whatever, where you want autoconfig to work, and have some way of dealing with all of the dead space, more power to you. But operationally, is *anything* gained today by giving every host a /64 to screw around in that isn't accomplished by a /120 or so? Thanks, DJ From jbates at brightok.net Thu Jan 6 16:14:25 2011 From: jbates at brightok.net (Jack Bates) Date: Thu, 06 Jan 2011 16:14:25 -0600 Subject: IPv6 - real vs theoretical problems In-Reply-To: References: Message-ID: <4D263EC1.3010007@brightok.net> On 1/6/2011 4:00 PM, Deepak Jain wrote: > In your enterprise, behind your firewall, whatever, where you want > autoconfig to work, and have some way of dealing with all of the dead > space, more power to you. But operationally, is*anything* gained > today by giving every host a /64 to screw around in that isn't > accomplished by a /120 or so? Today, I still like SLAAC. All my servers support specifying tokens for the host portion of the prefix. Pre-config, many utilize traditional SLAAC and end up in a range which is stateful firewall protected by the routers until such time as I can renumber them into the appropriate range. Anyways, ARIN just approved my new allocation and I have to go renumber all those servers. At least assigning the new IPv6 addresses only requires a quick router edit. Application changes will take longer, of course, since we don't automatically generate DNS and other nifties. The helpdesk, home, and customer trial networks should hopefully renumber with easy per my last renumbering trial. Link addressing, loopback changes, BGP, etc in the routers will still be a PITA. Jack From grant.phillips at gwtp.id.au Thu Jan 6 16:47:28 2011 From: grant.phillips at gwtp.id.au (Grant Phillips) Date: Fri, 7 Jan 2011 09:47:28 +1100 Subject: IPv6 - real vs theoretical problems In-Reply-To: References: Message-ID: Hi Deepak, I acknowledge and see the point made. There is a lot of dead space in the IPv6 world. Are we allowing history to repeat it self? Well i'm swaying more to no. Have you read this RFC? This is pretty satisfying in making me feel more comfortable assigning out /48 and /64's. I can sleep at night now! :P http://tools.ietf.org/html//rfc3177 Cheers, Grant Phillips On Fri, Jan 7, 2011 at 9:00 AM, Deepak Jain wrote: > > Please, before you flame out, recognize I know a bit of what I am talking > about. You can verify this by doing a search on NANOG archives. My point is > to actually engage in an operational discussion on this and not insult (or > be insulted). > > While I understand the theoretical advantages of /64s and /56s and /48s for > all kinds of purposes, *TODAY* there are very few folks that are actually > using any of them. No typical customer knows what do to do (for the most > part) with their own /48, and other than autoconfiguration, there is no > particular advantage to a /64 block for a single server -- yet. The left > side of the prefix I think people and routers are reasonably comfortable > with, it's the "host" side that presents the most challenge. > > My interest is principally in servers and high availability equipment > (routers, etc) and other things that live in POPs and datacenters, so > autoconfiguration doesn't even remotely appeal to me for anything. In a > datacenter, many of these concerns about having routers fall over exist > (high bandwidth links, high power equipment trying to do as many things as > it can, etc). > > Wouldn't a number of problems go away if we just, for now, follow the IPv4 > lessons/practices like allocating the number of addresses a customer needs > --- say /122s or /120s that current router architectures know how to handle > -- to these boxes/interfaces today, while just reserving /64 or /56 spaces > for each of them for whenever the magic day comes along where they can be > used safely? > > As far as I can tell, this "crippling" of the address space is completely > reversible, it's a reasonable step forward and the only "operational" loss > is you can't do all the address jumping and obfuscation people like to talk > about... which I'm not sure is a loss. > > In your enterprise, behind your firewall, whatever, where you want > autoconfig to work, and have some way of dealing with all of the dead space, > more power to you. But operationally, is *anything* gained today by giving > every host a /64 to screw around in that isn't accomplished by a /120 or so? > > Thanks, > > DJ > > > > From rdobbins at arbor.net Thu Jan 6 17:23:53 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 6 Jan 2011 23:23:53 +0000 Subject: NIST IPv6 document In-Reply-To: <201101061429.p06ETB7g096271@aurora.sol.net> References: <201101061429.p06ETB7g096271@aurora.sol.net> Message-ID: On Jan 6, 2011, at 9:29 PM, Joe Greco wrote: > Sorry, but I see this as not grasping a fundamental security concept. I see it as avoiding a common security misconception. > Making a host harder to find (or more specifically to address from remote) is a worthwhile goal. As I've stated repeatedly, I don't think that sparse addressing makes hosts harder to find, because hinted scanning will reveal them. > Things like 4941 take that a lot further, and provide enough bits to make both range scanning and scanning via learned addresses less useful techniques. I believe RFC4941 to be positively evil, that the harm it will do in terms of complicating traceback and attribution far outweigh any supposed benefits (which are questionably, anyways, IMHO). > This is basic security, whether or not you approve of it. You're trying to make it harder for bad guys. My view is that it's basic security theater, which a) makes nothing harder for the bad guys, and b) has unpleasant side-effects which have the net effect of degrading one's overall security posture. ------------------------------------------------------------------------ Roland Dobbins // Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay From rdobbins at arbor.net Thu Jan 6 17:27:04 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 6 Jan 2011 23:27:04 +0000 Subject: NIST IPv6 document In-Reply-To: <15350.1294331336@localhost> References: <201101060651.p066piXN088758@aurora.sol.net> <969A43C1-F11D-425A-B210-1721F893C24B@arbor.net> <15350.1294331336@localhost> Message-ID: <9D6C9127-212A-4B8D-AC6A-3693A4B44372@arbor.net> On Jan 6, 2011, at 11:28 PM, wrote: > Playing devil's advocate for a moment... I don't see this as devil's advocacy, since I've said a) we're already hosed (i.e., what you said) and b), we're going to get even more hosed with IPv6. ;> ------------------------------------------------------------------------ Roland Dobbins // Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay From rdobbins at arbor.net Thu Jan 6 17:29:13 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 6 Jan 2011 23:29:13 +0000 Subject: NIST IPv6 document In-Reply-To: <4D25F279.5000204@brightok.net> References: <201101060651.p066piXN088758@aurora.sol.net> <969A43C1-F11D-425A-B210-1721F893C24B@arbor.net> <15350.1294331336@localhost> <4D25F279.5000204@brightok.net> Message-ID: On Jan 6, 2011, at 11:48 PM, Jack Bates wrote: > It is not the intentional that we should fear, but the unintentional. This is the single largest issue with IPv6 and the whole ND mess in a nutshell - unintentional DoS becomes much more likely. ------------------------------------------------------------------------ Roland Dobbins // Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay From rdobbins at arbor.net Thu Jan 6 17:32:02 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 6 Jan 2011 23:32:02 +0000 Subject: NIST IPv6 document In-Reply-To: <3B61690A-3D51-4847-87B5-84D7D1949BF3@delong.com> References: <201101060308.p0638wha085757@aurora.sol.net> <8469431D-AD95-4B75-9CDC-9C0176ED8CF9@arbor.net> <3B61690A-3D51-4847-87B5-84D7D1949BF3@delong.com> Message-ID: On Jan 7, 2011, at 1:20 AM, Owen DeLong wrote: > You are mistaken... Host scanning followed by port sweeps is a very common threat and still widely practiced in IPv4. I know it's common and widely-practiced. My point is that if the host is security properly, this doesn't matter; and that if it isn't secured properly, it's going to be found via hinted scanning and exploited, anyways. > And there are ways to mitigate ND attacks as well. As has been pointed out elsewhere in this thread, not to the degree of control and certainty needed in production environments. > Sparse addressing is a win for much more than just rendering scanning useless, but, making scanning useless is still a win. Since it doesn't make scanning useless (again, hinted scanning), that 'win' is gone. How else is it supposedly a win? ------------------------------------------------------------------------ Roland Dobbins // Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay From owen at delong.com Thu Jan 6 17:46:49 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 6 Jan 2011 15:46:49 -0800 Subject: NIST IPv6 document In-Reply-To: <201101060517.p065Hwsd087410@aurora.sol.net> References: <201101060517.p065Hwsd087410@aurora.sol.net> Message-ID: On Jan 5, 2011, at 9:17 PM, Joe Greco wrote: >>> It has nothing to do with "security by obscurity". >> >> You may wish to re-read what Joe was saying - he was positing sparse addres= >> sing as a positive good because it will supposedly make it more difficult f= >> or attackers to locate endpoints in the first place, i.e., security through= >> obscurity. I think that's an invalid argument. > > That's not necessarily security through obscurity. A client that just > picks a random(*) address in the /64 and sits on it forever could be > reasonably argued to be doing a form of security through obscurity. > However, that's not the only potential use! A client that initiates > each new outbound connection from a different IP address is doing > something Really Good. > If hosts start cycling their addresses that frequently, don't you run the risk of that becoming a form of DOS on your router's ND tables? Owen From jsw at inconcepts.biz Thu Jan 6 18:01:33 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Thu, 6 Jan 2011 19:01:33 -0500 Subject: IPv6 - real vs theoretical problems In-Reply-To: References: Message-ID: On Thu, Jan 6, 2011 at 5:00 PM, Deepak Jain wrote: > As far as I can tell, this "crippling" of the address space is completely reversible, it's a reasonable step forward and the only "operational" loss is you can't do all the address jumping and obfuscation people like to talk about... which I'm not sure is a loss. I largely agree with you, but my knowledge is similar to yours, and does not extend to dealing with low-end CPE, dormitory LANs, hot spots, or mobile networks. I am by no means an authority in those areas and I remain open to the possibility that there may be some operational advantages to the IPv6 addressing concept for those users. The problem is there are very serious operational disadvantages for you and I, but the standard tells us to do it anyway. I would like the hot spot or mobile guys to be able to choose /64 if they want to. I need to choose otherwise, and customers expecting /64 as the "standard" are going to be disappointed until the standard allows for different choices. I don't have an opinion on whether the address space is truly "crippled." If I did, I'm not sure it would be useful. Classful addressing ran out of gas in IPv4, so IPv6 has a huge number of bits to hopefully avoid a repeat of that. Okay, I can buy into that. There are some major networks who aren't, though, and I think they made a very conscious choice. We won't know if it's a necessary choice for a long time. I will choose to devote my arguing-on-the-mailing-list time to topics I think are more useful to discuss. I do not think you will change very many minds about IPv6 numbering schemes. I hope I will change some minds about the current safety of public /64 LANs and get more folks talking to their vendors about it, which should give us some kind of solution sooner, rather than later. Choose your battles. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From jsw at inconcepts.biz Thu Jan 6 18:18:14 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Thu, 6 Jan 2011 19:18:14 -0500 Subject: NIST IPv6 document In-Reply-To: References: <201101060517.p065Hwsd087410@aurora.sol.net> Message-ID: On Thu, Jan 6, 2011 at 6:46 PM, Owen DeLong wrote: > On Jan 5, 2011, at 9:17 PM, Joe Greco wrote: >> However, that's not the only potential use! ?A client that initiates >> each new outbound connection from a different IP address is doing >> something Really Good. > If hosts start cycling their addresses that frequently, don't you run the > risk of that becoming a form of DOS on your router's ND tables? Of course, Owen. I replied to that specific point in Joe's post earlier, although I have written so much on this thread, I have tried to condense my replies, so anyone reading in thread mode may have missed it. The fact that Joe even makes that suggestion signals how little understanding he has of the problem. His idea would DoS his own router. There are many posts on this thread from folks who think of themselves as expert, at least enough to try and tell me that I'm wrong, when they lack basic understanding of how the forwarding process works in operation. That is what everyone should be afraid of -- most of the "experts" aren't, and almost no one has practical experience with a mission-critical IPv6 network, so conditions like this remain unanalyzed. It took a long time to discover a lot of vulnerabilities as the Internet grew from academia to everyday necessity. We are all now making some obvious, unnecessary mistakes with IPv6 deployments. It is also crucial to understand that some platforms use the same resources (in control plane or data plane) for ARP and NDP tables and resolution, and this means that some dual-stack networks will see their IPv4 networks melt down due to problems with their IPv6 network design and implementation. If you are dual-stack, this is probably not a problem confined to v6 traffic flowing through your network; it may also take out your mission-critical v4 services. If you don't know, then you need to admit you don't know and find out what the failure mode of your routers is, before your network blows up in your face. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From pscanlon at arbor.net Thu Jan 6 19:01:46 2011 From: pscanlon at arbor.net (Paul Scanlon) Date: Thu, 6 Jan 2011 18:01:46 -0700 Subject: NANOG 51 (Miami): ISP Security BOF Message-ID: <96287424-DF08-4C20-B7C7-96B909915900@arbor.net> Hi All, Happy New Year. NANOG 51 in Miami is rapidly approaching, January 30 - February 2, and we are looking for topics for the ISP Security BOF. Eric Osterweil and I are going to be moderating this year with the assistance of Danny McPherson. We would very much like to hear your feedback regarding topics of interest for the session. If you have any security related topics that you would like to hear about, not hear about, or be willing to speak about, please let one of us know as soon as possible, feedback to the list obviously welcome. Slides are welcome but not required. Much thanks, Eric & Paul ------------------------------------ Paul Scanlon Arbor Networks +1.303.477.0919 office +1.303.810.7260 mobile ------------------------------------ From mysidia at gmail.com Thu Jan 6 19:04:20 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 6 Jan 2011 19:04:20 -0600 Subject: IPv6 - real vs theoretical problems In-Reply-To: References: Message-ID: On Thu, Jan 6, 2011 at 4:00 PM, Deepak Jain wrote: > Wouldn't a number of problems go away if we just, for now, follow the IPv4 lessons/practices like allocating the number of addresses a customer needs --- > say /122s or /120s that current router architectures know how to handle -- to these boxes/interfaces today, while just reserving /64 or /56 spaces for > each of them for whenever the magic day comes along where they can be used safely? Trying to run the IPv6 network using IPv4 addressing practices is similar to upgrading your horse and buggy to a sports car, and insisting on driving this car only on dirt roads, avoiding pavements at all costs, due to the danger of slipping, if that was the lesson you learned with horses and buggies. You can probably do it, and survive, but that does not mean it will be advantageous trouble free, advisable, or fun. In this case, you will bring all the negatives (and more) that the practice had with IPv4, for questionable or no advantages. It is advisable to look for much stronger reasons than "With IPv4 we did it" or With IPv4 we ran into such and such problem" due to unique characteristics of IPv4 addressing or other IPv4 conventions that had to continue to exist for compatibility reasons, etc, etc. -- -JH From owen at delong.com Thu Jan 6 19:12:19 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 6 Jan 2011 17:12:19 -0800 Subject: NIST IPv6 document In-Reply-To: References: <201101060626.p066Q4ak088421@aurora.sol.net> <4D25DD6E.8000708@brightok.net> Message-ID: <2C9F54AF-29D1-40C8-8BCD-072DAB3033CA@delong.com> This would break dead-neighbor detection, but, I'm not sure that's necessarily a problem for end hosts at the local router level. It is touted as one of the IPv6 features, but, I'm not sure how valuable it is as a feature. Owen On Jan 6, 2011, at 7:37 AM, Marcel Plug wrote: > Perhaps we're reaching the point where we can say "We don't need an ND > table for a /64 network". If the ethernet MAC is embedded in the IPv6 > address, we don't need to discover it because we already know it. If > the IPv6 address has been manually configured on a host, perhaps that > host should now accept traffic directed to the MAC that the lower 64 > bits of the IPv6 address would translate to. > > Perhaps this idea has been discussed somewhere and discarded for its > flaws, but if not, perhaps it should be :-). > > Marcel > > (First post by the way, go easy on me :-) > > On Thu, Jan 6, 2011 at 10:19 AM, Jack Bates wrote: >> >> On 1/6/2011 12:26 AM, Joe Greco wrote: >>> >>> A bunch of very smart people have worked on IPv6 for a very long >>> time, and justification for /64's was hashed out at extended length >>> over the period of years. >> >> NDP should have been better designed. It still has the same problems we had >> with ARP except the address pool has magnified it. >> >> Routers should have 1) better methods for keeping ND tables low (and >> maintaining only valid entries) or 2) better methods for learning valid >> entries than unsolicited NDP requests. >> >> This isn't to say the protocol itself is a waste, but it should have taken >> in the concerns and developed the mitigation controls necessary as >> recommendations to the implementers. >> >> >> Jack >> >> From randy at psg.com Thu Jan 6 19:38:09 2011 From: randy at psg.com (Randy Bush) Date: Fri, 07 Jan 2011 10:38:09 +0900 Subject: ARIN and the RPKI (was Re: AltDB?) In-Reply-To: References: <20110106190330.4FADA1CC3E@ptavv.es.net> Message-ID: >> had a lot of excellent software that did all sorts of impressive stuff >> with the IRR, but I guess that all went into the bit bucket when UUnet >> took over. > we did require you to email nacr-list@ :) that didn't help? and he processed on wednesday, not exactly optimal for ops. if we are listing those who gave good blood for the irr, joe lawrence and roy alcala, of mci and later level(3), would be at the top of my list. randy From owen at delong.com Thu Jan 6 19:47:12 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 6 Jan 2011 17:47:12 -0800 Subject: NIST IPv6 document In-Reply-To: References: <20110105043548.BC01B1CC3E@ptavv.es.net> <4661ED7E-A4DA-4CD4-A7EB-C5B2E615F126@delong.com> <86zkreb486.fsf@seastrom.com> Message-ID: > > > On Thu, Jan 6, 2011 at 1:20 PM, Owen DeLong wrote: >> And there are ways to mitigate ND attacks as well. > > No, Owen, there aren't. The necessary router knobs do not exist. The > "Cisco approach" is currently to police NDP on a per-interface basis > (either with per-int or global configuration knob) and break NDP on > the interface once that policer is exceeded. This is good (thanks, > Cisco) because it limits damage to one subnet; but bad because it > exemplifies the severity of the issue: the "Cisco solution" is known > to be bad, but is less bad than letting the whole box break. Cisco is > not going to come up with a magic knob because there isn't any -- with > the current design, you have to pick your failure modes and live with > them. That's not good and it is not a Cisco failing by any means, it > is a design failing brought on by the standards bodies. > Saying this over and over doesn't make it so... 1. Block packets destined for your point-to-point links at your borders. There's no legitimate reason someone should be expecting your routers to respond to packets sent to the router specifically. 2. For networks that aren't intended to receive inbound requests from the outside, limit such requests to the live hosts that exist on those networks with a stateful firewall. 3. Police the ND issue rate on the router. Yes, it means that an ND attack could prevent some legitimate ND requests from getting through, but, at least it prevents ND overflow and the working hosts with existing ND entries continue to function. In most cases, this will be virtually all of the active hosts on the network. All of these things can be done today with the knobs that exist. The combination of them pretty much takes the wind out of any ND table overflow attack. Yes, it involves some tradeoffs and isn't a perfect solution. However, it is an effective mitigation. Owen From owen at delong.com Thu Jan 6 19:48:12 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 6 Jan 2011 17:48:12 -0800 Subject: Problems with removing NAT from a network In-Reply-To: <4D2634E7.2060502@matthew.at> References: <4D252B1F.8030506@kenweb.org> <3DFD6833-78C1-43D2-8074-6C89CFE3F2F3@arbor.net> <20110106043110.21C96876D21@drugs.dv.isc.org> <4D254ED8.6030006@matthew.at> <4D25F971.4090709@matthew.at> <4D2634E7.2060502@matthew.at> Message-ID: <9DEED87C-ED15-4D05-BCD6-69A5D4A69681@delong.com> Doesn't all of this become moot if Skype just develops a dual-stack capable client and servers? Owen On Jan 6, 2011, at 1:32 PM, Matthew Kaufman wrote: > On 1/6/2011 10:07 AM, Cameron Byrne wrote: >> >> Skype is not defined in an IETF RFC, so saying you need an RFC to move >> forward is bit confusing. > I don't see a disconnect at all. Skype also uses TCP and UDP, which are both subjects of RFCs. > > That said, it doesn't need to be an RFC... just *a reliable way* of discovering the appropriate NAT64 prefix. >> There are several methods that just work >> today, > Of the methods proposed in the survey draft, only one - the one that doesn't require the DNS64 spec or operator to make any changes (making an AAAA lookup for something you know only has an A record) - works but *only if* the mapping scheme is such that it is possible to successfully derive a functional prefix and the scheme from the results of that query. > > So in other words, *if* the query results in an AAAA where, by inspection, you can guess where you'd need to stuff the IPv4 address bits *and* the resulting address causes the "right" NAT64 (if there's >1) to be used, then you're set. >> I am all for standards, but a closed platforms generally find ways to >> progress without or in spite of standards. Skype is a closed >> platform. > No question. And for all you know we might be working on other ways around this problem, but none of them as elegant as a defined specification for how to discover the presence of a NAT64 and the mapping. >> >>> There's lots of other apps that don't work. Skype is just the squeaky wheel >>> because it is so popular. >>> >> Please make a list and let us know. Otherwise, this is just hand >> waving like the IPv4 literals sites. > I'll start with "peer to peer connectivity using RTMFP in Flash Player" and "BitTorrent". Both Flash Player and BitTorrent are fairly popular on desktop platforms. > > I'm sure there's more. > > >> My advice to Skype is to come up with a solution to work for IPv6-only >> clients. That is my advice to all apps and all content. IPv6-only >> clients are an obvious reality in an IPv4 exhausted world. > That's not the problem... the problem is reaching the existing base of IPv4 clients from those IPv6-only clients without making Skype relay all the traffic via servers somewhere, as I'm sure you know. > >> You cannot seriously come to a network operators support mailing list >> and say that the network guys have to keep investing in network tweaks >> while you wait for a standards body to solve a problem for your closed >> non-standard applications. > I've been on this list since approximately the time it was formed, so I'm not coming here to ask for something. Just pointing out what will break. > >> I also assure you, many mobile operators are pursuing this NAT64 path >> for the same reason I am. > Randy Bush would encourage his competitors to do just as you've done, I'm sure. > > Matthew Kaufman > From jsw at inconcepts.biz Thu Jan 6 20:01:12 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Thu, 6 Jan 2011 21:01:12 -0500 Subject: IPv6 - real vs theoretical problems In-Reply-To: References: Message-ID: On Thu, Jan 6, 2011 at 8:04 PM, Jimmy Hess wrote: > It is advisable to look for much stronger reasons than "With > IPv4 we did it" ?or ? With IPv4 we ran into such and such > problem" ? due to unique characteristics of IPv4 addressing > or other IPv4 conventions that had to continue to exist for > compatibility reasons, etc, etc. I certainly agree that there are many advantages to the greater address space offered by IPv6. I don't mean to advocate that we do things the same way as was necessary to conserve v4 address space, and I'm sure we all realize that RIR policies necessarily contributed to routing table growth in trade for extending the life of the available address space. I'm not blindly deploying /64 networks, either. Doing so with the current set of problems, and lack of knobs, is very foolish. My transit providers offer a mix of /126 and /124 demarc subnets so far, and /124 is what I choose to standardize on for my BGP customers and private peering, for simplicity and convenience. As I mentioned before, I currently allocate a /64 and configure a /124, so I am not painting myself into a corner either way. How many of us with an appreciable level of expertise remain concerned that our approach may need significant adjustment? How many think we know what those potential adjustments may be, and have planned to make them easy (or transparent) for ourselves and customers if they become necessary? This is what is IMO most important to a responsible IPv6 deployment. To do otherwise is inviting unpredictable future pain. I am comforted by the fact that Level3 is deploying customer demarc subnets as /126 and is NOT allocating a /64 for each, but are instead packing them densely in an IPv4 /30 fashion. They recognize problems with the /64 approach, choose not to follow the "standard" to the letter, and implement their dual-stack network in a way they presumably believe is safe and scalable. Large networks like Level3 choosing to insist that equipment vendors support this configuration, rather than have problems with densely packed subnets smaller than /64, will mean that anyone who wants to sell a router to Level3 had better make it work correctly this way, which is good for the small guy like me who thinks he will eventually transition to that configuration. Right now, I am still hedging my bet. Are there any large transit networks doing /64 on point-to-point networks to BGP customers? Who are they? What steps have they taken to eliminate problems, if any? -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From owen at delong.com Thu Jan 6 19:57:42 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 6 Jan 2011 17:57:42 -0800 Subject: IPv6 - real vs theoretical problems In-Reply-To: References: Message-ID: On Jan 6, 2011, at 2:00 PM, Deepak Jain wrote: > > Please, before you flame out, recognize I know a bit of what I am talking about. You can verify this by doing a search on NANOG archives. My point is to actually engage in an operational discussion on this and not insult (or be insulted). > > While I understand the theoretical advantages of /64s and /56s and /48s for all kinds of purposes, *TODAY* there are very few folks that are actually using any of them. No typical customer knows what do to do (for the most part) with their own /48, and other than autoconfiguration, there is no particular advantage to a /64 block for a single server -- yet. The left side of the prefix I think people and routers are reasonably comfortable with, it's the "host" side that presents the most challenge. > > My interest is principally in servers and high availability equipment (routers, etc) and other things that live in POPs and datacenters, so autoconfiguration doesn't even remotely appeal to me for anything. In a datacenter, many of these concerns about having routers fall over exist (high bandwidth links, high power equipment trying to do as many things as it can, etc). > > Wouldn't a number of problems go away if we just, for now, follow the IPv4 lessons/practices like allocating the number of addresses a customer needs --- say /122s or /120s that current router architectures know how to handle -- to these boxes/interfaces today, while just reserving /64 or /56 spaces for each of them for whenever the magic day comes along where they can be used safely? > No... A single perceived problem would go away and we would reacquire many many more problems that IPv6 is intended to leave behind. So far, IPv6 scans have been few and far between. The ones we have seen have been short lived and haven't even scanned a single network (Perhaps some time in the next 500+ years we will see one that does, but, I have my doubts). I think that targeted or hinted scanning will be the more likely approach in the IPv6 world. We haven't yet seen what will happen in that realm. As to what we lose if we eliminate large sparse end networks, we lose the following advantages: + Ability to just add machines to a network without having to worry about resizing the network or renumbering everything or worst of all adding yet another prefix to hold the new machines. + Sparse address density and privacy addressing capabilities + SLAAC + Simplified "network of things" capabilities There are probably other things as well, but, those 4 are what I can think of off the top of my head. Only the first one applies to server environments, but, it's a HUGE win for server environments, so, I think it's worth preserving for that reason alone. However, if you're willing to abandon that for your server farm, then, nobody is stopping you, actually. IPv6 fully supports statically configured networks of any size down to /127. Knock yourself out. > As far as I can tell, this "crippling" of the address space is completely reversible, it's a reasonable step forward and the only "operational" loss is you can't do all the address jumping and obfuscation people like to talk about... which I'm not sure is a loss. > I'm not sure what you mean by "crippling" of the address space. It seems to be working just fine in a number of production environments around the world, including both my work and home environments. > In your enterprise, behind your firewall, whatever, where you want autoconfig to work, and have some way of dealing with all of the dead space, more power to you. But operationally, is *anything* gained today by giving every host a /64 to screw around in that isn't accomplished by a /120 or so? > I don't imagine anyone will give every host a /64. What is currently proposed is giving every network a /64. Most networks contain at least two hosts to be minimally useful (router + end system), and the vast majority of those contain more than one end system (3+ hosts). Owen From bill at herrin.us Thu Jan 6 20:10:00 2011 From: bill at herrin.us (William Herrin) Date: Thu, 6 Jan 2011 21:10:00 -0500 Subject: IPv6 - real vs theoretical problems In-Reply-To: References: Message-ID: On Thu, Jan 6, 2011 at 5:00 PM, Deepak Jain wrote: > Wouldn't a number of problems go away if we just, for now, follow the > IPv4 lessons/practices like allocating the number of addresses a > customer needs --- say /122s or /120s that current router > architectures know how to handle -- to these boxes/interfaces > today, while just reserving /64 or /56 spaces for each of them > for whenever the magic day comes along where they can be > used safely? Hi Deepak, No. IPv6 is only *almost* the same as IPv4. Drill these three differences into your mind and you should do just fine: /64 LAN netmask nibble delegation boundary how many LANs (not hosts!) in this stub network? Without going into the technical details, IPv6 has been engineered with the intention that any netmask will work but a /64 netmask works distinctly better. Don't think of it as a 128 bit address. Think of it as a 64 bit network address plus a 64 bit host address. Apply IPv4 lessons to the 64 bit network address. The 64 bit host address is for the customer, the same way the 16-bit TCP port is for the customer. IPv6 has been rigged so that address space naturally delegates on nibble boundaries. It's one NS entry in the RDNS zone. It's an exact string of characters in the hexadecimal written form. Should you delegate on a different boundary, you invite all the common difficulties human beings have evaluating a netmask and add in the trouble dealing with base 16, rarely for any discernible gain. In IPv4 you think about how many addresses do I need to accommodate X hosts. This mental model does not match IPv6's technology model. If LANs are always /64, how many LANs does this stub network require? Example: Customer A has a gaming PC in a DMZ and two surfing PCs. How many IPv6 addresses? 1 LAN (/64) for the DMZ 1 LAN (/64) for the PCs 1 LAN (/64) between the firewall and the router round up to the nibble boundary: 16 LANs (/60) Consider providing a /56 or a /48 instead of a /60 so that there's lots of room for expansion, dynamic interior delegation or whatever. But /60 is your absolute floor. Less will turn out to be like telling the same customer to use 192.168.1.252/30: technical difficulties will promptly ensue. Regards, Bill Herrin -- 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 Jan 6 20:10:33 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 6 Jan 2011 18:10:33 -0800 Subject: NIST IPv6 document In-Reply-To: References: <201101060308.p0638wha085757@aurora.sol.net> <8469431D-AD95-4B75-9CDC-9C0176ED8CF9@arbor.net> <3B61690A-3D51-4847-87B5-84D7D1949BF3@delong.com> Message-ID: On Jan 6, 2011, at 3:32 PM, Dobbins, Roland wrote: > > On Jan 7, 2011, at 1:20 AM, Owen DeLong wrote: > >> You are mistaken... Host scanning followed by port sweeps is a very common threat and still widely practiced in IPv4. > > I know it's common and widely-practiced. My point is that if the host is security properly, this doesn't matter; and that if it isn't secured properly, it's going to be found via hinted scanning and exploited, anyways. > True, but, that doesn't really matter. Sparse addressing still provides other useful benefits. >> And there are ways to mitigate ND attacks as well. > > As has been pointed out elsewhere in this thread, not to the degree of control and certainty needed in production environments. > We can agree to disagree here until I see a production environment get taken down by a scan. So far, we've not had a problem with any of the IPv6 scans through our network. All have given up in <8 hours without having caused any sort of ND table overflow issues. >> Sparse addressing is a win for much more than just rendering scanning useless, but, making scanning useless is still a win. > > > Since it doesn't make scanning useless (again, hinted scanning), that 'win' is gone. How else is it supposedly a win? > Not having to worry about room to grow without renumbering is a good thing. I've posted other advantages in an earlier message. It does make sequential scanning useless and it does make even hinted scanning a bit more difficult or less effective. Think of the difference between playing battleship as it is traditionally played on a simple X, Y grid vs. playing it on a playing field where the ships have 180 different possible orientations (1 per degree instead of 0? and 90? only) Once you get a hit, you need a maximum of 4 additional attempts to identify the orientation of the ship and 50%+ of the time you can get it in ?2 additional attempts. With a 360? board, this becomes quite a bit more difficult. Sparse addressing does this even against hinted scanning. Owen From jsw at inconcepts.biz Thu Jan 6 20:13:52 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Thu, 6 Jan 2011 21:13:52 -0500 Subject: NIST IPv6 document In-Reply-To: References: <20110105043548.BC01B1CC3E@ptavv.es.net> <4661ED7E-A4DA-4CD4-A7EB-C5B2E615F126@delong.com> <86zkreb486.fsf@seastrom.com> Message-ID: On Thu, Jan 6, 2011 at 8:47 PM, Owen DeLong wrote: > 1. ? ? ?Block packets destined for your point-to-point links at your > ? ? ? ?borders. There's no legitimate reason someone should be Most networks do not do this today. Whether or not that is wise is questionable, but I don't think those networks want NDP to be the reason they choose to make this change. > 2. ? ? ?For networks that aren't intended to receive inbound requests > ? ? ? ?from the outside, limit such requests to the live hosts that > ? ? ? ?exist on those networks with a stateful firewall. Again, this doesn't fix the problem of misconfigured hosts on the LAN. I can and shall say it over and over, as long as folks continue to miss the potential for one compromised machine to disable the entire LAN, and in many cases, the entire router. It is bad that NDP table overflow can be triggered externally, but even if you solve that problem (which again does not require a stateful firewall, why do you keep saying this?) you still haven't made sure one host machine can't disable the LAN/router. > 3. ? ? ?Police the ND issue rate on the router. Yes, it means that > ? ? ? ?an ND attack could prevent some legitimate ND requests > ? ? ? ?from getting through, but, at least it prevents ND overflow and > ? ? ? ?the working hosts with existing ND entries continue to function. > ? ? ? ?In most cases, this will be virtually all of the active hosts on > ? ? ? ?the network. You must understand that policing will not stop the NDCache from becoming full almost instantly under an attack. Since the largest existing routers have about 100k entries at most, an attack can fill that up in *one second.* On some platforms, existing entries must be periodically refreshed by actual ARP/NDP exchange. If they are not refreshed, the entries go away, and traffic stops flowing. This is extremely bad because it can break even hosts with constant traffic flows, such as a server or infrastructure link to a neighboring router. Depending on the attack PPS and policer configuration, such hosts may remain broken for the duration of the attack. Implementations differ greatly in this regard. All of them break under an attack. Every single current implementation breaks in some fashion. It's just a question of how bad. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From jgreco at ns.sol.net Thu Jan 6 20:18:20 2011 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 6 Jan 2011 20:18:20 -0600 (CST) Subject: NIST IPv6 document In-Reply-To: Message-ID: <201101070218.p072IKeG003696@aurora.sol.net> > > On Jan 5, 2011, at 9:17 PM, Joe Greco wrote: > > >>> It has nothing to do with "security by obscurity". > >>=20 > >> You may wish to re-read what Joe was saying - he was positing sparse = > addres=3D > >> sing as a positive good because it will supposedly make it more = > difficult f=3D > >> or attackers to locate endpoints in the first place, i.e., security = > through=3D > >> obscurity. I think that's an invalid argument. > >=20 > > That's not necessarily security through obscurity. A client that just > > picks a random(*) address in the /64 and sits on it forever could be > > reasonably argued to be doing a form of security through obscurity. > > However, that's not the only potential use! A client that initiates > > each new outbound connection from a different IP address is doing > > something Really Good. > >=20 > If hosts start cycling their addresses that frequently, don't you run = > the risk of that becoming a form of DOS on your router's ND tables? It could, but given the changes we've seen in the last twenty years, I have no reason to expect that this won't become practical and commonplace in IPv6. I think it is a matter of finding the right enabling technologies, and as others have noted, what currently exists for IPv6 isn't necessarily the best-of-breed. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From jgreco at ns.sol.net Thu Jan 6 20:24:36 2011 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 6 Jan 2011 20:24:36 -0600 (CST) Subject: NIST IPv6 document In-Reply-To: Message-ID: <201101070224.p072OaMp003762@aurora.sol.net> > > On Thu, Jan 6, 2011 at 6:46 PM, Owen DeLong wrote: > > On Jan 5, 2011, at 9:17 PM, Joe Greco wrote: > >> However, that's not the only potential use! =A0A client that initiates > >> each new outbound connection from a different IP address is doing > >> something Really Good. > > If hosts start cycling their addresses that frequently, don't you run the > > risk of that becoming a form of DOS on your router's ND tables? > > Of course, Owen. I replied to that specific point in Joe's post > earlier, although I have written so much on this thread, I have tried > to condense my replies, so anyone reading in thread mode may have > missed it. > > The fact that Joe even makes that suggestion signals how little > understanding he has of the problem. His idea would DoS his own > router. With today's implementations of things? Perhaps. However, you show yourself equally incapable of grasping the real problem by looking at the broader picture, and recognizing that problematic issues such as finding hosts on a network are very solvable problems, and that we are at an early enough phase of IPv6 that we can even expect some experiments will be tried. Look beyond what _is_ today and see if you can figure out what it _could_ be. There's no need for what I suggest to DoS a router; that's just accepting a naive implementation and saying "well this can't be done because this one way of doing it breaks things." It is better to look for a way to fix the problem. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From smb at cs.columbia.edu Thu Jan 6 20:30:36 2011 From: smb at cs.columbia.edu (Steven Bellovin) Date: Thu, 6 Jan 2011 21:30:36 -0500 Subject: Problems with removing NAT from a network In-Reply-To: <9DEED87C-ED15-4D05-BCD6-69A5D4A69681@delong.com> References: <4D252B1F.8030506@kenweb.org> <3DFD6833-78C1-43D2-8074-6C89CFE3F2F3@arbor.net> <20110106043110.21C96876D21@drugs.dv.isc.org> <4D254ED8.6030006@matthew.at> <4D25F971.4090709@matthew.at> <4D2634E7.2060502@matthew.at> <9DEED87C-ED15-4D05-BCD6-69A5D4A69681@delong.com> Message-ID: <6FEC1711-9E80-4433-90C5-6491E7AC14F8@cs.columbia.edu> On Jan 6, 2011, at 8:48 12PM, Owen DeLong wrote: > Doesn't all of this become moot if Skype just develops a dual-stack capable client > and servers? Skype is an interesting case because of its peer-to-peer nature. Given the state of v6 deployment and operational experience[1], and especially given the fragility of tunneled IPv6 connections[2], there is potential for a lot of broken links. --Steve Bellovin, http://www.cs.columbia.edu/~smb [1] All concerned are mystified about why my office machines can't reach [major site] via v6, even though traceroute6 from both ends shows the packets reaching the same network. A couple of weeks earlier, I couldn't get anywhere via IPv6 because someone had connected a NAT+v6 tunneler in bridge mode, and my machine believe its RA messages. [2] See http://www.google.com/intl/en/ipv6/faq.html#tunnel From joelja at bogus.com Thu Jan 6 20:34:06 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Thu, 06 Jan 2011 18:34:06 -0800 Subject: Problems with removing NAT from a network In-Reply-To: <9DEED87C-ED15-4D05-BCD6-69A5D4A69681@delong.com> References: <4D252B1F.8030506@kenweb.org> <3DFD6833-78C1-43D2-8074-6C89CFE3F2F3@arbor.net> <20110106043110.21C96876D21@drugs.dv.isc.org> <4D254ED8.6030006@matthew.at> <4D25F971.4090709@matthew.at> <4D2634E7.2060502@matthew.at> <9DEED87C-ED15-4D05-BCD6-69A5D4A69681@delong.com> Message-ID: <4D267B9E.8040602@bogus.com> On 1/6/11 5:48 PM, Owen DeLong wrote: > Doesn't all of this become moot if Skype just develops a dual-stack capable client > and servers? Really, only some fraction of the supernodes and the login servers need to be dual stack. > Owen > > On Jan 6, 2011, at 1:32 PM, Matthew Kaufman wrote: > >> On 1/6/2011 10:07 AM, Cameron Byrne wrote: >>> >>> Skype is not defined in an IETF RFC, so saying you need an RFC to move >>> forward is bit confusing. >> I don't see a disconnect at all. Skype also uses TCP and UDP, which are both subjects of RFCs. >> >> That said, it doesn't need to be an RFC... just *a reliable way* of discovering the appropriate NAT64 prefix. >>> There are several methods that just work >>> today, >> Of the methods proposed in the survey draft, only one - the one that doesn't require the DNS64 spec or operator to make any changes (making an AAAA lookup for something you know only has an A record) - works but *only if* the mapping scheme is such that it is possible to successfully derive a functional prefix and the scheme from the results of that query. >> >> So in other words, *if* the query results in an AAAA where, by inspection, you can guess where you'd need to stuff the IPv4 address bits *and* the resulting address causes the "right" NAT64 (if there's >1) to be used, then you're set. >>> I am all for standards, but a closed platforms generally find ways to >>> progress without or in spite of standards. Skype is a closed >>> platform. >> No question. And for all you know we might be working on other ways around this problem, but none of them as elegant as a defined specification for how to discover the presence of a NAT64 and the mapping. >>> >>>> There's lots of other apps that don't work. Skype is just the squeaky wheel >>>> because it is so popular. >>>> >>> Please make a list and let us know. Otherwise, this is just hand >>> waving like the IPv4 literals sites. >> I'll start with "peer to peer connectivity using RTMFP in Flash Player" and "BitTorrent". Both Flash Player and BitTorrent are fairly popular on desktop platforms. >> >> I'm sure there's more. >> >> >>> My advice to Skype is to come up with a solution to work for IPv6-only >>> clients. That is my advice to all apps and all content. IPv6-only >>> clients are an obvious reality in an IPv4 exhausted world. >> That's not the problem... the problem is reaching the existing base of IPv4 clients from those IPv6-only clients without making Skype relay all the traffic via servers somewhere, as I'm sure you know. >> >>> You cannot seriously come to a network operators support mailing list >>> and say that the network guys have to keep investing in network tweaks >>> while you wait for a standards body to solve a problem for your closed >>> non-standard applications. >> I've been on this list since approximately the time it was formed, so I'm not coming here to ask for something. Just pointing out what will break. >> >>> I also assure you, many mobile operators are pursuing this NAT64 path >>> for the same reason I am. >> Randy Bush would encourage his competitors to do just as you've done, I'm sure. >> >> Matthew Kaufman >> > > > From matthew at matthew.at Thu Jan 6 20:55:19 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 06 Jan 2011 18:55:19 -0800 Subject: Problems with removing NAT from a network In-Reply-To: <9DEED87C-ED15-4D05-BCD6-69A5D4A69681@delong.com> References: <4D252B1F.8030506@kenweb.org> <3DFD6833-78C1-43D2-8074-6C89CFE3F2F3@arbor.net> <20110106043110.21C96876D21@drugs.dv.isc.org> <4D254ED8.6030006@matthew.at> <4D25F971.4090709@matthew.at> <4D2634E7.2060502@matthew.at> <9DEED87C-ED15-4D05-BCD6-69A5D4A69681@delong.com> Message-ID: <4D268097.6050502@matthew.at> On 1/6/2011 5:48 PM, Owen DeLong wrote: > Doesn't all of this become moot if Skype just develops a dual-stack capable client > and servers? > Not really. Imagine the case where you're on IPv6 and you can only reach IPv4 via a NAT64, and there's no progress made on the detection problem. And your family member is on a Skype-enabled TV plugged into an IPv4-only ISP. Now you can't get a direct media path between you, even though their ISP is giving them IPv4 and your ISP is *claiming* you can "still reach the IPv4 Internet". Skype can still make this work by relaying, but in order to protect the relay machine's bandwidth it will rate-limit the traffic, and so your A/V experience will suffer. And that's assuming there's enough dual-stacked relays... if there aren't, it won't be possible to find a relay that they can reach over IPv4 and you can reach over IPv6 that has available bandwidth. Matthew Kaufman From matthew at matthew.at Thu Jan 6 20:57:29 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 06 Jan 2011 18:57:29 -0800 Subject: Problems with removing NAT from a network In-Reply-To: <4D267B9E.8040602@bogus.com> References: <4D252B1F.8030506@kenweb.org> <3DFD6833-78C1-43D2-8074-6C89CFE3F2F3@arbor.net> <20110106043110.21C96876D21@drugs.dv.isc.org> <4D254ED8.6030006@matthew.at> <4D25F971.4090709@matthew.at> <4D2634E7.2060502@matthew.at> <9DEED87C-ED15-4D05-BCD6-69A5D4A69681@delong.com> <4D267B9E.8040602@bogus.com> Message-ID: <4D268119.2050205@matthew.at> On 1/6/2011 6:34 PM, Joel Jaeggli wrote: > On 1/6/11 5:48 PM, Owen DeLong wrote: >> Doesn't all of this become moot if Skype just develops a dual-stack capable client >> and servers? > Really, only some fraction of the supernodes and the login servers need > to be dual stack. > Without revealing too much about the architecture, I can tell you that it would need to be a significant fraction of the supernodes (due to how node-supernode mapping works in these types of P2P systems), the relay nodes (not mentioned) *and* the login servers. Not all of which are deployed and controlled by Skype, of course, as recent press about the most recent outage has reiterated for those who didn't know. Matthew Kaufman From jsw at inconcepts.biz Thu Jan 6 21:05:26 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Thu, 6 Jan 2011 22:05:26 -0500 Subject: NIST IPv6 document In-Reply-To: <2CA773A3-A7C1-4416-92B0-A367F6BBC300@delong.com> References: <20110105043548.BC01B1CC3E@ptavv.es.net> <4661ED7E-A4DA-4CD4-A7EB-C5B2E615F126@delong.com> <86zkreb486.fsf@seastrom.com> <2CA773A3-A7C1-4416-92B0-A367F6BBC300@delong.com> Message-ID: On Thu, Jan 6, 2011 at 9:31 PM, Owen DeLong wrote: >> You must understand that policing will not stop the NDCache from >> becoming full almost instantly under an attack. ?Since the largest >> existing routers have about 100k entries at most, an attack can fill >> that up in *one second.* >> > If the policing rate is set to ~100 requests per second, or, even > 1000 requests per second, then, I'm not sure why you think this. With a 100pps policer, it is trivial for an attack to make its NS requests far more likely to make it through the policer than legitimate NS requests that would result in discovering a valid layer-2 mapping. If you are hitting the policer, the subnet is broken. If you don't have a policer, the table is full and ... the subnet is broken. See how it's a problem that isn't solvable with a simple policer? Note that the Cisco "solution" is indeed a configurable per-interface policer, which is better than nothing, but does not fully solve the problem. Policing isn't a new idea. I'm not sure it's a step in the right direction, or just prolonging an inevitable change towards a real fix. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From jsw at inconcepts.biz Thu Jan 6 21:13:01 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Thu, 6 Jan 2011 22:13:01 -0500 Subject: NIST IPv6 document In-Reply-To: <201101070224.p072OaMp003762@aurora.sol.net> References: <201101070224.p072OaMp003762@aurora.sol.net> Message-ID: On Thu, Jan 6, 2011 at 9:24 PM, Joe Greco wrote: > With today's implementations of things? ?Perhaps. ?However, you > show yourself equally incapable of grasping the real problem by > looking at the broader picture, and recognizing that problematic > issues such as finding hosts on a network are very solvable > problems, and that we are at an early enough phase of IPv6 that > we can even expect some experiments will be tried. > > Look beyond what _is_ today and see if you can figure out what > it _could_ be. ?There's no need for what I suggest to DoS a router; > that's just accepting a naive implementation and saying "well this > can't be done because this one way of doing it breaks things." ?It > is better to look for a way to fix the problem. Actually, unlike most posters on this subject, I have a very good understanding of how everything works "under the hood." For this reason, I also understand what is possible given the size of a /64 subnet and the knowledge that we will never have adjacency tables approaching this size. If you are someone who thinks, oh, those Cisco and Juniper developers will figure this out, they just haven't thought about it hard enough yet, I can understand why you believe that a simple fix like "no ip directed-broadcast" is on the horizon. Unfortunately, it is not. The only thing they can do is give more mitigation knobs to allow operators to choose our failure modes and thresholds. To really fix it, you need a smaller subnet or a radical protocol change that will introduce a different set of problems. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From nanog at jima.tk Thu Jan 6 22:58:31 2011 From: nanog at jima.tk (Jima) Date: Thu, 06 Jan 2011 22:58:31 -0600 Subject: IPv6 - real vs theoretical problems In-Reply-To: References: Message-ID: <4D269D77.4080309@jima.tk> On 1/6/2011 4:47 PM, Grant Phillips wrote: > I acknowledge and see the point made. There is a lot of dead space in the > IPv6 world. Are we allowing history to repeat it self? Well i'm swaying more > to no. > > Have you read this RFC? This is pretty satisfying in making me feel more > comfortable assigning out /48 and /64's. I can sleep at night now! :P > > http://tools.ietf.org/html//rfc3177 I can't tell if you're trolling, or if you didn't get the memo from Monday. I guess I'll lean toward the latter. http://www.ietf.org/mail-archive/web/v6ops/current/msg06820.html Jima From dwing at cisco.com Thu Jan 6 23:28:34 2011 From: dwing at cisco.com (Dan Wing) Date: Thu, 6 Jan 2011 21:28:34 -0800 Subject: Problems with removing NAT from a network In-Reply-To: <4D268097.6050502@matthew.at> References: <4D252B1F.8030506@kenweb.org> <3DFD6833-78C1-43D2-8074-6C89CFE3F2F3@arbor.net> <20110106043110.21C96876D21@drugs.dv.isc.org> <4D254ED8.6030006@matthew.at> <4D25F971.4090709@matthew.at> <4D2634E7.2060502@matthew.at> <9DEED87C-ED15-4D05-BCD6-69A5D4A69681@delong.com> <4D268097.6050502@matthew.at> Message-ID: <0fa801cbae2b$bad57850$308068f0$@com> > -----Original Message----- > From: Matthew Kaufman [mailto:matthew at matthew.at] > Sent: Thursday, January 06, 2011 6:55 PM > To: Owen DeLong > Cc: Nanog Operators' Group > Subject: Re: Problems with removing NAT from a network > > On 1/6/2011 5:48 PM, Owen DeLong wrote: > > Doesn't all of this become moot if Skype just develops a dual-stack > capable client > > and servers? > > > Not really. Imagine the case where you're on IPv6 and you can only > reach > IPv4 via a NAT64, and there's no progress made on the detection > problem. > And your family member is on a Skype-enabled TV plugged into an > IPv4-only ISP. > > Now you can't get a direct media path between you, even though their > ISP > is giving them IPv4 and your ISP is *claiming* you can "still reach the > IPv4 Internet". > > Skype can still make this work by relaying, Skype could make it work with direct UDP packets in about 92% of cases, per Google's published direct-to-direct statistic at http://code.google.com/apis/talk/libjingle/important_concepts.html -d > but in order to protect the > relay machine's bandwidth it will rate-limit the traffic, and so your > A/V experience will suffer. And that's assuming there's enough > dual-stacked relays... if there aren't, it won't be possible to find a > relay that they can reach over IPv4 and you can reach over IPv6 that > has > available bandwidth. > > Matthew Kaufman From nanog at jima.tk Thu Jan 6 23:48:11 2011 From: nanog at jima.tk (Jima) Date: Thu, 06 Jan 2011 23:48:11 -0600 Subject: NIST IPv6 document In-Reply-To: <201101061116.03354.lowen@pari.edu> References: <201101060308.p0638wha085757@aurora.sol.net> <201101061116.03354.lowen@pari.edu> Message-ID: <4D26A91B.3080004@jima.tk> Hey Lamar, long time no talk. On 1/6/2011 10:16 AM, Lamar Owen wrote: > Standards are written by people, of course, and most paragraphs have reasons to be there; I would find it interesting to hear the rationale for a router filling a slot in its neighbor table for a host that doesn't exist. For that matter, I'd like to see a pointer to which standard that says this so I can read the verbiage myself, as that may have enough explanation to satisfy my curiosity. This actually came up last week in freenode/#ipv6; someone was puzzled why there were FAIL entries showing up in their neighbor table, so I dug into the RFC I found for ND (2461). Turns out, it specifically says entries for failed solicitations SHOULD be deleted. http://tools.ietf.org/html/rfc2461#section-7.3.3 It's the seventh paragraph into that section, including the indented Note. ("Upon entering the PROBE state...") Pardon me if that's the wrong RFC. Jima From owen at delong.com Thu Jan 6 23:57:38 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 6 Jan 2011 21:57:38 -0800 Subject: NIST IPv6 document In-Reply-To: References: <201101070224.p072OaMp003762@aurora.sol.net> Message-ID: On Jan 6, 2011, at 7:13 PM, Jeff Wheeler wrote: > On Thu, Jan 6, 2011 at 9:24 PM, Joe Greco wrote: >> With today's implementations of things? Perhaps. However, you >> show yourself equally incapable of grasping the real problem by >> looking at the broader picture, and recognizing that problematic >> issues such as finding hosts on a network are very solvable >> problems, and that we are at an early enough phase of IPv6 that >> we can even expect some experiments will be tried. >> >> Look beyond what _is_ today and see if you can figure out what >> it _could_ be. There's no need for what I suggest to DoS a router; >> that's just accepting a naive implementation and saying "well this >> can't be done because this one way of doing it breaks things." It >> is better to look for a way to fix the problem. > > Actually, unlike most posters on this subject, I have a very good > understanding of how everything works "under the hood." For this > reason, I also understand what is possible given the size of a /64 > subnet and the knowledge that we will never have adjacency tables > approaching this size. > > If you are someone who thinks, oh, those Cisco and Juniper developers > will figure this out, they just haven't thought about it hard enough > yet, I can understand why you believe that a simple fix like "no ip > directed-broadcast" is on the horizon. Unfortunately, it is not. The > only thing they can do is give more mitigation knobs to allow > operators to choose our failure modes and thresholds. To really fix > it, you need a smaller subnet or a radical protocol change that will > introduce a different set of problems. > I think I have a pretty good understanding of what happens under the hood, too. The reality is that what you say is theoretically possible, but, not terribly practical from an attacker perspective. It's pretty trivial to block these attacks out from threats outside your network or at least severely limit the number of attackable addresses within the individual network. Smaller network segments are not necessary to reduce the attackable profile of the network segment. Yes, a determined host within your network segment can DOS the network segment this way. Guess what... If you've got a determined attacker on your network segment, you've already lost on multiple other levels, so, this might even be a feature. As such, while the issue you bring up can be a problem for a poorly administered network, I think you overstate it's viability as an attack vector in most real world instances. Owen From owen at delong.com Fri Jan 7 00:11:29 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 6 Jan 2011 22:11:29 -0800 Subject: IPv6 - real vs theoretical problems In-Reply-To: <4D269D77.4080309@jima.tk> References: <4D269D77.4080309@jima.tk> Message-ID: <10FB3518-6470-4F14-963C-B3150FABE667@delong.com> On Jan 6, 2011, at 8:58 PM, Jima wrote: > On 1/6/2011 4:47 PM, Grant Phillips wrote: >> I acknowledge and see the point made. There is a lot of dead space in the >> IPv6 world. Are we allowing history to repeat it self? Well i'm swaying more >> to no. >> >> Have you read this RFC? This is pretty satisfying in making me feel more >> comfortable assigning out /48 and /64's. I can sleep at night now! :P >> >> http://tools.ietf.org/html//rfc3177 > > I can't tell if you're trolling, or if you didn't get the memo from Monday. I guess I'll lean toward the latter. > > http://www.ietf.org/mail-archive/web/v6ops/current/msg06820.html > > Jima That's a draft, and, it doesn't really eliminate the idea that /48s are generally a good thing so much as it recognizes that there might be SOME circumstances in which they are either not necessary or insufficient. As a draft, it hasn't been through the full process and shouldn't be considered to have the same weight as an RFC. While it intends to obsolete RFC-3177, it doesn't obsolete it yet and, indeed, may never do so. Owen From matthew at matthew.at Fri Jan 7 00:39:18 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 06 Jan 2011 22:39:18 -0800 Subject: Problems with removing NAT from a network In-Reply-To: <0fa801cbae2b$bad57850$308068f0$@com> References: <4D252B1F.8030506@kenweb.org> <3DFD6833-78C1-43D2-8074-6C89CFE3F2F3@arbor.net> <20110106043110.21C96876D21@drugs.dv.isc.org> <4D254ED8.6030006@matthew.at> <4D25F971.4090709@matthew.at> <4D2634E7.2060502@matthew.at> <9DEED87C-ED15-4D05-BCD6-69A5D4A69681@delong.com> <4D268097.6050502@matthew.at> <0fa801cbae2b$bad57850$308068f0$@com> Message-ID: <4D26B516.80001@matthew.at> On 1/6/2011 9:28 PM, Dan Wing wrote: >> -----Original Message----- >> From: Matthew Kaufman [mailto:matthew at matthew.at] >> Not really. Imagine the case where you're on IPv6 and you can only >> reach >> IPv4 via a NAT64, and there's no progress made on the detection >> problem. >> And your family member is on a Skype-enabled TV plugged into an >> IPv4-only ISP. >> >> Now you can't get a direct media path between you, even though their >> ISP >> is giving them IPv4 and your ISP is *claiming* you can "still reach the >> IPv4 Internet". >> >> Skype can still make this work by relaying, > Skype could make it work with direct UDP packets in about 92% of > cases, per Google's published direct-to-direct statistic at > http://code.google.com/apis/talk/libjingle/important_concepts.html > If one end is behind a NAT64 and there is no mechanism for discovering the NAT64's IPv6 interface prefix and mapping algorithm (and at present there is not), there is no way to send IPv6 IP packets from the IPv6-only host to IPv4 literal addresses (that is to say, addresses learned via a mechanism other than DNS responses synthesized by the DNS64 part of the NAT64 "solution") on the IPv4 Internet through said NAT64. That's the case we're discussing here. It breaks Skype, Adobe's RTMFP, BitTorrent, ICE-based NAT traversal, etc. Even the protocol described in the referenced document, Jingle (as it essentially uses ICE) fails. The candidate IPv4 addresses for the end that's on the IPv4 Internet (local and STUN-derived) that are delivered over Jingle's XMPP path cannot be used by the host that is on IPv6 + NAT64 to reach the IPv4 Internet because it has no IPv4 sockets available to it and even if it knew that NAT64 existed (which would take a modification to the Jingle-based apps) and opened an IPv6 socket it wouldn't know what IPv6 address to use to reach the IPv4 host because there's no discovery mechanism. If you want we can take this back to the BEHAVE list now. Matthew Kaufman From nanog at jima.tk Fri Jan 7 00:50:49 2011 From: nanog at jima.tk (Jima) Date: Fri, 07 Jan 2011 00:50:49 -0600 Subject: IPv6 - real vs theoretical problems In-Reply-To: <10FB3518-6470-4F14-963C-B3150FABE667@delong.com> References: <4D269D77.4080309@jima.tk> <10FB3518-6470-4F14-963C-B3150FABE667@delong.com> Message-ID: <4D26B7C9.3090205@jima.tk> On 1/7/2011 12:11 AM, Owen DeLong wrote: > That's a draft, and, it doesn't really eliminate the idea that /48s are generally > a good thing so much as it recognizes that there might be SOME circumstances > in which they are either not necessary or insufficient. > > As a draft, it hasn't been through the full process and shouldn't be considered > to have the same weight as an RFC. > > While it intends to obsolete RFC-3177, it doesn't obsolete it yet and, indeed, may > never do so. Fully understood; I wasn't meaning to present it as irrefutable evidence that the /64 & /48 mindset is flawed, but as a timely counterpoint to people expounding the virtues of 3177 without cautiously acknowledging that its recommendations aren't necessarily for everyone. I apologize if my intentions weren't terribly clear -- that may be a good cue for me to go to bed. Jima From swmike at swm.pp.se Fri Jan 7 01:19:36 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 7 Jan 2011 08:19:36 +0100 (CET) Subject: Problems with removing NAT from a network In-Reply-To: <4D26B516.80001@matthew.at> References: <4D252B1F.8030506@kenweb.org> <3DFD6833-78C1-43D2-8074-6C89CFE3F2F3@arbor.net> <20110106043110.21C96876D21@drugs.dv.isc.org> <4D254ED8.6030006@matthew.at> <4D25F971.4090709@matthew.at> <4D2634E7.2060502@matthew.at> <9DEED87C-ED15-4D05-BCD6-69A5D4A69681@delong.com> <4D268097.6050502@matthew.at> <0fa801cbae2b$bad57850$308068f0$@com> <4D26B516.80001@matthew.at> Message-ID: On Thu, 6 Jan 2011, Matthew Kaufman wrote: > If one end is behind a NAT64 and there is no mechanism for discovering > the NAT64's IPv6 interface prefix and mapping algorithm (and at present > there is not), there is no way to send IPv6 IP packets from the > IPv6-only host to IPv4 literal addresses (that is to say, addresses > learned via a mechanism other than DNS responses synthesized by the > DNS64 part of the NAT64 "solution") on the IPv4 Internet through said > NAT64. There has been discussions on v6ops mailinglist about BIH (Bump In Host) for mobile applications, so that one could create a client on the machine behind NAT64 and make it work work with programs that use v4 literals (or have no v6 support at all). It though seems there is considerable resistance within the IETF community against such solutions as (I've been told) history has shown there to be a lot of problems with this kind of double translation. Therefore the IETF seems to lean towards tunneling of IPv4 over IPv6 to give such a host literal IPv4 connextivity (could be called 4RD) instead of doing translation. For mobile applications, single stack on the access is to only realistic method in the next few years, therefore this needs to be solved somehow. 3GPP doesn't like tunnels though (since they already do tunneling), so right now there isn't really broad agreement on how to solve this. Personally I think we need some kind of transitioning mechanism to handle v4 only applications and v4 literals in the forseeable future, just like we needed trumped winsock in the 90ties, we're going to need full v4 connectivity for Windows XP (applications + dns transport) over v6only access. -- Mikael Abrahamsson email: swmike at swm.pp.se From bensons at queuefull.net Fri Jan 7 01:49:50 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Fri, 7 Jan 2011 01:49:50 -0600 Subject: Problems with removing NAT from a network In-Reply-To: <4D26B516.80001@matthew.at> References: <4D252B1F.8030506@kenweb.org> <3DFD6833-78C1-43D2-8074-6C89CFE3F2F3@arbor.net> <20110106043110.21C96876D21@drugs.dv.isc.org> <4D254ED8.6030006@matthew.at> <4D25F971.4090709@matthew.at> <4D2634E7.2060502@matthew.at> <9DEED87C-ED15-4D05-BCD6-69A5D4A69681@delong.com> <4D268097.6050502@matthew.at> <0fa801cbae2b$bad57850$308068f0$@com> <4D26B516.80001@matthew.at> Message-ID: <4ECA283F-856C-4813-A4E8-073C136613C5@queuefull.net> On Jan 7, 2011, at 12:39 AM, Matthew Kaufman wrote: > On 1/6/2011 9:28 PM, Dan Wing wrote: >> >> Skype could make it work with direct UDP packets in about 92% of >> cases, per Google's published direct-to-direct statistic at >> http://code.google.com/apis/talk/libjingle/important_concepts.html >> > If one end is behind a NAT64 and there is no mechanism for discovering the NAT64's IPv6 interface prefix and mapping algorithm (and at present there is not), there is no way to send IPv6 IP packets from the IPv6-only host to IPv4 literal addresses (that is to say, addresses learned via a mechanism other than DNS responses synthesized by the DNS64 part of the NAT64 "solution") on the IPv4 Internet through said NAT64. > > That's the case we're discussing here. > > It breaks Skype, Adobe's RTMFP, BitTorrent, ICE-based NAT traversal, etc. Even the protocol described in the referenced document, Jingle (as it essentially uses ICE) fails. The candidate IPv4 addresses for the end that's on the IPv4 Internet (local and STUN-derived) that are delivered over Jingle's XMPP path cannot be used by the host that is on IPv6 + NAT64 to reach the IPv4 Internet because it has no IPv4 sockets available to it and even if it knew that NAT64 existed (which would take a modification to the Jingle-based apps) and opened an IPv6 socket it wouldn't know what IPv6 address to use to reach the IPv4 host because there's no discovery mechanism. If you want we can take this back to the BEHAVE list now. To paraphrase what you're saying: stuff that embeds and passes around IPv4 addresses will break. I'm sorry to say this, but that's just reality. Embedded IP addresses has always been a Bad Idea (tm) in development and operations, and I don't think P2P protocols get a pass - building your own discovery and topology mechanisms don't insulate you from having to use the underlying network. The best chance anybody has, is to build dual-stack support and start using DNS names rather than IP numbers. Oh, and expect IPv4 to start breaking in the near future. We're trying to make IPv4 work long enough to survive the transition, but it's not a good bet for new protocols. Cheers, -Benson From owen at delong.com Fri Jan 7 03:00:29 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 7 Jan 2011 01:00:29 -0800 Subject: IPv6 - real vs theoretical problems In-Reply-To: <4D26B7C9.3090205@jima.tk> References: <4D269D77.4080309@jima.tk> <10FB3518-6470-4F14-963C-B3150FABE667@delong.com> <4D26B7C9.3090205@jima.tk> Message-ID: <2C0E263F-90D4-4088-84FD-122AAA4BE984@delong.com> On Jan 6, 2011, at 10:50 PM, Jima wrote: > On 1/7/2011 12:11 AM, Owen DeLong wrote: >> That's a draft, and, it doesn't really eliminate the idea that /48s are generally >> a good thing so much as it recognizes that there might be SOME circumstances >> in which they are either not necessary or insufficient. >> >> As a draft, it hasn't been through the full process and shouldn't be considered >> to have the same weight as an RFC. >> >> While it intends to obsolete RFC-3177, it doesn't obsolete it yet and, indeed, may >> never do so. > > Fully understood; I wasn't meaning to present it as irrefutable evidence that the /64 & /48 mindset is flawed, but as a timely counterpoint to people expounding the virtues of 3177 without cautiously acknowledging that its recommendations aren't necessarily for everyone. I apologize if my intentions weren't terribly clear -- that may be a good cue for me to go to bed. > > Jima I believe that the draft, even if it were to be adopted as is, does not intend to obsolete the /64, just the /48 recommendation in 3177. Owen From owen at delong.com Fri Jan 7 03:02:50 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 7 Jan 2011 01:02:50 -0800 Subject: Problems with removing NAT from a network In-Reply-To: <4ECA283F-856C-4813-A4E8-073C136613C5@queuefull.net> References: <4D252B1F.8030506@kenweb.org> <3DFD6833-78C1-43D2-8074-6C89CFE3F2F3@arbor.net> <20110106043110.21C96876D21@drugs.dv.isc.org> <4D254ED8.6030006@matthew.at> <4D25F971.4090709@matthew.at> <4D2634E7.2060502@matthew.at> <9DEED87C-ED15-4D05-BCD6-69A5D4A69681@delong.com> <4D268097.6050502@matthew.at> <0fa801cbae2b$bad57850$308068f0$@com> <4D26B516.80001@matthew.at> <4ECA283F-856C-4813-A4E8-073C136613C5@queuefull.net> Message-ID: <51390CEC-BF37-4211-A472-FC9989654BDA@delong.com> On Jan 6, 2011, at 11:49 PM, Benson Schliesser wrote: > > On Jan 7, 2011, at 12:39 AM, Matthew Kaufman wrote: > >> On 1/6/2011 9:28 PM, Dan Wing wrote: >>> >>> Skype could make it work with direct UDP packets in about 92% of >>> cases, per Google's published direct-to-direct statistic at >>> http://code.google.com/apis/talk/libjingle/important_concepts.html >>> >> If one end is behind a NAT64 and there is no mechanism for discovering the NAT64's IPv6 interface prefix and mapping algorithm (and at present there is not), there is no way to send IPv6 IP packets from the IPv6-only host to IPv4 literal addresses (that is to say, addresses learned via a mechanism other than DNS responses synthesized by the DNS64 part of the NAT64 "solution") on the IPv4 Internet through said NAT64. >> >> That's the case we're discussing here. >> >> It breaks Skype, Adobe's RTMFP, BitTorrent, ICE-based NAT traversal, etc. Even the protocol described in the referenced document, Jingle (as it essentially uses ICE) fails. The candidate IPv4 addresses for the end that's on the IPv4 Internet (local and STUN-derived) that are delivered over Jingle's XMPP path cannot be used by the host that is on IPv6 + NAT64 to reach the IPv4 Internet because it has no IPv4 sockets available to it and even if it knew that NAT64 existed (which would take a modification to the Jingle-based apps) and opened an IPv6 socket it wouldn't know what IPv6 address to use to reach the IPv4 host because there's no discovery mechanism. If you want we can take this back to the BEHAVE list now. > > To paraphrase what you're saying: stuff that embeds and passes around IPv4 addresses will break. I'm sorry to say this, but that's just reality. Embedded IP addresses has always been a Bad Idea (tm) in development and operations, and I don't think P2P protocols get a pass - building your own discovery and topology mechanisms don't insulate you from having to use the underlying network. > No, it hasn't always been a Bad Idea. It has been an idea fraught with peril since the deployment of overloaded NAT in IPv4. Fortunately, overloaded NAT will hopefully be a thing of the past in IPv6 and we may get a chance to return to a more functional end-to-end model of networking again. > The best chance anybody has, is to build dual-stack support and start using DNS names rather than IP numbers. Oh, and expect IPv4 to start breaking in the near future. We're trying to make IPv4 work long enough to survive the transition, but it's not a good bet for new protocols. > On this, at least we agree. Owen From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Fri Jan 7 03:14:52 2011 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Fri, 7 Jan 2011 19:44:52 +1030 Subject: NIST IPv6 document In-Reply-To: References: <20110105043548.BC01B1CC3E@ptavv.es.net> <4661ED7E-A4DA-4CD4-A7EB-C5B2E615F126@delong.com> <86zkreb486.fsf@seastrom.com> Message-ID: <20110107194452.110fa401@opy.nosense.org> On Thu, 6 Jan 2011 21:13:52 -0500 Jeff Wheeler wrote: > On Thu, Jan 6, 2011 at 8:47 PM, Owen DeLong wrote: > > 1. ? ? ?Block packets destined for your point-to-point links at your > > ? ? ? ?borders. There's no legitimate reason someone should be > > Most networks do not do this today. Whether or not that is wise is > questionable, but I don't think those networks want NDP to be the > reason they choose to make this change. > > > 2. ? ? ?For networks that aren't intended to receive inbound requests > > ? ? ? ?from the outside, limit such requests to the live hosts that > > ? ? ? ?exist on those networks with a stateful firewall. > > Again, this doesn't fix the problem of misconfigured hosts on the LAN. > I can and shall say it over and over, as long as folks continue to > miss the potential for one compromised machine to disable the entire > LAN, and in many cases, the entire router. It is bad that NDP table > overflow can be triggered externally, but even if you solve that > problem (which again does not require a stateful firewall, why do you > keep saying this?) you still haven't made sure one host machine can't > disable the LAN/router. > Doesn't this risk already exist in IPv4? Any device attached to a LAN can send any traffic it likes to any other device attached to a LAN, whether that be spoofed ARP updates, intentionally created duplicate IP addresses, or simple flat out traffic based denial of service attacks using valid IPv4 addresses. Just relying on ARP means you're trusting other LAN attached devices not be lying. If you really think a LAN attached device being malicious to another LAN attached device is an unacceptable risk, then you're going to need to abandon your peer-to-peer traffic forwarding topology provided by a multi-access LAN, and adopt a hub-and-spoke one, with the hub (router/firewall) acting as an inspection and quarantining device for all traffic originated by spokes. PPPoE or per-device VLANs would be the way to do that, while still gaining the price benefits of commodity Ethernet. I definitely think there is an issue with IPv6 ND cache state being exploitable from off-link sources e.g. the Internet. I think, however, targetting on-link devices on a LAN is far less of an issue - you've already accepted the risk that LAN other devices can send malicious traffic, and those LAN devices also have a vested interest in their default router being available, so they have far less of an incentive to maliciously disable it. > > 3. ? ? ?Police the ND issue rate on the router. Yes, it means that > > ? ? ? ?an ND attack could prevent some legitimate ND requests > > ? ? ? ?from getting through, but, at least it prevents ND overflow and > > ? ? ? ?the working hosts with existing ND entries continue to function. > > ? ? ? ?In most cases, this will be virtually all of the active hosts on > > ? ? ? ?the network. > > You must understand that policing will not stop the NDCache from > becoming full almost instantly under an attack. Since the largest > existing routers have about 100k entries at most, an attack can fill > that up in *one second.* > > On some platforms, existing entries must be periodically refreshed by > actual ARP/NDP exchange. If they are not refreshed, the entries go > away, and traffic stops flowing. This is extremely bad because it can > break even hosts with constant traffic flows, such as a server or > infrastructure link to a neighboring router. Depending on the attack > PPS and policer configuration, such hosts may remain broken for the > duration of the attack. > > Implementations differ greatly in this regard. All of them break > under an attack. Every single current implementation breaks in some > fashion. It's just a question of how bad. > > -- > Jeff S Wheeler > Sr Network Operator? /? Innovative Network Concepts > From sthaug at nethelp.no Fri Jan 7 03:19:41 2011 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Fri, 07 Jan 2011 10:19:41 +0100 (CET) Subject: IPv6 - real vs theoretical problems In-Reply-To: References: Message-ID: <20110107.101941.74740365.sthaug@nethelp.no> > Are there any large transit networks doing /64 on point-to-point > networks to BGP customers? Who are they? What steps have they taken > to eliminate problems, if any? Our Global Crossing IPv6 transit is on a /64 Ethernet point-to-point. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From rdobbins at arbor.net Fri Jan 7 03:38:32 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Fri, 7 Jan 2011 09:38:32 +0000 Subject: NIST IPv6 document In-Reply-To: <20110107194452.110fa401@opy.nosense.org> References: <20110105043548.BC01B1CC3E@ptavv.es.net> <4661ED7E-A4DA-4CD4-A7EB-C5B2E615F126@delong.com> <86zkreb486.fsf@seastrom.com> <20110107194452.110fa401@opy.nosense.org> Message-ID: <393B7513-84A6-470B-9CE5-63B3584B707F@arbor.net> On Jan 7, 2011, at 4:14 PM, Mark Smith wrote: > Doesn't this risk already exist in IPv4? There are various vendor knobs/features to ameliorate ARP-level issues in switching gear. Those same knobs aren't viable in IPv6 due to the way ND/NS work, and as you mention, the ND stuff is layer-3-routable. ------------------------------------------------------------------------ Roland Dobbins // Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay From rdobbins at arbor.net Fri Jan 7 04:44:19 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Fri, 7 Jan 2011 10:44:19 +0000 Subject: Problems with removing NAT from a network In-Reply-To: <51390CEC-BF37-4211-A472-FC9989654BDA@delong.com> References: <4D252B1F.8030506@kenweb.org> <3DFD6833-78C1-43D2-8074-6C89CFE3F2F3@arbor.net> <20110106043110.21C96876D21@drugs.dv.isc.org> <4D254ED8.6030006@matthew.at> <4D25F971.4090709@matthew.at> <4D2634E7.2060502@matthew.at> <9DEED87C-ED15-4D05-BCD6-69A5D4A69681@delong.com> <4D268097.6050502@matthew.at> <0fa801cbae2b$bad57850$308068f0$@com> <4D26B516.80001@matthew.at> <4ECA283F-856C-4813-A4E8-073C136613C5@queuefull.net> <51390CEC-BF37-4211-A472-FC9989654BDA@delong.com> Message-ID: <9F539E44-3012-41ED-8018-78973EA88632@arbor.net> On Jan 7, 2011, at 4:02 PM, Owen DeLong wrote: > No, it hasn't always been a Bad Idea. Yes, it has. There're lots of issues with embedding IP addresses directly into apps and so forth which have nothing to do with NAT. ------------------------------------------------------------------------ Roland Dobbins // Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay From rs at seastrom.com Fri Jan 7 06:11:42 2011 From: rs at seastrom.com (Robert E. Seastrom) Date: Fri, 07 Jan 2011 07:11:42 -0500 Subject: NIST IPv6 document In-Reply-To: <20110106060142.44CC11CC41@ptavv.es.net> (Kevin Oberman's message of "Wed, 05 Jan 2011 22:01:42 -0800") References: <20110106060142.44CC11CC41@ptavv.es.net> Message-ID: <867hegq5fl.fsf@seastrom.com> "Kevin Oberman" writes: >> The next ship will be departing in a hundred years or so, advance >> registration for the IPv7 design committee are available over there. > > Sorry, but IPv7 has come and gone. It was assigned to the TUBA proposal, > basically replacing IP with CLNP. IPv8 has also been assigned. (Don't ask > as it involved he who must not be named.) In the grand tradition of list pedantry, I must correct both of these statements. :-) IPv7 was TP/IX, which I never really learned anything about (at least nothing that I can remember) at the time. IPv8 was PIP, which got merged with SIP to form SIPP which as I recall evolved into IPv6. It had nothing to do with he who must not be named, but you can't figure this out by googling IPv8 as all it returns is a series of links to flights of fancy. IPv9 was TUBA. Went down for political reasons, but in retrospect perhaps wouldn't have been such a bad thing compred to the "second system syndrome" design that we find ourselves with today (I know I'm gonna take it on the chin for making such a comment, but whatever). 10-14 are unassigned, guess we'd better get crackin, eh? -r From patrick at ianai.net Fri Jan 7 07:55:09 2011 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 7 Jan 2011 08:55:09 -0500 Subject: NANOG 51 (Miami): ISP Security BOF In-Reply-To: <96287424-DF08-4C20-B7C7-96B909915900@arbor.net> References: <96287424-DF08-4C20-B7C7-96B909915900@arbor.net> Message-ID: <4492A8A7-6B0C-446C-8DAB-026D5170D168@ianai.net> On Jan 6, 2011, at 8:01 PM, Paul Scanlon wrote: > NANOG 51 in Miami is rapidly approaching, January 30 - February 2, and we are looking for topics for the ISP Security BOF. Eric Osterweil and I are going to be moderating this year with the assistance of Danny McPherson. We would very much like to hear your feedback regarding topics of interest for the session. > > If you have any security related topics that you would like to hear about, not hear about, or be willing to speak about, please let one of us know as soon as possible, feedback to the list obviously welcome. It would be nice if we could get some real intelligence on why the botnets have gone quite. By the time NANOG rolls around, if they are still down, it should be clear they are not just on "christmas vacation" or whatever. -- TTFN, patrick From tjc at ecs.soton.ac.uk Fri Jan 7 08:17:41 2011 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Fri, 7 Jan 2011 14:17:41 +0000 Subject: NIST IPv6 document In-Reply-To: <4D25F92A.3070402@brightok.net> References: <201101061644.p06GiIgr097683@aurora.sol.net> <4D25F92A.3070402@brightok.net> Message-ID: On 6 Jan 2011, at 17:17, Jack Bates wrote: > > A randomly setup ssh server without DNS will find itself brute force attacked. Darknets are setup specifically for detection of scans. One side effect of v6, is determining how best to deploy darknets, as we can't just take one or two blocks to do it anymore. We'll need to interweave the darknets with the production blocks. I wish it was possible via DHCPv6-PD to assign a block minus a sub-block (hey, don't use this /64 in the /48 I gave you). It could be that darknets will have to go and flow analysis is all we'll be left with. As RFC6018 suggests, this could be done dynamically on any given active subnet. Tim From tjc at ecs.soton.ac.uk Fri Jan 7 08:23:22 2011 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Fri, 7 Jan 2011 14:23:22 +0000 Subject: NIST IPv6 document In-Reply-To: <3B61690A-3D51-4847-87B5-84D7D1949BF3@delong.com> References: <201101060308.p0638wha085757@aurora.sol.net> <8469431D-AD95-4B75-9CDC-9C0176ED8CF9@arbor.net> <3B61690A-3D51-4847-87B5-84D7D1949BF3@delong.com> <32F280FE-AC3C-4D5C-B1F0-0738DC4D40DF@ecs.soton.ac.uk> Message-ID: On 6 Jan 2011, at 18:20, Owen DeLong wrote: > > On Jan 5, 2011, at 7:18 PM, Dobbins, Roland wrote: > >> >> On Jan 6, 2011, at 10:08 AM, Joe Greco wrote: >> >>> Packing everything densely is an obvious problem with IPv4; we learned early on that having a 48-bit (32 address, 16 port) space to scan made >>> port-scanning easy, attractive, productive, and commonplace. >> >> I don't believe that host-/port-scanning is as serious a problem as you seem to think it is, nor do I think that trying to somehow prevent host from being host-/port-scanned has any material benefit in terms of security posture, that's our fundamental disagreement. >> > You are mistaken... Host scanning followed by port sweeps is a very common threat and still widely practiced in IPv4. In our IPv6 enterprise we have not seen any 'traditional' port scans (across IP space), rather we see port sweeps on IPv6 addresses that we expose publicly (DNS servers, web servers, MX servers etc). This is discussed a bit in RFC5157. We have yet to see any of the ND problems discussed in this thread, mainly I believe because our perimeter firewall blacks any such sweeps before they hit the edge router serving the 'attacked' subnet. The main operational problem we see is denial of service caused by unintentional IPv6 RAs from hosts. I think this is an interesting thread though and we'll run some tests internally to see how the issue might (or might not) affect our network. Tim From dsparro at gmail.com Fri Jan 7 08:25:59 2011 From: dsparro at gmail.com (David Sparro) Date: Fri, 07 Jan 2011 09:25:59 -0500 Subject: NIST IPv6 document In-Reply-To: References: <201101061429.p06ETB7g096271@aurora.sol.net> Message-ID: <4D272277.8010207@gmail.com> On 1/6/2011 6:23 PM, Dobbins, Roland wrote: > > On Jan 6, 2011, at 9:29 PM, Joe Greco wrote: > >> Sorry, but I see this as not grasping a fundamental security concept. > > I see it as avoiding a common security misconception. > I find that the security "Layers" advocates tend not to look at the differing value of each of those layers. Going back to the physical door analogy, it's like saying that a bank vault protected by a bank vault door is less secure than a vault with the bank vault door AND a screen door. -- Dave From trejrco at gmail.com Fri Jan 7 08:30:50 2011 From: trejrco at gmail.com (TJ) Date: Fri, 7 Jan 2011 09:30:50 -0500 Subject: NIST IPv6 document In-Reply-To: References: <20110105043548.BC01B1CC3E@ptavv.es.net> <4661ED7E-A4DA-4CD4-A7EB-C5B2E615F126@delong.com> <86zkreb486.fsf@seastrom.com> Message-ID: On Thu, Jan 6, 2011 at 21:13, Jeff Wheeler wrote: > On Thu, Jan 6, 2011 at 8:47 PM, Owen DeLong wrote: > > 1. Block packets destined for your point-to-point links at your > > borders. There's no legitimate reason someone should be > > Most networks do not do this today. Whether or not that is wise is > questionable, but I don't think those networks want NDP to be the > reason they choose to make this change. > Today (IPv4) they may not, but many recommendations for tomorrow (IPv6) are to use discrete network allocations for your infrastructure (loopbacks and PtP links, specifically) and to filter traffic destined to those at your edges ... > > 3. Police the ND issue rate on the router. Yes, it means that > > an ND attack could prevent some legitimate ND requests > > from getting through, but, at least it prevents ND overflow and > > the working hosts with existing ND entries continue to function. > > In most cases, this will be virtually all of the active hosts on > > the network. > > You must understand that policing will not stop the NDCache from > becoming full almost instantly under an attack. Since the largest > existing routers have about 100k entries at most, an attack can fill > that up in *one second.* > > On some platforms, existing entries must be periodically refreshed by > actual ARP/NDP exchange. If they are not refreshed, the entries go > away, and traffic stops flowing. This is extremely bad because it can > break even hosts with constant traffic flows, such as a server or > infrastructure link to a neighboring router. Depending on the attack > PPS and policer configuration, such hosts may remain broken for the > duration of the attack. > > Implementations differ greatly in this regard. All of them break > under an attack. Every single current implementation breaks in some > fashion. It's just a question of how bad. And I am not saying there isn't a concern here that we should get vendors to allow us to mitigate, I think we just disagree on the severity of the issue at hand and the complexity of the solution. /TJ From jbates at brightok.net Fri Jan 7 08:32:17 2011 From: jbates at brightok.net (Jack Bates) Date: Fri, 07 Jan 2011 08:32:17 -0600 Subject: Problems with removing NAT from a network In-Reply-To: <9F539E44-3012-41ED-8018-78973EA88632@arbor.net> References: <4D252B1F.8030506@kenweb.org> <3DFD6833-78C1-43D2-8074-6C89CFE3F2F3@arbor.net> <20110106043110.21C96876D21@drugs.dv.isc.org> <4D254ED8.6030006@matthew.at> <4D25F971.4090709@matthew.at> <4D2634E7.2060502@matthew.at> <9DEED87C-ED15-4D05-BCD6-69A5D4A69681@delong.com> <4D268097.6050502@matthew.at> <0fa801cbae2b$bad57850$308068f0$@com> <4D26B516.80001@matthew.at> <4ECA283F-856C-4813-A4E8-073C136613C5@queuefull.net> <51390CEC-BF37-4211-A472-FC9989654BDA@delong.com> <9F539E44-3012-41ED-8018-78973EA88632@arbor.net> Message-ID: <4D2723F1.6070003@brightok.net> On 1/7/2011 4:44 AM, Dobbins, Roland wrote: > Yes, it has. There're lots of issues with embedding IP addresses > directly into apps and so forth which have nothing to do with NAT. Embedding into apps isn't the same as embedding into protocol packets. While NAT and stateful firewalls do tend to break with embedded addresses that they don't know to check for, it's still not a bad idea. I was fixing to complain that the IPv6 designers didn't take the chance to add the embedding to the Packet headers, when it occurs to me, they made the headers nice and extensible. It also baffles me as to why applications such as skype dealing with NAT64 can't use the compatibility addressing to start communicating with v4 hosts from a v6 only NIC. I thought this was already a fixed problem not requiring DNS to deal with. It's not like NAT46 (anyone actually publish such a hideous protocol?), which requires really messy state tables bidirectionally for everything and DNS rewrites. Jack From tjc at ecs.soton.ac.uk Fri Jan 7 08:32:41 2011 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Fri, 7 Jan 2011 14:32:41 +0000 Subject: IPv6 - real vs theoretical problems In-Reply-To: <10FB3518-6470-4F14-963C-B3150FABE667@delong.com> References: <4D269D77.4080309@jima.tk> <10FB3518-6470-4F14-963C-B3150FABE667@delong.com> <3D02DB52-0E31-4B9C-8EDF-D0933198331D@ecs.soton.ac.uk> Message-ID: On 7 Jan 2011, at 06:11, Owen DeLong wrote: > > That's a draft, and, it doesn't really eliminate the idea that /48s are generally > a good thing so much as it recognizes that there might be SOME circumstances > in which they are either not necessary or insufficient. > > As a draft, it hasn't been through the full process and shouldn't be considered > to have the same weight as an RFC. > > While it intends to obsolete RFC-3177, it doesn't obsolete it yet and, indeed, may > never do so. The IETF data tracker shows draft-ietf-v6ops-3177bis-end-sites is under IESG review, with comments currently being made, see https://datatracker.ietf.org/doc/draft-ietf-v6ops-3177bis-end-sites/ which also notes the draft has strong support so is likely to be published soon. The document is only guidance regardless. Tim From jbates at brightok.net Fri Jan 7 08:46:32 2011 From: jbates at brightok.net (Jack Bates) Date: Fri, 07 Jan 2011 08:46:32 -0600 Subject: NIST IPv6 document In-Reply-To: References: <201101061644.p06GiIgr097683@aurora.sol.net> <4D25F92A.3070402@brightok.net> Message-ID: <4D272748.50802@brightok.net> On 1/7/2011 8:17 AM, Tim Chown wrote: > As RFC6018 suggests, this could be done dynamically on any given active subnet. > Unfortunately, I don't see support for it in major router vendors for service providers. Currently, flow + arp/ND/routing tables are utilized to determine a variety of situations, but even then, flow collection is limited at higher speeds. I considered a 1 in 200 approach, but the iBGP tables will go through the roof for a single DHCPv6 pool in a single pop. I a worse problem with darknets than those scanning have with scanning a /64, especially since their scans are likely to be more targeted and not as random. Jack From rdobbins at arbor.net Fri Jan 7 08:56:33 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Fri, 7 Jan 2011 14:56:33 +0000 Subject: NIST IPv6 document In-Reply-To: References: <20110105043548.BC01B1CC3E@ptavv.es.net> <4661ED7E-A4DA-4CD4-A7EB-C5B2E615F126@delong.com> <86zkreb486.fsf@seastrom.com> Message-ID: <38EDE1C4-B991-45FB-8963-E7C25F9F0090@arbor.net> On Jan 7, 2011, at 9:30 PM, TJ wrote: > Today (IPv4) they may not, but many recommendations for tomorrow (IPv6) are to use discrete network allocations for your infrastructure (loopbacks and > PtP links, specifically) and to filter traffic destined to those at your edges ... Actually, this has been an IPv4 BCP for the last decade or so, in order to allow for scalable use of iACLs, CoPP, et. al. ------------------------------------------------------------------------ Roland Dobbins // Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay From rdobbins at arbor.net Fri Jan 7 08:57:42 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Fri, 7 Jan 2011 14:57:42 +0000 Subject: NIST IPv6 document In-Reply-To: References: <201101060308.p0638wha085757@aurora.sol.net> <8469431D-AD95-4B75-9CDC-9C0176ED8CF9@arbor.net> <3B61690A-3D51-4847-87B5-84D7D1949BF3@delong.com> <32F280FE-AC3C-4D5C-B1F0-0738DC4D40DF@ecs.soton.ac.uk> Message-ID: On Jan 7, 2011, at 9:23 PM, Tim Chown wrote: > The main operational problem we see is denial of service caused by unintentional IPv6 RAs from hosts. Which is a whole other can of IPv6 worms, heh. ;> ------------------------------------------------------------------------ Roland Dobbins // Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay From trejrco at gmail.com Fri Jan 7 09:11:57 2011 From: trejrco at gmail.com (TJ) Date: Fri, 7 Jan 2011 10:11:57 -0500 Subject: NIST IPv6 document In-Reply-To: References: <201101060308.p0638wha085757@aurora.sol.net> <8469431D-AD95-4B75-9CDC-9C0176ED8CF9@arbor.net> <3B61690A-3D51-4847-87B5-84D7D1949BF3@delong.com> <32F280FE-AC3C-4D5C-B1F0-0738DC4D40DF@ecs.soton.ac.uk> Message-ID: On Fri, Jan 7, 2011 at 09:57, Dobbins, Roland wrote: > > On Jan 7, 2011, at 9:23 PM, Tim Chown wrote: > > > The main operational problem we see is denial of service caused by > unintentional IPv6 RAs from hosts. > > Which is a whole other can of IPv6 worms, heh. > But atleast we are finally getting the solutions for those - RA-Guard, port ACLs, etc. /TJ (PS - Keep pushing vendors for more widespread support for those!) From trejrco at gmail.com Fri Jan 7 09:14:11 2011 From: trejrco at gmail.com (TJ) Date: Fri, 7 Jan 2011 10:14:11 -0500 Subject: NIST IPv6 document In-Reply-To: <38EDE1C4-B991-45FB-8963-E7C25F9F0090@arbor.net> References: <20110105043548.BC01B1CC3E@ptavv.es.net> <4661ED7E-A4DA-4CD4-A7EB-C5B2E615F126@delong.com> <86zkreb486.fsf@seastrom.com> <38EDE1C4-B991-45FB-8963-E7C25F9F0090@arbor.net> Message-ID: On Fri, Jan 7, 2011 at 09:56, Dobbins, Roland wrote: > > On Jan 7, 2011, at 9:30 PM, TJ wrote: > > > Today (IPv4) they may not, but many recommendations for tomorrow (IPv6) > are to use discrete network allocations for your infrastructure (loopbacks > and > > PtP links, specifically) and to filter traffic destined to those at your > edges ... > > Actually, this has been an IPv4 BCP for the last decade or so, in order to > allow for scalable use of iACLs, CoPP, et. al. True - but some places don't have enough IPv4 address space or willingness to renumber, nor did some have the forethought, to accomplish this ... /TJ From dwing at cisco.com Fri Jan 7 10:33:58 2011 From: dwing at cisco.com (Dan Wing) Date: Fri, 7 Jan 2011 08:33:58 -0800 Subject: Problems with removing NAT from a network In-Reply-To: <4D26B516.80001@matthew.at> References: <4D252B1F.8030506@kenweb.org> <3DFD6833-78C1-43D2-8074-6C89CFE3F2F3@arbor.net> <20110106043110.21C96876D21@drugs.dv.isc.org> <4D254ED8.6030006@matthew.at> <4D25F971.4090709@matthew.at> <4D2634E7.2060502@matthew.at> <9DEED87C-ED15-4D05-BCD6-69A5D4A69681@delong.com> <4D268097.6050502@matthew.at> <0fa801cbae2b$bad57850$308068f0$@com> <4D26B516.80001@matthew.at> Message-ID: <10fa01cbae88$af107df0$0d3179d0$@com> > On 1/6/2011 9:28 PM, Dan Wing wrote: > >> -----Original Message----- > >> From: Matthew Kaufman [mailto:matthew at matthew.at] > >> Not really. Imagine the case where you're on IPv6 and you can only > >> reach > >> IPv4 via a NAT64, and there's no progress made on the detection > >> problem. > >> And your family member is on a Skype-enabled TV plugged into an > >> IPv4-only ISP. > >> > >> Now you can't get a direct media path between you, even though their > >> ISP > >> is giving them IPv4 and your ISP is *claiming* you can "still reach > the > >> IPv4 Internet". > >> > >> Skype can still make this work by relaying, > > Skype could make it work with direct UDP packets in about 92% of > > cases, per Google's published direct-to-direct statistic at > > http://code.google.com/apis/talk/libjingle/important_concepts.html > > > If one end is behind a NAT64 and there is no mechanism for discovering > the NAT64's IPv6 interface prefix and mapping algorithm (and at present > there is not), there is no way to send IPv6 IP packets from the > IPv6-only host to IPv4 literal addresses (that is to say, addresses > learned via a mechanism other than DNS responses synthesized by the > DNS64 part of the NAT64 "solution") on the IPv4 Internet through said > NAT64. > > That's the case we're discussing here. There are a bunch of ideas for how to accomplish that. Several of the ideas don't require any support by the network infrastructure, draft-korhonen-behave-nat64-learn-analysis. > It breaks Skype, Adobe's RTMFP, BitTorrent, ICE-based NAT traversal, > etc. Even the protocol described in the referenced document, Jingle (as > it essentially uses ICE) fails. The candidate IPv4 addresses for the > end > that's on the IPv4 Internet (local and STUN-derived) that are delivered > over Jingle's XMPP path cannot be used by the host that is on IPv6 + > NAT64 to reach the IPv4 Internet because it has no IPv4 sockets > available to it and even if it knew that NAT64 existed (which would > take > a modification to the Jingle-based apps) and opened an IPv6 socket it > wouldn't know what IPv6 address to use to reach the IPv4 host because > there's no discovery mechanism. If you want we can take this back to > the BEHAVE list now. Sure. -d > > Matthew Kaufman From jared at puck.nether.net Fri Jan 7 11:31:12 2011 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 7 Jan 2011 12:31:12 -0500 Subject: Problems with removing NAT from a network In-Reply-To: <9F539E44-3012-41ED-8018-78973EA88632@arbor.net> References: <4D252B1F.8030506@kenweb.org> <3DFD6833-78C1-43D2-8074-6C89CFE3F2F3@arbor.net> <20110106043110.21C96876D21@drugs.dv.isc.org> <4D254ED8.6030006@matthew.at> <4D25F971.4090709@matthew.at> <4D2634E7.2060502@matthew.at> <9DEED87C-ED15-4D05-BCD6-69A5D4A69681@delong.com> <4D268097.6050502@matthew.at> <0fa801cbae2b$bad57850$308068f0$@com> <4D26B516.80001@matthew.at> <4ECA283F-856C-4813-A4E8-073C136613C5@queuefull.net> <51390CEC-BF37-4211-A472-FC9989654BDA@delong.com> <9F539E44-3012-41ED-8018-78973EA88632@arbor.net> Message-ID: <36B5CF4A-1037-445F-AFA7-52B1FA0B95B3@puck.nether.net> On Jan 7, 2011, at 5:44 AM, Dobbins, Roland wrote: > > On Jan 7, 2011, at 4:02 PM, Owen DeLong wrote: > >> No, it hasn't always been a Bad Idea. > > Yes, it has. There're lots of issues with embedding IP addresses directly into apps and so forth which have nothing to do with NAT. Let me know when the products from Arbor no longer require this. Thanks. - Jared From devon+nanog at noved.org Fri Jan 7 11:31:54 2011 From: devon+nanog at noved.org (Devon True) Date: Fri, 07 Jan 2011 12:31:54 -0500 Subject: IPv6 - real vs theoretical problems In-Reply-To: References: Message-ID: <4D274E0A.3040305@noved.org> On 1/6/2011 9:01 PM, Jeff Wheeler wrote: > Are there any large transit networks doing /64 on point-to-point > networks to BGP customers? Who are they? Our Qwest and TW Telecom links are /64. -- Devon From Greg.Whynott at oicr.on.ca Fri Jan 7 11:40:32 2011 From: Greg.Whynott at oicr.on.ca (Greg Whynott) Date: Fri, 7 Jan 2011 12:40:32 -0500 Subject: asymmetric routes/security concerns/Fortinet Message-ID: Hello, we have multiple internet connections of which one is a research network where many medical institutions and universities are also connected to threw out the country. This research network (ORION) also has internet access but is not meant to be used as a primary path to the internet by its customers. Connected to the ORION network are many sites we exchange email with daily who also have multiple internet connections. One of these sites is not reachable by us. After investigating, it was discovered this site is dropping our connections as the path back to use would use a different interface on the firewall ( a Fortinet device) than that which it arrived upon. The admins at this university claim this is by design and for security reasons.. My response was the entire internet is asymmetrical and while this may of been a legitimate concern in the 90's, I don't think its a real concern anymore if things are set up correctly. They suggested we add static routes to our equipment to address this? This seems like a bad idea and I am not comfortable adjusting my routing table to address one site's issues on the internet due to their (not ours) routing/security policies. am I correct here? any comments on this would be greatly appreciated as I'll be called into a meeting to discuss this further (they are digging in their heals in on this, and higher ups are getting involved now). I'd like to arm myself with a few perspectives. thanks very much for your time again, greg -- This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization. From rsm at fast-serv.com Fri Jan 7 12:12:51 2011 From: rsm at fast-serv.com (Randy McAnally) Date: Fri, 7 Jan 2011 13:12:51 -0500 Subject: IPv6 - real vs theoretical problems In-Reply-To: References: Message-ID: <20110107181142.M30040@fast-serv.com> ---------- Original Message ----------- From: Jeff Wheeler Sent: Thu, 6 Jan 2011 21:01:12 -0500 > Are there any large transit networks doing /64 on point-to-point > networks to BGP customers? Who are they? Add HE.net to the list. -Randy www.fastserv.com From jtk at cymru.com Fri Jan 7 12:15:09 2011 From: jtk at cymru.com (John Kristoff) Date: Fri, 7 Jan 2011 12:15:09 -0600 Subject: asymmetric routes/security concerns/Fortinet In-Reply-To: References: Message-ID: <20110107121509.331415d6@t61p> On Fri, 7 Jan 2011 12:40:32 -0500 Greg Whynott wrote: > we have multiple internet connections of which one is a research > network where many medical institutions and universities are also > connected to threw out the country. This research network (ORION) > also has internet access but is not meant to be used as a primary > path to the internet by its customers. Connected to the ORION > network are many sites we exchange email with daily who also have > multiple internet connections. One of these sites is not reachable > by us. After investigating, it was discovered this site is > dropping our connections as the path back to use would use a > different interface on the firewall ( a Fortinet device) than that > which it arrived upon. Correct me if I'm wrong, I'm not very familiar with ORION, but if it's like some of the research networks in the U.S. have been built in the past, ORION is dedicated high speed, low latency network that interconnects research institutions together. The way these are often used is that you localpref routes you learn from ORION participants so that traffic between each of you goes over the research network. You'd typically want this since the performance is good and there is plenty of capacity available, but it is also paid for, probably through some research grant, helping to reduce the use and expense of your commercial transit. You should be sending your traffic to them via ORION and they likewise. However, if that path is down, then it would make sense for it to go via another route. Hence, asymmetry may happen. Are you not sending the traffic via ORION? If so, then I'd suggest you both have something to fix. :-) John From Greg.Whynott at oicr.on.ca Fri Jan 7 12:56:00 2011 From: Greg.Whynott at oicr.on.ca (Greg Whynott) Date: Fri, 7 Jan 2011 13:56:00 -0500 Subject: asymmetric routes/security concerns/Fortinet In-Reply-To: <20110107121509.331415d6@t61p> References: <20110107121509.331415d6@t61p> Message-ID: <6D0D4DF3-4288-4E18-9456-42DAA8115995@oicr.on.ca> Thanks John for your input. You are correct, ORION is a dedicated high speed research network. Based on the fact that we access ORION via one of our ISPs (3rd party, we don't BGP/directly peer with ORION), I'm not sure if i can use this solution here. I could do that for the routes learned from that ISP, but we receive the entire internet routing table from them? I'd have to understand things more before I went down that road. perhaps I shouldn't be accepting the full table from them. the localpref is something I'll look at, thanks for that. I'm not a BGP expert by any stretch, and our requirements here are "simple". we are not a transit. I've only attempted to make the config safe, not efficient. i'd like to hear what you have to say about the original question, is there good reason in this day and age to drop traffic as described in the original post in your opinion? -g On Jan 7, 2011, at 1:15 PM, John Kristoff wrote: > On Fri, 7 Jan 2011 12:40:32 -0500 > Greg Whynott wrote: > >> we have multiple internet connections of which one is a research >> network where many medical institutions and universities are also >> connected to threw out the country. This research network (ORION) >> also has internet access but is not meant to be used as a primary >> path to the internet by its customers. Connected to the ORION >> network are many sites we exchange email with daily who also have >> multiple internet connections. One of these sites is not reachable >> by us. After investigating, it was discovered this site is >> dropping our connections as the path back to use would use a >> different interface on the firewall ( a Fortinet device) than that >> which it arrived upon. > > Correct me if I'm wrong, I'm not very familiar with ORION, but if it's > like some of the research networks in the U.S. have been built in the > past, ORION is dedicated high speed, low latency network that > interconnects research institutions together. The way these are often > used is that you localpref routes you learn from ORION participants so > that traffic between each of you goes over the research network. You'd > typically want this since the performance is good and there is plenty of > capacity available, but it is also paid for, probably through some > research grant, helping to reduce the use and expense of your commercial > transit. > > You should be sending your traffic to them via ORION and they > likewise. However, if that path is down, then it would make sense for > it to go via another route. Hence, asymmetry may happen. > > Are you not sending the traffic via ORION? If so, then I'd suggest you > both have something to fix. :-) > > John -- This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization. From streiner at cluebyfour.org Fri Jan 7 09:12:04 2011 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Fri, 7 Jan 2011 10:12:04 -0500 (EST) Subject: NIST IPv6 document In-Reply-To: References: <20110105043548.BC01B1CC3E@ptavv.es.net> <4661ED7E-A4DA-4CD4-A7EB-C5B2E615F126@delong.com> <86zkreb486.fsf@seastrom.com> Message-ID: On Thu, 6 Jan 2011, Jeff Wheeler wrote: > On Thu, Jan 6, 2011 at 8:47 PM, Owen DeLong wrote: >> 1. ? ? ?Block packets destined for your point-to-point links at your >> ? ? ? ?borders. There's no legitimate reason someone should be > > Most networks do not do this today. Whether or not that is wise is > questionable, but I don't think those networks want NDP to be the > reason they choose to make this change. Correct me if I'm wrong, but wouldn't blocking all traffic destined for your infrastructure at the borders also play havoc with PTMUD? Limiting the traffic allowed to just the necessary types would seem like a reasonable alternative. jms From streiner at cluebyfour.org Fri Jan 7 09:31:57 2011 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Fri, 7 Jan 2011 10:31:57 -0500 (EST) Subject: asymmetric routes/security concerns/Fortinet In-Reply-To: References: Message-ID: > The admins at this university claim this is by design and for security > reasons.. My response was the entire internet is asymmetrical and > while this may of been a legitimate concern in the 90's, I don't think > its a real concern anymore if things are set up correctly. They > suggested we add static routes to our equipment to address this? This > seems like a bad idea and I am not comfortable adjusting my routing > table to address one site's issues on the internet due to their (not > ours) routing/security policies. Working in a university environment like you, we do have connectivity to some of those high-speed R&E networks, and or routing policy generally prefers to use those paths if they are available, for reasons of performance (offloading traffic from more traditional transit paths) and cost/cost avoidance, as others have mentioned. Asymmetric routing is always a possibility between two multi-homed networks. I still occasionally have to wrestle with the notion that many people have that asymmetric routing is bad... If the organization at the far end is doing stateful firewalling at the borders of their multi-homed network, then they are probably accustomed to things 'just breaking' more often then they're willing to admit ;) jms From ken at sizone.org Fri Jan 7 13:37:57 2011 From: ken at sizone.org (Ken Chase) Date: Fri, 7 Jan 2011 14:37:57 -0500 Subject: asymmetric routes/security concerns/Fortinet In-Reply-To: <6D0D4DF3-4288-4E18-9456-42DAA8115995@oicr.on.ca> References: <20110107121509.331415d6@t61p> <6D0D4DF3-4288-4E18-9456-42DAA8115995@oicr.on.ca> Message-ID: <20110107193757.GP12836@sizone.org> On Fri, Jan 07, 2011 at 01:56:00PM -0500, Greg Whynott said: >Based on the fact that we access ORION via one of our ISPs (3rd party, we don't BGP/directly peer with ORION), I'm not sure if i can use this solution here. I could do that for the routes learned from that ISP, but we receive the entire internet routing table from them? I'd have to understand things more before I went down that road. perhaps I shouldn't be accepting the full table from them. > >the localpref is something I'll look at, thanks for that. I'm not a BGP expert by any stretch, and our requirements here are "simple". we are not a transit. I've only attempted to make the config safe, not efficient. > > i'd like to hear what you have to say about the original question, is there good reason in this day and age to drop traffic as described in the original post in your opinion? It sounds like the target site has a possible misconfiguration if this is a long term issue. If they're using the open internet to get back to you and not ORION (when your packets arrived from ORION-based connection), then something is misconfigured or down. The problem is a conflict in the way BGP works and how people assume it works :) BGP is designed to get packets to where they want to go, not drop them if they're going the wrong way. The route back to you via ORION might not be available temporarily for a legitimate reason (outtage, etc), or due to other unintentional side effects of preference configurations. They are likely not seeing a route to you being preferred via ORION. Try some traceroutes from your end and from their end and compare. They're likely different paths. However, that shouldnt be suprising - or a reason to filter traffic, really. Symmetric routes across any chunk (big or small) of the internet are a mythological thing of the past. Don't rely on that being the case at any time. As for your getting a full table from your upstream, you would likely expect and want that. Mixed in would be ORION's prefixes, and if things are working right, you are using an ORION path to get to your target. That's up to the upstream's config preferences for packets destined to go through ORION, so if you are the one using the open internet to get to the target (check your traceroutes), then you need to talk to your upstream and get them to fix their route preferences or whatever link or peering session is down. As for dropping traffic, that's a strong fail-fast signal there. If you want to ensure you are getting the intended bandwidth, say if you needed a 100mbps path guaranteed that ORION can easily give you but the open internet/your respective ISPs cant or wont (or you didnt pay for nor want to), then having it fail immediately instead of using a slow backup path might be what you want. There's a balance to be struck between failing fast thus generating sufficient complaints that pressure to fix the best (and only) path that has the required capacity is done ASAP, but then you are also left with no alternate connectivity to the target in the meantime. Which scenario you prefer is up to you and dependant on your organizations' needs. An alternative is to generate sufficient alarms on the best connection's failure, fail over to slower alternates, alert users to the degraded quality (and modify their expectations and behaviour), and have your respective tech teams respond promptly. This all requires awareness, training and a more sophisticated failure-handling system. (How do you automatically alert all users that the alternate degraded path is in use for eg? Email? Pager?) Having alternate connectivity tends to dilute responce urgency from my experience. A question of discipline/(dis)incentives. :) As for using an outtage as a security measure, yes you will reduce the opportunities for the open internet to be a source of spoofed packets from other 'semi-trusted' entities that you expect to only go across ORION for. However, it sounds like you have no opportunity to determine such packets' arrivals/departures, as it all goes through your upstream(s). The other end however seems to have a firewall system that does determine this disparity of paths. This is a minor security benefit, IMHO, which may be worth it to you, depending on how important some connectivity is vs the increased risk of spoofed packets from the general internet during the primary link via ORION's downtime. And, it seems this is the other org's decision to make, not yours, since you dont directly control your own ORION peering, and you are getting a full routing table from your upstream. If you wanted to control your ORION traffic, you would likely get a second BGP feed and link from your upstream if you cant connect to ORION directly somehow. Are you not on TORIX? If so you could connect to ORION directly as we at Heavy Computing do. /kc > >-g > > > >On Jan 7, 2011, at 1:15 PM, John Kristoff wrote: > >> On Fri, 7 Jan 2011 12:40:32 -0500 >> Greg Whynott wrote: >> >>> we have multiple internet connections of which one is a research >>> network where many medical institutions and universities are also >>> connected to threw out the country. This research network (ORION) >>> also has internet access but is not meant to be used as a primary >>> path to the internet by its customers. Connected to the ORION >>> network are many sites we exchange email with daily who also have >>> multiple internet connections. One of these sites is not reachable >>> by us. After investigating, it was discovered this site is >>> dropping our connections as the path back to use would use a >>> different interface on the firewall ( a Fortinet device) than that >>> which it arrived upon. >> >> Correct me if I'm wrong, I'm not very familiar with ORION, but if it's >> like some of the research networks in the U.S. have been built in the >> past, ORION is dedicated high speed, low latency network that >> interconnects research institutions together. The way these are often >> used is that you localpref routes you learn from ORION participants so >> that traffic between each of you goes over the research network. You'd >> typically want this since the performance is good and there is plenty of >> capacity available, but it is also paid for, probably through some >> research grant, helping to reduce the use and expense of your commercial >> transit. >> >> You should be sending your traffic to them via ORION and they >> likewise. However, if that path is down, then it would make sense for >> it to go via another route. Hence, asymmetry may happen. >> >> Are you not sending the traffic via ORION? If so, then I'd suggest you >> both have something to fix. :-) >> >> John > > >-- > >This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization. -- Ken Chase - ken at heavycomputing.ca - +1 416 897 6284 - Toronto CANADA Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W. From tony at pardini.org Fri Jan 7 13:45:51 2011 From: tony at pardini.org (Anthony Pardini) Date: Fri, 7 Jan 2011 13:45:51 -0600 Subject: asymmetric routes/security concerns/Fortinet In-Reply-To: References: Message-ID: You can allow asymmetric traffic on the Fortinet, but you lose some functionality. Firewalls aren't routers and pretty much all of them behave in the similar manner. On Fri, Jan 7, 2011 at 11:40 AM, Greg Whynott wrote: > > > Hello, > > we have multiple internet connections of which one is a research network where many medical institutions and universities are also connected to threw out the country. ?This research network (ORION) also has internet access but is not meant to be used as a primary path to the internet by its customers. ? ? Connected to the ORION network are many sites we exchange email with daily who also have multiple internet connections. ? One of these sites is not reachable by us. ? After investigating, ?it was discovered this site is dropping our connections as the path back to use would use a different interface on the firewall ( a Fortinet device) than that which it arrived upon. > > The admins at this university claim this is by design and for security reasons.. ? My response was the entire internet is asymmetrical and while this may of been a legitimate concern in the 90's, ?I don't think its a real concern anymore if things are set up correctly. ?They suggested we add static routes to our equipment to address this? ?This seems like a bad idea and I am not comfortable adjusting my routing table to address one site's issues on the internet due to their (not ours) routing/security policies. > > am I correct here? ?any comments on this would be greatly appreciated as I'll be called into a meeting to discuss this further (they are digging in their heals in on this, ?and higher ups are getting involved now). ?I'd like to arm myself with a few perspectives. > > thanks very much for your time again, > > greg > > > > > > -- > > This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization. > > From owen at delong.com Fri Jan 7 13:44:16 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 7 Jan 2011 11:44:16 -0800 Subject: NIST IPv6 document In-Reply-To: References: <201101060308.p0638wha085757@aurora.sol.net> <8469431D-AD95-4B75-9CDC-9C0176ED8CF9@arbor.net> <3B61690A-3D51-4847-87B5-84D7D1949BF3@delong.com> <32F280FE-AC3C-4D5C-B1F0-0738DC4D40DF@ecs.soton.ac.uk> Message-ID: <51A2F375-2C99-41BA-9CC0-16637779E50E@delong.com> On Jan 7, 2011, at 6:23 AM, Tim Chown wrote: > > On 6 Jan 2011, at 18:20, Owen DeLong wrote: > >> >> On Jan 5, 2011, at 7:18 PM, Dobbins, Roland wrote: >> >>> >>> On Jan 6, 2011, at 10:08 AM, Joe Greco wrote: >>> >>>> Packing everything densely is an obvious problem with IPv4; we learned early on that having a 48-bit (32 address, 16 port) space to scan made >>>> port-scanning easy, attractive, productive, and commonplace. >>> >>> I don't believe that host-/port-scanning is as serious a problem as you seem to think it is, nor do I think that trying to somehow prevent host from being host-/port-scanned has any material benefit in terms of security posture, that's our fundamental disagreement. >>> >> You are mistaken... Host scanning followed by port sweeps is a very common threat and still widely practiced in IPv4. > > In our IPv6 enterprise we have not seen any 'traditional' port scans (across IP space), rather we see port sweeps on IPv6 addresses that we expose publicly (DNS servers, web servers, MX servers etc). This is discussed a bit in RFC5157. > Good for you. We have seen actual host-scanning. It hasn't been particularly successful (firing blind into a very large ocean hoping to hit a whale rarely is), but, nonetheless, we've seen scans go at it for up to 8 hours before they were terminated by the originator. (Very little of a /64 gets scanned in 8 hours, however). > We have yet to see any of the ND problems discussed in this thread, mainly I believe because our perimeter firewall blacks any such sweeps before they hit the edge router serving the 'attacked' subnet. > Likewise, we haven't seen them. Not even with the active scanning that has been touted as the likely cause thereof. > The main operational problem we see is denial of service caused by unintentional IPv6 RAs from hosts. > Yep... Push your switch vendors for RA-Guard. This is a very real problem. Right up there with un-intentional 6to4 gateways that don't lead anywhere. Owen From owen at delong.com Fri Jan 7 13:47:29 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 7 Jan 2011 11:47:29 -0800 Subject: Problems with removing NAT from a network In-Reply-To: <4D2723F1.6070003@brightok.net> References: <4D252B1F.8030506@kenweb.org> <3DFD6833-78C1-43D2-8074-6C89CFE3F2F3@arbor.net> <20110106043110.21C96876D21@drugs.dv.isc.org> <4D254ED8.6030006@matthew.at> <4D25F971.4090709@matthew.at> <4D2634E7.2060502@matthew.at> <9DEED87C-ED15-4D05-BCD6-69A5D4A69681@delong.com> <4D268097.6050502@matthew.at> <0fa801cbae2b$bad57850$308068f0$@com> <4D26B516.80001@matthew.at> <4ECA283F-856C-4813-A4E8-073C136613C5@queuefull.net> <51390CEC-BF37-4211-A472-FC9989654BDA@delong.com> <9F539E44-3012-41ED-8018-78973EA88632@arbor.net> <4D2723F1.6070003@brightok.net> Message-ID: On Jan 7, 2011, at 6:32 AM, Jack Bates wrote: > > > On 1/7/2011 4:44 AM, Dobbins, Roland wrote: >> Yes, it has. There're lots of issues with embedding IP addresses >> directly into apps and so forth which have nothing to do with NAT. > > Embedding into apps isn't the same as embedding into protocol packets. While NAT and stateful firewalls do tend to break with embedded addresses that they don't know to check for, it's still not a bad idea. > I was fixing to complain that the IPv6 designers didn't take the chance to add the embedding to the Packet headers, when it occurs to me, they made the headers nice and extensible. > > It also baffles me as to why applications such as skype dealing with NAT64 can't use the compatibility addressing to start communicating with v4 hosts from a v6 only NIC. I thought this was already a fixed problem not requiring DNS to deal with. It's not like NAT46 (anyone actually publish such a hideous protocol?), which requires really messy state tables bidirectionally for everything and DNS rewrites. > > Jack Compatibility addresses don't work on the wire. They're not supposed to. It's a huge problem if they do. Compatibility addresses allow you to write an IPv6 application, run it on a dual-stacked host and talk to the IPv4 and IPv6 remote systems as if all of them are IPv6 hosts. The IPv4 hosts appear to come from the IPv6 range ::ffff:ip:v4 which is often presented to the user as ::ffff:i.p.v.4 . Hope that clarifies things. Owen From deepak at ai.net Fri Jan 7 13:53:49 2011 From: deepak at ai.net (Deepak Jain) Date: Fri, 7 Jan 2011 14:53:49 -0500 Subject: IPv6 - real vs theoretical problems In-Reply-To: References: Message-ID: Thanks Grant, I've already read this. :) I have no problem with enabling /64s for everyone/everything in the future, as the equipment capability increases, but right now there are real concerns about en masse deployment and the vulnerabilities we open our hardware to. Which is why I was talking about reserving the larger block, but only allowing folks to have as much space as they can manage successfully and with a similar risk profile as they have today. Obviously it doesn't take too many people leaving their networks wide to cause a problem for the rest of us. Best, Deepak From: Grant Phillips [mailto:grant.phillips at gwtp.id.au] Sent: Thursday, January 06, 2011 5:47 PM To: Deepak Jain Cc: NANOG list Subject: Re: IPv6 - real vs theoretical problems Hi Deepak, I acknowledge and see the point made. There is a lot of dead space in the IPv6 world. Are we allowing history to repeat it self? Well i'm swaying more to no. Have you read this RFC? This is pretty satisfying in making me feel more comfortable assigning out /48 and /64's. I can sleep at night now! :P http://tools.ietf.org/html//rfc3177 Cheers, Grant Phillips On Fri, Jan 7, 2011 at 9:00 AM, Deepak Jain > wrote: Please, before you flame out, recognize I know a bit of what I am talking about. You can verify this by doing a search on NANOG archives. My point is to actually engage in an operational discussion on this and not insult (or be insulted). While I understand the theoretical advantages of /64s and /56s and /48s for all kinds of purposes, *TODAY* there are very few folks that are actually using any of them. No typical customer knows what do to do (for the most part) with their own /48, and other than autoconfiguration, there is no particular advantage to a /64 block for a single server -- yet. The left side of the prefix I think people and routers are reasonably comfortable with, it's the "host" side that presents the most challenge. My interest is principally in servers and high availability equipment (routers, etc) and other things that live in POPs and datacenters, so autoconfiguration doesn't even remotely appeal to me for anything. In a datacenter, many of these concerns about having routers fall over exist (high bandwidth links, high power equipment trying to do as many things as it can, etc). Wouldn't a number of problems go away if we just, for now, follow the IPv4 lessons/practices like allocating the number of addresses a customer needs --- say /122s or /120s that current router architectures know how to handle -- to these boxes/interfaces today, while just reserving /64 or /56 spaces for each of them for whenever the magic day comes along where they can be used safely? As far as I can tell, this "crippling" of the address space is completely reversible, it's a reasonable step forward and the only "operational" loss is you can't do all the address jumping and obfuscation people like to talk about... which I'm not sure is a loss. In your enterprise, behind your firewall, whatever, where you want autoconfig to work, and have some way of dealing with all of the dead space, more power to you. But operationally, is *anything* gained today by giving every host a /64 to screw around in that isn't accomplished by a /120 or so? Thanks, DJ From Greg.Whynott at oicr.on.ca Fri Jan 7 14:13:02 2011 From: Greg.Whynott at oicr.on.ca (Greg Whynott) Date: Fri, 7 Jan 2011 15:13:02 -0500 Subject: asymmetric routes/security concerns/Fortinet In-Reply-To: <20110107193757.GP12836@sizone.org> References: <20110107121509.331415d6@t61p> <6D0D4DF3-4288-4E18-9456-42DAA8115995@oicr.on.ca> <20110107193757.GP12836@sizone.org> Message-ID: <05DC1683-52A4-4878-A41E-207058FD57B5@oicr.on.ca> Thanks Ken, Some good stuff there, thanks. Since my original email, i think i've come up with a partial solution not requiring the far end's involvement. If not, at least it would get us into a better position to utilize the ORION network when possible. We peer over a L2 tunnel with a router down in the states threw one of our ISP's 10G links, I'm going to see if ORION will do the same with us. This would allow us to establish a BGP session directly with the ORION router, then I could use the localpref options, which may help. this problem is intermitting, most of the time things are fine. doing the above isn't going to help if path/route conditions change, but at least we'll have done all we could within reason and have a proper config. I didn't consider the reasons you mentioned related to 'fail fast', that does make a lot of sense. this is not the reason they claim this policy is in place, it is for security reasons. we access ORION via GTAnet, they are within/part of/something to do with the UoT, and we are across the street. take care, greg @Anthony Pardini On Jan 7, 2011, at 2:45 PM, Anthony Pardini wrote: > Firewalls aren't routers and pretty much all of them > behave in the similar manner. oh! thanks. 8) On Jan 7, 2011, at 2:37 PM, Ken Chase wrote: > > It sounds like the target site has a possible misconfiguration if this is a > long term issue. If they're using the open internet to get back to you and not > ORION (when your packets arrived from ORION-based connection), then something > is misconfigured or down. The problem is a conflict in the way BGP works and > how people assume it works :) BGP is designed to get packets to where they > want to go, not drop them if they're going the wrong way. -- This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization. From ken at sizone.org Fri Jan 7 14:24:41 2011 From: ken at sizone.org (Ken Chase) Date: Fri, 7 Jan 2011 15:24:41 -0500 Subject: asymmetric routes/security concerns/Fortinet In-Reply-To: <05DC1683-52A4-4878-A41E-207058FD57B5@oicr.on.ca> References: <20110107121509.331415d6@t61p> <6D0D4DF3-4288-4E18-9456-42DAA8115995@oicr.on.ca> <20110107193757.GP12836@sizone.org> <05DC1683-52A4-4878-A41E-207058FD57B5@oicr.on.ca> Message-ID: <20110107202441.GS12836@sizone.org> On Fri, Jan 07, 2011 at 03:13:02PM -0500, Greg Whynott said: >Thanks Ken, > >Some good stuff there, thanks. > >Since my original email, i think i've come up with a partial solution not requiring the far end's involvement. If not, at least it would get us into a better position to utilize the ORION network when possible. We peer over a L2 tunnel with a router down in the states threw one of our ISP's 10G links, I'm going to see if ORION will do the same with us. This would allow us to establish a BGP session directly with the ORION router, then I could use the localpref options, which may help. > >this problem is intermitting, most of the time things are fine. doing the above isn't going to help if path/route conditions change, but at least we'll have done all we could within reason and have a proper config. > >I didn't consider the reasons you mentioned related to 'fail fast', that does make a lot of sense. this is not the reason they claim this policy is in place, it is for security reasons. > >we access ORION via GTAnet, they are within/part of/something to do with the UoT, and we are across the street. Intermittent sounds exactly like what's happening - and alternate routes are being chosen when the main link or peering session is down. And their firewall isnt liking the alternate route and blocking packets. (oddly if their policy is simple enough, you sending packets to them also across the open internet so you both are using it to eachother, might make things work - with a further reduction in (perceived?) security. :) Yes, peering directly with ORION would allow you some control of outgoing packets if that's the issue - ie the issue is you sending via open internet. But if the issue is you receiving via open internet (ie the far side is sending via open internet because their ORION routes are not being preferred to you due to outtage, etc), then you'll have to work with them on their side of the issue. Localpref and other big hammer approaches to preferences are effective but indelicate, and only work on outgoing traffic. Engineering incoming traffic is a black art (there are several vendors that will sell you gear and access to help you of course :) If you are going through an upstream that is also on ORION, their concerns for routing to your target should be convergent with yours. Im suspecting that the issue is at the far end with their firewalling policy and link/session, which are harder for you to fix directly. You could also get a lan extension between your site and theirs directly if you wanted to peer with that entity directly, if signficant/frequent valuable traffic between you is sufficient, and you do not want it to ever pass over the open internet. good luck. /kc > > >take care, >greg > > > > > > >@Anthony Pardini >On Jan 7, 2011, at 2:45 PM, Anthony Pardini wrote: > >> Firewalls aren't routers and pretty much all of them >> behave in the similar manner. > > > >oh! thanks. 8) > > > > > > > > > >On Jan 7, 2011, at 2:37 PM, Ken Chase wrote: >> >> It sounds like the target site has a possible misconfiguration if this is a >> long term issue. If they're using the open internet to get back to you and not >> ORION (when your packets arrived from ORION-based connection), then something >> is misconfigured or down. The problem is a conflict in the way BGP works and >> how people assume it works :) BGP is designed to get packets to where they >> want to go, not drop them if they're going the wrong way. > > >-- > >This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization. -- Ken Chase - ken at heavycomputing.ca - +1 416 897 6284 - Toronto CANADA Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W. From jbates at brightok.net Fri Jan 7 14:24:44 2011 From: jbates at brightok.net (Jack Bates) Date: Fri, 07 Jan 2011 14:24:44 -0600 Subject: Problems with removing NAT from a network In-Reply-To: References: <4D252B1F.8030506@kenweb.org> <3DFD6833-78C1-43D2-8074-6C89CFE3F2F3@arbor.net> <20110106043110.21C96876D21@drugs.dv.isc.org> <4D254ED8.6030006@matthew.at> <4D25F971.4090709@matthew.at> <4D2634E7.2060502@matthew.at> <9DEED87C-ED15-4D05-BCD6-69A5D4A69681@delong.com> <4D268097.6050502@matthew.at> <0fa801cbae2b$bad57850$308068f0$@com> <4D26B516.80001@matthew.at> <4ECA283F-856C-4813-A4E8-073C136613C5@queuefull.net> <51390CEC-BF37-4211-A472-FC9989654BDA@delong.com> <9F539E44-3012-41ED-8018-78973EA88632@arbor.net> <4D2723F1.6070003@brightok.net> Message-ID: <4D27768C.6080509@brightok.net> On 1/7/2011 1:47 PM, Owen DeLong wrote: > Compatibility addresses don't work on the wire. They're not supposed to. It's a huge problem if they do. > Sounds like someone should have developed more than 1 compatibility addressing then. Jack From deepak at ai.net Fri Jan 7 14:29:32 2011 From: deepak at ai.net (Deepak Jain) Date: Fri, 7 Jan 2011 15:29:32 -0500 Subject: IPv6 - real vs theoretical problems In-Reply-To: <10FB3518-6470-4F14-963C-B3150FABE667@delong.com> References: <4D269D77.4080309@jima.tk> <10FB3518-6470-4F14-963C-B3150FABE667@delong.com> Message-ID: > > http://www.ietf.org/mail-archive/web/v6ops/current/msg06820.html > > > > Jima > Just skimming through the draft: 1) It is no longer recommended that /128s be given out. While there may be some cases where assigning only a single address may be justified, a site by definition implies multiple subnets and multiple devices. --- I never knew a site, by definition, has multiple subnets and devices. A key principle for address management is that end sites always be able to obtain a reasonable amount of address space for their actual and planned usage, and over time ranges specified in years rather than just months. In practice, that means at least one /64, and in most cases significantly more. One particular situation that must be avoided is having an end site feel compelled to use IPv6-to-IPv6 Network Address Translation or other burdensome address conservation techniques because it could not get sufficient address space. I think this is the real point everyone is trying to get at. They want IP6 to be the end of NAT. Got it. There are now years of security dogma that says NAT is a good thing, in the 20+ years IP6 has been on the books, the dogma went another way. This concept will take a long time to unwind. Somehow this is supposed to mesh with dynamic renumbering where we can move around between /48s without "too much burden" while wildly waving our hands at all the higher-level configs (DNS, Applications, firewalls, etc) that don't play nicely with automatic renumbering. There is some convoluted discussion about how they wanted their /48 policy to somehow encourage residential ISPs to give their users more IP space in the base offering. I'm not sure why or what purpose an addressing policy should have to a business case. I see nothing motivating a residential ISP (especially one providing CPE equipment) to change their current deployment system one iota. And I'm pretty sure they are the ones MOST exposed to abuses of this address space by the least technical user base. (side note, if I were a residential ISP I'd configure a /64 to my highly-controlled CPE router and issue /128s to each and every device that plugged in on the customer site, and only one per MAC and have a remotely configurable limit of say 50 devices or whatever the mac table limit was. So I only have one route entry in my aggregation layer and if the customer blows his CPE router up, I'm still protected.) Question - Whatever happened to the concept of a customer coming to their SP for more space? Why do we have to give them enough space for a decade of theoretical use when every week we could widen their subnet without causing any negative impact on them? No renumbering, etc. It's not considered a burden today, but under IP6 it is? Heck, since space is so plentiful, we can all set up gateways to do it automatically, but until routers get smarter, I don't see how all that dead routable space is a good thing. Customers are paying for and getting a service, a continuous relationship with some set of SPs. In that service they aren't getting a mathematical representation, they are getting usable IP space, but that doesn't mean that if they hop out of bed in the middle of the night and decide to allocate 5,000,000 unique IPs the SP network should automatically accept it (based on today's current technology). BOGONS, IP hijacks and all the rest seem like the worse problem here and the whole point of putting training wheels on these roll outs. Instead, it seems we are systematically unwinding all the lessons learned from CIDR and going back to addresses being classful, interface links being massive space wasters and no one caring about addresses. That's fine, and probably an improvement, until the next round of attacks and then shortages occur. Once the schools start teaching RFC3177, the hardcoded apps are sure to follow. Deepak From Chris_Harvey at cable.comcast.com Fri Jan 7 14:39:13 2011 From: Chris_Harvey at cable.comcast.com (Harvey, Chris) Date: Fri, 7 Jan 2011 20:39:13 +0000 Subject: Starbucks network admins Message-ID: Does anyone have any good contacts for Starbucks network admins? -- Chris Harvey Distinguished Engineer o: 703-939-8479 m: 703-967-4229 From swmike at swm.pp.se Fri Jan 7 14:39:35 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 7 Jan 2011 21:39:35 +0100 (CET) Subject: IPv6 - real vs theoretical problems In-Reply-To: References: <4D269D77.4080309@jima.tk> <10FB3518-6470-4F14-963C-B3150FABE667@delong.com> Message-ID: On Fri, 7 Jan 2011, Deepak Jain wrote: > least technical user base. (side note, if I were a residential ISP I'd > configure a /64 to my highly-controlled CPE router and issue /128s to > each and every device that plugged in on the customer site, and only one > per MAC and have a remotely configurable limit of say 50 devices or > whatever the mac table limit was. So I only have one route entry in my > aggregation layer and if the customer blows his CPE router up, I'm still > protected.) This is exactly the reason to issue /48 or /56 to the end user. You give them plenty of space, and you then don't have to care anymore about what the user does with this space. You keep do LL only between CPE and PE, so you only need to keep 4 TCAM entries per customer (one for the /XX route, one for the LL adjacancy, one for the permit ACL to permit packets from the /XX, and one deny line. (I might be misunderstanding exactly what's needed here and a few TCAM entries more are needed, but you get the idea). > until routers get smarter, I don't see how all that dead routable space > is a good thing. Customers are paying for and getting a service, a > continuous relationship with some set of SPs. In that service they If I give them a /56 then it's zero administration for me for the forseeable future. Why on earth would I want to handle customer administration when I don't need to? -- Mikael Abrahamsson email: swmike at swm.pp.se From bill at herrin.us Fri Jan 7 15:28:03 2011 From: bill at herrin.us (William Herrin) Date: Fri, 7 Jan 2011 16:28:03 -0500 Subject: IPv6 - real vs theoretical problems In-Reply-To: References: <4D269D77.4080309@jima.tk> <10FB3518-6470-4F14-963C-B3150FABE667@delong.com> Message-ID: On Fri, Jan 7, 2011 at 3:29 PM, Deepak Jain wrote: > Question - Whatever happened to the concept of a customer > coming to their SP for more space? [E]very week we could > widen their subnet without causing any negative > impact on them? Clever folks figured that making the customer wait for support hours and then paying people to process configuration changes could be usefully removed from the business cycle? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Fri Jan 7 15:28:20 2011 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sat, 8 Jan 2011 07:58:20 +1030 Subject: NIST IPv6 document In-Reply-To: <393B7513-84A6-470B-9CE5-63B3584B707F@arbor.net> References: <20110105043548.BC01B1CC3E@ptavv.es.net> <4661ED7E-A4DA-4CD4-A7EB-C5B2E615F126@delong.com> <86zkreb486.fsf@seastrom.com> <20110107194452.110fa401@opy.nosense.org> <393B7513-84A6-470B-9CE5-63B3584B707F@arbor.net> Message-ID: <20110108075820.7fe32a58@opy.nosense.org> On Fri, 7 Jan 2011 09:38:32 +0000 "Dobbins, Roland" wrote: > > On Jan 7, 2011, at 4:14 PM, Mark Smith wrote: > > > Doesn't this risk already exist in IPv4? > > > There are various vendor knobs/features to ameliorate ARP-level issues in switching gear. Those same knobs aren't viable in IPv6 due to the way ND/NS work, I was commenting on the mentality the OP seemed to be expressing, about *both* onlink and off link sources triggering address resolution for lots of non-existent destinations, and that this was a new and unacceptable threat. I think the offlink risk is a far more significant one. I think the onlink risk pretty much no worse than any of the other things that LAN attached devices can do if they choose to. > and as you mention, the ND stuff is layer-3-routable. > The issue isn't that ND is layer 3 routable - it isn't unless a router implementation is broken. The problem is that somebody on the Internet could send 1000s of UDP packets (i.e. an offlink traffic source) towards destinations that don't exist on the target subnet. The upstream router will then perform address resolution, sending ND NSes for those unknown destinations, and while waiting to see if ND NAs are returned, will maintain state for each outstanding ND NS. This state is what is exploitable remotely, unless the state table size is large enough to hold all possible outstanding ND NA entries for all possible addresses on the target subnet. I think this problem can be avoided by getting rid of this offlink traffic triggered address resolution state. The purpose of the state (from the Neighbor Discovery RFC) is two fold - - to allow the ND NS to be resent up to two times if no ND NA response is received to ND NSes. A number of triggering packets (e.g. UDP ones or TCP SYNs) are queued as well so that they can be resent if and when ND NS/NA completes. - to allow ICMP destination unreachables to be generated if the ND NS/NA transaction fails, even after resending. I think it is acceptable to compromise on these requirements. ND NS/NA transactions are going to be successful most of the time, so the ND NS/NA retransmit mechanism is going to be rarely used. Original traffic sources have to be prepared for it to fail anyway - the Internet is a best effort network, so if a source node wants to be sure a packet gets to the original destination it needs to be prepared to retransmit it. This has actually proved not to be a problem in IPv4 as Cisco routers have for many years dumped the data packet that triggers ARP, which I'm pretty sure is the reason why the ARP timeout is 4 hours, rather than the more common 5 minutes. Time outs are pretty much moot anyway, because active Neighbor Unreachability Detection is usually performed these days instead of using simple timeouts for existing ARP entries and is required to be performed by IPv6. If you don't maintain state for outstanding ND NS transactions, then that means that the ND NS issuing device will have to just blindly accept any ND NAs it receives at any time, and put them in the neighbor cache, assuming they are correct. That is an vulnerability, as a local node could fill up the neighbor cache with bogus entries, but one that is far less of a risk than the Internet sourced one we're talking about, as it is only onlink devices that can exploit it. As a LAN is already a trusted environment for basic protocol operations, and devices have a vested interest not disabling other devices that provide them with services e.g. default routers, I think it is a reasonable and acceptable risk given those we already accept in LANs, such as the IPv4 ones I mentioned. If it isn't, implement static address resolution entries, PPPoE, per-device VLANs, SEND etc. I doubt I need to go into much detail about whether ICMP destination unreachables need to be reliably received, the reality is that they aren't in IPv4 and I doubt that will change much in IPv6. I think they're a "nice to have" not a "need to have". Regards, Mark. From cidr-report at potaroo.net Fri Jan 7 16:00:04 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 7 Jan 2011 22:00:04 GMT Subject: BGP Update Report Message-ID: <201101072200.p07M04in000915@wattle.apnic.net> BGP Update Report Interval: 30-Dec-10 -to- 06-Jan-11 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS18025 31461 3.2% 873.9 -- ACE-1-WIFI-AS-AP Ace-1 Wifi Network 2 - AS17974 20942 2.1% 17.7 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 3 - AS8103 20677 2.1% 55.0 -- STATE-OF-FLA - Florida Department of Management Services - Technology Program 4 - AS32528 19431 2.0% 4857.8 -- ABBOTT Abbot Labs 5 - AS33475 18464 1.9% 129.1 -- RSN-1 - RockSolid Network, Inc. 6 - AS24627 17517 1.8% 486.6 -- SHOWNET-KW-AS GULFSATCOMMUNICATIONS COMPANY K.S.C. 7 - AS35931 15601 1.6% 5200.3 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 8 - AS7462 13969 1.4% 297.2 -- ONEWEST - SRVnet, Inc. 9 - AS24554 12398 1.3% 108.8 -- FIVE-NET-AS-IN Fivenetwork Solution India Pvt Ltd Internet 10 - AS9498 12353 1.2% 17.5 -- BBIL-AP BHARTI Airtel Ltd. 11 - AS24923 12123 1.2% 12123.0 -- SETTC South-East Transtelecom Joint Stock Co. 12 - AS23700 11034 1.1% 30.1 -- BM-AS-ID PT. Broadband Multimedia, Tbk 13 - AS45474 10393 1.1% 692.9 -- NEXUSGUARD-AS-AP Tower 1 Millennium City 1 14 - AS10113 10157 1.0% 597.5 -- DATAFAST-AP DATAFAST TELECOMMUNICATIONS LTD 15 - AS24560 9145 0.9% 8.7 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 16 - AS9829 9012 0.9% 23.9 -- BSNL-NIB National Internet Backbone 17 - AS25620 8759 0.9% 62.1 -- COTAS LTDA. 18 - AS5800 8266 0.8% 37.9 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 19 - AS8151 6941 0.7% 21.6 -- Uninet S.A. de C.V. 20 - AS45595 6611 0.7% 13.8 -- PKTELECOM-AS-PK Pakistan Telecom Company Limited TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS24923 12123 1.2% 12123.0 -- SETTC South-East Transtelecom Joint Stock Co. 2 - AS35931 15601 1.6% 5200.3 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 3 - AS32528 19431 2.0% 4857.8 -- ABBOTT Abbot Labs 4 - AS17408 3041 0.3% 3041.0 -- ABOVE-AS-AP AboveNet Communications Taiwan 5 - AS4454 2979 0.3% 2979.0 -- TNET-AS - State of Tennessee 6 - AS49776 1870 0.2% 1870.0 -- GORSET-AS Gorodskaya Set Ltd. 7 - AS49600 1745 0.2% 1745.0 -- LASEDA La Seda de Barcelona, S.A 8 - AS8510 1441 0.1% 1441.0 -- Tomsk town Educational and Scientific network 9 - AS2828 5679 0.6% 1419.8 -- XO-AS15 - XO Communications 10 - AS34239 1335 0.1% 1335.0 -- INTERAMERICAN General Insurance Company 11 - AS43534 2597 0.3% 1298.5 -- CREDITCALL CreditCall Ltd 12 - AS45550 1221 0.1% 1221.0 -- NGT-AS-VN New Generations Telecommunications Corporation 13 - AS2685 1955 0.2% 977.5 -- ASATTCA AT&T Global Network Services - CA 14 - AS28666 4805 0.5% 961.0 -- HOSTLOCATION LTDA 15 - AS21324 926 0.1% 926.0 -- OSW Osrodek Studiow Wschodnich im Marka Karpia 16 - AS1959 2755 0.3% 918.3 -- DMSLABNET - DoD Network Information Center 17 - AS18025 31461 3.2% 873.9 -- ACE-1-WIFI-AS-AP Ace-1 Wifi Network 18 - AS47722 861 0.1% 861.0 -- CONCORDE-AS Concorde Capital Ltd. 19 - AS27666 814 0.1% 814.0 -- INSTITUTO TECNOLOGICO DE TELEFONOS DE MEXICO 20 - AS21271 798 0.1% 798.0 -- SOTELMABGP TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 194.126.34.0/24 17142 1.6% AS24627 -- SHOWNET-KW-AS GULFSATCOMMUNICATIONS COMPANY K.S.C. 2 - 213.129.96.0/19 12123 1.1% AS24923 -- SETTC South-East Transtelecom Joint Stock Co. 3 - 180.233.173.0/24 10181 1.0% AS45474 -- NEXUSGUARD-AS-AP Tower 1 Millennium City 1 4 - 202.182.78.0/23 10125 1.0% AS10113 -- DATAFAST-AP DATAFAST TELECOMMUNICATIONS LTD 5 - 63.211.68.0/22 10064 0.9% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 6 - 130.36.35.0/24 9716 0.9% AS32528 -- ABBOTT Abbot Labs 7 - 130.36.34.0/24 9711 0.9% AS32528 -- ABBOTT Abbot Labs 8 - 202.92.235.0/24 7094 0.7% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 9 - 27.123.248.0/22 6288 0.6% AS18025 -- ACE-1-WIFI-AS-AP Ace-1 Wifi Network 10 - 182.54.140.0/22 6279 0.6% AS18025 -- ACE-1-WIFI-AS-AP Ace-1 Wifi Network 11 - 182.54.148.0/22 6279 0.6% AS18025 -- ACE-1-WIFI-AS-AP Ace-1 Wifi Network 12 - 101.78.24.0/22 6129 0.6% AS18025 -- ACE-1-WIFI-AS-AP Ace-1 Wifi Network 13 - 101.78.20.0/22 6128 0.6% AS18025 -- ACE-1-WIFI-AS-AP Ace-1 Wifi Network 14 - 198.140.43.0/24 5446 0.5% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 15 - 189.1.173.0/24 4739 0.5% AS28666 -- HOSTLOCATION LTDA 16 - 216.126.136.0/22 4559 0.4% AS6316 -- AS-PAETEC-NET - PaeTec Communications, Inc. 17 - 189.85.51.0/24 3683 0.3% AS28175 -- 18 - 206.184.16.0/24 3553 0.3% AS174 -- COGENT Cogent/PSI 19 - 68.65.152.0/22 3358 0.3% AS11915 -- TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 20 - 202.153.174.0/24 3041 0.3% AS17408 -- ABOVE-AS-AP AboveNet Communications Taiwan Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu 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 Jan 7 16:00:00 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 7 Jan 2011 22:00:00 GMT Subject: The Cidr Report Message-ID: <201101072200.p07M0055000905@wattle.apnic.net> This report has been generated at Fri Jan 7 21:11:48 2011 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 31-12-10 341294 200729 01-01-11 341509 200882 02-01-11 341492 200810 03-01-11 341470 200862 04-01-11 341512 200876 05-01-11 341666 200899 06-01-11 341989 200893 07-01-11 342117 201012 AS Summary 36422 Number of ASes in routing system 15485 Number of ASes announcing only one prefix 3717 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 118804736 Largest address span announced by an AS (/32s) AS237 : MERIT-ASN Merit Network Inc. 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'). --- 07Jan11 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 342320 201017 141303 41.3% All ASes AS6389 3717 271 3446 92.7% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 2633 405 2228 84.6% TWTC - tw telecom holdings, inc. AS19262 1841 286 1555 84.5% VZGNI-TRANSIT - Verizon Online LLC AS4766 1898 540 1358 71.5% KIXS-AS-KR Korea Telecom AS22773 1263 83 1180 93.4% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS6478 1441 272 1169 81.1% ATT-INTERNET3 - AT&T Services, Inc. AS4755 1394 337 1057 75.8% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS1785 1788 769 1019 57.0% AS-PAETEC-NET - PaeTec Communications, Inc. AS28573 1226 313 913 74.5% NET Servicos de Comunicao S.A. AS7545 1559 714 845 54.2% TPG-INTERNET-AP TPG Internet Pty Ltd AS6503 1198 362 836 69.8% Axtel, S.A.B. de C.V. AS10620 1344 545 799 59.4% Telmex Colombia S.A. AS18101 913 150 763 83.6% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS8151 1409 663 746 52.9% Uninet S.A. de C.V. AS7303 840 122 718 85.5% Telecom Argentina S.A. AS4808 1022 316 706 69.1% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS3356 1189 489 700 58.9% LEVEL3 Level 3 Communications AS24560 1060 371 689 65.0% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS17488 943 269 674 71.5% HATHWAY-NET-AP Hathway IP Over Cable Internet AS9498 736 108 628 85.3% BBIL-AP BHARTI Airtel Ltd. AS18566 1095 475 620 56.6% COVAD - Covad Communications Co. AS11492 1283 680 603 47.0% CABLEONE - CABLE ONE, INC. AS17676 645 68 577 89.5% GIGAINFRA Softbank BB Corp. AS855 630 55 575 91.3% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS4780 749 211 538 71.8% SEEDNET Digital United Inc. AS22047 565 31 534 94.5% VTR BANDA ANCHA S.A. AS14420 593 89 504 85.0% CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP AS7552 632 132 500 79.1% VIETEL-AS-AP Vietel Corporation AS3549 856 358 498 58.2% GBLX Global Crossing Ltd. AS9443 571 75 496 86.9% INTERNETPRIMUS-AS-AP Primus Telecommunications Total 37033 9559 27474 74.2% Top 30 total Possible Bogus Routes 5.0.0.0/8 AS237 MERIT-ASN Merit Network Inc. 5.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 5.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 5.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 23.0.0.0/8 AS237 MERIT-ASN Merit Network Inc. 24.129.192.0/19 AS7922 COMCAST-7922 - Comcast Cable Communications, Inc. 37.0.0.0/8 AS237 MERIT-ASN Merit Network Inc. 37.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 37.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 37.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.21.192.0/20 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.212.0/22 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.216.0/21 AS11610 INETNEBR-1 - Internet Nebraska Corporation 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 69.6.81.0/24 AS13442 71.19.134.0/23 AS3313 INET-AS I.NET S.p.A. 72.22.32.0/19 AS33150 72.22.61.0/24 AS33150 72.22.62.0/24 AS33150 76.77.32.0/19 AS2828 XO-AS15 - XO Communications 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 96.45.161.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.162.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.163.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.164.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.165.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.166.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.167.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.168.0/21 AS3257 TINET-BACKBONE Tinet SpA 100.0.0.0/8 AS237 MERIT-ASN Merit Network Inc. 100.100.100.0/24 AS3549 GBLX Global Crossing Ltd. 105.0.0.0/8 AS237 MERIT-ASN Merit Network Inc. 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas 110.173.64.0/19 AS37963 CNNIC-ALIBABA-CN-NET-AP Alibaba (China) Technology Co., Ltd. 113.29.0.0/17 AS3549 GBLX Global Crossing Ltd. 113.29.0.0/20 AS3549 GBLX Global Crossing Ltd. 113.29.16.0/20 AS3549 GBLX Global Crossing Ltd. 113.29.32.0/20 AS3549 GBLX Global Crossing Ltd. 113.29.64.0/20 AS3549 GBLX Global Crossing Ltd. 115.42.28.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.30.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.31.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.40.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.42.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.43.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.44.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.47.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.48.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.49.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.50.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.51.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.52.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.53.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.54.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.55.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.56.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.57.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.58.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.59.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.61.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.62.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.63.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 116.68.136.0/21 AS28045 Pantel Communications 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 121.54.160.0/24 AS38890 121.54.161.0/24 AS38890 121.54.162.0/24 AS38890 121.54.163.0/24 AS38890 121.54.164.0/24 AS38890 121.54.166.0/24 AS38890 121.54.167.0/24 AS38890 121.200.192.0/24 AS17767 122.200.32.0/20 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 122.200.40.0/21 AS38272 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services Inc. 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 172.12.0.0/18 AS28665 PredialNet Provedor de Internet Ltda. 176.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 176.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 176.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 180.210.220.0/22 AS17494 BTTB-AS-AP Telecom Operator & Internet Service Provider as well 190.102.32.0/20 AS30058 FDCSERVERS - FDCservers.net 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.101.46.0/24 AS6503 Axtel, S.A.B. de C.V. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 196.2.224.0/22 AS24863 LINKdotNET-AS 196.6.108.0/24 AS5713 SAIX-NET 196.13.201.0/24 AS2018 TENET-1 196.13.202.0/24 AS2018 TENET-1 196.13.203.0/24 AS2018 TENET-1 196.13.204.0/24 AS2018 TENET-1 196.110.105.0/24 AS8513 SKYVISION SkyVision Network Services 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.15.4.0/24 AS4323 TWTC - tw telecom holdings, inc. 198.15.5.0/24 AS4323 TWTC - tw telecom holdings, inc. 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.99.241.0/24 AS11797 AC-NIELSEN-AS AC NIELSEN 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 198.182.235.0/24 AS3356 LEVEL3 Level 3 Communications 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 199.185.130.0/23 AS19662 UNISERVE-ONLINE - Uniserve On Line 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.233.92.0/24 AS26896 D102-ITC - Data 102, LLC 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.24.73.0/24 AS26061 Equant Colombia 200.24.78.0/26 AS3549 GBLX Global Crossing Ltd. 200.24.78.64/26 AS3549 GBLX Global Crossing Ltd. 202.1.224.0/24 AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000 202.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.38.63.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.58.113.0/24 AS19161 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.66.128.0/18 AS9584 GENESIS-AP Diyixian.com Limited 202.66.160.0/19 AS9584 GENESIS-AP Diyixian.com Limited 202.66.160.0/20 AS9584 GENESIS-AP Diyixian.com Limited 202.66.176.0/20 AS9584 GENESIS-AP Diyixian.com Limited 202.66.184.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.186.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.188.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.189.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.190.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.133.37.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.146.186.0/24 AS23655 SNAP-NZ-AS Snap Internet Limited 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 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.130.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.131.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.133.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 202.179.144.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.149.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.150.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.18.156.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.22.78.0/24 AS18117 HARBOURMSP-AU-AP Harbour MSP Pty. Ltd 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.27.123.0/24 AS4739 CIX-ADELAIDE-AS Internode Systems Pty Ltd 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.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.142.219.0/24 AS45149 203.175.107.0/24 AS45595 PKTELECOM-AS-PK Pakistan Telecom Company Limited 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.10.232.0/21 AS33150 204.19.14.0/23 AS577 BACOM - Bell Canada 204.209.114.0/24 AS13768 PEER1 - Peer 1 Network Inc. 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 DISTRIBUTEL-AS11814 - DISTRIBUTEL COMMUNICATIONS LTD. 205.207.148.0/23 AS812 ROGERS-CABLE - Rogers Cable Communications Inc. 205.210.145.0/24 AS11814 DISTRIBUTEL-AS11814 - DISTRIBUTEL COMMUNICATIONS LTD. 206.72.192.0/23 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 206.72.194.0/23 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 206.123.129.0/24 AS10790 INREACH-AS - InReach Internet 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.188.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.189.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.190.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.191.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.64.200.0/22 AS11730 CIL-ASN - Circle Internet LTD 208.64.240.0/21 AS13871 TELEBYTE-NW - Telebyte NW 208.73.160.0/24 AS32767 208.78.165.0/24 AS16565 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.83.54.0/24 AS23485 SEI-LLC-AS-NUM - SEI LLC 208.92.196.0/22 AS10929 NETELLIGENT - Netelligent Hosting Services Inc. 208.92.199.0/24 AS26198 3MENATWORK - 3Men at Work Integrated Networks, Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.165.239.0/24 AS209 ASN-QWEST - Qwest Communications Company, LLC 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.213.1.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 209.213.4.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 216.10.235.0/24 AS13780 NTNCOMMUNICATIONS - NTN 216.10.236.0/24 AS13780 NTNCOMMUNICATIONS - NTN 216.21.196.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.201.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.202.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.206.0/23 AS12251 INVISION - Invision.com, Inc. 216.58.192.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.197.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.200.0/24 AS18530 ISOMEDIA-1 - Isomedia Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.250.112.0/20 AS7296 ALCHEMYNET - Alchemy Communications, Inc. Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From owen at delong.com Fri Jan 7 16:11:58 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 7 Jan 2011 14:11:58 -0800 Subject: IPv6 - real vs theoretical problems In-Reply-To: <20110107181142.M30040@fast-serv.com> References: <20110107181142.M30040@fast-serv.com> Message-ID: <75ED8860-556E-4390-B0DF-7416265F0112@delong.com> On Jan 7, 2011, at 10:12 AM, Randy McAnally wrote: > ---------- Original Message ----------- > From: Jeff Wheeler > Sent: Thu, 6 Jan 2011 21:01:12 -0500 > >> Are there any large transit networks doing /64 on point-to-point >> networks to BGP customers? Who are they? > > Add HE.net to the list. > > -Randy > www.fastserv.com Correct... HE uses /64 on point-to-point links. We give tunnel broker customers a /64 if they only want a single network and a /48 upon request. Owen From owen at delong.com Fri Jan 7 16:15:59 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 7 Jan 2011 14:15:59 -0800 Subject: NIST IPv6 document In-Reply-To: References: <20110105043548.BC01B1CC3E@ptavv.es.net> <4661ED7E-A4DA-4CD4-A7EB-C5B2E615F126@delong.com> <86zkreb486.fsf@seastrom.com> Message-ID: On Jan 7, 2011, at 7:12 AM, Justin M. Streiner wrote: > On Thu, 6 Jan 2011, Jeff Wheeler wrote: > >> On Thu, Jan 6, 2011 at 8:47 PM, Owen DeLong wrote: >>> 1. Block packets destined for your point-to-point links at your >>> borders. There's no legitimate reason someone should be >> >> Most networks do not do this today. Whether or not that is wise is >> questionable, but I don't think those networks want NDP to be the >> reason they choose to make this change. > > Correct me if I'm wrong, but wouldn't blocking all traffic destined for your infrastructure at the borders also play havoc with PTMUD? Limiting the traffic allowed to just the necessary types would seem like a reasonable alternative. > > jms It would only play havoc if your infrastructure is originating packets destined to the outside world from it's link addresses. Generally this shouldn't happen. Remember, I'm only blocking traffic TO the point-to-point LINK networks. Not to the servers, loopbacks, etc. Owen From Greg.Whynott at oicr.on.ca Fri Jan 7 16:28:03 2011 From: Greg.Whynott at oicr.on.ca (Greg Whynott) Date: Fri, 7 Jan 2011 17:28:03 -0500 Subject: asymmetric routes/security concerns/Fortinet In-Reply-To: References: <20110107121509.331415d6@t61p> <6D0D4DF3-4288-4E18-9456-42DAA8115995@oicr.on.ca> <20110107193757.GP12836@sizone.org> <05DC1683-52A4-4878-A41E-207058FD57B5@oicr.on.ca> Message-ID: Randy your assumptions are correct, all outbounds get that slapped on them, automagically. good thing you have read the same magic book and can counter! 8) I don't or ever did expect anything from you, not sure why you thought i might. do you think I should quit this organization because we do this, and not consider the good work and intentions they have? (finding a cure for cancer) I don't think the legal's deparments intention was to force anything onto the world. sounds like you have a lot of anger issues to work out. 8) take care and have a great weekend, greg On Jan 7, 2011, at 4:59 PM, Randy Bush wrote: > you have sent a message to me which seems to contain a legal > warning on who can read it, or how it may be distributed, or > whether it may be archived, etc. > > i do not accept such email. my mail user agent detected a legal > notice when i was opening your mail, and automatically deleted it. > so do not expect further response. > > yes, i know your mail environment automatically added the legal > notice. well, my mail environment automatically detected it, > deleted it, and sent this message to you. so don't expect a lot > of sympathy. > > and if you choose to work for some enterprise clueless enough to > think that they can force this silliness on the world, use gmail, > hotmail, ... > > randy -- This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization. From jtk at cymru.com Fri Jan 7 16:43:29 2011 From: jtk at cymru.com (John Kristoff) Date: Fri, 7 Jan 2011 16:43:29 -0600 Subject: asymmetric routes/security concerns/Fortinet In-Reply-To: <6D0D4DF3-4288-4E18-9456-42DAA8115995@oicr.on.ca> References: <20110107121509.331415d6@t61p> <6D0D4DF3-4288-4E18-9456-42DAA8115995@oicr.on.ca> Message-ID: <20110107164329.027569af@t61p> On Fri, 7 Jan 2011 13:56:00 -0500 Greg Whynott wrote: > the localpref is something I'll look at, thanks for that. I'm not > a BGP expert by any stretch, and our requirements here are > "simple". we are not a transit. I've only attempted to make the > config safe, not efficient. I'm not quite sure I understand what the paths look like, but you could also append your ASN once or twice for your routes on the less preferred path to make the other institution use the more preferred one as long as it is available. > i'd like to hear what you have to say about the original question, > is there good reason in this day and age to drop traffic as described > in the original post in your opinion? Depends on who you ask. I think it clearly shows a mismatch in the assumptions of security devices, engineers and the actual behavior of some deployed networks. Since you're both part of ORION, ideally packets would be following the same path in both directions. I suggest you endeavor to make that the common case. However, to answer your question, dropping packets because the path is asymmetrical would not be something I'd want my university network to be doing. I'd love for them to tell me it's happening though. John From owen at delong.com Fri Jan 7 16:44:42 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 7 Jan 2011 14:44:42 -0800 Subject: IPv6 - real vs theoretical problems In-Reply-To: References: <4D269D77.4080309@jima.tk> <10FB3518-6470-4F14-963C-B3150FABE667@delong.com> Message-ID: <70A7A45E-6685-4584-BA71-8B25F0EA09BF@delong.com> On Jan 7, 2011, at 12:29 PM, Deepak Jain wrote: >>> http://www.ietf.org/mail-archive/web/v6ops/current/msg06820.html >>> >>> Jima >> > > Just skimming through the draft: > > 1) It is no longer recommended that /128s be given out. While there > may be some cases where assigning only a single address may be > justified, a site by definition implies multiple subnets and > multiple devices. > > --- I never knew a site, by definition, has multiple subnets and devices. > > A key principle for address management is that end sites always > be able to obtain a reasonable amount of address space for their > actual and planned usage, and over time ranges specified in > years rather than just months. In practice, that means at least > one /64, and in most cases significantly more. One particular > situation that must be avoided is having an end site feel > compelled to use IPv6-to-IPv6 Network Address Translation or > other burdensome address conservation techniques because it > could not get sufficient address space. > > I think this is the real point everyone is trying to get at. They want IP6 to be the end of NAT. Got it. There are now years of security dogma that says NAT is a good thing, in the 20+ years IP6 has been on the books, the dogma went another way. This concept will take a long time to unwind. Somehow this is supposed to mesh with dynamic renumbering where we can move around between /48s without "too much burden" while wildly waving our hands at all the higher-level configs (DNS, Applications, firewalls, etc) that don't play nicely with automatic renumbering. > You say dogma, I say mythology. Stateful inspection provides security. NAT, by itself, does not. The reason people are confused about this is because overloaded NAT cannot occur without stateful inspection. Actually, DNS can be made to play relatively nicely with automatic renumbering and most client hosts don't need DNS entries anyway. Firewalls generally apply policy to network segments and not individual policies to migratory hosts. Yes, it might be nice if they could, but, that's a hard problem to solve in a secure fashion. Generally, nomadic or migratory hosts can usually accept the security policy for the network to which they are attached and augment it with their own host-based firewall/filter rules in any case. In such a case, the host-based rules can be written in terms of interfaces and directions without much regard to the renumbering of the host in question. > There is some convoluted discussion about how they wanted their /48 policy to somehow encourage residential ISPs to give their users more IP space in the base offering. I'm not sure why or what purpose an addressing policy should have to a business case. I see nothing motivating a residential ISP (especially one providing CPE equipment) to change their current deployment system one iota. And I'm pretty sure they are the ones MOST exposed to abuses of this address space by the least technical user base. (side note, if I were a residential ISP I'd configure a /64 to my highly-controlled CPE router and issue /128s to each and every device that plugged in on the customer site, and only one per MAC and have a remotely configurable limit of say 50 devices or whatever the mac table limit was. So I only have one route entry in my aggregation layer and if the customer blows his CPE router up, I'm still protected.) > If you were an ISP, you wouldn't be one I would subscribe to. There are multiple purposes to /48s to residential end users. DHCP-PD allows a lot of future innovations not yet available. Imagine a house where the border router receives a /48 from the ISP and delegates /64s or /60s or whatever to other routers within the house. Each home entertainment cluster may be one group of networks with its own router. The appliance network(s) may have their own router(s). RFID tags on groceries may lead to a time when your home automation server can gather up data from your refrigerator, pantries, etc. and present the inventory on your mobile phone while you're at the grocery store. No more need to maintain a shopping list, just query the inventory from the store. These are just the things that could easily be done with the technology we already know about. Imagine what we might think of once we get more used to having prefix abundance. > Question - Whatever happened to the concept of a customer coming to their SP for more space? Why do we have to give them enough space for a decade of theoretical use when every week we could widen their subnet without causing any negative impact on them? No renumbering, etc. It's not considered a burden today, but under IP6 it is? Heck, since space is so plentiful, we can all set up gateways to do it automatically, but until routers get smarter, I don't see how all that dead routable space is a good thing. Customers are paying for and getting a service, a continuous relationship with some set of SPs. In that service they aren't getting a mathematical representation, they are getting usable IP space, but that doesn't mean that if they hop out of bed in the middle of the night and decide to allocate 5,000,000 unique IPs the SP network should automatically accept it (based on today's current technology). > It is considered a burden today, but, it's a burden everyone accepts for the following reasons: 1. IPv4 is scarce, so, we recognize the need to conserve. 2. For the most part, people live behind a single address and expansion is done from RFC-1918 space where the average household sees said space as virtually limitless and they aren't coming back to their ISP. Think of giving a residence a /48 as the IPv6 equivalent of letting them use 10/8 without the additional headaches associated with NAT. 3. The rare occasion that does require another address, people swallow hard face the burden and do what they have to to get more space. Usually this involves paying an additional fee to the ISP. As an ISP, once you issue a /48 to a customer, what do you care how many of those addresses they actually use/allocate? What difference does it make to you whether they use 1, 50, 100, 10,000, 100,000, 500,000,000,000 or whatever? Why should you care? You have one route entry that forwards packets to their router. After that, it's up to them to have enough hardware to handle the ND tables, etc. that result. It doesn't affect your network. You just shovel all the packets to them and it's their problem from there. > BOGONS, IP hijacks and all the rest seem like the worse problem here and the whole point of putting training wheels on these roll outs. Instead, it seems we are systematically unwinding all the lessons learned from CIDR and going back to addresses being classful, interface links being massive space wasters and no one caring about addresses. That's fine, and probably an improvement, until the next round of attacks and then shortages occur. Once the schools start teaching RFC3177, the hardcoded apps are sure to follow. > If you give your customers /48s and nobody accepts routes that are more specific than /48, where does the BOGON problem come from here? This is a huge red herring and shows a lack of understanding of how IPv6 actually works. CIDR is inherent in IPv6. It just happens (mostly) in the left-most 48 bits, leaving the remaining 80 bits to be administered by the local site, usually as 16-bits for network and 64 bits for host, but, even that isn't written in stone for every site, it's just what works best. Owen From owen at delong.com Fri Jan 7 16:53:02 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 7 Jan 2011 14:53:02 -0800 Subject: NIST IPv6 document In-Reply-To: <20110108075820.7fe32a58@opy.nosense.org> References: <20110105043548.BC01B1CC3E@ptavv.es.net> <4661ED7E-A4DA-4CD4-A7EB-C5B2E615F126@delong.com> <86zkreb486.fsf@seastrom.com> <20110107194452.110fa401@opy.nosense.org> <393B7513-84A6-470B-9CE5-63B3584B707F@arbor.net> <20110108075820.7fe32a58@opy.nosense.org> Message-ID: On Jan 7, 2011, at 1:28 PM, Mark Smith wrote: > On Fri, 7 Jan 2011 09:38:32 +0000 > "Dobbins, Roland" wrote: > >> >> On Jan 7, 2011, at 4:14 PM, Mark Smith wrote: >> >>> Doesn't this risk already exist in IPv4? >> >> >> There are various vendor knobs/features to ameliorate ARP-level issues in switching gear. Those same knobs aren't viable in IPv6 due to the way ND/NS work, > > I was commenting on the mentality the OP seemed to be > expressing, about *both* onlink and off link sources triggering address > resolution for lots of non-existent destinations, and that this was a > new and unacceptable threat. I think the offlink risk is a > far more significant one. I think the onlink risk pretty much no worse > than any of the other things that LAN attached devices can do if they > choose to. > >> and as you mention, the ND stuff is layer-3-routable. >> > > The issue isn't that ND is layer 3 routable - it isn't unless a router > implementation is broken. The problem is that somebody on the Internet > could send 1000s of UDP packets (i.e. an offlink traffic source) > towards destinations that don't exist on the target subnet. The > upstream router will then perform address resolution, sending ND NSes > for those unknown destinations, and while waiting to see if ND NAs are > returned, will maintain state for each outstanding ND NS. This state is > what is exploitable remotely, unless the state table size is large > enough to hold all possible outstanding ND NA entries for all possible > addresses on the target subnet. > > I think this problem can be avoided by getting rid of this offlink > traffic triggered address resolution state. The purpose of the state > (from the Neighbor Discovery RFC) is two fold - > > - to allow the ND NS to be resent up to two times if no ND NA response > is received to ND NSes. A number of triggering packets (e.g. UDP > ones or TCP SYNs) are queued as well so that they can be resent if and > when ND NS/NA completes. > > - to allow ICMP destination unreachables to be generated if the ND > NS/NA transaction fails, even after resending. > > I think it is acceptable to compromise on these requirements. I'm inclined to agree with you, but... I think it might also make sense to eliminate the ND NS/NA transaction altogether for addresses that do not begin with xxxx:xxxx:xxxx:xxxx:000x. In other words, for non SLAAC addresses, we need the ND NS/NA process (even if we do it stateless which isn't an entirely bad idea), but, for SLAAC addresses, the MAC is embedded in the IP address, so, why not just use that? Owen From mikeal.clark at gmail.com Fri Jan 7 17:29:20 2011 From: mikeal.clark at gmail.com (Mikeal Clark) Date: Fri, 7 Jan 2011 17:29:20 -0600 Subject: Gmail Contact Message-ID: I'm having some issues with personal domains that forward to gmail being blacklist. If anyone from gmail would be available to talk through it with me offlist I would greatly appreciate it. Thanks, Mikeal From rdobbins at arbor.net Fri Jan 7 19:02:51 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Sat, 8 Jan 2011 01:02:51 +0000 Subject: IPv6 - real vs theoretical problems In-Reply-To: References: <4D269D77.4080309@jima.tk> <10FB3518-6470-4F14-963C-B3150FABE667@delong.com> Message-ID: <442E296F-A5DD-4BE0-AE42-BA02E49F5F4D@arbor.net> On Jan 8, 2011, at 3:29 AM, Deepak Jain wrote: > There are now years of security dogma that says NAT is a good thing, Actually, this isn't the case. There's some *security theater* dogma which makes totally unsupported claims about the supposed security benefits of NAT, but that's not quite the same thing. ;> NAT has no inherent security benefits whatsoever, and quite a few security drawbacks. ------------------------------------------------------------------------ Roland Dobbins // Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay From rdobbins at arbor.net Fri Jan 7 19:06:56 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Sat, 8 Jan 2011 01:06:56 +0000 Subject: IPv6 - real vs theoretical problems In-Reply-To: <70A7A45E-6685-4584-BA71-8B25F0EA09BF@delong.com> References: <4D269D77.4080309@jima.tk> <10FB3518-6470-4F14-963C-B3150FABE667@delong.com> <70A7A45E-6685-4584-BA71-8B25F0EA09BF@delong.com> Message-ID: <72CBC0FE-3376-42C0-880B-6162DE943BED@arbor.net> On Jan 8, 2011, at 5:44 AM, Owen DeLong wrote: > You say dogma, I say mythology. Concur 100%. > Stateful inspection provides security. To clarify, stateful inspection only provides security in a context where there's state to inspect - i.e., at the southernmost end of access networks, directly in front of machines which are serving as client workstations. In all other contexts, such as in front of servers and in the middle of access networks, stateful inspection has no security benefit whatsoever, and is actually quite harmful, with a hugely negative effect on security. ;> ------------------------------------------------------------------------ Roland Dobbins // Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay From rdobbins at arbor.net Fri Jan 7 19:08:55 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Sat, 8 Jan 2011 01:08:55 +0000 Subject: NIST IPv6 document In-Reply-To: <20110108075820.7fe32a58@opy.nosense.org> References: <20110105043548.BC01B1CC3E@ptavv.es.net> <4661ED7E-A4DA-4CD4-A7EB-C5B2E615F126@delong.com> <86zkreb486.fsf@seastrom.com> <20110107194452.110fa401@opy.nosense.org> <393B7513-84A6-470B-9CE5-63B3584B707F@arbor.net> <20110108075820.7fe32a58@opy.nosense.org> Message-ID: <61C02575-54F2-4EF5-A5CD-7882F5215178@arbor.net> On Jan 8, 2011, at 4:28 AM, Mark Smith wrote: > The problem is that somebody on the Internet > could send 1000s of UDP packets (i.e. an offlink traffic source) towards destinations that don't exist on the target subnet. I meant to type 'ND-triggering stuff', concur 100%. ------------------------------------------------------------------------ Roland Dobbins // Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay From randy at psg.com Fri Jan 7 19:43:44 2011 From: randy at psg.com (Randy Bush) Date: Sat, 08 Jan 2011 10:43:44 +0900 Subject: asymmetric routes/security concerns/Fortinet In-Reply-To: References: <20110107121509.331415d6@t61p> <6D0D4DF3-4288-4E18-9456-42DAA8115995@oicr.on.ca> <20110107193757.GP12836@sizone.org> <05DC1683-52A4-4878-A41E-207058FD57B5@oicr.on.ca> Message-ID: you have sent a message to me which seems to contain a legal warning on who can read it, or how it may be distributed, or whether it may be archived, etc. i do not accept such email. my mail user agent detected a legal notice when i was opening your mail, and automatically deleted it. so do not expect further response. yes, i know your mail environment automatically added the legal notice. well, my mail environment automatically detected it, deleted it, and sent this message to you. so don't expect a lot of sympathy. and if you choose to work for some enterprise clueless enough to think that they can force this silliness on the world, use gmail, hotmail, ... randy From bill at herrin.us Fri Jan 7 19:54:07 2011 From: bill at herrin.us (William Herrin) Date: Fri, 7 Jan 2011 20:54:07 -0500 Subject: IPv6 - real vs theoretical problems In-Reply-To: <442E296F-A5DD-4BE0-AE42-BA02E49F5F4D@arbor.net> References: <4D269D77.4080309@jima.tk> <10FB3518-6470-4F14-963C-B3150FABE667@delong.com> <442E296F-A5DD-4BE0-AE42-BA02E49F5F4D@arbor.net> Message-ID: On Fri, Jan 7, 2011 at 8:02 PM, Dobbins, Roland wrote: > NAT has no inherent security benefits whatsoever. Hi Roland, With that statement, you paint with a remarkably broad brush. As you know, folks use (or perhaps misuse) the term "NAT" to describe everything from RFC 1631 to so-called "transparent proxies" which are basically bastion hosts with some fancy behavior on the interior interface. I presume you don't intend us to conclude that a bastion host firewall provides no security benefit to the equipment it protects. Would you care to clarify which of that range of technologies you consider to serve no security function? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From rdobbins at arbor.net Fri Jan 7 20:00:10 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Sat, 8 Jan 2011 02:00:10 +0000 Subject: IPv6 - real vs theoretical problems In-Reply-To: References: <4D269D77.4080309@jima.tk> <10FB3518-6470-4F14-963C-B3150FABE667@delong.com> <442E296F-A5DD-4BE0-AE42-BA02E49F5F4D@arbor.net> Message-ID: <8D806878-5D6E-4ABB-BDD9-9E6A58F33D77@arbor.net> On Jan 8, 2011, at 8:54 AM, William Herrin wrote: > I presume you don't intend us to conclude that a bastion host firewall provides no security benefit to the equipment it > protects. If it's protecting workstations, yes, it has some positive security value - but not due to NAT. If it's inappropriately placed in front of servers, where's there's no state to inspect and were the stateful nature of the device in and of itself forms a DoS vector, it has negative security value; i.e., it makes things far worse. ------------------------------------------------------------------------ Roland Dobbins // Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay From bill at herrin.us Fri Jan 7 20:49:15 2011 From: bill at herrin.us (William Herrin) Date: Fri, 7 Jan 2011 21:49:15 -0500 Subject: IPv6 - real vs theoretical problems In-Reply-To: <8D806878-5D6E-4ABB-BDD9-9E6A58F33D77@arbor.net> References: <4D269D77.4080309@jima.tk> <10FB3518-6470-4F14-963C-B3150FABE667@delong.com> <442E296F-A5DD-4BE0-AE42-BA02E49F5F4D@arbor.net> <8D806878-5D6E-4ABB-BDD9-9E6A58F33D77@arbor.net> Message-ID: On Fri, Jan 7, 2011 at 9:00 PM, Dobbins, Roland wrote: > On Jan 8, 2011, at 8:54 AM, William Herrin wrote: >> I presume you don't intend us to conclude that a bastion >> host firewall provides no security benefit to the equipment it >> protects. > > If it's protecting workstations, yes, it has some positive security value - but not due to NAT. Hi Roland, I see. Would I misstate your view if I characterized it as: "A bastion host firewall which simulates identical IP addresses on both sides provides at least as effective security as an otherwise identical firewall which does not." Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From ryan.finnesey at HarrierInvestments.com Fri Jan 7 21:11:21 2011 From: ryan.finnesey at HarrierInvestments.com (Ryan Finnesey) Date: Fri, 7 Jan 2011 19:11:21 -0800 Subject: FAA - ASDI servers In-Reply-To: References: Your message of "Tue, 04 Jan 2011 22:49:34 EST." <20110105041148.DE0951CC3E@ptavv.es.net> <6EFFEFBAC68377459A2E972105C759EC0342B558@EXVBE005-2.exch005intermedia.net> Message-ID: <6EFFEFBAC68377459A2E972105C759EC0342B7CF@EXVBE005-2.exch005intermedia.net> I wanted to thank everyone for both their online and offline replies. At this time the FAA does not support IPv6 to connect to the ASDI servers. Cheers Ryan -----Original Message----- From: Merike Kaeo [mailto:merike at doubleshotsecurity.com] Sent: Wednesday, January 05, 2011 12:14 AM To: Ryan Finnesey Cc: nanog at nanog.org Subject: Re: FAA - ASDI servers I've pinged someone offline who may have a contact. Will let you know offline if I do and connect you. I had some peripheral insight a few years ago when I did some work with Boeing. Even had a hand at editing some ARINC standards. The airline industry was umm....interesting :) Suffice to say the guy I was working with at Boeing was pushing hard for v6 capability within ARINC and this was 2007. Keep fingers crossed. - merike On Jan 4, 2011, at 8:57 PM, Ryan Finnesey wrote: > Can they simply extend the mandate? We need to setup new connectivity > to the FFA and was hoping to go IPv6 right out of the gate. > Cheers > Ryan > > > -----Original Message----- > From: Kevin Oberman [mailto:oberman at es.net] > Sent: Tuesday, January 04, 2011 11:12 PM > To: Christopher Morrow > Cc: Ryan Finnesey; nanog at nanog.org > Subject: Re: FAA - ASDI servers > >> Date: Tue, 4 Jan 2011 22:49:34 -0500 >> From: Christopher Morrow >> >> On Tue, Jan 4, 2011 at 10:39 PM, Ryan Finnesey >> wrote: >>> Very true but why the reference to vacuum tubes? >> >> sadly it was an FAA computer system joke. > > But, since the "F" stands for Federal, if it is still up in two years, > it must be reachable by IPv6. Today, the odds are pretty slim as > almost no federal systems are reachable by IPv6. It will be an > interesting two years for a lot of federal IT folks as the mandate is > from the OMB who can pull a budget for non-compliance. > -- > R. Kevin Oberman, Network Engineer > Energy Sciences Network (ESnet) > Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) > E-mail: oberman at es.net Phone: +1 510 486-8634 > Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 > From vixie at isc.org Fri Jan 7 23:33:20 2011 From: vixie at isc.org (Paul Vixie) Date: Sat, 08 Jan 2011 05:33:20 +0000 Subject: AltDB? Message-ID: <59051.1294464800@nsa.vix.com> note that while i am also an ARIN trustee, i am speaking here as what randy calls "just another bozo on this bus". for further background, ISC has done some rpki work and everybody at ISC including me likes rpki just fine. when the ARIN board was first considering funding ISC to do some early rpki work, went out into the hallway until the discussion was over (ending positively.) On Jan 5, 2011, at 12:32 PM, Randy Bush wrote: > i have a rumor that arin is delaying and possibly not doing rpki that > seems to have been announced on the ppml list (to which i do not > subscribe). john curran has explained that arin is doing its due diligence on some concerns that were brought up during a review of the rpki rollout. there is no sense in which arin has said that it is "not doing rpki" although the current review does technically qualify as "delaying rpki". i'm treating the above rumour as false. David Conrad writes: > I heard about the delay, but not about ARIN possibly not doing RPKI. That > would be ... surprising. [...] it would be very much surprising to me as well. [bush] > as it has impact on routing, not address policy, across north america > and, in fact the globe, one would think it would be announced and > discussed a bit more openly and widely. even if i thought that the operational impact could be felt in these early days when rpki remains an almost completely nonproduction service, and i don't think this by the way, i would still say that an internal review of a new service is not really something the whole community cares about. [conrad] > The definition of what comes under the "public policy mailing list" > umbrella has always been a bit confusing to me. Too bad something like > the APNIC SIGs and RIPE Working Groups don't really exist in the ARIN > region. do you have a specific proposal? i've noted in the past that arin tries hard to stick to its knitting, which is allocation and allocation policy. it seems to me that if some in the community wanted arin to run SIGs or WGs on things like routing policy arin could do it but that a lot of folks would say that's mission creep and that it would be arin poaching on nanog lands. -- Paul Vixie Chairman and Chief Scientist, ISC Trustee, ARIN From randy at psg.com Sat Jan 8 00:47:51 2011 From: randy at psg.com (Randy Bush) Date: Sat, 08 Jan 2011 15:47:51 +0900 Subject: AltDB? In-Reply-To: <59051.1294464800@nsa.vix.com> References: <59051.1294464800@nsa.vix.com> Message-ID: [ caveat: i am *one of* the architects of all this, and am paid to work on it, currently (indirectly) by the usg dhs. ] for background, the other four rirs have rolled rpki out in the last weeks, apnic and afrinic with the up/down protocol, ripe web only, and i am not well informed about lacnic's roll out. for the geeky, i append the trust anchor locators for all but afrinic (i'll try to get that). > even if i thought that the operational impact could be felt in these > early days when rpki remains an almost completely nonproduction > service, and i don't think this by the way, i would still say that an > internal review of a new service is not really something the whole > community cares about. well yes and no. it was important enough that (i have been told) john announced it on major arin mailing list(s). and, as we all know, when info is not openly visible, it gets warped in transmission. hence the (i think you are saying) incorrect impression out here that the bot is questioning rpki roll-out in general. more recent rumors, and john's posting here, seem to indicate that o arin's lawyer, who actually seems to run arin, has created massive fud about liability. o so arin management is seriously reconsidering a web-only roll-out and seriously considering prioritizing being able to delegate the authority to the large isps by implementing the up/down protocol (draft-ietf-sidr-rescerts-provisioning-09.txt). i am a big fan of up/down. i am not a big fan of delay. first, it would really help if the arin bot and management were much more open about these issues and decisions. at the detailed level. we are all not fools out here, present company excepted :). for a radical example, considering that arin is managing a public resource for the community, why are bot meetings not streamed a la cspan? i do not see how you are going to get rid of the liability. you have it now in whois/irr if i use it for routing (except they are so widely known to be bad data that the world knows i would be a fool to bet on them). whether the source of a roa is a user whacking on an arin web page or by other means, you still attested to the rights to that address space. but all this is based on inference and rumor. can you please be more open and direct about this? thanks. randy --- ripe-ncc-root.tal rsync://rpki.afrinic.net/repository/AfriNIC.cer MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxsAqAhWIO+ON2Ef9oRDM pKxv+AfmSLIdLWJtjrvUyDxJPBjgR+kVrOHUeTaujygFUp49tuN5H2C1rUuQavTH vve6xNF5fU3OkTcqEzMOZy+ctkbde2SRMVdvbO22+TH9gNhKDc9l7Vu01qU4LeJH k3X0f5uu5346YrGAOSv6AaYBXVgXxa0s9ZvgqFpim50pReQe/WI3QwFKNgpPzfQL 6Y7fDPYdYaVOXPXSKtx7P4s4KLA/ZWmRL/bobw/i2fFviAGhDrjqqqum+/9w1hEl L/vqihVnV18saKTnLvkItA/Bf5i11Yhw2K7qv573YWxyuqCknO/iYLTR1DToBZcZ UQIDAQAB rsync://repository.lacnic.net/rpki/lacnic/RTA_LACNIC_RPKI.cer MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1AuR49ZoKS59Vnpq8M0X djeV3ROqtElwx6sNmUXvWBFPQlZLs2tR5/0MwprIWRi91WnMBVWjsECcLBe7Pu+u V/tTvPMJRXm/c+l8nR+FhAj7pn4M5A2pHFBndCPc1UrFD+BLACx9DSNiUjzKr1t7 wjHTW+F0NMnZ9g9hKdxDNCFi66BGx2f3TTW3uGns/IPfkxrRCeYtJcBpQ5mKoc8g QOndiEG/33uXDS9EOe1dycmnaw9EQqxqHp+Bj0TIVoFyfDNuT+soJ3uwtQr2g5Ys AIxJtmBAZrLj+acmLeQrYC0xQuK118dSAS9r6GSm476m2aGEYtb083fLodeYSEjM /wIDAQAB rsync://rpki.ripe.net/ta/ripe-ncc-ta.cer MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0URYSGqUz2m yBsOzeW1jQ6NsxNvlLMyhWknvnl8NiBCs/T/S2XuNKQNZ+wBZxIgPPV 2pFBFeQAvoH/WK83HwA26V2siwm/MY2nKZ+Olw+wlpzlZ1p3Ipj2eNc Krmit8BwBC8xImzuCGaV0jkRB0GZ0hoH6Ml03umLprRsn6v0xOP0+l6 Qc1ZHMFVFb385IQ7FQQTcVIxrdeMsoyJq9eMkE6DoclHhF/NlSllXub ASQ9KUWqJ0+Ot3QCXr4LXECMfkpkVR2TZT+v5v658bHVs6ZxRD1b6Uk 1uQKAyHUbn/tXvP8lrjAibGzVsXDT2L0x4Edx+QdixPgOji3gBMyL2V wIDAQAB From drc at virtualized.org Sat Jan 8 01:01:52 2011 From: drc at virtualized.org (David Conrad) Date: Fri, 7 Jan 2011 21:01:52 -1000 Subject: AltDB? In-Reply-To: <59051.1294464800@nsa.vix.com> References: <59051.1294464800@nsa.vix.com> Message-ID: <00041A16-473F-4F96-93E8-E3CD3F83E1B2@virtualized.org> Paul, On Jan 7, 2011, at 7:33 PM, Paul Vixie wrote: >> The definition of what comes under the "public policy mailing list" >> umbrella has always been a bit confusing to me. Too bad something like >> the APNIC SIGs and RIPE Working Groups don't really exist in the ARIN >> region. > > do you have a specific proposal? i've noted in the past that arin tries > hard to stick to its knitting, which is allocation and allocation policy. Yes. This is a positive (IMHO), however it seems that occasionally, ARIN's knitting tangles up folks who don't necessarily involve themselves with ARIN's existing interaction mechanisms (at least directly). > it seems to me that if some in the community wanted arin to run SIGs or WGs > on things like routing policy arin could do it but that a lot of folks would > say that's mission creep and that it would be arin poaching on nanog lands. The issue I see is that there are non-address allocation{, policy} topics that can deeply affect network operations in which ARIN has a direct role, yet network operators (outside of the normal ARIN participants) have no obvious mechanism in which to comment/discuss/etc. Examples would include reverse DNS operations, whois database-related issues (operations, schema, access methods, etc.), (potentially?) RPKI, etc. It doesn't seem appropriate to me for these to be discussed in relation to addressing policy nor are the issues associated with those examples necessarily related to address allocation, hence I wouldn't think they'd be fodder for ppml. In the other regions, the RIRs host the discussions (e.g., for reverse DNS-related discussions there is dns-wg in RIPE and dns-sig in APNIC, not sure if there are similar constructs in LACNIC or AfriNIC) and the RIR staff provides input but (as far as I know) do not direct results. Since the (non-ARIN) RIRs typically perform some action based on input from these hosted discussions (or explain to the community why they can't/won't), this works reasonably well. In the ARIN region, for reasons that you mention among others, I'm unclear whether there is sufficient trust (on both sides, ARIN or the ARIN-region network operations community) for ARIN to do something similar (note I'm not saying there isn't trust, just that I'm not sure that there is). One alternative (which I suggest being blissfully ignorant of either politics or establishment mechanisms in NANOG) would be for some sort of joint ARIN/NANOG "interest group" (or whatever) for areas that impact ARIN and network operators in which folks have interest such as routing policy/security, dns operations, registration data representation/access, etc. So, in other words, no, I don't really have a specific proposal. Regards, -drc From randy at psg.com Sat Jan 8 01:31:26 2011 From: randy at psg.com (Randy Bush) Date: Sat, 08 Jan 2011 16:31:26 +0900 Subject: arin and ops fora (was: AltDB? RPKI, the universe, and ...) In-Reply-To: <00041A16-473F-4F96-93E8-E3CD3F83E1B2@virtualized.org> References: <59051.1294464800@nsa.vix.com> <00041A16-473F-4F96-93E8-E3CD3F83E1B2@virtualized.org> Message-ID: > The issue I see is that there are non-address allocation{, policy} > topics that can deeply affect network operations in which ARIN has a > direct role, yet network operators (outside of the normal ARIN > participants) have no obvious mechanism in which to > comment/discuss/etc. Examples would include reverse DNS operations, > whois database-related issues (operations, schema, access methods, > etc.), (potentially?) RPKI, etc. It doesn't seem appropriate to me > for these to be discussed in relation to addressing policy nor are the > issues associated with those examples necessarily related to address > allocation, hence I wouldn't think they'd be fodder for ppml. please $deity no. one difference in north america from the other 'regions' is that there is a strong and very separate operator community and forum. this does not really exist in the other regions. ripe ate the eof years ago. apops is dormant aside from helping with apricot. afnog has been strong, but is fading except for the once a year workshops. enredo may be reborn, but we have yet to see. observe that the main north american irr, radb, is not run by the rir, unlike in other regions. and i like that there are a number of diverse rir services in the region. it's healthy. so i would be perfectly happy if arin discussed operational matters here on nanog with the rest of us ops. i would not be pleased to see ops start to be subsumed by the rir here. randy From vixie at isc.org Sat Jan 8 02:11:13 2011 From: vixie at isc.org (Paul Vixie) Date: Sat, 08 Jan 2011 08:11:13 +0000 Subject: AltDB? In-Reply-To: Your message of "Sat, 08 Jan 2011 15:47:51 +0900." References: <59051.1294464800@nsa.vix.com> Message-ID: <69585.1294474273@nsa.vix.com> > Date: Sat, 08 Jan 2011 15:47:51 +0900 > From: Randy Bush > ... > more recent rumors, and john's posting here, seem to indicate that > ... even to the extent that i know what's really happened or happening, i'd be loathe to comment on rumours. i have high confidence in arin's board and staff, and i believe that the right things are happening, even with the delays. "right things" as in what's best for the community and for the internet industry in the arin service region. as a strong proponent of rpki and of all things like rpki that will strengthen infrastructure, i remain delay-tolerant if review is the cost of getting it right. > first, it would really help if the arin bot and management were much > more open about these issues and decisions. at the detailed level. we > are all not fools out here, present company excepted :). for a radical > example, considering that arin is managing a public resource for the > community, why are bot meetings not streamed a la cspan? can you cite some examples of nonprofit companies whose boards operate at the level of transparency you're asking me to consider in this example? the process of rolling out something like rpki involves some checks and balances, it's no longer just a simple matter of the technical people "doing the right thing" even though i remember older times when that was the way most things on the internet worked. > i do not see how you are going to get rid of the liability. you have it > now in whois/irr if i use it for routing (except they are so widely known > to be bad data that the world knows i would be a fool to bet on them). > whether the source of a roa is a user whacking on an arin web page or by > other means, you still attested to the rights to that address space. my own belief here (not speaking for ARIN or for the ARIN BoT) is that the folks who use IRR/whois data to build route filters have a confidence level much lower than those who will use RPKI to do the same will have. i know that if i still had "enable" on anything other than my home router, that's how i'd feel. also, liability isn't just "got rid of" it's also documented and risk-managed, and doing that may require some kind of internal review. > but all this is based on inference and rumor. can you please be more > open and direct about this? thanks. i don't know. john (speaking for ARIN) gave an excellent and complete answer that i completely agree with. you're repeating some rumours which i won't comment on one way or the other. if you have specific questions which were not answered by john's response or which were raised by john's response you should ask them. saying "i heard a rumour, would anyone care to refute it?" is not going to move the conversational line of scrimmage at all. paul From drc at virtualized.org Sat Jan 8 02:13:34 2011 From: drc at virtualized.org (David Conrad) Date: Fri, 7 Jan 2011 22:13:34 -1000 Subject: arin and ops fora (was: AltDB? RPKI, the universe, and ...) In-Reply-To: References: <59051.1294464800@nsa.vix.com> <00041A16-473F-4F96-93E8-E3CD3F83E1B2@virtualized.org> Message-ID: Randy, On Jan 7, 2011, at 9:31 PM, Randy Bush wrote: > one difference in north america from the other 'regions' is that there > is a strong and very separate operator community and forum. Right. However, it seems to me that this strong separation has led to exactly the problem you raised. The issue, as far as I can tell, is that there are functions and services performed by ARIN that can impact the operational community yet even within the existing ARIN structures, there is no obvious (to me at least) mechanism by which the operational community can voice their concerns/provide input/etc. on these services and functions (excluding address allocation/policy of course). > so i would be perfectly happy if arin discussed operational matters here > on nanog with the rest of us ops. I suspect the ambiguity of "operational matters" (and who defines what that is) and "discussed" will inevitably conspire to make you (and presumably other operators) less than "perfectly happy". > i would not be pleased to see ops start to be subsumed by the rir here. That's a different topic. I'm talking about some mechanism by which ARIN and the operational community can communicate more effectively about the services ARIN provides as a public service. Regards, -drc From randy at psg.com Sat Jan 8 02:14:02 2011 From: randy at psg.com (Randy Bush) Date: Sat, 08 Jan 2011 17:14:02 +0900 Subject: AltDB? In-Reply-To: <69585.1294474273@nsa.vix.com> References: <59051.1294464800@nsa.vix.com> <69585.1294474273@nsa.vix.com> Message-ID: >> first, it would really help if the arin bot and management were much >> more open about these issues and decisions. at the detailed level. we >> are all not fools out here, present company excepted :). for a radical >> example, considering that arin is managing a public resource for the >> community, why are bot meetings not streamed a la cspan? > > can you cite some examples of nonprofit companies whose boards operate at > the level of transparency you're asking me to consider in this > example? fcc From randy at psg.com Sat Jan 8 02:17:17 2011 From: randy at psg.com (Randy Bush) Date: Sat, 08 Jan 2011 17:17:17 +0900 Subject: arin and ops fora (was: AltDB? RPKI, the universe, and ...) In-Reply-To: References: <59051.1294464800@nsa.vix.com> <00041A16-473F-4F96-93E8-E3CD3F83E1B2@virtualized.org> Message-ID: >> one difference in north america from the other 'regions' is that there >> is a strong and very separate operator community and forum. > Right. However, it seems to me that this strong separation has led to > exactly the problem you raised. The issue, as far as I can tell, is > that there are functions and services performed by ARIN that can > impact the operational community yet even within the existing ARIN > structures, there is no obvious (to me at least) mechanism by which > the operational community can voice their concerns/provide input/etc. > on these services and functions (excluding address allocation/policy > of course). i will admit to some carry-over from the ietf's old high and mighty attitude, "we're open, if you want to talk about it, come to our turf." i am happy to say that this has been changing in recent years. randy From vixie at isc.org Sat Jan 8 02:24:00 2011 From: vixie at isc.org (Paul Vixie) Date: Sat, 08 Jan 2011 08:24:00 +0000 Subject: AltDB? In-Reply-To: Your message of "Fri, 07 Jan 2011 21:01:52 -1000." <00041A16-473F-4F96-93E8-E3CD3F83E1B2@virtualized.org> References: <59051.1294464800@nsa.vix.com> <00041A16-473F-4F96-93E8-E3CD3F83E1B2@virtualized.org> Message-ID: <70374.1294475040@nsa.vix.com> > From: David Conrad > Date: Fri, 7 Jan 2011 21:01:52 -1000 > > > do you have a specific proposal? i've noted in the past that arin tries > > hard to stick to its knitting, which is allocation and allocation policy. > > Yes. This is a positive (IMHO), however it seems that occasionally, > ARIN's knitting tangles up folks who don't necessarily involve > themselves with ARIN's existing interaction mechanisms (at least > directly). the price of changing what ARIN does is, at a minimum: participation. > > it seems to me that if some in the community wanted arin to run SIGs > > or WGs on things like routing policy arin could do it but that a lot > > of folks would say that's mission creep and that it would be arin > > poaching on nanog lands. > > The issue I see is that there are non-address allocation{, policy} > topics that can deeply affect network operations in which ARIN has a > direct role, yet network operators (outside of the normal ARIN > participants) have no obvious mechanism in which to > comment/discuss/etc. Examples would include reverse DNS operations, > whois database-related issues (operations, schema, access methods, > etc.), (potentially?) RPKI, etc. It doesn't seem appropriate to me > for these to be discussed in relation to addressing policy nor are the > issues associated with those examples necessarily related to address > allocation, hence I wouldn't think they'd be fodder for ppml. they are, though. i understand the subtlety of the question, "is that a policy matter?" but discussions on ppml@ have led to determinations of "what is lameness?" and "when is a nameserver so lame that it's better to remove it from in-addr than to leave it in?" i hear in what you're saying a desire to have a way to impact ARIN's behaviour outside of NRPM edits and perhaps ARIN does need to address this with some new online forum for things which aren't allocation policy but which should still be decided using community input. (as i recall my first act as a new ARIN trustee was to sign onto a policy proposal that would have changed the way e-mail templates worked, and at the end of the process the ARIN BoT shot it down because it wasn't a policy, and i understood that decision. strange, eh?) > ... > > So, in other words, no, I don't really have a specific proposal. perhaps others will chime in. i will continue to think about it also. From randy at psg.com Sat Jan 8 03:08:12 2011 From: randy at psg.com (Randy Bush) Date: Sat, 08 Jan 2011 18:08:12 +0900 Subject: AltDB? In-Reply-To: <70374.1294475040@nsa.vix.com> References: <59051.1294464800@nsa.vix.com> <00041A16-473F-4F96-93E8-E3CD3F83E1B2@virtualized.org> <70374.1294475040@nsa.vix.com> Message-ID: > the price of changing what ARIN does is, at a minimum: participation. aha! there we go. the old ietf attitude. you come to the mountain. well, i'll tell you what i told the ietf. the high and mighty mountain can bite my ass. randy From drc at virtualized.org Sat Jan 8 03:11:32 2011 From: drc at virtualized.org (David Conrad) Date: Fri, 7 Jan 2011 23:11:32 -1000 Subject: AltDB? In-Reply-To: <70374.1294475040@nsa.vix.com> References: <59051.1294464800@nsa.vix.com> <00041A16-473F-4F96-93E8-E3CD3F83E1B2@virtualized.org> <70374.1294475040@nsa.vix.com> Message-ID: Paul, On Jan 7, 2011, at 10:24 PM, Paul Vixie wrote: > the price of changing what ARIN does is, at a minimum: participation. Another view is that ARIN's whole and sole reason for being is to provide services to the network operators in the ARIN region. As such, it would be ill-advised for ARIN to change those services without consulting the community that ARIN serves and getting their buy-in. Hopefully, there's a middle ground. > i hear in what you're saying > a desire to have a way to impact ARIN's behaviour outside of NRPM edits > and perhaps ARIN does need to address this with some new online forum for > things which aren't allocation policy but which should still be decided > using community input. Yep. Not sure it should be an ARIN-operated thing (nor am I sure that it shouldn't be), but something a bit more focused on the operation of services ARIN provides than ppml might be helpful. Regards, -drc From randy at psg.com Sat Jan 8 03:17:55 2011 From: randy at psg.com (Randy Bush) Date: Sat, 08 Jan 2011 18:17:55 +0900 Subject: AltDB? In-Reply-To: References: <59051.1294464800@nsa.vix.com> <00041A16-473F-4F96-93E8-E3CD3F83E1B2@virtualized.org> <70374.1294475040@nsa.vix.com> Message-ID: >> the price of changing what ARIN does is, at a minimum: participation. > aha! there we go. the old ietf attitude. you come to the mountain. > well, i'll tell you what i told the ietf. the high and mighty mountain > can bite my ass. let me be a bit more clear on this o you affect the operational community, you talk with (not to) the operational community where the operational community talks o i have given a lot of blood to arin, far more than it deserved. so do not tell me i need to give more. o eighteen months or so ago, a gang of big arin folk guilt-tripped me into running for the board (which i founded back in '96-'97). i did the nomcom form and all that, AND WAS SILENTLY NOT ALLOWED ON THE BALLOT. never given notice or reason. so take your high and mighty open participation crap and shove it where the sun don't shine. but i sure was relieved, to tell the truth. my mental and physical health just don't need the arin vigilante high and mighty crap on a daily basis. randy From leen at consolejunkie.net Sat Jan 8 05:16:40 2011 From: leen at consolejunkie.net (Leen Besselink) Date: Sat, 08 Jan 2011 12:16:40 +0100 Subject: Problems with removing NAT from a network In-Reply-To: <4D268119.2050205@matthew.at> References: <4D252B1F.8030506@kenweb.org> <3DFD6833-78C1-43D2-8074-6C89CFE3F2F3@arbor.net> <20110106043110.21C96876D21@drugs.dv.isc.org> <4D254ED8.6030006@matthew.at> <4D25F971.4090709@matthew.at> <4D2634E7.2060502@matthew.at> <9DEED87C-ED15-4D05-BCD6-69A5D4A69681@delong.com> <4D267B9E.8040602@bogus.com> <4D268119.2050205@matthew.at> Message-ID: <4D284798.3010806@consolejunkie.net> On 01/07/2011 03:57 AM, Matthew Kaufman wrote: > On 1/6/2011 6:34 PM, Joel Jaeggli wrote: >> On 1/6/11 5:48 PM, Owen DeLong wrote: >>> Doesn't all of this become moot if Skype just develops a dual-stack >>> capable client >>> and servers? >> Really, only some fraction of the supernodes and the login servers need >> to be dual stack. >> > Without revealing too much about the architecture, I can tell you that > it would need to be a significant fraction of the supernodes (due to > how node-supernode mapping works in these types of P2P systems), the > relay nodes (not mentioned) *and* the login servers. Not all of which > are deployed and controlled by Skype, of course, as recent press about > the most recent outage has reiterated for those who didn't know. > > Matthew Kaufman > > Hello Mr. Kaufman, In the upcoming years, we will have no IPv6 in some places and badly performing IPv4 (CGN, etc.) with working IPv6 in others. If I was Skype I would make really sure that all my relay nodes and login servers have IPv6 with enough bandwidth or can easily upgrade the bandwidth where neede. And make sure atleast IPv6-client and IPv6-servers communication works everywhere where there is IPv6. Atleast get your servers and network ready with IPv6. Tell your suppliers that if they don't have IPv6 by 'deadline' (you decide) you will (have to) go somewhere else. Because if you still have to deploy, test and fix IPv6 to your servers when it turns out the transition workarounds you have created in software don't work as well as you hoped then you will have a real problem on your hands. For your customers it is really easy. When Skype does not work, people will jump ship where they can and maybe use Google Talk or whatever. I hear they also have a similair service like SkypeOut ? Judging by the amount of effort Google put in to making sure their network supports IPv6, I wouldn't be surprised if Google Talk 'just works'. They might even start including it with Google TV. I suggest making sure you include both IPv4 and IPv6 addresses in your protocol, maybe it needs to be extended. So that the client at the other end can choose what IP-version to use. Or can try both. Maybe the login-server can help to decide for the client. But those login servers will need to have good IPv6 connectivity to be able to do so. If you don't do these 2 things (maybe you already have I don't know) you might find that your business will suffer. I'm sorry if it sounds a bit like fear mongering, but to me it sounds like common sense that if a business is not prepared when the environment that business operates in changes and that business does not adapt to the changes in time that business might suffer. Have a nice weekend, Leen. From simon.leinen at switch.ch Sat Jan 8 05:41:07 2011 From: simon.leinen at switch.ch (Simon Leinen) Date: Sat, 08 Jan 2011 12:41:07 +0100 Subject: arin and ops fora In-Reply-To: (Randy Bush's message of "Sat, 08 Jan 2011 16:31:26 +0900") References: <59051.1294464800@nsa.vix.com> <00041A16-473F-4F96-93E8-E3CD3F83E1B2@virtualized.org> Message-ID: Randy Bush writes: > one difference in north america from the other 'regions' is that there > is a strong and very separate operator community and forum. this does > not really exist in the other regions. ripe ate the eof years ago. > apops is dormant aside from [...] Right. > observe that the main north american irr, radb, is not run by the rir, > unlike in other regions. and i like that there are a number of > diverse rir services in the region. it's healthy. ^^^ you mean "rr" I think. > so i would be perfectly happy if arin discussed operational matters > here on nanog with the rest of us ops. i would not be pleased to see > ops start to be subsumed by the rir here. I'm sympathetic with that, but, like David said, the separation (NANOG/ARIN) you have in North America does lead to issues such as not being able to trust what's in the RR(s). So I'm quite happy with the situation here in Europe, where RIPE (deliberately ignoring the difference between RIPE NCC and the RIPE community for a second) takes care of both running the address registry, and running a routing registry that can leverage the same authentication/authorization substrate. This makes the RR much more trustworthy, and should really make the introduction of something like RPKI much easier (albeit with the temptation to set it up in a more centralized way than we might like). Randy, what is the model you have in mind for running a routing registry infrastructure that is sustainable and trustworthy enough for uses such as RPKI, i.e. who could/should be running it? I guess I'm arguing that from my non-North-American perspective, an ARIN with a carefully extended mandate could be of much help here. So even if you're unhappy with the current ARIN governance, maybe it would still be worthwhile for the community to fix that issue - unless there are credible alternatives. -- Simon. From randy at psg.com Sat Jan 8 07:54:28 2011 From: randy at psg.com (Randy Bush) Date: Sat, 08 Jan 2011 22:54:28 +0900 Subject: arin and ops fora In-Reply-To: References: <59051.1294464800@nsa.vix.com> <00041A16-473F-4F96-93E8-E3CD3F83E1B2@virtualized.org> Message-ID: [ vix, apologies for giving you both barrels. you unintentionally pushed a hot button or two ] > Randy, what is the model you have in mind for running a routing > registry infrastructure that is sustainable and trustworthy enough for > uses such as RPKI, i.e. who could/should be running it? the pki wg sat with their thumbs up their nether sides for a decade instead of working on a trust topology that mapped something a bit more operationally realistic than x.500. so all we have is a hierarchic trust model. luckily, that matches the topology of the resources we are tracking, ip address space and asns. like ipv6, we're not going to go back a few decades and change either the allocation topology (iana->{rirs+legacy}->...->...) or x.509. [ and yes, i have put some time into thinking about hacking a pgp-based solution. probably i am just not smart enough. but i asked a bunch of folk smarter than i (target rich environment, i know), and did not find optimism. ] so whether we like it or not, the rpki underlies formally verifiable routing security. it's all we have. and i care a real lot about formally verifiable routing security. a real lot. so this is why i am so deeply concerned about the iana and the rirs' actions, policies, engineering, operations, ... on this stuff. we are married to them whether either side likes it or not, at least until the youngest kid leaves for uni or gets a job. > I guess I'm arguing that from my non-North-American perspective, an > ARIN with a carefully extended mandate could be of much help here. So > even if you're unhappy with the current ARIN governance, maybe it > would still be worthwhile for the community to fix that issue - unless > there are credible alternatives. i do not see much alternative. maybe if we could pry the iana away from the domainer slime and the usg and maybe move it to iceland, it could allocate directly and we could dump the regional address cartel. but it it not likely. so we as the ops community need to work to make the iana/rir system, pretty much as it is today, do the rpki deployment in a manner we can trust and with which we can be comfortable. randy From lee at asgard.org Sat Jan 8 08:23:01 2011 From: lee at asgard.org (Lee Howard) Date: Sat, 8 Jan 2011 09:23:01 -0500 Subject: AltDB? In-Reply-To: References: <59051.1294464800@nsa.vix.com> Message-ID: <000001cbaf3f$8edf7240$ac9e56c0$@org> > example, considering that arin is managing a public resource for the > community, why are bot meetings not streamed a la cspan? Having watched Congress on CSPAN, and heard reports about open ICANN Board meetings, it looks to me like making deliberative meetings public means nothing substantive happens during meetings. People get afraid to say anything that might make them look ignorant, and just make prepared speeches. All decisions are made ahead of time through private negotiations, which ends up being the opposite of transparency. I think ARIN's Board's output is better than Congress. > i do not see how you are going to get rid of the liability. Looking at the ARIN Board minutes of https://www.arin.net/about_us/bot/bot2010_1006.html and https://www.arin.net/about_us/bot/bot2010_1122.html it looks like the Board is requesting a more detailed liability assessment. Well-informed decisions are more likely to be good than the other kind. Lee From lee at asgard.org Sat Jan 8 08:40:48 2011 From: lee at asgard.org (Lee Howard) Date: Sat, 8 Jan 2011 09:40:48 -0500 Subject: AltDB? In-Reply-To: <734B46C1-AE6C-406A-8163-00CFFE942B1B@virtualized.org> References: <94F3F129-608E-46EC-B157-CC23CAA47454@tozz.net> <4D24A734.3000807@jcoley.net> <816AB912-14CF-4028-853A-F0BE77D2EB09@puck.nether.net> <734B46C1-AE6C-406A-8163-00CFFE942B1B@virtualized.org> Message-ID: <000101cbaf42$0a65d7e0$1f3187a0$@org> > -----Original Message----- > From: David Conrad [mailto:drc at virtualized.org] > > The definition of what comes under the "public policy mailing list" umbrella has always been > a bit confusing to me. Too bad something like the APNIC SIGs and RIPE Working Groups > don't really exist in the ARIN region. I think that's a bit of what we've been trying to do with the Best Current Operational Practices BoFs. We need a place where operators can discuss and document BCOPs. Lee From bonomi at mail.r-bonomi.com Sat Jan 8 10:19:04 2011 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Sat, 8 Jan 2011 10:19:04 -0600 (CST) Subject: asymmetric routes/security concerns/Fortinet In-Reply-To: Message-ID: <201101081619.p08GJ4Bo083937@mail.r-bonomi.com> From astrosm at gmail.com Sat Jan 8 10:20:57 2011 From: astrosm at gmail.com (Sandra Munoz) Date: Sat, 8 Jan 2011 11:20:57 -0500 Subject: For posting Message-ID: My email: astrosm at gmail.com From vixie at isc.org Sat Jan 8 10:57:25 2011 From: vixie at isc.org (Paul Vixie) Date: Sat, 08 Jan 2011 16:57:25 +0000 Subject: AltDB? In-Reply-To: Your message of "Fri, 07 Jan 2011 23:11:32 -1000." References: <59051.1294464800@nsa.vix.com> <00041A16-473F-4F96-93E8-E3CD3F83E1B2@virtualized.org> <70374.1294475040@nsa.vix.com> Message-ID: <4207.1294505845@nsa.vix.com> > From: David Conrad > Date: Fri, 7 Jan 2011 23:11:32 -1000 > > On Jan 7, 2011, at 10:24 PM, Paul Vixie wrote: > > the price of changing what ARIN does is, at a minimum: participation. > > Another view is that ARIN's whole and sole reason for being is to > provide services to the network operators in the ARIN region. yes. > As such, it would be ill-advised for ARIN to change those services > without consulting the community that ARIN serves and getting their > buy-in. that's very much what i mean by participation. arin could never exist without a community to serve. if there are better ways to serve the community or better ways for the community to participate in steering arin's services, then i'm very interested in discovering them. > Hopefully, there's a middle ground. this *is* the middle ground. we're beyond the span of decades when a couple of smart engineers could bang out a working solution that the rest of the community would just adopt out of opportunity and inertia. and let's not just blame-the-lawyers for that. the stakeholders in the infrastructure of the information economy now number in the 'many' and their views and needs have to be represented in the decisions that get made by places like ICANN, IETF, the RIRs, and similar. > > i hear in what you're saying a desire to have a way to impact ARIN's > > behaviour outside of NRPM edits and perhaps ARIN does need to address > > this with some new online forum for things which aren't allocation > > policy but which should still be decided using community input. > > Yep. Not sure it should be an ARIN-operated thing (nor am I sure that > it shouldn't be), but something a bit more focused on the operation of > services ARIN provides than ppml might be helpful. count me as 'intrigued' and expect me to be thinking more about this. From sam_mailinglists at spacething.org Sat Jan 8 11:11:23 2011 From: sam_mailinglists at spacething.org (Sam Stickland) Date: Sat, 8 Jan 2011 17:11:23 +0000 Subject: IPv6 - real vs theoretical problems In-Reply-To: <8D806878-5D6E-4ABB-BDD9-9E6A58F33D77@arbor.net> References: <4D269D77.4080309@jima.tk> <10FB3518-6470-4F14-963C-B3150FABE667@delong.com> <442E296F-A5DD-4BE0-AE42-BA02E49F5F4D@arbor.net> <8D806878-5D6E-4ABB-BDD9-9E6A58F33D77@arbor.net> Message-ID: On Sat, Jan 8, 2011 at 2:00 AM, Dobbins, Roland wrote: > > > If it's inappropriately placed in front of servers, where's there's no > state to inspect and were the stateful nature of the device in and of itself > forms a DoS vector, it has negative security value; i.e., it makes things > far worse. Roland, I'm missing something here. Why do you say there is zero state at the server, but the not at the client? (Because of all the servers TCP/UDP ports are well known perhaps?) Sam From vixie at isc.org Sat Jan 8 11:13:59 2011 From: vixie at isc.org (Paul Vixie) Date: Sat, 08 Jan 2011 17:13:59 +0000 Subject: AltDB? In-Reply-To: Your message of "Sat, 08 Jan 2011 18:17:55 +0900." References: <59051.1294464800@nsa.vix.com> <00041A16-473F-4F96-93E8-E3CD3F83E1B2@virtualized.org> <70374.1294475040@nsa.vix.com> Message-ID: <5336.1294506839@nsa.vix.com> > Date: Sat, 08 Jan 2011 18:17:55 +0900 > From: Randy Bush > > let me be a bit more clear on this thanks. > o you affect the operational community, you talk with (not to) the > operational community where the operational community talks i think arin does this today. certainly that is the intent. on the other fork of this thread, drc has noted some ways that this engagement area can be further improved, and i have counted myself as intrigued. also, i neglected to mention in my earlier notes on this thread that in addition to public policy meetings and the public policy mailing list which are open to the entire community not just arin members and which allow for remote participation not just those who can travel, arin has a consultation and suggestion process (URL below). i urge all operators and interested parties of the operational community to consider sharing their perspectives and their wisdom with arin to guide it going forward. ARIN Consultation and Suggestion Process: https://www.arin.net/participate/acsp/index.html ARIN Public Policy Mailing List: http://lists.arin.net/mailman/listinfo/arin-ppml Meetings: https://www.arin.net/participate/meetings/index.html https://www.arin.net/participate/meetings/reports/ARIN_XXVI/index.html https://www.arin.net/participate/meetings/ARIN-XXVI/remote.html https://www.arin.net/participate/meetings/ARIN-XXVII/index.html https://www.arin.net/participate/meetings/ARIN-XXVIII/index.html Fellowships: https://www.arin.net/participate/meetings/fellowship.html Scholarships: https://www.arin.net/participate/meetings/scholarships.html From bonomi at mail.r-bonomi.com Sat Jan 8 11:39:12 2011 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Sat, 8 Jan 2011 11:39:12 -0600 (CST) Subject: AltDB? In-Reply-To: Message-ID: <201101081739.p08HdCMR084335@mail.r-bonomi.com> > Date: Sat, 08 Jan 2011 18:08:12 +0900 > From: Randy Bush > Subject: Re: AltDB? > > > aha! there we go. the old ietf attitude. you come to the mountain. > > well, i'll tell you what i told the ietf. the high and mighty mountain > can bite my ass. Let me see if I've got this right -- you think ARIN should change their policies, but _you_ are not willing to put in any personal effort to make it happen, right? Can you think of any good reason why _any_ organization should care about the opinions of someone with that attitude? From jlewis at lewis.org Sat Jan 8 12:10:47 2011 From: jlewis at lewis.org (Jon Lewis) Date: Sat, 8 Jan 2011 13:10:47 -0500 (EST) Subject: AltDB? In-Reply-To: <5336.1294506839@nsa.vix.com> References: <59051.1294464800@nsa.vix.com> <00041A16-473F-4F96-93E8-E3CD3F83E1B2@virtualized.org> <70374.1294475040@nsa.vix.com> <5336.1294506839@nsa.vix.com> Message-ID: Getting back to the original topic...sort of: Looking at the data from altdb, it's not as widely used as I'd have guessed. There are 461 mntner objects. Of these, 268 use MAIL-FROM authentication. 192 use CRYPT-PW. At least those are the split if you look at just the first auth: for each mntner object...plenty of objects have multiple auth:'s and some even have multiple types like MAIL-FROM and PGP. In such a case, does a change request have to satisfy both auth's or just either one? This makes me ask two questions. 1) Why did ARIN even bother setting up rr.arin.net with no authentication other than MAIL-FROM? Even CRYPT-PW, while weak would be far stronger and preferable to effectively no authentication. 2) Why does altdb (and presumably other RR's that support CRYPT-PW) only support DES and not MD5-crypt? It's not 1990 anymore. RFC 2622 says that CRYPT-PW uses the UNIX crypt format...but today, UNIX crypt supports a variety of formats, including MD5, which is popular at least with Linux. I don't mean to whine that altdb doesn't support MD5...it'd be nice if it did, but at the price I'm paying for service ($0), I can't complain. AFAIK, few networks base their BGP filters on the RR data, so I don't care too much about RPKI[1]. Who cares if ARIN certifies that my entries are legit if only a fraction of the net uses that data and there will always be portions of the net where anything goes and resource certification is ignored? What I do care about is that my peers or transits that use RR data to build filters use the data I put there, and that that data isn't tampered with by anyone with the minimal level of clue required to forge the from address on an email and construct an RPSL update email. Sure, we'd get email notification of the change...but if they time it right or the email doesn't get acted on quickly enough, filters might be built improperly. [1] Don't care is probably too strong. At this point in time, I don't think it makes sense to get hung up on it and refuse to do any authentication if we're not doing RPKI, but not implement RPKI, because we haven't worked out all the details on how it'll be done. As it is, rr.arin.net is pretty much worthless. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From tariq198487 at hotmail.com Sat Jan 8 13:01:00 2011 From: tariq198487 at hotmail.com (Tarig Ahmed) Date: Sat, 8 Jan 2011 22:01:00 +0300 Subject: asymmetric routes/security concerns/Fortinet In-Reply-To: References: Message-ID: Tarig Yassin Ahmed On Jan 7, 2011, at 10:45 PM, Anthony Pardini wrote: > You can allow asymmetric traffic on the Fortinet, but you lose some > functionality. Firewalls aren't routers and pretty much all of them > behave in the similar manner. > Hi I think u can solve this issue only by adding router between the firewall and the Internet. in multihoming metwork, Internet connections should be connect to routers then afterthat come the the firewall to avoid such problems. Thanks > On Fri, Jan 7, 2011 at 11:40 AM, Greg Whynott > wrote: >> >> >> Hello, >> >> we have multiple internet connections of which one is a research >> network where many medical institutions and universities are also >> connected to threw out the country. This research network (ORION) >> also has internet access but is not meant to be used as a primary >> path to the internet by its customers. Connected to the ORION >> network are many sites we exchange email with daily who also have >> multiple internet connections. One of these sites is not >> reachable by us. After investigating, it was discovered this >> site is dropping our connections as the path back to use would use >> a different interface on the firewall ( a Fortinet device) than >> that which it arrived upon. >> >> The admins at this university claim this is by design and for >> security reasons.. My response was the entire internet is >> asymmetrical and while this may of been a legitimate concern in the >> 90's, I don't think its a real concern anymore if things are set >> up correctly. They suggested we add static routes to our equipment >> to address this? This seems like a bad idea and I am not comforta >> ble adjusting my routing table to address one site's issues on the >> internet due to their (not ours) routing/security policies. >> >> am I correct here? any comments on this would be greatly >> appreciated as I'll be called into a meeting to discuss this >> further (they are digging in their heals in on this, and higher >> ups are getting involved now). I'd like to arm myself with a few >> perspectives. >> >> thanks very much for your time again, >> >> greg >> >> >> >> >> >> -- >> >> This message and any attachments may contain confidential and/or >> privileged information for the sole use of the intended recipient. >> Any review or distribution by anyone other than the person for whom >> it was originally intended is strictly prohibited. If you have >> received this message in error, please contact the sender and >> delete all copies. Opinions, conclusions or other information >> contained in this message may not be that of the organization. >> >> > > From morrowc.lists at gmail.com Sat Jan 8 13:47:47 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 8 Jan 2011 14:47:47 -0500 Subject: AltDB? In-Reply-To: References: <59051.1294464800@nsa.vix.com> <00041A16-473F-4F96-93E8-E3CD3F83E1B2@virtualized.org> <70374.1294475040@nsa.vix.com> <5336.1294506839@nsa.vix.com> Message-ID: On Sat, Jan 8, 2011 at 1:10 PM, Jon Lewis wrote: > Getting back to the original topic...sort of: thanks! > [1] Don't care is probably too strong. ?At this point in time, I don't think > it makes sense to get hung up on it and refuse to do any authentication if > we're not doing RPKI, but not implement RPKI, because we haven't worked out > all the details on how it'll be done. ?As it is, rr.arin.net is pretty much > worthless. I don't think rr.arin.net and RPKI have anything to do with each other. I think the direction the RPKI should/is taking is to have the RIR sign a ROA to the ORG that they allocate the address space to... Similarly the ORG (if they are an N|LIR-type) will sign a ROA to the ORG that they assign address space to. Ideally you should be able to ask the RPKI system: "I have 1.2.3.0/24 in a bgp announcement, origin'd by AS1234. Is that proper?" Ideally that magic doesn't happen on the "router" but a digested form of the data is available making much of the heavy-lifting not router-based. The parts of the puzzle here that ARIN (or really any RIR) is responsible for are the 'signing roas to allocatees' (the "up/down protocol" as it's referred to in the drafts - and potentially having a system which permits end-users/ORGs to enter data which generates ROA data (and sends that along to some publication point for the rest of the routing world to download/digest). I believe the 'up/down protocol' part here is critical, the "web server" part ... I'm not sure is so critical, maybe a third party makes that happen outside of the ARIN management chain? Using someone not yourself (ARIN or another third party) to manage your ROA data means you probably have (in the most simple case) given the ability to that third party to sign objects for you, that means they have your private key(s) and can break you by mistake/malfeasance/oversight/etc. For this reason some folks may be ok with using a third party, many will choose to hold their fate in their own hands. -Chris From morrowc.lists at gmail.com Sat Jan 8 14:03:43 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 8 Jan 2011 15:03:43 -0500 Subject: AltDB? In-Reply-To: <005EFE15-AC57-491E-BB9E-3C44A6CD2C42@unitedlayer.com> References: <59051.1294464800@nsa.vix.com> <00041A16-473F-4F96-93E8-E3CD3F83E1B2@virtualized.org> <70374.1294475040@nsa.vix.com> <5336.1294506839@nsa.vix.com> <005EFE15-AC57-491E-BB9E-3C44A6CD2C42@unitedlayer.com> Message-ID: On Sat, Jan 8, 2011 at 2:58 PM, Abhijit Phanse wrote: > Could you please remove all @unitedlayer.com addresses from this > distribution. > > Thanks in advance. I think you mean to ask this of nanog-admin ... though honestly @unitedlayer.com folks CAN request that themselves (with the associated mailman data in the message headers) -chris From drc at virtualized.org Sat Jan 8 15:15:46 2011 From: drc at virtualized.org (David Conrad) Date: Sat, 8 Jan 2011 11:15:46 -1000 Subject: arin and ops fora (was Re: AltDB?) In-Reply-To: <000101cbaf42$0a65d7e0$1f3187a0$@org> References: <94F3F129-608E-46EC-B157-CC23CAA47454@tozz.net> <4D24A734.3000807@jcoley.net> <816AB912-14CF-4028-853A-F0BE77D2EB09@puck.nether.net> <734B46C1-AE6C-406A-8163-00CFFE942B1B@virtualized.org> <000101cbaf42$0a65d7e0$1f3187a0$@org> Message-ID: <55EF24AC-DFFC-4A84-B828-693F0A1864A9@virtualized.org> Lee, On Jan 8, 2011, at 4:40 AM, Lee Howard wrote: > I think that's a bit of what we've been trying to do with the Best Current Operational Practices BoFs. We need a place where operators can discuss and document BCOPs. While I think BCOPs (and BCOP BoFs) are a great idea, I guess the question is how can folks be assured that ARIN would follow a NANOG community-defined BCOP relating directly to ARIN operations. For example, if the NANOG community were to (reasonably) say "BCOP is to use IETF-defined standards for publishing and accessing resource registration data", I'd imagine ARIN might (reasonably) disagree and continue down the RWS path. I suspect part of the issue is that ARIN is a monopoly provider of a variety public services that folks unrelated (directly) to ARIN must make use of. In other areas of public service provision, there are things like public utilities commissions that (in theory) ensure the monopoly service provider acts in the public benefit when services are added/changed/deleted. My impression is that the various WGs and SIGs in the other RIRs perform something similar to that function. There doesn't appear to be anything similar in the ARIN region. Regards, -drc From randy at psg.com Sat Jan 8 15:22:01 2011 From: randy at psg.com (Randy Bush) Date: Sun, 09 Jan 2011 06:22:01 +0900 Subject: how the rpki works In-Reply-To: References: <59051.1294464800@nsa.vix.com> <00041A16-473F-4F96-93E8-E3CD3F83E1B2@virtualized.org> <70374.1294475040@nsa.vix.com> <5336.1294506839@nsa.vix.com> Message-ID: [ and 06:00 here so i am probably also making critical errors ] > I don't think rr.arin.net and RPKI have anything to do with each > other. I think the direction the RPKI should/is taking is to have the > RIR sign a ROA to the ORG that they allocate the address space to... s/ROA/resource certificate/ > Similarly the ORG (if they are an N|LIR-type) will sign a ROA to the > ORG that they assign address space to. idem it is only when you get down to someone who has [a piece of] that allocation they wish to announce into bgp that they acually cause a ROA to be issued which may be validated using the cert chain. > The parts of the puzzle here that ARIN (or really any RIR) is > responsible for are the 'signing roas to allocatees' (the "up/down > protocol" as it's referred to in the drafts s/roas/certificates/ > I believe the 'up/down protocol' part here is critical, the "web > server" part ... I'm not sure is so critical, maybe a third party > makes that happen outside of the ARIN management chain? this is easily done with the rpki, up/down, publication, ... architecture. > Using someone not yourself (ARIN or another third party) to manage > your ROA data means you probably have (in the most simple case) given > the ability to that third party to sign objects for you, that means > they have your private key(s) and can break you by > mistake/malfeasance/oversight/etc. For this reason some folks may be > ok with using a third party, many will choose to hold their fate in > their own hands. exactly. but only if the parent runs the up/down ('provisioning') protocol, does the child have that choice. randy From randy at psg.com Sat Jan 8 15:25:33 2011 From: randy at psg.com (Randy Bush) Date: Sun, 09 Jan 2011 06:25:33 +0900 Subject: AltDB? In-Reply-To: <201101081739.p08HdCMR084335@mail.r-bonomi.com> References: <201101081739.p08HdCMR084335@mail.r-bonomi.com> Message-ID: > Let me see if I've got this right -- you think ARIN should change their > policies, but _you_ are not willing to put in any personal effort to make > it happen, right? i not put in personal effort? you're kidding or really new here, right? one underlying problem with the RIRs, ICANN, ... is that once we form these organizations, they start thinking like organizations, protect themselves, look to budgets, look to liability, .... welcome to real life. but these realistic organizational things sometimes actually have conflict with the original goals. randy From randy at psg.com Sat Jan 8 15:35:19 2011 From: randy at psg.com (Randy Bush) Date: Sun, 09 Jan 2011 06:35:19 +0900 Subject: arin and ops fora (was Re: AltDB?) In-Reply-To: <55EF24AC-DFFC-4A84-B828-693F0A1864A9@virtualized.org> References: <94F3F129-608E-46EC-B157-CC23CAA47454@tozz.net> <4D24A734.3000807@jcoley.net> <816AB912-14CF-4028-853A-F0BE77D2EB09@puck.nether.net> <734B46C1-AE6C-406A-8163-00CFFE942B1B@virtualized.org> <000101cbaf42$0a65d7e0$1f3187a0$@org> <55EF24AC-DFFC-4A84-B828-693F0A1864A9@virtualized.org> Message-ID: > I suspect part of the issue is that ARIN is a monopoly provider of a > variety public services that folks unrelated (directly) to ARIN must > make use of. In other areas of public service provision, there are > things like public utilities commissions that (in theory) ensure the > monopoly service provider acts in the public benefit when services are > added/changed/deleted. My impression is that the various WGs and SIGs > in the other RIRs perform something similar to that function. There > doesn't appear to be anything similar in the ARIN region. having worked closely with a number of other RIRs, sad to say that a lot still goes on under the table [0]. hence my cspan analogy, shed some light in the corners. the community should be transparent before wikileaks gets to us. :) randy -- [0] - an old sardonic comment of mine on ripe is that it is a bottom up organization, and daniel and rob are at the bottom. and wear thick rubber/leather gloves when entering apnic. From drc at virtualized.org Sat Jan 8 15:41:42 2011 From: drc at virtualized.org (David Conrad) Date: Sat, 8 Jan 2011 11:41:42 -1000 Subject: AltDB? In-Reply-To: <201101081739.p08HdCMR084335@mail.r-bonomi.com> References: <201101081739.p08HdCMR084335@mail.r-bonomi.com> Message-ID: <334092B6-63F1-4E1D-9E55-67EEAC31996C@virtualized.org> On Jan 8, 2011, at 7:39 AM, Robert Bonomi wrote: > Let me see if I've got this right -- you think ARIN should change their > policies, Not policies. Operations. Or rather, how ARIN communicates and obtains buy-in from the operational community regarding operations that affect that community. > but _you_ are not willing to put in any personal effort to make > it happen, right? Not to speak for Randy, but I believe he is suggesting the onus is on ARIN to engage the community their activities impact, rather than the community engaging ARIN. > Can you think of any good reason why _any_ organization should care about > the opinions of someone with that attitude? Liability? Folks don't have an option regarding where they get some of the services. An (imperfect) analogy: in the SF bay area, the monopoly provider of pipeline natural gas, PG&E, appears to have made the operational decision to cut costs in inspecting high risk gas lines and not upgrade those pipelines (despite receiving permission from the CA PUC to bill ratepayers for the upgrade). Pragmatically speaking, the vast majority of folks affected by the operation of those pipelines most likely had no interest in making a personal effort to ensure PG&E does what they say they'll do. In Sept 2009, one of those high risk pipelines exploded. I imagine PG&E now cares a great deal about the folks who were affected as you can probably already hear the class action lawsuit lawyers revving their engines. Regards, -drc From frnkblk at iname.com Sat Jan 8 17:22:06 2011 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 8 Jan 2011 17:22:06 -0600 Subject: Problems with removing NAT from a network In-Reply-To: <4D268097.6050502@matthew.at> References: <4D252B1F.8030506@kenweb.org> <3DFD6833-78C1-43D2-8074-6C89CFE3F2F3@arbor.net> <20110106043110.21C96876D21@drugs.dv.isc.org> <4D254ED8.6030006@matthew.at> <4D25F971.4090709@matthew.at> <4D2634E7.2060502@matthew.at> <9DEED87C-ED15-4D05-BCD6-69A5D4A69681@delong.com> <4D268097.6050502@matthew.at> Message-ID: <000101cbaf8a$dd300310$97900930$@iname.com> Relay nodes are always protecting themselves by rate-limiting, aren't they? And isn't most media traffic relayed? I'm not seeing how the NAT64 scenario would *dramatically* increase Skype's global relay traffic. NAT64 would currently be a very small percentage of all Skype traffic. We can always find examples of where things will break with v6. While the v6-only world is still very small, let's *start* somewhere, where intelligent clients like Skype can always "fall back" to v4. Lots of time to figure out the corner cases. Frank -----Original Message----- From: Matthew Kaufman [mailto:matthew at matthew.at] Sent: Thursday, January 06, 2011 8:55 PM To: Owen DeLong Cc: Nanog Operators' Group Subject: Re: Problems with removing NAT from a network On 1/6/2011 5:48 PM, Owen DeLong wrote: > Doesn't all of this become moot if Skype just develops a dual-stack capable client > and servers? > Skype can still make this work by relaying, but in order to protect the relay machine's bandwidth it will rate-limit the traffic, and so your A/V experience will suffer. And that's assuming there's enough dual-stacked relays... if there aren't, it won't be possible to find a relay that they can reach over IPv4 and you can reach over IPv6 that has available bandwidth. Matthew Kaufman From frnkblk at iname.com Sat Jan 8 17:22:16 2011 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 8 Jan 2011 17:22:16 -0600 Subject: Problems with removing NAT from a network In-Reply-To: <4D268119.2050205@matthew.at> References: <4D252B1F.8030506@kenweb.org> <3DFD6833-78C1-43D2-8074-6C89CFE3F2F3@arbor.net> <20110106043110.21C96876D21@drugs.dv.isc.org> <4D254ED8.6030006@matthew.at> <4D25F971.4090709@matthew.at> <4D2634E7.2060502@matthew.at> <9DEED87C-ED15-4D05-BCD6-69A5D4A69681@delong.com> <4D267B9E.8040602@bogus.com> <4D268119.2050205@matthew.at> Message-ID: <000201cbaf8a$e3a99300$aafcb900$@iname.com> Maybe HE would volunteer to host some Skype servers at their various POPS for this purpose. Skype has to start somewhere. While the v6-only population is still very small, why not dual-stack the clients now with a heavily weighted preference towards v4, track and understand the volume and capabilities of v6, and slowly de-preference v4 over time? Frank -----Original Message----- From: Matthew Kaufman [mailto:matthew at matthew.at] Sent: Thursday, January 06, 2011 8:57 PM To: Joel Jaeggli Cc: Nanog Operators' Group Subject: Re: Problems with removing NAT from a network On 1/6/2011 6:34 PM, Joel Jaeggli wrote: > On 1/6/11 5:48 PM, Owen DeLong wrote: >> Doesn't all of this become moot if Skype just develops a dual-stack capable client >> and servers? > Really, only some fraction of the supernodes and the login servers need > to be dual stack. > Without revealing too much about the architecture, I can tell you that it would need to be a significant fraction of the supernodes (due to how node-supernode mapping works in these types of P2P systems), the relay nodes (not mentioned) *and* the login servers. Not all of which are deployed and controlled by Skype, of course, as recent press about the most recent outage has reiterated for those who didn't know. Matthew Kaufman From jsw at inconcepts.biz Sat Jan 8 18:12:38 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Sat, 8 Jan 2011 19:12:38 -0500 Subject: AltDB? In-Reply-To: References: <59051.1294464800@nsa.vix.com> <00041A16-473F-4F96-93E8-E3CD3F83E1B2@virtualized.org> <70374.1294475040@nsa.vix.com> <5336.1294506839@nsa.vix.com> Message-ID: On Sat, Jan 8, 2011 at 2:47 PM, Christopher Morrow wrote: > I don't think rr.arin.net and RPKI have anything to do with each > other. I think the direction the RPKI should/is taking is to have the I at least think that whatever future and time-table is planned for RPKI, this should not stand in the way of ARIN offering an effective authentication mechanism for the ARIN IRR. FYI, the reply I received from ARIN was that there are no plans to improve its authentication capability. I didn't ask why and don't really care why it has never had anything more than MAIL-FROM in the past. Either it should be improved (IMO) or it shouldn't be. I really do wonder what ARIN's plan is if a bad guy decides to forge emails and delete or modify some or all of the objects. Would they just shut it down, improve authentication, or keep doing business as usual? I am always surprised that black hat folks do not do things like this when faced with a damaging vulnerability that can easily be exploited with no way to trace the activity back to the bad guy. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From bonomi at mail.r-bonomi.com Sat Jan 8 18:50:01 2011 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Sat, 8 Jan 2011 18:50:01 -0600 (CST) Subject: AltDB? In-Reply-To: Message-ID: <201101090050.p090o1sL086076@mail.r-bonomi.com> > Date: Sun, 09 Jan 2011 06:25:33 +0900 > From: Randy Bush > Cc: nanog at nanog.org > Subject: Re: AltDB? > > > Let me see if I've got this right -- you think ARIN should change their > > policies, but _you_ are not willing to put in any personal effort to make > > it happen, right? > > i not put in personal effort? you're kidding or really new here, right? I used future tense, not past. Taking your prior language at face value, which you elided, it appears that you have no intent of any future participation in ARIN processes. Your subsequently revaealed story regarding your thwarted attempt at a _requested_ run for a BoT seat, provides some understanding for a 'why' for that attitude. I'll simply note that _if_ you do cease future particioation in =their= process, you _have_ 'let the bastards win'. From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sat Jan 8 18:48:02 2011 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sun, 9 Jan 2011 11:18:02 +1030 Subject: NIST IPv6 document In-Reply-To: References: <20110105043548.BC01B1CC3E@ptavv.es.net> <4661ED7E-A4DA-4CD4-A7EB-C5B2E615F126@delong.com> <86zkreb486.fsf@seastrom.com> <20110107194452.110fa401@opy.nosense.org> <393B7513-84A6-470B-9CE5-63B3584B707F@arbor.net> <20110108075820.7fe32a58@opy.nosense.org> Message-ID: <20110109111802.1caec0ef@opy.nosense.org> On Fri, 7 Jan 2011 14:53:02 -0800 Owen DeLong wrote: > > On Jan 7, 2011, at 1:28 PM, Mark Smith wrote: > > > On Fri, 7 Jan 2011 09:38:32 +0000 > > "Dobbins, Roland" wrote: > > > >> > >> On Jan 7, 2011, at 4:14 PM, Mark Smith wrote: > >> > >>> Doesn't this risk already exist in IPv4? > >> > >> > >> There are various vendor knobs/features to ameliorate ARP-level issues in switching gear. Those same knobs aren't viable in IPv6 due to the way ND/NS work, > > > > I was commenting on the mentality the OP seemed to be > > expressing, about *both* onlink and off link sources triggering address > > resolution for lots of non-existent destinations, and that this was a > > new and unacceptable threat. I think the offlink risk is a > > far more significant one. I think the onlink risk pretty much no worse > > than any of the other things that LAN attached devices can do if they > > choose to. > > > >> and as you mention, the ND stuff is layer-3-routable. > >> > > > > The issue isn't that ND is layer 3 routable - it isn't unless a router > > implementation is broken. The problem is that somebody on the Internet > > could send 1000s of UDP packets (i.e. an offlink traffic source) > > towards destinations that don't exist on the target subnet. The > > upstream router will then perform address resolution, sending ND NSes > > for those unknown destinations, and while waiting to see if ND NAs are > > returned, will maintain state for each outstanding ND NS. This state is > > what is exploitable remotely, unless the state table size is large > > enough to hold all possible outstanding ND NA entries for all possible > > addresses on the target subnet. > > > > I think this problem can be avoided by getting rid of this offlink > > traffic triggered address resolution state. The purpose of the state > > (from the Neighbor Discovery RFC) is two fold - > > > > - to allow the ND NS to be resent up to two times if no ND NA response > > is received to ND NSes. A number of triggering packets (e.g. UDP > > ones or TCP SYNs) are queued as well so that they can be resent if and > > when ND NS/NA completes. > > > > - to allow ICMP destination unreachables to be generated if the ND > > NS/NA transaction fails, even after resending. > > > > I think it is acceptable to compromise on these requirements. > > I'm inclined to agree with you, but... > > I think it might also make sense to eliminate the ND NS/NA transaction > altogether for addresses that do not begin with xxxx:xxxx:xxxx:xxxx:000x. > In other words, for non SLAAC addresses, we need the ND NS/NA > process (even if we do it stateless which isn't an entirely bad idea), > but, for SLAAC addresses, the MAC is embedded in the IP address, > so, why not just use that? > I think then you'd only be able to avoid the issue by maintaining "MAC/SLAAC" only segments, with no stateful DHCPv6, privacy address or static addressed nodes, so that (stateful or stateless) ND NS/NA could be disabled. While it would work for those types of nodes, it wouldn't restore the properties we'd have to give up for the stateless ND NS/NA idea, as they need state to be performed, regardless of the destination address type. I think there are a variety of valid and legitimate reasons to preserve the ability to have different layer 3 and layer 2 node addresses, rather than 1-to-1 mapping them. Therefore I think an ideal solution to this problem solves it for all cases, rather than having different solutions or mitigations for different situations. With your suggestion, in theory a solution would now exist for point-to-point links via /127 configured prefix lengths and for "MAC/SLAAC" only LAN segments. Neither of those solutions can be used for stateful DHCPv6 segments, or segments where privacy addresses are useful and could be used - so we'd only be at 2 out of (at least) 4 situations to mitigate it. I think when you start going down the path of creating a number of different special cases with fairly different methods of addressing them, it is worth sitting back and saying is there a single general solution that will cover all cases. That is what has been done in IPv6 with ND address resolution, rather than having link specific methods of configuring and/or discovering IPv6 addresses (e.g. in IPv4 IPCP, ARP etc.), so if there is a solution that can be applied within ND address resolution, it automatically applies to all existing and future link types that IPv6 operates over. Regards, Mark. From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sat Jan 8 19:09:38 2011 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sun, 9 Jan 2011 11:39:38 +1030 Subject: NIST IPv6 document In-Reply-To: <867hegq5fl.fsf@seastrom.com> References: <20110106060142.44CC11CC41@ptavv.es.net> <867hegq5fl.fsf@seastrom.com> Message-ID: <20110109113938.0502b3b2@opy.nosense.org> On Fri, 07 Jan 2011 07:11:42 -0500 "Robert E. Seastrom" wrote: > > "Kevin Oberman" writes: > > >> The next ship will be departing in a hundred years or so, advance > >> registration for the IPv7 design committee are available over there. > > > > Sorry, but IPv7 has come and gone. It was assigned to the TUBA proposal, > > basically replacing IP with CLNP. IPv8 has also been assigned. (Don't ask > > as it involved he who must not be named.) > > In the grand tradition of list pedantry, I must correct both of these > statements. :-) > > IPv7 was TP/IX, which I never really learned anything about (at least > nothing that I can remember) at the time. > > IPv8 was PIP, which got merged with SIP to form SIPP which as I recall > evolved into IPv6. It had nothing to do with he who must not be > named, but you can't figure this out by googling IPv8 as all it > returns is a series of links to flights of fancy. > > IPv9 was TUBA. Went down for political reasons, but in retrospect > perhaps wouldn't have been such a bad thing compred to the "second > system syndrome" design that we find ourselves with today (I know I'm > gonna take it on the chin for making such a comment, but whatever). > > 10-14 are unassigned, guess we'd better get crackin, eh? > If you define a new protocol version as one that means devices with older protocol generations of firmware/software may not interoperate reliably with devices with new protocol generations of firmware/software, then IPv4 as we know it today is probably at least "IPv7" - address classes was a generational change requiring software/firmware updates (compare addressing in rfc760 verses rfc791), as was classful+subnets and then CIDR. Regards, Mark. From nanog at jima.tk Sat Jan 8 19:20:26 2011 From: nanog at jima.tk (Jima) Date: Sat, 08 Jan 2011 19:20:26 -0600 Subject: Problems with removing NAT from a network In-Reply-To: <4D26B516.80001@matthew.at> References: <4D252B1F.8030506@kenweb.org> <3DFD6833-78C1-43D2-8074-6C89CFE3F2F3@arbor.net> <20110106043110.21C96876D21@drugs.dv.isc.org> <4D254ED8.6030006@matthew.at> <4D25F971.4090709@matthew.at> <4D2634E7.2060502@matthew.at> <9DEED87C-ED15-4D05-BCD6-69A5D4A69681@delong.com> <4D268097.6050502@matthew.at> <0fa801cbae2b$bad57850$308068f0$@com> <4D26B516.80001@matthew.at> Message-ID: <4D290D5A.5040905@jima.tk> On 1/7/2011 12:39 AM, Matthew Kaufman wrote: > If one end is behind a NAT64 and there is no mechanism for discovering > the NAT64's IPv6 interface prefix and mapping algorithm (and at present > there is not), there is no way to send IPv6 IP packets from the > IPv6-only host to IPv4 literal addresses (that is to say, addresses > learned via a mechanism other than DNS responses synthesized by the > DNS64 part of the NAT64 "solution") on the IPv4 Internet through said > NAT64. While a rather inelegant solution, it just popped into my head that one could do an AAAA query for a known-value A record (i.e., under skype.com), and based on a response (if any), replace the known IP value with the IP which with one wants to connect. A little weird, but it's a thought. Jima From rdobbins at arbor.net Sat Jan 8 20:39:29 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Sun, 9 Jan 2011 02:39:29 +0000 Subject: IPv6 - real vs theoretical problems In-Reply-To: References: <4D269D77.4080309@jima.tk> <10FB3518-6470-4F14-963C-B3150FABE667@delong.com> <442E296F-A5DD-4BE0-AE42-BA02E49F5F4D@arbor.net> <8D806878-5D6E-4ABB-BDD9-9E6A58F33D77@arbor.net> Message-ID: <8967718F-528B-4137-ACC5-C532152704AE@arbor.net> On Jan 9, 2011, at 12:11 AM, Sam Stickland wrote: > Why do you say there is zero state at the server, but the not at the client? Because every incoming connection to the server is unsolicited - therefore, there's no pre-existing state to evaluate. ------------------------------------------------------------------------ Roland Dobbins // Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay From randy at psg.com Sat Jan 8 21:08:15 2011 From: randy at psg.com (Randy Bush) Date: Sun, 09 Jan 2011 12:08:15 +0900 Subject: AltDB? In-Reply-To: <201101090050.p090o1sL086076@mail.r-bonomi.com> References: <201101090050.p090o1sL086076@mail.r-bonomi.com> Message-ID: > Taking your prior language at face value, which you elided, it appears > that you have no intent of any future participation in ARIN processes. i am doing so right here and now. you just don't like my choice of forum and probably my message. tough patooties. randy From randy at psg.com Sat Jan 8 21:23:20 2011 From: randy at psg.com (Randy Bush) Date: Sun, 09 Jan 2011 12:23:20 +0900 Subject: AltDB? In-Reply-To: References: <59051.1294464800@nsa.vix.com> <00041A16-473F-4F96-93E8-E3CD3F83E1B2@virtualized.org> <70374.1294475040@nsa.vix.com> <5336.1294506839@nsa.vix.com> Message-ID: > I at least think that whatever future and time-table is planned for > RPKI, this should not stand in the way of ARIN offering an effective > authentication mechanism for the ARIN IRR. > ... > I really do wonder what ARIN's plan is if a bad guy decides to forge > emails and delete or modify some or all of the objects. my guess is do their best to try to see who has the right data. as arin seems to be driven by fud, policy wannbes, and lawyer(s), this might be complex, slow, and expensive. so it goes. but, unlike the other regions, the arin.irr is not confuddled with the arin.whois. i.e. it is kind of irrelevant to the authority on resource ownership, arin's real responsibility. they are just providing a free irr service, as it is the popular thing for rirs to do these years. and i don't think many use it. if you don't like its weak authentication, then don't use it, there are plenty of alternatives, e.g. see $subject. i agree that running an irr instance with only mail-from is pretty lame. and there is good free software out there to do it well if you do not suffer from nih. so i would advise putting it late in your peval() string. randy, who runs an irr instance using irrd From owen at delong.com Sat Jan 8 22:56:07 2011 From: owen at delong.com (Owen DeLong) Date: Sat, 8 Jan 2011 20:56:07 -0800 Subject: arin and ops fora (was Re: AltDB?) In-Reply-To: <55EF24AC-DFFC-4A84-B828-693F0A1864A9@virtualized.org> References: <94F3F129-608E-46EC-B157-CC23CAA47454@tozz.net> <4D24A734.3000807@jcoley.net> <816AB912-14CF-4028-853A-F0BE77D2EB09@puck.nether.net> <734B46C1-AE6C-406A-8163-00CFFE942B1B@virtualized.org> <000101cbaf42$0a65d7e0$1f3187a0$@org> <55EF24AC-DFFC-4A84-B828-693F0A1864A9@virtualized.org> Message-ID: <70BCF9E7-BC8E-4C81-A5C7-32F47EB55575@delong.com> On Jan 8, 2011, at 1:15 PM, David Conrad wrote: > Lee, > > On Jan 8, 2011, at 4:40 AM, Lee Howard wrote: >> I think that's a bit of what we've been trying to do with the Best Current Operational Practices BoFs. We need a place where operators can discuss and document BCOPs. > > While I think BCOPs (and BCOP BoFs) are a great idea, I guess the question is how can folks be assured that ARIN would follow a NANOG community-defined BCOP relating directly to ARIN operations. For example, if the NANOG community were to (reasonably) say "BCOP is to use IETF-defined standards for publishing and accessing resource registration data", I'd imagine ARIN might (reasonably) disagree and continue down the RWS path. > > I suspect part of the issue is that ARIN is a monopoly provider of a variety public services that folks unrelated (directly) to ARIN must make use of. In other areas of public service provision, there are things like public utilities commissions that (in theory) ensure the monopoly service provider acts in the public benefit when services are added/changed/deleted. My impression is that the various WGs and SIGs in the other RIRs perform something similar to that function. There doesn't appear to be anything similar in the ARIN region. > > Regards, > -drc > In ARIN, there are things like BoT elections and the BoT very much fulfills the role of the PUC as you describe above. People can submit requests for operational changes to ARIN through the ACSP and in my experience they get a good review and comment period by the community and the board listens to these things and responds appropriately. Especially if a suggestion receives significant support, it tends to get implemented. Owen From owen at delong.com Sat Jan 8 23:03:43 2011 From: owen at delong.com (Owen DeLong) Date: Sat, 8 Jan 2011 21:03:43 -0800 Subject: NIST IPv6 document In-Reply-To: <20110109113938.0502b3b2@opy.nosense.org> References: <20110106060142.44CC11CC41@ptavv.es.net> <867hegq5fl.fsf@seastrom.com> <20110109113938.0502b3b2@opy.nosense.org> Message-ID: <3C279A96-BBB5-4B50-8A13-3E910E88D762@delong.com> >> >> > > If you define a new protocol version as one that means devices with > older protocol generations of firmware/software may not interoperate > reliably with devices with new protocol generations of > firmware/software, then IPv4 as we know it today is probably at least > "IPv7" - address classes was a generational change requiring > software/firmware updates (compare addressing in rfc760 verses rfc791), > as was classful+subnets and then CIDR. > > Regards, > Mark. I think it's defined, instead, in terms of incompatible changes to the content of the packet header. Owen From owen at delong.com Sat Jan 8 23:15:27 2011 From: owen at delong.com (Owen DeLong) Date: Sat, 8 Jan 2011 21:15:27 -0800 Subject: AltDB? In-Reply-To: References: <201101090050.p090o1sL086076@mail.r-bonomi.com> Message-ID: On Jan 8, 2011, at 7:08 PM, Randy Bush wrote: >> Taking your prior language at face value, which you elided, it appears >> that you have no intent of any future participation in ARIN processes. > > i am doing so right here and now. you just don't like my choice of > forum and probably my message. tough patooties. > > randy Throwing rocks at a process in another organizations forum is not participating in the process any more than standing before the Syrian Government and criticizing the US congress would be participating in US politics. Owen From matthew at matthew.at Sun Jan 9 00:39:47 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Sat, 08 Jan 2011 22:39:47 -0800 Subject: Problems with removing NAT from a network In-Reply-To: <4D290D5A.5040905@jima.tk> References: <4D252B1F.8030506@kenweb.org> <3DFD6833-78C1-43D2-8074-6C89CFE3F2F3@arbor.net> <20110106043110.21C96876D21@drugs.dv.isc.org> <4D254ED8.6030006@matthew.at> <4D25F971.4090709@matthew.at> <4D2634E7.2060502@matthew.at> <9DEED87C-ED15-4D05-BCD6-69A5D4A69681@delong.com> <4D268097.6050502@matthew.at> <0fa801cbae2b$bad57850$308068f0$@com> <4D26B516.80001@matthew.at> <4D290D5A.5040905@jima.tk> Message-ID: <4D295833.7070101@matthew.at> On 1/8/2011 5:20 PM, Jima wrote: > On 1/7/2011 12:39 AM, Matthew Kaufman wrote: >> If one end is behind a NAT64 and there is no mechanism for discovering >> the NAT64's IPv6 interface prefix and mapping algorithm (and at present >> there is not), there is no way to send IPv6 IP packets from the >> IPv6-only host to IPv4 literal addresses (that is to say, addresses >> learned via a mechanism other than DNS responses synthesized by the >> DNS64 part of the NAT64 "solution") on the IPv4 Internet through said >> NAT64. > > While a rather inelegant solution, it just popped into my head that > one could do an AAAA query for a known-value A record (i.e., under > skype.com), and based on a response (if any), replace the known IP > value with the IP which with one wants to connect. > A little weird, but it's a thought. > > Jima > That's one of the proposed solutions on the list of discovery technologies, IIRC. Matthew Kaufman From matthew at matthew.at Sun Jan 9 00:46:47 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Sat, 08 Jan 2011 22:46:47 -0800 Subject: Problems with removing NAT from a network In-Reply-To: <4D284798.3010806@consolejunkie.net> References: <4D252B1F.8030506@kenweb.org> <3DFD6833-78C1-43D2-8074-6C89CFE3F2F3@arbor.net> <20110106043110.21C96876D21@drugs.dv.isc.org> <4D254ED8.6030006@matthew.at> <4D25F971.4090709@matthew.at> <4D2634E7.2060502@matthew.at> <9DEED87C-ED15-4D05-BCD6-69A5D4A69681@delong.com> <4D267B9E.8040602@bogus.com> <4D268119.2050205@matthew.at> <4D284798.3010806@consolejunkie.net> Message-ID: <4D2959D7.7040407@matthew.at> On 1/8/2011 3:16 AM, Leen Besselink wrote: > > Hello Mr. Kaufman, > > In the upcoming years, we will have no IPv6 in some places and badly > performing IPv4 (CGN, etc.) with working IPv6 in others. Right. So we're discussing just how "badly performing" the IPv4 can be and still be acceptable as "access to the IPv4 Internet for your customers". I am arguing that CGN (NAT44 to get additional IPv4 to dual-stack) doesn't break nearly as much as NAT64/DNS64 does, and that in fact NAT64/DNS64 breaks *so much* that you probably can't/shouldn't sell it to your customers as "access to the IPv4 Internet". Note that for a *very* long time... much longer than there will be new IPv4 addresses available... there will be a whole lot of places that have good IPv4 and no IPv6. (As you note above) > If I was Skype I would make really sure that all my relay nodes and > login servers have IPv6 with enough bandwidth or can easily upgrade the > bandwidth where neede. And make sure atleast IPv6-client and > IPv6-servers communication works everywhere where there is IPv6. Clearly that would be needed to serve the IPv6-only users well. > > For your customers it is really easy. When Skype does not work, people > will jump ship where they can and maybe use Google Talk or whatever. Ah. But you're taking the bet that when Skype does not work on *your* network that provides IPv4 access via NAT64 people won't "jump ship" to a provider that uses CGN or even has enough native IPv4 addresses left around. > I suggest making sure you include both IPv4 and IPv6 addresses in your > protocol, maybe it needs to be extended. So that the client at the other > end can choose what IP-version to use. Or can try both. Maybe the > login-server can help to decide for the client. But those login servers > will need to have good IPv6 connectivity to be able to do so. But none of that solves the problem of talking from an IPv6 client that has broken IPv4 access (NAT64) to a an IPv4 client that has no IPv6 access. > I'm sorry if it sounds a bit like fear mongering, but to me it sounds > like common sense that if a business is not prepared when the > environment that business operates in changes and that business does not > adapt to the changes in time that business might suffer. But that's true of ISPs when they choose how to deal with the lack of additional IPv4 space but continued customer demand to reach the IPv4 Internet, too, isn't it? Matthew Kaufman From matthew at matthew.at Sun Jan 9 00:55:02 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Sat, 08 Jan 2011 22:55:02 -0800 Subject: Problems with removing NAT from a network In-Reply-To: <000101cbaf8a$dd300310$97900930$@iname.com> References: <4D252B1F.8030506@kenweb.org> <3DFD6833-78C1-43D2-8074-6C89CFE3F2F3@arbor.net> <20110106043110.21C96876D21@drugs.dv.isc.org> <4D254ED8.6030006@matthew.at> <4D25F971.4090709@matthew.at> <4D2634E7.2060502@matthew.at> <9DEED87C-ED15-4D05-BCD6-69A5D4A69681@delong.com> <4D268097.6050502@matthew.at> <000101cbaf8a$dd300310$97900930$@iname.com> Message-ID: <4D295BC6.2060607@matthew.at> On 1/8/2011 3:22 PM, Frank Bulk wrote: > Relay nodes are always protecting themselves by rate-limiting, aren't they? Yes. > And isn't most media traffic relayed? No, not at all. Almost all media traffic goes directly end-to-end by using really good NAT traversal. > I'm not seeing how the NAT64 scenario > would *dramatically* increase Skype's global relay traffic. NAT64 would > currently be a very small percentage of all Skype traffic. The relay issue isn't about that. If you can't discover the NAT64 and you can't discover the mapping algorithm, then you can't use IPv4 literal addresses. If you can and the application is changed to use the discovery mechanism, then the traffic flows through the NAT64 and relay nodes aren't an issue. But if you can't then the only way for a future IPv6-enabled Skype client that has IPv6 + NAT64 to (not) reach the IPv4 Internet can talk to another Skype client that has IPv4 only would be to go through the relay node. That means that people who are on ISPs that use native IPv4 dual-stack, and people who are on ISPs that use CGN NAT44 to dual-stack both get the direct end-to-end experience when calling IPv4-only clients... but people who are on ISPs that use NAT64 instead of dual-stack end up having to go through (rate limited) relays to call IPv4-only clients. That means they'd have an excellent reason to choose an ISP that uses a different technology. Which they'll need to do to make their BitTorrent and everything else that uses IPv4 literals work anyway. > We can always find examples of where things will break with v6. While the > v6-only world is still very small, let's *start* somewhere, where > intelligent clients like Skype can always "fall back" to v4. Lots of time > to figure out the corner cases. The point is that NAT64 creates a huge additional set of corner cases (all of the cases where IPv4 literal addresses are transported by anything other than DNS lookups) that none of the other transition choices do. (NAT64 has all the problems of CGN *plus* this issue, for instance.) Matthew Kaufman From jsw at inconcepts.biz Sun Jan 9 01:09:41 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Sun, 9 Jan 2011 02:09:41 -0500 Subject: AltDB? In-Reply-To: References: <59051.1294464800@nsa.vix.com> <00041A16-473F-4F96-93E8-E3CD3F83E1B2@virtualized.org> <70374.1294475040@nsa.vix.com> <5336.1294506839@nsa.vix.com> Message-ID: On Sat, Jan 8, 2011 at 10:23 PM, Randy Bush wrote: > but, unlike the other regions, the arin.irr is not confuddled with the > arin.whois. ?i.e. it is kind of irrelevant to the authority on resource > ownership, arin's real responsibility. I certainly agree with this, and I am admittedly ignorant of the history here, but I don't understand why ARIN is operating an IRR that is very much insecure, instead of just not operating one at all. > they are just providing a free irr service, as it is the popular thing > for rirs to do these years. ?and i don't think many use it. ?if you In terms of database size, excluding RIPE, the ARIN IRR is the 8th largest, ahead of ALTDB and about 10% as large as Level3, the second largest IRR database (except RIPE.) A mass-corruption of the ARIN IRR overnight might be a serious incident causing service impact to a large number of users and businesses, and cause probably thousands of people to be got out of bed in the middle of the night, but clearly it would not be a total disaster. No one is forced to use ARIN IRR, but it's worth asking the question: why is ARIN a trustworthy steward of RPKI infrastructure if their IRR is a serious liability to The Internet because of a simple issue like not supporting password or PGP authentication? Is this the reason ARIN is spending time consulting their lawyers? -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From cb.list6 at gmail.com Sun Jan 9 08:42:16 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Sun, 9 Jan 2011 06:42:16 -0800 Subject: Problems with removing NAT from a network In-Reply-To: <4D295BC6.2060607@matthew.at> References: <4D252B1F.8030506@kenweb.org> <3DFD6833-78C1-43D2-8074-6C89CFE3F2F3@arbor.net> <20110106043110.21C96876D21@drugs.dv.isc.org> <4D254ED8.6030006@matthew.at> <4D25F971.4090709@matthew.at> <4D2634E7.2060502@matthew.at> <9DEED87C-ED15-4D05-BCD6-69A5D4A69681@delong.com> <4D268097.6050502@matthew.at> <000101cbaf8a$dd300310$97900930$@iname.com> <4D295BC6.2060607@matthew.at> Message-ID: On Sat, Jan 8, 2011 at 10:55 PM, Matthew Kaufman wrote: > On 1/8/2011 3:22 PM, Frank Bulk wrote: >> >> Relay nodes are always protecting themselves by rate-limiting, aren't >> they? > > Yes. >> >> And isn't most media traffic relayed? > > No, not at all. Almost all media traffic goes directly end-to-end by using > really good NAT traversal. >> >> ?I'm not seeing how the NAT64 scenario >> would *dramatically* increase Skype's global relay traffic. ?NAT64 would >> currently be a very small percentage of all Skype traffic. > > The relay issue isn't about that. If you can't discover the NAT64 and you > can't discover the mapping algorithm, then you can't use IPv4 literal > addresses. If you can and the application is changed to use the discovery > mechanism, then the traffic flows through the NAT64 and relay nodes aren't > an issue. > > But if you can't then the only way for a future IPv6-enabled Skype client > that has IPv6 + NAT64 to (not) reach the IPv4 Internet can talk to another > Skype client that has IPv4 only would be to go through the relay node. > > That means that people who are on ISPs that use native IPv4 dual-stack, and > people who are on ISPs that use CGN NAT44 to dual-stack both get the direct > end-to-end experience when calling IPv4-only clients... but people who are > on ISPs that use NAT64 instead of dual-stack end up having to go through > (rate limited) relays to call IPv4-only clients. > > That means they'd have an excellent reason to choose an ISP that uses a > different technology. Which they'll need to do to make their BitTorrent and > everything else that uses IPv4 literals work anyway. > >> We can always find examples of where things will break with v6. ?While the >> v6-only world is still very small, let's *start* somewhere, where >> intelligent clients like Skype can always "fall back" to v4. ?Lots of time >> to figure out the corner cases. > > The point is that NAT64 creates a huge additional set of corner cases (all > of the cases where IPv4 literal addresses are transported by anything other > than DNS lookups) that none of the other transition choices do. (NAT64 has > all the problems of CGN *plus* this issue, for instance.) > 1. The companies that have selected NAT64 as a tool for rolling out IPv6 to address the IPv4 exhaustion business risk are aware of the various application trade offs. They select NAT64 because it makes business sense to aggressively go after IPv6 as the end-state and not provide patches and work-arounds in their network to make dual-stack work, which is not an end-state, it is a transition mechanism on the path to ipv6. Also, as i mentioned for mobile, dual-stack is MUCH more expensive. And ipv6-only works for the vast majority of my user and my traffic. 2. You can pass this FUD around about people leaving networks so that skype and bittorrent work. Last time i checked, many mobile network operators and handsets only begrudgingly supported skype and bittorent if at all. In fact, many networks spend considerable time and money to stop them. I also know that Skype has some mobile partners. I am not here to say if this is right or wrong, but i do not expect network providers to alter their ipv6 strategy of business decisions to accommodate Skype and Bittorrent. These applications have shown amazing resiliency over the years to bust through firewalls and NATs, and i am really amazed at how much opposition Skype is providing to the IPv6 transition. I imagine Skype would have a better hand if Skype was IPv6 enabled a long time ago and pushing dual-stack and waiting on the carriers, but Skype is IPv4-only just like all the rest of the slow moving world. If dual-stack had worked, we would not be here talking about NAT64. But, dual-stack did not work. We are out of IPv4 and the network still has to grow, hence IPv6-only + NAT64. And again, dual-stack is much more expensive in mobile networks than single stack so it won't happen with the Ipv4 side being endless duplication of RFC 1918 and bogon space. 3. I am just here to create awareness of this technology that the IETF as the protocol standardizer and the 3GPP as the mobile architecture standardizer have accepted and are moving forward. I want all applications to work with IPv6 and NAT64. In every email i have sent on this topic and off-list to Matthew, i have made the call to action to support ipv6 and to work together. From the network side, i am willing partner. But, not supporting IPv6 is not an option in my mind. That is where Skype stands today. IPv4 is really not a strategic path for any network, especially a mobile network that has a large and growing edge. There are several ways to work through making NAT64 work, as Matthew has acknowledge, and even hinted at having a better proprietary way. I am open to new ways and new partnerships to make this work. When you are ready to talk about moving forward, i am all ears. Until then, you can keep posturing while the clock ticks on committed deployments. If you know it's coming and don't have a solution, if you strategically choose to play that game of chicken, thats fine too, it's a calculated risk that my business has made. Cameron > Matthew Kaufman > > > From lee at asgard.org Sun Jan 9 10:40:25 2011 From: lee at asgard.org (Lee Howard) Date: Sun, 9 Jan 2011 11:40:25 -0500 Subject: arin and ops fora (was Re: AltDB?) In-Reply-To: <55EF24AC-DFFC-4A84-B828-693F0A1864A9@virtualized.org> References: <94F3F129-608E-46EC-B157-CC23CAA47454@tozz.net> <4D24A734.3000807@jcoley.net> <816AB912-14CF-4028-853A-F0BE77D2EB09@puck.nether.net> <734B46C1-AE6C-406A-8163-00CFFE942B1B@virtualized.org> <000101cbaf42$0a65d7e0$1f3187a0$@org> <55EF24AC-DFFC-4A84-B828-693F0A1864A9@virtualized.org> Message-ID: <002d01cbb01b$eaa07160$bfe15420$@org> > On Jan 8, 2011, at 4:40 AM, Lee Howard wrote: > > I think that's a bit of what we've been trying to do with the Best Current Operational > Practices BoFs. We need a place where operators can discuss and document BCOPs. > > While I think BCOPs (and BCOP BoFs) are a great idea, I guess the question is how can > folks be assured that ARIN would follow a NANOG community-defined BCOP relating > directly to ARIN operations. For example, if the NANOG community were to (reasonably) > say "BCOP is to use IETF-defined standards for publishing and accessing resource > registration data", I'd imagine ARIN might (reasonably) disagree and continue down the > RWS path. I don't think of BCOP as a subset of NANOG, but as an overlap of several communities, including NANOG and ARIN. Certainly ARIN is not bound by BCOP's findings (no one would be), but the AC and Board would take seriously a community-consensus best practice. I doubt ARIN would be surprised by any BCOP finding, given the involvement of several ARIN AC members in it. > provision, there are things like public utilities commissions that (in theory) ensure the > monopoly service provider acts in the public benefit when services are > added/changed/deleted. My impression is that the various WGs and SIGs in the other RIRs > perform something similar to that function. There doesn't appear to be anything similar in > the ARIN region. Are you saying ARIN needs an ombudsman function to make sure the Board doesn't delay implementation of things the community wants while it figures out whether doing such things will prevent it from doing other things the community wants? I don't understand how this bee-watcher-watcher thing works. Lee From joelja at bogus.com Sun Jan 9 11:02:45 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Sun, 09 Jan 2011 09:02:45 -0800 Subject: Problems with removing NAT from a network In-Reply-To: <000201cbaf8a$e3a99300$aafcb900$@iname.com> References: <4D252B1F.8030506@kenweb.org> <3DFD6833-78C1-43D2-8074-6C89CFE3F2F3@arbor.net> <20110106043110.21C96876D21@drugs.dv.isc.org> <4D254ED8.6030006@matthew.at> <4D25F971.4090709@matthew.at> <4D2634E7.2060502@matthew.at> <9DEED87C-ED15-4D05-BCD6-69A5D4A69681@delong.com> <4D267B9E.8040602@bogus.com> <4D268119.2050205@matthew.at> <000201cbaf8a$e3a99300$aafcb900$@iname.com> Message-ID: <4D29EA35.6090405@bogus.com> On 1/8/11 3:22 PM, Frank Bulk wrote: > Maybe HE would volunteer to host some Skype servers at their various POPS > for this purpose. skype has the the ability to deploy supernodes on demand using their own capacity. they've demonstrated that in the face of congestive collapse, buying ipv6 transit isn't hard. > Skype has to start somewhere. While the v6-only population is still very > small, why not dual-stack the clients now with a heavily weighted preference > towards v4, track and understand the volume and capabilities of v6, and > slowly de-preference v4 over time? > > Frank > > -----Original Message----- > From: Matthew Kaufman [mailto:matthew at matthew.at] > Sent: Thursday, January 06, 2011 8:57 PM > To: Joel Jaeggli > Cc: Nanog Operators' Group > Subject: Re: Problems with removing NAT from a network > > On 1/6/2011 6:34 PM, Joel Jaeggli wrote: >> On 1/6/11 5:48 PM, Owen DeLong wrote: >>> Doesn't all of this become moot if Skype just develops a dual-stack > capable client >>> and servers? >> Really, only some fraction of the supernodes and the login servers need >> to be dual stack. >> > Without revealing too much about the architecture, I can tell you that > it would need to be a significant fraction of the supernodes (due to how > node-supernode mapping works in these types of P2P systems), the relay > nodes (not mentioned) *and* the login servers. Not all of which are > deployed and controlled by Skype, of course, as recent press about the > most recent outage has reiterated for those who didn't know. > > Matthew Kaufman > > > > From jcurran at arin.net Sun Jan 9 12:09:13 2011 From: jcurran at arin.net (John Curran) Date: Sun, 9 Jan 2011 18:09:13 +0000 Subject: AltDB? In-Reply-To: References: <59051.1294464800@nsa.vix.com> <00041A16-473F-4F96-93E8-E3CD3F83E1B2@virtualized.org> <70374.1294475040@nsa.vix.com> <5336.1294506839@nsa.vix.com> Message-ID: <1AAAEF13-B1AC-41CA-8B16-9985FD9E0EB2@arin.net> On Jan 9, 2011, at 2:09 AM, Jeff Wheeler wrote: > In terms of database size, excluding RIPE, the ARIN IRR is the 8th > largest, ahead of ALTDB and about 10% as large as Level3, the second > largest IRR database (except RIPE.) A mass-corruption of the ARIN IRR > overnight might be a serious incident causing service impact to a > large number of users and businesses, and cause probably thousands of > people to be got out of bed in the middle of the night, but clearly it > would not be a total disaster. Jeff - Please suggest your preferred means of IRR authentication to the ARIN suggestion process: Alternatively, point to a best practice document from the operator community for what should be done here. ARIN's work plan is very much driven by community input, so that's what is needed here. Thanks! /John John Curran President and CEO ARIN From jcurran at arin.net Sun Jan 9 12:49:26 2011 From: jcurran at arin.net (John Curran) Date: Sun, 9 Jan 2011 18:49:26 +0000 Subject: AltDB? (IRR support & direction at ARIN) In-Reply-To: References: Message-ID: On Jan 5, 2011, at 12:07 PM, Jeff Wheeler wrote: > I would like to note that RADB had route6: support in about 2004 or > so, if my memory serves me; while the ARIN database did not accept > route6 objects until about a year ago. So it is not exactly a high > priority for ARIN. The priority of IRR at ARIN is based on community feedback and direction. There is no particular reason for ARIN to focus on ongoing IRR enhancements, if the community isn't asking for such. ARIN needs to stay focused on its mission, and prioritize all work accordingly. There has not been a clear consensus from the community one way or the other about enhancing the IRR services as part of that mission, nor on deeming it to be outside of the mission and phasing out the services. This makes it somewhat challenging for the Board and staff to discern the right approach, and leaves us simply maintaining the status quo for these services. Should IRR services be part of the ARIN mission? ARIN-discuss would be a great mailing list on which to discuss this topic, or (along the lines of Randy's earlier comments) on this NANOG list, if the mailing list folks consider it to be on topic. /John John Curran President and CEO ARIN From francois at menards.ca Sun Jan 9 13:28:37 2011 From: francois at menards.ca (Francois Menard) Date: Sun, 9 Jan 2011 14:28:37 -0500 Subject: Anyone out there providing Public Services over MEF E-Tree ? Message-ID: In an effort of figuring out a metro ethernet access network to carry Internet access services, I'm comparing the approaches of several equipment manufacturers insofar as how, they allow a metro service provider to provide point-to-multipoint E-TREE public services, (where the leaves of the multipoint tree are different billing entities from that of the root of the tree), such that it remains possible to distinguish at the root traffic originating from a given service provider demarcation device in the tree. In an effort to solve this problem, I am finding myself diving deep down into the behaviour of Ethernet switches at the 802.1Q 2005 bridge behaviour. I would appreciate feedback from people whom are aware since WHEN and under which conditions, Ethernet switches have begun to implement separate MAC addresses for every client ports. and whether such MAC addresses draw from the global pool of MAC addresses. A cursory understanding of this leads me to believe that as soon as a switch is capable of spanning tree on a downstream client port, it must have separate MAC addresses for every client port. Feedback appreciated -=Francois=- From jlewis at lewis.org Sun Jan 9 14:02:40 2011 From: jlewis at lewis.org (Jon Lewis) Date: Sun, 9 Jan 2011 15:02:40 -0500 (EST) Subject: AltDB? (IRR support & direction at ARIN) In-Reply-To: References: Message-ID: On Sun, 9 Jan 2011, John Curran wrote: > Should IRR services be part of the ARIN mission? If that's a serious question, why does rr.arin.net exist at all? ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From jcurran at arin.net Sun Jan 9 16:55:50 2011 From: jcurran at arin.net (John Curran) Date: Sun, 9 Jan 2011 22:55:50 +0000 Subject: AltDB? (IRR support & direction at ARIN) In-Reply-To: References: Message-ID: On Jan 9, 2011, at 3:02 PM, Jon Lewis wrote: >> Should IRR services be part of the ARIN mission? > > If that's a serious question, why does rr.arin.net exist at all? Jon - Existence of not in and of itself proof that the services are presently desired by the community, nor that there are benefits in having them provided by ARIN. For example, one can argue that it is desirable for ARIN to provide IRR services in the case where allocation policy had dependencies into the state of the IRR; this is not the case in the ARIN region. Another reason for ARIN to offer services is if it can do so in a manner that would significantly improve their quality (one might argue such about resource certification via RPKI, but that's not as obvious for a routing registry) At the end of the day, we want ARIN to be providing quality services around the registration of Internet number resources; these services need to be valued by the community and provided cost-effectively. Do you: 1) want IRR services, and if so, with what features? 2) believe IRR services should be provided by ARIN? Getting input from the community on this will significantly help the ARIN staff make informed recommendations to the ARIN Board regarding how to best proceed. I'd also welcome private email with these thoughts if that's your preference. Thanks! /John John Curran President and CEO ARIN From randy at psg.com Sun Jan 9 17:27:06 2011 From: randy at psg.com (Randy Bush) Date: Mon, 10 Jan 2011 08:27:06 +0900 Subject: AltDB? (IRR support & direction at ARIN) In-Reply-To: References: Message-ID: > Do you: 1) want IRR services, and if so, with what features? > 2) believe IRR services should be provided by ARIN? the irr is slightly useful today. so, iff it is cheap and easy, arin providing an open and free instance is a public good. again, iff it is easy and cheap. and please do not waste time trying to 'fix' the irr, sad to say it's trying to make a silk purse out of a sow's ear. and thanks for asking. randy From jcurran at arin.net Sun Jan 9 17:27:43 2011 From: jcurran at arin.net (John Curran) Date: Sun, 9 Jan 2011 23:27:43 +0000 Subject: arin and ops fora (was Re: AltDB?) In-Reply-To: References: <59051.1294464800@nsa.vix.com> <00041A16-473F-4F96-93E8-E3CD3F83E1B2@virtualized.org> <70374.1294475040@nsa.vix.com> Message-ID: On Jan 8, 2011, at 4:11 AM, David Conrad wrote: > Another view is that ARIN's whole and sole reason for being is to provide services to the network operators in the ARIN region. As such, it would be ill-advised for ARIN to change those services without consulting the community that ARIN serves and getting their buy-in. Hopefully, there's a middle ground. Agreed. Presently, we rely upon the ARIN consultation and suggestion process for getting tactical input on operational changes. We also recognize guidance from the IETF both via IAB communications and in the form of the BCP RFC series. Obviously, if there were a convenient way for the operator community to provide consensus guidance on Internet number resource operational matters, such input would be highly valued. > On Jan 7, 2011, at 10:24 PM, Paul Vixie wrote: >> i hear in what you're saying >> a desire to have a way to impact ARIN's behaviour outside of NRPM edits >> and perhaps ARIN does need to address this with some new online forum for >> things which aren't allocation policy but which should still be decided >> using community input. > > Yep. Not sure it should be an ARIN-operated thing (nor am I sure that it shouldn't be), but something a bit more focused on the operation of services ARIN provides than ppml might be helpful. Excellent question. To the extent that it is best practices on these types of services, then that's relatively easy for ARIN to interface with... if it is specific direction to ARIN to "do xyz", then ultimately the decision rests with the ARIN Board regarding that input, since that involves how we spend the service fees of the members. On Jan 8, 2011, at 4:15 PM, David Conrad wrote: > While I think BCOPs (and BCOP BoFs) are a great idea, I guess the question is how can folks be assured that ARIN would follow a NANOG community-defined BCOP relating directly to ARIN operations. For example, if the NANOG community were to (reasonably) say "BCOP is to use IETF-defined standards for publishing and accessing resource registration data", I'd imagine ARIN might (reasonably) disagree and continue down the RWS path. If the process for forming such recommendations were fair & open to the same community, the resulting documents would be quite compelling. While that does not assure ARIN would follow them, this community has never been shy about providing feedback when the right things aren't happening... (and I'd note that a community which capable of reaching consensus on such documents is equally capable of seating a Board amenable to such documents, if there ever were to be a problem in this area) > My impression is that the various WGs and SIGs in the other RIRs perform something similar to that function. There doesn't appear to be anything similar in the ARIN region. The role is served by the ARIN Board, which is member-elected and composed of volunteers (and myself as CEO). If folks think that a more formal structure for operational input (either within ARIN or via liaison to another body) is called for, I'd suggest continued discussion on the various mailing lists. Interesting discussion... thanks for raising it. /John John Curran President and CEO ARIN From drew.weaver at thenap.com Sun Jan 9 17:30:21 2011 From: drew.weaver at thenap.com (Drew Weaver) Date: Sun, 9 Jan 2011 18:30:21 -0500 Subject: TW Telecom sales rep/national office Message-ID: I feel a bit silly asking this but I have had the hardest time finding a sales representative for the TW Telecom national group. Can someone please assist off-list? thanks, -Drew From jsw at inconcepts.biz Sun Jan 9 17:30:49 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Sun, 9 Jan 2011 18:30:49 -0500 Subject: AltDB? In-Reply-To: <1AAAEF13-B1AC-41CA-8B16-9985FD9E0EB2@arin.net> References: <59051.1294464800@nsa.vix.com> <00041A16-473F-4F96-93E8-E3CD3F83E1B2@virtualized.org> <70374.1294475040@nsa.vix.com> <5336.1294506839@nsa.vix.com> <1AAAEF13-B1AC-41CA-8B16-9985FD9E0EB2@arin.net> Message-ID: On Sun, Jan 9, 2011 at 1:09 PM, John Curran wrote: > ?Please suggest your preferred means of IRR authentication to the ARIN > ?suggestion process: > ?Alternatively, point to a best practice document from the operator > ?community for what should be done here. ARIN's work plan is very much > ?driven by community input, so that's what is needed here. John, I appreciate you taking time to respond to this while on vacation. However, I think we all know that your response is not a "here is how you tell us what to do," it's a "here is our cop-out response to make an incredibly simple fix either never happen, or take six months to make it through the ARIN process." If you truly do not understand the posts regarding this matter, I will summarize them for you very simply: 1) ARIN IRR is a tool that has operational impact; service providers use it to build prefix-lists automatically, and if the data that underlies those prefix-lists is corrupted, networks that use the ARIN IRR will see their transit providers stop accepting their BGP announcements overnight. This is not a "some database might be inaccurate but it's okay," problem; it is an operational problem. Some peoples' networks depend on that data not becoming corrupted. Specifically, every network that uses ARIN IRR. 2) ARIN IRR has effectively no security for record updates or deletes. Anyone who knows how to forge an email From: header can corrupt or delete part or all of the ARIN IRR database at any time. ARIN IRR is the only database that I am aware of without support for at least password authentication. The standard toolset supports passwords trivially. 3) If not supporting passwords was a business-driven decision, it was a bad one, but perhaps a mistake born out of ignorance. If it was a technically-driven decision by the staff members responsible for implementing and maintaining the ARIN IRR, those staff members are not qualified to handle anything of an operational nature, and you would be well-advised to find jobs for them that don't require any attentiveness to operational security. 4) The "ARIN process" will almost certainly not be the route taken when a change eventually arises. Some black hat will eventually decide it would be a clever prank to erase or corrupt the entire database, and you will then be faced with three choices; a) implement passwords immediately and not allow any updates from users who haven't selected one; b) make the ARIN IRR read-only and effectively make it useless; c) ignore the problem, at which point no ISPs will be willing to mirror the ARIN IRR anymore, because its data is a liability, not an asset. I appreciate that there is a process to go through for proposing ARIN policy changes, etc. Your suggestion that this be used when addressing an operational security matter is foolish and provides plenty of ammo for people who say ARIN is ineffective (or worse.) I suggest you take a moment to think about what the news coverage might be if this eventually blows up in a big enough way to interest news people. If a bunch of ISPs go down overnight due to an ARIN oversight, will some savvy reporter ask himself who at ARIN knew they were running an operationally-important service with no security mechanism at all? Will he have much trouble finding out about a mailing list discussion in which the CEO of ARIN glazed over the issue and referred a whistle-blowing person to the ARIN policy process? Will he then ask if ARIN is an effective steward of RPKI? Will his article assign blame to you personally? Will he draw some link to "Chinese interception of 15% of the Internet?" Who knows how mainstream press would interpret such an event, if it was big enough to attract attention. If I were you, though, I would not want my signature at the bottom of an email essentially telling someone to go post on the correct mailing list. I suggest you don't be the ARIN CEO that gets mud in his eye because he didn't understand the value of a password over mail-from. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From mansaxel at besserwisser.org Sun Jan 9 17:36:53 2011 From: mansaxel at besserwisser.org (Mans Nilsson) Date: Mon, 10 Jan 2011 00:36:53 +0100 Subject: AltDB? In-Reply-To: <1AAAEF13-B1AC-41CA-8B16-9985FD9E0EB2@arin.net> References: <70374.1294475040@nsa.vix.com> <5336.1294506839@nsa.vix.com> <1AAAEF13-B1AC-41CA-8B16-9985FD9E0EB2@arin.net> Message-ID: <20110109233650.GE23143@besserwisser.org> Subject: Re: AltDB? Date: Sun, Jan 09, 2011 at 06:09:13PM +0000 Quoting John Curran (jcurran at arin.net): > On Jan 9, 2011, at 2:09 AM, Jeff Wheeler wrote: > Please suggest your preferred means of IRR authentication to the ARIN > suggestion process: > Alternatively, point to a best practice document from the operator > community for what should be done here. ARIN's work plan is very much > driven by community input, so that's what is needed here. Just do as the other RIRen, for starters. The database sw is available, and ARIN coming up to the standards of the others would be a real improvement. -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 My mind is a potato field ... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From jsw at inconcepts.biz Sun Jan 9 17:41:38 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Sun, 9 Jan 2011 18:41:38 -0500 Subject: AltDB? (IRR support & direction at ARIN) In-Reply-To: References: Message-ID: On Sun, Jan 9, 2011 at 6:27 PM, Randy Bush wrote: >> ? Do you: 1) want IRR services, and if so, with what features? >> ? ? ? ? ? 2) believe IRR services should be provided by ARIN? > > the irr is slightly useful today. ?so, iff it is cheap and easy, arin > providing an open and free instance is a public good. ?again, iff it is > easy and cheap. ?and please do not waste time trying to 'fix' the irr, > sad to say it's trying to make a silk purse out of a sow's ear. I'm not suggesting that ARIN undertake a large and complex effort to solve a bunch of issues with IRR. All I am suggesting is that they prevent anonymous bad guys with no inside information, special access, or knowledge of passwords, from corrupting the data which some networks choose to publish in ARIN IRR. I am simply suggesting it is dangerous and irresponsible to run an IRR with only MAIL-FROM authentication, and quite easy to also support CRYPT-PW. ARIN should either support passwords or immediately make their IRR read-only and stop offering it as a service. Imagine if there was a Slashdot article or something about this, how long would it take for some 14-year-old to erase the whole database, and how that would pretty much force ARIN to make a choice anyway, but also, create a lot of negative fall-out that might jeopardize trust in ARIN with regard to other operational matters, like RPKI. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From randy at psg.com Sun Jan 9 17:48:30 2011 From: randy at psg.com (Randy Bush) Date: Mon, 10 Jan 2011 08:48:30 +0900 Subject: AltDB? (IRR support & direction at ARIN) In-Reply-To: References: Message-ID: >>> ? Do you: 1) want IRR services, and if so, with what features? >>> ? ? ? ? ? 2) believe IRR services should be provided by ARIN? >> >> the irr is slightly useful today. ?so, iff it is cheap and easy, arin >> providing an open and free instance is a public good. ?again, iff it is >> easy and cheap. ?and please do not waste time trying to 'fix' the irr, >> sad to say it's trying to make a silk purse out of a sow's ear. > > I'm not suggesting that ARIN undertake a large and complex effort to > solve a bunch of issues with IRR. jeff, i do not disagree that running an irr instance with only mail-from is soooo 1980s. and, as mans points out, there is free software out there to do it (i recommend irrd). but i do not see good cause for arin to spend anything non-trivial to fix a problem in an irr instance which is not used very much. i.e. better to drop it than to spend non-trivial money to modernize it. but more to the point, by 'fix' it, i did not mean modernizing the auth method set. i meant the content, syntax and semantics. randy From jsw at inconcepts.biz Sun Jan 9 17:57:43 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Sun, 9 Jan 2011 18:57:43 -0500 Subject: AltDB? (IRR support & direction at ARIN) In-Reply-To: References: Message-ID: On Sun, Jan 9, 2011 at 6:48 PM, Randy Bush wrote: > jeff, i do not disagree that running an irr instance with only mail-from > is soooo 1980s. ?and, as mans points out, there is free software out > there to do it (i recommend irrd). ?but i do not see good cause for arin > to spend anything non-trivial to fix a problem in an irr instance which > is not used very much. ?i.e. better to drop it than to spend non-trivial > money to modernize it. I agree that if ARIN thinks it would be "too costly" to support password authentication, they should make the database read-only so users will migrate away from it and no damage can be done by "bad guys." > but more to the point, by 'fix' it, i did not mean modernizing the auth > method set. ?i meant the content, syntax and semantics. I understood what you meant, and again, I agree with you; there is no reason to invest "a lot" of time and resources in something that should be made obsolete by other work already in progress. The "fix" I want is simply eliminating the large liability by continuing to allow updates with MAIL-FROM authentication. I believe ARIN IRR actually does support MD5 authentication, but if you email the ARIN IRR person, or go to ARIN's web site, you are told that only MAIL-FROM is allowed. So they probably already have the appropriate technical mechanism in place AND JUST AREN'T USING IT, and are actively discouraging users from utilizing it. This would be an example of ARIN's ineffectiveness when it comes to operational matters, and is why I have real fear that RPKI may one-day be a disaster because ARIN is an ineffective steward. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From jcurran at arin.net Sun Jan 9 18:33:18 2011 From: jcurran at arin.net (John Curran) Date: Mon, 10 Jan 2011 00:33:18 +0000 Subject: AltDB? In-Reply-To: References: <59051.1294464800@nsa.vix.com> <00041A16-473F-4F96-93E8-E3CD3F83E1B2@virtualized.org> <70374.1294475040@nsa.vix.com> <5336.1294506839@nsa.vix.com> <1AAAEF13-B1AC-41CA-8B16-9985FD9E0EB2@arin.net> Message-ID: <5D5B7D2A-4F9A-4DB2-8D4D-03296FF4AEE8@arin.net> On Jan 9, 2011, at 6:30 PM, Jeff Wheeler wrote: > > John, > > I appreciate you taking time to respond to this while on vacation. > However, I think we all know that your response is not a "here is how > you tell us what to do," it's a "here is our cop-out response to make > an incredibly simple fix either never happen, or take six months to > make it through the ARIN process." Jeff - As it turned out, I'm back from vacation but thanks for the thought. My reason for responding is simply to make sure that ARIN is doing what the community wants. I won't deny that this may take some time depending on exactly what is involved, but in my mind that is far better than not fixing the situation. > If you truly do not understand the posts regarding this matter, I will > summarize them for you very simply: > 1) ARIN IRR is a tool that has operational impact; service providers > use it to build prefix-lists automatically, and if the data that > underlies those prefix-lists is corrupted, networks that use the ARIN > IRR will see their transit providers stop accepting their BGP > announcements overnight. This is not a "some database might be > inaccurate but it's okay," problem; it is an operational problem. > Some peoples' networks depend on that data not becoming corrupted. > Specifically, every network that uses ARIN IRR. Thanks; I'm aware of the ARIN IRR and how operators in the community make use of it, and have run ISPs which have made use of the data for route filtering. > ... > I appreciate that there is a process to go through for proposing ARIN > policy changes, etc. Your suggestion that this be used when > addressing an operational security matter is foolish and provides > plenty of ammo for people who say ARIN is ineffective (or worse.) Agreed; dropping me an email is a fine process for operational security matters. Consider this one so reported. /John John Curran President and CEO ARIN From leen at consolejunkie.net Sun Jan 9 18:57:29 2011 From: leen at consolejunkie.net (Leen Besselink) Date: Mon, 10 Jan 2011 01:57:29 +0100 Subject: Problems with removing NAT from a network In-Reply-To: <4D2959D7.7040407@matthew.at> References: <4D252B1F.8030506@kenweb.org> <3DFD6833-78C1-43D2-8074-6C89CFE3F2F3@arbor.net> <20110106043110.21C96876D21@drugs.dv.isc.org> <4D254ED8.6030006@matthew.at> <4D25F971.4090709@matthew.at> <4D2634E7.2060502@matthew.at> <9DEED87C-ED15-4D05-BCD6-69A5D4A69681@delong.com> <4D267B9E.8040602@bogus.com> <4D268119.2050205@matthew.at> <4D284798.3010806@consolejunkie.net> <4D2959D7.7040407@matthew.at> Message-ID: <4D2A5979.6050606@consolejunkie.net> On 01/09/2011 07:46 AM, Matthew Kaufman wrote: > On 1/8/2011 3:16 AM, Leen Besselink wrote: >> >> Hello Mr. Kaufman, >> >> In the upcoming years, we will have no IPv6 in some places and badly >> performing IPv4 (CGN, etc.) with working IPv6 in others. > Right. So we're discussing just how "badly performing" the IPv4 can be > and still be acceptable as "access to the IPv4 Internet for your > customers". > > I am arguing that CGN (NAT44 to get additional IPv4 to dual-stack) > doesn't break nearly as much as NAT64/DNS64 does, and that in fact > NAT64/DNS64 breaks *so much* that you probably can't/shouldn't sell it > to your customers as "access to the IPv4 Internet". > I think there will be CGN's and NAT64/DNS64 which will add extra latency and may be overloaded at times. But I also currently still see a fragmented IPv6 Internet where not everyone can reach everyone. So currently IPv6 isn't ready and IPv4 is still working, but for how long ? > Note that for a *very* long time... much longer than there will be new > IPv4 addresses available... there will be a whole lot of places that > have good IPv4 and no IPv6. (As you note above) > Personally I hope there be a lot of places where we have good IPv4 and good IPv6. Looking at the history of IPv6 I would have liked to see more of that today. Yes, it will be a long time before IPv4 will suck in a lot of places. But that is no reason for not deploying IPv6 in the network everywhere now. That is what we are doing. >> If I was Skype I would make really sure that all my relay nodes and >> login servers have IPv6 with enough bandwidth or can easily upgrade the >> bandwidth where neede. And make sure atleast IPv6-client and >> IPv6-servers communication works everywhere where there is IPv6. > Clearly that would be needed to serve the IPv6-only users well. And the dual-stack customers, CGN with IPv6 customers and NAT64/DNS64 customers who want to talk to IPv6-only users. >> >> For your customers it is really easy. When Skype does not work, people >> will jump ship where they can and maybe use Google Talk or whatever. > Ah. But you're taking the bet that when Skype does not work on *your* > network that provides IPv4 access via NAT64 people won't "jump ship" > to a provider that uses CGN or even has enough native IPv4 addresses > left around. I couldn't care less about what Skype does, it was just advice. I'm in the content-/hosting-business. Most of what we have on our network is websites. For that I can only choose between 2 things publish no AAAA record in DNS or publish an AAAA-record in DNS for our hosted websites. I could try to do this selectively or per network basis like Google does, but that is about it. As IPv6 is a reality, all I can do is choose when to add the AAAA-record. >> I suggest making sure you include both IPv4 and IPv6 addresses in your >> protocol, maybe it needs to be extended. So that the client at the other >> end can choose what IP-version to use. Or can try both. Maybe the >> login-server can help to decide for the client. But those login servers >> will need to have good IPv6 connectivity to be able to do so. > But none of that solves the problem of talking from an IPv6 client > that has broken IPv4 access (NAT64) to a an IPv4 client that has no > IPv6 access. > I'm just suggesting you add it to give you more flexibility. If you have more information and more paths to/from and between your customers you have more options to allow them to talk directly. I've seen a discussion about DNSSEC and DNS64/NAT64 as well and it would be really good to have some pointers maybe in the additional section of the DNS-response or something like EDNS0 to tell us that the DNS64-translation has happend. NAT64/DNS64 will suck if they do deploy it, I would rather see CGN too. To be honest I don't think that will be great either on the long run. I would like to see everyone deploy IPv6 already. Take for example the access-provider for my home connection, it looks like their network will be ready for IPv6 maybe next year. From my experience with deploying IPv6 their are always problems which need extra time. So next year might be on time, but who says they will make that 'deadline'. >> I'm sorry if it sounds a bit like fear mongering, but to me it sounds >> like common sense that if a business is not prepared when the >> environment that business operates in changes and that business does not >> adapt to the changes in time that business might suffer. > But that's true of ISPs when they choose how to deal with the lack of > additional IPv4 space but continued customer demand to reach the IPv4 > Internet, too, isn't it? > Yes, as a content-/hosting-provider or creator of a network application as yourself I hope that everywhere where IPv6 has been deployed it works well. If it is true what someone else mentioned that the mobile operators choose to all deploy NAT64/DNS64 then that sucks. But I fully understand it, if they as an industry can't get the equipment manufacturers to deliver them products which don't cost them twice as much if they deploy IPv4 and IPv6 at the same time then they have a hard choice to make. It looks like they already made their choice. The mobile stack has many parts and paying twice for a lot of those parts is a hard to sell to management. > Matthew Kaufman > From jsw at inconcepts.biz Sun Jan 9 20:53:31 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Sun, 9 Jan 2011 21:53:31 -0500 Subject: AltDB? In-Reply-To: <5D5B7D2A-4F9A-4DB2-8D4D-03296FF4AEE8@arin.net> References: <59051.1294464800@nsa.vix.com> <00041A16-473F-4F96-93E8-E3CD3F83E1B2@virtualized.org> <70374.1294475040@nsa.vix.com> <5336.1294506839@nsa.vix.com> <1AAAEF13-B1AC-41CA-8B16-9985FD9E0EB2@arin.net> <5D5B7D2A-4F9A-4DB2-8D4D-03296FF4AEE8@arin.net> Message-ID: On Sun, Jan 9, 2011 at 7:33 PM, John Curran wrote: > My reason for responding is simply to make sure that ARIN is doing > what the community wants. ?I won't deny that this may take some time > depending on exactly what is involved, but in my mind that is far > better than not fixing the situation. How will ARIN respond to operational security matters with regard to RPKI infrastructure in the future? What experience does ARIN have with operational security in the past? When faced with DNS server vulnerabilities, did ARIN solicit community feedback before patching the servers responsible for IN-ADDR.ARPA zones administered by ARIN? Or did ARIN treat this matter as a legitimate, operational security concern, and apply whatever technical solution was available and generally accepted by other organizations administering DNS servers? Why should an operational security issue with the ARIN IRR be handled as a policy issue? Do you know that I have emailed ARIN about this both recently and in years past? Am I the only person who has ever tried to bring this to ARIN's attention? I doubt that. Are the personnel managing the ARIN IRR oblivious to the fact that every other IRR database except ARIN supports at least some form of password authentication? Are these personnel qualified to handle services with operational impact? Do you, or they, know that ARIN's IRR technical infrastructure actually does support password security, and that records exist in the ARIN IRR database with MD5 authentication, but that email to ARIN about this are answered with replies that only MAIL-FROM is possible? Why does the ARIN web site make no mention of anything besides MAIL-FROM? > Thanks; I'm aware of the ARIN IRR and how operators in the community > make use of it, and have run ISPs which have made use of the data > for route filtering. When you ran ISPs that made use of IRR data for route filtering, did you use any kind of authentication when publishing and maintaining your own records, or advise customers to use such? Did the possibility of malicious data corruption or erasure ever enter your mind? > Agreed; dropping me an email is a fine process for operational > security matters. ?Consider this one so reported. What will the process be for handling operational security issues regarding future RPKI infrastructure? It is conceivable that there may be no alternative to ARIN, in the ARIN region, for trusted routing information data in the future. Today, we can choose not to use ARIN IRR, and the huge majority of networks who publish IRR data use their ISP databases or MERIT RADB. Are we faced with the possibility that ARIN simply doesn't have personnel capable of handling operational services, yet are forcing ARIN down a road that may make them a sole source of something we all need? If so, perhaps this is a very bad idea in need of further debate. I think the mentality at ARIN is one of paper-pushers and policy guys. That's perfectly fine for an organization whose main function is ... processing paperwork and allocating IP addresses. It is perhaps a very bad idea to ask ARIN to do operational things which they are very clearly unprepared to handle, to such an extent that they may need additional or different personnel, and really need to change their mentality. I understand that the technical side of the RPKI implementation at ARIN is most likely entrusted to Paul Vixie and ISC, which is a good thing. I never read an email from Paul saying, "I think we need to solicit feedback before we patch this BIND issue." DNSSEC progress has taken a very long time, but that hasn't stopped ISC from continuing to provide quick technical solutions to immediate technical problems. What really worries me is ... if there is some serious issue with RPKI infrastructure in the future, will ARIN be able to solve it in an operational time-frame, or won't they? -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From jcurran at arin.net Sun Jan 9 21:47:39 2011 From: jcurran at arin.net (John Curran) Date: Mon, 10 Jan 2011 03:47:39 +0000 Subject: AltDB? In-Reply-To: References: <59051.1294464800@nsa.vix.com> <00041A16-473F-4F96-93E8-E3CD3F83E1B2@virtualized.org> <70374.1294475040@nsa.vix.com> <5336.1294506839@nsa.vix.com> <1AAAEF13-B1AC-41CA-8B16-9985FD9E0EB2@arin.net> <5D5B7D2A-4F9A-4DB2-8D4D-03296FF4AEE8@arin.net> Message-ID: <1F4CC55D-1628-4086-9EDC-AE6B9BD2E236@arin.net> On Jan 9, 2011, at 9:53 PM, Jeff Wheeler wrote: > > Why should an operational security issue with the ARIN IRR be handled > as a policy issue? Operational security matters should simply be fixed; that's not a policy matter but an implementation issue. > Do you know that I have emailed ARIN about this both recently and in > years past? Am I the only person who has ever tried to bring this to > ARIN's attention? I doubt that. Good to know; I'm rather interesting in knowing some particulars here, so can you forward to me one or two of those messages? (or just let me know the 'To' field used and I'll take it from there) > What will the process be for handling operational security issues > regarding future RPKI infrastructure? It is conceivable that there > may be no alternative to ARIN, in the ARIN region, for trusted routing > information data in the future. Today, we can choose not to use ARIN > IRR, and the huge majority of networks who publish IRR data use their > ISP databases or MERIT RADB. Are we faced with the possibility that > ARIN simply doesn't have personnel capable of handling operational > services, yet are forcing ARIN down a road that may make them a sole > source of something we all need? If so, perhaps this is a very bad > idea in need of further debate. Feel free to discuss on this list (if deemed in charter) or arin-discuss as you feel appropriate. > I think the mentality at ARIN is one of paper-pushers and policy guys. > That's perfectly fine for an organization whose main function is ... > processing paperwork and allocating IP addresses. It is perhaps a > very bad idea to ask ARIN to do operational things which they are very > clearly unprepared to handle, to such an extent that they may need > additional or different personnel, and really need to change their > mentality. Jeff - ARIN does indeed have folks who worry about whether the policy development process is being followed. We also have folks who actually implement the policy and issue number resources. What you may not know is that we also have quite a few folks who have run production operational services both for the Internet and other mission-critical environments. I'm not surprised that the IRR allows plaintext passwords, but am myself stunned if indeed we require them, since that disallows even a modicum of protection from trivial acts of sabotage. Rather than repeat what lack of information there is on the web site in regards to what forms of IRR authentication is available, I will go determinate the state of reality and post back here asap. At a minimum, we need much clearer documentation, but if more is required, we'll get it fixed asap. /John John Curran President and CEO ARIN From charles at knownelement.com Sun Jan 9 22:00:18 2011 From: charles at knownelement.com (Charles N Wyble) Date: Sun, 09 Jan 2011 20:00:18 -0800 Subject: AltDB? (IRR support & direction at ARIN) In-Reply-To: References: Message-ID: <4D2A8452.4070900@knownelement.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/09/2011 03:41 PM, Jeff Wheeler wrote: > On Sun, Jan 9, 2011 at 6:27 PM, Randy Bush wrote: >>> Do you: 1) want IRR services, and if so, with what features? >>> 2) believe IRR services should be provided by ARIN? >> > > I am simply suggesting it is dangerous and irresponsible to run an IRR > with only MAIL-FROM authentication, and quite easy to also support > CRYPT-PW. ARIN should either support passwords or immediately make > their IRR read-only and stop offering it as a service. Imagine if > there was a Slashdot article or something about this, how long would > it take for some 14-year-old to erase the whole database, and how that > would pretty much force ARIN to make a choice anyway, but also, create > a lot of negative fall-out that might jeopardize trust in ARIN with > regard to other operational matters, like RPKI. So why hasn't this happened already? If it's so easy, then all the normal actors that like to cause us late nights would have struck already. And according to http://www.irr.net/docs/list.html there are lots of IRR databases. I had a vague concept of IRR before this thread, and have researched them as a result of it. They seem quite useful. I didn't know anything about RPKI before this thread. I'm looking into that now. So I don't think ARIN should spend it's limited resources on anything to do with it's copy of the IRR. In fact I'm not sure why they even operate one. It seems to be the realm of service providers to do so. Can anyone enlighten me as to why a RIR is operating an IRR database? It doesn't make sense to me. - -- Charles N Wyble (charles at knownelement.com) Systems craftsman for the stars http://www.knownelement.com Mobile: 626 539 4344 Office: 310 929 8793 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNKoRSAAoJEMvvG/TyLEAtjuUP/0HsjYoulhixWOp/2LRMzll+ zc0YBVOD+mebDyM2tPdXN/UGVVQCrhdakbWOkbRsn1+qHOZEK0SKI41cnWineluB z4xxEXVSbOb3wRfqVr+WwNilZnQIST8p6IddEShJ283ZDvFBa7f6b80POue28SU2 DSFW0DWL+Ti38tGyXBuiPSBMWNY4mRUJQDznz5msiXLiWTzHIUeXmiyGErbR0R+f OPK5SPUvkJvI1G2ytqqWdzkelCgp78O6uQzVM0443ZvdN4HBEq45ac82+t3pR99q 2DgTnU4mWjMiQBZxWAZidqxW7Rsl3K4Zbr1lJEQ8R5Ke9PQzLD2cd8k0AKUFOg3M rNY/wz2ha75G38k9f4OqglCcwQOglGwXX1ASWCjKM9ISVcq0+m/SyOnlmtf/fRLH R+LdX8fntpCMv6kxjqAojBghOmaso9NvrW0umHqT0XSMZRuHGOIP4XYj+Rws/TwI IFV4gQLNCoqEswq5vreM2cMzTIFXJDsS8Pd4HS/g+c+teIMC/8TIIs4EUMhX2wPY O5iW8PiDCLnbwXT0OrPDHjz1M5Xl5fNduAvjsTnN0Kn7jc+TwRuTIoPJudKxqa9A L6MDGEYgK7nyboARUYmPrB9f+/FMA9jKTXD2b5j7ZiTj0bWxByU1BL6V2eBtDwdd GPMgRarxix8cp2Stn4dx =shdY -----END PGP SIGNATURE----- From charles at knownelement.com Sun Jan 9 22:09:16 2011 From: charles at knownelement.com (Charles N Wyble) Date: Sun, 09 Jan 2011 20:09:16 -0800 Subject: AltDB? (IRR support & direction at ARIN) In-Reply-To: References: Message-ID: <4D2A866C.7060700@knownelement.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/09/2011 03:48 PM, Randy Bush wrote: >>>> Do you: 1) want IRR services, and if so, with what features? I think so. In theory it seems useful. In practice... http://www.renesys.com/blog/2009/05/keeping-score.shtml not so much. >>>> 2) believe IRR services should be provided by ARIN? No. As I mentioned elsewhere in this thread, I don't see why an RIR is operating an IRR database. It seems to be something clearly in the realm of service providers (ie people who are making use of allocated resources). John, Can you shed some light on why this is the case? Was this requested by the community, or driven internally? Or both? - -- Charles N Wyble (charles at knownelement.com) Systems craftsman for the stars http://www.knownelement.com Mobile: 626 539 4344 Office: 310 929 8793 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNKoZsAAoJEMvvG/TyLEAt/xsP/2CC55GEeTO46/QB2UN3RWwZ MxiLAIgurtyHTjeh9Gr6dfujnx5si6HP1Kxv+ET3HDapyOc4M8yfugvuSfrAMz1Z A/ObcWbHwtTFvii6ULtE4w7+AU1Msy7XQIPluh9g3fYk85+fBdMvE45Hyw1je04o SidM3m9XP5jCDMcKNgbSN90ibf8GykgzR6u0fExRxUta0bhHrTWZM15oVSpXeCGN Kl/6E0QSd1DbQvWxvQPotMCHoaEulAjPt4kKiBAKnxAAGsB1aC2ceMZ5PI2xeNeB pZcsWqiaemhnDmlUyPE5xjoVYSUxFk5R99RV4PfGBbAf7TyZJFAhfsm3yHqYVefN EIaguXaB0T1ekCJuBzgljExNnrMCTllx8j5GmLAQrgusrkBna61OFknp/DzVzWjS cxb60AKVbJX8kfvFdxd//zw4+15qflslrBFoGx+8/eJItzCuE5sggj4vQj9lSO5p ocvl7zbVkiYsw0EfDcJAlVpj3VGC4V93k0h8Rkh9oIykqJuO0JC7VSB7ZBwjM43t AN7/Kjqhp0e19ztUiIjFpFW3Gi9Bpw0M8KMPo8pX27W4sXcG/CMlu2jTwadiKQyR Dk+7a5B9qVvgLC4c1ygYzfyPYJzvq78CYa+vpsBl3Wl0vgLNSLicPg9gN/87fJhU kt4lYu8javFnsFGQbH69 =Bc5T -----END PGP SIGNATURE----- From cgucker at onesc.net Sun Jan 9 23:22:23 2011 From: cgucker at onesc.net (Charles Gucker) Date: Mon, 10 Jan 2011 00:22:23 -0500 Subject: AltDB? (IRR support & direction at ARIN) In-Reply-To: <4D2A8452.4070900@knownelement.com> References: <4D2A8452.4070900@knownelement.com> Message-ID: > I had a vague concept of IRR before this thread, and have researched > them as a result of it. They seem quite useful. I didn't know anything > about RPKI before this thread. I'm looking into that now. > > So I don't think ARIN should spend it's limited resources on anything to > do with it's copy of the IRR. In fact I'm not sure why they even operate > one. It seems to be the realm of service providers to do so. > > Can anyone enlighten me as to why a RIR is operating an IRR database? It > doesn't make sense to me. Sure. I've been staying quiet on this thread, but as one person who has used (and still maintains a number of records) ARIN's IRRd, I'll respond. Firstly, There are many networks with whom want to put their IRR objects into a neutral and objective database. I know that AltDB is "free", but as I've been told before, if you want support, donate to "Abha Ahuja Women in Science in Engineering" scholarship fund, otherwise your maintainer objects will never be approved (know this one first hand). And RADB, with whom used to be free charges a fee to have records maintained via their web GUI. Many network operators don't want to directly pay for such services, so ARIN makes sense in this regard. My original alternative was to setup my own IRRd, but was glad not to have to go to the trouble. Secondly, ARIN's IRRd is a lot easier to use than any service provider IRRd as those are intended for customer records only and if you wish to leave them, they will delete your records or just simply deny you support. Especially when said providers mirror ARIN's database. It's much like using PA vs PI IP space. If you want to be indebted to your provider, continue to use their "free" services. Thirdly, with the above in mind, ARIN provides support to all members of ARIN, so you can get a real person on the phone or by email to respond to questions. So, all in all, I am grateful that ARIN has supplied the IRRd service, would love to see the authentication enhanced, but otherwise I don't have any complaints. I encourage others to use the service regularly and am glad to see it getting some attention, we just need to make sure to channel the attention into enhancements and not limitations. thanks, charles From owen at delong.com Sun Jan 9 23:51:56 2011 From: owen at delong.com (Owen DeLong) Date: Sun, 9 Jan 2011 21:51:56 -0800 Subject: Problems with removing NAT from a network In-Reply-To: <4D2959D7.7040407@matthew.at> References: <4D252B1F.8030506@kenweb.org> <3DFD6833-78C1-43D2-8074-6C89CFE3F2F3@arbor.net> <20110106043110.21C96876D21@drugs.dv.isc.org> <4D254ED8.6030006@matthew.at> <4D25F971.4090709@matthew.at> <4D2634E7.2060502@matthew.at> <9DEED87C-ED15-4D05-BCD6-69A5D4A69681@delong.com> <4D267B9E.8040602@bogus.com> <4D268119.2050205@matthew.at> <4D284798.3010806@consolejunkie.net> <4D2959D7.7040407@matthew.at> Message-ID: <50F0FF27-DE27-40BC-AB71-0B9EBCD7D0E3@delong.com> On Jan 8, 2011, at 10:46 PM, Matthew Kaufman wrote: > On 1/8/2011 3:16 AM, Leen Besselink wrote: >> >> Hello Mr. Kaufman, >> >> In the upcoming years, we will have no IPv6 in some places and badly >> performing IPv4 (CGN, etc.) with working IPv6 in others. > Right. So we're discussing just how "badly performing" the IPv4 can be and still be acceptable as "access to the IPv4 Internet for your customers". > > I am arguing that CGN (NAT44 to get additional IPv4 to dual-stack) doesn't break nearly as much as NAT64/DNS64 does, and that in fact NAT64/DNS64 breaks *so much* that you probably can't/shouldn't sell it to your customers as "access to the IPv4 Internet". > NAT44 perhaps, but, the problem is that most CGNs proposed aren't NAT44, they're at best NAT444 and likely more like NAT44444 or worse in the real world. Today, we have NAT44->Internet<-NAT44 in many sessions (Skype, VOIP, etc.) which connect to each other via STUN, UPnP, etc. Once you move from NAT44 to NAT444, most of the working traversal mechanisms break in interesting ways and at NAT44444, virtually nothing peer-to-peer-ish gets through at all as you simply can't abstract UPnP or anything else through that many layers at either end. With CGN, the details look more like: NAT44->ISP->NAT44->Internet<-NAT44<-ISP<-NAT44 Giving us NAT44444. > Note that for a *very* long time... much longer than there will be new IPv4 addresses available... there will be a whole lot of places that have good IPv4 and no IPv6. (As you note above) > I think this "*very* long time" will be much shorter than you think for meaningful values of "whole lot of places". >> If I was Skype I would make really sure that all my relay nodes and >> login servers have IPv6 with enough bandwidth or can easily upgrade the >> bandwidth where neede. And make sure atleast IPv6-client and >> IPv6-servers communication works everywhere where there is IPv6. > Clearly that would be needed to serve the IPv6-only users well. I think this is definitely the ideal first step, but, I confess I don't know the inner workings of Skype. Even this is probably a large effort in their codebase, so, I hope they've started working on it. >> >> For your customers it is really easy. When Skype does not work, people >> will jump ship where they can and maybe use Google Talk or whatever. > Ah. But you're taking the bet that when Skype does not work on *your* network that provides IPv4 access via NAT64 people won't "jump ship" to a provider that uses CGN or even has enough native IPv4 addresses left around. I'm betting Skype breaks just as bad in many CGN environments and that the most likely candidate to actually work will be B4/AFTR or DS-Lite. However, there are different problems that come up there as well. >> I suggest making sure you include both IPv4 and IPv6 addresses in your >> protocol, maybe it needs to be extended. So that the client at the other >> end can choose what IP-version to use. Or can try both. Maybe the >> login-server can help to decide for the client. But those login servers >> will need to have good IPv6 connectivity to be able to do so. > But none of that solves the problem of talking from an IPv6 client that has broken IPv4 access (NAT64) to a an IPv4 client that has no IPv6 access. > Nor will anything else and broken IPv4 access is an apt term to describe any of: NAT64 DS-LITE/B4/AFTR CGN/LSN They each have their own brand of broken IPv4. Let's face it, while the existing IPv4 internet isn't going to suddenly break when we run out of available addresses, it is going to slowly suffer from increased breakage as we attempt to recycle those addresses in ever more creative and unintended ways. >> I'm sorry if it sounds a bit like fear mongering, but to me it sounds >> like common sense that if a business is not prepared when the >> environment that business operates in changes and that business does not >> adapt to the changes in time that business might suffer. > But that's true of ISPs when they choose how to deal with the lack of additional IPv4 space but continued customer demand to reach the IPv4 Internet, too, isn't it? > Yep. Owen From owen at delong.com Mon Jan 10 00:24:06 2011 From: owen at delong.com (Owen DeLong) Date: Sun, 9 Jan 2011 22:24:06 -0800 Subject: Problems with removing NAT from a network In-Reply-To: <4D2A5979.6050606@consolejunkie.net> References: <4D252B1F.8030506@kenweb.org> <3DFD6833-78C1-43D2-8074-6C89CFE3F2F3@arbor.net> <20110106043110.21C96876D21@drugs.dv.isc.org> <4D254ED8.6030006@matthew.at> <4D25F971.4090709@matthew.at> <4D2634E7.2060502@matthew.at> <9DEED87C-ED15-4D05-BCD6-69A5D4A69681@delong.com> <4D267B9E.8040602@bogus.com> <4D268119.2050205@matthew.at> <4D284798.3010806@consolejunkie.net> <4D2959D7.7040407@matthew.at> <4D2A5979.6050606@consolejunkie.net> Message-ID: <824C2E7D-A9E5-4226-AE09-FE8F23ED13E0@delong.com> On Jan 9, 2011, at 4:57 PM, Leen Besselink wrote: > On 01/09/2011 07:46 AM, Matthew Kaufman wrote: >> On 1/8/2011 3:16 AM, Leen Besselink wrote: >>> >>> Hello Mr. Kaufman, >>> >>> In the upcoming years, we will have no IPv6 in some places and badly >>> performing IPv4 (CGN, etc.) with working IPv6 in others. >> Right. So we're discussing just how "badly performing" the IPv4 can be >> and still be acceptable as "access to the IPv4 Internet for your >> customers". >> >> I am arguing that CGN (NAT44 to get additional IPv4 to dual-stack) >> doesn't break nearly as much as NAT64/DNS64 does, and that in fact >> NAT64/DNS64 breaks *so much* that you probably can't/shouldn't sell it >> to your customers as "access to the IPv4 Internet". >> > > I think there will be CGN's and NAT64/DNS64 which will add extra latency > and may be overloaded at times. But I also currently still see a > fragmented IPv6 Internet where not everyone can reach everyone. So > currently IPv6 isn't ready and IPv4 is still working, but for how long ? > We're trying to do everything we can to resolve the fragmentation. We have offered on numerous occasions to peer with both of the providers that are currently segmented from our ASN (6939), going even so far as baking a cake for Cogent (AS174). Our attempts to resolve this continue to this day and we remain willing to peer with anyone that is able to reach us physically. We have an aggressively open peering policy. If you are segmented from our network, we encourage you to either peer directly with us, encourage your upstream(s) to peer with us, or, connect to us with a fee BGP tunnel for the time being. If anyone is having trouble getting "unsegmented" from AS6939, they are welcome to send me email and I will make sure we do whatever we can to assist in resolving the matter. Owen From jsw at inconcepts.biz Mon Jan 10 00:33:40 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Mon, 10 Jan 2011 01:33:40 -0500 Subject: AltDB? In-Reply-To: <1F4CC55D-1628-4086-9EDC-AE6B9BD2E236@arin.net> References: <59051.1294464800@nsa.vix.com> <00041A16-473F-4F96-93E8-E3CD3F83E1B2@virtualized.org> <70374.1294475040@nsa.vix.com> <5336.1294506839@nsa.vix.com> <1AAAEF13-B1AC-41CA-8B16-9985FD9E0EB2@arin.net> <5D5B7D2A-4F9A-4DB2-8D4D-03296FF4AEE8@arin.net> <1F4CC55D-1628-4086-9EDC-AE6B9BD2E236@arin.net> Message-ID: On Sun, Jan 9, 2011 at 10:47 PM, John Curran wrote: > Jeff - ARIN does indeed have folks who worry about whether the policy > development process is being followed. ?We also have folks who actually > implement the policy and issue number resources. And we all agree that this is ARIN's primary role, and what ARIN, organizationally, has been built to be good at. This is what members consider when electing the BoT and no doubt drives ARIN's day-to-day business and technical decisions. > is that we also have quite a few folks who have run production operational > services both for the Internet and other mission-critical environments. What does ARIN, as an organization, do that has short-term operational impact on its members? Two things that I am aware of: IN-ADDR.ARPA delegation and IRR. One of these things gives people no reason to complain. The other is demonstrably insecure in a manner that could have really serious, and embarrassing, consequences, both financial for the members, and in terms of peoples' confidence in ARIN. > I'm not surprised that the IRR allows plaintext passwords, but am myself > stunned if indeed we require them, since that disallows even a modicum of > protection from trivial acts of sabotage. ?Rather than repeat what lack > of information there is on the web site in regards to what forms of IRR > authentication is available, I will go determinate the state of reality > and post back here asap. At a minimum, we need much clearer documentation, > but if more is required, we'll get it fixed asap. Thanks, I am glad you are now looking into this. To be clear, it's not just "plain text passwords." There aren't any passwords for the majority of objects. The ARIN documentation indicates that only MAIL-FROM is supported. When asked about this, ARIN personnel who respond to rtreg at arin.net reply that yes, MAIL-FROM is the only authentication mechanism supported, and that no, there is no support for passwords (good) or PGP (also good, but too complicated for some users.) This isn't simply an issue of "plain text passwords." Your mechanism is MAIL-FROM, which means the only check that is done on update/add/delete requests is the From: header. The ARIN database, which is publicly mirrored, contains the email addresses that must be used to add/update/delete objects maintained by a given mntner: object. All you have to do to corrupt or erase a record is look up the record you want to corrupt in the IRR, then look up that mntner, then forge an email from the auth: MAIL-FROM listed in that mntner record. It's dead simple and it is not "plain text passwords," it is no passwords at all. The reason I am still posting is I am deeply concerned about the lack of technical and management competence needed to let this happen in the first place. You shouldn't seriously believe that no ARIN staffer ever thought about this, while also believing that ARIN is currently capable of administering RPKI, by its very nature and as its primary goal, to improve operational network security. For this reason, I think your true task is not simply to address the IRR issue, but to change the mentality at ARIN. If you do have technically skilled personnel, something is preventing them from being effective. If there isn't a management or cultural problem stopping folks from speaking up, then, quite frankly, I think you may be greatly over-estimating the technical savvy of ARIN staff. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From jsw at inconcepts.biz Mon Jan 10 00:52:22 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Mon, 10 Jan 2011 01:52:22 -0500 Subject: AltDB? (IRR support & direction at ARIN) In-Reply-To: <4D2A8452.4070900@knownelement.com> References: <4D2A8452.4070900@knownelement.com> Message-ID: On Sun, Jan 9, 2011 at 11:00 PM, Charles N Wyble wrote: > So why hasn't this happened already? If it's so easy, then all the > normal actors that like to cause us late nights would have struck already. As most of us in the net ops community know, there are many vulnerabilities that are very much non-obvious to a black hat guy used to DDoSing with botnets or exploiting the latest common daemon vulnerability. That is no assurance that this vulnerability will never be exploited. The very fact that we are talking about it on this mailing list (unfortunately) raises the chances that it will happen. If there was an article on Slashdot, I bet significant corruption pranks or deliberate, malicious erasure would happen inside of a week. If I spent 15 minutes making a "HOWTO anonymously delete an ISP from the ARIN IRR with a telnet client and an open proxy" and spread it around to some IRC bad-guys, you can be assured we would be talking about damage control, not prevention, by tomorrow. Finally, anyone who has ever 1) learned how email works; and 2) learned how to update their own IRR objects via email; can do it without reading anything, and has probably realized this vulnerability on their own years ago. > So I don't think ARIN should spend it's limited resources on anything to > do with it's copy of the IRR. In fact I'm not sure why they even operate > one. It seems to be the realm of service providers to do so. It is desirable to publish your IRR records in a neutral database, as opposed to a service provider database. Let's say I am a Level3 customer and I use their IRR. A year goes by, and I don't renew my contract with Level3, I instead start buying transit from AT&T. Well, AT&T does not operate an IRR database. Now I have to find a new place to publish my IRR data, *and* my new transit provider doesn't offer it as a service. If I have a need for IRR, I had better hope one of my other transit providers offers me a database, or use RADB, ALTDB, or another third-party database. This is why MERIT has a bunch of customers paying annual fees for RADB, a valuable service; and why some great folks volunteer their time to maintain the ALTDB. It is also no doubt the reason ARIN has an IRR database, but unfortunately, the ARIN IRR is a liability, not an asset, to the net ops community. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From brandon at rd.bbc.co.uk Mon Jan 10 04:51:34 2011 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Mon, 10 Jan 2011 10:51:34 GMT Subject: Problems with removing NAT from a network Message-ID: <201101101051.KAA14187@sunf10.rd.bbc.co.uk> > We have offered on numerous occasions to peer with both of the > providers that are currently segmented from our ASN (6939), going > even so far as baking a cake for Cogent (AS174). Are some parties refusing to use transit, trying to bake in a de-facto "tier-1" ness? brandon From tjc at ecs.soton.ac.uk Mon Jan 10 07:56:26 2011 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Mon, 10 Jan 2011 13:56:26 +0000 Subject: NIST IPv6 document In-Reply-To: References: <20110105043548.BC01B1CC3E@ptavv.es.net> <4661ED7E-A4DA-4CD4-A7EB-C5B2E615F126@delong.com> <86zkreb486.fsf@seastrom.com> <0B19C108-2B18-43E5-A4CF-9AFD421F4206@ecs.soton.ac.uk> Message-ID: On 7 Jan 2011, at 15:12, Justin M. Streiner wrote: > On Thu, 6 Jan 2011, Jeff Wheeler wrote: > >> On Thu, Jan 6, 2011 at 8:47 PM, Owen DeLong wrote: >>> 1. Block packets destined for your point-to-point links at your >>> borders. There's no legitimate reason someone should be >> >> Most networks do not do this today. Whether or not that is wise is >> questionable, but I don't think those networks want NDP to be the >> reason they choose to make this change. > > Correct me if I'm wrong, but wouldn't blocking all traffic destined for your infrastructure at the borders also play havoc with PTMUD? Limiting the traffic allowed to just the necessary types would seem like a reasonable alternative. Recommendations for PTMUD-friendly filtering are described in RFC 4890. Tim From leo.vegoda at icann.org Wed Jan 5 14:39:08 2011 From: leo.vegoda at icann.org (Leo Vegoda) Date: Wed, 5 Jan 2011 12:39:08 -0800 Subject: Three blocks of AS Numbers allocated to the RIPE NCC Message-ID: <275186D7-5ADA-47D7-A3DB-869B3C546398@icann.org> Hi, The IANA AS Numbers registry has been updated to reflect the allocation of three blocks to the RIPE NCC in January 2011. 56320-57343 Assigned by RIPE NCC whois.ripe.net 2011-01-04 57344-58367 Assigned by RIPE NCC whois.ripe.net 2011-01-04 197632-198655 Assigned by RIPE NCC whois.ripe.net 2011-01-04 You can find the registry at: http://www.iana.org/assignments/as-numbers/as-numbers.xml http://www.iana.org/assignments/as-numbers/as-numbers.xhtml http://www.iana.org/assignments/as-numbers/as-numbers.txt Regards, Leo Vegoda Number Resources Manager, IANA ICANN From behrnetworks at gmail.com Mon Jan 10 08:51:53 2011 From: behrnetworks at gmail.com (Chris) Date: Mon, 10 Jan 2011 09:51:53 -0500 Subject: How are you aggregating WAN customers these days? Message-ID: Hello, I'm looking to put some feelers out there and see what people are doing to aggregate WAN customers (T1,T3, etc...) these days. What platforms/devices are you using? What seems to be working/not working? Any insights would be great! Thanks, Chris From lists at mtin.net Mon Jan 10 09:00:14 2011 From: lists at mtin.net (Justin Wilson) Date: Mon, 10 Jan 2011 10:00:14 -0500 Subject: How are you aggregating WAN customers these days? In-Reply-To: Message-ID: Cisco ASR 1000. For T3 you can get a 4 port card. Seems to perform well. Also have a 6500 deployed with some flexwan interfaces. Believe this will also work in the 7000 something chassis. Justin -- Justin Wilson Aol & Yahoo IM: j2sw http://www.mtin.net/blog ? xISP News http://www.twitter.com/j2sw ? Follow me on Twitter Wisp Consulting ? Tower Climbing ? Network Support From: Chris Date: Mon, 10 Jan 2011 09:51:53 -0500 To: Subject: How are you aggregating WAN customers these days? Hello, I'm looking to put some feelers out there and see what people are doing to aggregate WAN customers (T1,T3, etc...) these days. What platforms/devices are you using? What seems to be working/not working? Any insights would be great! Thanks, Chris From jra at baylink.com Mon Jan 10 09:08:57 2011 From: jra at baylink.com (Jay Ashworth) Date: Mon, 10 Jan 2011 10:08:57 -0500 (EST) Subject: Satellite IP Message-ID: <21333441.816.1294672137156.JavaMail.root@benjamin.baylink.com> This is admittedly a touch end-usery, my apologies... I'm looking into satellite-based 2-way IP transport, on the scale of SCPC DVB-RCS or iDirect, as an adjunct to the already installed "traditional" one-way satellite gear installed in the Frontline DSNG truck owned by my new employer, both for MPEG streaming for broadcast, and possibly for emergency-response support, if I can sell that idea. Has anyone on NANOG any personal experience with that, from either end? Almost all of what I'll need to do will be what the satellite guys call "occasional use", ie: "I need a six hour block Thursday night, starting at 7pm", as opposed to the "monthly service with an FAP" that most people seem to sell. LBiSat is one company that understands occasional, I'm wondering if there are others (and if their IP jocks hang out here). Cheers, -- jra From jbates at brightok.net Mon Jan 10 09:25:45 2011 From: jbates at brightok.net (Jack Bates) Date: Mon, 10 Jan 2011 09:25:45 -0600 Subject: arin and ops fora (was Re: AltDB?) In-Reply-To: References: <59051.1294464800@nsa.vix.com> <00041A16-473F-4F96-93E8-E3CD3F83E1B2@virtualized.org> <70374.1294475040@nsa.vix.com> Message-ID: <4D2B24F9.9000507@brightok.net> On 1/9/2011 5:27 PM, John Curran wrote: > Excellent question. To the extent that it is best practices on these types of > services, then that's relatively easy for ARIN to interface with... if it is > specific direction to ARIN to "do xyz", then ultimately the decision rests with > the ARIN Board regarding that input, since that involves how we spend the service > fees of the members. > Which ARIN membership does have some resources on, though I do believe they could be improved, as most membership input deals more with the NRPM and not with auxiliary services. > The role is served by the ARIN Board, which is member-elected and composed of > volunteers (and myself as CEO). If folks think that a more formal structure > for operational input (either within ARIN or via liaison to another body) is > called for, I'd suggest continued discussion on the various mailing lists. > It's always a stickler, too. PPML works well for NRPM, but ARIN doesn't have enough auxiliary services to warrant a mailing list dealing with them. It becomes more of a suggestion, proposal, feedback, implementation, more feedback process. ARIN is generally good at notification of implementation concerning new services, though it would be nice if they had better channels for feedback through the entire process of new services so that they could be closer in sync with the membership. I don't believe services should reach the PDP level, but better communication wouldn't hurt, especially with members who generally don't know how or realize they can participate. It's just my personal opinion as a member. ARIN always has communication with other organizations and even nanog. They've always been polite in accepting input from others (even if they don't implement every suggestion, they'll be much nicer than some IETF people). :) Jack From behrnetworks at gmail.com Mon Jan 10 09:28:20 2011 From: behrnetworks at gmail.com (Chris) Date: Mon, 10 Jan 2011 10:28:20 -0500 Subject: How are you aggregating WAN customers these days? In-Reply-To: References: Message-ID: The ASRs seem to be the consensus in a lot of places. Wondering if anyone has tried anything like aggregating T1 customers onto a mux box, then connecting that back to a 6500. What are the general impressions of the ASR series? On Mon, Jan 10, 2011 at 10:00 AM, Justin Wilson wrote: > ???Cisco ASR 1000. For T3 you can get a 4 port card. ?Seems to perform well. > > ????Also have a 6500 deployed with some flexwan interfaces. ?Believe this > will also work in the 7000 something chassis. > > ????Justin > -- > Justin Wilson > Aol & Yahoo IM: j2sw > http://www.mtin.net/blog ? xISP News > http://www.twitter.com/j2sw ? Follow me on Twitter > Wisp Consulting ? Tower Climbing ? Network Support > > > > ________________________________ > From: Chris > Date: Mon, 10 Jan 2011 09:51:53 -0500 > To: > Subject: How are you aggregating WAN customers these days? > > Hello, > > I'm looking to put some feelers out there and see what people are > doing to aggregate WAN customers (T1,T3, etc...) these days. What > platforms/devices are you using? What seems to be working/not working? > Any insights would be great! > > Thanks, > Chris > > From brandon.kim at brandontek.com Mon Jan 10 09:31:32 2011 From: brandon.kim at brandontek.com (Brandon Kim) Date: Mon, 10 Jan 2011 10:31:32 -0500 Subject: Is Cisco equpiment de facto for you? Message-ID: Hello gents: I wanted to put this out there for all of you. Our network consists of a mixture of Cisco and Extreme equipment. Would you say that it's fair to say that if you are serious at all about being a service provider that your core equipment is Cisco based? Am I limiting myself by thinking that Cisco is the "de facto" vendor of choice? I'm not looking for so much "fanboy" responses, but more of a real world experience of what you guys use that actually work and does the job..... No technical questions here, just general feedback. I try to follow the Tolly Group who compares products, and they continually show that Cisco equipment is a poor performer in almost any equipment compared to others, I find that so hard to believe..... Thanks! Brandon From jbates at brightok.net Mon Jan 10 09:37:43 2011 From: jbates at brightok.net (Jack Bates) Date: Mon, 10 Jan 2011 09:37:43 -0600 Subject: How are you aggregating WAN customers these days? In-Reply-To: References: Message-ID: <4D2B27C7.5000209@brightok.net> On 1/10/2011 9:28 AM, Chris wrote: > The ASRs seem to be the consensus in a lot of places. Wondering if > anyone has tried anything like aggregating T1 customers onto a mux > box, then connecting that back to a 6500. > > What are the general impressions of the ASR series? I need to get one to play with. I see them better for handling end-node terminations, and according to the cisco guys I've talked to, the ASR has and will continue to have more subscriber management functionality than traditional IOS. For t1, I either run a mux(telco side) into a CT3(ISP side) on a 7200 (there's equiv SPAs), or if it hits one of my larger pops, I drop it into a mux(telco side) which terminates with all of my OC3 and smaller circuits into a CHOC48(telco/ISP crossconnect link). Given that most of these circuits are being long hauled anyways, this just made the best sense to us. It also (even though telco/ISP are related in this case) assisted in management domains. Jack From jared at puck.nether.net Mon Jan 10 09:38:38 2011 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 10 Jan 2011 10:38:38 -0500 Subject: Is Cisco equpiment de facto for you? In-Reply-To: References: Message-ID: <03E10AD9-CD45-4D46-9BF2-A31F2A2076A8@puck.nether.net> On Jan 10, 2011, at 10:31 AM, Brandon Kim wrote: > > Hello gents: > > I wanted to put this out there for all of you. Our network consists of a mixture of Cisco and Extreme equipment. > > Would you say that it's fair to say that if you are serious at all about being a service provider that your core equipment is Cisco based? > > Am I limiting myself by thinking that Cisco is the "de facto" vendor of choice? I'm not looking for so much "fanboy" responses, but more of a real world > experience of what you guys use that actually work and does the job..... I think a lot of this depends on the market. If you're into FTTH/FTTP then Cisco is not the way to go. They have no serious offerings in this space IMHO. (that are cost competitive). Each vendor has various things they do well. Cisco surely is well capitalized with a broad portfolio of offerings in the DWDM to IP space. I do believe they are the "IBM" of the industry, ie: "Nobody ever was fired for buying IBM(sic)". This does not mean they (nor anyone else) delivers a perfect solution. This is a challenge that I frequently remind the vendors of, as apparently many customers actually do *yell* at them when there are bugs, vs offering constructive partnerships to resolve the issues. I think that Juniper, Foundry(Brocade) and some other vendors offer compelling products in the core space as well. It's well worth its while to build a relationship with your vendors so you can have that constructive partnership IMHO. Then when you hit a serious problem, you can take constructive actions vs just screaming loudly and hoping they jump. - Jared From jbates at brightok.net Mon Jan 10 09:42:39 2011 From: jbates at brightok.net (Jack Bates) Date: Mon, 10 Jan 2011 09:42:39 -0600 Subject: Is Cisco equpiment de facto for you? In-Reply-To: References: Message-ID: <4D2B28EF.2030209@brightok.net> On 1/10/2011 9:31 AM, Brandon Kim wrote: > Would you say that it's fair to say that if you are serious at all > about being a service provider that your core equipment is Cisco > based? > > Am I limiting myself by thinking that Cisco is the "de facto" vendor > of choice? I'm not looking for so much "fanboy" responses, but more > of a real world experience of what you guys use that actually work > and does the job..... > You have to really narrow the network criteria. What's good for DSL subscriber termination with or without subscriber management features (on router, or handled externally), in core networks a t1/t3/oc3/gig-e/oc48/10G+ speeds, mpls features, etc. The first kickoff on any network is if it is service provider or enterprise. The feature sets and types of boxes differ greatly between these for most manufacturers (as does price). I've been happy with, and disappointed with, Cisco, Extreme, Juniper, and Brocade. There's a few others out there that I haven't used or tested. In the Terabit market, I love Alcatel and Juniper, but I can't afford the terabit market. :) Jack From saxon.jones at gmail.com Mon Jan 10 09:43:10 2011 From: saxon.jones at gmail.com (Saxon Jones) Date: Mon, 10 Jan 2011 08:43:10 -0700 Subject: Is Cisco equpiment de facto for you? In-Reply-To: References: Message-ID: In my experience it all comes down to Cisco-certified people being easy to find, and managers not wanting to spend all their time in the hiring process. So yes, I've generally seen Cisco as the de-facto choice, but it's rarely been a technical argument that swings the balance. I'm generally playing in the Enterprise space now, though. -saxon On 10 January 2011 08:31, Brandon Kim wrote: > > Hello gents: > > I wanted to put this out there for all of you. Our network consists of a mixture of Cisco and Extreme equipment. > > Would you say that it's fair to say that if you are serious at all about being a service provider that your core equipment is Cisco based? > > Am I limiting myself by thinking that Cisco is the "de facto" vendor of choice? I'm not looking for so much "fanboy" responses, but more of a real world > experience of what you guys use that actually work and does the job..... > > No technical questions here, just general feedback. I try to follow the Tolly Group who compares products, and they continually show that Cisco equipment > is a poor performer in almost any equipment compared to others, I find that so hard to believe..... > > Thanks! > > Brandon > > From cvuljanic at gmail.com Mon Jan 10 09:46:01 2011 From: cvuljanic at gmail.com (Craig V) Date: Mon, 10 Jan 2011 10:46:01 -0500 Subject: Is Cisco equpiment de facto for you? In-Reply-To: References: Message-ID: Our core business is not as a service provider, as in selling services to others, but we act as a service provider providing services for the various customers in our internal network that we support. Our core used to be an all Cisco Core. a few years back the decision was made to replace this with Alcatel-Lucent IPD products. I can say we are happy that we did replace the Cisco core, and we have had a very good experience with the IPD product line. I am sure others can attest to this also. The features and functionality along with the reliability have been very good, and in my opinion they have a strong product. Our edge at this point is a mixture of Cisco access switches, and we also still have some Cisco Distribution. On Mon, Jan 10, 2011 at 10:31 AM, Brandon Kim wrote: > > Hello gents: > > I wanted to put this out there for all of you. Our network consists of a > mixture of Cisco and Extreme equipment. > > Would you say that it's fair to say that if you are serious at all about > being a service provider that your core equipment is Cisco based? > > Am I limiting myself by thinking that Cisco is the "de facto" vendor of > choice? I'm not looking for so much "fanboy" responses, but more of a real > world > experience of what you guys use that actually work and does the job..... > > No technical questions here, just general feedback. I try to follow the > Tolly Group who compares products, and they continually show that Cisco > equipment > is a poor performer in almost any equipment compared to others, I find that > so hard to believe..... > > Thanks! > > Brandon > > From Valdis.Kletnieks at vt.edu Mon Jan 10 09:56:35 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 10 Jan 2011 10:56:35 -0500 Subject: Satellite IP In-Reply-To: Your message of "Mon, 10 Jan 2011 10:08:57 EST." <21333441.816.1294672137156.JavaMail.root@benjamin.baylink.com> References: <21333441.816.1294672137156.JavaMail.root@benjamin.baylink.com> Message-ID: <63753.1294674995@localhost> On Mon, 10 Jan 2011 10:08:57 EST, Jay Ashworth said: > Almost all of what I'll need to do will be what the satellite guys call > "occasional use", ie: "I need a six hour block Thursday night, starting > at 7pm", as opposed to the "monthly service with an FAP" that most > people seem to sell. What happens if the bird is already fully booked for 9PM to midnight? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From streiner at cluebyfour.org Mon Jan 10 06:02:17 2011 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Mon, 10 Jan 2011 07:02:17 -0500 (EST) Subject: Is Cisco equpiment de facto for you? In-Reply-To: References: Message-ID: On Mon, 10 Jan 2011, Brandon Kim wrote: > Would you say that it's fair to say that if you are serious at all > about being a service provider that your core equipment is Cisco based? I would not necessarily say that. Granted, most of the places I've worked are Cisco shops to a large extent, that does not mean it is the only solution to many problems. There are product spaces where Cisco has a very well established presence (routers, switches, remote access, wireless, DWDM, IP telephony, etc), but there are other players in those spaces, in additional to spaces where Cisco does not have as large of a presence. There are many people who will give 'buy Cisco' as a default answer to many networking needs, much the same as there are meny people who will give 'buy Microsoft' or 'buy Oracle' for software/database needs. There are other solutions to those needs. If you see a piece of gear from a new vendor, don't be afraid to contact them to see if get their sales team in to give you a presentation or take a box for a test drive. Ideally, you also have acess to some type of lab or non-production environment where you can try out equipment without putting 'live' data at risk. In most shops I've worked in, the final decision comes down to: 1. cost 2. performance/reliability 3. support 4. scalability (read: investment protection, speaking back to point 1) 5. interoperability 6. security 7. environmental factors (rack space, power, cooling, etc) Pretty much all of the subsequent points ties back to point 1 in some way. Network devices are tools designed to do one or more jobs. The job you're trying to do determines the tools you use, and how you use them. jms PS: I take test results from Tolly/Gartner/Burton/etc with a grain of salt. When a vendor performs well in a bake-off, they will proudly trumpet that fact. When they don't they will usually claim that either the box they tested was broken, or the testing methodology was flawed in some way :) From truman at suspicious.org Mon Jan 10 10:09:00 2011 From: truman at suspicious.org (Truman Boyes) Date: Mon, 10 Jan 2011 08:09:00 -0800 Subject: How are you aggregating WAN customers these days? In-Reply-To: References: Message-ID: <9B44C1C9-2132-4198-8684-A0636A032A32@suspicious.org> On 10 Jan 2011, at 6:51 AM, Chris wrote: > Hello, > > I'm looking to put some feelers out there and see what people are > doing to aggregate WAN customers (T1,T3, etc...) these days. What > platforms/devices are you using? What seems to be working/not working? > Any insights would be great! > > Thanks, > Chris Still plenty of sites using Juniper E-series for circuit aggregation. Many deployments have been active for about 10 years. Cheers, Truman From alex at corp.nac.net Mon Jan 10 10:14:14 2011 From: alex at corp.nac.net (Alex Rubenstein) Date: Mon, 10 Jan 2011 11:14:14 -0500 Subject: How are you aggregating WAN customers these days? In-Reply-To: References: Message-ID: Cheap and reliable. Cisco 7507, RSP4 or RSP8 or whatever, with ChanDS3 cards, running 12.0S. > -----Original Message----- > From: Chris [mailto:behrnetworks at gmail.com] > Sent: Monday, January 10, 2011 9:52 AM > To: nanog at nanog.org > Subject: How are you aggregating WAN customers these days? > > Hello, > > I'm looking to put some feelers out there and see what people are doing to > aggregate WAN customers (T1,T3, etc...) these days. What platforms/devices > are you using? What seems to be working/not working? > Any insights would be great! > > Thanks, > Chris From paul at paulstewart.org Mon Jan 10 10:16:29 2011 From: paul at paulstewart.org (Paul Stewart) Date: Mon, 10 Jan 2011 11:16:29 -0500 Subject: Is Cisco equpiment de facto for you? In-Reply-To: References: Message-ID: <01f501cbb0e1$bdd0a990$3971fcb0$@org> Cisco shop here that is avidly converting to Juniper..... Paul -----Original Message----- From: Brandon Kim [mailto:brandon.kim at brandontek.com] Sent: Monday, January 10, 2011 10:32 AM To: nanog group Subject: Is Cisco equpiment de facto for you? Hello gents: I wanted to put this out there for all of you. Our network consists of a mixture of Cisco and Extreme equipment. Would you say that it's fair to say that if you are serious at all about being a service provider that your core equipment is Cisco based? Am I limiting myself by thinking that Cisco is the "de facto" vendor of choice? I'm not looking for so much "fanboy" responses, but more of a real world experience of what you guys use that actually work and does the job..... No technical questions here, just general feedback. I try to follow the Tolly Group who compares products, and they continually show that Cisco equipment is a poor performer in almost any equipment compared to others, I find that so hard to believe..... Thanks! Brandon = From andrew.koch at gawul.net Mon Jan 10 10:21:20 2011 From: andrew.koch at gawul.net (Andrew Koch) Date: Mon, 10 Jan 2011 10:21:20 -0600 Subject: How are you aggregating WAN customers these days? In-Reply-To: References: Message-ID: On Mon, Jan 10, 2011 at 09:28, Chris wrote: > The ASRs seem to be the consensus in a lot of places. Wondering if > anyone has tried anything like aggregating T1 customers onto a mux > box, then connecting that back to a 6500. > > What are the general impressions of the ASR series? > > On Mon, Jan 10, 2011 at 10:00 AM, Justin Wilson wrote: >> ???Cisco ASR 1000. For T3 you can get a 4 port card. ?Seems to perform well. >> >> ????Also have a 6500 deployed with some flexwan interfaces. ?Believe this >> will also work in the 7000 something chassis. >> I would concur that the ASR1000 works well for channelized T3 aggregation. We are currently phasing our 7600 series with SIP-200 cards and channelized T3 SPAs in favor of the ASR1000, using the same SPAs, and have found them to perform well. We found that the SIP-200 on the 7600 was incapable of handling PPP flapping as may occur when a T1 is having facility trouble or looped back on itself. In the 7600, the SIP processes the PPP messaging, whereas the ASR SIP is a passthrough to the RP for processing of PPP. When the 7600 SIP starts having trouble, it can cause the SIP to crash or even have the overall PPP process on the whole box stop responding, needing to reload the whole router. It is possible that the beefier SIP modules on the 7600 would handle this better, but I have no experience with such. Andrew Koch andrew.koch at gawul.net From rcarpen at network1.net Mon Jan 10 10:21:37 2011 From: rcarpen at network1.net (Randy Carpenter) Date: Mon, 10 Jan 2011 11:21:37 -0500 (EST) Subject: Is Cisco equpiment de facto for you? In-Reply-To: Message-ID: <1177151411.1544.1294676497222.JavaMail.root@zimbra.network1.net> We have traditionally been a Cisco shop, but we are starting to move toward Juniper for much of our needs, and will be recommending Juniper as an alternative for customers' needs. From a technical point of view, I find the configurations to be simpler and easier to understand, and I like the fact that most everything runs the same OS, with the same interface. From a financial point of view, Juniper tends to be less expensive for more performance, and their support contracts are much cheaper. All that said, and as other's have said, Cisco is always a safe choice, particularly since many people are familiar with them. -Randy -- | Randy Carpenter | Vice President, IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (419)739-9240, x1 ---- ----- Original Message ----- > Hello gents: > > I wanted to put this out there for all of you. Our network consists of > a mixture of Cisco and Extreme equipment. > > Would you say that it's fair to say that if you are serious at all > about being a service provider that your core equipment is Cisco > based? > > Am I limiting myself by thinking that Cisco is the "de facto" vendor > of choice? I'm not looking for so much "fanboy" responses, but more of > a real world > experience of what you guys use that actually work and does the > job..... > > No technical questions here, just general feedback. I try to follow > the Tolly Group who compares products, and they continually show that > Cisco equipment > is a poor performer in almost any equipment compared to others, I find > that so hard to believe..... > > Thanks! > > Brandon From scott at sberkman.net Mon Jan 10 10:25:17 2011 From: scott at sberkman.net (Scott Berkman) Date: Mon, 10 Jan 2011 11:25:17 -0500 Subject: How are you aggregating WAN customers these days? In-Reply-To: References: Message-ID: <010c01cbb0e2$f81256c0$e8370440$@sberkman.net> Juniper M20. -----Original Message----- From: Justin Wilson [mailto:lists at mtin.net] Sent: Monday, January 10, 2011 10:00 AM To: Chris; nanog at nanog.org Subject: Re: How are you aggregating WAN customers these days? Cisco ASR 1000. For T3 you can get a 4 port card. Seems to perform well. Also have a 6500 deployed with some flexwan interfaces. Believe this will also work in the 7000 something chassis. Justin -- Justin Wilson Aol & Yahoo IM: j2sw http://www.mtin.net/blog - xISP News http://www.twitter.com/j2sw - Follow me on Twitter Wisp Consulting - Tower Climbing - Network Support From: Chris Date: Mon, 10 Jan 2011 09:51:53 -0500 To: Subject: How are you aggregating WAN customers these days? Hello, I'm looking to put some feelers out there and see what people are doing to aggregate WAN customers (T1,T3, etc...) these days. What platforms/devices are you using? What seems to be working/not working? Any insights would be great! Thanks, Chris From ryan at deadfrog.net Mon Jan 10 10:28:51 2011 From: ryan at deadfrog.net (Ryan Wilkins) Date: Mon, 10 Jan 2011 10:28:51 -0600 Subject: Satellite IP In-Reply-To: <21333441.816.1294672137156.JavaMail.root@benjamin.baylink.com> References: <21333441.816.1294672137156.JavaMail.root@benjamin.baylink.com> Message-ID: <906BD08A-F1D9-4F62-AFCE-6E1EA5812D89@deadfrog.net> On Jan 10, 2011, at 9:08 AM, Jay Ashworth wrote: > I'm looking into satellite-based 2-way IP transport, on the scale of > SCPC DVB-RCS or iDirect, as an adjunct to the already installed > "traditional" one-way satellite gear installed in the Frontline DSNG > truck owned by my new employer, both for MPEG streaming for broadcast, > and possibly for emergency-response support, if I can sell that idea. > > Has anyone on NANOG any personal experience with that, from either end? I have some experience with what you are asking. While not from the DSNG side, I have experience with satellite based IP using iDirect Infinity shared satellite hubs. The 5000- and 7000-series Infinity remotes will support SCPC between two remotes if you wish, but it's all IP based. Getting into the emergency response arena would require an IP based network. I have done this with the City of Chicago for several communications trucks that my former employer built and maintains for them. They send and receive live video, VoIP, and enterprise network data across the satellite. They have a dedicated space segment that they buy annually so they don't run into the issue of not having satellite connectivity available when they really need it. Trying to sell this together to your employer possibly means a merging of your two disparate capabilities. Can you move your MPEG streams over IP? > Almost all of what I'll need to do will be what the satellite guys call > "occasional use", ie: "I need a six hour block Thursday night, starting > at 7pm", as opposed to the "monthly service with an FAP" that most > people seem to sell. LBiSat is one company that understands occasional, > I'm wondering if there are others (and if their IP jocks hang out here). Intelsat operates several iDirect hubs available for public use which are tied to the Internet. They should be able to help you with your occasional use needs. If you need a contact, I can try to dig one up for you. Ryan Wilkins From tad1214 at gmail.com Mon Jan 10 10:36:24 2011 From: tad1214 at gmail.com (Thomas Donnelly) Date: Mon, 10 Jan 2011 10:36:24 -0600 Subject: Is Cisco equpiment de facto for you? In-Reply-To: References: Message-ID: On Mon, 10 Jan 2011 09:31:32 -0600, Brandon Kim wrote: > > Hello gents: > > I wanted to put this out there for all of you. Our network consists of a > mixture of Cisco and Extreme equipment. > > Would you say that it's fair to say that if you are serious at all about > being a service provider that your core equipment is Cisco based? > > Am I limiting myself by thinking that Cisco is the "de facto" vendor of > choice? I'm not looking for so much "fanboy" responses, but more of a > real world > experience of what you guys use that actually work and does the job..... > > No technical questions here, just general feedback. I try to follow the > Tolly Group who compares products, and they continually show that Cisco > equipment > is a poor performer in almost any equipment compared to others, I find > that so hard to believe..... Cisco is typically not known as the fastest or most power efficient when compared to other vendors, but they usually have some advanced feature sets that are very nice. In the ISP space this may be less helpful, but in the SMB and Enterprise space this can be very helpful. Things such as Call Manager Express, Web Content Filtering, WebEx Nodes, Server Load Balancing, Wireless Lan Controllers, etc. that are either built into IOS or available with a line card or module, are nice tools to have at your disposal, and often can mean reducing the number of devices you need in your rack. As of the Tolly group, I find whomever pays Tolly for the survey tends to be the fastest. Example: Abstract: HP commissioned Tolly to evaluate the performance, power consumption and TCO of its E5400 zl and E8200 switch series and compare those systems with the Cisco Systems Catalyst 3750-X and Catalyst 4500. This is because the Vendor is getting to pick what they want to benchmark rather than the company benchmarking them. No one is going to choose tests that their product will lose in. There isn't much in the way of "Tom's Hardware Style" testing of enterprise gear to my knowledge. Cisco gear is also known for long life, being very consistent, and high reliability. A walk through colos you will often see many many Cisco 12000's for those exact reasons. I feel each vendor has its strong points, price/performance may not be Cisco's but Cisco's ease of configuration and feature sets, along with reliability are definitely notable. -=Tom > > Thanks! > > Brandon > > -- Using Opera's revolutionary email client: http://www.opera.com/mail/ From lorddoskias at gmail.com Mon Jan 10 10:39:56 2011 From: lorddoskias at gmail.com (lorddoskias) Date: Mon, 10 Jan 2011 16:39:56 +0000 Subject: Is Cisco equpiment de facto for you? In-Reply-To: References: Message-ID: <4D2B365C.5070506@gmail.com> On 1/10/2011 3:31 PM, Brandon Kim wrote: > Hello gents: > > I wanted to put this out there for all of you. Our network consists of a mixture of Cisco and Extreme equipment. > > Would you say that it's fair to say that if you are serious at all about being a service provider that your core equipment is Cisco based? > > Am I limiting myself by thinking that Cisco is the "de facto" vendor of choice? I'm not looking for so much "fanboy" responses, but more of a real world > experience of what you guys use that actually work and does the job..... > > No technical questions here, just general feedback. I try to follow the Tolly Group who compares products, and they continually show that Cisco equipment > is a poor performer in almost any equipment compared to others, I find that so hard to believe..... > > Thanks! > > Brandon > > Just as a pointer - one of the largest and most utilized IX (AMS-IX) has their platform built on Brocade devices. From Greg.Whynott at oicr.on.ca Mon Jan 10 10:52:16 2011 From: Greg.Whynott at oicr.on.ca (Greg Whynott) Date: Mon, 10 Jan 2011 11:52:16 -0500 Subject: Is Cisco equpiment de facto for you? In-Reply-To: <1177151411.1544.1294676497222.JavaMail.root@zimbra.network1.net> References: <1177151411.1544.1294676497222.JavaMail.root@zimbra.network1.net> Message-ID: I've tried to use other vendors threw out the years for internal L2/L3. Always Cisco for perimeter routing/firewalling. from my personal experience, each time we took a chance and tried to use another vendor for internal L2 needs, we would be reminded why it was a bad choice down the road, due to hardware reliability, support issues, multiple and ongoing software bugs, architectural design choices. Then for the next few years I'd regret the decision. This is not to say Cisco gear has been without its issues, but they are much fewer and handled better when stuff hits the fan. the only other vendor at this point in my career I'd fee comfortable deploying for internal enterprise switching, including HPC requirements which is not CIsco branded, would be Force10 or Extreme. it has always been Cisco for edge routing/firewalling, but i wouldn't be opposed to trying Juniper for routing, I know of a few shops who do and they have been pleased thus far. I've little or no experience with many of the other vendors, and I'm sure they have good offerings, but I won't be beta testing their firmwares anymore (one vendor insisted we upgrade our firmware on our core equipment several times in one year?). Cisco isn't a good choice if you don't have the budget for the smart net contracts. They come at a price. a little 5505 with unrestricted license and contract costs over 2k, a 5540 about 40k-70k depending on options, with a yearly renewal of about 15k or more? -g On Jan 10, 2011, at 11:21 AM, Randy Carpenter wrote: > > We have traditionally been a Cisco shop, but we are starting to move toward Juniper for much of our needs, and will be recommending Juniper as an alternative for customers' needs. From a technical point of view, I find the configurations to be simpler and easier to understand, and I like the fact that most everything runs the same OS, with the same interface. From a financial point of view, Juniper tends to be less expensive for more performance, and their support contracts are much cheaper. > > All that said, and as other's have said, Cisco is always a safe choice, particularly since many people are familiar with them. > > -Randy > > -- > | Randy Carpenter > | Vice President, IT Services > | Red Hat Certified Engineer > | First Network Group, Inc. > | (419)739-9240, x1 > ---- > > ----- Original Message ----- >> Hello gents: >> >> I wanted to put this out there for all of you. Our network consists of >> a mixture of Cisco and Extreme equipment. >> >> Would you say that it's fair to say that if you are serious at all >> about being a service provider that your core equipment is Cisco >> based? >> >> Am I limiting myself by thinking that Cisco is the "de facto" vendor >> of choice? I'm not looking for so much "fanboy" responses, but more of >> a real world >> experience of what you guys use that actually work and does the >> job..... >> >> No technical questions here, just general feedback. I try to follow >> the Tolly Group who compares products, and they continually show that >> Cisco equipment >> is a poor performer in almost any equipment compared to others, I find >> that so hard to believe..... >> >> Thanks! >> >> Brandon > -- This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization. From Greg.Whynott at oicr.on.ca Mon Jan 10 11:03:06 2011 From: Greg.Whynott at oicr.on.ca (Greg Whynott) Date: Mon, 10 Jan 2011 12:03:06 -0500 Subject: Is Cisco equpiment de facto for you? In-Reply-To: <4D2B365C.5070506@gmail.com> References: <4D2B365C.5070506@gmail.com> Message-ID: <61EC3786-5732-4C5A-8938-A15E840DC75B@oicr.on.ca> >> >> Brandon >> >> > Just as a pointer - one of the largest and most utilized IX (AMS-IX) has > their platform built on Brocade devices. > Brocade device's pre Foundry purchase correct? I can't see anyone that large using Foundry in large deployments.. -g -- This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization. From brandon.kim at brandontek.com Mon Jan 10 11:04:22 2011 From: brandon.kim at brandontek.com (Brandon Kim) Date: Mon, 10 Jan 2011 12:04:22 -0500 Subject: Is Cisco equpiment de facto for you? In-Reply-To: References: , Message-ID: Wow, overall consensus is that there are quite a few that are migrating to Juniper from Cisco. I am a bit biased because I have spent an awful amount of time invested into Cisco and understanding how to configure them. But being a former business owner, I also am very much sensitive to costs and business needs. For those that have been Cisco focused, do you stay fully objective, and are you willing to pitch another vendor knowing that you will have to learn a new IOS? And that that will be your time that you'll have to spend to understand the product and support it? We have been selling HP procurves to SMB's because of the cost factor. I don't really mind them all that much. I've tried to fit Cisco switches in the mix but their pricing is just so much more as well as the smartnet costs. They really price themselves out and that is unfortunate. I will be looking at refreshing our core switches and routers soon so I will stay objective as much as I can. =) > To: nanog at nanog.org > Subject: Re: Is Cisco equpiment de facto for you? > Date: Mon, 10 Jan 2011 10:36:24 -0600 > CC: brandon.kim at brandontek.com > From: tad1214 at gmail.com > > On Mon, 10 Jan 2011 09:31:32 -0600, Brandon Kim > wrote: > > > > > Hello gents: > > > > I wanted to put this out there for all of you. Our network consists of a > > mixture of Cisco and Extreme equipment. > > > > Would you say that it's fair to say that if you are serious at all about > > being a service provider that your core equipment is Cisco based? > > > > Am I limiting myself by thinking that Cisco is the "de facto" vendor of > > choice? I'm not looking for so much "fanboy" responses, but more of a > > real world > > experience of what you guys use that actually work and does the job..... > > > > No technical questions here, just general feedback. I try to follow the > > Tolly Group who compares products, and they continually show that Cisco > > equipment > > is a poor performer in almost any equipment compared to others, I find > > that so hard to believe..... > > Cisco is typically not known as the fastest or most power efficient when > compared to other vendors, but they usually have some advanced feature > sets that are very nice. In the ISP space this may be less helpful, but in > the SMB and Enterprise space this can be very helpful. Things such as Call > Manager Express, Web Content Filtering, WebEx Nodes, Server Load > Balancing, Wireless Lan Controllers, etc. that are either built into IOS > or available with a line card or module, are nice tools to have at your > disposal, and often can mean reducing the number of devices you need in > your rack. > > As of the Tolly group, I find whomever pays Tolly for the survey tends to > be the fastest. > > Example: > Abstract: > > HP commissioned Tolly to evaluate the performance, power consumption and > TCO of its E5400 zl and E8200 switch series and compare those systems with > the Cisco Systems Catalyst 3750-X and Catalyst 4500. > > This is because the Vendor is getting to pick what they want to benchmark > rather than the company benchmarking them. No one is going to choose tests > that their product will lose in. There isn't much in the way of "Tom's > Hardware Style" testing of enterprise gear to my knowledge. > > Cisco gear is also known for long life, being very consistent, and high > reliability. A walk through colos you will often see many many Cisco > 12000's for those exact reasons. > > I feel each vendor has its strong points, price/performance may not be > Cisco's but Cisco's ease of configuration and feature sets, along with > reliability are definitely notable. > > -=Tom > > > > > Thanks! > > > > Brandon > > > > > > > -- > Using Opera's revolutionary email client: http://www.opera.com/mail/ From streiner at cluebyfour.org Mon Jan 10 07:19:58 2011 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Mon, 10 Jan 2011 08:19:58 -0500 (EST) Subject: Is Cisco equpiment de facto for you? In-Reply-To: References: , Message-ID: On Mon, 10 Jan 2011, Brandon Kim wrote: > For those that have been Cisco focused, do you stay fully objective, > and are you willing to pitch another vendor knowing that you will have > to learn a new IOS? And that that will be your time that you'll have to > spend to understand the product and support it? I work at a multivendor shop - we're not afraid to work with other vendors' gear. There's a lot of Cisco here, but there is a lot of non-Cisco here too. Core routing/switching: Cisco Access switches: Cisco Border routers: Juniper Firewalls: Cisco/Fortinet Load balancers: F5 Wireless: Cisco IP Telephony: Avaya SAN: Cisco/Brocade (I think - I don't touch the storage stuff too much :)) VPNs: Juniper/Fortinet/Cisco (depending on VPN type/application) UPSs: Emerson(Liebert) and Eaton(Powerware) jms From JBonner at enventis.com Mon Jan 10 11:17:30 2011 From: JBonner at enventis.com (Jerry Bonner) Date: Mon, 10 Jan 2011 11:17:30 -0600 Subject: How are you aggregating WAN customers these days? In-Reply-To: References: Message-ID: If you have a large amount of ppp/mlppp channelized T3's as most people then I would recommend dumping these into an Adtran TA5000 chassis with multiservice ct3 cards and dumping them to ethernet. Then to an ASR or whatever your vlan agg box is. The cost per t3 port should be significantly cheaper than comparable cisco/juniper router ct3 ports. Last I checked the TA5K doesn't have double tag stacking or HDLC support, but that may or may not be an issue for some. ~jerry -----Original Message----- From: Chris [mailto:behrnetworks at gmail.com] Sent: Monday, January 10, 2011 8:52 AM To: nanog at nanog.org Subject: How are you aggregating WAN customers these days? Hello, I'm looking to put some feelers out there and see what people are doing to aggregate WAN customers (T1,T3, etc...) these days. What platforms/devices are you using? What seems to be working/not working? Any insights would be great! Thanks, Chris From Joel.Snyder at Opus1.COM Mon Jan 10 11:26:06 2011 From: Joel.Snyder at Opus1.COM (Joel M Snyder) Date: Mon, 10 Jan 2011 10:26:06 -0700 Subject: Is Cisco equpiment de facto for you? In-Reply-To: References: Message-ID: <4D2B412E.3090501@opus1.com> >I try to follow the Tolly Group who compares products, and they >continually show that Cisco equipment >is a poor performer in almost any equipment compared to others, I find >that so hard to believe..... Just a rough comment here. Tolly's business model is a sponsored test one, and Cisco is the dominant vendor in the marketplace. So when anyone has a new product they want to promote, they can hire Tolly's lab to show how a particular feature set is implemented and can often show how one model exceeds Cisco's performance on some or all benchmarks. While Tolly never cheats, remember that the guys who "win" the test are the ones that are helping to design the test methodology, and so they are focusing on features that they know that they can beat Cisco on. Thus, the Tolly reports are true, but may not be telling the whole story or may be focusing on a particular feature more than anything else. No one is lying to you, but you may not be given the whole picture. There's nothing wrong with having Tolly show that your product is in the same league as Cisco's, but I would not necessarily read those reports to say that Cisco is always the "loser" in any new product comparison. The real value in Tolly's reports is to give credibility to the new and up-coming products by having a mostly-independent source show that the new products are comparable with the market leaders' in some ways. Tolly is also very very important at doing spec verification: showing that a product actually DOES what the specification sheet says it does. Remember that those numbers are often made up by product managers based on poorly-done in-house tests, so having a third-party, even a paid one, say "yes, it does do that in our test lab" is WAY more information than you get from most vendors. Tolly provides a valuable service to our community but you need to look at a combination of benchmarks from Tolly as well as other very-unbiased sources (IDG and CMP magazines are pretty thorough) AND YOUR OWN TESTING to know what is best for you. On the other hand, compared to the analyst firms like Gartner who don't even have test labs and generate their reports based on phone calls, Google searches, and unverified specification sheets, Tolly is a source of infinite knowledge about products. Finally, also remember that performance is only one part of system design and deployment. Management and feature completeness are, for the operator community, often more important than whether the box can do 80 Gbps or 85 Gbps. Product selection is best done by YOU setting YOUR requirements and doing YOUR OWN testing, not by looking at point tests to see if one product version/model/device beats another in a particular small set of performance tests. Obligatory disclaimer: we don't compete directly with Tolly, but we do get paid by the magazines to do testing and there is some overlap, so we do compete indirectly. jms -- Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Senior Partner, Opus One Phone: +1 520 324 0494 jms at Opus1.COM http://www.opus1.com/jms From Greg.Whynott at oicr.on.ca Mon Jan 10 11:29:39 2011 From: Greg.Whynott at oicr.on.ca (Greg Whynott) Date: Mon, 10 Jan 2011 12:29:39 -0500 Subject: Is Cisco equpiment de facto for you? In-Reply-To: References: , Message-ID: the pro curve line is cheap and the standard support contract price can't be beat (life time free). For many ' normal ' deployments it would be a good choice. in a 10Gbit HPC or highly redundant environment I'd probably be looking at Extreme or Force 10. There is a feature on the Cisco 6500 series which is very appealing for those needing highly redundant / quick fail over, VSS. Currently you can only get it on 6500's or better, so the cost of admission is huge, and you have to have the physical space to mount the units. Extreme has a similar feature which is available threw out most of the product line, meaning you don't have to drop 6 figures for a redundant zero time fail over solution and can fit it into as little as 2Us in the rack. I recently set up a pair of Summit 650's using the virtual switch feature. I have multiple 10Gbit clients terminated to the pair. zero time fail over when a link goes down, its nice. This is what I find is the trend with features and Cisco, Cisco sticks with what is known and a bit reluctant to throw a new feature into the mix, where as a compeating vendor sees that as an opertunity. Cisco is slow and steady, where the other vendors tend to be lighter on their feet. sometimes when you are quick on your feet, you trip more often than the one walking slowly. -g On Jan 10, 2011, at 12:04 PM, Brandon Kim wrote: > > Wow, overall consensus is that there are quite a few that are migrating to Juniper from Cisco. > > I am a bit biased because I have spent an awful amount of time invested into Cisco and understanding how to configure them. > But being a former business owner, I also am very much sensitive to costs and business needs. > > For those that have been Cisco focused, do you stay fully objective, and are you willing to pitch another vendor knowing that you will > have to learn a new IOS? And that that will be your time that you'll have to spend to understand the product and support it? > > We have been selling HP procurves to SMB's because of the cost factor. I don't really mind them all that much. I've tried to fit Cisco switches > in the mix but their pricing is just so much more as well as the smartnet costs. They really price themselves out and that is unfortunate. > > I will be looking at refreshing our core switches and routers soon so I will stay objective as much as I can. > > =) > > > > >> To: nanog at nanog.org >> Subject: Re: Is Cisco equpiment de facto for you? >> Date: Mon, 10 Jan 2011 10:36:24 -0600 >> CC: brandon.kim at brandontek.com >> From: tad1214 at gmail.com >> >> On Mon, 10 Jan 2011 09:31:32 -0600, Brandon Kim >> wrote: >> >>> >>> Hello gents: >>> >>> I wanted to put this out there for all of you. Our network consists of a >>> mixture of Cisco and Extreme equipment. >>> >>> Would you say that it's fair to say that if you are serious at all about >>> being a service provider that your core equipment is Cisco based? >>> >>> Am I limiting myself by thinking that Cisco is the "de facto" vendor of >>> choice? I'm not looking for so much "fanboy" responses, but more of a >>> real world >>> experience of what you guys use that actually work and does the job..... >>> >>> No technical questions here, just general feedback. I try to follow the >>> Tolly Group who compares products, and they continually show that Cisco >>> equipment >>> is a poor performer in almost any equipment compared to others, I find >>> that so hard to believe..... >> >> Cisco is typically not known as the fastest or most power efficient when >> compared to other vendors, but they usually have some advanced feature >> sets that are very nice. In the ISP space this may be less helpful, but in >> the SMB and Enterprise space this can be very helpful. Things such as Call >> Manager Express, Web Content Filtering, WebEx Nodes, Server Load >> Balancing, Wireless Lan Controllers, etc. that are either built into IOS >> or available with a line card or module, are nice tools to have at your >> disposal, and often can mean reducing the number of devices you need in >> your rack. >> >> As of the Tolly group, I find whomever pays Tolly for the survey tends to >> be the fastest. >> >> Example: >> Abstract: >> >> HP commissioned Tolly to evaluate the performance, power consumption and >> TCO of its E5400 zl and E8200 switch series and compare those systems with >> the Cisco Systems Catalyst 3750-X and Catalyst 4500. >> >> This is because the Vendor is getting to pick what they want to benchmark >> rather than the company benchmarking them. No one is going to choose tests >> that their product will lose in. There isn't much in the way of "Tom's >> Hardware Style" testing of enterprise gear to my knowledge. >> >> Cisco gear is also known for long life, being very consistent, and high >> reliability. A walk through colos you will often see many many Cisco >> 12000's for those exact reasons. >> >> I feel each vendor has its strong points, price/performance may not be >> Cisco's but Cisco's ease of configuration and feature sets, along with >> reliability are definitely notable. >> >> -=Tom >> >>> >>> Thanks! >>> >>> Brandon >>> >>> >> >> >> -- >> Using Opera's revolutionary email client: http://www.opera.com/mail/ > -- This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization. From jlewis at lewis.org Mon Jan 10 11:37:32 2011 From: jlewis at lewis.org (Jon Lewis) Date: Mon, 10 Jan 2011 12:37:32 -0500 (EST) Subject: AltDB? (IRR support & direction at ARIN) In-Reply-To: <4D2A8452.4070900@knownelement.com> References: <4D2A8452.4070900@knownelement.com> Message-ID: On Sun, 9 Jan 2011, Charles N Wyble wrote: >> I am simply suggesting it is dangerous and irresponsible to run an IRR >> with only MAIL-FROM authentication, and quite easy to also support >> CRYPT-PW. ARIN should either support passwords or immediately make The trouble is, since the DES crypt passwords are publicly accessible, even CRYPT-PW is not much security. I suspect with a copy of the db, a passsword cracking program, and some modest computing capacity, you could crack all the passwords in ALTDB before this thread dies. I've been trying to convert from CRYPT-PW to PGPKEY auth, but I don't seem to be having much luck getting that working. I've put a key-cert (PGPKEY-7ABEC6A3) into altdb, and changed our mntner to permit either CRYPT-PW or PGPKEY-7ABEC6A3 for auth. But PGP signed update requests result in #ERROR: Authorization failure. I'm not sure why I'm getting this auth failure. i.e. Something wrong with the formatting of my submissions? Something wrong with my key-cert? The certif: from my key-cert wasn't automatically imported into the auto-dbm keyring? I'm assuming I can take a RPSL format submission, save it to a file, use GPG to clearisgn it, and put the result in the body of an email to auto-dbm. It's also possible altdb doesn't actually have working PGP support. Looking at the database dump I downloaded the other day, only one mntner uses PGP as their sole auth method...and that mntner hasn't made changes to any objects since the last change to their mntner...so it could be they changed to PGP auth, never got it working, and abandoned altdb. I was afraid of losing control of my mntner if there were issues with PGP, so I figured I'd add PGP as an auth method, test it, and then after seeing it work, remove CRYPT-PW. ---------------------------------------------------------------------- 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 at jamesstewartsmith.com Mon Jan 10 11:38:10 2011 From: james at jamesstewartsmith.com (James Smith) Date: Mon, 10 Jan 2011 12:38:10 -0500 Subject: Is Cisco equpiment de facto for you? In-Reply-To: References: Message-ID: All the places I've worked in the past decade have been all Cisco shops for routing and switching, with a lot of Cisco use for security too (firewalls and IDS). Same with my current position, but we're switching to Juniper for all those product categories. Same or better performance, but 10-20% less cost. Additionally, I find the Juniper command line has more features that make operating and monitoring much more efficient. Also, JunOS has only one development train which means that the commands I use work on every single Juniper platform. It always bugs me when I?m trying to setup QOS across a network with different Cisco platforms (CatOS, ASA, different versions of IOS) and each platform has a completely different way of doing it. F5 all the way for content management. TippingPoint for IPS. On Mon, Jan 10, 2011 at 10:31 AM, Brandon Kim wrote: > > Hello gents: > > I wanted to put this out there for all of you. Our network consists of a > mixture of Cisco and Extreme equipment. > > Would you say that it's fair to say that if you are serious at all about > being a service provider that your core equipment is Cisco based? > > Am I limiting myself by thinking that Cisco is the "de facto" vendor of > choice? I'm not looking for so much "fanboy" responses, but more of a real > world > experience of what you guys use that actually work and does the job..... > > No technical questions here, just general feedback. I try to follow the > Tolly Group who compares products, and they continually show that Cisco > equipment > is a poor performer in almost any equipment compared to others, I find that > so hard to believe..... > > Thanks! > > Brandon > > -- James Smith From jbates at brightok.net Mon Jan 10 11:43:01 2011 From: jbates at brightok.net (Jack Bates) Date: Mon, 10 Jan 2011 11:43:01 -0600 Subject: Is Cisco equpiment de facto for you? In-Reply-To: <61EC3786-5732-4C5A-8938-A15E840DC75B@oicr.on.ca> References: <4D2B365C.5070506@gmail.com> <61EC3786-5732-4C5A-8938-A15E840DC75B@oicr.on.ca> Message-ID: <4D2B4525.8030302@brightok.net> On 1/10/2011 11:03 AM, Greg Whynott wrote: > Brocade device's pre Foundry purchase correct? I can't see anyone that large using Foundry in large deployments.. > People (who should know) have told me L3 does for some of their 10GE bonding. If you want high end at low cost, the box does it. Just price 100GE cards at the different vendors. :) Jack From nickellman at gmail.com Mon Jan 10 11:59:58 2011 From: nickellman at gmail.com (b nickell) Date: Mon, 10 Jan 2011 10:59:58 -0700 Subject: Is Cisco equpiment de facto for you? In-Reply-To: <4D2B4525.8030302@brightok.net> References: <4D2B365C.5070506@gmail.com> <61EC3786-5732-4C5A-8938-A15E840DC75B@oicr.on.ca> <4D2B4525.8030302@brightok.net> Message-ID: Cisco and my new Love; Juniper.. for Tier I / Peer On Mon, Jan 10, 2011 at 10:43 AM, Jack Bates wrote: > > > On 1/10/2011 11:03 AM, Greg Whynott wrote: > >> Brocade device's pre Foundry purchase correct? I can't see anyone that >> large using Foundry in large deployments.. >> >> > People (who should know) have told me L3 does for some of their 10GE > bonding. If you want high end at low cost, the box does it. Just price 100GE > cards at the different vendors. :) > > > Jack > > -- -B From Valdis.Kletnieks at vt.edu Mon Jan 10 12:02:02 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 10 Jan 2011 13:02:02 -0500 Subject: Satellite IP In-Reply-To: Your message of "Mon, 10 Jan 2011 11:06:32 EST." References: <21333441.816.1294672137156.JavaMail.root@benjamin.baylink.com> <63753.1294674995@localhost> Message-ID: <8743.1294682522@localhost> On Mon, 10 Jan 2011 11:06:32 EST, Kelly Olsen said: > That would only happen with an outrageously over-subscribed provider. OK - I'll feed the troll. What's the proper amount of unused and therefor non-revenue-generating capacity the operator is supposed to reserve in order to *guarantee* that bandwidth will be available? (Hint - the provider doesn't have to be "outrageously" oversubscribed - by definition, if you're oversubscribed *at all*, it's possible for somebody to lose out. It's easy for the provider to be 98% sure that they'll be able to satisfy all the requests. But guaranteeing 100% is a whole nother story...) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jra at baylink.com Mon Jan 10 12:28:07 2011 From: jra at baylink.com (Jay Ashworth) Date: Mon, 10 Jan 2011 13:28:07 -0500 (EST) Subject: Satellite IP In-Reply-To: <8743.1294682522@localhost> Message-ID: <17227231.906.1294684087129.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Valdis Kletnieks" > On Mon, 10 Jan 2011 11:06:32 EST, Kelly Olsen said: > > That would only happen with an outrageously over-subscribed > > provider. > > OK - I'll feed the troll. What's the proper amount of unused and therefor > non-revenue-generating capacity the operator is supposed to reserve in > order to *guarantee* that bandwidth will be available? > (Hint - the provider doesn't have to be "outrageously" oversubscribed > - by definition, if you're oversubscribed *at all*, it's possible for > somebody to lose out. It's easy for the provider to be 98% sure that they'll be > able to satisfy all the requests. But guaranteeing 100% is a whole nother > story...) Ok, I'll feed the troll. :-) Those who want to *guarantee* that they will never lose out -- people like network news organizations -- *lease entire transponders by the year, or for the projected lifetime of the satellite*, after which those 36MHz are yours to do with as you like; here's a list of the current *dedicated* ABC transponder avails: http://www.abcnewsabsat.com/files/frequencies_nac_041510%5B2%5D.pdf There's really a *lot* of space-segment available, Valdis. A lot. And if you buy a transponder for the entire projected 15-year lifetime of the bird, I hear you get a pretty hefty discount over the hourly rack rate. ;-) Now, in my particular case, the secondary usage I was talking about wasn't so much first-line municipal support per se, but backup to that, in the way that hams have always provided that sort of support, just fancier; in that case, it's practical for me to utilize contended, and therefore substantially cheaper, occasional time (LBiSat, for example, has quoted me $179/hr for 3MHz, and $250/hr for 4.5MHz as a rack rate, which is acceptable for my primary use, as long as the uncontended-service packet-loss and jitter numbers are low enough; contended time should be much cheaper than that), and in either use case, since there are at least 3 providers, with a total of something like 12 full transponders, who provide occasional iDirect connectivity, I shouldbe able to book the time *somewhere*, just as "traditional" DSNG operators (using DVB-S MPEG2, mostly) always have. Thanks to Kelly, I'd seen Skycasters, but didn't get the impression from the website that they did anything other than monthly service; to James, I'll check out Trustcomm; and to Ryan: yeah, there are Video-to-MPEG-to- IP-Ethernet encoders off the rack; for that use-case, I mostly need to find a matched pair that's efficient; the primary use of the truck will *not* be sports. :-) And I'll be leaving in the DVB-S modulator that's there, so if the truck is suitable to someone for rental, they'll be able to use it in the traditional fashion as well. My motivation for asking the question *here* was of course to get the operator perspective on the actual transport, if anyone had any. Cheers, -- jra From jarod.smouth at gmail.com Mon Jan 10 12:32:10 2011 From: jarod.smouth at gmail.com (jarod smith) Date: Mon, 10 Jan 2011 19:32:10 +0100 Subject: jetcore bigiron 4000 max ipv6 routes Message-ID: Hi, I know that jetcore bigiron 4000 allow max 400000 ipv4 routes. I want to add a dual stack. Is IPv6 routes are added to the IPv4 routes or are they stored elsewhere. Regards. From mikevs at xs4all.net Mon Jan 10 12:52:41 2011 From: mikevs at xs4all.net (Miquel van Smoorenburg) Date: Mon, 10 Jan 2011 19:52:41 +0100 Subject: Is Cisco equpiment de facto for you? In-Reply-To: <61EC3786-5732-4C5A-8938-A15E840DC75B@oicr.on.ca> References: <4D2B365C.5070506@gmail.com> Message-ID: <201101101852.p0AIqf3E029318@xs8.xs4all.nl> In article you write: >> Just as a pointer - one of the largest and most utilized IX (AMS-IX) has >> their platform built on Brocade devices. > >Brocade device's pre Foundry purchase correct? I can't see anyone that >large using Foundry in large deployments.. Well the ams-ix has been using Foundry for years, so it's really the Brocade-formerly-Foundry hardware. http://www.ams-ix.net/infrastructure/ http://www.ams-ix.net/infrastructure-detail/ Mike. From matthew at matthew.at Mon Jan 10 13:07:32 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 10 Jan 2011 11:07:32 -0800 Subject: Problems with removing NAT from a network In-Reply-To: References: <4D252B1F.8030506@kenweb.org> <3DFD6833-78C1-43D2-8074-6C89CFE3F2F3@arbor.net> <20110106043110.21C96876D21@drugs.dv.isc.org> <4D254ED8.6030006@matthew.at> <4D25F971.4090709@matthew.at> <4D2634E7.2060502@matthew.at> <9DEED87C-ED15-4D05-BCD6-69A5D4A69681@delong.com> <4D268097.6050502@matthew.at> <000101cbaf8a$dd300310$97900930$@iname.com> <4D295BC6.2060607@matthew.at> Message-ID: <4D2B58F4.20107@matthew.at> On 1/9/2011 6:42 AM, Cameron Byrne wrote: > > 1. The companies that have selected NAT64 as a tool for rolling out > IPv6 to address the IPv4 exhaustion business risk are aware of the > various application trade offs. They select NAT64 because it makes > business sense to aggressively go after IPv6 as the end-state and not > provide patches and work-arounds in their network to make dual-stack > work, which is not an end-state, it is a transition mechanism on the > path to ipv6. Also, as i mentioned for mobile, dual-stack is MUCH > more expensive. And ipv6-only works for the vast majority of my user > and my traffic. As long as your customers are aware that they are getting full IPv6 and a particularly crippled form of IPv4, then that's fine. But NAT64 isn't a solution for providing actual IPv4 connectivity to your customers.... just a poor simulation of it. > 2. You can pass this FUD around about people leaving networks so that > skype and bittorrent work. Last time i checked, many mobile network > operators and handsets only begrudgingly supported skype and bittorent > if at all. In fact, many networks spend considerable time and money > to stop them. I also know that Skype has some mobile partners. I am > not here to say if this is right or wrong, but i do not expect network > providers to alter their ipv6 strategy of business decisions to > accommodate Skype and Bittorrent. These applications have shown > amazing resiliency over the years to bust through firewalls and NATs, > and i am really amazed at how much opposition Skype is providing to > the IPv6 transition. Note that while I do work for Skype at the present time, I am not representing Skype or its business plans when I post here from my personal email account. Please do not take my statements here as "opposition from Skype" with regard to the IPv6 transition. And yes, the mobile environment is likely a special case at this time... but one would hope that in the long term we didn't have mobile providers that were "spending considerable time and money" to stop applications that work on the non-mobile Internet. > I imagine Skype would have a better hand if > Skype was IPv6 enabled a long time ago and pushing dual-stack and > waiting on the carriers, but Skype is IPv4-only just like all the rest > of the slow moving world. Agreed. Skype should (and again note that this is my personal opinion) have much better IPv6 support for use when both endpoints can speak IPv6. A situation that is presently rare. > If dual-stack had worked, we would not be > here talking about NAT64. But, dual-stack did not work. We are out of > IPv4 and the network still has to grow, hence IPv6-only + NAT64. Or any number of other transition choices. You've just chosen one that has a particular weakness. > And > again, dual-stack is much more expensive in mobile networks than > single stack so it won't happen with the Ipv4 side being endless > duplication of RFC 1918 and bogon space. Business needs often outweigh what would be technically superior. > 3. I am just here to create awareness of this technology that the > IETF as the protocol standardizer and the 3GPP as the mobile > architecture standardizer have accepted and are moving forward. I > want all applications to work with IPv6 and NAT64. For that to happen there needs to be, at a minimum, a way for applications to discover that they are in a NAT64 environment and work with it even if they do not use DNS to exchange addresses. And as I said before, *that* discussion probably belongs back on the BEHAVE list where, for whatever reason, it is hibernating. > When you are ready to talk about > moving forward, i am all ears. Until then, you can keep posturing > while the clock ticks on committed deployments. See above. Lets get the discovery problem back on top. Matthew Kaufman From matthew at matthew.at Mon Jan 10 13:18:29 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 10 Jan 2011 11:18:29 -0800 Subject: Problems with removing NAT from a network In-Reply-To: <50F0FF27-DE27-40BC-AB71-0B9EBCD7D0E3@delong.com> References: <4D252B1F.8030506@kenweb.org> <3DFD6833-78C1-43D2-8074-6C89CFE3F2F3@arbor.net> <20110106043110.21C96876D21@drugs.dv.isc.org> <4D254ED8.6030006@matthew.at> <4D25F971.4090709@matthew.at> <4D2634E7.2060502@matthew.at> <9DEED87C-ED15-4D05-BCD6-69A5D4A69681@delong.com> <4D267B9E.8040602@bogus.com> <4D268119.2050205@matthew.at> <4D284798.3010806@consolejunkie.net> <4D2959D7.7040407@matthew.at> <50F0FF27-DE27-40BC-AB71-0B9EBCD7D0E3@delong.com> Message-ID: <4D2B5B85.2040106@matthew.at> On 1/9/2011 9:51 PM, Owen DeLong wrote: > On Jan 8, 2011, at 10:46 PM, Matthew Kaufman wrote: > >> On 1/8/2011 3:16 AM, Leen Besselink wrote: >>> Hello Mr. Kaufman, >>> >>> In the upcoming years, we will have no IPv6 in some places and badly >>> performing IPv4 (CGN, etc.) with working IPv6 in others. >> Right. So we're discussing just how "badly performing" the IPv4 can be and still be acceptable as "access to the IPv4 Internet for your customers". >> >> I am arguing that CGN (NAT44 to get additional IPv4 to dual-stack) doesn't break nearly as much as NAT64/DNS64 does, and that in fact NAT64/DNS64 breaks *so much* that you probably can't/shouldn't sell it to your customers as "access to the IPv4 Internet". >> > NAT44 perhaps, but, the problem is that most CGNs proposed aren't NAT44, they're at best NAT444 and likely more like NAT44444 or worse in the real world. Well yes, at the very least it'll be NAT444 because people won't throw their home boxes out just because their carrier can now give them more synthetic IPv4 space. > Today, we have NAT44->Internet<-NAT44 in many sessions (Skype, VOIP, etc.) which connect to each other via STUN, UPnP, etc. > > Once you move from NAT44 to NAT444, most of the working traversal mechanisms break in interesting ways and at NAT44444, virtually nothing peer-to-peer-ish gets through at all as you simply can't abstract UPnP or anything else through that many layers at either end. > Maybe. It really depends on where you have nodes that can provide useful information about the topology. But yes, it gets uglier and uglier, eventually to the point of not working in some cases. But NAT64 is NAT too *and* makes the (incorrect) assumption that there's no good reason to pass IPv4 addresses around except in DNS. >> Note that for a *very* long time... much longer than there will be new IPv4 addresses available... there will be a whole lot of places that have good IPv4 and no IPv6. (As you note above) >> > I think this "*very* long time" will be much shorter than you think for meaningful values of "whole lot of places". Should we make a short list of countries and coffee shops and go test it out in two years? >>> If I was Skype I would make really sure that all my relay nodes and >>> login servers have IPv6 with enough bandwidth or can easily upgrade the >>> bandwidth where neede. And make sure atleast IPv6-client and >>> IPv6-servers communication works everywhere where there is IPv6. >> Clearly that would be needed to serve the IPv6-only users well. > I think this is definitely the ideal first step, but, I confess I don't know the inner workings of Skype. Even this is probably > a large effort in their codebase, so, I hope they've started working on it. >>> For your customers it is really easy. When Skype does not work, people >>> will jump ship where they can and maybe use Google Talk or whatever. >> Ah. But you're taking the bet that when Skype does not work on *your* network that provides IPv4 access via NAT64 people won't "jump ship" to a provider that uses CGN or even has enough native IPv4 addresses left around. > I'm betting Skype breaks just as bad in many CGN environments and that > the most likely candidate to actually work will be B4/AFTR or DS-Lite. This is probably a correct assessment. All NAT64 will fail unless there's discovery *and* the NAT64 behaves in a useful way, some CGN environments will fail and more so as both ends end up on different CGNs, and things like DS-Lite will do fairly well. At least that's how it looks to me, based on analysis I did for a different peer-to-peer protocol and these cases. > > Nor will anything else and broken IPv4 access is an apt term to describe > any of: > NAT64 > DS-LITE/B4/AFTR > CGN/LSN True. Though you get to choose in what way it is broken in each. > They each have their own brand of broken IPv4. Let's face it, while the > existing IPv4 internet isn't going to suddenly break when we run out of > available addresses, it is going to slowly suffer from increased breakage > as we attempt to recycle those addresses in ever more creative and > unintended ways. No question. >>> I'm sorry if it sounds a bit like fear mongering, but to me it sounds >>> like common sense that if a business is not prepared when the >>> environment that business operates in changes and that business does not >>> adapt to the changes in time that business might suffer. >> But that's true of ISPs when they choose how to deal with the lack of additional IPv4 space but continued customer demand to reach the IPv4 Internet, too, isn't it? >> > Yep. So which technology are you choosing? :) Matthew Kaufman From khomyakov.andrey at gmail.com Mon Jan 10 13:35:36 2011 From: khomyakov.andrey at gmail.com (Andrey Khomyakov) Date: Mon, 10 Jan 2011 14:35:36 -0500 Subject: Is Cisco equpiment de facto for you? In-Reply-To: References: <1177151411.1544.1294676497222.JavaMail.root@zimbra.network1.net> Message-ID: There have been awfully too many time when Cisco TAC would just say that since the problem you are trying to troubleshoot is between Cisco and VendorX, we can't help you. You should have bought Cisco for both sides. I had that happen when I was troubleshooting LLDP between 3750s and Avaya phones, TACACS between Cisco and tac_plus daemon, link bundling between juniper EX and Cisco, some obscure switching issues between CAT and Procurves and other examples like that just don't recall them anymore. Every time I'm reminded that if you have a lot of Cisco on the network, the rest should be cisco too, unless there is a very good technical/financial reason for it, but you should be prepared to be your own help in those cases. Vendors love to point at the other vendors for solutions. At least in my experience. My $0.02 Andrey On Mon, Jan 10, 2011 at 11:52 AM, Greg Whynott wrote: > I've tried to use other vendors threw out the years for internal L2/L3. > Always Cisco for perimeter routing/firewalling. > > from my personal experience, each time we took a chance and tried to use > another vendor for internal L2 needs, we would be reminded why it was a bad > choice down the road, due to hardware reliability, support issues, > multiple and ongoing software bugs, architectural design choices. Then > for the next few years I'd regret the decision. This is not to say Cisco > gear has been without its issues, but they are much fewer and handled > better when stuff hits the fan. > > the only other vendor at this point in my career I'd fee comfortable > deploying for internal enterprise switching, including HPC requirements > which is not CIsco branded, would be Force10 or Extreme. it has always > been Cisco for edge routing/firewalling, but i wouldn't be opposed to > trying Juniper for routing, I know of a few shops who do and they have been > pleased thus far. I've little or no experience with many of the other > vendors, and I'm sure they have good offerings, but I won't be beta > testing their firmwares anymore (one vendor insisted we upgrade our firmware > on our core equipment several times in one year?). > > > Cisco isn't a good choice if you don't have the budget for the smart net > contracts. They come at a price. a little 5505 with unrestricted license > and contract costs over 2k, a 5540 about 40k-70k depending on options, > with a yearly renewal of about 15k or more? > > -g > > > -- Andrey Khomyakov [khomyakov.andrey at gmail.com] From lowen at pari.edu Mon Jan 10 13:37:53 2011 From: lowen at pari.edu (Lamar Owen) Date: Mon, 10 Jan 2011 14:37:53 -0500 Subject: Satellite IP In-Reply-To: <17227231.906.1294684087129.JavaMail.root@benjamin.baylink.com> References: <17227231.906.1294684087129.JavaMail.root@benjamin.baylink.com> Message-ID: <201101101437.53284.lowen@pari.edu> On Monday, January 10, 2011 01:28:07 pm Jay Ashworth wrote: > My motivation for asking the question *here* was of course to get the operator > perspective on the actual transport, if anyone had any. I helped a radio station put together a remote trailer using a mobile satellite system back in 2004; SDN was the provider. Bandwidth we had available was I believe 1.5MB down and 384K up, burstable to 512K IIRC. Mobile satellite operations is a trip, especially with the 4 watt uplink transmitter required at the time for the wide uplink bandwidth. For the target use, UDP video and audio streaming, it worked very well once the system linked up; satellite acquisition and clearance for uplink transmitter RF turnon was typically a half an hour or so. When using TCP, however, the latency was noticeable. Once the stream started and slow-start finished the bandwidth was what you'd expect from a terrestrial circuit, but slow-start was really slow, thanks to the propagation time to and from geosync orbit. These systems had great use for VoIP PBX trunks for setting up a field phone system; the IP phone 'extensions' connected with WiFi, and the PBX itself was in the trailer, with the PBX to outside trunks handled by the satellite link. The system was decommissioned just this past year due to the uplink bandwidth cost, the intermittent system use, and the penetration of G3 data services in the area. From jra at baylink.com Mon Jan 10 13:35:54 2011 From: jra at baylink.com (Jay Ashworth) Date: Mon, 10 Jan 2011 14:35:54 -0500 (EST) Subject: Satellite IP In-Reply-To: <11105.1294685303@localhost> Message-ID: <31834621.930.1294688154398.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Valdis Kletnieks" > So what you're saying is that after a Kyoto/Chile sized quake, or a > Katrina, or a Quebec 1990 ice storm, you can *guarantee* that you can > still fill all requests for transponder space, and *still* satisfy every > single customer who wants to book 4 hours on Thursday on short notice. > > Like I said - 98% is easy. 100% is hard. Sure. But 100% is also your strawman, I believe; no? Particularly in the specific space we're presently talking about: iDirect Satellite IP service over transponders dedicated to the hub operator, the service is a bit more elastic than I believe you imagine. *Most* iDirect customers are sharing a carrier; it's a TDMA service. It's only the fairly rare ones, like I may be, who actually want a "1:1" or uncontended carrier all to ourselves. Depending on your spectrum management practices as a hub operator, if you have an entire 36MHz Ku band transponder -- or better, 2 on the same bird -- with which to play, you may be able to carve out 3MHz worth of free space, without *anyone* getting knocked off line. The 1000 other clients who are contending for that 72MHz of space merely have to contend a very small amount harder. So in actual fact, it may be possible to both meet your SLA's to the contention customers and *still* give an occasional customer 100% uncontended bandwidth for a short period of time; it's one of the reasons I propose to go that way: it *increases* my odds of getting a clean slot from at least one of 3 hub providers at any given hour. Cheers, -- jra From alh-ietf at tndh.net Mon Jan 10 13:46:23 2011 From: alh-ietf at tndh.net (Tony Hain) Date: Mon, 10 Jan 2011 11:46:23 -0800 Subject: IPv6 - real vs theoretical problems In-Reply-To: References: Message-ID: <085301cbb0ff$2dbb74c0$89325e40$@net> ... yes I know you understand operational issues. While managed networks can 'reverse the damage', there is no way to fix that for consumer unmanaged networks. Whatever gets deployed now, that is what the routers will be built to deal with, and it will be virtually impossible to change it due to the 'installed base' and lack of knowledgeable management. It is hard enough getting the product teams to accept that it is possible to build a self-configuring home network without having that be crippled by braindead conservation. The worst possible value I can see for delegation to the home is /56, yet that is the most popular value because people have their heads so far into the dark void of conservation they can't let accept that the space will be 'wasted sitting on the shelf at IANA when somebody comes along with a better idea in the next 500 years'. I understand the desire to 'do it like we do with IPv4', because that reduces the learning curve, but it also artificially restricts IPv6, ensures that the work is doubled to remove the restraints later, and makes it even harder to show value in the short term because 'it is just like IPv4 with a different bit pattern'. "IPv6 is not just IPv4 with bigger addresses" no matter what the popular mantra is. The only way you can even get close to that kind of argument is if you totally myopic on BGP, and even then there are differences. Bottom line, just fix the tools to deal with the reality of IPv6, and move on. Tony > -----Original Message----- > From: Deepak Jain [mailto:deepak at ai.net] > Sent: Thursday, January 06, 2011 2:01 PM > To: NANOG list > Subject: IPv6 - real vs theoretical problems > > > Please, before you flame out, recognize I know a bit of what I am > talking about. You can verify this by doing a search on NANOG archives. > My point is to actually engage in an operational discussion on this and > not insult (or be insulted). > > While I understand the theoretical advantages of /64s and /56s and /48s > for all kinds of purposes, *TODAY* there are very few folks that are > actually using any of them. No typical customer knows what do to do > (for the most part) with their own /48, and other than > autoconfiguration, there is no particular advantage to a /64 block for > a single server -- yet. The left side of the prefix I think people and > routers are reasonably comfortable with, it's the "host" side that > presents the most challenge. > > My interest is principally in servers and high availability equipment > (routers, etc) and other things that live in POPs and datacenters, so > autoconfiguration doesn't even remotely appeal to me for anything. In a > datacenter, many of these concerns about having routers fall over exist > (high bandwidth links, high power equipment trying to do as many things > as it can, etc). > > Wouldn't a number of problems go away if we just, for now, follow the > IPv4 lessons/practices like allocating the number of addresses a > customer needs --- say /122s or /120s that current router architectures > know how to handle -- to these boxes/interfaces today, while just > reserving /64 or /56 spaces for each of them for whenever the magic day > comes along where they can be used safely? > > As far as I can tell, this "crippling" of the address space is > completely reversible, it's a reasonable step forward and the only > "operational" loss is you can't do all the address jumping and > obfuscation people like to talk about... which I'm not sure is a loss. > > In your enterprise, behind your firewall, whatever, where you want > autoconfig to work, and have some way of dealing with all of the dead > space, more power to you. But operationally, is *anything* gained today > by giving every host a /64 to screw around in that isn't accomplished > by a /120 or so? > > Thanks, > > DJ > > From charles at knownelement.com Mon Jan 10 13:49:08 2011 From: charles at knownelement.com (Charles N Wyble) Date: Mon, 10 Jan 2011 11:49:08 -0800 Subject: Is Cisco equpiment de facto for you? In-Reply-To: References: Message-ID: <4D2B62B4.3050107@knownelement.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 pfsense in redundant pair for routing/security/vlan termination cisco all the way for l2 switching On 01/10/2011 09:38 AM, James Smith wrote: > All the places I've worked in the past decade have been all Cisco shops for > routing and switching, with a lot of Cisco use for security too (firewalls > and IDS). Same with my current position, but we're switching to Juniper for > all those product categories. Same or better performance, but 10-20% less > cost. Additionally, I find the Juniper command line has more features that > make operating and monitoring much more efficient. Also, JunOS has only one > development train which means that the commands I use work on every single > Juniper platform. It always bugs me when I?m trying to setup QOS across a > network with different Cisco platforms (CatOS, ASA, different versions of > IOS) and each platform has a completely different way of doing it. > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNK2KwAAoJEMvvG/TyLEAtXloP/3PkJv8vGs4zZMpaQVO++Err JOtLbTCuKDIpmaB71KFBPUfMBzCNHfpiV1hrkY2gRjf+MC+9510kdC6KT2mPW2lz KyJXkvy3TxZn2LgOsYodQGBdq4ngmtdUBNJHWkOZpOZ3p1mxWUTmqsoSt+7PwNw+ LN5cYfxTVx083LukISfTaZQLDvAbJETfUunvi5k8q+JpJOgQM226nN+eMSgMmuU0 cDdWclzSeLuJwM7NZD2pijm7fNT6rZj2NynLvq161sMy6CLmCUckzyRNz6dxjBuT 8Pvabs02CfCsFBkK2QBdhAQpyPcgCyZIj01PM2IYeKfnX2fUwO/k2tIEAkg6jxLO EpJEJACWIN8Clbs6Lxz7rNhTZozsNeSmSF9yMLbQZubUu8JFa0JnW3KhQEYqBBgB 6JK1NS7VJz5DEsnm3ZrH2Udwo+WTm4AdoLVmaAQUlHLt5A2vchYS8OEA4FJuy24o gzXZ+cPVqqx3FOoOSlAsTDt7ofM78KyuqbAJqubwWOBjxIFSZjOGTKAhcrrW6tzc NGejHfiTU6LlnfJ9HFY0NuS+LccA36RYdu2J/Ubm6v6JqDZqCbBdfdTLnxgfamp7 tZtziA0c7Jk9tjh0KYncgEtqlLQPyOEWZXHHNHDX3LOcpUZWW1OhdTzyV4fOR8N4 zUzZ+qfrmN4VRpr4VHHt =c7OX -----END PGP SIGNATURE----- From lowen at pari.edu Mon Jan 10 13:52:56 2011 From: lowen at pari.edu (Lamar Owen) Date: Mon, 10 Jan 2011 14:52:56 -0500 Subject: NIST IPv6 document In-Reply-To: <4D272277.8010207@gmail.com> References: <201101061429.p06ETB7g096271@aurora.sol.net> Message-ID: <201101101452.56885.lowen@pari.edu> On Friday, January 07, 2011 09:25:59 am David Sparro wrote: > I find that the security "Layers" advocates tend not to look at the > differing value of each of those layers. Different layers very much have different values, and, yes, this is often glossed over. > Going back to the physical door analogy, it's like saying that a bank > vault protected by a bank vault door is less secure than a vault with > the bank vault door AND a screen door. More analogous would be the safe with glass relockers and a vial of tear gas behind the ideal drill point. Yes, those do exist, and, should you want to see a photo of such a vial, I can either provide one (have to take the photo with the safe door open next time I'm on that site, which may be a while with all this snow and ice on the ground) or you can find pics through google. Even physical locks have layered security principles. Think Medeco locks with chisel-pointed pins and the associated sidebar in the center, or ASSA's Twin double-stack pin technology, or the use of spool pins in locks, or Schlage's Primus system (also sidebar driven) or anti-drill armor in front of the pin stack (to prevent drilling the shear line), etc. The use of layers in the physical security realm is a proven concept, and the synergy of the layers has been shown effective over time. Not totally secure, of course, but as the number of layers increases the security becomes better and better. From gbonser at seven.com Mon Jan 10 13:54:25 2011 From: gbonser at seven.com (George Bonser) Date: Mon, 10 Jan 2011 11:54:25 -0800 Subject: Is Cisco equpiment de facto for you? In-Reply-To: References: <1177151411.1544.1294676497222.JavaMail.root@zimbra.network1.net> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC132AD@RWC-EX1.corp.seven.com> > From: Andrey Khomyakov > Sent: Monday, January 10, 2011 11:36 AM > To: nanog group > Subject: Re: Is Cisco equpiment de facto for you? > > There have been awfully too many time when Cisco TAC would just say > that > since the problem you are trying to troubleshoot is between Cisco and > VendorX, we can't help you. You should have bought Cisco for both > sides. > I had that happen when I was troubleshooting LLDP between 3750s and > Avaya > phones, TACACS between Cisco and tac_plus daemon, link bundling between > juniper EX and Cisco, some obscure switching issues between CAT and > Procurves and other examples like that just don't recall them anymore. On the other hand, the other vendors are generally willing to bend over backwards and sort out interoperability issues and often have technical resources that are just as experienced on the Cisco gear as the Cisco techs are. And while Cisco might have at one time done the "you should have bought Cisco (click)" act, I don't get that impression these days as more networks have equipment from mixed vendors for very specific parts. There are reasons why one might choose to purchase gear from different vendors in a "best of breed" approach. One might have load balancers from A10 or Citrix, a firewall from Juniper or Palo Alto Networks, access switches from Arista, core gear from Brocade and maybe even a couple of Cisco boxes here and there where they make sense. Having one single vendor for no reason other than to simply ease troubleshooting might be a valid reason in some networks but doesn't make sense in others. If you don't have the technical resources to sort out issues in-house, sure, it might make sense to let the vendor do it all and in that case you will need a network from one vendor. Different vendors have different things they do very well. A network might want to leverage those good aspects in their network design. It basically comes down to the type of service you are offering and how much money you have. For a "best of breed" network, you might have to pay a little more for in-house talent. For a homogeneous network, you might sacrifice performance in some areas for savings on talent. It just depends on what is important to you. No one vendor, in my experience, makes the very best gear at the very best price in every portion of the network. That isn't Cisco specific, it goes for practically all vendors. From cmadams at hiwaay.net Mon Jan 10 14:04:28 2011 From: cmadams at hiwaay.net (Chris Adams) Date: Mon, 10 Jan 2011 14:04:28 -0600 Subject: Is Cisco equpiment de facto for you? In-Reply-To: References: <1177151411.1544.1294676497222.JavaMail.root@zimbra.network1.net> Message-ID: <20110110200428.GE8877@hiwaay.net> Once upon a time, Andrey Khomyakov said: > There have been awfully too many time when Cisco TAC would just say that > since the problem you are trying to troubleshoot is between Cisco and > VendorX, we can't help you. You should have bought Cisco for both sides. That kind of behavior from a vendor tells me I shouldn't have bought that vendor for either side. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From brandon.kim at brandontek.com Mon Jan 10 14:04:57 2011 From: brandon.kim at brandontek.com (Brandon Kim) Date: Mon, 10 Jan 2011 15:04:57 -0500 Subject: Is Cisco equpiment de facto for you? In-Reply-To: References: <1177151411.1544.1294676497222.JavaMail.root@zimbra.network1.net>, , Message-ID: To your point Andrey, It probably works both ways too. I'm sure HP would love to finger point as well. I remember reading for my CCNP one of the thought process behind getting all Cisco is the very reason you pointed out, get all Cisco! How convenient though for Cisco to do that, I wonder if they are being sincere(sarcasm). Wouldn't it a perfect world for Cisco to just have everyone buy their stuff...I think it's a cop out though and you really should try to support your product as best you can if it is connected to another vendor. I'm sad to hear that TACACS took that route. I hope they at least tried their hardest to support you..... > From: khomyakov.andrey at gmail.com > Date: Mon, 10 Jan 2011 14:35:36 -0500 > Subject: Re: Is Cisco equpiment de facto for you? > To: nanog at nanog.org > > There have been awfully too many time when Cisco TAC would just say that > since the problem you are trying to troubleshoot is between Cisco and > VendorX, we can't help you. You should have bought Cisco for both sides. > I had that happen when I was troubleshooting LLDP between 3750s and Avaya > phones, TACACS between Cisco and tac_plus daemon, link bundling between > juniper EX and Cisco, some obscure switching issues between CAT and > Procurves and other examples like that just don't recall them anymore. > > Every time I'm reminded that if you have a lot of Cisco on the network, the > rest should be cisco too, unless there is a very good technical/financial > reason for it, but you should be prepared to be your own help in those > cases. > > Vendors love to point at the other vendors for solutions. At least in my > experience. > > My $0.02 > > Andrey > > On Mon, Jan 10, 2011 at 11:52 AM, Greg Whynott wrote: > > > I've tried to use other vendors threw out the years for internal L2/L3. > > Always Cisco for perimeter routing/firewalling. > > > > from my personal experience, each time we took a chance and tried to use > > another vendor for internal L2 needs, we would be reminded why it was a bad > > choice down the road, due to hardware reliability, support issues, > > multiple and ongoing software bugs, architectural design choices. Then > > for the next few years I'd regret the decision. This is not to say Cisco > > gear has been without its issues, but they are much fewer and handled > > better when stuff hits the fan. > > > > the only other vendor at this point in my career I'd fee comfortable > > deploying for internal enterprise switching, including HPC requirements > > which is not CIsco branded, would be Force10 or Extreme. it has always > > been Cisco for edge routing/firewalling, but i wouldn't be opposed to > > trying Juniper for routing, I know of a few shops who do and they have been > > pleased thus far. I've little or no experience with many of the other > > vendors, and I'm sure they have good offerings, but I won't be beta > > testing their firmwares anymore (one vendor insisted we upgrade our firmware > > on our core equipment several times in one year?). > > > > > > Cisco isn't a good choice if you don't have the budget for the smart net > > contracts. They come at a price. a little 5505 with unrestricted license > > and contract costs over 2k, a 5540 about 40k-70k depending on options, > > with a yearly renewal of about 15k or more? > > > > -g > > > > > > > -- > Andrey Khomyakov > [khomyakov.andrey at gmail.com] From mikea at mikea.ath.cx Mon Jan 10 14:09:25 2011 From: mikea at mikea.ath.cx (mikea) Date: Mon, 10 Jan 2011 14:09:25 -0600 Subject: NIST IPv6 document In-Reply-To: <201101101452.56885.lowen@pari.edu> References: <4D272277.8010207@gmail.com> <201101101452.56885.lowen@pari.edu> Message-ID: <20110110200925.GD51955@mikea.ath.cx> On Mon, Jan 10, 2011 at 02:52:56PM -0500, Lamar Owen wrote: > On Friday, January 07, 2011 09:25:59 am David Sparro wrote: > > I find that the security "Layers" advocates tend not to look at the > > differing value of each of those layers. > > Different layers very much have different values, and, yes, this is often glossed over. > > > Going back to the physical door analogy, it's like saying that a bank > > vault protected by a bank vault door is less secure than a vault with > > the bank vault door AND a screen door. > > More analogous would be the safe with glass relockers and a vial of > tear gas behind the ideal drill point. Yes, those do exist, and, > should you want to see a photo of such a vial, I can either provide > one (have to take the photo with the safe door open next time I'm on > that site, which may be a while with all this snow and ice on the > ground) or you can find pics through google. > > Even physical locks have layered security principles. Think Medeco > locks with chisel-pointed pins and the associated sidebar in the > center, or ASSA's Twin double-stack pin technology, or the use of > spool pins in locks, or Schlage's Primus system (also sidebar driven) > or anti-drill armor in front of the pin stack (to prevent drilling the > shear line), etc. The use of layers in the physical security realm > is a proven concept, and the synergy of the layers has been shown > effective over time. Not totally secure, of course, but as the number > of layers increases the security becomes better and better. My father used to tell me that "Locks keep the honest people out." He was right; the clever non-honest are the ones we have to deal with at that level. Computers are so great a force multiplier that we are having to do the same sorts of things to defend against assaults from them. -- Mike Andrews, W5EGO mikea at mikea.ath.cx Tired old sysadmin From Greg.Whynott at oicr.on.ca Mon Jan 10 14:13:16 2011 From: Greg.Whynott at oicr.on.ca (Greg Whynott) Date: Mon, 10 Jan 2011 15:13:16 -0500 Subject: Is Cisco equpiment de facto for you? In-Reply-To: <20110110200428.GE8877@hiwaay.net> References: <1177151411.1544.1294676497222.JavaMail.root@zimbra.network1.net> <20110110200428.GE8877@hiwaay.net> Message-ID: <1F095A7A-0774-43E5-B4E0-BFF3111EF292@oicr.on.ca> i think it really depends on who answers your call. I've called Cisco a few times before for inter vendor issues and they gave us the " call the other vendor " finger. .. Other times they saved the day. i know some shops negotiate their support contract which precludes them from going threw the regular support escalation process. you get to speak to a more senior tech on the first 'hello'. -g On Jan 10, 2011, at 3:04 PM, Chris Adams wrote: > Once upon a time, Andrey Khomyakov said: >> There have been awfully too many time when Cisco TAC would just say that >> since the problem you are trying to troubleshoot is between Cisco and >> VendorX, we can't help you. You should have bought Cisco for both sides. > > That kind of behavior from a vendor tells me I shouldn't have bought > that vendor for either side. -- This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization. From nickellman at gmail.com Mon Jan 10 14:16:09 2011 From: nickellman at gmail.com (b nickell) Date: Mon, 10 Jan 2011 13:16:09 -0700 Subject: How are you aggregating WAN customers these days? In-Reply-To: References: Message-ID: The ASRs seem to be the consensus in a lot of places. Wondering if anyone has tried anything like aggregating T1 customers onto a mux box, then connecting that back to a 6500. I work in that kind of topology all day long/ both in 6500 & ASR's. All is well/ On Mon, Jan 10, 2011 at 7:51 AM, Chris wrote: > Hello, > > I'm looking to put some feelers out there and see what people are > doing to aggregate WAN customers (T1,T3, etc...) these days. What > platforms/devices are you using? What seems to be working/not working? > Any insights would be great! > > Thanks, > > Chris > > -- -B From Greg.Whynott at oicr.on.ca Mon Jan 10 14:20:06 2011 From: Greg.Whynott at oicr.on.ca (Greg Whynott) Date: Mon, 10 Jan 2011 15:20:06 -0500 Subject: Is Cisco equpiment de facto for you? In-Reply-To: References: <1177151411.1544.1294676497222.JavaMail.root@zimbra.network1.net>, , Message-ID: just a side note, HP probably was the most helpful vendor i've dealt with in relation to solving/providing inter vendor interoperability solutions. they have PDF booklets on many things we would run into during work. for example, setting up STP between Cisco and HP gear, ( http://cdn.procurve.com/training/Manuals/ProCurve-and-Cisco-STP-Interoperability.pdf ). At the time the other vendor in this case (cisco) flat our refused to help us. this was a few years back tho, things may of changed. I'd ask support "you are not telling me i'm the _only_ customer trying to do this" ? to which they would try and play the "well most people don't mix gear".. HP's example should be the yard stick in the field. -g On Jan 10, 2011, at 3:04 PM, Brandon Kim wrote: > > To your point Andrey, > > It probably works both ways too. I'm sure HP would love to finger point as well. I remember reading for my CCNP one > of the thought process behind getting all Cisco is the very reason you pointed out, get all Cisco! > > How convenient though for Cisco to do that, I wonder if they are being sincere(sarcasm). > > Wouldn't it a perfect world for Cisco to just have everyone buy their stuff...I think it's a cop out though and you really should > try to support your product as best you can if it is connected to another vendor. > > I'm sad to hear that TACACS took that route. I hope they at least tried their hardest to support you..... > > > >> From: khomyakov.andrey at gmail.com >> Date: Mon, 10 Jan 2011 14:35:36 -0500 >> Subject: Re: Is Cisco equpiment de facto for you? >> To: nanog at nanog.org >> >> There have been awfully too many time when Cisco TAC would just say that >> since the problem you are trying to troubleshoot is between Cisco and >> VendorX, we can't help you. You should have bought Cisco for both sides. >> I had that happen when I was troubleshooting LLDP between 3750s and Avaya >> phones, TACACS between Cisco and tac_plus daemon, link bundling between >> juniper EX and Cisco, some obscure switching issues between CAT and >> Procurves and other examples like that just don't recall them anymore. >> >> Every time I'm reminded that if you have a lot of Cisco on the network, the >> rest should be cisco too, unless there is a very good technical/financial >> reason for it, but you should be prepared to be your own help in those >> cases. >> >> Vendors love to point at the other vendors for solutions. At least in my >> experience. >> >> My $0.02 >> >> Andrey >> >> On Mon, Jan 10, 2011 at 11:52 AM, Greg Whynott wrote: >> >>> I've tried to use other vendors threw out the years for internal L2/L3. >>> Always Cisco for perimeter routing/firewalling. >>> >>> from my personal experience, each time we took a chance and tried to use >>> another vendor for internal L2 needs, we would be reminded why it was a bad >>> choice down the road, due to hardware reliability, support issues, >>> multiple and ongoing software bugs, architectural design choices. Then >>> for the next few years I'd regret the decision. This is not to say Cisco >>> gear has been without its issues, but they are much fewer and handled >>> better when stuff hits the fan. >>> >>> the only other vendor at this point in my career I'd fee comfortable >>> deploying for internal enterprise switching, including HPC requirements >>> which is not CIsco branded, would be Force10 or Extreme. it has always >>> been Cisco for edge routing/firewalling, but i wouldn't be opposed to >>> trying Juniper for routing, I know of a few shops who do and they have been >>> pleased thus far. I've little or no experience with many of the other >>> vendors, and I'm sure they have good offerings, but I won't be beta >>> testing their firmwares anymore (one vendor insisted we upgrade our firmware >>> on our core equipment several times in one year?). >>> >>> >>> Cisco isn't a good choice if you don't have the budget for the smart net >>> contracts. They come at a price. a little 5505 with unrestricted license >>> and contract costs over 2k, a 5540 about 40k-70k depending on options, >>> with a yearly renewal of about 15k or more? >>> >>> -g >>> >>> >>> >> -- >> Andrey Khomyakov >> [khomyakov.andrey at gmail.com] > -- This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization. From bruns at 2mbit.com Mon Jan 10 14:32:10 2011 From: bruns at 2mbit.com (Brielle Bruns) Date: Mon, 10 Jan 2011 20:32:10 +0000 Subject: How are you aggregating WAN customers these days? Message-ID: <1105696211-1294691514-cardhu_decombobulator_blackberry.rim.net-1715311788-@bda400.bisx.prod.on.blackberry> Back in the days when I still did NOC stuff, we'd bring in individual T1 lines through a Kentrox EZ-T3, which would hand off a channelized T3 to a 7513. With the EZ-T3, it was literally just plug and play. I believe the Atlas 800 series can be used in the same ways, but its been 10 years, so I may be mistaken... ------Original Message------ From: b nickell To: Chris Cc: nanog at nanog.org Subject: Re: How are you aggregating WAN customers these days? Sent: Jan 10, 2011 1:16 PM The ASRs seem to be the consensus in a lot of places. Wondering if anyone has tried anything like aggregating T1 customers onto a mux box, then connecting that back to a 6500. I work in that kind of topology all day long/ both in 6500 & ASR's. All is well/ On Mon, Jan 10, 2011 at 7:51 AM, Chris wrote: > Hello, > > I'm looking to put some feelers out there and see what people are > doing to aggregate WAN customers (T1,T3, etc...) these days. What > platforms/devices are you using? What seems to be working/not working? > Any insights would be great! > > Thanks, > > Chris > > -- -B -- Brielle Bruns http://www.sosdg.org / http://www.ahbl.org From brandon.kim at brandontek.com Mon Jan 10 14:39:19 2011 From: brandon.kim at brandontek.com (Brandon Kim) Date: Mon, 10 Jan 2011 15:39:19 -0500 Subject: Is Cisco equpiment de facto for you? In-Reply-To: References: <1177151411.1544.1294676497222.JavaMail.root@zimbra.network1.net>, , , , , , Message-ID: to which they would try and play the "well most people don't mix gear".. ha! Funny if you responded with, "Oh really? Thanks I didn't know that, I guess I'll get all HP...who do I talk to, to return this Cisco router?" > From: Greg.Whynott at oicr.on.ca > To: brandon.kim at brandontek.com > CC: khomyakov.andrey at gmail.com; nanog at nanog.org > Date: Mon, 10 Jan 2011 15:20:06 -0500 > Subject: Re: Is Cisco equpiment de facto for you? > > just a side note, HP probably was the most helpful vendor i've dealt with in relation to solving/providing inter vendor interoperability solutions. they have PDF booklets on many things we would run into during work. for example, setting up STP between Cisco and HP gear, ( http://cdn.procurve..com/training/Manuals/ProCurve-and-Cisco-STP-Interoperability.pdf ). > > At the time the other vendor in this case (cisco) flat our refused to help us. this was a few years back tho, things may of changed. I'd ask support "you are not telling me i'm the _only_ customer trying to do this" ? to which they would try and play the "well most people don't mix gear".. > > HP's example should be the yard stick in the field. > > -g > > > > On Jan 10, 2011, at 3:04 PM, Brandon Kim wrote: > > > > > To your point Andrey, > > > > It probably works both ways too. I'm sure HP would love to finger point as well. I remember reading for my CCNP one > > of the thought process behind getting all Cisco is the very reason you pointed out, get all Cisco! > > > > How convenient though for Cisco to do that, I wonder if they are being sincere(sarcasm). > > > > Wouldn't it a perfect world for Cisco to just have everyone buy their stuff...I think it's a cop out though and you really should > > try to support your product as best you can if it is connected to another vendor. > > > > I'm sad to hear that TACACS took that route. I hope they at least tried their hardest to support you..... > > > > > > > >> From: khomyakov.andrey at gmail.com > >> Date: Mon, 10 Jan 2011 14:35:36 -0500 > >> Subject: Re: Is Cisco equpiment de facto for you? > >> To: nanog at nanog.org > >> > >> There have been awfully too many time when Cisco TAC would just say that > >> since the problem you are trying to troubleshoot is between Cisco and > >> VendorX, we can't help you. You should have bought Cisco for both sides. > >> I had that happen when I was troubleshooting LLDP between 3750s and Avaya > >> phones, TACACS between Cisco and tac_plus daemon, link bundling between > >> juniper EX and Cisco, some obscure switching issues between CAT and > >> Procurves and other examples like that just don't recall them anymore. > >> > >> Every time I'm reminded that if you have a lot of Cisco on the network, the > >> rest should be cisco too, unless there is a very good technical/financial > >> reason for it, but you should be prepared to be your own help in those > >> cases. > >> > >> Vendors love to point at the other vendors for solutions. At least in my > >> experience. > >> > >> My $0.02 > >> > >> Andrey > >> > >> On Mon, Jan 10, 2011 at 11:52 AM, Greg Whynott wrote: > >> > >>> I've tried to use other vendors threw out the years for internal L2/L3. > >>> Always Cisco for perimeter routing/firewalling. > >>> > >>> from my personal experience, each time we took a chance and tried to use > >>> another vendor for internal L2 needs, we would be reminded why it was a bad > >>> choice down the road, due to hardware reliability, support issues, > >>> multiple and ongoing software bugs, architectural design choices. Then > >>> for the next few years I'd regret the decision. This is not to say Cisco > >>> gear has been without its issues, but they are much fewer and handled > >>> better when stuff hits the fan. > >>> > >>> the only other vendor at this point in my career I'd fee comfortable > >>> deploying for internal enterprise switching, including HPC requirements > >>> which is not CIsco branded, would be Force10 or Extreme. it has always > >>> been Cisco for edge routing/firewalling, but i wouldn't be opposed to > >>> trying Juniper for routing, I know of a few shops who do and they have been > >>> pleased thus far. I've little or no experience with many of the other > >>> vendors, and I'm sure they have good offerings, but I won't be beta > >>> testing their firmwares anymore (one vendor insisted we upgrade our firmware > >>> on our core equipment several times in one year?). > >>> > >>> > >>> Cisco isn't a good choice if you don't have the budget for the smart net > >>> contracts. They come at a price. a little 5505 with unrestricted license > >>> and contract costs over 2k, a 5540 about 40k-70k depending on options, > >>> with a yearly renewal of about 15k or more? > >>> > >>> -g > >>> > >>> > >>> > >> -- > >> Andrey Khomyakov > >> [khomyakov.andrey at gmail.com] > > > > > -- > > This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization. From tad1214 at gmail.com Mon Jan 10 15:14:44 2011 From: tad1214 at gmail.com (Thomas Donnelly) Date: Mon, 10 Jan 2011 15:14:44 -0600 Subject: Is Cisco equpiment de facto for you? In-Reply-To: References: <1177151411.1544.1294676497222.JavaMail.root@zimbra.network1.net> Message-ID: On Mon, 10 Jan 2011 14:39:19 -0600, Brandon Kim wrote: > > > to which they would try and play the "well most people don't mix gear".. > > > > ha! Funny if you responded with, "Oh really? Thanks I didn't know that, > I guess I'll get all HP...who do I talk to, to return this Cisco router?" I've threatened that one against Juniper and minutes later I had an engineer on the phone. At 3:30am. Funny how once you mention buying another vendor they raise an eyebrow. > > > > > >> From: Greg.Whynott at oicr.on.ca >> To: brandon.kim at brandontek.com >> CC: khomyakov.andrey at gmail.com; nanog at nanog.org >> Date: Mon, 10 Jan 2011 15:20:06 -0500 >> Subject: Re: Is Cisco equpiment de facto for you? >> >> just a side note, HP probably was the most helpful vendor i've dealt >> with in relation to solving/providing inter vendor interoperability >> solutions. they have PDF booklets on many things we would run into >> during work. for example, setting up STP between Cisco and HP gear, >> ( >> http://cdn.procurve..com/training/Manuals/ProCurve-and-Cisco-STP-Interoperability.pdf >> ). >> >> At the time the other vendor in this case (cisco) flat our refused to >> help us. this was a few years back tho, things may of changed. I'd >> ask support "you are not telling me i'm the _only_ customer trying to >> do this" ? to which they would try and play the "well most people >> don't mix gear".. >> >> HP's example should be the yard stick in the field. >> >> -g >> >> >> >> On Jan 10, 2011, at 3:04 PM, Brandon Kim wrote: >> >> > >> > To your point Andrey, >> > >> > It probably works both ways too. I'm sure HP would love to finger >> point as well. I remember reading for my CCNP one >> > of the thought process behind getting all Cisco is the very reason >> you pointed out, get all Cisco! >> > >> > How convenient though for Cisco to do that, I wonder if they are >> being sincere(sarcasm). >> > >> > Wouldn't it a perfect world for Cisco to just have everyone buy their >> stuff...I think it's a cop out though and you really should >> > try to support your product as best you can if it is connected to >> another vendor. >> > >> > I'm sad to hear that TACACS took that route. I hope they at least >> tried their hardest to support you..... >> > >> > >> > >> >> From: khomyakov.andrey at gmail.com >> >> Date: Mon, 10 Jan 2011 14:35:36 -0500 >> >> Subject: Re: Is Cisco equpiment de facto for you? >> >> To: nanog at nanog.org >> >> >> >> There have been awfully too many time when Cisco TAC would just say >> that >> >> since the problem you are trying to troubleshoot is between Cisco and >> >> VendorX, we can't help you. You should have bought Cisco for both >> sides. >> >> I had that happen when I was troubleshooting LLDP between 3750s and >> Avaya >> >> phones, TACACS between Cisco and tac_plus daemon, link bundling >> between >> >> juniper EX and Cisco, some obscure switching issues between CAT and >> >> Procurves and other examples like that just don't recall them >> anymore. >> >> >> >> Every time I'm reminded that if you have a lot of Cisco on the >> network, the >> >> rest should be cisco too, unless there is a very good >> technical/financial >> >> reason for it, but you should be prepared to be your own help in >> those >> >> cases. >> >> >> >> Vendors love to point at the other vendors for solutions. At least >> in my >> >> experience. >> >> >> >> My $0.02 >> >> >> >> Andrey >> >> >> >> On Mon, Jan 10, 2011 at 11:52 AM, Greg Whynott >> wrote: >> >> >> >>> I've tried to use other vendors threw out the years for internal >> L2/L3. >> >>> Always Cisco for perimeter routing/firewalling. >> >>> >> >>> from my personal experience, each time we took a chance and tried >> to use >> >>> another vendor for internal L2 needs, we would be reminded why it >> was a bad >> >>> choice down the road, due to hardware reliability, support issues, >> >>> multiple and ongoing software bugs, architectural design choices. >> Then >> >>> for the next few years I'd regret the decision. This is not to >> say Cisco >> >>> gear has been without its issues, but they are much fewer and >> handled >> >>> better when stuff hits the fan. >> >>> >> >>> the only other vendor at this point in my career I'd fee comfortable >> >>> deploying for internal enterprise switching, including HPC >> requirements >> >>> which is not CIsco branded, would be Force10 or Extreme. it has >> always >> >>> been Cisco for edge routing/firewalling, but i wouldn't be opposed >> to >> >>> trying Juniper for routing, I know of a few shops who do and they >> have been >> >>> pleased thus far. I've little or no experience with many of the >> other >> >>> vendors, and I'm sure they have good offerings, but I won't be >> beta >> >>> testing their firmwares anymore (one vendor insisted we upgrade our >> firmware >> >>> on our core equipment several times in one year?). >> >>> >> >>> >> >>> Cisco isn't a good choice if you don't have the budget for the >> smart net >> >>> contracts. They come at a price. a little 5505 with >> unrestricted license >> >>> and contract costs over 2k, a 5540 about 40k-70k depending on >> options, >> >>> with a yearly renewal of about 15k or more? >> >>> >> >>> -g >> >>> >> >>> >> >>> >> >> -- >> >> Andrey Khomyakov >> >> [khomyakov.andrey at gmail.com] >> > >> >> >> -- >> >> This message and any attachments may contain confidential and/or >> privileged information for the sole use of the intended recipient. Any >> review or distribution by anyone other than the person for whom it was >> originally intended is strictly prohibited. If you have received this >> message in error, please contact the sender and delete all copies. >> Opinions, conclusions or other information contained in this message >> may not be that of the organization. > -- Using Opera's revolutionary email client: http://www.opera.com/mail/ From Greg.Whynott at oicr.on.ca Mon Jan 10 15:30:44 2011 From: Greg.Whynott at oicr.on.ca (Greg Whynott) Date: Mon, 10 Jan 2011 16:30:44 -0500 Subject: Is Cisco equpiment de facto for you? In-Reply-To: References: <1177151411.1544.1294676497222.JavaMail.root@zimbra.network1.net> Message-ID: for vendors who we were not getting the goods from, I've found calling your sales rep much more efficient than anything you can say/ask/beg/threaten the tech on the phone. Sales guys have the inside numbers to call, the clout to get things moving as they generate revenue for said vendor. his pay comes from you, you pay him, he works for 2. -g On Jan 10, 2011, at 4:14 PM, Thomas Donnelly wrote: > > On Mon, 10 Jan 2011 14:39:19 -0600, Brandon Kim > wrote: > >> >> >> to which they would try and play the "well most people don't mix gear".. >> >> >> >> ha! Funny if you responded with, "Oh really? Thanks I didn't know that, >> I guess I'll get all HP...who do I talk to, to return this Cisco router?" > > I've threatened that one against Juniper and minutes later I had an > engineer on the phone. At 3:30am. Funny how once you mention buying > another vendor they raise an eyebrow. > >> >> >> >> >> >>> From: Greg.Whynott at oicr.on.ca >>> To: brandon.kim at brandontek.com >>> CC: khomyakov.andrey at gmail.com; nanog at nanog.org >>> Date: Mon, 10 Jan 2011 15:20:06 -0500 >>> Subject: Re: Is Cisco equpiment de facto for you? >>> >>> just a side note, HP probably was the most helpful vendor i've dealt >>> with in relation to solving/providing inter vendor interoperability >>> solutions. they have PDF booklets on many things we would run into >>> during work. for example, setting up STP between Cisco and HP gear, >>> ( >>> http://cdn.procurve..com/training/Manuals/ProCurve-and-Cisco-STP-Interoperability.pdf >>> ). >>> >>> At the time the other vendor in this case (cisco) flat our refused to >>> help us. this was a few years back tho, things may of changed. I'd >>> ask support "you are not telling me i'm the _only_ customer trying to >>> do this" ? to which they would try and play the "well most people >>> don't mix gear".. >>> >>> HP's example should be the yard stick in the field. >>> >>> -g >>> >>> >>> >>> On Jan 10, 2011, at 3:04 PM, Brandon Kim wrote: >>> >>>> >>>> To your point Andrey, >>>> >>>> It probably works both ways too. I'm sure HP would love to finger >>> point as well. I remember reading for my CCNP one >>>> of the thought process behind getting all Cisco is the very reason >>> you pointed out, get all Cisco! >>>> >>>> How convenient though for Cisco to do that, I wonder if they are >>> being sincere(sarcasm). >>>> >>>> Wouldn't it a perfect world for Cisco to just have everyone buy their >>> stuff...I think it's a cop out though and you really should >>>> try to support your product as best you can if it is connected to >>> another vendor. >>>> >>>> I'm sad to hear that TACACS took that route. I hope they at least >>> tried their hardest to support you..... >>>> >>>> >>>> >>>>> From: khomyakov.andrey at gmail.com >>>>> Date: Mon, 10 Jan 2011 14:35:36 -0500 >>>>> Subject: Re: Is Cisco equpiment de facto for you? >>>>> To: nanog at nanog.org >>>>> >>>>> There have been awfully too many time when Cisco TAC would just say >>> that >>>>> since the problem you are trying to troubleshoot is between Cisco and >>>>> VendorX, we can't help you. You should have bought Cisco for both >>> sides. >>>>> I had that happen when I was troubleshooting LLDP between 3750s and >>> Avaya >>>>> phones, TACACS between Cisco and tac_plus daemon, link bundling >>> between >>>>> juniper EX and Cisco, some obscure switching issues between CAT and >>>>> Procurves and other examples like that just don't recall them >>> anymore. >>>>> >>>>> Every time I'm reminded that if you have a lot of Cisco on the >>> network, the >>>>> rest should be cisco too, unless there is a very good >>> technical/financial >>>>> reason for it, but you should be prepared to be your own help in >>> those >>>>> cases. >>>>> >>>>> Vendors love to point at the other vendors for solutions. At least >>> in my >>>>> experience. >>>>> >>>>> My $0.02 >>>>> >>>>> Andrey >>>>> >>>>> On Mon, Jan 10, 2011 at 11:52 AM, Greg Whynott >>> wrote: >>>>> >>>>>> I've tried to use other vendors threw out the years for internal >>> L2/L3. >>>>>> Always Cisco for perimeter routing/firewalling. >>>>>> >>>>>> from my personal experience, each time we took a chance and tried >>> to use >>>>>> another vendor for internal L2 needs, we would be reminded why it >>> was a bad >>>>>> choice down the road, due to hardware reliability, support issues, >>>>>> multiple and ongoing software bugs, architectural design choices. >>> Then >>>>>> for the next few years I'd regret the decision. This is not to >>> say Cisco >>>>>> gear has been without its issues, but they are much fewer and >>> handled >>>>>> better when stuff hits the fan. >>>>>> >>>>>> the only other vendor at this point in my career I'd fee comfortable >>>>>> deploying for internal enterprise switching, including HPC >>> requirements >>>>>> which is not CIsco branded, would be Force10 or Extreme. it has >>> always >>>>>> been Cisco for edge routing/firewalling, but i wouldn't be opposed >>> to >>>>>> trying Juniper for routing, I know of a few shops who do and they >>> have been >>>>>> pleased thus far. I've little or no experience with many of the >>> other >>>>>> vendors, and I'm sure they have good offerings, but I won't be >>> beta >>>>>> testing their firmwares anymore (one vendor insisted we upgrade our >>> firmware >>>>>> on our core equipment several times in one year?). >>>>>> >>>>>> >>>>>> Cisco isn't a good choice if you don't have the budget for the >>> smart net >>>>>> contracts. They come at a price. a little 5505 with >>> unrestricted license >>>>>> and contract costs over 2k, a 5540 about 40k-70k depending on >>> options, >>>>>> with a yearly renewal of about 15k or more? >>>>>> >>>>>> -g >>>>>> >>>>>> >>>>>> >>>>> -- >>>>> Andrey Khomyakov >>>>> [khomyakov.andrey at gmail.com] >>>> >>> >>> >>> -- >>> >>> This message and any attachments may contain confidential and/or >>> privileged information for the sole use of the intended recipient. Any >>> review or distribution by anyone other than the person for whom it was >>> originally intended is strictly prohibited. If you have received this >>> message in error, please contact the sender and delete all copies. >>> Opinions, conclusions or other information contained in this message >>> may not be that of the organization. >> > > > -- > Using Opera's revolutionary email client: http://www.opera.com/mail/ > -- This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization. From jra at baylink.com Mon Jan 10 15:33:30 2011 From: jra at baylink.com (Jay Ashworth) Date: Mon, 10 Jan 2011 16:33:30 -0500 (EST) Subject: Satellite IP In-Reply-To: <46553.1294692742@localhost> Message-ID: <18554927.984.1294695210090.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Valdis Kletnieks" > > Why the hostility, Valdis? > > As I said several times - it's not hard to be 98% or 99% sure you can make > all your commitments. However, since predicting the future is an inexact > science, > it's really hard to provide a *100% guarantee* that you'll have enough > contended capacity to make all the performance targets even if every > single occasional customer shows up at once. As Jay pointed out in his > follow-up note, his backup strategy is "scramble around and hope another > provider can > come through in time", which is OK if you *know* that's your strategy > and are OK on it. However, blindly going along with "my usual provider > guaranteed 100% availability" is a bad idea. I don't think Kelly is on his first rodeo, and I know I'm not. "scramble around" is a bit pejorative as descriptions for my booking strategy go, but everyone has a cranky day every so often, not least me. :-) And note that I *also* pointed out that carrier statmuxing on the transport is a valid strategy for capacity elasticity, in that particular environment. > Remember, we're coming out of a solar minimum. ;) Are we in fact coming out of it yet? I heard it was getting deeper, and that we were looking at a Dalton, if not another Maunder. Cheers, -- jra From goemon at anime.net Mon Jan 10 15:51:26 2011 From: goemon at anime.net (goemon at anime.net) Date: Mon, 10 Jan 2011 13:51:26 -0800 (PST) Subject: Working abuse contact for lstn.net / limestonenetworks.com? Message-ID: Anyone have a WORKING abuse contact for lstn.net / limestonenetworks.com? I have tried the usual channels (abuse at limestonenetworks.com, phone calls, "live chat") with no results. -Dan From glenn at vinehosting.com Mon Jan 10 15:57:33 2011 From: glenn at vinehosting.com (Glenn Kelley) Date: Mon, 10 Jan 2011 16:57:33 -0500 Subject: NANOG Digest, Vol 36, Issue 61 In-Reply-To: References: Message-ID: I would agree w/ the HP vs. Cisco comment from Greg Whynott Cisco has refused to help without a huge pricetag in the past. We have migrated many of our customers off of Cisco gear to mitigate future issues for exactly this reason. HP is a great partner! If you need a router check out vYatta or pfSense - pfSense for the low end of course. - Both are open - Both have paid support and we are very happy with them. Glenn On Jan 10, 2011, at 4:52 PM, nanog-request at nanog.org wrote: > Send NANOG mailing list submissions to > nanog at nanog.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mailman.nanog.org/mailman/listinfo/nanog > or, via email, send a message with subject or body 'help' to > nanog-request at nanog.org > > You can reach the person managing the list at > nanog-owner at nanog.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of NANOG digest..." > > > Today's Topics: > > 1. RE: Is Cisco equpiment de facto for you? (Brandon Kim) > 2. Re: Is Cisco equpiment de facto for you? (Thomas Donnelly) > 3. Re: Is Cisco equpiment de facto for you? (Greg Whynott) > 4. Re: Satellite IP (Jay Ashworth) > 5. Working abuse contact for lstn.net / limestonenetworks.com? > (goemon at anime.net) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 10 Jan 2011 15:39:19 -0500 > From: Brandon Kim > Subject: RE: Is Cisco equpiment de facto for you? > To: > Cc: nanog group , khomyakov.andrey at gmail.com > Message-ID: > Content-Type: text/plain; charset="Windows-1252" > > > > to which they would try and play the "well most people don't mix gear".. > > > > ha! Funny if you responded with, "Oh really? Thanks I didn't know that, I guess I'll get all HP...who do I talk to, to return this Cisco router?" > > > > > >> From: Greg.Whynott at oicr.on.ca >> To: brandon.kim at brandontek.com >> CC: khomyakov.andrey at gmail.com; nanog at nanog.org >> Date: Mon, 10 Jan 2011 15:20:06 -0500 >> Subject: Re: Is Cisco equpiment de facto for you? >> >> just a side note, HP probably was the most helpful vendor i've dealt with in relation to solving/providing inter vendor interoperability solutions. they have PDF booklets on many things we would run into during work. for example, setting up STP between Cisco and HP gear, ( http://cdn.procurve..com/training/Manuals/ProCurve-and-Cisco-STP-Interoperability.pdf ). >> >> At the time the other vendor in this case (cisco) flat our refused to help us. this was a few years back tho, things may of changed. I'd ask support "you are not telling me i'm the _only_ customer trying to do this" ? to which they would try and play the "well most people don't mix gear".. >> >> HP's example should be the yard stick in the field. >> >> -g >> >> >> >> On Jan 10, 2011, at 3:04 PM, Brandon Kim wrote: >> >>> >>> To your point Andrey, >>> >>> It probably works both ways too. I'm sure HP would love to finger point as well. I remember reading for my CCNP one >>> of the thought process behind getting all Cisco is the very reason you pointed out, get all Cisco! >>> >>> How convenient though for Cisco to do that, I wonder if they are being sincere(sarcasm). >>> >>> Wouldn't it a perfect world for Cisco to just have everyone buy their stuff...I think it's a cop out though and you really should >>> try to support your product as best you can if it is connected to another vendor. >>> >>> I'm sad to hear that TACACS took that route. I hope they at least tried their hardest to support you..... >>> >>> >>> >>>> From: khomyakov.andrey at gmail.com >>>> Date: Mon, 10 Jan 2011 14:35:36 -0500 >>>> Subject: Re: Is Cisco equpiment de facto for you? >>>> To: nanog at nanog.org >>>> >>>> There have been awfully too many time when Cisco TAC would just say that >>>> since the problem you are trying to troubleshoot is between Cisco and >>>> VendorX, we can't help you. You should have bought Cisco for both sides. >>>> I had that happen when I was troubleshooting LLDP between 3750s and Avaya >>>> phones, TACACS between Cisco and tac_plus daemon, link bundling between >>>> juniper EX and Cisco, some obscure switching issues between CAT and >>>> Procurves and other examples like that just don't recall them anymore. >>>> >>>> Every time I'm reminded that if you have a lot of Cisco on the network, the >>>> rest should be cisco too, unless there is a very good technical/financial >>>> reason for it, but you should be prepared to be your own help in those >>>> cases. >>>> >>>> Vendors love to point at the other vendors for solutions. At least in my >>>> experience. >>>> >>>> My $0.02 >>>> >>>> Andrey >>>> >>>> On Mon, Jan 10, 2011 at 11:52 AM, Greg Whynott wrote: >>>> >>>>> I've tried to use other vendors threw out the years for internal L2/L3. >>>>> Always Cisco for perimeter routing/firewalling. >>>>> >>>>> from my personal experience, each time we took a chance and tried to use >>>>> another vendor for internal L2 needs, we would be reminded why it was a bad >>>>> choice down the road, due to hardware reliability, support issues, >>>>> multiple and ongoing software bugs, architectural design choices. Then >>>>> for the next few years I'd regret the decision. This is not to say Cisco >>>>> gear has been without its issues, but they are much fewer and handled >>>>> better when stuff hits the fan. >>>>> >>>>> the only other vendor at this point in my career I'd fee comfortable >>>>> deploying for internal enterprise switching, including HPC requirements >>>>> which is not CIsco branded, would be Force10 or Extreme. it has always >>>>> been Cisco for edge routing/firewalling, but i wouldn't be opposed to >>>>> trying Juniper for routing, I know of a few shops who do and they have been >>>>> pleased thus far. I've little or no experience with many of the other >>>>> vendors, and I'm sure they have good offerings, but I won't be beta >>>>> testing their firmwares anymore (one vendor insisted we upgrade our firmware >>>>> on our core equipment several times in one year?). >>>>> >>>>> >>>>> Cisco isn't a good choice if you don't have the budget for the smart net >>>>> contracts. They come at a price. a little 5505 with unrestricted license >>>>> and contract costs over 2k, a 5540 about 40k-70k depending on options, >>>>> with a yearly renewal of about 15k or more? >>>>> >>>>> -g >>>>> >>>>> >>>>> >>>> -- >>>> Andrey Khomyakov >>>> [khomyakov.andrey at gmail.com] >>> >> >> >> -- >> >> This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization. > > > ------------------------------ > > Message: 2 > Date: Mon, 10 Jan 2011 15:14:44 -0600 > From: "Thomas Donnelly" > Subject: Re: Is Cisco equpiment de facto for you? > To: nanog at nanog.org > Message-ID: > Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes > > > On Mon, 10 Jan 2011 14:39:19 -0600, Brandon Kim > wrote: > >> >> >> to which they would try and play the "well most people don't mix gear".. >> >> >> >> ha! Funny if you responded with, "Oh really? Thanks I didn't know that, >> I guess I'll get all HP...who do I talk to, to return this Cisco router?" > > I've threatened that one against Juniper and minutes later I had an > engineer on the phone. At 3:30am. Funny how once you mention buying > another vendor they raise an eyebrow. > >> >> >> >> >> >>> From: Greg.Whynott at oicr.on.ca >>> To: brandon.kim at brandontek.com >>> CC: khomyakov.andrey at gmail.com; nanog at nanog.org >>> Date: Mon, 10 Jan 2011 15:20:06 -0500 >>> Subject: Re: Is Cisco equpiment de facto for you? >>> >>> just a side note, HP probably was the most helpful vendor i've dealt >>> with in relation to solving/providing inter vendor interoperability >>> solutions. they have PDF booklets on many things we would run into >>> during work. for example, setting up STP between Cisco and HP gear, >>> ( >>> http://cdn.procurve..com/training/Manuals/ProCurve-and-Cisco-STP-Interoperability.pdf >>> ). >>> >>> At the time the other vendor in this case (cisco) flat our refused to >>> help us. this was a few years back tho, things may of changed. I'd >>> ask support "you are not telling me i'm the _only_ customer trying to >>> do this" ? to which they would try and play the "well most people >>> don't mix gear".. >>> >>> HP's example should be the yard stick in the field. >>> >>> -g >>> >>> >>> >>> On Jan 10, 2011, at 3:04 PM, Brandon Kim wrote: >>> >>>> >>>> To your point Andrey, >>>> >>>> It probably works both ways too. I'm sure HP would love to finger >>> point as well. I remember reading for my CCNP one >>>> of the thought process behind getting all Cisco is the very reason >>> you pointed out, get all Cisco! >>>> >>>> How convenient though for Cisco to do that, I wonder if they are >>> being sincere(sarcasm). >>>> >>>> Wouldn't it a perfect world for Cisco to just have everyone buy their >>> stuff...I think it's a cop out though and you really should >>>> try to support your product as best you can if it is connected to >>> another vendor. >>>> >>>> I'm sad to hear that TACACS took that route. I hope they at least >>> tried their hardest to support you..... >>>> >>>> >>>> >>>>> From: khomyakov.andrey at gmail.com >>>>> Date: Mon, 10 Jan 2011 14:35:36 -0500 >>>>> Subject: Re: Is Cisco equpiment de facto for you? >>>>> To: nanog at nanog.org >>>>> >>>>> There have been awfully too many time when Cisco TAC would just say >>> that >>>>> since the problem you are trying to troubleshoot is between Cisco and >>>>> VendorX, we can't help you. You should have bought Cisco for both >>> sides. >>>>> I had that happen when I was troubleshooting LLDP between 3750s and >>> Avaya >>>>> phones, TACACS between Cisco and tac_plus daemon, link bundling >>> between >>>>> juniper EX and Cisco, some obscure switching issues between CAT and >>>>> Procurves and other examples like that just don't recall them >>> anymore. >>>>> >>>>> Every time I'm reminded that if you have a lot of Cisco on the >>> network, the >>>>> rest should be cisco too, unless there is a very good >>> technical/financial >>>>> reason for it, but you should be prepared to be your own help in >>> those >>>>> cases. >>>>> >>>>> Vendors love to point at the other vendors for solutions. At least >>> in my >>>>> experience. >>>>> >>>>> My $0.02 >>>>> >>>>> Andrey >>>>> >>>>> On Mon, Jan 10, 2011 at 11:52 AM, Greg Whynott >>> wrote: >>>>> >>>>>> I've tried to use other vendors threw out the years for internal >>> L2/L3. >>>>>> Always Cisco for perimeter routing/firewalling. >>>>>> >>>>>> from my personal experience, each time we took a chance and tried >>> to use >>>>>> another vendor for internal L2 needs, we would be reminded why it >>> was a bad >>>>>> choice down the road, due to hardware reliability, support issues, >>>>>> multiple and ongoing software bugs, architectural design choices. >>> Then >>>>>> for the next few years I'd regret the decision. This is not to >>> say Cisco >>>>>> gear has been without its issues, but they are much fewer and >>> handled >>>>>> better when stuff hits the fan. >>>>>> >>>>>> the only other vendor at this point in my career I'd fee comfortable >>>>>> deploying for internal enterprise switching, including HPC >>> requirements >>>>>> which is not CIsco branded, would be Force10 or Extreme. it has >>> always >>>>>> been Cisco for edge routing/firewalling, but i wouldn't be opposed >>> to >>>>>> trying Juniper for routing, I know of a few shops who do and they >>> have been >>>>>> pleased thus far. I've little or no experience with many of the >>> other >>>>>> vendors, and I'm sure they have good offerings, but I won't be >>> beta >>>>>> testing their firmwares anymore (one vendor insisted we upgrade our >>> firmware >>>>>> on our core equipment several times in one year?). >>>>>> >>>>>> >>>>>> Cisco isn't a good choice if you don't have the budget for the >>> smart net >>>>>> contracts. They come at a price. a little 5505 with >>> unrestricted license >>>>>> and contract costs over 2k, a 5540 about 40k-70k depending on >>> options, >>>>>> with a yearly renewal of about 15k or more? >>>>>> >>>>>> -g >>>>>> >>>>>> >>>>>> >>>>> -- >>>>> Andrey Khomyakov >>>>> [khomyakov.andrey at gmail.com] >>>> >>> >>> >>> -- >>> >>> This message and any attachments may contain confidential and/or >>> privileged information for the sole use of the intended recipient. Any >>> review or distribution by anyone other than the person for whom it was >>> originally intended is strictly prohibited. If you have received this >>> message in error, please contact the sender and delete all copies. >>> Opinions, conclusions or other information contained in this message >>> may not be that of the organization. >> > > > -- > Using Opera's revolutionary email client: http://www.opera.com/mail/ > > > > ------------------------------ > > Message: 3 > Date: Mon, 10 Jan 2011 16:30:44 -0500 > From: Greg Whynott > Subject: Re: Is Cisco equpiment de facto for you? > To: Thomas Donnelly > Cc: "nanog at nanog.org" > Message-ID: > Content-Type: text/plain; charset="Windows-1252" > > for vendors who we were not getting the goods from, I've found calling your sales rep much more efficient than anything you can say/ask/beg/threaten the tech on the phone. Sales guys have the inside numbers to call, the clout to get things moving as they generate revenue for said vendor. his pay comes from you, you pay him, he works for 2. > > -g > > > On Jan 10, 2011, at 4:14 PM, Thomas Donnelly wrote: > >> >> On Mon, 10 Jan 2011 14:39:19 -0600, Brandon Kim >> wrote: >> >>> >>> >>> to which they would try and play the "well most people don't mix gear".. >>> >>> >>> >>> ha! Funny if you responded with, "Oh really? Thanks I didn't know that, >>> I guess I'll get all HP...who do I talk to, to return this Cisco router?" >> >> I've threatened that one against Juniper and minutes later I had an >> engineer on the phone. At 3:30am. Funny how once you mention buying >> another vendor they raise an eyebrow. >> >>> >>> >>> >>> >>> >>>> From: Greg.Whynott at oicr.on.ca >>>> To: brandon.kim at brandontek.com >>>> CC: khomyakov.andrey at gmail.com; nanog at nanog.org >>>> Date: Mon, 10 Jan 2011 15:20:06 -0500 >>>> Subject: Re: Is Cisco equpiment de facto for you? >>>> >>>> just a side note, HP probably was the most helpful vendor i've dealt >>>> with in relation to solving/providing inter vendor interoperability >>>> solutions. they have PDF booklets on many things we would run into >>>> during work. for example, setting up STP between Cisco and HP gear, >>>> ( >>>> http://cdn.procurve..com/training/Manuals/ProCurve-and-Cisco-STP-Interoperability.pdf >>>> ). >>>> >>>> At the time the other vendor in this case (cisco) flat our refused to >>>> help us. this was a few years back tho, things may of changed. I'd >>>> ask support "you are not telling me i'm the _only_ customer trying to >>>> do this" ? to which they would try and play the "well most people >>>> don't mix gear".. >>>> >>>> HP's example should be the yard stick in the field. >>>> >>>> -g >>>> >>>> >>>> >>>> On Jan 10, 2011, at 3:04 PM, Brandon Kim wrote: >>>> >>>>> >>>>> To your point Andrey, >>>>> >>>>> It probably works both ways too. I'm sure HP would love to finger >>>> point as well. I remember reading for my CCNP one >>>>> of the thought process behind getting all Cisco is the very reason >>>> you pointed out, get all Cisco! >>>>> >>>>> How convenient though for Cisco to do that, I wonder if they are >>>> being sincere(sarcasm). >>>>> >>>>> Wouldn't it a perfect world for Cisco to just have everyone buy their >>>> stuff...I think it's a cop out though and you really should >>>>> try to support your product as best you can if it is connected to >>>> another vendor. >>>>> >>>>> I'm sad to hear that TACACS took that route. I hope they at least >>>> tried their hardest to support you..... >>>>> >>>>> >>>>> >>>>>> From: khomyakov.andrey at gmail.com >>>>>> Date: Mon, 10 Jan 2011 14:35:36 -0500 >>>>>> Subject: Re: Is Cisco equpiment de facto for you? >>>>>> To: nanog at nanog.org >>>>>> >>>>>> There have been awfully too many time when Cisco TAC would just say >>>> that >>>>>> since the problem you are trying to troubleshoot is between Cisco and >>>>>> VendorX, we can't help you. You should have bought Cisco for both >>>> sides. >>>>>> I had that happen when I was troubleshooting LLDP between 3750s and >>>> Avaya >>>>>> phones, TACACS between Cisco and tac_plus daemon, link bundling >>>> between >>>>>> juniper EX and Cisco, some obscure switching issues between CAT and >>>>>> Procurves and other examples like that just don't recall them >>>> anymore. >>>>>> >>>>>> Every time I'm reminded that if you have a lot of Cisco on the >>>> network, the >>>>>> rest should be cisco too, unless there is a very good >>>> technical/financial >>>>>> reason for it, but you should be prepared to be your own help in >>>> those >>>>>> cases. >>>>>> >>>>>> Vendors love to point at the other vendors for solutions. At least >>>> in my >>>>>> experience. >>>>>> >>>>>> My $0.02 >>>>>> >>>>>> Andrey >>>>>> >>>>>> On Mon, Jan 10, 2011 at 11:52 AM, Greg Whynott >>>> wrote: >>>>>> >>>>>>> I've tried to use other vendors threw out the years for internal >>>> L2/L3. >>>>>>> Always Cisco for perimeter routing/firewalling. >>>>>>> >>>>>>> from my personal experience, each time we took a chance and tried >>>> to use >>>>>>> another vendor for internal L2 needs, we would be reminded why it >>>> was a bad >>>>>>> choice down the road, due to hardware reliability, support issues, >>>>>>> multiple and ongoing software bugs, architectural design choices. >>>> Then >>>>>>> for the next few years I'd regret the decision. This is not to >>>> say Cisco >>>>>>> gear has been without its issues, but they are much fewer and >>>> handled >>>>>>> better when stuff hits the fan. >>>>>>> >>>>>>> the only other vendor at this point in my career I'd fee comfortable >>>>>>> deploying for internal enterprise switching, including HPC >>>> requirements >>>>>>> which is not CIsco branded, would be Force10 or Extreme. it has >>>> always >>>>>>> been Cisco for edge routing/firewalling, but i wouldn't be opposed >>>> to >>>>>>> trying Juniper for routing, I know of a few shops who do and they >>>> have been >>>>>>> pleased thus far. I've little or no experience with many of the >>>> other >>>>>>> vendors, and I'm sure they have good offerings, but I won't be >>>> beta >>>>>>> testing their firmwares anymore (one vendor insisted we upgrade our >>>> firmware >>>>>>> on our core equipment several times in one year?). >>>>>>> >>>>>>> >>>>>>> Cisco isn't a good choice if you don't have the budget for the >>>> smart net >>>>>>> contracts. They come at a price. a little 5505 with >>>> unrestricted license >>>>>>> and contract costs over 2k, a 5540 about 40k-70k depending on >>>> options, >>>>>>> with a yearly renewal of about 15k or more? >>>>>>> >>>>>>> -g >>>>>>> >>>>>>> >>>>>>> >>>>>> -- >>>>>> Andrey Khomyakov >>>>>> [khomyakov.andrey at gmail.com] >>>>> >>>> >>>> >>>> -- >>>> >>>> This message and any attachments may contain confidential and/or >>>> privileged information for the sole use of the intended recipient. Any >>>> review or distribution by anyone other than the person for whom it was >>>> originally intended is strictly prohibited. If you have received this >>>> message in error, please contact the sender and delete all copies. >>>> Opinions, conclusions or other information contained in this message >>>> may not be that of the organization. >>> >> >> >> -- >> Using Opera's revolutionary email client: http://www.opera.com/mail/ >> > > > -- > > This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization. > > > > ------------------------------ > > Message: 4 > Date: Mon, 10 Jan 2011 16:33:30 -0500 (EST) > From: Jay Ashworth > Subject: Re: Satellite IP > To: NANOG > Message-ID: > <18554927.984.1294695210090.JavaMail.root at benjamin.baylink.com> > Content-Type: text/plain; charset=utf-8 > > ----- Original Message ----- >> From: "Valdis Kletnieks" > >>> Why the hostility, Valdis? >> >> As I said several times - it's not hard to be 98% or 99% sure you can make >> all your commitments. However, since predicting the future is an inexact >> science, >> it's really hard to provide a *100% guarantee* that you'll have enough >> contended capacity to make all the performance targets even if every >> single occasional customer shows up at once. As Jay pointed out in his >> follow-up note, his backup strategy is "scramble around and hope another >> provider can >> come through in time", which is OK if you *know* that's your strategy >> and are OK on it. However, blindly going along with "my usual provider >> guaranteed 100% availability" is a bad idea. > > I don't think Kelly is on his first rodeo, and I know I'm not. > > "scramble around" is a bit pejorative as descriptions for my booking > strategy go, but everyone has a cranky day every so often, not least me. > > :-) > > And note that I *also* pointed out that carrier statmuxing on the > transport is a valid strategy for capacity elasticity, in that particular > environment. > >> Remember, we're coming out of a solar minimum. ;) > > Are we in fact coming out of it yet? I heard it was getting deeper, > and that we were looking at a Dalton, if not another Maunder. > > Cheers, > -- jra > > > > ------------------------------ > > Message: 5 > Date: Mon, 10 Jan 2011 13:51:26 -0800 (PST) > From: goemon at anime.net > Subject: Working abuse contact for lstn.net / limestonenetworks.com? > To: "'nanog at merit.edu'" > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > Anyone have a WORKING abuse contact for lstn.net / limestonenetworks.com? > > I have tried the usual channels (abuse at limestonenetworks.com, phone calls, "live chat") with no results. > > -Dan > > > > ------------------------------ > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > https://mailman.nanog.org/mailman/listinfo/nanog > > End of NANOG Digest, Vol 36, Issue 61 > ************************************* -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part URL: From alh-ietf at tndh.net Mon Jan 10 16:02:14 2011 From: alh-ietf at tndh.net (Tony Hain) Date: Mon, 10 Jan 2011 14:02:14 -0800 Subject: IPv6 - real vs theoretical problems In-Reply-To: <4D2B6A81.7000002@nasa.gov> References: <085301cbb0ff$2dbb74c0$89325e40$@net> <4D2B6A81.7000002@nasa.gov> Message-ID: <08c401cbb112$13ea7010$3bbf5030$@net> *requested anonymous* wrote: > (I don't post on public mailing lists, so, please consider this > private. > That is, I don't care if the question/reply are public, just, not the > source.) > > On 1/10/11 11:46 AM, Tony Hain wrote: > > ... yes I know you understand operational issues. > > > > While managed networks can 'reverse the damage', there is no way to > fix that > > for consumer unmanaged networks. Whatever gets deployed now, that is > what > > the routers will be built to deal with, and it will be virtually > impossible > > to change it due to the 'installed base' and lack of knowledgeable > > management. > > > > It is hard enough getting the product teams to accept that it is > possible to > > build a self-configuring home network without having that be crippled > by > > braindead conservation. The worst possible value I can see for > delegation to > > the home is /56, yet that is the most popular value because people > have > ^^^^^^^^^^^^^^^^^ > Why would you say /56 is the worst possible value? Just curious -- I am actually trying to develop a simple set of 'auto conf' rules for all the CPE vendors to build against, and for a Joe-sixpack plug-n-play network configuration a /56 means there is only one topology option beyond single subnet. > my provider doesn't offer IPv6 yet, but, I think they will soon. > I was going to ask for a /56 for my home net. If I ever get around > to using them to set up a domain for my wife's business, I will ask > for a /48, but, for a house without a private domain, /56 seems > perfect. You are thinking of a managed network. Connect a random graph of boxes, then figure out a subnet scheme that all cpe vendors can implement that will correctly deal with prefix delegation and hierarchical routing. > I don't expect to run out in my lifetime, or even my children's > or grandchildren's lifetimes if somehow the house stays in the family > ;-) > How many subnets will they really need, no matter if every lightbulb > is on the net? Wrong question. In a managed network that would be the right question, but in an unmanaged one the right question is how many sub-delegations and how many branches per sub-delegate are going to be automatically figured out. > > My frame of reference is that while we need to make the addresses big > enough, we also need to preserve the hierarchy. There is no shortage > of addresses, nor will there be, ever, but there could be a shortage > of levels in the hierarchy. I assume you would like a home to have a > /48? But, from my provider's /32, that is only 4 levels at the > assumed nibble boundary. I think my provider could use another > two levels. If your provide has more than 10,000 customers they should never have gotten a /32. The braindead notion that everyone needed to rush out and get a /32 has not helped get IPv6 deployed. The /32 value was the default one for a startup provider. Every provider with a customer base should have done a plan for a /48 per customer, then gotten the right size block to start with. Any provider with a /32 and more than 10k customers needs to do that now and swap for 'a real block', instead of trying to squeeze their customers into a tiny block due to their insufficient initial request. > > I also think ~256 subnets has stood the test of time -- seldom in > the last 25 years has a geographically contiguous enterprise network > (such as a university or company) required more than 256 subnets -- > except for cisco, microsoft, et al., but not, e.g. most colleges, > universities, research centers, etc. More addresses, sure, but, > not usually more than 256 subnets. So, even in a world where > every possible device has its own set of addresses -- how many > subnets will I really need? Again, wrong question. Most of the possible subnets in a Joe-sixpack configuration will be 'wasted'. So what? That space will be wasted sitting on the shelf at IANA in 500 years when someone comes up with a better idea. IPv6 is not the last protocol known to mankind (unless the 2012 predictions are true), so most of its potential space will be wasted. Get over that point and accept that innovation requires thinking differently than the limited myopia of the past. > > Also from my frame of reference -- we need to work on making addressing > and re-addressing easier and more automatic for consumers anyway, so, > if /56 is not enough, we can easily and painlessly switch to a /52 > with no problems. Easy in a managed network where it is possible to update code and expect that things will happen in a timeframe that makes development worth the effort. Impossible in consumer land where it is well documented that things are never updated, and all vendors need to play by the same simple rules because there is no hope that the consumer will know how to tweak them. > And, if I decide to grow an enterprise from home, > I feel that I should be able to re-address as needed over the course > of time anyway, so, I would rather make re-addressing easier than > put all my eggs in the large-enough-/48 basket. What if I grow so > large that I buy someone else's company, or otherwise merge? We have > to solve the re-addressing problem anyway, in which case, /48, /52, /56 > assignments should not be a big deal. > > What am I missing? You are thinking like every other network engineer on Nanog, not like a consumer that doesn?t understand why some configurations are not possible. The only way to avoid support calls is to make it trivial for the devices to deal with just about anything that a consumer might do, and it has to be scalable enough over time to deal with the fact that a device from today will still be in use 10-15 years from now. Evolution of the rules is possible over very long timeframes, but more complex and costly. Starting with a short-sighted, managed network viewpoint is a guarantee that it will be impossible to innovate in the unmanaged home network space. Tony From marka at isc.org Mon Jan 10 16:04:34 2011 From: marka at isc.org (Mark Andrews) Date: Tue, 11 Jan 2011 09:04:34 +1100 Subject: Problems with removing NAT from a network In-Reply-To: Your message of "Mon, 10 Jan 2011 11:18:29 -0800." <4D2B5B85.2040106@matthew.at> References: <4D252B1F.8030506@kenweb.org> <3DFD6833-78C1-43D2-8074-6C89CFE3F2F3@arbor.net> <20110106043110.21C96876D21@drugs.dv.isc.org> <4D254ED8.6030006@matthew.at> <4D25F971.4090709@matthew.at> <4D2634E7.2060502@matthew.at> <9DEED87C-ED15-4D05-BCD6-69A5D4A69681@delong.com> <4D267B9E.8040602@bogus.com> <4D268119.2050205@matthew.at> <4D284798.3010806@consolejunkie.net> <4D2959D7.7040407@matthew.at> <50F0FF27-DE27-40BC-AB71-0B9EBCD7D0E3@delong.com> <4D2B5B85.2040106@matthew.at> Message-ID: <20110110220434.6C48F89E344@drugs.dv.isc.org> One can still do DS-lite when the provider only offers NAT64. A B4 can connect to a AFTR which can be anywhere that is reachable via IPv6. I can see small ISPs and those that can't get IPv4 addresses for themselves out sourcing the DS-lite service. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jeff-kell at utc.edu Mon Jan 10 16:32:16 2011 From: jeff-kell at utc.edu (Jeff Kell) Date: Mon, 10 Jan 2011 17:32:16 -0500 Subject: Is Cisco equpiment de facto for you? In-Reply-To: References: <1177151411.1544.1294676497222.JavaMail.root@zimbra.network1.net>, , Message-ID: <4D2B88F0.7090507@utc.edu> On 1/10/2011 3:20 PM, Greg Whynott wrote: > HP probably was the most helpful vendor i've dealt with in relation to solving/providing inter vendor interoperability solutions. they have PDF booklets on many things we would run into during work. for example, setting up STP between Cisco and HP gear, ( http://cdn.procurve.com/training/Manuals/ProCurve-and-Cisco-STP-Interoperability.pdf ). Well, technically, the HP reference tells you how to convert your Cisco default PVST over to MST to match the HP preference. The handful of HP switches versus the stacks and stacks of production Cisco requiring conversion to suit them was "intimidating" to say the least :-) Foundry/Brocade on the other hand do PVST (so they say, I haven't given it a thorough lab test). Jeff From Greg.Whynott at oicr.on.ca Mon Jan 10 16:42:35 2011 From: Greg.Whynott at oicr.on.ca (Greg Whynott) Date: Mon, 10 Jan 2011 17:42:35 -0500 Subject: Is Cisco equpiment de facto for you? In-Reply-To: <4D2B88F0.7090507@utc.edu> References: <1177151411.1544.1294676497222.JavaMail.root@zimbra.network1.net>, , <4D2B88F0.7090507@utc.edu> Message-ID: <1A3FC47C-54A6-478F-8A19-E9FAC4C5F437@oicr.on.ca> just to play devils advocate.. PVST is Cisco propriety. I'd rather see vendors default to an open standard as opposed to something which is closed. the lowest common denominator? in my eyes the document tells you how to make a cisco and hp switch work together, not convert. numbers alone do not denote intelligence, if so cockroaches would rule the world. 8) -g On Jan 10, 2011, at 5:32 PM, Jeff Kell wrote: > On 1/10/2011 3:20 PM, Greg Whynott wrote: >> HP probably was the most helpful vendor i've dealt with in relation to solving/providing inter vendor interoperability solutions. they have PDF booklets on many things we would run into during work. for example, setting up STP between Cisco and HP gear, ( http://cdn.procurve.com/training/Manuals/ProCurve-and-Cisco-STP-Interoperability.pdf ). > > Well, technically, the HP reference tells you how to convert your Cisco > default PVST over to MST to match the HP preference. > > The handful of HP switches versus the stacks and stacks of production > Cisco requiring conversion to suit them was "intimidating" to say the > least :-) > > Foundry/Brocade on the other hand do PVST (so they say, I haven't given > it a thorough lab test). > > Jeff -- This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization. From sethm at rollernet.us Mon Jan 10 16:46:53 2011 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 10 Jan 2011 14:46:53 -0800 Subject: Is Cisco equpiment de facto for you? In-Reply-To: <4D2B88F0.7090507@utc.edu> References: <1177151411.1544.1294676497222.JavaMail.root@zimbra.network1.net>, , <4D2B88F0.7090507@utc.edu> Message-ID: <4D2B8C5D.20601@rollernet.us> On 1/10/2011 14:32, Jeff Kell wrote: > On 1/10/2011 3:20 PM, Greg Whynott wrote: >> HP probably was the most helpful vendor i've dealt with in relation to solving/providing inter vendor interoperability solutions. they have PDF booklets on many things we would run into during work. for example, setting up STP between Cisco and HP gear, ( http://cdn.procurve.com/training/Manuals/ProCurve-and-Cisco-STP-Interoperability.pdf ). > > Well, technically, the HP reference tells you how to convert your Cisco > default PVST over to MST to match the HP preference. > > The handful of HP switches versus the stacks and stacks of production > Cisco requiring conversion to suit them was "intimidating" to say the > least :-) > To be fair, one is Cisco proprietary while the other is IEEE 802.1Q. ~Seth From jsw at inconcepts.biz Mon Jan 10 16:54:03 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Mon, 10 Jan 2011 17:54:03 -0500 Subject: AltDB? (IRR support & direction at ARIN) In-Reply-To: References: <4D2A8452.4070900@knownelement.com> Message-ID: On Mon, Jan 10, 2011 at 12:37 PM, Jon Lewis wrote: > On Sun, 9 Jan 2011, Charles N Wyble wrote: > >>> I am simply suggesting it is dangerous and irresponsible to run an IRR >>> with only MAIL-FROM authentication, and quite easy to also support >>> CRYPT-PW. ?ARIN should either support passwords or immediately make > > The trouble is, since the DES crypt passwords are publicly accessible, even > CRYPT-PW is not much security. ?I suspect with a copy of the db, a passsword > cracking program, and some modest computing capacity, you could crack all DES crypt() is not completely trivial yet, but I agree, it is far from state-of-the-art. It is substantially superior to MAIL-FROM. In addition, MERIT reduced this problem by simply filtering out the hashes from the RADB.db file and whois output (and presumably also, the www.radb.net tools.) -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From brandon.kim at brandontek.com Mon Jan 10 16:54:33 2011 From: brandon.kim at brandontek.com (Brandon Kim) Date: Mon, 10 Jan 2011 17:54:33 -0500 Subject: Is Cisco equpiment de facto for you? In-Reply-To: <4D2B8C5D.20601@rollernet.us> References: <1177151411.1544.1294676497222.JavaMail.root@zimbra.network1.net>, , , , , <4D2B88F0.7090507@utc.edu>, <4D2B8C5D.20601@rollernet.us> Message-ID: To be fair to Cisco and maybe I'm way off here. But it seems they do come out with a way to do things first which then become a standard that they have to follow. ISL/DOT1Q HSRP/VRRP etherchannel/LACP Just some examples..... I'm not aware of too many other vendors that create their own protocol, in which they then become a standard? > Date: Mon, 10 Jan 2011 14:46:53 -0800 > From: sethm at rollernet.us > To: nanog at nanog.org > Subject: Re: Is Cisco equpiment de facto for you? > > On 1/10/2011 14:32, Jeff Kell wrote: > > On 1/10/2011 3:20 PM, Greg Whynott wrote: > >> HP probably was the most helpful vendor i've dealt with in relation to solving/providing inter vendor interoperability solutions. they have PDF booklets on many things we would run into during work. for example, setting up STP between Cisco and HP gear, ( http://cdn.procurve.com/training/Manuals/ProCurve-and-Cisco-STP-Interoperability.pdf ). > > > > Well, technically, the HP reference tells you how to convert your Cisco > > default PVST over to MST to match the HP preference. > > > > The handful of HP switches versus the stacks and stacks of production > > Cisco requiring conversion to suit them was "intimidating" to say the > > least :-) > > > > > To be fair, one is Cisco proprietary while the other is IEEE 802.1Q. > > ~Seth > From owen at delong.com Mon Jan 10 17:04:23 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 10 Jan 2011 15:04:23 -0800 Subject: NIST IPv6 document In-Reply-To: References: <20110105043548.BC01B1CC3E@ptavv.es.net> <4661ED7E-A4DA-4CD4-A7EB-C5B2E615F126@delong.com> <86zkreb486.fsf@seastrom.com> <0B19C108-2B18-43E5-A4CF-9AFD421F4206@ecs.soton.ac.uk> Message-ID: On Jan 10, 2011, at 5:56 AM, Tim Chown wrote: > > On 7 Jan 2011, at 15:12, Justin M. Streiner wrote: > >> On Thu, 6 Jan 2011, Jeff Wheeler wrote: >> >>> On Thu, Jan 6, 2011 at 8:47 PM, Owen DeLong wrote: >>>> 1. Block packets destined for your point-to-point links at your >>>> borders. There's no legitimate reason someone should be >>> >>> Most networks do not do this today. Whether or not that is wise is >>> questionable, but I don't think those networks want NDP to be the >>> reason they choose to make this change. >> >> Correct me if I'm wrong, but wouldn't blocking all traffic destined for your infrastructure at the borders also play havoc with PTMUD? Limiting the traffic allowed to just the necessary types would seem like a reasonable alternative. > > Recommendations for PTMUD-friendly filtering are described in RFC 4890. > > Tim Unless my point-to-point links are originating packets to the outside world (they should not be, in general), then I should not expect any PMTU-D responses directed at them. As such, blocking even those packets TO my point-to-point interfaces should not be problematic. Owen From owen at delong.com Mon Jan 10 17:13:30 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 10 Jan 2011 15:13:30 -0800 Subject: arin and ops fora (was Re: AltDB?) In-Reply-To: <4D2B24F9.9000507@brightok.net> References: <59051.1294464800@nsa.vix.com> <00041A16-473F-4F96-93E8-E3CD3F83E1B2@virtualized.org> <70374.1294475040@nsa.vix.com> <4D2B24F9.9000507@brightok.net> Message-ID: <4CB1420A-386C-4017-8011-ABC0C2F376EA@delong.com> On Jan 10, 2011, at 7:25 AM, Jack Bates wrote: > On 1/9/2011 5:27 PM, John Curran wrote: >> Excellent question. To the extent that it is best practices on these types of >> services, then that's relatively easy for ARIN to interface with... if it is >> specific direction to ARIN to "do xyz", then ultimately the decision rests with >> the ARIN Board regarding that input, since that involves how we spend the service >> fees of the members. >> > > Which ARIN membership does have some resources on, though I do believe they could be improved, as most membership input deals more with the NRPM and not with auxiliary services. > Members may bring any topic of interest to arin-discuss. The fact that there is more traffic on ppml dealing with the NRPM than there is on arin-discuss dealing with other issues is a matter of where the members choose to focus their attention more than anything else. >> The role is served by the ARIN Board, which is member-elected and composed of >> volunteers (and myself as CEO). If folks think that a more formal structure >> for operational input (either within ARIN or via liaison to another body) is >> called for, I'd suggest continued discussion on the various mailing lists. >> > > It's always a stickler, too. PPML works well for NRPM, but ARIN doesn't have enough auxiliary services to warrant a mailing list dealing with them. It becomes more of a suggestion, proposal, feedback, implementation, more feedback process. ARIN is generally good at notification of implementation concerning new services, though it would be nice if they had better channels for feedback through the entire process of new services so that they could be closer in sync with the membership. I don't believe services should reach the PDP level, but better communication wouldn't hurt, especially with members who generally don't know how or realize they can participate. > PPML is a forum for the community (not just ARIN members, the entire community). There is a separate mailing list... arin-discuss which is for members of ARIN to discuss any ARIN-related topic of interest to the membership. They can and sometimes do discuss operational matters there. Additionally, there is the ACSP which allows members or the community to send comments and suggestions to ARIN regarding anything, including operations, etc. The ACSP provides a process for community review of the suggestions and semi-formal comment processes as well. Everything you are asking for in your last paragraph is available. Perhaps what is needed is better education of the membership and community on what tools are available and how to use them. Were you familiar with arin-discuss prior to this message? If so, in what way does it not meet the need you are describing? I'm not trying to pick on you Jack. I'm really trying to identify if what we have here is an issue of needing better tools, or, if all we need is better education and utilization of the tools that are already in place, or, some combination of both. Thanks, Owen From sethm at rollernet.us Mon Jan 10 17:20:19 2011 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 10 Jan 2011 15:20:19 -0800 Subject: Is Cisco equpiment de facto for you? In-Reply-To: References: <1177151411.1544.1294676497222.JavaMail.root@zimbra.network1.net>, , , , , <4D2B88F0.7090507@utc.edu>, <4D2B8C5D.20601@rollernet.us> Message-ID: <4D2B9433.4020509@rollernet.us> On 1/10/2011 14:54, Brandon Kim wrote: > > To be fair to Cisco and maybe I'm way off here. But it seems they do come out with a way to do things first which then become a standard that > they have to follow. > > ISL/DOT1Q > HSRP/VRRP > etherchannel/LACP > > Just some examples..... I'm not aware of too many other vendors that create their own protocol, in which they then become a standard? > > All I found (quickly without trying too hard) is that the IEEE version is based on Cisco's MISTP rather than PVST. ~Seth From jbates at brightok.net Mon Jan 10 17:28:34 2011 From: jbates at brightok.net (Jack Bates) Date: Mon, 10 Jan 2011 17:28:34 -0600 Subject: arin and ops fora (was Re: AltDB?) In-Reply-To: <4CB1420A-386C-4017-8011-ABC0C2F376EA@delong.com> References: <59051.1294464800@nsa.vix.com> <00041A16-473F-4F96-93E8-E3CD3F83E1B2@virtualized.org> <70374.1294475040@nsa.vix.com> <4D2B24F9.9000507@brightok.net> <4CB1420A-386C-4017-8011-ABC0C2F376EA@delong.com> Message-ID: <4D2B9622.6060706@brightok.net> On 1/10/2011 5:13 PM, Owen DeLong wrote: > > Members may bring any topic of interest to arin-discuss. The fact that there is more > traffic on ppml dealing with the NRPM than there is on arin-discuss dealing with other > issues is a matter of where the members choose to focus their attention more than > anything else. > Would that be the list I've tried to subscribe to multiple times, get an autoresponder that it has to be approved, and then never hear a word? > PPML is a forum for the community (not just ARIN members, the entire > community). Good to know. I was under the impression that it was member only. > There is a separate mailing list... arin-discuss which is for members of ARIN to discuss > any ARIN-related topic of interest to the membership. They can and sometimes do > discuss operational matters there. > Except it's listed as no input from ARIN itself? > Everything you are asking for in your last paragraph is available. Perhaps what is needed > is better education of the membership and community on what tools are available and how > to use them. Were you familiar with arin-discuss prior to this message? If so, in what way > does it not meet the need you are describing? > I can't get subscribed, so, :P I also haven't seen on the website pointers for where different tools and resources fall into for community review, comment, suggestion, etc. Perhaps it's just my website navigation skills. However, as I said previously, I have no serious complaints. It's not like the AC and CEO aren't publicly visible and vocal. Jack From Valdis.Kletnieks at vt.edu Mon Jan 10 17:30:01 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 10 Jan 2011 18:30:01 -0500 Subject: Satellite IP In-Reply-To: Your message of "Mon, 10 Jan 2011 16:33:30 EST." <18554927.984.1294695210090.JavaMail.root@benjamin.baylink.com> References: <18554927.984.1294695210090.JavaMail.root@benjamin.baylink.com> Message-ID: <7748.1294702201@localhost> On Mon, 10 Jan 2011 16:33:30 EST, Jay Ashworth said: > > From: "Valdis Kletnieks" > > Remember, we're coming out of a solar minimum. ;) > > Are we in fact coming out of it yet? I heard it was getting deeper, > and that we were looking at a Dalton, if not another Maunder. Hmm.. guess Sunspots 1112 and 1123 were a false alarm? :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jbates at brightok.net Mon Jan 10 17:44:42 2011 From: jbates at brightok.net (Jack Bates) Date: Mon, 10 Jan 2011 17:44:42 -0600 Subject: NIST IPv6 document In-Reply-To: References: <20110105043548.BC01B1CC3E@ptavv.es.net> <4661ED7E-A4DA-4CD4-A7EB-C5B2E615F126@delong.com> <86zkreb486.fsf@seastrom.com> <0B19C108-2B18-43E5-A4CF-9AFD421F4206@ecs.soton.ac.uk> Message-ID: <4D2B99EA.90302@brightok.net> On 1/10/2011 5:04 PM, Owen DeLong wrote: > > Unless my point-to-point links are originating packets to the outside world > (they should not be, in general), then I should not expect any PMTU-D > responses directed at them. > > As such, blocking even those packets TO my point-to-point interfaces > should not be problematic. > Unless the router responds to traceroutes with it's loopback, I'd expect ping traffic to p2p addresses. I'd also expect to see customer traceroutes originating from the p2p address (useful in troubleshooting as it uses an address outside the customer's BGP addresses. Jack From john-nanog at johnpeach.com Mon Jan 10 17:45:01 2011 From: john-nanog at johnpeach.com (John Peach) Date: Mon, 10 Jan 2011 18:45:01 -0500 Subject: Working abuse contact for lstn.net / limestonenetworks.com? In-Reply-To: References: Message-ID: <20110110184501.3c51706d@godzilla> Waste of time; I don't accept email from them, it's all spam. On Mon, 10 Jan 2011 13:51:26 -0800 (PST) goemon at anime.net wrote: > Anyone have a WORKING abuse contact for lstn.net / limestonenetworks.com? > > I have tried the usual channels (abuse at limestonenetworks.com, phone calls, "live chat") with no results. > > -Dan > From owen at delong.com Mon Jan 10 17:50:55 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 10 Jan 2011 15:50:55 -0800 Subject: Is Cisco equpiment de facto for you? In-Reply-To: References: <1177151411.1544.1294676497222.JavaMail.root@zimbra.network1.net> Message-ID: On Jan 10, 2011, at 11:35 AM, Andrey Khomyakov wrote: > There have been awfully too many time when Cisco TAC would just say that > since the problem you are trying to troubleshoot is between Cisco and > VendorX, we can't help you. You should have bought Cisco for both sides. > I had that happen when I was troubleshooting LLDP between 3750s and Avaya > phones, TACACS between Cisco and tac_plus daemon, link bundling between > juniper EX and Cisco, some obscure switching issues between CAT and > Procurves and other examples like that just don't recall them anymore. > This has been my justification in the past for buying Cisco for neither side the next time. I've never had Juniper tell me that until they could show clearly that the misbehaving item was the brand C hardware on the other side. They even went so far as to provide me very detailed analysis of the exact form of misbehavior in the brand C gear and offered to talk to the C-TAC if I could arrange it in order to better communicate the problem. While I'm not sure this is the usual behavior of the J-TAC, I can say that the C-TAC behavior described above is all too common. > Every time I'm reminded that if you have a lot of Cisco on the network, the > rest should be cisco too, unless there is a very good technical/financial > reason for it, but you should be prepared to be your own help in those > cases. > A network-equipment vendor that won't help you resolve interoperability problems with equipment they didn't build (BTW, I've had C-TAC refuse to resolve problems between different business units of C-Gear, too) IS a reason to buy from other vendors, IMHO. > Vendors love to point at the other vendors for solutions. At least in my > experience. > Good vendors don't do that. Vendors that do that don't get my business. Vote with your feet and your $$. My $.0.2. > My $0.02 > > Andrey > Owen From owen at delong.com Mon Jan 10 17:55:15 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 10 Jan 2011 15:55:15 -0800 Subject: NIST IPv6 document In-Reply-To: <201101101452.56885.lowen@pari.edu> References: <201101061429.p06ETB7g096271@aurora.sol.net> <201101101452.56885.lowen@pari.edu> Message-ID: On Jan 10, 2011, at 11:52 AM, Lamar Owen wrote: > On Friday, January 07, 2011 09:25:59 am David Sparro wrote: >> I find that the security "Layers" advocates tend not to look at the >> differing value of each of those layers. > > Different layers very much have different values, and, yes, this is often glossed over. > >> Going back to the physical door analogy, it's like saying that a bank >> vault protected by a bank vault door is less secure than a vault with >> the bank vault door AND a screen door. > > More analogous would be the safe with glass relockers and a vial of tear gas behind the ideal drill point. Yes, those do exist, and, should you want to see a photo of such a vial, I can either provide one (have to take the photo with the safe door open next time I'm on that site, which may be a while with all this snow and ice on the ground) or you can find pics through google. > > Even physical locks have layered security principles. Think Medeco locks with chisel-pointed pins and the associated sidebar in the center, or ASSA's Twin double-stack pin technology, or the use of spool pins in locks, or Schlage's Primus system (also sidebar driven) or anti-drill armor in front of the pin stack (to prevent drilling the shear line), etc. The use of layers in the physical security realm is a proven concept, and the synergy of the layers has been shown effective over time. Not totally secure, of course, but as the number of layers increases the security becomes better and better. Nonetheless, NAT remains an opaque screen door at best. If the bad guy is behind the door, it helps hide him. If the bad guy is outside the door, the time it takes for his knife to cut through it is so small as to be meaningless. Owen From owen at delong.com Mon Jan 10 18:14:29 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 10 Jan 2011 16:14:29 -0800 Subject: IPv6 - real vs theoretical problems In-Reply-To: <08c401cbb112$13ea7010$3bbf5030$@net> References: <085301cbb0ff$2dbb74c0$89325e40$@net> <4D2B6A81.7000002@nasa.gov> <08c401cbb112$13ea7010$3bbf5030$@net> Message-ID: > >> >> My frame of reference is that while we need to make the addresses big >> enough, we also need to preserve the hierarchy. There is no shortage >> of addresses, nor will there be, ever, but there could be a shortage >> of levels in the hierarchy. I assume you would like a home to have a >> /48? But, from my provider's /32, that is only 4 levels at the >> assumed nibble boundary. I think my provider could use another >> two levels. > > If your provide has more than 10,000 customers they should never have gotten a /32. The braindead notion that everyone needed to rush out and get a /32 has not helped get IPv6 deployed. The /32 value was the default one for a startup provider. Every provider with a customer base should have done a plan for a /48 per customer, then gotten the right size block to start with. Any provider with a /32 and more than 10k customers needs to do that now and swap for 'a real block', instead of trying to squeeze their customers into a tiny block due to their insufficient initial request. > ARIN proposal 121 is seeking to clarify this in the NRPM. I've also submitted a similar proposal to APNIC and expect it to be published shortly and discussed in Hong Kong. Unfortunately, I won't be in Hong Kong for the discussion, but, I'm going to try and participate remotely. I encourage anyone facing the /32 is not enough problem at the service provider (or anyone else for that matter) to get involved and speak up in favor of proposal 121 and/or the APNIC equivalent. I intend to put forth similar proposals where necessary in the other RIRs as well. Owen From jeff-kell at utc.edu Mon Jan 10 18:22:46 2011 From: jeff-kell at utc.edu (Jeff Kell) Date: Mon, 10 Jan 2011 19:22:46 -0500 Subject: NIST IPv6 document In-Reply-To: References: <201101061429.p06ETB7g096271@aurora.sol.net> <201101101452.56885.lowen@pari.edu> Message-ID: <4D2BA2D6.3070500@utc.edu> On 1/10/2011 6:55 PM, Owen DeLong wrote: > Nonetheless, NAT remains an opaque screen door at best. > > If the bad guy is behind the door, it helps hide him. > > If the bad guy is outside the door, the time it takes for his knife to cut through it is so small as to be meaningless. For a "server" expected to be open to anyone, anywhere, anytime... yes. Otherwise no. NAT overload (many to 1), and 1-to-1 NAT with some timeout value both serve to disconnect the potential targets from the network, absent any static NAT or port mapping (for "servers"). RFC-1918 behind NAT insures this (notwithstanding pivot attacks). It is a decreasing risk, given the typical user initiated compromise of today (click here to infect your computer), but a non-zero one. The whole IPv6 / no-NAT philosophy of "always connected and always directly addressable" eliminates this layer. Jeff From owen at delong.com Mon Jan 10 18:23:41 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 10 Jan 2011 16:23:41 -0800 Subject: Is Cisco equpiment de facto for you? In-Reply-To: References: <1177151411.1544.1294676497222.JavaMail.root@zimbra.network1.net>, , , , , <4D2B88F0.7090507@utc.edu>, <4D2B8C5D.20601@rollernet.us> Message-ID: <12AA1901-035B-4EE3-813F-3A229E8AA507@delong.com> This is a two-edged sword. Cisco tends to do their own thing, then, try to push their way of doing it onto the standards bodies when the competition starts trying to catch up. Other vendors tend to bring ideas that will require interoperability to the standards bodies and work on getting the standard at least partially defined before spending effort on implementation. There are advantages and drawbacks to both approaches. Owen On Jan 10, 2011, at 2:54 PM, Brandon Kim wrote: > > To be fair to Cisco and maybe I'm way off here. But it seems they do come out with a way to do things first which then become a standard that > they have to follow. > > ISL/DOT1Q > HSRP/VRRP > etherchannel/LACP > > Just some examples..... I'm not aware of too many other vendors that create their own protocol, in which they then become a standard? > > > > > > >> Date: Mon, 10 Jan 2011 14:46:53 -0800 >> From: sethm at rollernet.us >> To: nanog at nanog.org >> Subject: Re: Is Cisco equpiment de facto for you? >> >> On 1/10/2011 14:32, Jeff Kell wrote: >>> On 1/10/2011 3:20 PM, Greg Whynott wrote: >>>> HP probably was the most helpful vendor i've dealt with in relation to solving/providing inter vendor interoperability solutions. they have PDF booklets on many things we would run into during work. for example, setting up STP between Cisco and HP gear, ( http://cdn.procurve.com/training/Manuals/ProCurve-and-Cisco-STP-Interoperability.pdf ). >>> >>> Well, technically, the HP reference tells you how to convert your Cisco >>> default PVST over to MST to match the HP preference. >>> >>> The handful of HP switches versus the stacks and stacks of production >>> Cisco requiring conversion to suit them was "intimidating" to say the >>> least :-) >>> >> >> >> To be fair, one is Cisco proprietary while the other is IEEE 802.1Q. >> >> ~Seth >> > From Valdis.Kletnieks at vt.edu Mon Jan 10 18:33:08 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 10 Jan 2011 19:33:08 -0500 Subject: NIST IPv6 document In-Reply-To: Your message of "Mon, 10 Jan 2011 19:22:46 EST." <4D2BA2D6.3070500@utc.edu> References: <201101061429.p06ETB7g096271@aurora.sol.net> <201101101452.56885.lowen@pari.edu> <4D2BA2D6.3070500@utc.edu> Message-ID: <10091.1294705988@localhost> On Mon, 10 Jan 2011 19:22:46 EST, Jeff Kell said: > It is a decreasing risk, given the typical user initiated compromise of > today (click here to infect your computer), but a non-zero one. > > The whole IPv6 / no-NAT philosophy of "always connected and always > directly addressable" eliminates this layer. I'd say on the whole, it's a net gain - the added ease of tracking down the click-here-to-infect machines that are no longer behind a NAT outweighs the little added security the NAT adds (above and beyond the statefulness that both NAT and a good firewall both add). -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From owen at delong.com Mon Jan 10 18:36:34 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 10 Jan 2011 16:36:34 -0800 Subject: arin and ops fora (was Re: AltDB?) In-Reply-To: <4D2B9622.6060706@brightok.net> References: <59051.1294464800@nsa.vix.com> <00041A16-473F-4F96-93E8-E3CD3F83E1B2@virtualized.org> <70374.1294475040@nsa.vix.com> <4D2B24F9.9000507@brightok.net> <4CB1420A-386C-4017-8011-ABC0C2F376EA@delong.com> <4D2B9622.6060706@brightok.net> Message-ID: <78710C20-94ED-4DDA-9071-2457E6814DD7@delong.com> >> PPML is a forum for the community (not just ARIN members, the entire community). > Good to know. I was under the impression that it was member only. > Nope... Anyone interested can subscribe to PPML. >> There is a separate mailing list... arin-discuss which is for members of ARIN to discuss >> any ARIN-related topic of interest to the membership. They can and sometimes do >> discuss operational matters there. >> > Except it's listed as no input from ARIN itself? > ARIN does occasionally send informational postings to arin-discuss, but, you are correct that ARIN staff does not engage in the discussions on that list. Perhaps a mechanism for ARIN participation would be a good improvement in this area. >> Everything you are asking for in your last paragraph is available. Perhaps what is needed >> is better education of the membership and community on what tools are available and how >> to use them. Were you familiar with arin-discuss prior to this message? If so, in what way >> does it not meet the need you are describing? >> > I can't get subscribed, so, :P > I'll try to address this issue with you off-list. > I also haven't seen on the website pointers for where different tools and resources fall into for community review, comment, suggestion, etc. Perhaps it's just my website navigation skills. However, as I said previously, I have no serious complaints. It's not like the AC and CEO aren't publicly visible and vocal. > Thanks... We try to be accessible to the community for just this reason. I think the website doesn't particularly point to those things, but, there pretty much are only three directions to go and the web site does provide a description of each one... PPML for discussion of number resource policies and related matters. ACSP for suggestions and consultations of the community on non-policy matters. arin-discuss mailing list for discussion with other members about any topic of interest to the ARIN membership, potentially including demand/desire for tools, operational practices of ARIN, fees, etc. Does that help? Owen From tb at tburke.us Mon Jan 10 18:37:14 2011 From: tb at tburke.us (Tim Burke) Date: Mon, 10 Jan 2011 18:37:14 -0600 Subject: Working abuse contact for lstn.net / limestonenetworks.com? Message-ID: Ha, good luck... Limestone is a haven for cheap child-run web hosting companies. I can almost guarantee abuse@ goes to /dev/null... Sent from my Samsung Captivate(tm) on AT&T goemon at anime.net wrote: >Anyone have a WORKING abuse contact for lstn.net / limestonenetworks.com? > >I have tried the usual channels (abuse at limestonenetworks.com, phone calls, "live chat") with no results. > >-Dan > From dougb at dougbarton.us Mon Jan 10 18:57:07 2011 From: dougb at dougbarton.us (Doug Barton) Date: Mon, 10 Jan 2011 16:57:07 -0800 Subject: AltDB? In-Reply-To: <1AAAEF13-B1AC-41CA-8B16-9985FD9E0EB2@arin.net> References: <59051.1294464800@nsa.vix.com> <00041A16-473F-4F96-93E8-E3CD3F83E1B2@virtualized.org> <70374.1294475040@nsa.vix.com> <5336.1294506839@nsa.vix.com> <1AAAEF13-B1AC-41CA-8B16-9985FD9E0EB2@arin.net> Message-ID: <4D2BAAE3.8080009@dougbarton.us> On 01/09/2011 10:09, John Curran wrote: > On Jan 9, 2011, at 2:09 AM, Jeff Wheeler wrote: > >> In terms of database size, excluding RIPE, the ARIN IRR is the 8th >> largest, ahead of ALTDB and about 10% as large as Level3, the second >> largest IRR database (except RIPE.) A mass-corruption of the ARIN IRR >> overnight might be a serious incident causing service impact to a >> large number of users and businesses, and cause probably thousands of >> people to be got out of bed in the middle of the night, but clearly it >> would not be a total disaster. > > > Jeff - > > Please suggest your preferred means of IRR authentication to the ARIN > suggestion process: > Alternatively, point to a best practice document from the operator > community for what should be done here. ARIN's work plan is very much > driven by community input, so that's what is needed here. John, I get what motivates this response, and am even guilty of having provided similar responses. So I'm not going to glom onto the criticism of this as a response _per se_. However, there is a line beyond which some things cross which takes them out of the realm of, "Show me you care about this issue by reporting it in triplicate" and into the category of "This is bad on its face and I need to use my internal channels to get people an answer ASAP." To me (speaking as someone with absolutely no dog in this hunt) the issue of "The only authentication method available for the ARIN IRR is mail-from" clearly falls into the latter category. My reading of the reaction here is incredulity that this was not your immediate response, and (once again without trying to glom on) this is a reaction that I share. Now it seems that you acknowledged that further on in this thread, but just for fun I decided to try your suggestions-suggestion. I went to the site, it requires a login. Well, ok, I think having a method for "I don't want to track this I just want to throw it over the wall in case someone cares" might be valuable, but everyone wants a login nowadays, so fine. I attempt to click the "new user?" link, and at some point I realize that the site requires cookies for login stuff. Ok, another necessary evil. So I enter my desired information, and click continue, and get bounced right back to to the original page. I figure my registration was successful and attempt to log in. That fails. I click the "assistance" link and enter the e-mail address I used to register, it's not registered. So I go back to the registration form, enter my information again, and hit Continue. This time I got an error message, user names must be at least 6 characters. Um .... ok. So I think of another username, click Continue, and get a new error: The e-mail address you entered appears to be a role account. Please enter an e-mail address that contains your name or initials. Note that ARIN Web account information will not be published in ARIN's Whois. If the e-mail address you entered is not a role account, please contact the Registration Services Department at hostmaster at arin.net or +1.703.227.0660. I create e-mail addresses of the form @dougbarton.us for all the sites that I register on to track whether or not they use my e-mail address for nefarious purposes. So yes, "arin at dougbarton.us" looks like a role account, but it's not. So I'll bite, I'll call the number and talk to them. Ooops! I called at 4:01 pm PST, and y'all had closed up shop 1 minute earlier. (Yes, I realize that the ARIN office is on the East Coast, don't care. My working day is still going on for hours more. Must really suck for ops in HI.) Now admittedly my method of working on line is different from the average Internet user, although arguably not _that_ different from a lot of the people in your custo^Wmember demographic. So one could make the argument that in its current form the suggestions page actually serves as a barrier to entry, rather than an effective communications channel. But soldiering on, I put in my "regular" e-mail address, and hit Continue again. It once again bounced me back to the main page, but once again, I was not actually registered. So, I started the whole registration process all over again, and this time it succeeded. So now... You must accept the Terms of Service Agreement in order to proceed. Hmm.. well, 79 very long lines of text, no way to download the document for my lawyers to review, and most of it applies to people managing information related to services. But what the heck, I'll give it a go. So now I have to create a web profile. First/Last, Company, and full postal address are all mandatory fields. Ok, all done with that, now I actually have a web account. *phew* Wait, what was I going to do with it again? Oh yes, I was going to submit a suggestion .... um .... where is the link for suggestions? At the top of the page I have Number Resources, Participate, Policies, Fees & Invoices, Knowledge, About Us. Most of those don't apply to me, so let's see, on the left side we have Message Center, Web Account, POC Records, Organization Data, Manage Resources, Track Tickets, Listing Service, Downloads, Ask ARIN ... neither I nor Firefox can find "suggestions" anywhere on that page. I could of course use the "Ask ARIN" link which brings up a reasonable-looking form to send my suggestion in the form of a question, so I suppose that'll work. Now in case anyone is still reading this message, my point is _not_ "ARIN SUCKS!" My point is simply that saying, "All you have to do is ...." doesn't always cut it, and as I said (way, way) above there _is_ a line where it really is incumbent on the operator community to get involved in the process on your turf. Hopefully though you'll take this thread as feedback from the operator community that where you have (at least up until recently) believed that line to be is not appropriate, or even realistic. best regards, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owen at delong.com Mon Jan 10 18:57:54 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 10 Jan 2011 16:57:54 -0800 Subject: NIST IPv6 document In-Reply-To: <4D2BA2D6.3070500@utc.edu> References: <201101061429.p06ETB7g096271@aurora.sol.net> <201101101452.56885.lowen@pari.edu> <4D2BA2D6.3070500@utc.edu> Message-ID: <99CDF633-ACB8-4175-95BE-F7E9BC10281D@delong.com> On Jan 10, 2011, at 4:22 PM, Jeff Kell wrote: > On 1/10/2011 6:55 PM, Owen DeLong wrote: >> Nonetheless, NAT remains an opaque screen door at best. >> >> If the bad guy is behind the door, it helps hide him. >> >> If the bad guy is outside the door, the time it takes for his knife to cut through it is so small as to be meaningless. > > For a "server" expected to be open to anyone, anywhere, anytime... yes. > Otherwise no. > Uh, yes. For a server, it's a transparent hole in the wall. > NAT overload (many to 1), and 1-to-1 NAT with some timeout value both > serve to disconnect the potential targets from the network, absent any > static NAT or port mapping (for "servers"). > No, they don't, really. Once the host becomes compromised via other means, it readily opens whatever necessary holes in the NAT to permit the undesirable traffic in. Additionally, even an un-compromised host may open the needed holes in NAT through processes like 6to4 and Teredo. > RFC-1918 behind NAT insures this (notwithstanding pivot attacks). > Stateful inspection without address mangling does just as much to insure this as NAT. You, like so many others, are confusing the security benefits of stateful inspection with the misapplication of the term NAT. > It is a decreasing risk, given the typical user initiated compromise of > today (click here to infect your computer), but a non-zero one. > > The whole IPv6 / no-NAT philosophy of "always connected and always > directly addressable" eliminates this layer. > No, it doesn't. A good stateful firewall in front of an IPv6 host without NAT does every bit as much to protect it as the NAT box in your RFC-1918 scenario can. The problem is that everyone assumes directly addressable means directly reachable because they've become so ingrained in this world of NAT that they forget that it is possible to implement effective stateful security without it. The big difference between stateful inspection without NAT and with overloaded NAT is that in the overloaded NAT case, it will help hide the bad guy from the audit trails whereas the non-NAT approach does not do so. Owen From lorddoskias at gmail.com Mon Jan 10 19:17:39 2011 From: lorddoskias at gmail.com (lorddoskias) Date: Tue, 11 Jan 2011 01:17:39 +0000 Subject: Is Cisco equpiment de facto for you? In-Reply-To: <4D2B88F0.7090507@utc.edu> References: <1177151411.1544.1294676497222.JavaMail.root@zimbra.network1.net>, , <4D2B88F0.7090507@utc.edu> Message-ID: <4D2BAFB3.5020602@gmail.com> http://www.youtube.com/watch?v=-aECSsfd4Wk Watch this video, now, I know that it is essentially advertisement from brocade but the guy from ams-ix says something very interesting - "For us it is important to have a board-level relationship with the vendor, no matter who it is". So in the end this might be a factor in deciding which equipment to buy - whether your company will be able to have a higher-level relationship with your vendor so that you can expect appropriate treatment in case of emergency. With bigger company this would be harder, though I think the position "account manager" is essential this, whereas with smaller companies it is easier to build such a relationship From brandon.kim at brandontek.com Mon Jan 10 20:24:56 2011 From: brandon.kim at brandontek.com (Brandon Kim) Date: Mon, 10 Jan 2011 21:24:56 -0500 Subject: Is Cisco equpiment de facto for you? In-Reply-To: <4D2BAFB3.5020602@gmail.com> References: <1177151411.1544.1294676497222.JavaMail.root@zimbra.network1.net>, , , , , <4D2B88F0.7090507@utc.edu>, <4D2BAFB3.5020602@gmail.com> Message-ID: Thank you for this. I find him very honest and humble. Although he didn't mention Cisco, should I assume that he's probably thinking about Cisco without saying it? For anyone that has watched this, he has mentioned going from dual star topology to an MPLS. Perhaps one can educate me a little on how that is better off-list? It is an intresting topology. Do you guys run MPLS internally as your main topology? I was a little confused on that part.... > Date: Tue, 11 Jan 2011 01:17:39 +0000 > From: lorddoskias at gmail.com > To: nanog at nanog.org > Subject: Re: Is Cisco equpiment de facto for you? > > http://www.youtube.com/watch?v=-aECSsfd4Wk > > Watch this video, now, I know that it is essentially advertisement from > brocade but the guy from ams-ix says something very interesting - "For > us it is important to have a board-level relationship with the vendor, > no matter who it is". So in the end this might be a factor in deciding > which equipment to buy - whether your company will be able to have a > higher-level relationship with your vendor so that you can expect > appropriate treatment in case of emergency. With bigger company this > would be harder, though I think the position "account manager" is > essential this, whereas with smaller companies it is easier to build > such a relationship > From jeroen at mompl.net Mon Jan 10 20:38:51 2011 From: jeroen at mompl.net (Jeroen van Aart) Date: Mon, 10 Jan 2011 18:38:51 -0800 Subject: Cruzio peering Message-ID: <4D2BC2BB.6030608@mompl.net> Cruzio in Santa Cruz recently opened a new coloc facility using a newly installed fiber connection (I believe they share this with UCSC, I am not sure who "owns" it in practice). Which in theory should be good news for the Monterey Bay Area which has been without fiber connectivity before. I would like to know with who they're peering with in San Jose and who their provider(s) is or are. Any other information is welcome. Thank you, Jeroen -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html From Valdis.Kletnieks at vt.edu Mon Jan 10 20:52:51 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 10 Jan 2011 21:52:51 -0500 Subject: Is Cisco equpiment de facto for you? In-Reply-To: Your message of "Tue, 11 Jan 2011 01:17:39 GMT." <4D2BAFB3.5020602@gmail.com> References: <1177151411.1544.1294676497222.JavaMail.root@zimbra.network1.net> <4D2B88F0.7090507@utc.edu> <4D2BAFB3.5020602@gmail.com> Message-ID: <11631.1294714371@localhost> On Tue, 11 Jan 2011 01:17:39 GMT, lorddoskias said: > appropriate treatment in case of emergency. With bigger company this > would be harder, though I think the position "account manager" is > essential this Heard someplace, but we've been here ourselves: "We were thrilled to hear they were assigning us our very own lead account manager, until we found out the other levels were platinum, gold, silver, and bronze..." -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From matthew at matthew.at Mon Jan 10 20:53:29 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 10 Jan 2011 18:53:29 -0800 Subject: Cruzio peering In-Reply-To: <4D2BC2BB.6030608@mompl.net> References: <4D2BC2BB.6030608@mompl.net> Message-ID: <4D2BC629.5050105@matthew.at> On 1/10/2011 6:38 PM, Jeroen van Aart wrote: > Cruzio in Santa Cruz recently opened a new coloc facility using a > newly installed fiber connection (I believe they share this with UCSC, > I am not sure who "owns" it in practice). Which in theory should be > good news for the Monterey Bay Area which has been without fiber > connectivity before. > > I would like to know with who they're peering with in San Jose and who > their provider(s) is or are. Any other information is welcome. > Have you considered simply asking them? (If you don't have a contact there, email me off-list) Matthew Kaufman From jcurran at arin.net Mon Jan 10 21:18:54 2011 From: jcurran at arin.net (John Curran) Date: Tue, 11 Jan 2011 03:18:54 +0000 Subject: AltDB? In-Reply-To: <4D2BAAE3.8080009@dougbarton.us> References: <59051.1294464800@nsa.vix.com> <00041A16-473F-4F96-93E8-E3CD3F83E1B2@virtualized.org> <70374.1294475040@nsa.vix.com> <5336.1294506839@nsa.vix.com> <1AAAEF13-B1AC-41CA-8B16-9985FD9E0EB2@arin.net> <4D2BAAE3.8080009@dougbarton.us> Message-ID: On Jan 10, 2011, at 7:57 PM, Doug Barton wrote: On 01/09/2011 10:09, John Curran wrote: >> Please suggest your preferred means of IRR authentication to the ARIN >> suggestion process: > ... > Now it seems that you acknowledged that further on in this thread, but just for fun I decided to try your suggestions-suggestion. I went to the site, it requires a login. Doug - Perhaps you saw the "ARIN Online" login on the left side and decided to create an account for registration services? The Suggestion Process page should haved displayed for you without any login; it describes the suggestion process as follows: "Any person in the ARIN community is welcome to make a suggestion regarding an existing or potential ARIN service or practice. Such a suggestion will be sent to ARIN as described at Suggestion Submission page. " That Suggestion Submission form seems operational without any login as well (or at least works best I can recreate at this time using various browsers.) > Well, ok, I think having a method for "I don't want to track this I just want to throw it over the wall in case someone cares" might be valuable That's the intent, and if its not working that way, then it will be fixed. Can you double check that the suggestion process page displayed including the link to the simple suggestion form? Thanks! /John John Curran President and CEO ARIN From jbates at brightok.net Mon Jan 10 22:22:32 2011 From: jbates at brightok.net (Jack Bates) Date: Mon, 10 Jan 2011 22:22:32 -0600 Subject: NIST IPv6 document In-Reply-To: <10091.1294705988@localhost> References: <201101061429.p06ETB7g096271@aurora.sol.net> <201101101452.56885.lowen@pari.edu> <4D2BA2D6.3070500@utc.edu> <10091.1294705988@localhost> Message-ID: <4D2BDB08.7030701@brightok.net> On 1/10/2011 6:33 PM, Valdis.Kletnieks at vt.edu wrote: > I'd say on the whole, it's a net gain - the added ease of tracking down > the click-here-to-infect machines that are no longer behind a NAT > outweighs the little added security the NAT adds (above and beyond > the statefulness that both NAT and a good firewall both add). > Really? Which machine was using the privacy extension address on the /64? I don't see how it's made it any easier to track. In some ways, on provider edges that don't support DHCPv6 IA_TA and relay on slaac, it's one extra nightmare. Jack From jlewis at lewis.org Mon Jan 10 23:40:29 2011 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 11 Jan 2011 00:40:29 -0500 (EST) Subject: AltDB? In-Reply-To: References: <59051.1294464800@nsa.vix.com> <00041A16-473F-4F96-93E8-E3CD3F83E1B2@virtualized.org> <70374.1294475040@nsa.vix.com> <5336.1294506839@nsa.vix.com> <1AAAEF13-B1AC-41CA-8B16-9985FD9E0EB2@arin.net> <4D2BAAE3.8080009@dougbarton.us> Message-ID: On Tue, 11 Jan 2011, John Curran wrote: > "Any person in the ARIN community is welcome to make a suggestion > regarding an existing or potential ARIN service or practice. > Such a suggestion will be sent to ARIN as described at Suggestion > Submission page. " I just used that to put in the suggestion that rr.arin.net be updated to support CRYPT-PW (DES and MD5) and PGP, along with reasoning for the suggestion. The page had a captcha on it. Immediately after submitting, it, I got an email saying I had to hit a link to confirm the suggestion. Does ARIN get that much form submission spam on the suggestion form (with the captcha)? My suggestion ID is 2011.1...so I'm guessing this isn't a heavily used form :) ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From dougb at dougbarton.us Tue Jan 11 00:45:20 2011 From: dougb at dougbarton.us (Doug Barton) Date: Mon, 10 Jan 2011 22:45:20 -0800 Subject: AltDB? In-Reply-To: References: <59051.1294464800@nsa.vix.com> <00041A16-473F-4F96-93E8-E3CD3F83E1B2@virtualized.org> <70374.1294475040@nsa.vix.com> <5336.1294506839@nsa.vix.com> <1AAAEF13-B1AC-41CA-8B16-9985FD9E0EB2@arin.net> <4D2BAAE3.8080009@dougbarton.us> Message-ID: <4D2BFC80.2040305@dougbarton.us> On 01/10/2011 19:18, John Curran wrote: > On Jan 10, 2011, at 7:57 PM, Doug Barton wrote: > On 01/09/2011 10:09, John Curran wrote: >>> Please suggest your preferred means of IRR authentication to the ARIN >>> suggestion process: >> ... >> Now it seems that you acknowledged that further on in this thread, but just for fun I decided to try your suggestions-suggestion. I went to the site, it requires a login. > > Doug - Perhaps you saw the "ARIN Online" login on the left side and decided > to create an account for registration services? Wasn't a conscious decision, no. :) The page at the URL above looks like this for me: http://dougbarton.us/ARIN-Participation.png That's using firefox 3.6.13 on FreeBSD with a few addons, but nothing that should be affecting how the page renders. OTOH I do have the minimum font size cranked up globally. On (admittedly) cursory exam I didn't see a form to submit anything, so I gravitated to the rather large login widget under the assumption that it must be important because it's so big. :) Of course I wish now that I had spent a little more time searching for a suggestion link, but with the only prominently displayed suggestion-related item being the "ARIN Consultation and Suggestion Process" header, and no form below it, my eye went to the next biggest thing. > The Suggestion Process page > should haved displayed for you without any login; it describes the suggestion > process as follows: > > "Any person in the ARIN community is welcome to make a suggestion > regarding an existing or potential ARIN service or practice. > Such a suggestion will be sent to ARIN as described at Suggestion > Submission page. " Yes, when going to that page it's a lot more clear. I'm glad that it's my own incompetence that prevented me from effectively making a submission. Perhaps we're all better off as a result. :) Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From drc at virtualized.org Mon Jan 10 22:23:33 2011 From: drc at virtualized.org (David Conrad) Date: Mon, 10 Jan 2011 20:23:33 -0800 Subject: arin and ops fora (was Re: AltDB?) In-Reply-To: <70BCF9E7-BC8E-4C81-A5C7-32F47EB55575@delong.com> References: <94F3F129-608E-46EC-B157-CC23CAA47454@tozz.net> <4D24A734.3000807@jcoley.net> <816AB912-14CF-4028-853A-F0BE77D2EB09@puck.nether.net> <734B46C1-AE6C-406A-8163-00CFFE942B1B@virtualized.org> <000101cbaf42$0a65d7e0$1f3187a0$@org> <55EF24AC-DFFC-4A84-B828-693F0A1864A9@virtualized.org> <70BCF9E7-BC8E-4C81-A5C7-32F47EB55575@delong.com> Message-ID: <6013CADB-6031-42B7-86D7-F14E0F8DAB69@virtualized.org> Owen, On Jan 8, 2011, at 8:56 PM, Owen DeLong wrote: >> I suspect part of the issue is that ARIN is a monopoly provider of a variety public services that folks unrelated (directly) to ARIN must make use of. In other areas of public service provision, there are things like public utilities commissions that (in theory) ensure the monopoly service provider acts in the public benefit when services are added/changed/deleted. My impression is that the various WGs and SIGs in the other RIRs perform something similar to that function. There doesn't appear to be anything similar in the ARIN region. > > In ARIN, there are things like BoT elections and the BoT very much fulfills the role of the PUC as you describe above. Well, ARIN BoT members are fiduciarily responsible for ARIN. PUC members, to my understanding, are responsible to the public. In my experience on ARIN's board, the key role of the board was to ensure the public policy process was followed, not oversight of how public services are provided. However, things might have changed -- that was some time ago. > People can submit requests for operational changes to ARIN through the ACSP and in my experience they get a good review > and comment period by the community Which community? ARIN or NANOG? > and the board listens to these things and responds appropriately. Somewhat as an aside, I'm a bit surprised the board would get involved at the level of detail this implies. I would've thought how public services are to be provided would be an operational decision made by the ARIN CEO/staff and that the board would only get involved to ensure sufficient resources were available. > Especially if a > suggestion receives significant support, it tends to get implemented. My impression of the concern is that the definition of support and decisions regarding what gets implemented are made within a subset of the network operations community. Regards, -drc From drc at virtualized.org Mon Jan 10 22:52:48 2011 From: drc at virtualized.org (David Conrad) Date: Mon, 10 Jan 2011 20:52:48 -0800 Subject: arin and ops fora (was Re: AltDB?) In-Reply-To: <4CB1420A-386C-4017-8011-ABC0C2F376EA@delong.com> References: <59051.1294464800@nsa.vix.com> <00041A16-473F-4F96-93E8-E3CD3F83E1B2@virtualized.org> <70374.1294475040@nsa.vix.com> <4D2B24F9.9000507@brightok.net> <4CB1420A-386C-4017-8011-ABC0C2F376EA@delong.com> Message-ID: <782258FA-E657-4E62-8F0C-1C693B1129E6@virtualized.org> Owen, On Jan 10, 2011, at 3:13 PM, Owen DeLong wrote: > Members may bring any topic of interest to arin-discuss. Just to be clear, arin-discuss is limited to ARIN members? > They can and sometimes do discuss operational matters there. Operational matters that impact more than members? > The ACSP provides > a process for community review of the suggestions and semi-formal comment processes as > well. Which community? Regards, -drc From drc at virtualized.org Tue Jan 11 00:57:32 2011 From: drc at virtualized.org (David Conrad) Date: Mon, 10 Jan 2011 22:57:32 -0800 Subject: arin and ops fora (was Re: AltDB?) In-Reply-To: <002d01cbb01b$eaa07160$bfe15420$@org> References: <94F3F129-608E-46EC-B157-CC23CAA47454@tozz.net> <4D24A734.3000807@jcoley.net> <816AB912-14CF-4028-853A-F0BE77D2EB09@puck.nether.net> <734B46C1-AE6C-406A-8163-00CFFE942B1B@virtualized.org> <000101cbaf42$0a65d7e0$1f3187a0$@org> <55EF24AC-DFFC-4A84-B828-693F0A1864A9@virtualized.org> <002d01cbb01b$eaa07160$bfe15420$@org> Message-ID: Lee, On Jan 9, 2011, at 8:40 AM, Lee Howard wrote: > Are you saying ARIN needs an ombudsman function to make sure the Board doesn't delay implementation of things the community wants while it figures out whether doing such things will prevent it from doing other things the community wants? No (or at least I don't think so -- I have difficulty parsing that sentence). I'm suggesting that the informal input mechanisms historically and currently used by ARIN to determine what should be done (and to some extent how) may be insufficient, inefficient, and/or imply certain risks given that many of the services provided by ARIN are done on a monopoly basis and failure of those service could have global effect. Or not. It may be that network operators (not just the ones that show up at ARIN meetings and are on PPML) are happy with the existing communication channels and that additional structures to encourage participation and input in the ARIN region regarding services ARIN provides to the public are unnecessary. > I don't understand how this bee-watcher-watcher thing works. Sorry, which? Regards, -drc From owen at delong.com Tue Jan 11 01:10:50 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 10 Jan 2011 23:10:50 -0800 Subject: NIST IPv6 document In-Reply-To: <4D2BDB08.7030701@brightok.net> References: <201101061429.p06ETB7g096271@aurora.sol.net> <201101101452.56885.lowen@pari.edu> <4D2BA2D6.3070500@utc.edu> <10091.1294705988@localhost> <4D2BDB08.7030701@brightok.net> Message-ID: On Jan 10, 2011, at 8:22 PM, Jack Bates wrote: > On 1/10/2011 6:33 PM, Valdis.Kletnieks at vt.edu wrote: >> I'd say on the whole, it's a net gain - the added ease of tracking down >> the click-here-to-infect machines that are no longer behind a NAT >> outweighs the little added security the NAT adds (above and beyond >> the statefulness that both NAT and a good firewall both add). >> > > Really? Which machine was using the privacy extension address on the /64? I don't see how it's made it any easier to track. In some ways, on provider edges that don't support DHCPv6 IA_TA and relay on slaac, it's one extra nightmare. > > > Jack At least I can tell which segment the pwn3d machine is on. As it currently stands, I'm lucky if I can tell which state the pwn3d machine inside $ENTERPRISE is located in. Sometimes, you can't even tell which country. Owen From owen at delong.com Tue Jan 11 01:16:09 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 10 Jan 2011 23:16:09 -0800 Subject: arin and ops fora (was Re: AltDB?) In-Reply-To: <782258FA-E657-4E62-8F0C-1C693B1129E6@virtualized.org> References: <59051.1294464800@nsa.vix.com> <00041A16-473F-4F96-93E8-E3CD3F83E1B2@virtualized.org> <70374.1294475040@nsa.vix.com> <4D2B24F9.9000507@brightok.net> <4CB1420A-386C-4017-8011-ABC0C2F376EA@delong.com> <782258FA-E657-4E62-8F0C-1C693B1129E6@virtualized.org> Message-ID: On Jan 10, 2011, at 8:52 PM, David Conrad wrote: > Owen, > > On Jan 10, 2011, at 3:13 PM, Owen DeLong wrote: >> Members may bring any topic of interest to arin-discuss. > > Just to be clear, arin-discuss is limited to ARIN members? > To the best of my knowledge, yes. >> They can and sometimes do discuss operational matters there. > > Operational matters that impact more than members? > Operational matters as in ARIN operations. While operations ARIN does such as rDNS, whois, etc. may impact those outside of ARIN membership, ARIN members are (generally) the ones paying for those operations. If you want a say in changing those operations (and thus changing what it costs to perform them), you can become a member of ARIN for a mere $500/year, or, you can use the ACSP which is the process for submitting non-policy matters to ARIN which are then brought before the community on PPML in a non-policy context. >> The ACSP provides >> a process for community review of the suggestions and semi-formal comment processes as >> well. > > Which community? > The community on PPML. Owen From owen at delong.com Tue Jan 11 01:24:31 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 10 Jan 2011 23:24:31 -0800 Subject: arin and ops fora (was Re: AltDB?) In-Reply-To: <6013CADB-6031-42B7-86D7-F14E0F8DAB69@virtualized.org> References: <94F3F129-608E-46EC-B157-CC23CAA47454@tozz.net> <4D24A734.3000807@jcoley.net> <816AB912-14CF-4028-853A-F0BE77D2EB09@puck.nether.net> <734B46C1-AE6C-406A-8163-00CFFE942B1B@virtualized.org> <000101cbaf42$0a65d7e0$1f3187a0$@org> <55EF24AC-DFFC-4A84-B828-693F0A1864A9@virtualized.org> <70BCF9E7-BC8E-4C81-A5C7-32F47EB55575@delong.com> <6013CADB-6031-42B7-86D7-F14E0F8DAB69@virtualized.org> Message-ID: On Jan 10, 2011, at 8:23 PM, David Conrad wrote: > Owen, > > On Jan 8, 2011, at 8:56 PM, Owen DeLong wrote: >>> I suspect part of the issue is that ARIN is a monopoly provider of a variety public services that folks unrelated (directly) to ARIN must make use of. In other areas of public service provision, there are things like public utilities commissions that (in theory) ensure the monopoly service provider acts in the public benefit when services are added/changed/deleted. My impression is that the various WGs and SIGs in the other RIRs perform something similar to that function. There doesn't appear to be anything similar in the ARIN region. >> >> In ARIN, there are things like BoT elections and the BoT very much fulfills the role of the PUC as you describe above. > > Well, ARIN BoT members are fiduciarily responsible for ARIN. PUC members, to my understanding, are responsible to the public. In my experience on ARIN's board, the key role of the board was to ensure the public policy process was followed, not oversight of how public services are provided. However, things might have changed -- that was some time ago. > Yes, ARIN BoT members have fiduciary responsibility for ARIN. However, the ARIN charter is not the same as most corporations. Indeed, as I understand it, the ARIN charter requires that ARIN disband itself if that is determined to be what is in the best interests of the community. The board is accountable to the ARIN membership, which includes all subscriber ISPs and others who pay their annual membership dues. I believe the board both ensures that the public policy process is followed and performs other executive management and leadership functions governing the operations of ARIN at a high level. Obviously most of the day-to-day decision making for that is vested in the CEO who also sits on the board. >> People can submit requests for operational changes to ARIN through the ACSP and in my experience they get a good review >> and comment period by the community > > Which community? ARIN or NANOG? > Those who subscribe to PPML. If you are interested in having a voice in ARIN policies or how ARIN operates, it's essential to be on that list. >> and the board listens to these things and responds appropriately. > > Somewhat as an aside, I'm a bit surprised the board would get involved at the level of detail this implies. I would've thought how public services are to be provided would be an operational decision made by the ARIN CEO/staff and that the board would only get involved to ensure sufficient resources were available. > For the most part, it is. However, if the community is asking for something ARIN isn't doing or pushing for ARIN to change how it does something, the board tends to at least review the matter. >> Especially if a >> suggestion receives significant support, it tends to get implemented. > > My impression of the concern is that the definition of support and decisions regarding what gets implemented are made within a subset of the network operations community. > Anyone who wants to participate can join the mailing list and do so. I'm not sure how you would extend it to a wider group without seriously diminishing returns. Owen From tme at americafree.tv Tue Jan 11 04:50:09 2011 From: tme at americafree.tv (Marshall Eubanks) Date: Tue, 11 Jan 2011 05:50:09 -0500 Subject: Internet to Tunisia Message-ID: I am hearing reports of Internet blockage in / to Tunisia, where a near full-on revolt is being coordinated / reported on by social media such as twitter ( #sidibouzid ), Facebook and Youtube. Can anyone confirm that there is blockage ? Are there any in-country resources to check this ? There does not appear to be a looking glass in Tunisia. Regards Marshall From bortzmeyer at nic.fr Tue Jan 11 05:01:07 2011 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 11 Jan 2011 12:01:07 +0100 Subject: Internet to Tunisia In-Reply-To: References: Message-ID: <20110111110107.GA14059@nic.fr> On Tue, Jan 11, 2011 at 05:50:09AM -0500, Marshall Eubanks wrote a message of 10 lines which said: > Can anyone confirm that there is blockage ? There exists filtering for a long time and it is widely documented. I am not aware of a global blockage today. > Are there any in-country resources to check this ? The Web site of the Tunisian Internet agency, , it is hosted in Tunis, as are some of the name servers of .TN like ns2.ati.tn. From nick at foobar.org Tue Jan 11 05:03:26 2011 From: nick at foobar.org (Nick Hilliard) Date: Tue, 11 Jan 2011 11:03:26 +0000 Subject: Internet to Tunisia In-Reply-To: References: Message-ID: <4D2C38FE.4060500@foobar.org> On 11/01/2011 10:50, Marshall Eubanks wrote: > I am hearing reports of Internet blockage in / to Tunisia, where a near full-on revolt is being coordinated / reported on by > social media such as twitter ( #sidibouzid ), Facebook and Youtube. > > Can anyone confirm that there is blockage ? Are there any in-country resources to check this ? There does not appear to be a looking glass in Tunisia. Are you referring to this: http://www.thetechherald.com/article.php/201101/6651/Tunisian-government-harvesting-usernames-and-passwords (short url: http://tinyurl.com/36tu64h) Nick From jethro.binks at strath.ac.uk Tue Jan 11 07:56:31 2011 From: jethro.binks at strath.ac.uk (Jethro R Binks) Date: Tue, 11 Jan 2011 13:56:31 +0000 (GMT) Subject: Is Cisco equpiment de facto for you? In-Reply-To: <61EC3786-5732-4C5A-8938-A15E840DC75B@oicr.on.ca> References: <4D2B365C.5070506@gmail.com> <61EC3786-5732-4C5A-8938-A15E840DC75B@oicr.on.ca> Message-ID: On Mon, 10 Jan 2011, Greg Whynott wrote: > > Just as a pointer - one of the largest and most utilized IX (AMS-IX) > > has their platform built on Brocade devices. > > Brocade device's pre Foundry purchase correct? I can't see anyone that > large using Foundry in large deployments.. Probably not as large as AMX-IX, but London Internet Exchange (LINX): both as Foundry and Brocade. Jethro. . . . . . . . . . . . . . . . . . . . . . . . . . Jethro R Binks, Network Manager, Information Services Directorate, University Of Strathclyde, Glasgow, UK The University of Strathclyde is a charitable body, registered in Scotland, number SC015263. From jcurran at arin.net Tue Jan 11 08:14:25 2011 From: jcurran at arin.net (John Curran) Date: Tue, 11 Jan 2011 14:14:25 +0000 Subject: AltDB? In-Reply-To: <4D2BFC80.2040305@dougbarton.us> References: <59051.1294464800@nsa.vix.com> <00041A16-473F-4F96-93E8-E3CD3F83E1B2@virtualized.org> <70374.1294475040@nsa.vix.com> <5336.1294506839@nsa.vix.com> <1AAAEF13-B1AC-41CA-8B16-9985FD9E0EB2@arin.net> <4D2BAAE3.8080009@dougbarton.us> <4D2BFC80.2040305@dougbarton.us> Message-ID: On Jan 11, 2011, at 1:45 AM, Doug Barton wrote: > On (admittedly) cursory exam I didn't see a form to submit anything, so I gravitated to the rather large login widget under the assumption that it must be important because it's so big. :) > ... Doug - It's perfectly understandable, and doesn't distract from your main point that the circumstances (ARIN effectively mandating MAIL-FROM for authentication) is patently unacceptable and shouldn't require any more effort than pointing such out in email. I did not perceive the situation initially, and hence sent Jeff Wheeler off to said suggestion form. As noted, we're now looking into how to fix the IRR authentication situation and will report back asap. /John John Curran President and CEO ARIN From jbates at brightok.net Tue Jan 11 08:15:15 2011 From: jbates at brightok.net (Jack Bates) Date: Tue, 11 Jan 2011 08:15:15 -0600 Subject: arin and ops fora (was Re: AltDB?) In-Reply-To: References: <94F3F129-608E-46EC-B157-CC23CAA47454@tozz.net> <4D24A734.3000807@jcoley.net> <816AB912-14CF-4028-853A-F0BE77D2EB09@puck.nether.net> <734B46C1-AE6C-406A-8163-00CFFE942B1B@virtualized.org> <000101cbaf42$0a65d7e0$1f3187a0$@org> <55EF24AC-DFFC-4A84-B828-693F0A1864A9@virtualized.org> <002d01cbb01b$eaa07160$bfe15420$@org> Message-ID: <4D2C65F3.9050200@brightok.net> On 1/11/2011 12:57 AM, David Conrad wrote: > Or not. It may be that network operators (not just the ones that show up at ARIN meetings and are on PPML) are happy with the existing communication channels and that additional structures to encourage participation and input in the ARIN region regarding services ARIN provides to the public are unnecessary. > Public easily reachable people. Public information on operations and what they do on their website with tons of pointers (even if it's not laid out the best). Public participation mailing lists. Presence of key people on other lists such as nanog. What more is an org supposed to do to communicate with people? Even the CEO lurks on nanog and responds when necessary. What community were you wanting them to interface with? I could be wrong, but I suspect any genius ideas which the CEO hears via the various communication mediums may quickly find it's way to be implemented. Sure, it may get restricted to some degree depending on how people in PPML feel about it. I'm sure the membership has some say on how their money is spent. Neither of these things limit the ability to suggest an idea. Jack From mikea at mikea.ath.cx Tue Jan 11 08:20:51 2011 From: mikea at mikea.ath.cx (mikea) Date: Tue, 11 Jan 2011 08:20:51 -0600 Subject: Satellite IP In-Reply-To: <18554927.984.1294695210090.JavaMail.root@benjamin.baylink.com> References: <46553.1294692742@localhost> <18554927.984.1294695210090.JavaMail.root@benjamin.baylink.com> Message-ID: <20110111142050.GA97594@mikea.ath.cx> On Mon, Jan 10, 2011 at 04:33:30PM -0500, Jay Ashworth wrote: > ----- Original Message ----- > > From: "Valdis Kletnieks" > > > > Why the hostility, Valdis? > > > > As I said several times - it's not hard to be 98% or 99% sure you can make > > all your commitments. However, since predicting the future is an inexact > > science, > > it's really hard to provide a *100% guarantee* that you'll have enough > > contended capacity to make all the performance targets even if every > > single occasional customer shows up at once. As Jay pointed out in his > > follow-up note, his backup strategy is "scramble around and hope another > > provider can > > come through in time", which is OK if you *know* that's your strategy > > and are OK on it. However, blindly going along with "my usual provider > > guaranteed 100% availability" is a bad idea. > > I don't think Kelly is on his first rodeo, and I know I'm not. > > "scramble around" is a bit pejorative as descriptions for my booking > strategy go, but everyone has a cranky day every so often, not least me. > > :-) > > And note that I *also* pointed out that carrier statmuxing on the > transport is a valid strategy for capacity elasticity, in that particular > environment. > > > Remember, we're coming out of a solar minimum. ;) > > Are we in fact coming out of it yet? I heard it was getting deeper, > and that we were looking at a Dalton, if not another Maunder. I'll have to find the paper I read yesterday that said we should expect to wait a long time before we see sunspot counts back where they should be. ... Try this: -- Mike Andrews, W5EGO mikea at mikea.ath.cx Tired old sysadmin From ron at spawar.navy.mil Tue Jan 11 08:21:35 2011 From: ron at spawar.navy.mil (Ron Broersma) Date: Tue, 11 Jan 2011 06:21:35 -0800 Subject: Is Cisco equpiment de facto for you? In-Reply-To: <61EC3786-5732-4C5A-8938-A15E840DC75B@oicr.on.ca> References: <4D2B365C.5070506@gmail.com> <61EC3786-5732-4C5A-8938-A15E840DC75B@oicr.on.ca> Message-ID: <6EC839D7-ABA9-4EF8-A416-E3F76142CB4C@spawar.navy.mil> > Brocade device's pre Foundry purchase correct? I can't see anyone that large using Foundry in large deployments.. Foundry/Brocade is used heavily in portions of DoD's research and engineering community. It is usually preferred where you need high 10Gig port density, IPv6, and/or sflow. But Juniper and Cisco are used heavily as well, depending on local requirements and culture. --Ron -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4936 bytes Desc: not available URL: From brandon.kim at brandontek.com Tue Jan 11 08:23:39 2011 From: brandon.kim at brandontek.com (Brandon Kim) Date: Tue, 11 Jan 2011 09:23:39 -0500 Subject: Is Cisco equpiment de facto for you? In-Reply-To: References: , <4D2B365C.5070506@gmail.com>, <61EC3786-5732-4C5A-8938-A15E840DC75B@oicr.on.ca>, Message-ID: For anyone that is following this thread/subject from yesterday, is it me or does it seem as if Cisco really isn't the choice for most SP's? Someone has mentioned that it all really depends on your needs and what it is you want to provide. IMO, every vendor has something they are good at. I wouldn't use Cisco for everything, nor Juniper etc etc... The concern I sense is that from Cisco's POV, it's their way or the highway. Not only do you pay a premium for smartnet, but if there's an issue, they are quick to point the finger. That is not service/support that I desire.... Is this what everyone is sensing as well? I'm starting to look at Brocade now just to do some fair comparisons..... > Date: Tue, 11 Jan 2011 13:56:31 +0000 > From: jethro.binks at strath.ac.uk > To: nanog at nanog.org > Subject: Re: Is Cisco equpiment de facto for you? > > On Mon, 10 Jan 2011, Greg Whynott wrote: > > > > Just as a pointer - one of the largest and most utilized IX (AMS-IX) > > > has their platform built on Brocade devices. > > > > Brocade device's pre Foundry purchase correct? I can't see anyone that > > large using Foundry in large deployments.. > > Probably not as large as AMX-IX, but London Internet Exchange (LINX): both > as Foundry and Brocade. > > Jethro. > > .. . . . . . . . . . . . . . . . . . . . . . . . . > Jethro R Binks, Network Manager, > Information Services Directorate, University Of Strathclyde, Glasgow, UK > > The University of Strathclyde is a charitable body, registered in > Scotland, number SC015263. > From jbates at brightok.net Tue Jan 11 08:49:45 2011 From: jbates at brightok.net (Jack Bates) Date: Tue, 11 Jan 2011 08:49:45 -0600 Subject: Is Cisco equpiment de facto for you? In-Reply-To: References: , <4D2B365C.5070506@gmail.com>, <61EC3786-5732-4C5A-8938-A15E840DC75B@oicr.on.ca>, Message-ID: <4D2C6E09.8010705@brightok.net> On 1/11/2011 8:23 AM, Brandon Kim wrote: > > For anyone that is following this thread/subject from yesterday, is it me or does it seem as if Cisco really isn't > the choice for most SP's? > Just going on Cisco, Juniper, and Brocade. Cisco (especially ASR) makes the best DSL services aggregation feature set, Juniper a close second. Brocade doesn't have subscriber management functionality. The ASR is the cheapest subscriber management router I've been able to find (outside of 7200) and supports redundant processors. Brocade has the cheapest 10GE/100GE interfaces, does well in many middleman situations. It has limitations on 802.11ad which can be redesigned using p2p vpls if you need granular control at the SP edge. At last check, multi-topology for isis was still on roadmap but not implemented. This may have changed. Not sure. Juniper makes for excellent core routing, BGP and business customer edge. The functionality a Juniper does support is very robust. With the new MX line's trio chipset, they are continuing to push more edge/subscriber management features to the edge, all hardware supported. An additional point is always added to Cisco for supporting the used market. This drastically lowers purchase cost at a slightly higher support cost. Even an ASR, which is hard to find used, can keep it's cost low by adding used SPA interfaces. This generally means I look at Cisco for the subscriber management aggregation router, Juniper for the core, and Brocade for mpls switching in metro scenarios where the cost of Juniper at each of the metro pops makes for a very scary bill. > The concern I sense is that from Cisco's POV, it's their way or the highway. Not only do you pay a premium for smartnet, > but if there's an issue, they are quick to point the finger. That is not service/support that I desire.... > Premium for smartnet is offset by the fact that you can get smartnet on used gear at a fraction of the cost. Even if your used portion is only the linecards (which new often cost more than the chassis/switching fabric/dual routing engines), it's a huge cost savings for large deployments in broadband aggregation w/ subscriber management. To be honest, I use smartnet to upgrade the OS. I quit calling TAC after they failed to understand, much less help me with my eigrp over frame relay with automatic ISDN backup on route failure and re-establishment of eigrp over the ISDN. :) > Is this what everyone is sensing as well? I'm starting to look at Brocade now just to do some fair comparisons..... Nothing wrong with brocade unless you want high end 802.1ad, multi-topology (may be fixed, or will soon) isis, subscriber management. There is no fair comparisons, though. Each box has it's strengths and weaknesses. Jack (currently using C/J, Brocade is spec'd if management will ever sign off on replacing those darn C5500s which are 10 years overdue to upgrade) From tme at americafree.tv Tue Jan 11 08:58:51 2011 From: tme at americafree.tv (Marshall Eubanks) Date: Tue, 11 Jan 2011 09:58:51 -0500 Subject: Internet to Tunisia In-Reply-To: <4D2C38FE.4060500@foobar.org> References: <4D2C38FE.4060500@foobar.org> Message-ID: <092EB950-B2EB-40F8-A54A-467BC671847A@americafree.tv> On Jan 11, 2011, at 6:03 AM, Nick Hilliard wrote: > On 11/01/2011 10:50, Marshall Eubanks wrote: >> I am hearing reports of Internet blockage in / to Tunisia, where a near full-on revolt is being coordinated / reported on by >> social media such as twitter ( #sidibouzid ), Facebook and Youtube. >> >> Can anyone confirm that there is blockage ? Are there any in-country resources to check this ? There does not appear to be a looking glass in Tunisia. > > Are you referring to this: > > http://www.thetechherald.com/article.php/201101/6651/Tunisian-government-harvesting-usernames-and-passwords > > (short url: http://tinyurl.com/36tu64h) No, I have received personal communications. On twitter right now there are frequent claims that all https is blocked (presumably a port blocking). Regards Marshall > > Nick > From streiner at cluebyfour.org Tue Jan 11 05:11:27 2011 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Tue, 11 Jan 2011 06:11:27 -0500 (EST) Subject: Is Cisco equpiment de facto for you? In-Reply-To: References: , <4D2B365C.5070506@gmail.com>, <61EC3786-5732-4C5A-8938-A15E840DC75B@oicr.on.ca>, Message-ID: On Tue, 11 Jan 2011, Brandon Kim wrote: > Someone has mentioned that it all really depends on your needs and what > it is you want to provide. Agree 100%. Some vendors are better at delivering X than others. > IMO, every vendor has something they are good at. I wouldn't use Cisco > for everything, nor Juniper etc etc... A lot of it comes down to striking an appropriate balance between the points I made in my last message. Using a different vendor for every service you offer would probably not scale too well in terms of manageability, but getting into bed with one vendor can have consequences as well. It's ultimately up to you to decide how you want to proceed since you're the one spending the money :) > The concern I sense is that from Cisco's POV, it's their way or the > highway. Not only do you pay a premium for smartnet, but if there's an > issue, they are quick to point the finger. That is not service/support > that I desire.... Some of that perceived arrogance came from being the big kid on the block. The way Cisco acted in the past when they were pretty much the only game in town reminds me a lot of the way Microsoft and Oracle conduct(ed) their business as well, even today **. I haven't seen much of that from Cisco in a while, but if I have a problem with a TAC case or a TAC engineer, I'll get my account team involved. Over the years, a number of legitimate competitors to Cisco have gained market share, and competition often has the effect of adjusting attitudes and leveling the playing field a bit. jms ** - had an account rep from Cisco in the dot-com days, whose idea of customer interaction was calling to confirm that the purchase order just came off the fax machine :) From simonw at zynet.net Tue Jan 11 09:17:19 2011 From: simonw at zynet.net (Simon Waters) Date: Tue, 11 Jan 2011 15:17:19 +0000 Subject: Internet to Tunisia In-Reply-To: <092EB950-B2EB-40F8-A54A-467BC671847A@americafree.tv> References: <4D2C38FE.4060500@foobar.org> <092EB950-B2EB-40F8-A54A-467BC671847A@americafree.tv> Message-ID: <201101111517.19708.simonw@zynet.net> On Tuesday 11 January 2011 14:58:51 Marshall Eubanks wrote: > > On twitter right now there are frequent claims that all https is blocked > (presumably a port blocking). A quick search pulls up. http://www.cpj.org/internet/2011/01/tunisia-invades-censors-facebook-other-accounts.php Since Gmail defaults to HTTPS, and many other sites left to their own devices, it is necessary for an attacker to try and force clients to use HTTP or start conversation using HTTP (so that no one notices when the important bit isn't encrypted, or to enable javascript from a third part to be injected). NoScript for Firefox has a force HTTPS for a domain feature. http://noscript.net/faq#qa6_3 But what clients really need is a way for servers to say "always use encryption". http://noscript.net/faq#STS Of course when it gets to the level of countries, it is quite plausible your browser may already trust a certificate authority under their jurisdiction so all bets are off. I think I'm saying HTTPS doesn't quite hack it in browsers yet, but it will be "secure enough" real soon now. From andrew.koch at tdstelecom.com Tue Jan 11 09:18:29 2011 From: andrew.koch at tdstelecom.com (Koch, Andrew) Date: Tue, 11 Jan 2011 09:18:29 -0600 Subject: AltDB? In-Reply-To: Message-ID: <84F7634862692847B463C7934B86ECD9E206E80D@CMX001.corp.tds.local> On Jan 11, 2011 at 8:14AM, John Curran wrote: > It's perfectly understandable, and doesn't distract from your main > point that the circumstances (ARIN effectively mandating MAIL-FROM > for authentication) is patently unacceptable and shouldn't require any > more effort than pointing such out in email. I did not perceive the > situation initially, and hence sent Jeff Wheeler off to said suggestion > form. As noted, we're now looking into how to fix the IRR authentication > situation and will report back asap. As you are checking out authentication, can you also check out the notify fields as well. I was informed in July 2010 that neither mnt-nfy nor notify fields were operational. I submitted suggestion 2011.2 requesting these be activated. Regards, Andrew Koch TDS Telecom - IP Network Operations andrew.koch at tdstelecom.com From jcurran at arin.net Tue Jan 11 09:30:20 2011 From: jcurran at arin.net (John Curran) Date: Tue, 11 Jan 2011 15:30:20 +0000 Subject: AltDB? In-Reply-To: <84F7634862692847B463C7934B86ECD9E206E80D@CMX001.corp.tds.local> References: <84F7634862692847B463C7934B86ECD9E206E80D@CMX001.corp.tds.local> Message-ID: <78D79933-5134-4714-94A4-4AEAD1F9167E@arin.net> On Jan 11, 2011, at 10:18 AM, Koch, Andrew wrote: > As you are checking out authentication, can you also check out the notify fields as well. I was informed in July 2010 that neither mnt-nfy nor notify fields were operational. I submitted suggestion 2011.2 requesting these be activated. Will do - Thanks for the note. /John John Curran President and CEO ARIN From sethm at rollernet.us Tue Jan 11 10:29:07 2011 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 11 Jan 2011 08:29:07 -0800 Subject: Is Cisco equpiment de facto for you? In-Reply-To: <4D2C6E09.8010705@brightok.net> References: , <4D2B365C.5070506@gmail.com>, <61EC3786-5732-4C5A-8938-A15E840DC75B@oicr.on.ca>, <4D2C6E09.8010705@brightok.net> Message-ID: <4D2C8553.3050901@rollernet.us> On 1/11/11 6:49 AM, Jack Bates wrote: > > To be honest, I use smartnet to upgrade the OS. I quit calling TAC after > they failed to understand, much less help me with my eigrp over frame > relay with automatic ISDN backup on route failure and re-establishment > of eigrp over the ISDN. :) > The cisco-nsp mailing list is often much more helpful than TAC. ~Seth From Valdis.Kletnieks at vt.edu Tue Jan 11 10:57:12 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 11 Jan 2011 11:57:12 -0500 Subject: NIST IPv6 document In-Reply-To: Your message of "Mon, 10 Jan 2011 22:22:32 CST." <4D2BDB08.7030701@brightok.net> References: <201101061429.p06ETB7g096271@aurora.sol.net> <201101101452.56885.lowen@pari.edu> <4D2BA2D6.3070500@utc.edu> <10091.1294705988@localhost> <4D2BDB08.7030701@brightok.net> Message-ID: <15170.1294765032@localhost> On Mon, 10 Jan 2011 22:22:32 CST, Jack Bates said: > Really? Which machine was using the privacy extension address on the > /64? I don't see how it's made it any easier to track. In some ways, on > provider edges that don't support DHCPv6 IA_TA and relay on slaac, it's > one extra nightmare. The same exact way you currently track down an IP address that some machine has started using without bothering to ask your DHCP server for an allocation, of course. Remember - the privacy extension was so that somebody far away on the Internet couldn't easily correlate "all these hits on websites were from the same box". It gives a user approximately *zero* protection against their own ISP dumping the ARP tables off every switch 5 minutes and keeping the data handy in case they have to track a specific MAC or IP address down. And if you know how to do that sort of thing for rogue/unexpected stuff on IPv4, doing it for IPv6 is trivial. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jbates at brightok.net Tue Jan 11 11:10:47 2011 From: jbates at brightok.net (Jack Bates) Date: Tue, 11 Jan 2011 11:10:47 -0600 Subject: NIST IPv6 document In-Reply-To: <15170.1294765032@localhost> References: <201101061429.p06ETB7g096271@aurora.sol.net> <201101101452.56885.lowen@pari.edu> <4D2BA2D6.3070500@utc.edu> <10091.1294705988@localhost> <4D2BDB08.7030701@brightok.net> <15170.1294765032@localhost> Message-ID: <4D2C8F17.4090006@brightok.net> On 1/11/2011 10:57 AM, Valdis.Kletnieks at vt.edu wrote: > The same exact way you currently track down an IP address that some machine has > started using without bothering to ask your DHCP server for an allocation, of course. > But it's no easier. Especially when you hit the customer equipment. NAT may be gone there, but knowing which computer it is will likely be impossible (as it won't be standard policy for the customer to grab arp tables). > Remember - the privacy extension was so that somebody far away on the Internet > couldn't easily correlate "all these hits on websites were from the same box". > It gives a user approximately *zero* protection against their own ISP dumping > the ARP tables off every switch 5 minutes and keeping the data handy in case > they have to track a specific MAC or IP address down. > I dislike this method, though. It works, but I much prefer to correlate with radius accounting logs backended on a DHCP server. Sadly, even in v4, implementations are not always available. Of course, I don't run NAT at the provider edge, but customer's often do, and while I will be able to track the customer, knowing which machine will be just as impossible as it is with NAT. Jack From mloftis at wgops.com Tue Jan 11 12:45:41 2011 From: mloftis at wgops.com (Michael Loftis) Date: Tue, 11 Jan 2011 11:45:41 -0700 Subject: IPv6 - real vs theoretical problems In-Reply-To: <70A7A45E-6685-4584-BA71-8B25F0EA09BF@delong.com> References: <4D269D77.4080309@jima.tk> <10FB3518-6470-4F14-963C-B3150FABE667@delong.com> <70A7A45E-6685-4584-BA71-8B25F0EA09BF@delong.com> Message-ID: On Fri, Jan 7, 2011 at 3:44 PM, Owen DeLong wrote: > There are multiple purposes to /48s to residential end users. > > DHCP-PD allows a lot of future innovations not yet available. > > ? ? ? ?Imagine a house where the border router receives a /48 > ? ? ? ?from the ISP and delegates /64s or /60s or whatever to > ? ? ? ?other routers within the house. > > ? ? ? ?Each home entertainment cluster may be one group of > ? ? ? ?networks with its own router. > > ? ? ? ?The appliance network(s) may have their own router(s). > > ? ? ? ?RFID tags on groceries may lead to a time when your > ? ? ? ?home automation server can gather up data from your > ? ? ? ?refrigerator, pantries, etc. and present the inventory > ? ? ? ?on your mobile phone while you're at the grocery store. > ? ? ? ?No more need to maintain a shopping list, just query > ? ? ? ?the inventory from the store. > > These are just the things that could easily be done with the > technology we already know about. Imagine what we might > think of once we get more used to having prefix abundance. Having more address space won't help most of these uses, and as for why, take a look at the proposed situation with for example home media serving/sharing systems by TiVo, Apple, etc. They all require that the units be within the same broadcast domain or that there be a configured bridge of some sort if they even allow that topology. They (actually rightfully) assume that the network topology is flat, single broadcast domain, and mroe and more use Multicast DNS (which I've seen called a bunch of different things) More to the point, your average home user can not technically fathom anything more complicated than "plug it in" -- and many begin to fail to set something up properly when its extended to something as complicated as "plug it in, push a button" or "plug it in, type some numbers into the device" Your average home user has no reason at all for anything more than a PtP to his/her gateway, and a single prefix routed to that gateway. There are most certainly a few (which includes I'm sure 99% of the NANOGers!) subscribers who can and will use more space than that, and ISPs most definitely should make /48s readily and easily available for those customers, but giving each and every customer a /48 (or really, even a pair of /64s, one for the PtP, one delegated) is almost certainly overkill. The devices won't use the extra space unless there's some automagic way of them communicating the desire to eachother, and appropriately configuring themselves, and it would have to be very widely accepted. But there's no technical gain. A typical household would probably have less than about 50, maybe 100 devices, even if we start networking appliances like toasters, hair dryers and every single radio, tv, and light switch. Just my 2 cents worth. From owen at delong.com Tue Jan 11 12:51:16 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 11 Jan 2011 10:51:16 -0800 Subject: arin and ops fora (was Re: AltDB?) In-Reply-To: <4D2C65F3.9050200@brightok.net> References: <94F3F129-608E-46EC-B157-CC23CAA47454@tozz.net> <4D24A734.3000807@jcoley.net> <816AB912-14CF-4028-853A-F0BE77D2EB09@puck.nether.net> <734B46C1-AE6C-406A-8163-00CFFE942B1B@virtualized.org> <000101cbaf42$0a65d7e0$1f3187a0$@org> <55EF24AC-DFFC-4A84-B828-693F0A1864A9@virtualized.org> <002d01cbb01b$eaa07160$bfe15420$@org> <4D2C65F3.9050200@brightok.net> Message-ID: <5297CF29-5D98-4D90-8FBD-68B088940FD2@delong.com> On Jan 11, 2011, at 6:15 AM, Jack Bates wrote: > On 1/11/2011 12:57 AM, David Conrad wrote: >> Or not. It may be that network operators (not just the ones that show up at ARIN meetings and are on PPML) are happy with the existing communication channels and that additional structures to encourage participation and input in the ARIN region regarding services ARIN provides to the public are unnecessary. >> > > Public easily reachable people. Public information on operations and what they do on their website with tons of pointers (even if it's not laid out the best). Public participation mailing lists. Presence of key people on other lists such as nanog. > > What more is an org supposed to do to communicate with people? Even the CEO lurks on nanog and responds when necessary. What community were you wanting them to interface with? I could be wrong, but I suspect any genius ideas which the CEO hears via the various communication mediums may quickly find it's way to be implemented. Sure, it may get restricted to some degree depending on how people in PPML feel about it. I'm sure the membership has some say on how their money is spent. Neither of these things limit the ability to suggest an idea. > > > Jack Just to be clear... Participation in PPML is open to ANYONE, not just ARIN members. There are a lot of non-members on PPML and their voices count just as much as members on that list. Owen From gbonser at seven.com Tue Jan 11 13:05:06 2011 From: gbonser at seven.com (George Bonser) Date: Tue, 11 Jan 2011 11:05:06 -0800 Subject: IPv6 - real vs theoretical problems In-Reply-To: References: <4D269D77.4080309@jima.tk><10FB3518-6470-4F14-963C-B3150FABE667@delong.com><70A7A45E-6685-4584-BA71-8B25F0EA09BF@delong.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC132DC@RWC-EX1.corp.seven.com> > From: Michael Loftis > Sent: Tuesday, January 11, 2011 10:46 AM > To: nanog > Subject: Re: IPv6 - real vs theoretical problems > Your average home user has no reason at all for anything more than a > PtP to his/her gateway, and a single prefix routed to that gateway. > There are most certainly a few (which includes I'm sure 99% of the > NANOGers!) subscribers who can and will use more space than that, and > ISPs most definitely should make /48s readily and easily available for > those customers, but giving each and every customer a /48 (or really, > even a pair of /64s, one for the PtP, one delegated) is almost > certainly overkill. The devices won't use the extra space unless > there's some automagic way of them communicating the desire to > eachother, and appropriately configuring themselves, and it would have > to be very widely accepted. But there's no technical gain. A typical > household would probably have less than about 50, maybe 100 devices, > even if we start networking appliances like toasters, hair dryers and > every single radio, tv, and light switch. > > Just my 2 cents worth. And what is to say that some devices won't have several different IPs? Maybe a different subnet is associated with each individual in the household when getting their voicemail or making DVR recordings or whatever. And I might want the stuff in my garage on a different subnet that the stuff in my living room because it has different access policy. To say " Your average home user has no reason at all ..." seems like saying the average user will have no reason at all to need more than 640K of RAM. Many of us are looking at things from today's perspective. Maybe each room of my house will have its own subnet with a low power access point and I can find which room something is in by the IP address it has. I have no idea, but do believe there is no reason to be restrictive in network assignments with v6. From jbates at brightok.net Tue Jan 11 13:15:58 2011 From: jbates at brightok.net (Jack Bates) Date: Tue, 11 Jan 2011 13:15:58 -0600 Subject: IPv6 - real vs theoretical problems In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC132DC@RWC-EX1.corp.seven.com> References: <4D269D77.4080309@jima.tk><10FB3518-6470-4F14-963C-B3150FABE667@delong.com><70A7A45E-6685-4584-BA71-8B25F0EA09BF@delong.com> <5A6D953473350C4B9995546AFE9939EE0BC132DC@RWC-EX1.corp.seven.com> Message-ID: <4D2CAC6E.5070108@brightok.net> On 1/11/2011 1:05 PM, George Bonser wrote: > Many of us are looking at things from today's > perspective. Maybe each room of my house will have its own subnet with > a low power access point and I can find which room something is in by > the IP address it has. Today, there are several vendors who believe the wireless part of their cpe should be a different subnet than the ethernet. There are multiple cases of stacked routers in homes, which requires multiple DHCPv6-PD delegations, and the current philosophy is very wasteful (as DHCPv6 itself doesn't support variable sized requests, chained requesting, and other options which would make it efficient for a requesting router 3 routers away from the initial DHCPv6 server). Jack From heather.schiller at verizonbusiness.com Tue Jan 11 13:22:47 2011 From: heather.schiller at verizonbusiness.com (Schiller, Heather A) Date: Tue, 11 Jan 2011 19:22:47 +0000 Subject: Agenda for Miami Message-ID: Hopefully posted soonish? Less than 3 weeks to the meeting, the early registration window has passed and there is still no agenda. Thanks, --h ~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~* Heather Schiller Network Security - Verizon Business 1.800.900.0241 security at verizonbusiness.com From owen at delong.com Tue Jan 11 13:31:43 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 11 Jan 2011 11:31:43 -0800 Subject: IPv6 - real vs theoretical problems In-Reply-To: References: <4D269D77.4080309@jima.tk> <10FB3518-6470-4F14-963C-B3150FABE667@delong.com> <70A7A45E-6685-4584-BA71-8B25F0EA09BF@delong.com> Message-ID: On Jan 11, 2011, at 10:45 AM, Michael Loftis wrote: > On Fri, Jan 7, 2011 at 3:44 PM, Owen DeLong wrote: > >> There are multiple purposes to /48s to residential end users. >> >> DHCP-PD allows a lot of future innovations not yet available. >> >> Imagine a house where the border router receives a /48 >> from the ISP and delegates /64s or /60s or whatever to >> other routers within the house. >> >> Each home entertainment cluster may be one group of >> networks with its own router. >> >> The appliance network(s) may have their own router(s). >> >> RFID tags on groceries may lead to a time when your >> home automation server can gather up data from your >> refrigerator, pantries, etc. and present the inventory >> on your mobile phone while you're at the grocery store. >> No more need to maintain a shopping list, just query >> the inventory from the store. >> >> These are just the things that could easily be done with the >> technology we already know about. Imagine what we might >> think of once we get more used to having prefix abundance. > > > Having more address space won't help most of these uses, and as for > why, take a look at the proposed situation with for example home media Yes, it will... > serving/sharing systems by TiVo, Apple, etc. They all require that the > units be within the same broadcast domain or that there be a > configured bridge of some sort if they even allow that topology. They That is the current state of the art which is the direct result of the lack of address space and the lack of the features I am describing making this absolutely necessarily. > (actually rightfully) assume that the network topology is flat, single > broadcast domain, and mroe and more use Multicast DNS (which I've seen Yes, that assumption is valid today. Future technology can change that assumption in useful and meaningful ways. > called a bunch of different things) More to the point, your average > home user can not technically fathom anything more complicated than > "plug it in" -- and many begin to fail to set something up properly > when its extended to something as complicated as "plug it in, push a > button" or "plug it in, type some numbers into the device" DHCP-PD will allow for hierarchical topology that is not more complicated than "plug it in". No button push, no typing something in. Literally plug it in. > > Your average home user has no reason at all for anything more than a > PtP to his/her gateway, and a single prefix routed to that gateway. Correct. I'm just saying that prefix should be a /48 so that the gateway can work with the other gateways inside the house to designate the best topology within the house. Note, this is all automated. It doesn't require the end-user to actually do anything other than plug it in. > There are most certainly a few (which includes I'm sure 99% of the > NANOGers!) subscribers who can and will use more space than that, and > ISPs most definitely should make /48s readily and easily available for > those customers, but giving each and every customer a /48 (or really, > even a pair of /64s, one for the PtP, one delegated) is almost > certainly overkill. The devices won't use the extra space unless That is today only thinking. Toss out your IPv4 scarcity-based assumptions about what is possible. IPv6 does have new features and new capabilities that we are just beginning to consider. > there's some automagic way of them communicating the desire to > eachother, and appropriately configuring themselves, and it would have > to be very widely accepted. But there's no technical gain. A typical It's called DHCPv6-PD and it already exists. That's the point!! > household would probably have less than about 50, maybe 100 devices, > even if we start networking appliances like toasters, hair dryers and > every single radio, tv, and light switch. > It's not about the number of devices. That's IPv4-think. It's about the number of segments. I see a world where each home-entertainment cluster would be a separate segment (today, few things use IP, but, future HE solutions will include Monitors, Amps, Blu-Ray players, and other Media gateways that ALL have ethernet ports for control and software update). The kitchen appliances would probably have their own segment. A refrigerator or pantry may have a front-end router that separates the household backbone from the network interfacing all the RFIDs contained within the device. I'm sure there are other examples where automated segmentation of the network can, does, and will make sense. We're just starting to explore this. The point is to have address delegation policies which don't interfere with this development. > Just my 2 cents worth. I'll see your $0.02 and raise you $0.48 ;-) Owen From oberman at es.net Tue Jan 11 15:01:27 2011 From: oberman at es.net (Kevin Oberman) Date: Tue, 11 Jan 2011 13:01:27 -0800 Subject: Agenda for Miami In-Reply-To: Your message of "Tue, 11 Jan 2011 19:22:47 GMT." Message-ID: <20110111210127.92B9B1CC09@ptavv.es.net> > Date: Tue, 11 Jan 2011 19:22:47 +0000 > From: "Schiller, Heather A" > > Hopefully posted soonish? Less than 3 weeks to the meeting, the early > registration window has passed and there is still no agenda. Heather, Yes, the holidays and the collision with Internet2 Joint Techs has slowed down the process. The PC is meeting on Thursday to pretty much finalize the agenda and I hope it will be available this week. -- R. Kevin Oberman, Network Engineer NANOG Program Committee From tariq198487 at hotmail.com Wed Jan 12 07:39:25 2011 From: tariq198487 at hotmail.com (Tarig Ahmed) Date: Wed, 12 Jan 2011 13:39:25 -0000 Subject: Is NAT can provide some kind of protection? Message-ID: We have wide range of Public IP addresses, I tried to assign public ip directly to a server behined firewall( in DMZ), but I have been resisted. Security guy told me is not correct to assign public ip to a server, it should have private ip for security reasons. Is it true that NAT can provide more security? Thanks, Tarig Yassin Ahmed From nick at foobar.org Wed Jan 12 07:59:22 2011 From: nick at foobar.org (Nick Hilliard) Date: Wed, 12 Jan 2011 13:59:22 +0000 Subject: Is NAT can provide some kind of protection? In-Reply-To: References: Message-ID: <4D2DB3BA.90308@foobar.org> On 21/03/2007 09:41, Tarig Ahmed wrote: > Is it true that NAT can provide more security? No. Your security person is probably confusing NAT with firewalling, as NAT devices will intrinsically do firewalling of various forms, sometimes stateful, sometimes not. Stateful firewalling _may_ provide more security in some situations for low bandwidth applications, at least before you're hit by a DoS attack; for high bandwidth applications, stateful firewalling is usually a complete waste of time. Your security guy will probably say that a private IP address will give better protection because it's not reachable on the internet. But the reality is if you have 1:1 NAT to a server port, then you have reachability and his argument becomes substantially invalid. Most security problems are going to be related to poor coding anyway (XSS, improper data validation, etc), rather than port reachability, which is easy to fix. Unfortunately, many security people from large organisations do not appreciate these arguments, but instead write their own and other peoples' opinions down and call them "policy". Changing policy can be difficult. Nick From tariq198487 at hotmail.com Wed Jan 12 08:23:30 2011 From: tariq198487 at hotmail.com (Tarig Ahmed) Date: Wed, 12 Jan 2011 14:23:30 -0000 Subject: Is NAT can provide some kind of protection? In-Reply-To: <4D2DB3BA.90308@foobar.org> References: <4D2DB3BA.90308@foobar.org> Message-ID: In fact our firewall is stateful. This is why I thought, we no need to Nat at least our servers. Tarig Yassin Ahmed On Jan 12, 2011, at 4:59 PM, Nick Hilliard wrote: > On 21/03/2007 09:41, Tarig Ahmed wrote: >> Is it true that NAT can provide more security? > > No. > > Your security person is probably confusing NAT with firewalling, as > NAT devices will intrinsically do firewalling of various forms, > sometimes stateful, sometimes not. Stateful firewalling _may_ > provide more security in some situations for low bandwidth > applications, at least before you're hit by a DoS attack; for high > bandwidth applications, stateful firewalling is usually a complete > waste of time. > > Your security guy will probably say that a private IP address will > give better protection because it's not reachable on the internet. > But the reality is if you have 1:1 NAT to a server port, then you > have reachability and his argument becomes substantially invalid. > Most security problems are going to be related to poor coding anyway > (XSS, improper data validation, etc), rather than port reachability, > which is easy to fix. > > Unfortunately, many security people from large organisations do not > appreciate these arguments, but instead write their own and other > peoples' opinions down and call them "policy". Changing policy can > be difficult. > > Nick > > From Timothy.Green at ManTech.com Wed Jan 12 08:41:15 2011 From: Timothy.Green at ManTech.com (Green, Timothy) Date: Wed, 12 Jan 2011 09:41:15 -0500 Subject: Cisco Sanitization Message-ID: Hey all! I'm currently creating a sanitization guide for all my hardware. When I got to my Cisco devices I noticed there are numerous ways to reset them back to the default and clear the NVRAM. Does anyone have a guide that includes sanitization information for all Cisco devices(at least switches, routers, IDS's, and ASA 5500 Series) so I don't have to recreate the wheel? Thanks, Tim From Greg.Whynott at oicr.on.ca Wed Jan 12 08:48:40 2011 From: Greg.Whynott at oicr.on.ca (Greg Whynott) Date: Wed, 12 Jan 2011 09:48:40 -0500 Subject: Fw: Cisco Sanitization Message-ID: V ----- Original Message ----- From: Greg Whynott Sent: Wednesday, January 12, 2011 09:46 AM To: 'Timothy.Green at ManTech.com' Subject: Re: Cisco Sanitization Replace the flash cards. If you are really concerned about information being disclosed, formatting/deleting files will not destroy the data and it probably can be recovered. Or take the flash cards and scrub them from a pc. G ----- Original Message ----- From: Green, Timothy [mailto:Timothy.Green at ManTech.com] Sent: Wednesday, January 12, 2011 09:41 AM To: nanog at nanog.org Subject: Cisco Sanitization Hey all! I'm currently creating a sanitization guide for all my hardware. When I got to my Cisco devices I noticed there are numerous ways to reset them back to the default and clear the NVRAM. Does anyone have a guide that includes sanitization information for all Cisco devices(at least switches, routers, IDS's, and ASA 5500 Series) so I don't have to recreate the wheel? Thanks, Tim -- This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization. From ml at kenweb.org Wed Jan 12 08:52:39 2011 From: ml at kenweb.org (ML) Date: Wed, 12 Jan 2011 09:52:39 -0500 Subject: Is NAT can provide some kind of protection? In-Reply-To: References: <4D2DB3BA.90308@foobar.org> Message-ID: <4D2DC037.3050303@kenweb.org> On 3/21/2007 6:25 AM, Tarig Ahmed wrote: > In fact our firewall is stateful. > This is why I thought, we no need to Nat at least our servers. > > > Tarig Yassin Ahmed > > > On Jan 12, 2011, at 4:59 PM, Nick Hilliard wrote: > >> On 21/03/2007 09:41, Tarig Ahmed wrote: >>> Is it true that NAT can provide more security? >> >> No. >> >> Your security person is probably confusing NAT with firewalling, as >> NAT devices will intrinsically do firewalling of various forms, >> sometimes stateful, sometimes not. Stateful firewalling _may_ provide >> more security in some situations for low bandwidth applications, at >> least before you're hit by a DoS attack; for high bandwidth >> applications, stateful firewalling is usually a complete waste of time. >> >> Your security guy will probably say that a private IP address will >> give better protection because it's not reachable on the internet. But >> the reality is if you have 1:1 NAT to a server port, then you have >> reachability and his argument becomes substantially invalid. Most >> security problems are going to be related to poor coding anyway (XSS, >> improper data validation, etc), rather than port reachability, which >> is easy to fix. >> >> Unfortunately, many security people from large organisations do not >> appreciate these arguments, but instead write their own and other >> peoples' opinions down and call them "policy". Changing policy can be >> difficult. >> >> Nick >> >> > Tarig is sending email from the past. Spooky. From jco at direwolf.com Wed Jan 12 08:58:24 2011 From: jco at direwolf.com (John Orthoefer) Date: Wed, 12 Jan 2011 09:58:24 -0500 Subject: Cisco Sanitization In-Reply-To: References: Message-ID: Really the only way to to clean devices with flash is to destroy the flash. At a very least you'll need to reflash them with the current OS. Here is a copy of the DOD Guidelines for every thing... http://it.ouhsc.edu/policies/documents/infosecurity/DoD_5220.pdf The flash answer is to use something to write to EVERY address, then erase, or just pulverize it. johno On Jan 12, 2011, at 9:41 AM, Green, Timothy wrote: > Hey all! > > I'm currently creating a sanitization guide for all my hardware. When I got to my Cisco devices I noticed there are numerous ways to reset them back to the default and clear the NVRAM. Does anyone have a guide that includes sanitization information for all Cisco devices(at least switches, routers, IDS's, and ASA 5500 Series) so I don't have to recreate the wheel? > > Thanks, > > Tim > > From ljakab at ac.upc.edu Wed Jan 12 09:01:15 2011 From: ljakab at ac.upc.edu (=?ISO-8859-1?Q?Lor=E1nd_Jakab?=) Date: Wed, 12 Jan 2011 16:01:15 +0100 Subject: Is NAT can provide some kind of protection? In-Reply-To: <4D2DB3BA.90308@foobar.org> References: <4D2DB3BA.90308@foobar.org> Message-ID: <4D2DC23B.5080707@ac.upc.edu> On 01/12/2011 02:59 PM, Nick Hilliard wrote: > On 21/03/2007 09:41, Tarig Ahmed wrote: >> Is it true that NAT can provide more security? > > No. > > [snip] > > Your security guy will probably say that a private IP address will > give better protection because it's not reachable on the internet. > But the reality is if you have 1:1 NAT to a server port, then you have > reachability and his argument becomes substantially invalid. This setup will provide *less* security. Apart from the DoS scenario, should your public facing server get compromised, you have given easy access to your private infrastructure. -Lorand Jakab From swm at emanon.com Wed Jan 12 09:01:48 2011 From: swm at emanon.com (Scott Morris) Date: Wed, 12 Jan 2011 10:01:48 -0500 Subject: Fw: Cisco Sanitization In-Reply-To: References: Message-ID: <4D2DC25C.9020307@emanon.com> Or why not just paste a REALLY large bogus config in there to max-out the NVRAM chip? That's the one that's harder to move to a PC. On the flash, moving to a PC is easier (at least if we're talking about newer devices using PCMCIA!) :) I suppose that everyone's level of detail is somewhat equivalent to the level of paranoia or level of desired protection along the way! Scott On 1/12/11 9:48 AM, Greg Whynott wrote: > V > > ----- Original Message ----- > From: Greg Whynott > Sent: Wednesday, January 12, 2011 09:46 AM > To: 'Timothy.Green at ManTech.com' > Subject: Re: Cisco Sanitization > > Replace the flash cards. If you are really concerned about information being disclosed, formatting/deleting files will not destroy the data and it probably can be recovered. Or take the flash cards and scrub them from a pc. > > G > > ----- Original Message ----- > From: Green, Timothy [mailto:Timothy.Green at ManTech.com] > Sent: Wednesday, January 12, 2011 09:41 AM > To: nanog at nanog.org > Subject: Cisco Sanitization > > Hey all! > > I'm currently creating a sanitization guide for all my hardware. When I got to my Cisco devices I noticed there are numerous ways to reset them back to the default and clear the NVRAM. Does anyone have a guide that includes sanitization information for all Cisco devices(at least switches, routers, IDS's, and ASA 5500 Series) so I don't have to recreate the wheel? > > Thanks, > > Tim > > > > -- > > This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization. > > > From os10rules at gmail.com Wed Jan 12 09:36:37 2011 From: os10rules at gmail.com (Greg Ihnen) Date: Wed, 12 Jan 2011 11:06:37 -0430 Subject: Is NAT can provide some kind of protection? In-Reply-To: References: <4D2DB3BA.90308@foobar.org> Message-ID: +1 on Nick's comment. If you're doing 1:1 NAT or port forwarding your server is still public facing. If your firewall is merely stateful and not deep packet inspecting all it's doing is seeing is that the statefulness of the connection meets it's requirements. You could have that and still have all kinds of naughtiness going on. Greg On Mar 21, 2007, at 6:25 AM, Tarig Ahmed wrote: > In fact our firewall is stateful. > This is why I thought, we no need to Nat at least our servers. > > > Tarig Yassin Ahmed > > > On Jan 12, 2011, at 4:59 PM, Nick Hilliard wrote: > >> On 21/03/2007 09:41, Tarig Ahmed wrote: >>> Is it true that NAT can provide more security? >> >> No. >> >> Your security person is probably confusing NAT with firewalling, as NAT devices will intrinsically do firewalling of various forms, sometimes stateful, sometimes not. Stateful firewalling _may_ provide more security in some situations for low bandwidth applications, at least before you're hit by a DoS attack; for high bandwidth applications, stateful firewalling is usually a complete waste of time. >> >> Your security guy will probably say that a private IP address will give better protection because it's not reachable on the internet. But the reality is if you have 1:1 NAT to a server port, then you have reachability and his argument becomes substantially invalid. Most security problems are going to be related to poor coding anyway (XSS, improper data validation, etc), rather than port reachability, which is easy to fix. >> >> Unfortunately, many security people from large organisations do not appreciate these arguments, but instead write their own and other peoples' opinions down and call them "policy". Changing policy can be difficult. >> >> Nick >> >> > From Greg.Whynott at oicr.on.ca Wed Jan 12 10:04:58 2011 From: Greg.Whynott at oicr.on.ca (Greg Whynott) Date: Wed, 12 Jan 2011 11:04:58 -0500 Subject: Cisco Sanitization In-Reply-To: References: Message-ID: <1B5DDAEC-F6B2-404B-AD45-0B8AB787B76D@oicr.on.ca> list, sorry for this but this is getting a little annoying. I've tried sending Randy email without luck.. think i'm black listed by his kit, so if someone would kindly forward this to him? Randy, I'm not trying to be difficult or annoy you. Please stop sending me this email which is considered spam by most. 30 messages of with the same unsolicited content is spam. I understand you do not like a signature which 'seems' to contain legal jargon. I understand you know everything about my environment and the policies of my company which I do not define. I undertand you would like me to use gmail and violate my company policy. I don't expect _anything_ from you, but i would appreciate it if you could take some of your apparent talent and put some logic into your proc mail recipe or whatever it is you use to to generate this message. avoid responding with this spam message every time i post to a list you happen to be on. The email was not directed to you directly. should take about someone with your skill set very little effort. thank you. greg On Jan 12, 2011, at 10:50 AM, Randy Bush wrote: > you have sent a message to me which seems to contain a legal > warning on who can read it, or how it may be distributed, or > whether it may be archived, etc. > > i do not accept such email. my mail user agent detected a legal > notice when i was opening your mail, and automatically deleted it. > so do not expect further response. > > yes, i know your mail environment automatically added the legal > notice. well, my mail environment automatically detected it, > deleted it, and sent this message to you. so don't expect a lot > of sympathy. > > and if you choose to work for some enterprise clueless enough to > think that they can force this silliness on the world, use gmail, > hotmail, ... > > randy -- This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization. From gbonser at seven.com Wed Jan 12 10:17:26 2011 From: gbonser at seven.com (George Bonser) Date: Wed, 12 Jan 2011 08:17:26 -0800 Subject: Is NAT can provide some kind of protection? In-Reply-To: References: Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC132F0@RWC-EX1.corp.seven.com> > > Is it true that NAT can provide more security? > > Thanks, > > Tarig Yassin Ahmed > You are going to get different answers from different people. In and of itself it doesn't provide security but it does place one more layer of difficulty in getting at your internal machines. On the other hand, NAT makes many things a lot more difficult than they need to be in many cases and outright breaks some protocols (SCTP, for example). On one hand, yes, it can make direct addressing of your servers more difficult but doesn't guarantee anything. RFC1918 routes should not be routed over the internet but sometimes people "leak" them and sometimes people accept such leaked routes. So there is the possibility that someone could "see" a route to your RFC1918 space. But on the other hand, even if you did "leak" the route, the odds of someone being able to reliably connect to your network is pretty low because if they are accepting such leaked routes from you, they might be accepting them from others, too. And your upstream's peers are probably filtering 1918 space and most likely route traffic destined to rfc1918 space they aren't using to a black hole. But your security person needs to shift their thinking because the purpose of NAT and private addressing is to conserve IP address, not to provide security. With IPv6, the concept of NAT goes away. You servers will need public IP addresses if they are going to transact information across the Internet. So the "security" concerns of public IP space are moot when it comes to IPv6. From shrdlu at deaddrop.org Wed Jan 12 10:19:56 2011 From: shrdlu at deaddrop.org (Lynda) Date: Wed, 12 Jan 2011 08:19:56 -0800 Subject: Cisco Sanitization In-Reply-To: <1B5DDAEC-F6B2-404B-AD45-0B8AB787B76D@oicr.on.ca> References: <1B5DDAEC-F6B2-404B-AD45-0B8AB787B76D@oicr.on.ca> Message-ID: <4D2DD4AC.7040406@deaddrop.org> On 1/12/2011 8:04 AM, Greg Whynott wrote: > list, sorry for this but this is getting a little annoying. I've > tried sending Randy email without luck.. think i'm black listed by > his kit, so if someone would kindly forward this to him? Well, here it is. Perhaps you might consider getting a gmail or other account, and posting on NANOG from there. Either that, or filter Randy out. Personally, I find those silly disclaimers annoying, but am far too lazy to set up a script such as Randy has. You don't want to be annoyed? Lose the disclaimer, use a different email address, or filter Randy out. This is NOT the first time you've complained about this (although we know, for sure, that Randy is going to send this off, automagically, to anyone that has the silly disclaimer thing going for them). Get over it. Please don't post on this again. Thanks in advance. -- Amor fati. Vale. (Seneca) From Greg.Whynott at oicr.on.ca Wed Jan 12 10:45:42 2011 From: Greg.Whynott at oicr.on.ca (Greg Whynott) Date: Wed, 12 Jan 2011 11:45:42 -0500 Subject: Cisco Sanitization In-Reply-To: <4D2DD4AC.7040406@deaddrop.org> References: <1B5DDAEC-F6B2-404B-AD45-0B8AB787B76D@oicr.on.ca> <4D2DD4AC.7040406@deaddrop.org> Message-ID: <2C622B9A-E38F-4DEB-99BD-CB5D4696D8B7@oicr.on.ca> my bad list, i'll stay on topic in the future and ensure i keep personal messages out of here and your inbox. bad bad greg? interesting how brain dead and un respectful i am till sufficiently caffeinated. On Jan 12, 2011, at 11:19 AM, Lynda wrote: > On 1/12/2011 8:04 AM, Greg Whynott wrote: > >> list, sorry for this but this is getting a little annoying. I've >> tried sending Randy email without luck.. think i'm black listed by >> his kit, so if someone would kindly forward this to him? > > Well, here it is. Perhaps you might consider getting a gmail or other > account, and posting on NANOG from there. Either that, or filter Randy > out. Personally, I find those silly disclaimers annoying, but am far too > lazy to set up a script such as Randy has. > > You don't want to be annoyed? Lose the disclaimer, use a different email > address, or filter Randy out. This is NOT the first time you've > complained about this (although we know, for sure, that Randy is going > to send this off, automagically, to anyone that has the silly disclaimer > thing going for them). Get over it. Please don't post on this again. > Thanks in advance. > > -- > Amor fati. Vale. (Seneca) > > -- This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization. From fernando at gont.com.ar Wed Jan 12 10:54:18 2011 From: fernando at gont.com.ar (Fernando Gont) Date: Wed, 12 Jan 2011 13:54:18 -0300 Subject: Is NAT can provide some kind of protection? In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC132F0@RWC-EX1.corp.seven.com> References: <5A6D953473350C4B9995546AFE9939EE0BC132F0@RWC-EX1.corp.seven.com> Message-ID: <4D2DDCBA.1050304@gont.com.ar> On 12/01/2011 01:17 p.m., George Bonser wrote: > But your security person needs to shift their thinking because the > purpose of NAT and private addressing is to conserve IP address, not to > provide security. With IPv6, the concept of NAT goes away. You have heard about NAT66, right? Thanks, -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From nanog at jima.tk Wed Jan 12 10:59:35 2011 From: nanog at jima.tk (Jima) Date: Wed, 12 Jan 2011 10:59:35 -0600 Subject: IPv6 - real vs theoretical problems In-Reply-To: References: <4D269D77.4080309@jima.tk> <10FB3518-6470-4F14-963C-B3150FABE667@delong.com> <70A7A45E-6685-4584-BA71-8B25F0EA09BF@delong.com> Message-ID: <4D2DDDF7.3090104@jima.tk> On 01/11/2011 01:31 PM, Owen DeLong wrote: > It's not about the number of devices. That's IPv4-think. It's about the number > of segments. I see a world where each home-entertainment cluster would > be a separate segment (today, few things use IP, but, future HE solutions > will include Monitors, Amps, Blu-Ray players, and other Media gateways > that ALL have ethernet ports for control and software update). Your future is now, Owen. I have four network devices at my primary television -- the TV itself, TiVo, PS3, and Wii (using the wired adapter). All told, I have seven networked home entertainment devices in my house, with another (Blu-Ray player) likely coming soon. I feel confident in saying that my use case isn't unusual these days. While a lot of the scalability concerns are blown off as "not applying to typical consumers," we're quickly getting to the point where your average joe IS somewhat likely to have different classes of devices that might benefit from being on separate subnets. Jima From jay at miscreant.org Wed Jan 12 10:57:40 2011 From: jay at miscreant.org (Jay Mitchell) Date: Thu, 13 Jan 2011 03:57:40 +1100 Subject: Is NAT can provide some kind of protection? In-Reply-To: References: Message-ID: <158F603F-E983-4C7F-8870-0AEEBB9F5092@miscreant.org> Tell your security guy he should be looking for another job. On 21/03/2007, at 8:41 PM, Tarig Ahmed wrote: > We have wide range of Public IP addresses, I tried to assign public ip directly to a server behined firewall( in DMZ), but I have been resisted. > Security guy told me is not correct to assign public ip to a server, it should have private ip for security reasons. > > Is it true that NAT can provide more security? > > Thanks, > > Tarig Yassin Ahmed > > From gbonser at seven.com Wed Jan 12 11:01:27 2011 From: gbonser at seven.com (George Bonser) Date: Wed, 12 Jan 2011 09:01:27 -0800 Subject: Is NAT can provide some kind of protection? In-Reply-To: <4D2DDCBA.1050304@gont.com.ar> References: <5A6D953473350C4B9995546AFE9939EE0BC132F0@RWC-EX1.corp.seven.com> <4D2DDCBA.1050304@gont.com.ar> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC132F5@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Fernando Gont [mailto:fernando.gont.netbook.win at gmail.com] On > Behalf Of Fernando Gont > Sent: Wednesday, January 12, 2011 8:54 AM > To: George Bonser > Cc: Tarig Ahmed; nanog at nanog.org > Subject: Re: Is NAT can provide some kind of protection? > > On 12/01/2011 01:17 p.m., George Bonser wrote: > > > But your security person needs to shift their thinking because the > > purpose of NAT and private addressing is to conserve IP address, not > to > > provide security. With IPv6, the concept of NAT goes away. > > You have heard about NAT66, right? > > Thanks, > -- > Fernando Gont > e-mail: fernando at gont.com.ar || fgont at acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 Oh, yeah. But NAT66 does not provide the "security" aspect of PAT with V4. It is just a straight static NAT. So each of your machines is still directly addressable from the Internet. With v4 PAT, you can not be sure which address/port on the external IP maps to which address/port on the inside IP at any given moment and PAT is stateful in that an outbound packet is required to start the mapping. NAT66 is just straight static NAT that maps one prefix to a different prefix. From bill at herrin.us Wed Jan 12 11:04:01 2011 From: bill at herrin.us (William Herrin) Date: Wed, 12 Jan 2011 12:04:01 -0500 Subject: Is NAT can provide some kind of protection? In-Reply-To: References: Message-ID: On Wed, Mar 21, 2007 at 5:41 AM, Tarig Ahmed wrote: > We have wide range of Public IP addresses, I tried to assign public ip > directly to a server behined firewall( in DMZ), but I have been resisted. > Security guy told me is not correct to assign public ip to a server, it > should have private ip for security reasons. > > Is it true that NAT can provide more security? Hi Tarig, Yes NAT can provide more security, but not in the particular scenario you described. In your scenario, the firewall knows how to map incoming connections for the public address to your server's private address, so you won't see any benefit from NAT versus a merely stateful firewall -- a connection request will either get through the filter or it won't. If it gets through, the firewall knows where to send it. On the other hand, the use of any kind of stateful firewall (most of what we refer to as NAT firewalls keep per-connection state) increases your vulnerability to denial of services attacks: folks DOSing you can target both the server and the firewall's state table. So the use of NAT there is potentially counterproductive. In a client (rather than server) scenario, the picture is different. Depending on the specific "NAT" technology in use, the firewall may be incapable of selecting a target for unsolicited communications inbound from the public Internet. In fact, it may be theoretically impossible for it to do so. In those scenarios, the presence of NAT in the equation makes a large class of direct attacks on the interior host impractical, requiring the attacker to fall back on other methods like attempting to breach the firewall itself or indirectly polluting the responses to communication initiated by the internal host. In both cases there's a larger question: security value. The value of a security measure is the damage it prevents (risk times impact) minus the damage it causes (system usability, capability). NAT generally causes more damage than packet filters and other lighter-duty security measures. Look for an appropriate improvement in system security to counterbalance that damage. If you don't find it then don't use NAT. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jbates at brightok.net Wed Jan 12 11:07:24 2011 From: jbates at brightok.net (Jack Bates) Date: Wed, 12 Jan 2011 11:07:24 -0600 Subject: Is NAT can provide some kind of protection? In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC132F5@RWC-EX1.corp.seven.com> References: <5A6D953473350C4B9995546AFE9939EE0BC132F0@RWC-EX1.corp.seven.com> <4D2DDCBA.1050304@gont.com.ar> <5A6D953473350C4B9995546AFE9939EE0BC132F5@RWC-EX1.corp.seven.com> Message-ID: <4D2DDFCC.3020906@brightok.net> On 1/12/2011 11:01 AM, George Bonser wrote: > NAT66 is just > straight static NAT that maps one prefix to a different prefix. > I'd eat a hat if a vendor didn't implement a PAT equivalent. It's demanded too much. There is money for it, so it will be there. Jack From sethm at rollernet.us Wed Jan 12 11:10:40 2011 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 12 Jan 2011 09:10:40 -0800 Subject: Is NAT can provide some kind of protection? In-Reply-To: References: Message-ID: <4D2DE090.1000702@rollernet.us> On 3/21/07 2:41 AM, Tarig Ahmed wrote: > > Is it true that NAT can provide more security? > No. However, some things like PCI compliance require NAT, likely because of the "NAT = super hacker firewall" concept. ~Seth From Valdis.Kletnieks at vt.edu Wed Jan 12 11:12:10 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 12 Jan 2011 12:12:10 -0500 Subject: Is NAT can provide some kind of protection? In-Reply-To: Your message of "Wed, 12 Jan 2011 16:01:15 +0100." <4D2DC23B.5080707@ac.upc.edu> References: <4D2DB3BA.90308@foobar.org> <4D2DC23B.5080707@ac.upc.edu> Message-ID: <15026.1294852330@localhost> On Wed, 12 Jan 2011 16:01:15 +0100, =?ISO-8859-1?Q?Lor=E1nd_Jakab?= said: > This setup will provide *less* security. Apart from the DoS scenario, > should your public facing server get compromised, you have given easy > access to your private infrastructure. If a public server behind a NAT gets whacked via a php vulnerability, you've *still* given away access to everything behind the NAT that server can reach. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From Valdis.Kletnieks at vt.edu Wed Jan 12 11:16:27 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 12 Jan 2011 12:16:27 -0500 Subject: Is NAT can provide some kind of protection? In-Reply-To: Your message of "Wed, 12 Jan 2011 12:04:01 EST." References: Message-ID: <15191.1294852587@localhost> On Wed, 12 Jan 2011 12:04:01 EST, William Herrin said: > In a client (rather than server) scenario, the picture is different. > Depending on the specific "NAT" technology in use, the firewall may be > incapable of selecting a target for unsolicited communications inbound > from the public Internet. In fact, it may be theoretically impossible > for it to do so. In those scenarios, the presence of NAT in the > equation makes a large class of direct attacks on the interior host > impractical, requiring the attacker to fall back on other methods like > attempting to breach the firewall itself or indirectly polluting the > responses to communication initiated by the internal host. Note that the presence of a firewall with a 'default deny' rule for inbound packets provides the same level of impracticality. And given the fact that Windows has had a reasonably sane host-based firewall since XP SP2, and the truly huge number of compromised PC's that sit behind a NAT on a DSL or cablemodem, it's pretty obvious that the presence of NAT is doing approximately *zero* to actually slow down the miscreants. 140 million compromised PC's, most of them behind a NAT, can't be wrong. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From gbonser at seven.com Wed Jan 12 11:21:39 2011 From: gbonser at seven.com (George Bonser) Date: Wed, 12 Jan 2011 09:21:39 -0800 Subject: Is NAT can provide some kind of protection? In-Reply-To: <4D2DDFCC.3020906@brightok.net> References: <5A6D953473350C4B9995546AFE9939EE0BC132F0@RWC-EX1.corp.seven.com> <4D2DDCBA.1050304@gont.com.ar> <5A6D953473350C4B9995546AFE9939EE0BC132F5@RWC-EX1.corp.seven.com> <4D2DDFCC.3020906@brightok.net> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC132F6@RWC-EX1.corp.seven.com> > > I'd eat a hat if a vendor didn't implement a PAT equivalent. It's > demanded too much. There is money for it, so it will be there. > > > Jack Yeah, I think you are right. But in really thinking about it, I wonder why. The whole point of PAT was address conservation. You don't need that with v6. All you need to do with v6 is basically have what amounts to a firewall in transparent mode in the line and doesn't let a packet in (except where explicitly configure to) unless it is associated with a packet that went out. PAT makes little sense to me for v6, but I suspect you are correct. In addition, we are putting the "fire suit" on each host in addition to the firewall. Kernel firewall rules on each host for the *nix boxen. From jbates at brightok.net Wed Jan 12 11:25:30 2011 From: jbates at brightok.net (Jack Bates) Date: Wed, 12 Jan 2011 11:25:30 -0600 Subject: Is NAT can provide some kind of protection? In-Reply-To: <15191.1294852587@localhost> References: <15191.1294852587@localhost> Message-ID: <4D2DE40A.1030406@brightok.net> On 1/12/2011 11:16 AM, Valdis.Kletnieks at vt.edu wrote: > > 140 million compromised PC's, most of them behind a NAT, can't be wrong. :) And yet blaster type worms are less common now, and I still get the occasional reinfection reported where a computer shop installs XP pre-patch with a public IP. A simple stateful firewall or NAT router would stop that and allow them to finish patching the OS. There is always a new attack vector. Jack From scott at doc.net.au Wed Jan 12 11:36:14 2011 From: scott at doc.net.au (Scott Howard) Date: Wed, 12 Jan 2011 09:36:14 -0800 Subject: World IPv6 Day Message-ID: >From http://www.networkworld.com/news/2011/011211-world-ipv6-day.html Several of the Internet's most popular Web sites - including Facebook, Google and Yahoo - have agreed to participate in the first global-scale trial of IPv6, the long-anticipated upgrade to the Internet's main communications protocol known as IPv4. The trial ? dubbed "World IPv6 Day" ? requires participants to support native IPv6 traffic on their main Web sites on June 8, 2011. Leading content delivery networks Akamai and Limelight Networks also committed to the IPv6 trial, which is being sponsored by the Internet Society. [...] Scott. From ted at fred.net Wed Jan 12 11:34:45 2011 From: ted at fred.net (Ted Fischer) Date: Wed, 12 Jan 2011 12:34:45 -0500 Subject: IPv6 - real vs theoretical problems In-Reply-To: <4D2DDDF7.3090104@jima.tk> References: <4D269D77.4080309@jima.tk> <10FB3518-6470-4F14-963C-B3150FABE667@delong.com> <70A7A45E-6685-4584-BA71-8B25F0EA09BF@delong.com> <4D2DDDF7.3090104@jima.tk> Message-ID: <20110112173645.3F4B210393B@mail-out06.xecu.net> At 11:59 AM 1/12/2011, Jim postulated wrote: >On 01/11/2011 01:31 PM, Owen DeLong wrote: > > It's not about the number of devices. That's IPv4-think. It's > about the number > > of segments. I see a world where each home-entertainment cluster would > > be a separate segment (today, few things use IP, but, future HE solutions > > will include Monitors, Amps, Blu-Ray players, and other Media gateways > > that ALL have ethernet ports for control and software update). > > Your future is now, Owen. I have four network devices at my primary >television -- the TV itself, TiVo, PS3, and Wii (using the wired >adapter). All told, I have seven networked home entertainment devices >in my house, with another (Blu-Ray player) likely coming soon. I feel >confident in saying that my use case isn't unusual these days. > > While a lot of the scalability concerns are blown off as "not applying >to typical consumers," we're quickly getting to the point where your >average joe IS somewhat likely to have different classes of devices that >might benefit from being on separate subnets. > > Jima I helped a friend setup his "home network" recently. He is using an old Linksys Router with no v6 support. I like to be conservative and only allocate what might be needed ... part of my "Defense in Depth" strategy to provide some layer of "security" with NAT (yes, I know - my security by obscurity is to use something from 172.16) and a limited amount of addresses to allocate (not to mention WPA2 - he had default no security when I first got there). Used to be a /29 would be sufficient for any home. But, before I knew it, he had a wireless printer, laptop, and 4 iPhones all needing the new wireless passphrase to connect, plus he was anticipating 2 more laptops (one each for his children - to whom 2 of the iPhones belonged), and addresses set aside for guests and the occasional business visitor (he works from home). I left him configured with a /28, and told him to call me if he anticipated more. As a side security note - we lost the laptop on the "new" secured network before I tracked down that it had automatically logged in to his neighbor's (also unprotected) network on reboot. Ted From jbates at brightok.net Wed Jan 12 11:36:48 2011 From: jbates at brightok.net (Jack Bates) Date: Wed, 12 Jan 2011 11:36:48 -0600 Subject: Is NAT can provide some kind of protection? In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC132F6@RWC-EX1.corp.seven.com> References: <5A6D953473350C4B9995546AFE9939EE0BC132F0@RWC-EX1.corp.seven.com> <4D2DDCBA.1050304@gont.com.ar> <5A6D953473350C4B9995546AFE9939EE0BC132F5@RWC-EX1.corp.seven.com> <4D2DDFCC.3020906@brightok.net> <5A6D953473350C4B9995546AFE9939EE0BC132F6@RWC-EX1.corp.seven.com> Message-ID: <4D2DE6B0.2010308@brightok.net> On 1/12/2011 11:21 AM, George Bonser wrote: > PAT makes little sense to me for v6, but I suspect you are correct. In > addition, we are putting the "fire suit" on each host in addition to the > firewall. Kernel firewall rules on each host for the *nix boxen. > As my corp IT guy put it to me, PAT forces a routing disconnect between internal and external. There is no way to reach the hosts without the firewall performing it's NAT function. Given that the internal is exclusively PAT, the DMZ is public with stateful/proxy, this provides protection for the internal network while limiting the dmz exposure. The argument everyone makes is that a stateful firewall defaults to deny. However, a single mistake prior to the deny allows traffic in. The only equivalent in a PAT scenario is to screw up port forwarding which would cause a single host to expose a single port unknowingly per mistake (which said port/host combo may not be vulnerable). In a stateful firewall, a screw up could expose all ports on a host or multiple hosts in a single mistake. Then there are the firewall software bugs. In PAT, such bugs don't suddenly expose all your hosts behind the firewall for direct communication from the outside world. In v6 stateful firewall, such a bug could allow circumvention of the entire firewall ruleset and the hosts would be directly addressable from the outside. PAT offers the smallest of security safeguards. However, many corp IT personnel feel more secure having that small safeguard in place along with the many other safeguards they deploy. In a corporate environment where they often love to break everything and anything, I don't blame them. Then we go to the educational sector, where the admins often prefer as much openness as possible. In their case, they will prefer to do away with PAT. Jack From nathan at atlasnetworks.us Wed Jan 12 11:52:15 2011 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Wed, 12 Jan 2011 17:52:15 +0000 Subject: Is NAT can provide some kind of protection? In-Reply-To: <4D2DE40A.1030406@brightok.net> References: <15191.1294852587@localhost> <4D2DE40A.1030406@brightok.net> Message-ID: <8C26A4FDAE599041A13EB499117D3C286B30FED9@ex-mb-1.corp.atlasnetworks.us> > And yet blaster type worms are less common now, and I still get the > occasional reinfection reported where a computer shop installs XP pre-patch > with a public IP. A simple stateful firewall or NAT router would stop that and > allow them to finish patching the OS. There is always a new attack vector. > > Jack I'd argue that the above has everything to do with firewalling, and nothing to do with NAT. Slightly OT: It boggles the mind a bit when I find desktop shops -not- using imaging. I would think most people would prefer not to stare at OS install screens - and when you can blast out a fully patched XP image easily in sub-10 minutes, the ROI is staggering. Nathan From skurylo+nanog at gmail.com Wed Jan 12 11:57:51 2011 From: skurylo+nanog at gmail.com (Steven Kurylo) Date: Wed, 12 Jan 2011 09:57:51 -0800 Subject: Is NAT can provide some kind of protection? In-Reply-To: <4D2DE6B0.2010308@brightok.net> References: <5A6D953473350C4B9995546AFE9939EE0BC132F0@RWC-EX1.corp.seven.com> <4D2DDCBA.1050304@gont.com.ar> <5A6D953473350C4B9995546AFE9939EE0BC132F5@RWC-EX1.corp.seven.com> <4D2DDFCC.3020906@brightok.net> <5A6D953473350C4B9995546AFE9939EE0BC132F6@RWC-EX1.corp.seven.com> <4D2DE6B0.2010308@brightok.net> Message-ID: On Wed, Jan 12, 2011 at 9:36 AM, Jack Bates wrote: > > As my corp IT guy put it to me, PAT forces a routing disconnect between > internal and external. There is no way to reach the hosts without the > firewall performing it's NAT function. But that's not true. If you have NAT, without a firewall, I can access your internal hosts (by addressing their RFC 1918 address) because you'll be leaking your RFC 1918 addresses in and out. Granted, I might have to be in your immediate upstream, but it can be done. So at best, all it does is limit how many hops away I need to be from you to attack you. Some benefit? Yes. Enough benefit to be worth the trouble? I personally am not convinced. Considering the amount of people who mistake the amount of security NAT provides, we're probably better off without it to remove that false sense of security. From jbates at brightok.net Wed Jan 12 11:58:16 2011 From: jbates at brightok.net (Jack Bates) Date: Wed, 12 Jan 2011 11:58:16 -0600 Subject: Is NAT can provide some kind of protection? In-Reply-To: <8C26A4FDAE599041A13EB499117D3C286B30FED9@ex-mb-1.corp.atlasnetworks.us> References: <15191.1294852587@localhost> <4D2DE40A.1030406@brightok.net> <8C26A4FDAE599041A13EB499117D3C286B30FED9@ex-mb-1.corp.atlasnetworks.us> Message-ID: <4D2DEBB8.8080208@brightok.net> On 1/12/2011 11:52 AM, Nathan Eisenberg wrote: > > I'd argue that the above has everything to do with firewalling, and nothing to do with NAT. > I agree, but both effectively handle the job. My point is that just because we have lots of infections behind NAT, doesn't mean that NAT (or a firewall) doesn't still serve a purpose. > Slightly OT: It boggles the mind a bit when I find desktop shops -not- using imaging. I would think most people would prefer not to stare at OS install screens - and when you can blast out a fully patched XP image easily in sub-10 minutes, the ROI is staggering. Hardware drivers? Jack From jbates at brightok.net Wed Jan 12 12:03:29 2011 From: jbates at brightok.net (Jack Bates) Date: Wed, 12 Jan 2011 12:03:29 -0600 Subject: Is NAT can provide some kind of protection? In-Reply-To: References: <5A6D953473350C4B9995546AFE9939EE0BC132F0@RWC-EX1.corp.seven.com> <4D2DDCBA.1050304@gont.com.ar> <5A6D953473350C4B9995546AFE9939EE0BC132F5@RWC-EX1.corp.seven.com> <4D2DDFCC.3020906@brightok.net> <5A6D953473350C4B9995546AFE9939EE0BC132F6@RWC-EX1.corp.seven.com> <4D2DE6B0.2010308@brightok.net> Message-ID: <4D2DECF1.5010201@brightok.net> On 1/12/2011 11:57 AM, Steven Kurylo wrote: > Some benefit? Yes. Enough benefit to be worth the trouble? I > personally am not convinced. > Some people believe it is. Who am I to tell them how to run their network? They block facebook and yahoo. I, unfortunately, can't. :) > Considering the amount of people who mistake the amount of security > NAT provides, we're probably better off without it to remove that > false sense of security. People will then have a false sense of security with stateful firewalls that perform no better than NAT, just without the address translation. The type of stateful firewall with or without address translation will not suddenly make people become wiser and implement better security policies. Vendors will always make a cheap setup which people will use and consider themselves secure. Jack From streiner at cluebyfour.org Wed Jan 12 09:00:11 2011 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Wed, 12 Jan 2011 10:00:11 -0500 (EST) Subject: Cisco Sanitization In-Reply-To: <4D2DD4AC.7040406@deaddrop.org> References: <1B5DDAEC-F6B2-404B-AD45-0B8AB787B76D@oicr.on.ca> <4D2DD4AC.7040406@deaddrop.org> Message-ID: On Wed, 12 Jan 2011, Lynda wrote: > On 1/12/2011 8:04 AM, Greg Whynott wrote: > >> list, sorry for this but this is getting a little annoying. I've >> tried sending Randy email without luck.. think i'm black listed by >> his kit, so if someone would kindly forward this to him? > > Well, here it is. Perhaps you might consider getting a gmail or other > account, and posting on NANOG from there. Either that, or filter Randy out. > Personally, I find those silly disclaimers annoying, but am far too lazy to > set up a script such as Randy has. > > You don't want to be annoyed? Lose the disclaimer, use a different email > address, or filter Randy out. This is NOT the first time you've complained > about this (although we know, for sure, that Randy is going to send this off, > automagically, to anyone that has the silly disclaimer thing going for them). > Get over it. Please don't post on this again. Thanks in advance. While I agree that the disclaimers are annoying, I also recognize that: 1. Many companies have policies that require them to append those disclaimers to every outgoing email message, and the people who post to NANOG often don't have any control over that policy. Debating on this list whether those policies are right or wrong really isn't constructive. 2. Some companies have very strict policies against unauthorized surfing on company time, and checking a gmail account could fall under their definition of unauthorized surfing, even if the purpose of checking said gmail account is to try to resolve a work issue without offending someone's procmail filters with your company's auto-disclaimer. Debating on this list whether those policies are right or wrong really isn't constructive either. That said, sending the "You sent me a message with a disclaimer that I do not accept and have thrown in the bitbucket" response back to NANOG, for the enjoyment of the other 10,000+ people on the list is even more annoying.... This will be my only post to this particular tangent of the original thread. jms From randy at psg.com Wed Jan 12 13:05:11 2011 From: randy at psg.com (Randy Bush) Date: Wed, 12 Jan 2011 11:05:11 -0800 Subject: Cisco Sanitization In-Reply-To: <4D2DD4AC.7040406@deaddrop.org> References: <1B5DDAEC-F6B2-404B-AD45-0B8AB787B76D@oicr.on.ca> <4D2DD4AC.7040406@deaddrop.org> Message-ID: > Well, here it is. Perhaps you might consider getting a gmail or other > account, and posting on NANOG from there. Either that, or filter Randy > out. Personally, I find those silly disclaimers annoying, but am far too > lazy to set up a script such as Randy has. disclaimers used to be against nanog list policy. dunno about now. but whomever does not have much sympathy from me. randy From owen at delong.com Wed Jan 12 13:03:09 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 12 Jan 2011 11:03:09 -0800 Subject: Is NAT can provide some kind of protection? In-Reply-To: <4D2DDCBA.1050304@gont.com.ar> References: <5A6D953473350C4B9995546AFE9939EE0BC132F0@RWC-EX1.corp.seven.com> <4D2DDCBA.1050304@gont.com.ar> Message-ID: <17024986-9DA5-4244-BF31-759B075AFE0D@delong.com> On Jan 12, 2011, at 8:54 AM, Fernando Gont wrote: > On 12/01/2011 01:17 p.m., George Bonser wrote: > >> But your security person needs to shift their thinking because the >> purpose of NAT and private addressing is to conserve IP address, not to >> provide security. With IPv6, the concept of NAT goes away. > > You have heard about NAT66, right? > Yes... Hopefully it was just a bad dream. NATing IPv6 doesn't do anything good. There's no benefit, only cost. Owen From randy at psg.com Wed Jan 12 13:10:03 2011 From: randy at psg.com (Randy Bush) Date: Wed, 12 Jan 2011 11:10:03 -0800 Subject: World IPv6 Day In-Reply-To: References: Message-ID: > the first global-scale trial of IPv6, the long-anticipated upgrade to > the Internet's main communications protocol known as IPv4. this phrasing is both amusing and deeply sad. amusing because many folk have been running ipv6 globaly for over a decade. deeply sad because this is taken to be shiny and new as we approach the end of the iana ipv4 free pool. what have people been smoking? randy From owen at delong.com Wed Jan 12 13:08:30 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 12 Jan 2011 11:08:30 -0800 Subject: Is NAT can provide some kind of protection? In-Reply-To: <4D2DDFCC.3020906@brightok.net> References: <5A6D953473350C4B9995546AFE9939EE0BC132F0@RWC-EX1.corp.seven.com> <4D2DDCBA.1050304@gont.com.ar> <5A6D953473350C4B9995546AFE9939EE0BC132F5@RWC-EX1.corp.seven.com> <4D2DDFCC.3020906@brightok.net> Message-ID: <6FC2E5AB-795A-4512-802F-F66213831BBA@delong.com> On Jan 12, 2011, at 9:07 AM, Jack Bates wrote: > > > On 1/12/2011 11:01 AM, George Bonser wrote: >> NAT66 is just >> straight static NAT that maps one prefix to a different prefix. >> > > I'd eat a hat if a vendor didn't implement a PAT equivalent. It's demanded too much. There is money for it, so it will be there. > > > Jack Fortunately, so far, it isn't. Hopefully we can cure the demand through education instead of acquiescence and profiteering. Owen From owen at delong.com Wed Jan 12 13:09:31 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 12 Jan 2011 11:09:31 -0800 Subject: Is NAT can provide some kind of protection? In-Reply-To: References: Message-ID: <21ADBBE3-8A9C-4EC1-BAE3-1997925E6826@delong.com> On Jan 12, 2011, at 9:04 AM, William Herrin wrote: > On Wed, Mar 21, 2007 at 5:41 AM, Tarig Ahmed wrote: >> We have wide range of Public IP addresses, I tried to assign public ip >> directly to a server behined firewall( in DMZ), but I have been resisted. >> Security guy told me is not correct to assign public ip to a server, it >> should have private ip for security reasons. >> >> Is it true that NAT can provide more security? > > Hi Tarig, > > Yes NAT can provide more security, but not in the particular scenario > you described. > > In your scenario, the firewall knows how to map incoming connections > for the public address to your server's private address, so you won't > see any benefit from NAT versus a merely stateful firewall -- a > connection request will either get through the filter or it won't. If > it gets through, the firewall knows where to send it. On the other > hand, the use of any kind of stateful firewall (most of what we refer > to as NAT firewalls keep per-connection state) increases your > vulnerability to denial of services attacks: folks DOSing you can > target both the server and the firewall's state table. So the use of > NAT there is potentially counterproductive. > > In a client (rather than server) scenario, the picture is different. > Depending on the specific "NAT" technology in use, the firewall may be > incapable of selecting a target for unsolicited communications inbound > from the public Internet. In fact, it may be theoretically impossible > for it to do so. In those scenarios, the presence of NAT in the > equation makes a large class of direct attacks on the interior host > impractical, requiring the attacker to fall back on other methods like > attempting to breach the firewall itself or indirectly polluting the > responses to communication initiated by the internal host. > No, NAT doesn't provide additional security. The stateful inspection that NAT cannot operate without provides the security. Take away the address mangling and the stateful inspection still provides the same level of security. Owen From fergdawgster at gmail.com Wed Jan 12 13:21:24 2011 From: fergdawgster at gmail.com (Paul Ferguson) Date: Wed, 12 Jan 2011 11:21:24 -0800 Subject: Is NAT can provide some kind of protection? In-Reply-To: <21ADBBE3-8A9C-4EC1-BAE3-1997925E6826@delong.com> References: <21ADBBE3-8A9C-4EC1-BAE3-1997925E6826@delong.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Jan 12, 2011 at 11:09 AM, Owen DeLong wrote: > No, NAT doesn't provide additional security. The stateful inspection that > NAT cannot operate without provides the security. Take away the > address mangling and the stateful inspection still provides the same > level of security. > There is a least one situation where NAT *does* provide a small amount of necessary security. Try this at home, with/without NAT: 1. Buy a new PC with Windows installed 2. Install all security patches needed since the OS was installed Without NAT, you're unpatched PC will get infected in less than 1 minute. Cheers, - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFNLf8gq1pz9mNUZTMRAjduAJ4w7az13wwn1zsze0DoLTRvOajxxQCgmWMG ZckeFBpLWyoqG/g9iD2cKIk= =yYof -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson ?Engineering Architecture for the Internet ?fergdawgster(at)gmail.com ?ferg's tech blog: http://fergdawg.blogspot.com/ From owen at delong.com Wed Jan 12 13:28:56 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 12 Jan 2011 11:28:56 -0800 Subject: IPv6 - real vs theoretical problems In-Reply-To: <20110112173645.3F4B210393B@mail-out06.xecu.net> References: <4D269D77.4080309@jima.tk> <10FB3518-6470-4F14-963C-B3150FABE667@delong.com> <70A7A45E-6685-4584-BA71-8B25F0EA09BF@delong.com> <4D2DDDF7.3090104@jima.tk> <20110112173645.3F4B210393B@mail-out06.xecu.net> Message-ID: On Jan 12, 2011, at 9:34 AM, Ted Fischer wrote: > At 11:59 AM 1/12/2011, Jim postulated wrote: > >> On 01/11/2011 01:31 PM, Owen DeLong wrote: >> > It's not about the number of devices. That's IPv4-think. It's about the number >> > of segments. I see a world where each home-entertainment cluster would >> > be a separate segment (today, few things use IP, but, future HE solutions >> > will include Monitors, Amps, Blu-Ray players, and other Media gateways >> > that ALL have ethernet ports for control and software update). >> >> Your future is now, Owen. I have four network devices at my primary >> television -- the TV itself, TiVo, PS3, and Wii (using the wired >> adapter). All told, I have seven networked home entertainment devices >> in my house, with another (Blu-Ray player) likely coming soon. I feel >> confident in saying that my use case isn't unusual these days. >> >> While a lot of the scalability concerns are blown off as "not applying >> to typical consumers," we're quickly getting to the point where your >> average joe IS somewhat likely to have different classes of devices that >> might benefit from being on separate subnets. >> >> Jima > > I helped a friend setup his "home network" recently. He is using an old Linksys Router with no v6 support. I like to be conservative and only allocate what might be needed ... part of my "Defense in Depth" strategy to provide some layer of "security" with NAT (yes, I know - my security by obscurity is to use something from 172.16) and a limited amount of addresses to allocate (not to mention WPA2 - he had default no security when I first got there). Used to be a /29 would be sufficient for any home. But, before I knew it, he had a wireless printer, laptop, and 4 iPhones all needing the new wireless passphrase to connect, plus he was anticipating 2 more laptops (one each for his children - to whom 2 of the iPhones belonged), and addresses set aside for guests and the occasional business visitor (he works from home). I left him configured with a /28, and told him to call me if he anticipated more. > > As a side security note - we lost the laptop on the "new" secured network before I tracked down that it had automatically logged in to his neighbor's (also unprotected) network on reboot. > > Ted > I'm not sure how you see limiting available addresses as a security feature rather than just a nuisance, but, to each their own. Owen From d.nostra at gmail.com Wed Jan 12 13:33:23 2011 From: d.nostra at gmail.com (Michel de Nostredame) Date: Wed, 12 Jan 2011 11:33:23 -0800 Subject: Is NAT can provide some kind of protection? In-Reply-To: References: Message-ID: On Wed, Mar 21, 2007 at 2:41 AM, Tarig Ahmed wrote: > We have wide range of Public IP addresses, I tried to assign public ip > directly to a server behined firewall( in DMZ), but I have been resisted. > Security guy told me is not correct to assign public ip to a server, it > should have private ip for security reasons. > > Is it true that NAT can provide more security? > > Thanks, > > Tarig Yassin Ahmed I assume you are talking about the protection to the current running "public facing" servers, hence the NAT could not provide more protection to them compares to a proper configed firewall. However, for a small business who does not have its own ASN & Provider Independent IP block(s), a NAT (NAT44 and NAT66) could provide lots of protection on IT resources when there is a need to install multiple Internet access lines for providing quickly failover (manual or automatic, doesn't matter) and/or load-sharing capability to end users. -- Michel~ From skurylo+nanog at gmail.com Wed Jan 12 13:39:59 2011 From: skurylo+nanog at gmail.com (Steven Kurylo) Date: Wed, 12 Jan 2011 11:39:59 -0800 Subject: Is NAT can provide some kind of protection? In-Reply-To: References: <21ADBBE3-8A9C-4EC1-BAE3-1997925E6826@delong.com> Message-ID: > There is a least one situation where NAT *does* provide a small amount of > necessary security. > > Try this at home, with/without NAT: > > 1. Buy a new PC with Windows installed > 2. Install all security patches needed since the OS was installed > > Without NAT, you're unpatched PC will get infected in less than 1 minute. Its the firewall included with the NAT which protects against the infection, not the NAT. So you can remove the NAT, leave the firewall, and be just as secure. From owen at delong.com Wed Jan 12 13:35:42 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 12 Jan 2011 11:35:42 -0800 Subject: Is NAT can provide some kind of protection? In-Reply-To: <4D2DE6B0.2010308@brightok.net> References: <5A6D953473350C4B9995546AFE9939EE0BC132F0@RWC-EX1.corp.seven.com> <4D2DDCBA.1050304@gont.com.ar> <5A6D953473350C4B9995546AFE9939EE0BC132F5@RWC-EX1.corp.seven.com> <4D2DDFCC.3020906@brightok.net> <5A6D953473350C4B9995546AFE9939EE0BC132F6@RWC-EX1.corp.seven.com> <4D2DE6B0.2010308@brightok.net> Message-ID: On Jan 12, 2011, at 9:36 AM, Jack Bates wrote: > On 1/12/2011 11:21 AM, George Bonser wrote: >> PAT makes little sense to me for v6, but I suspect you are correct. In >> addition, we are putting the "fire suit" on each host in addition to the >> firewall. Kernel firewall rules on each host for the *nix boxen. >> > > As my corp IT guy put it to me, PAT forces a routing disconnect between internal and external. There is no way to reach the hosts without the firewall performing it's NAT function. Given that the internal is exclusively PAT, the DMZ is public with stateful/proxy, this provides protection for the internal network while limiting the dmz exposure. > The corp IT guy is delusional. The solution to the routing disconnect is map+encap or tunnels. Many exploits now take advantage of these technologies to use a system compromised through point-click-pwn3d to provide a route into the rest of the network. If you allow outbound access to TCP/80, TCP/443, or TCP/22, then, it is trivial to create an inbound path to your network, NAT or no. > The argument everyone makes is that a stateful firewall defaults to deny. However, a single mistake prior to the deny allows traffic in. The only equivalent in a PAT scenario is to screw up port forwarding which would cause a single host to expose a single port unknowingly per mistake (which said port/host combo may not be vulnerable). In a stateful firewall, a screw up could expose all ports on a host or multiple hosts in a single mistake. > The argument everyone is making is that a stateful firewall without mangling the headers is just as secure (and just as insecure) as one with PAT. Both can and are trivially compromised. As to the PAT scenario only exposing a single port on a single host, not entirely accurate, either. I have seen errant mappings which exposed much more in a single mapping command on some systems. Then there are the NAT Traversal mechanisms which are necessary to make things function but can also be exploited. The list of problems created by PAT goes on and on. > Then there are the firewall software bugs. In PAT, such bugs don't suddenly expose all your hosts behind the firewall for direct communication from the outside world. In v6 stateful firewall, such a bug could allow circumvention of the entire firewall ruleset and the hosts would be directly addressable from the outside. > I've seen PAT bugs that exposed multiple hosts. This is false sense of security. > PAT offers the smallest of security safeguards. However, many corp IT personnel feel more secure having that small safeguard in place along with the many other safeguards they deploy. In a corporate environment where they often love to break everything and anything, I don't blame them. > Paraphrased: A bank vault with a screen door is more secure than a bank vault without a screen door. Pay no attention to the fact that the bank vault was, in this case, built with a skylight. Owen From jcdill.lists at gmail.com Wed Jan 12 13:41:18 2011 From: jcdill.lists at gmail.com (JC Dill) Date: Wed, 12 Jan 2011 11:41:18 -0800 Subject: Cisco Sanitization In-Reply-To: References: <1B5DDAEC-F6B2-404B-AD45-0B8AB787B76D@oicr.on.ca> <4D2DD4AC.7040406@deaddrop.org> Message-ID: <4D2E03DE.8010009@gmail.com> On 12/01/11 11:05 AM, Randy Bush wrote: >> Well, here it is. Perhaps you might consider getting a gmail or other >> account, and posting on NANOG from there. Either that, or filter Randy >> out. Personally, I find those silly disclaimers annoying, but am far too >> lazy to set up a script such as Randy has. > disclaimers used to be against nanog list policy. Randy, If you want to cite list policy, let's start by noting that it's a clear violation of the nanog list AUP to setup an autoresponder reply to list email[1], no matter if the autoresponder replies to the list or just to the poster. You must whitelist email from the list before applying an autoresponder. If you don't want to see the disclaimer-laden emails, then you can whitelist, then send posts with disclaimers (along with all other posts you don't care to read) to dev/null. OTOH, there is nothing in the AUP about disclaimers. Disclaimers, top posting, excessive quoting, etc. are discouraged (considered poor netiquette) but not outright forbidden. jc [1] http://www.nanog.org/mailinglist/index.php 8) Autoresponders sending mail either to the list or to the poster are prohibited. From owen at delong.com Wed Jan 12 13:57:34 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 12 Jan 2011 11:57:34 -0800 Subject: Is NAT can provide some kind of protection? In-Reply-To: References: <21ADBBE3-8A9C-4EC1-BAE3-1997925E6826@delong.com> Message-ID: On Jan 12, 2011, at 11:21 AM, Paul Ferguson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Wed, Jan 12, 2011 at 11:09 AM, Owen DeLong wrote: > >> No, NAT doesn't provide additional security. The stateful inspection that >> NAT cannot operate without provides the security. Take away the >> address mangling and the stateful inspection still provides the same >> level of security. >> > > There is a least one situation where NAT *does* provide a small amount of > necessary security. > > Try this at home, with/without NAT: > > 1. Buy a new PC with Windows installed > 2. Install all security patches needed since the OS was installed > > Without NAT, you're unpatched PC will get infected in less than 1 minute. > Wrong. Repeat the experiment with stateful firewall with default inbound deny and no NAT. Yep... Same results as NAT. NAT != security. Stateful inspection = some security. Next!! Owen From mleber at he.net Wed Jan 12 14:07:17 2011 From: mleber at he.net (Mike Leber) Date: Wed, 12 Jan 2011 12:07:17 -0800 Subject: World IPv6 Day In-Reply-To: References: Message-ID: <4D2E09F5.5050702@he.net> On 1/12/11 11:10 AM, Randy Bush wrote: >> the first global-scale trial of IPv6, the long-anticipated upgrade to >> the Internet's main communications protocol known as IPv4. > > this phrasing is both amusing and deeply sad. amusing because many folk > have been running ipv6 globaly for over a decade. deeply sad because > this is taken to be shiny and new For the people they are trying to reach, it is. Mike. From khelms at ispalliance.net Wed Jan 12 14:13:43 2011 From: khelms at ispalliance.net (Scott Helms) Date: Wed, 12 Jan 2011 15:13:43 -0500 Subject: Is NAT can provide some kind of protection? In-Reply-To: References: <21ADBBE3-8A9C-4EC1-BAE3-1997925E6826@delong.com> Message-ID: <4D2E0B77.9060504@ispalliance.net> Few home users have a stateful firewall configured and AFAIK none of the consumer models come with a good default set of rules much less a drop all unknown. For end users NAT is and will likely to continue to be the most significant and effective front line security they have. Home router manufacturers have very limited budgets for training or support for home end users so the approach is likely to remain the least expensive thing that produces the fewest inbound support calls. If the question is whether NAT was designed to be a security level then I agree your stance and I'd also agree that correctly configured firewalls do a better job at security. Where I disagree is your position that there is no extra security inherent in the default NAT behavior. Until someone makes an effort to create either a DMZ entry or starts doing port forwarding all (AFAIK) of the common routers will drop packets that they don't know where to forward them. Is this a tenuous and accidental security level based on current defaults in cheap gear? Of course, but given how normal users behave until routers can automagically configure firewall settings in a safe (i.e. not UPNP) manner I don't see things changing. On 1/12/2011 2:57 PM, Owen DeLong wrote: > On Jan 12, 2011, at 11:21 AM, Paul Ferguson wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On Wed, Jan 12, 2011 at 11:09 AM, Owen DeLong wrote: >> >>> No, NAT doesn't provide additional security. The stateful inspection that >>> NAT cannot operate without provides the security. Take away the >>> address mangling and the stateful inspection still provides the same >>> level of security. >>> >> There is a least one situation where NAT *does* provide a small amount of >> necessary security. >> >> Try this at home, with/without NAT: >> >> 1. Buy a new PC with Windows installed >> 2. Install all security patches needed since the OS was installed >> >> Without NAT, you're unpatched PC will get infected in less than 1 minute. >> > Wrong. > > Repeat the experiment with stateful firewall with default inbound deny and no NAT. > > Yep... Same results as NAT. > > NAT != security. Stateful inspection = some security. > > Next!! > > Owen > > > -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- Looking for hand-selected news, views and tips for independent broadband providers? Follow us on Twitter! http://twitter.com/ZCorum -------------------------------- From jeroen at mompl.net Wed Jan 12 14:14:23 2011 From: jeroen at mompl.net (Jeroen van Aart) Date: Wed, 12 Jan 2011 12:14:23 -0800 Subject: Cruzio peering In-Reply-To: <4D2BC629.5050105@matthew.at> References: <4D2BC2BB.6030608@mompl.net> <4D2BC629.5050105@matthew.at> Message-ID: <4D2E0B9F.9090506@mompl.net> Matthew Kaufman wrote: > Have you considered simply asking them? Sadly the person I contacted with regards to some colocation business wasn't able to answer the simplest of question (i.e. from which netblock do they assign IPs). Or at least the question was met with silence (he may still be researching the answer :-). So I felt that asking about peering would be met with even more silence. Someone sent me this link: http://bgp.he.net/AS11994#_peers Thanks, Jeroen -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html From m.hallgren at free.fr Wed Jan 12 14:17:27 2011 From: m.hallgren at free.fr (Michael Hallgren) Date: Wed, 12 Jan 2011 21:17:27 +0100 Subject: Cisco Sanitization In-Reply-To: <4D2E03DE.8010009@gmail.com> References: <1B5DDAEC-F6B2-404B-AD45-0B8AB787B76D@oicr.on.ca> <4D2DD4AC.7040406@deaddrop.org> <4D2E03DE.8010009@gmail.com> Message-ID: <1294863447.2798.66.camel@home> Le mercredi 12 janvier 2011 ? 11:41 -0800, JC Dill a ?crit : > Randy, > > If you want to cite list policy, let's start by noting that it's a clear > violation of the nanog list AUP to setup an autoresponder reply to list > email[1], no matter if the autoresponder replies to the list or just to > the poster. You must whitelist email from the list before applying an > autoresponder. If you don't want to see the disclaimer-laden emails, > then you can whitelist, then send posts with disclaimers (along with all > other posts you don't care to read) to dev/null. > > OTOH, there is nothing in the AUP about disclaimers. Disclaimers, top > posting, excessive quoting, etc. are discouraged (considered poor > netiquette) but not outright forbidden. Either way, a 15-50 or more lines legal notification style appendix to a mail in an informal operation's forum... ... seems at the very best... to be of... bad taste... (to me). (Who's reading these? :)) Cheers, mh From jbates at brightok.net Wed Jan 12 14:18:56 2011 From: jbates at brightok.net (Jack Bates) Date: Wed, 12 Jan 2011 14:18:56 -0600 Subject: Is NAT can provide some kind of protection? In-Reply-To: References: <5A6D953473350C4B9995546AFE9939EE0BC132F0@RWC-EX1.corp.seven.com> <4D2DDCBA.1050304@gont.com.ar> <5A6D953473350C4B9995546AFE9939EE0BC132F5@RWC-EX1.corp.seven.com> <4D2DDFCC.3020906@brightok.net> <5A6D953473350C4B9995546AFE9939EE0BC132F6@RWC-EX1.corp.seven.com> <4D2DE6B0.2010308@brightok.net> Message-ID: <4D2E0CB0.6020505@brightok.net> On 1/12/2011 1:35 PM, Owen DeLong wrote: > The corp IT guy is delusional. The solution to the routing disconnect > is map+encap or tunnels. Many exploits now take advantage of these > technologies to use a system compromised through point-click-pwn3d to > provide a route into the rest of the network. If you allow outbound > access to TCP/80, TCP/443, or TCP/22, then, it is trivial to create > an inbound path to your network, NAT or no. > This presumes the inside network is already compromised. In such a case, a stateful/non-proxy firewall would also be subject to such a thing. This is not what PAT prevents that a stateful firewall doesn't. > The argument everyone is making is that a stateful firewall without > mangling the headers is just as secure (and just as insecure) as one > with PAT. > Except that the routing isolation means that it is not just as secure. It has one extra vulnerability over NAT. > Both can and are trivially compromised. > Agreed that there are still ways around them. Anyone relying on a single mechanism for security will often find their security to be inefficient. > As to the PAT scenario only exposing a single port on a single host, > not entirely accurate, either. I have seen errant mappings which > exposed much more in a single mapping command on some systems. > On a standard port redirect, I'd be interested to hear the specifics. However, as my IT guy points out, he doesn't do port or 1-1 redirects through NAT. > Then there are the NAT Traversal mechanisms which are necessary to > make things function but can also be exploited. > Things don't function through his firewall. He likes breakage. > The list of problems created by PAT goes on and on. > PAT creates a lot of issues. However, for some environments, what it breaks are perfectly acceptable. Utilizing PAT in home routers and facilities that have a more open use of technology, would be crippling the protocol needlessly. > I've seen PAT bugs that exposed multiple hosts. This is false sense > of security. > Specifics. > Paraphrased: A bank vault with a screen door is more secure than a > bank vault without a screen door. > > Pay no attention to the fact that the bank vault was, in this case, > built with a skylight. If you installed a skylight, that's your own fault. Nowhere have I said, PAT is the ultimate in security and forget everything else. I've said the opposite. PAT has it's uses and does provide certain safeguards. It is one small piece in a huge arsenal of security mechanisms implemented in a network. The entire edge firewall system is only a small piece in network security. If you strictly depend on the edge firewall for security, you may someday learn the error of doing so. Many companies have. Jack From jeroen at mompl.net Wed Jan 12 14:24:18 2011 From: jeroen at mompl.net (Jeroen van Aart) Date: Wed, 12 Jan 2011 12:24:18 -0800 Subject: co-location and access to your server Message-ID: <4D2E0DF2.4010301@mompl.net> Cruzio in Santa Cruz recently opened a little co-location facility. That makes two of such facilities in Santa Cruz (the other being got.net), which could be a good thing for competition. Their 1U offer comes with limited access to your server, only from 10AM to 6 PM. I find that not acceptable. Why wait until 10 AM when a disk breaks at 8 PM? But maybe I am being too picky. What is considered normal with regards to access to your co-located server(s)? Especially when you're just co-locating one or a few servers. Thanks, Jeroen -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html From mike.lyon at gmail.com Wed Jan 12 14:28:01 2011 From: mike.lyon at gmail.com (Mike Lyon) Date: Wed, 12 Jan 2011 12:28:01 -0800 Subject: co-location and access to your server In-Reply-To: <4D2E0DF2.4010301@mompl.net> References: <4D2E0DF2.4010301@mompl.net> Message-ID: 24x7x365 On Wed, Jan 12, 2011 at 12:24 PM, Jeroen van Aart wrote: > Cruzio in Santa Cruz recently opened a little co-location facility. That > makes two of such facilities in Santa Cruz (the other being got.net), > which could be a good thing for competition. > > Their 1U offer comes with limited access to your server, only from 10AM to > 6 PM. I find that not acceptable. Why wait until 10 AM when a disk breaks at > 8 PM? But maybe I am being too picky. > > What is considered normal with regards to access to your co-located > server(s)? Especially when you're just co-locating one or a few servers. > > Thanks, > Jeroen > > -- > http://goldmark.org/jeff/stupid-disclaimers/ > http://linuxmafia.com/~rick/faq/plural-of-virus.html > > From mjkelly at gmail.com Wed Jan 12 14:28:31 2011 From: mjkelly at gmail.com (Matt Kelly) Date: Wed, 12 Jan 2011 15:28:31 -0500 Subject: co-location and access to your server In-Reply-To: <4D2E0DF2.4010301@mompl.net> References: <4D2E0DF2.4010301@mompl.net> Message-ID: When you are talking single or partial rack colo it is generally done as escorted only, due to security. They can't have anyone coming in and poking around other customers hardware without being watched. We do the same thing but we allow 24x7 escorted access. Half and full racks get 24x7 access also but that is because they are individually locked. -- Matt On Jan 12, 2011, at 3:24 PM, Jeroen van Aart wrote: > Cruzio in Santa Cruz recently opened a little co-location facility. That makes two of such facilities in Santa Cruz (the other being got.net), which could be a good thing for competition. > > Their 1U offer comes with limited access to your server, only from 10AM to 6 PM. I find that not acceptable. Why wait until 10 AM when a disk breaks at 8 PM? But maybe I am being too picky. > > What is considered normal with regards to access to your co-located server(s)? Especially when you're just co-locating one or a few servers. > > Thanks, > Jeroen > > -- > http://goldmark.org/jeff/stupid-disclaimers/ > http://linuxmafia.com/~rick/faq/plural-of-virus.html > From jack at crepinc.com Wed Jan 12 14:28:53 2011 From: jack at crepinc.com (Jack Carrozzo) Date: Wed, 12 Jan 2011 15:28:53 -0500 Subject: co-location and access to your server In-Reply-To: <4D2E0DF2.4010301@mompl.net> References: <4D2E0DF2.4010301@mompl.net> Message-ID: The answer, as always, is "how much do you want to pay?" There are lots of cheap places that make it a hassle for you to get in so you use their remote hands, or just let you in on their terms so they don't have to keep the place open at night. -Jack Carrozzo On Wed, Jan 12, 2011 at 3:24 PM, Jeroen van Aart wrote: > Cruzio in Santa Cruz recently opened a little co-location facility. That > makes two of such facilities in Santa Cruz (the other being got.net), > which could be a good thing for competition. > > Their 1U offer comes with limited access to your server, only from 10AM to > 6 PM. I find that not acceptable. Why wait until 10 AM when a disk breaks at > 8 PM? But maybe I am being too picky. > > What is considered normal with regards to access to your co-located > server(s)? Especially when you're just co-locating one or a few servers. > > Thanks, > Jeroen > > -- > http://goldmark.org/jeff/stupid-disclaimers/ > http://linuxmafia.com/~rick/faq/plural-of-virus.html > > From cmadams at hiwaay.net Wed Jan 12 14:31:16 2011 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 12 Jan 2011 14:31:16 -0600 Subject: Is NAT can provide some kind of protection? In-Reply-To: <4D2E0B77.9060504@ispalliance.net> References: <21ADBBE3-8A9C-4EC1-BAE3-1997925E6826@delong.com> <4D2E0B77.9060504@ispalliance.net> Message-ID: <20110112203116.GA9385@hiwaay.net> Once upon a time, Scott Helms said: > Few home users have a stateful firewall configured Yes, they do. NAT requires a stateful firewall. Why is that so hard to understand? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From gbonser at seven.com Wed Jan 12 14:32:04 2011 From: gbonser at seven.com (George Bonser) Date: Wed, 12 Jan 2011 12:32:04 -0800 Subject: TeliaSonera US contact? Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13314@RWC-EX1.corp.seven.com> Does anyone have a (preferably sales) contact with TeliaSonera in the US? I have been trying to get someone to speak to me about a product of theirs (have exchanged email but can't get them on the phone). It might be the time difference with Europe making things difficult so I am wondering if someone might have a contact in North America. Thanks. G From stephend at gmail.com Wed Jan 12 14:36:11 2011 From: stephend at gmail.com (Stephen Davis) Date: Thu, 13 Jan 2011 09:36:11 +1300 Subject: co-location and access to your server In-Reply-To: <4D2E0DF2.4010301@mompl.net> References: <4D2E0DF2.4010301@mompl.net> Message-ID: > What is considered normal with regards to access to your co-located > server(s)? Especially when you're just co-locating one or a few servers. Normally you need an escort so you don't go fiddling with other people's hardware. Our provider has a callout fee if we want to get in at nights or weekends. From jbates at brightok.net Wed Jan 12 14:36:14 2011 From: jbates at brightok.net (Jack Bates) Date: Wed, 12 Jan 2011 14:36:14 -0600 Subject: Is NAT can provide some kind of protection? In-Reply-To: <4D2E0B77.9060504@ispalliance.net> References: <21ADBBE3-8A9C-4EC1-BAE3-1997925E6826@delong.com> <4D2E0B77.9060504@ispalliance.net> Message-ID: <4D2E10BE.1090308@brightok.net> On 1/12/2011 2:13 PM, Scott Helms wrote: > Until someone makes an effort to create either a DMZ entry or starts > doing port forwarding all (AFAIK) of the common routers will drop > packets that they don't know where to forward them. This can be easily implemented in stateful firewalls for home routers. The code is almost identical to NAT, just no address mangling. I suspect that v4 NAT and v6 stateful inspection will actually use the same code in many cases. Not to say NAT doesn't have other uses, but they generally are useful for enterprise networks or sometimes service providers, not home routers. Jack From mikevs at xs4all.net Wed Jan 12 14:37:47 2011 From: mikevs at xs4all.net (Miquel van Smoorenburg) Date: Wed, 12 Jan 2011 21:37:47 +0100 Subject: Is NAT can provide some kind of protection? In-Reply-To: <4D2E0B77.9060504@ispalliance.net> References: <21ADBBE3-8A9C-4EC1-BAE3-1997925E6826@delong.com> Message-ID: <201101122037.p0CKblfG011464@xs8.xs4all.nl> In article , Scott Helms wrote: >Few home users have a stateful firewall configured and AFAIK none of the >consumer models come with a good default set of rules much less a drop >all unknown. The v6 capable CPEs for home users I've seen so far all include stateful firewalling with inbound default deny. (including the one I'm using right now) Is your experience with such CPEs any different ? Mike. From jeffrey.lyon at blacklotus.net Wed Jan 12 14:40:49 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Wed, 12 Jan 2011 15:40:49 -0500 Subject: TeliaSonera US contact? In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13314@RWC-EX1.corp.seven.com> References: <5A6D953473350C4B9995546AFE9939EE0BC13314@RWC-EX1.corp.seven.com> Message-ID: George, Try Stephen Brown, stephen.brown at teliasonera.com . He is based in Virginia and has always been very good about telephone contact. Jeff On Wed, Jan 12, 2011 at 3:32 PM, George Bonser wrote: > Does anyone have a (preferably sales) contact with TeliaSonera in the > US? ?I have been trying to get someone to speak to me about a product of > theirs (have exchanged email but can't get them on the phone). It might > be the time difference with Europe making things difficult so I am > wondering if someone might have a contact in North America. > > Thanks. > > G > > > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From brandon.kim at brandontek.com Wed Jan 12 14:43:31 2011 From: brandon.kim at brandontek.com (Brandon Kim) Date: Wed, 12 Jan 2011 15:43:31 -0500 Subject: co-location and access to your server In-Reply-To: <4D2E0DF2.4010301@mompl.net> References: <4D2E0DF2.4010301@mompl.net> Message-ID: If you're co-locating with us, you have access to your equipment 24x7. And we are also staffed 24x7 in the event you can't get to our location for whatever reason...(vacation etc...) Colo's have their own rules I suppose, did you know about this before hosting with them? > Date: Wed, 12 Jan 2011 12:24:18 -0800 > From: jeroen at mompl.net > To: nanog at nanog.org > Subject: co-location and access to your server > > Cruzio in Santa Cruz recently opened a little co-location facility. That > makes two of such facilities in Santa Cruz (the other being got.net), > which could be a good thing for competition. > > Their 1U offer comes with limited access to your server, only from 10AM > to 6 PM. I find that not acceptable. Why wait until 10 AM when a disk > breaks at 8 PM? But maybe I am being too picky. > > What is considered normal with regards to access to your co-located > server(s)? Especially when you're just co-locating one or a few servers. > > Thanks, > Jeroen > > -- > http://goldmark.org/jeff/stupid-disclaimers/ > http://linuxmafia.com/~rick/faq/plural-of-virus.html > From khelms at ispalliance.net Wed Jan 12 14:44:27 2011 From: khelms at ispalliance.net (Scott Helms) Date: Wed, 12 Jan 2011 15:44:27 -0500 Subject: Is NAT can provide some kind of protection? In-Reply-To: <20110112203116.GA9385@hiwaay.net> References: <21ADBBE3-8A9C-4EC1-BAE3-1997925E6826@delong.com> <4D2E0B77.9060504@ispalliance.net> <20110112203116.GA9385@hiwaay.net> Message-ID: <4D2E12AB.1060803@ispalliance.net> No it really doesn't. Thank you for leaving the key word when you quoted me (configured). The difference is the _default_ behavior of the two. NAT by _default_ drops packets it doesn't have a mapped PAT translation for. Home firewalls do not _default_ to dropping all packets they don't have a rule to explicitly allow. The behaviors when configured by someone knowledgeable behave the in a similar fashion (allowing packets that are configured to pass and dropping all others) but end users don't do that as a rule. On 1/12/2011 3:31 PM, Chris Adams wrote: > Once upon a time, Scott Helms said: >> Few home users have a stateful firewall configured > Yes, they do. NAT requires a stateful firewall. Why is that so hard to > understand? -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- Looking for hand-selected news, views and tips for independent broadband providers? Follow us on Twitter! http://twitter.com/ZCorum -------------------------------- From drais at icantclick.org Wed Jan 12 14:49:09 2011 From: drais at icantclick.org (david raistrick) Date: Wed, 12 Jan 2011 15:49:09 -0500 (EST) Subject: co-location and access to your server In-Reply-To: <4D2E0DF2.4010301@mompl.net> References: <4D2E0DF2.4010301@mompl.net> Message-ID: On Wed, 12 Jan 2011, Jeroen van Aart wrote: > What is considered normal with regards to access to your co-located > server(s)? Especially when you're just co-locating one or a few servers. For less than 1 rack, or specialty racks with lockable sections (1/2 or 1/3 or 1/4 racks with their own doors), I'd consider any physical access to simply be a plus. I wouldn't expect any at all. You're not paying for enough space to justify the costs involved in 24x7 independant access, and the risks to other customers gear. When you get a full rack+, or cage+, I'd expect unfettered 24x7 access since your gear should be seperated and secured from other folks gear. Some specialty providers would be exceptions, of course (ie, I used to colo gear inside tv stations, satellite downlink stations, etc). Telecom colo (switch and network gear in a dedicated but shared space for providers providing service) would be an exception, of course. -- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html From owen at delong.com Wed Jan 12 14:50:28 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 12 Jan 2011 12:50:28 -0800 Subject: Is NAT can provide some kind of protection? In-Reply-To: <4D2E0B77.9060504@ispalliance.net> References: <21ADBBE3-8A9C-4EC1-BAE3-1997925E6826@delong.com> <4D2E0B77.9060504@ispalliance.net> Message-ID: <094D5B92-6EFA-4A42-9E95-79790EE95BBC@delong.com> On Jan 12, 2011, at 12:13 PM, Scott Helms wrote: > Few home users have a stateful firewall configured and AFAIK none of the consumer models come with a good default set of rules much less a drop all unknown. For end users NAT is and will likely to continue to be the most significant and effective front line security they have. Home router That's simply not true. Every end user running NAT is running a stateful firewall with a default inbound deny. It then takes the extra step of mangling the packet header. This header mangling step is unnecessary in IPv6 and is not part of the security mechanism. Unfortunately, because these two features have been bundled for so long in IPv4, many people, apparently yourself included, don't see that what most people call a "NAT" box is actually a stateful-inspection+NAT box doing both steps. > manufacturers have very limited budgets for training or support for home end users so the approach is likely to remain the least expensive thing that produces the fewest inbound support calls. If the question is whether NAT was designed to be a security level then I agree your stance and I'd also agree that correctly configured firewalls do a better job at security. Where I disagree is your position that there is no extra security inherent in the default NAT behavior. Until someone makes an effort to create either a DMZ entry or starts doing port forwarding all (AFAIK) of the common routers will drop packets that they don't know where to forward them. > And there's no reason they can't function exactly that way in IPv6 without mangling the packet header. > Is this a tenuous and accidental security level based on current defaults in cheap gear? Of course, but given how normal users behave until routers can automagically configure firewall settings in a safe (i.e. not UPNP) manner I don't see things changing. > Actually, even if it's deliberate, the point here is that it's a three-step process: 1. State table update/match 2. Mangle packet header 3. Forward packet In IPv6, we can discard step 2 without changing the security provided by step 1 and improve the functionality of step 3. Owen > On 1/12/2011 2:57 PM, Owen DeLong wrote: >> On Jan 12, 2011, at 11:21 AM, Paul Ferguson wrote: >> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> On Wed, Jan 12, 2011 at 11:09 AM, Owen DeLong wrote: >>> >>>> No, NAT doesn't provide additional security. The stateful inspection that >>>> NAT cannot operate without provides the security. Take away the >>>> address mangling and the stateful inspection still provides the same >>>> level of security. >>>> >>> There is a least one situation where NAT *does* provide a small amount of >>> necessary security. >>> >>> Try this at home, with/without NAT: >>> >>> 1. Buy a new PC with Windows installed >>> 2. Install all security patches needed since the OS was installed >>> >>> Without NAT, you're unpatched PC will get infected in less than 1 minute. >>> >> Wrong. >> >> Repeat the experiment with stateful firewall with default inbound deny and no NAT. >> >> Yep... Same results as NAT. >> >> NAT != security. Stateful inspection = some security. >> >> Next!! >> >> Owen >> >> >> > > > -- > Scott Helms > Vice President of Technology > ISP Alliance, Inc. DBA ZCorum > (678) 507-5000 > -------------------------------- > Looking for hand-selected news, views and > tips for independent broadband providers? > > Follow us on Twitter! http://twitter.com/ZCorum > -------------------------------- > From drais at icantclick.org Wed Jan 12 14:53:07 2011 From: drais at icantclick.org (david raistrick) Date: Wed, 12 Jan 2011 15:53:07 -0500 (EST) Subject: Is NAT can provide some kind of protection? In-Reply-To: <20110112203116.GA9385@hiwaay.net> References: <21ADBBE3-8A9C-4EC1-BAE3-1997925E6826@delong.com> <4D2E0B77.9060504@ispalliance.net> <20110112203116.GA9385@hiwaay.net> Message-ID: On Wed, 12 Jan 2011, Chris Adams wrote: > Yes, they do. NAT requires a stateful firewall. Why is that so hard to > understand? Um. No. NAT requires stateful inspection (because NAT needs to maintain a state table), but does not require a stateful firewall. You can (and many CPE appliances do/did) have no firewall, or stateless firewall in front of NAT. All NAT does is give you an implied deny-all-inbound rule, but doesn't, in and of itself, prevent someone probing open (configured by you or the vendor) ports that are forwarded or on the device. Or from having unfettered inside access of 1 internal IP if you NAT all external ports to an internal IP. -- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html From khelms at ispalliance.net Wed Jan 12 14:54:19 2011 From: khelms at ispalliance.net (Scott Helms) Date: Wed, 12 Jan 2011 15:54:19 -0500 Subject: Is NAT can provide some kind of protection? In-Reply-To: <201101122037.p0CKblfG011464@xs8.xs4all.nl> References: <21ADBBE3-8A9C-4EC1-BAE3-1997925E6826@delong.com> <201101122037.p0CKblfG011464@xs8.xs4all.nl> Message-ID: <4D2E14FB.2050007@ispalliance.net> Miquel, Almost no home users have an IPv6 connection currently and the ones that do are the extreme outliers. IPv6 gear (depending on the deployment method) will hopefully handle this well, but no I haven't seen any that did a default drop all. In truth most of the CPE I've seen don't even run v6 well even if their marketing claims otherwise. However, v6 is an entirely different generation of gear that will _hopefully_ get things right since they will _hopefully_ avoid NAT. Having said that so far the smoothest (from an end user perspective) way of moving forward is often 4 to 6 in the home and I expect that to be dirt common for very long time in the future. On 1/12/2011 3:37 PM, Miquel van Smoorenburg wrote: > In article, > Scott Helms wrote: >> Few home users have a stateful firewall configured and AFAIK none of the >> consumer models come with a good default set of rules much less a drop >> all unknown. > The v6 capable CPEs for home users I've seen so far all include > stateful firewalling with inbound default deny. > > (including the one I'm using right now) > > Is your experience with such CPEs any different ? > > Mike. > -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- Looking for hand-selected news, views and tips for independent broadband providers? Follow us on Twitter! http://twitter.com/ZCorum -------------------------------- From tglassey at earthlink.net Wed Jan 12 14:56:50 2011 From: tglassey at earthlink.net (todd glassey) Date: Wed, 12 Jan 2011 12:56:50 -0800 Subject: co-location and access to your server In-Reply-To: References: <4D2E0DF2.4010301@mompl.net> Message-ID: <4D2E1592.4090805@earthlink.net> On 1/12/2011 12:28 PM, Matt Kelly wrote: > When you are talking single or partial rack colo it is generally done as escorted only, due to security. They can't have anyone coming in and poking around other customers hardware without being watched. We do the same thing but we allow 24x7 escorted access. Half and full racks get 24x7 access also but that is because they are individually locked. > > > -- > Matt > > > On Jan 12, 2011, at 3:24 PM, Jeroen van Aart wrote: > >> Cruzio in Santa Cruz recently opened a little co-location facility. That makes two of such facilities in Santa Cruz (the other being got.net), which could be a good thing for competition. >> >> Their 1U offer comes with limited access to your server, only from 10AM to 6 PM. I find that not acceptable. Why wait until 10 AM when a disk breaks at 8 PM? But maybe I am being too picky. >> >> What is considered normal with regards to access to your co-located server(s)? Especially when you're just co-locating one or a few servers. >> >> Thanks, >> Jeroen >> >> -- >> http://goldmark.org/jeff/stupid-disclaimers/ >> http://linuxmafia.com/~rick/faq/plural-of-virus.html >> > This is beginning to sound like the blind leading the blind & this commentary is too funny. If you outsource your IT facilities to a ISP and you do not plan for redundancy then the failure is YOURS and not the ISP's limited access policy. The ISP's limited access policy has to do with their overhead models and that's all there is to that. Sorry to bring daylight into this but it is what it is... YOU MUST plan for redundancy. Todd Glassey - as a GOT.NET Client > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 10.0.1191 / Virus Database: 1435/3375 - Release Date: 01/12/11 > > > From jeff-kell at utc.edu Wed Jan 12 14:58:56 2011 From: jeff-kell at utc.edu (Jeff Kell) Date: Wed, 12 Jan 2011 15:58:56 -0500 Subject: Is NAT can provide some kind of protection? In-Reply-To: References: <21ADBBE3-8A9C-4EC1-BAE3-1997925E6826@delong.com> Message-ID: <4D2E1610.90004@utc.edu> On 1/12/2011 2:57 PM, Owen DeLong wrote: >> Try this at home, with/without NAT: >> >> 1. Buy a new PC with Windows installed >> 2. Install all security patches needed since the OS was installed >> >> Without NAT, you're unpatched PC will get infected in less than 1 minute. > Wrong. > Repeat the experiment with stateful firewall with default inbound deny and no NAT. > Yep... Same results as NAT. Now let that laptop (or another one on the home subnet) show up with Bridging or Internet Connection Sharing enabled with wired/wireless connections and see what you get. Still maybe OK if it's the "host" firewall, and it's turned on, and it's not domain-joined with the local subnet allowed, etc., but that was post-SP2 and assumes some malware [or the user] hasn't turned it off. NAT+RFC1918 = no accidental leakage/bridging (yes, they could spoof RFC1918 destinations, assuming they get routed all the way to the endpoint... but that's a bigger "if" than a public address) "Perfect stateful firewall with perfect default inbound deny and no other variables thrown in the mix" and yes, but it's breakable in contrast to the NAT+RFC1918 case. There is something to be said for "unreachable" (i.e., "not in your forwarding table") -- else the VPN / VRF / MPLS / etc folks wouldn't have a leg to stand on :-) With that said, this isn't a one-size-fits-all, everybody's perfect solution. We've covered the gamut from home CPE to server farms here, with the original question being about a DMZ case. They are however legitimate security layers applied to certain cloves of this particular bulb of garlic (a more appropriate model than the homogeneous "onion") :-) Jeff From gbonser at seven.com Wed Jan 12 15:05:40 2011 From: gbonser at seven.com (George Bonser) Date: Wed, 12 Jan 2011 13:05:40 -0800 Subject: TeliaSonera US contact? In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13314@RWC-EX1.corp.seven.com> References: <5A6D953473350C4B9995546AFE9939EE0BC13314@RWC-EX1.corp.seven.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC1331D@RWC-EX1.corp.seven.com> Thanks, folks, I got the contact I needed and the ball is rolling. George > -----Original Message----- > From: George Bonser [mailto:gbonser at seven.com] > Sent: Wednesday, January 12, 2011 12:32 PM > To: nanog at nanog.org > Subject: TeliaSonera US contact? > > Does anyone have a (preferably sales) contact with TeliaSonera in the > US? I have been trying to get someone to speak to me about a product > of > theirs (have exchanged email but can't get them on the phone). It might > be the time difference with Europe making things difficult so I am > wondering if someone might have a contact in North America. > > Thanks. > > G > > From khelms at ispalliance.net Wed Jan 12 15:05:42 2011 From: khelms at ispalliance.net (Scott Helms) Date: Wed, 12 Jan 2011 16:05:42 -0500 Subject: Is NAT can provide some kind of protection? In-Reply-To: <094D5B92-6EFA-4A42-9E95-79790EE95BBC@delong.com> References: <21ADBBE3-8A9C-4EC1-BAE3-1997925E6826@delong.com> <4D2E0B77.9060504@ispalliance.net> <094D5B92-6EFA-4A42-9E95-79790EE95BBC@delong.com> Message-ID: <4D2E17A6.4090708@ispalliance.net> > > That's simply not true. Every end user running NAT is running a stateful firewall with a default inbound deny. Really? I just tested this with 8 different router models from 5 different manufacturers and in all cases the default behavior was the same. Put a public IP on a PC behind the router, tell the router how to connect (DHCP in this case), and leaving everything else as default meant that all traffic to the public IP was allowed through unless I configured rules. One of the Netgear models (IIRC) did block ICMP but any TCP or UDP traffic was allowed through. Now, this certainly isn't an exhaustive test, but it tested the devices we needed checked. If someone knows of a model that does block incoming (non-established TCP) traffic by default I'd like to know about it. That's especially true of combo DSL modem routers. -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- Looking for hand-selected news, views and tips for independent broadband providers? Follow us on Twitter! http://twitter.com/ZCorum -------------------------------- From Valdis.Kletnieks at vt.edu Wed Jan 12 15:16:44 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 12 Jan 2011 16:16:44 -0500 Subject: Is NAT can provide some kind of protection? In-Reply-To: Your message of "Wed, 12 Jan 2011 15:13:43 EST." <4D2E0B77.9060504@ispalliance.net> References: <21ADBBE3-8A9C-4EC1-BAE3-1997925E6826@delong.com> <4D2E0B77.9060504@ispalliance.net> Message-ID: <37353.1294867004@localhost> On Wed, 12 Jan 2011 15:13:43 EST, Scott Helms said: > Few home users have a stateful firewall configured What percent of home users are running a Windows older than XP SP2? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jbates at brightok.net Wed Jan 12 15:17:43 2011 From: jbates at brightok.net (Jack Bates) Date: Wed, 12 Jan 2011 15:17:43 -0600 Subject: Is NAT can provide some kind of protection? In-Reply-To: <4D2E17A6.4090708@ispalliance.net> References: <21ADBBE3-8A9C-4EC1-BAE3-1997925E6826@delong.com> <4D2E0B77.9060504@ispalliance.net> <094D5B92-6EFA-4A42-9E95-79790EE95BBC@delong.com> <4D2E17A6.4090708@ispalliance.net> Message-ID: <4D2E1A77.3050700@brightok.net> On 1/12/2011 3:05 PM, Scott Helms wrote: > If someone knows of a model that does block incoming (non-established > TCP) traffic by default I'd like to know about it. That's especially > true of combo DSL modem routers. I believe Visionnet's v6 dsl modem does, as well as comtrends. Jack From Valdis.Kletnieks at vt.edu Wed Jan 12 15:18:17 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 12 Jan 2011 16:18:17 -0500 Subject: Is NAT can provide some kind of protection? In-Reply-To: Your message of "Wed, 12 Jan 2011 11:21:24 PST." References: <21ADBBE3-8A9C-4EC1-BAE3-1997925E6826@delong.com> Message-ID: <37451.1294867097@localhost> On Wed, 12 Jan 2011 11:21:24 PST, Paul Ferguson said: > Try this at home, with/without NAT: > > 1. Buy a new PC with Windows installed > 2. Install all security patches needed since the OS was installed > > Without NAT, you're unpatched PC will get infected in less than 1 minute. What release of Windows? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From Valdis.Kletnieks at vt.edu Wed Jan 12 15:22:51 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 12 Jan 2011 16:22:51 -0500 Subject: Is NAT can provide some kind of protection? In-Reply-To: Your message of "Wed, 12 Jan 2011 16:05:42 EST." <4D2E17A6.4090708@ispalliance.net> References: <21ADBBE3-8A9C-4EC1-BAE3-1997925E6826@delong.com> <4D2E0B77.9060504@ispalliance.net> <094D5B92-6EFA-4A42-9E95-79790EE95BBC@delong.com> <4D2E17A6.4090708@ispalliance.net> Message-ID: <37701.1294867371@localhost> On Wed, 12 Jan 2011 16:05:42 EST, Scott Helms said: > > That's simply not true. Every end user running NAT is running a stateful firewall with a default inbound deny. > Really? I just tested this with 8 different router models from 5 > different manufacturers and in all cases the default behavior was the > same. Put a public IP on a PC behind the router At which point you're not running NAT, so it's a different configuration than the one under discussion. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Wed Jan 12 15:23:55 2011 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Thu, 13 Jan 2011 07:53:55 +1030 Subject: World IPv6 Day In-Reply-To: References: Message-ID: <20110113075355.548b19bd@opy.nosense.org> On Wed, 12 Jan 2011 11:10:03 -0800 Randy Bush wrote: > > the first global-scale trial of IPv6, the long-anticipated upgrade to > > the Internet's main communications protocol known as IPv4. > > this phrasing is both amusing and deeply sad. amusing because many folk > have been running ipv6 globaly for over a decade. deeply sad because > this is taken to be shiny and new as we approach the end of the iana > ipv4 free pool. what have people been smoking? > IPv4. Every now and then it is worth remembering that IPv4 was a protocol that was designed for a small experimental network that managed to escape into production. How long it has been usable is actually quite remarkable, and has only been achieved through a series of neat hacks like classes, subnets and CIDR. Regards, Mark. From fergdawgster at gmail.com Wed Jan 12 15:24:57 2011 From: fergdawgster at gmail.com (Paul Ferguson) Date: Wed, 12 Jan 2011 13:24:57 -0800 Subject: Is NAT can provide some kind of protection? In-Reply-To: <37451.1294867097@localhost> References: <21ADBBE3-8A9C-4EC1-BAE3-1997925E6826@delong.com> <37451.1294867097@localhost> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Jan 12, 2011 at 1:18 PM, wrote: > On Wed, 12 Jan 2011 11:21:24 PST, Paul Ferguson said: > >> Try this at home, with/without NAT: >> >> 1. Buy a new PC with Windows installed >> 2. Install all security patches needed since the OS was installed >> >> Without NAT, you're unpatched PC will get infected in less than 1 >> minute. > > What release of Windows? > Okay, okay -- you got me on that one. :-) It used to be a much bigger problem when XP was shipping on PCs, but of course that has changed. I suppose there's a sliding-window principle (no pun intended) with regards to the number of security vulnerabilities that are remotely exploitable and the amount of time since the OS version was introduced, but you get my point. :-) - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFNLhwjq1pz9mNUZTMRAstGAKDhsX9AYZL6sGMIH5WWJM2GpilQNQCgm3TH UQ26ucDTFifTB3eAQEZxj0M= =Lh9p -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson ?Engineering Architecture for the Internet ?fergdawgster(at)gmail.com ?ferg's tech blog: http://fergdawg.blogspot.com/ From owen at delong.com Wed Jan 12 15:24:14 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 12 Jan 2011 13:24:14 -0800 Subject: Is NAT can provide some kind of protection? In-Reply-To: <4D2E17A6.4090708@ispalliance.net> References: <21ADBBE3-8A9C-4EC1-BAE3-1997925E6826@delong.com> <4D2E0B77.9060504@ispalliance.net> <094D5B92-6EFA-4A42-9E95-79790EE95BBC@delong.com> <4D2E17A6.4090708@ispalliance.net> Message-ID: <3AF11656-F71B-452D-9A1C-3C914E85CD05@delong.com> On Jan 12, 2011, at 1:05 PM, Scott Helms wrote: > >> >> That's simply not true. Every end user running NAT is running a stateful firewall with a default inbound deny. > > Really? I just tested this with 8 different router models from 5 different manufacturers and in all cases the default behavior was the same. Put a public IP on a PC behind the router, tell the router how to connect (DHCP in this case), and leaving everything else as default meant that all traffic to the public IP was allowed through unless I configured rules. One of the Netgear models (IIRC) did block ICMP but any TCP or UDP traffic was allowed through. Now, this certainly isn't an exhaustive test, but it tested the devices we needed checked. If someone knows of a model that does block incoming (non-established TCP) traffic by default I'd like to know about it. That's especially true of combo DSL modem routers. > It may be that the default behavior of the models you tested is to turn off the stateful firewall if there's a public inside address, but, the same code that does the stateful inspection for NAT can do it without NAT if the vendor chooses. I suspect that the vendors chose to automatically disable stateful inspection to avoid tech support calls from ignorant users with public IPs that didn't understand why their packets weren't getting through. Owen From fergdawgster at gmail.com Wed Jan 12 15:28:23 2011 From: fergdawgster at gmail.com (Paul Ferguson) Date: Wed, 12 Jan 2011 13:28:23 -0800 Subject: Is NAT can provide some kind of protection? In-Reply-To: <37353.1294867004@localhost> References: <21ADBBE3-8A9C-4EC1-BAE3-1997925E6826@delong.com> <4D2E0B77.9060504@ispalliance.net> <37353.1294867004@localhost> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Jan 12, 2011 at 1:16 PM, wrote: > On Wed, 12 Jan 2011 15:13:43 EST, Scott Helms said: >> Few home users have a stateful firewall configured > > What percent of home users are running a Windows older than XP SP2? > I don't have stats per specific XP SP version, but a sampling of OSs visiting a blog that I admin: 43.40% WinXP 26.33% Win7 13.00% MacOSX 12.60% WinVista 1.60% unknown 1.00% iOS 0.87% Linux 0.87% Android 0.13% Win2003 0.13% Win2000 0.07% SymbianOS Of course, this is just a sampling that may or may not be relevant. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFNLhzuq1pz9mNUZTMRAgN0AJ4hrUq0qSfLLNMWq6RAXleb8bya2ACglxTU tT/sP0oVu89WeWrG6XodcKU= =+pa8 -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson ?Engineering Architecture for the Internet ?fergdawgster(at)gmail.com ?ferg's tech blog: http://fergdawg.blogspot.com/ From jeroen at mompl.net Wed Jan 12 15:31:42 2011 From: jeroen at mompl.net (Jeroen van Aart) Date: Wed, 12 Jan 2011 13:31:42 -0800 Subject: co-location and access to your server In-Reply-To: <4D2E1592.4090805@earthlink.net> References: <4D2E0DF2.4010301@mompl.net> <4D2E1592.4090805@earthlink.net> Message-ID: <4D2E1DBE.7050500@mompl.net> todd glassey wrote: > On 1/12/2011 12:28 PM, Matt Kelly wrote: >> When you are talking single or partial rack colo it is generally done > policy. The ISP's limited access policy has to do with their overhead > models and that's all there is to that. > > Sorry to bring daylight into this but it is what it is... YOU MUST plan > for redundancy. Thanks for all the replies, I understand that allowing access to other people's servers unsupervised could be a bad idea. Problem for my specific situation is that the 10 to 6 access is exactly the time I generally am NOT in town. I guess knowing who entered the building by means of a keycard and having cameras isn't considered enough to deter potential "evil doers". I know it's not enough for places like equinix, but that's of a different caliber. Thanks, Jeroen -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html From drais at icantclick.org Wed Jan 12 15:44:13 2011 From: drais at icantclick.org (david raistrick) Date: Wed, 12 Jan 2011 16:44:13 -0500 (EST) Subject: co-location and access to your server In-Reply-To: <4D2E1DBE.7050500@mompl.net> References: <4D2E0DF2.4010301@mompl.net> <4D2E1592.4090805@earthlink.net> <4D2E1DBE.7050500@mompl.net> Message-ID: On Wed, 12 Jan 2011, Jeroen van Aart wrote: > I guess knowing who entered the building by means of a keycard and having > cameras isn't considered enough to deter potential "evil doers". I know it's > not enough for places like equinix, but that's of a different caliber. Paying for 1u of colo justifys a keycard for you, cameras and keycard hardware for the facility? you're paying what, 50-100$ a month, maybe less? you realize that low prices comes at the cost of reduced services? -- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html From gbonser at seven.com Wed Jan 12 15:50:49 2011 From: gbonser at seven.com (George Bonser) Date: Wed, 12 Jan 2011 13:50:49 -0800 Subject: co-location and access to your server In-Reply-To: References: <4D2E0DF2.4010301@mompl.net><4D2E1592.4090805@earthlink.net> <4D2E1DBE.7050500@mompl.net> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13322@RWC-EX1.corp.seven.com> > From: david raistrick > Sent: Wednesday, January 12, 2011 1:44 PM > To: Jeroen van Aart > Cc: NANOG list > Subject: Re: co-location and access to your server > > On Wed, 12 Jan 2011, Jeroen van Aart wrote: > > > I guess knowing who entered the building by means of a keycard and > having > > cameras isn't considered enough to deter potential "evil doers". I > know it's > > not enough for places like equinix, but that's of a different > caliber. > > Paying for 1u of colo justifys a keycard for you, cameras and keycard > hardware for the facility? you're paying what, 50-100$ a month, maybe > less? you realize that low prices comes at the cost of reduced > services? I would say even that hosting other people's hardware on a "one off" basis isn't even really cost effective. Better, in my opinion, for the service provider to simply buy a rack from Rackable or another vendor and rent the servers out to people. At least you are then dealing with a known entity as far as hardware goes. Housing who knows what gives you a potential mix of things like front to back, back to front, and side to side airflow; an assortment of network issues due to an assortment of NICs in the network; people wanting physical access to their servers for things like driver replacement, etc. Even having someone willing to allow individuals to house their own single servers in a rack is amazing. Complaining about the service as far as access just seems like looking the gift horse in the mouth! From sethm at rollernet.us Wed Jan 12 15:56:07 2011 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 12 Jan 2011 13:56:07 -0800 Subject: co-location and access to your server In-Reply-To: <4D2E0DF2.4010301@mompl.net> References: <4D2E0DF2.4010301@mompl.net> Message-ID: <4D2E2377.3010702@rollernet.us> On 1/12/2011 12:24, Jeroen van Aart wrote: > Cruzio in Santa Cruz recently opened a little co-location facility. That > makes two of such facilities in Santa Cruz (the other being got.net), > which could be a good thing for competition. > > Their 1U offer comes with limited access to your server, only from 10AM > to 6 PM. I find that not acceptable. Why wait until 10 AM when a disk > breaks at 8 PM? But maybe I am being too picky. > > What is considered normal with regards to access to your co-located > server(s)? Especially when you're just co-locating one or a few servers. > I treat all my colo customers as 24 hour (escorted) access. ~Seth From kevin at steadfast.net Wed Jan 12 16:00:58 2011 From: kevin at steadfast.net (Kevin Stange) Date: Wed, 12 Jan 2011 16:00:58 -0600 Subject: co-location and access to your server In-Reply-To: References: <4D2E0DF2.4010301@mompl.net> <4D2E1592.4090805@earthlink.net> <4D2E1DBE.7050500@mompl.net> Message-ID: <4D2E249A.9050802@steadfast.net> On 01/12/2011 03:44 PM, david raistrick wrote: > On Wed, 12 Jan 2011, Jeroen van Aart wrote: > >> I guess knowing who entered the building by means of a keycard and >> having cameras isn't considered enough to deter potential "evil >> doers". I know it's not enough for places like equinix, but that's of >> a different caliber. > > Paying for 1u of colo justifys a keycard for you, cameras and keycard > hardware for the facility? you're paying what, 50-100$ a month, maybe > less? you realize that low prices comes at the cost of reduced services? Having the infrastructure in place to support full cab customers already and 24/7 remote hands, the cost of providing 24/7 access to smaller colo customers is negligible. We could issue a card to every single server one of our colo customers for only the one-time cost of the card. It doesn't make sense for most single-server customers because a tech still has to go into the data center, unlock the cabinet, fetch a crash cart, etc, so he might as well let them in the front door. I guess what you're saying holds true if the facility doesn't already offer /anyone/ this access regardless of how much equipment and space they have. -- Kevin Stange Chief Technology Officer Steadfast Networks http://steadfast.net Phone: 312-602-2689 ext. 203 | Fax: 312-602-2688 | Cell: 312-320-5867 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 261 bytes Desc: OpenPGP digital signature URL: From kevin at steadfast.net Wed Jan 12 16:11:54 2011 From: kevin at steadfast.net (Kevin Stange) Date: Wed, 12 Jan 2011 16:11:54 -0600 Subject: co-location and access to your server In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13322@RWC-EX1.corp.seven.com> References: <4D2E0DF2.4010301@mompl.net><4D2E1592.4090805@earthlink.net> <4D2E1DBE.7050500@mompl.net> <5A6D953473350C4B9995546AFE9939EE0BC13322@RWC-EX1.corp.seven.com> Message-ID: <4D2E272A.9040607@steadfast.net> On 01/12/2011 03:50 PM, George Bonser wrote: > I would say even that hosting other people's hardware on a "one off" > basis isn't even really cost effective. Better, in my opinion, for the > service provider to simply buy a rack from Rackable or another vendor > and rent the servers out to people. At least you are then dealing with > a known entity as far as hardware goes. Housing who knows what gives > you a potential mix of things like front to back, back to front, and > side to side airflow; an assortment of network issues due to an > assortment of NICs in the network; people wanting physical access to > their servers for things like driver replacement, etc. You're talking about a dedicated server business versus colocation. Colocation can be a better solution if you have special needs for hardware or want to not pay for the extra overhead that needs to be built-in for supporting dedicated hardware (like stocking replacement parts, paying for the server's original purchase cost, extra fees for upgrade hardware, etc). Colo also lets customers move their hardware around if they ever want to change providers, rather than have to do a soft migration and to deliver a prepared server to a facility they can set up at home or in their office beforehand. Depending on your exact needs, some of these things might outweigh the benefits of a dedicated server from the data center operator. As a colo provider, if you set up and enforce rules regarding mounting, air flow, cabling, etc and confirm them when the customer brings them to the facility, this problem does not really exist. In our facilities, customers are welcome to come in to work on their hardware at any time 24/7. We do not guarantee or offer that we will have the parts or tools needed to service the equipment and encourage customers to send us those things as needed or take care of the hardware personally in order to deal with any such concerns. This has never been a problem for us. -- Kevin Stange Chief Technology Officer Steadfast Networks http://steadfast.net Phone: 312-602-2689 ext. 203 | Fax: 312-602-2688 | Cell: 312-320-5867 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 261 bytes Desc: OpenPGP digital signature URL: From lists at mtin.net Wed Jan 12 16:34:38 2011 From: lists at mtin.net (Justin Wilson) Date: Wed, 12 Jan 2011 17:34:38 -0500 Subject: co-location and access to your server In-Reply-To: Message-ID: If it were cheap and I needed a secondary site for backups and DR then I would live with that. Otherwise no. -- Justin Wilson Aol & Yahoo IM: j2sw http://www.mtin.net/blog ? xISP News http://www.twitter.com/j2sw ? Follow me on Twitter Wisp Consulting ? Tower Climbing ? Network Support From jeroen at mompl.net Wed Jan 12 16:46:12 2011 From: jeroen at mompl.net (Jeroen van Aart) Date: Wed, 12 Jan 2011 14:46:12 -0800 Subject: co-location and access to your server In-Reply-To: <4D2E249A.9050802@steadfast.net> References: <4D2E0DF2.4010301@mompl.net> <4D2E1592.4090805@earthlink.net> <4D2E1DBE.7050500@mompl.net> <4D2E249A.9050802@steadfast.net> Message-ID: <4D2E2F34.1040002@mompl.net> Kevin Stange wrote: > I guess what you're saying holds true if the facility doesn't already > offer /anyone/ this access regardless of how much equipment and space > they have. They offer 24/7 access to 1/3 racks or more. The price is not that low, $100/month for 1*1U and 1 IP. I'd say that's not a sales bin style rock bottom price where expecting even free coffee is excessive. ;-) There is another small colo in town which to the best of my knowledge does provide 24/7 access with a keycard. Greetings, Jeroen -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html From ptbnat at yahoo.com Wed Jan 12 17:44:31 2011 From: ptbnat at yahoo.com (Natarajan Balasubramanian) Date: Thu, 13 Jan 2011 05:14:31 +0530 (IST) Subject: BT Support# Message-ID: <327668.96832.qm@web95104.mail.in2.yahoo.com> Hi, ? I am looking for the Enterprise (24x7) technical support contact# for British Telecom (BT), services provided in USA. ? ? Thanks & Regards, ? Natarajan Balasubramanian From gbonser at seven.com Wed Jan 12 17:57:20 2011 From: gbonser at seven.com (George Bonser) Date: Wed, 12 Jan 2011 15:57:20 -0800 Subject: co-location and access to your server In-Reply-To: <4D2E272A.9040607@steadfast.net> References: <4D2E0DF2.4010301@mompl.net><4D2E1592.4090805@earthlink.net> <4D2E1DBE.7050500@mompl.net> <5A6D953473350C4B9995546AFE9939EE0BC13322@RWC-EX1.corp.seven.com> <4D2E272A.9040607@steadfast.net> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC1332C@RWC-EX1.corp.seven.com> > From: Kevin Stange > You're talking about a dedicated server business versus colocation. > Colocation can be a better solution if you have special needs for > hardware or want to not pay for the extra overhead that needs to be > built-in for supporting dedicated hardware (like stocking replacement > parts, paying for the server's original purchase cost, extra fees for > upgrade hardware, etc). > > Colo also lets customers move their hardware around if they ever want > to change providers, rather than have to do a soft migration and to > deliver a prepared server to a facility they can set up at home or in > their office beforehand. Depending on your exact needs, some of these > things might outweigh the benefits of a dedicated server from the data > center operator. Agreed on the above two points. I was thinking that it was great just to find someone these days that would accept a one-off server and that should be enough to be thankful for! The access requirements can be a pain but if you are in a shared cabinet, you have people installing rack mounts, pulling servers in and out around your stuff, etc. I can see where I would probably want the colo provider to have someone supervising what that other customer is doing right next to my server (did he cover my air vents with a bunch of cables?) The degree of clue varies widely between people who might want to collocate a single server and if I am unlucky enough to be hosted directly above/below someone who is in/out of their server every week, I might get a little nervous. Knowing that there is someone with a bit more clue (does that for a living) supervising (or at least witnessing) might ease my anxiety somewhat about what is going on in the cabinet where I am being hosted. > As a colo provider, if you set up and enforce rules regarding mounting, > air flow, cabling, etc and confirm them when the customer brings them > to the facility, this problem does not really exist. To some extent, that is true. I guess it depends on what is going on, too. Does the customer arrive, request their server and the colo provider pulls it for them and deliver it to a work area or does the customer go get the server themselves under supervision of the colo provider? There can be a lot of variables. > In our facilities, customers are welcome to come in to work on their > hardware at any time 24/7. We do not guarantee or offer that we will > have the parts or tools needed to service the equipment and encourage > customers to send us those things as needed or take care of the > hardware personally in order to deal with any such concerns. > > This has never been a problem for us. Awesome. It's good to know that there are still operations like that around. That is probably found more often in local providers and not so often in the big operations. The more community oriented providers would be much more accepting of such a situation than a large operation. But having clueful people around 24x7 to assist customers in shared cabinets may not be effective for them if they have just opened up and might not have a lot of customers yet. If they only get one or two customers who come in after hours, I could see where they might figure it isn't cost effective for them to have staff on the swing and graveyard shifts. Larger operations might have an easier time with that, but having someone "on call" probably isn't that bad if it is infrequently needed. From larsscarter at gmail.com Wed Jan 12 18:13:53 2011 From: larsscarter at gmail.com (Lars Carter) Date: Wed, 12 Jan 2011 19:13:53 -0500 Subject: Routing Suggestions Message-ID: Hi NANOG list, I have a simple, hypothetical question regarding preferred connectivity methods for you guys that I would like to get the hive mind opinion about. There are two companies, Company A and Company B, that are planning to continuously exchange a large amount of sensitive data and are located in a mutual datacenter. They decide to order a cross connect and peer privately for the obvious reasons. Company A has a small but knowledgable engineering staff and it's network is running BGP as its only routing protocol with multiple transit vendors and a handful of other larger peers. Company B is a smaller shop that is single homed behind one ISP through a default static route, they have hardware that can handle advanced routing protocols but have not had the need to implement them as of yet. There is a single prefix on both sides that will need to be routed to the other party. It is rare that prefixes would need to change or for additional prefixes to be added. >From an technical, operational, and security standpoint what would be the preferred way to route traffic between these two networks? Cheers, Lars From jared at puck.nether.net Wed Jan 12 18:18:11 2011 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 12 Jan 2011 19:18:11 -0500 Subject: Routing Suggestions In-Reply-To: References: Message-ID: On Jan 12, 2011, at 7:13 PM, Lars Carter wrote: > Hi NANOG list, > > I have a simple, hypothetical question regarding preferred connectivity > methods for you guys that I would like to get the hive mind opinion about. > > > There are two companies, Company A and Company B ... [ trimmed, but they want to interconnect directly, one does static, the other can do bgp] > From an technical, operational, and security standpoint what would be the > preferred way to route traffic between these two networks? I suggest using one of the reserved/private BGP asns for this purpose. ASNumber: 64512 - 65535 ASName: IANA-RSVD2 ASHandle: AS64512 RegDate: 1995-04-06 Updated: 2009-01-14 Comment: Designated for private use [RFC1930] - Jared From jlewis at lewis.org Wed Jan 12 18:23:14 2011 From: jlewis at lewis.org (Jon Lewis) Date: Wed, 12 Jan 2011 19:23:14 -0500 (EST) Subject: Routing Suggestions In-Reply-To: References: Message-ID: On Wed, 12 Jan 2011, Jared Mauch wrote: > I suggest using one of the reserved/private BGP asns for this purpose. > > ASNumber: 64512 - 65535 It sounds to me like Company B isn't doing BGP (probably has no experience with it) and if there's only a single prefix per side of the cross connect, especially if the cross connect is going into routers smart enough to remove a route from the table if the destination interface is down, static would do just fine. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From r.engehausen at gmail.com Wed Jan 12 18:26:14 2011 From: r.engehausen at gmail.com (Roy) Date: Wed, 12 Jan 2011 16:26:14 -0800 Subject: Routing Suggestions In-Reply-To: References: Message-ID: <4D2E46A6.8070504@gmail.com> On 1/12/2011 4:13 PM, Lars Carter wrote: > Hi NANOG list, > > I have a simple, hypothetical question regarding preferred connectivity > methods for you guys that I would like to get the hive mind opinion about. > > > There are two companies, Company A and Company B, that are planning to > continuously exchange a large amount of sensitive data and are located in a > mutual datacenter. They decide to order a cross connect and peer privately > for the obvious reasons. Company A has a small but knowledgable engineering > staff and it's network is running BGP as its only routing protocol with > multiple transit vendors and a handful of other larger peers. Company B is a > smaller shop that is single homed behind one ISP through a default static > route, they have hardware that can handle advanced routing protocols but > have not had the need to implement them as of yet. There is a single prefix > on both sides that will need to be routed to the other party. It is rare > that prefixes would need to change or for additional prefixes to be added. > > > > From an technical, operational, and security standpoint what would be the > preferred way to route traffic between these two networks? > > > Cheers, > > Lars > Apply the KISS principle. Use a static route From adrian at creative.net.au Wed Jan 12 18:28:55 2011 From: adrian at creative.net.au (Adrian Chadd) Date: Thu, 13 Jan 2011 08:28:55 +0800 Subject: Routing Suggestions In-Reply-To: References: Message-ID: <20110113002855.GC8617@skywalker.creative.net.au> On Wed, Jan 12, 2011, Jon Lewis wrote: > On Wed, 12 Jan 2011, Jared Mauch wrote: > > >I suggest using one of the reserved/private BGP asns for this purpose. > > > >ASNumber: 64512 - 65535 > > It sounds to me like Company B isn't doing BGP (probably has no experience > with it) and if there's only a single prefix per side of the cross > connect, especially if the cross connect is going into routers smart > enough to remove a route from the table if the destination interface is > down, static would do just fine. Unless you'd like to ensure the sensitive traffic doesn't cross an "unsafer" default rout path if the XC is down. (Assuming the prefixes are both public IPv4/6 space to begin with.) Adrian -- - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support - - $24/pm+GST entry-level VPSes w/ capped bandwidth charges available in WA - From jeroen at mompl.net Wed Jan 12 18:28:56 2011 From: jeroen at mompl.net (Jeroen van Aart) Date: Wed, 12 Jan 2011 16:28:56 -0800 Subject: co-location and access to your server In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC1332C@RWC-EX1.corp.seven.com> References: <4D2E0DF2.4010301@mompl.net><4D2E1592.4090805@earthlink.net> <4D2E1DBE.7050500@mompl.net> <5A6D953473350C4B9995546AFE9939EE0BC13322@RWC-EX1.corp.seven.com> <4D2E272A.9040607@steadfast.net> <5A6D953473350C4B9995546AFE9939EE0BC1332C@RWC-EX1.corp.seven.com> Message-ID: <4D2E4748.2080504@mompl.net> George Bonser wrote: > Awesome. It's good to know that there are still operations like that around. That is probably found more often in local providers and not so often in the big operations. The more community oriented providers would be much more accepting of such a situation than a large operation. Community oriented provider, that's what I am talking about. I just couldn't find the right term. > but having someone "on call" probably isn't that bad if it is infrequently needed. I'd be willing to pay extra for access after hours, either a recurring fee or on a case by case basis. I am not searching for the cheapest option and demanding that in addition my car be detailed weekly. But just some co-locating space for one or a few servers where I don't have to plan a week ahead or miss half a day of $dayjob in order to work on it (which would cost me more). Greetings, Jeroen -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html From james at jamesstewartsmith.com Wed Jan 12 18:29:53 2011 From: james at jamesstewartsmith.com (james at jamesstewartsmith.com) Date: Thu, 13 Jan 2011 00:29:53 +0000 Subject: Routing Suggestions Message-ID: <240577938-1294878593-cardhu_decombobulator_blackberry.rim.net-191564214-@bda343.bisx.prod.on.blackberry> Since it sounds like there is no alternate path, it sounds like the most secure, simplest to operate would be static routes. It's not sexy, but no need to toss in a routing protocol if it's such a static setup. ------Original Message------ From: Lars Carter To: NANOG at NANOG.org Subject: Routing Suggestions Sent: Jan 12, 2011 7:13 PM Hi NANOG list, I have a simple, hypothetical question regarding preferred connectivity methods for you guys that I would like to get the hive mind opinion about. There are two companies, Company A and Company B, that are planning to continuously exchange a large amount of sensitive data and are located in a mutual datacenter. They decide to order a cross connect and peer privately for the obvious reasons. Company A has a small but knowledgable engineering staff and it's network is running BGP as its only routing protocol with multiple transit vendors and a handful of other larger peers. Company B is a smaller shop that is single homed behind one ISP through a default static route, they have hardware that can handle advanced routing protocols but have not had the need to implement them as of yet. There is a single prefix on both sides that will need to be routed to the other party. It is rare that prefixes would need to change or for additional prefixes to be added. >From an technical, operational, and security standpoint what would be the preferred way to route traffic between these two networks? Cheers, Lars Sent from my ?contract free? BlackBerry? smartphone on the WIND network. From dr at cluenet.de Wed Jan 12 18:39:28 2011 From: dr at cluenet.de (Daniel Roesen) Date: Thu, 13 Jan 2011 01:39:28 +0100 Subject: Routing Suggestions In-Reply-To: References: Message-ID: <20110113003928.GC944@srv03.cluenet.de> On Wed, Jan 12, 2011 at 07:13:53PM -0500, Lars Carter wrote: > From an technical, operational, and security standpoint what would be the > preferred way to route traffic between these two networks? Static routing - at least "on" the direct link. For extra "security", you might want to make sure that the sensitive traffic won't take the internet path, but only the directconnection. Example: 192.168.0.0/24 being the prefix in question. Drop traffic for that /24 via a static Null0 (IOS et al) / discard or reject (JUNOS) route. Then add /25 statics for 192.168.0.0/25 and .128/25 via the direct link. On the BGP speaking network, make sure you don't accept 192.168.0.0/24 or more specifics of that via BGP from untrusted parties. In case the link goes down, the /25s should become inactive, and the /24 Null/discard/reject route prevents leakage of sensitive data in unintended (untrusted) directions (e.g. Internet) via default or covering aggregate routes. Of course all this assumes "no dynamic redundancy" etc. and some other things not further specified in your scenario. There are many ways to skin a cat. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From nanog-post at rsuc.gweep.net Wed Jan 12 18:55:32 2011 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Wed, 12 Jan 2011 19:55:32 -0500 Subject: Routing Suggestions In-Reply-To: References: Message-ID: <20110113005532.GA35927@gweep.net> On Wed, Jan 12, 2011 at 07:13:53PM -0500, Lars Carter wrote: [snip] > There are two companies, Company A and Company B, that are planning to > continuously exchange a large amount of sensitive data and are located in a > mutual datacenter. They decide to order a cross connect and peer privately > for the obvious reasons. Company A has a small but knowledgable engineering > staff and it's network is running BGP as its only routing protocol with > multiple transit vendors and a handful of other larger peers. Company B is a > smaller shop that is single homed behind one ISP through a default static > route, they have hardware that can handle advanced routing protocols but > have not had the need to implement them as of yet. There is a single prefix > on both sides that will need to be routed to the other party. It is rare > that prefixes would need to change or for additional prefixes to be added. > > > From an technical, operational, and security standpoint what would be the > preferred way to route traffic between these two networks? Use eBGP. Company B runs a mutually-agreed private ASN (at least from company A's unused list). This scales from the initial deployment to multiple cross-connects for failover [or even IPSEC tunnel over public interfaces]. Company B should have Company A provide some clues to their staff if needed (and get more out of the deal). "Simple" static solutions wind up being entrenched, so move/add/change becomes convoluted. And how many times has one prefix really stayed that way? :-) -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From leviathan at darktech.org Wed Jan 12 18:57:18 2011 From: leviathan at darktech.org (Justin Scott) Date: Wed, 12 Jan 2011 19:57:18 -0500 Subject: co-location and access to your server In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC1332C@RWC-EX1.corp.seven.com> References: <4D2E0DF2.4010301@mompl.net> <4D2E1592.4090805@earthlink.net> <4D2E1DBE.7050500@mompl.net> <5A6D953473350C4B9995546AFE9939EE0BC13322@RWC-EX1.corp.seven.com> <4D2E272A.9040607@steadfast.net> <5A6D953473350C4B9995546AFE9939EE0BC1332C@RWC-EX1.corp.seven.com> Message-ID: > I was thinking that it was great just to find someone these days > that would accept a one-off server and that should be enough to > be thankful for! Especially true with providers like SoftLayer which can turn up a fully dedicated server to spec at any of several locations within a few hours. No hardware to manage or worrying about getting direct access at all. They even give you the ability to cycle the outlet(s) the server is plugged into if needed. Unless there is some really specialized hardware, location-specific or regulatory need, I couldn't imagine a desire to deal with putting my own single box at a co-lo anymore. Of course, since you're leasing the box you pay a premium over a pure bare-bones co-lo, but it vastly simplifies things. -Justin Scott From jlewis at lewis.org Wed Jan 12 18:58:25 2011 From: jlewis at lewis.org (Jon Lewis) Date: Wed, 12 Jan 2011 19:58:25 -0500 (EST) Subject: Routing Suggestions In-Reply-To: <20110113002855.GC8617@skywalker.creative.net.au> References: <20110113002855.GC8617@skywalker.creative.net.au> Message-ID: On Thu, 13 Jan 2011, Adrian Chadd wrote: > On Wed, Jan 12, 2011, Jon Lewis wrote: >> On Wed, 12 Jan 2011, Jared Mauch wrote: >> >>> I suggest using one of the reserved/private BGP asns for this purpose. >>> >>> ASNumber: 64512 - 65535 >> >> It sounds to me like Company B isn't doing BGP (probably has no experience >> with it) and if there's only a single prefix per side of the cross >> connect, especially if the cross connect is going into routers smart >> enough to remove a route from the table if the destination interface is >> down, static would do just fine. > > Unless you'd like to ensure the sensitive traffic doesn't cross an > "unsafer" default rout path if the XC is down. BGP would have that same issue since B is default routing to their provider. [config for B] ip route ip route null0 250 ip route 0.0.0.0 0.0.0.0 problem solved. If the gw to A is reachable, traffic goes via the cross connect. If the gw is down, traffic goes nowhere. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From joe at nethead.com Wed Jan 12 19:02:34 2011 From: joe at nethead.com (Joe Hamelin) Date: Wed, 12 Jan 2011 17:02:34 -0800 Subject: Routing Suggestions In-Reply-To: <20110113005532.GA35927@gweep.net> References: <20110113005532.GA35927@gweep.net> Message-ID: >> There are two companies, Company A and Company B, that are planning to >> continuously exchange a large amount of sensitive data and are located in a >> mutual datacenter. They decide to order a cross connect and peer privately >> for the obvious reasons. Second NIC on a secure server at "A" wired with a crossover cable to a second NIC a secure server at "B". Use an RFC1918 /30 that is null routed on both companies routers. KISS. Hand it off to the developers. -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 From kevin at steadfast.net Wed Jan 12 19:13:47 2011 From: kevin at steadfast.net (Kevin Stange) Date: Wed, 12 Jan 2011 19:13:47 -0600 Subject: co-location and access to your server In-Reply-To: References: <4D2E0DF2.4010301@mompl.net> <4D2E1592.4090805@earthlink.net> <4D2E1DBE.7050500@mompl.net> <5A6D953473350C4B9995546AFE9939EE0BC13322@RWC-EX1.corp.seven.com> <4D2E272A.9040607@steadfast.net> <5A6D953473350C4B9995546AFE9939EE0BC1332C@RWC-EX1.corp.seven.com> Message-ID: <4D2E51CB.8080602@steadfast.net> On 01/12/2011 06:57 PM, Justin Scott wrote: >> I was thinking that it was great just to find someone these days >> that would accept a one-off server and that should be enough to >> be thankful for! > > Especially true with providers like SoftLayer which can turn up a > fully dedicated server to spec at any of several locations within a > few hours. No hardware to manage or worrying about getting direct > access at all. They even give you the ability to cycle the outlet(s) > the server is plugged into if needed. Unless there is some really > specialized hardware, location-specific or regulatory need, I couldn't > imagine a desire to deal with putting my own single box at a co-lo > anymore. Of course, since you're leasing the box you pay a premium > over a pure bare-bones co-lo, but it vastly simplifies things. That's true. Most dedicated server providers will get you remote power outlet control and many can get you remote console (IPMI, DRAC) as an included feature, so you can take care of almost all administration on your own, including OS reinstalls and fscks. There's still sometimes an edge in price and control when you use your own hardware and that's definitely worth it for some. -- Kevin Stange Chief Technology Officer Steadfast Networks http://steadfast.net Phone: 312-602-2689 ext. 203 | Fax: 312-602-2688 | Cell: 312-320-5867 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 261 bytes Desc: OpenPGP digital signature URL: From patrick at zill.net Wed Jan 12 19:16:16 2011 From: patrick at zill.net (Patrick Giagnocavo) Date: Wed, 12 Jan 2011 20:16:16 -0500 Subject: co-location and access to your server In-Reply-To: <4D2E0DF2.4010301@mompl.net> References: <4D2E0DF2.4010301@mompl.net> Message-ID: <4D2E5260.2010600@zill.net> On 1/12/2011 3:24 PM, Jeroen van Aart wrote: > > What is considered normal with regards to access to your co-located > server(s)? Especially when you're just co-locating one or a few servers. Depends on how much you are paying really. If you decide to go with this provider, get dual power supplies, RAID, etc. on the server you will be giving them. You might want instead to look for another provider who offers decent remote hands 24x7 who is in a major market - price should be about the same. --Patrick From adrian at creative.net.au Wed Jan 12 19:20:14 2011 From: adrian at creative.net.au (Adrian Chadd) Date: Thu, 13 Jan 2011 09:20:14 +0800 Subject: Routing Suggestions In-Reply-To: References: <20110113002855.GC8617@skywalker.creative.net.au> Message-ID: <20110113012014.GD8617@skywalker.creative.net.au> On Wed, Jan 12, 2011, Jon Lewis wrote: > >Unless you'd like to ensure the sensitive traffic doesn't cross an > >"unsafer" default rout path if the XC is down. > > BGP would have that same issue since B is default routing to their > provider. > > [config for B] > ip route > ip route null0 250 > ip route 0.0.0.0 0.0.0.0 > > problem solved. If the gw to A is reachable, traffic goes via the cross > connect. If the gw is down, traffic goes nowhere. I was just making the observation; the solution is pretty simple. (Yes, I've seen "secure" network cross-connects get bitten by this. :-) Adrian -- - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support - - $24/pm+GST entry-level VPSes w/ capped bandwidth charges available in WA - From deleskie at gmail.com Wed Jan 12 19:21:10 2011 From: deleskie at gmail.com (jim deleskie) Date: Wed, 12 Jan 2011 21:21:10 -0400 Subject: Routing Suggestions In-Reply-To: References: <20110113005532.GA35927@gweep.net> Message-ID: What Joe Said. Static with 1918 space. If they NEED global space, explain 1918 space will work and tell them to use it. -jim On Wed, Jan 12, 2011 at 9:02 PM, Joe Hamelin wrote: >>> There are two companies, Company A and Company B, that are planning to >>> continuously exchange a large amount of sensitive data and are located in a >>> mutual datacenter. They decide to order a cross connect and peer privately >>> for the obvious reasons. > > Second NIC on a secure server at "A" wired with a crossover cable to a > second NIC a secure server at "B". Use an RFC1918 /30 that is null > routed on both companies routers. > > KISS. ?Hand it off to the developers. > > -- > Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 > > From bill at herrin.us Wed Jan 12 20:13:50 2011 From: bill at herrin.us (William Herrin) Date: Wed, 12 Jan 2011 21:13:50 -0500 Subject: Is NAT can provide some kind of protection? In-Reply-To: <15191.1294852587@localhost> References: <15191.1294852587@localhost> Message-ID: On Wed, Jan 12, 2011 at 12:16 PM, wrote: > On Wed, 12 Jan 2011 12:04:01 EST, William Herrin said: >> In a client (rather than server) scenario, the picture is different. >> Depending on the specific "NAT" technology in use, the firewall may be >> incapable of selecting a target for unsolicited communications inbound >> from the public Internet. In fact, it may be theoretically impossible >> for it to do so. In those scenarios, the presence of NAT in the >> equation makes a large class of direct attacks on the interior host >> impractical, requiring the attacker to fall back on other methods like >> attempting to breach the firewall itself or indirectly polluting the >> responses to communication initiated by the internal host. > > Note that the presence of a firewall with a 'default deny' rule for inbound > packets provides the same level of impracticality. Hi Valdis, There's actually a large difference between something that's impossible for a technology to do (even in theory), something that the technology has been programmed not to do and something that a technology is by default configured not to do. The hacker can't make the equipment do something impossible. He can only go around it, try a different attack vector. To push through something the technology has been programmed not to do, he needs to identify a suitable bug: hard but not quite impractical. As for default configurations... human error is a *major* part of the security equation. Identifying and exploiting configuration errors is a hacker's fertile hunting ground. On Wed, Jan 12, 2011 at 2:35 PM, Owen DeLong wrote: > On Jan 12, 2011, at 9:36 AM, Jack Bates wrote: >> As my corp IT guy put it to me, PAT forces a routing disconnect >> between internal and external. There is no way to reach the hosts >> without the firewall performing it's NAT function. Given that the >> internal is exclusively PAT, the DMZ is public with stateful/proxy, >> this provides protection for the internal network while limiting the >> dmz exposure. > > The corp IT guy is delusional. The solution to the routing disconnect is > map+encap or tunnels. Logical fallacy, ad hominem: the sanity of Jack's IT guy is not at issue. Logical fallacy, straw man: that a security technology failed to close attack vectors it was not claimed to have closed makes no statement as to whether the tech blocked the attack vectors it did claim to block. The only technology which stops all possible network attack vectors is the off switch. Logical fallacy, circular reasoning: to bring your magic tunnels into existence, the firewall must have already been breached. Yet you claim the tunnels allow you to breach the firewall, allegedly proving that the PAT routing disconnect is a no-op. It took you only 17 words to get the trifecta. Congratulations, or something. On Wed, Jan 12, 2011 at 2:09 PM, Owen DeLong wrote: > No, NAT doesn't provide additional security. The stateful inspection that > NAT cannot operate without provides the security. Take away the > address mangling and the stateful inspection still provides the same > level of security. When you'd care to offer a refutation of my explanation (above) of exactly how NAT impacts the security process beyond what the stateful inspection does, a refutation that doesn't involve a bunch of bald assertions, hand-waving and logical fallacies, you let me know. Perhaps the "security expert" you tell me you relied on when formulating your viewpoint could help you out with that? On Wed, Jan 12, 2011 at 2:21 PM, Paul Ferguson wrote: > There is a least one situation where NAT *does* provide a small amount of > necessary security. > > Try this at home, with/without NAT: > > 1. Buy a new PC with Windows installed > 2. Install all security patches needed since the OS was installed > > Without NAT, you're unpatched PC will get infected in less than 1 minute. Hi Paul, That doesn't really prove your point. Owen is correct that any reasonably configured firewall of any type would tend to prevent such infections. The different firewall types don't begin to exhibit a major difference in security effectiveness until you factor in the impact of human error in specific scenarios. 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 Wed Jan 12 21:02:22 2011 From: marka at isc.org (Mark Andrews) Date: Thu, 13 Jan 2011 14:02:22 +1100 Subject: Is NAT can provide some kind of protection? In-Reply-To: Your message of "Wed, 12 Jan 2011 21:13:50 CDT." References: <15191.1294852587@localhost> Message-ID: <20110113030222.C79E58B9B35@drugs.dv.isc.org> In message , William Herrin writes: > On Wed, Jan 12, 2011 at 12:16 PM, wrote: > > On Wed, 12 Jan 2011 12:04:01 EST, William Herrin said: > >> In a client (rather than server) scenario, the picture is different. > >> Depending on the specific "NAT" technology in use, the firewall may be > >> incapable of selecting a target for unsolicited communications inbound > >> from the public Internet. In fact, it may be theoretically impossible > >> for it to do so. In those scenarios, the presence of NAT in the > >> equation makes a large class of direct attacks on the interior host > >> impractical, requiring the attacker to fall back on other methods like > >> attempting to breach the firewall itself or indirectly polluting the > >> responses to communication initiated by the internal host. > > > > Note that the presence of a firewall with a 'default deny' rule for inbou= > nd > > packets provides the same level of impracticality. > > Hi Valdis, > > There's actually a large difference between something that's > impossible for a technology to do (even in theory), something that the > technology has been programmed not to do and something that a > technology is by default configured not to do. Well ask the firewall vendor not to give you the knob to open it up completely. Note the CPE NAT boxes I've seen all have the ability to send anything that isn't being NAT'd to a internal box so it isn't like NAT boxes don't already have the flaw you are complaining about. Usually it's labeled as DMZ host or something similar. They also have the ability to send traffic for individual port to particular boxes on the inside without it being initiated from the inside. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From owen at delong.com Wed Jan 12 21:01:01 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 12 Jan 2011 19:01:01 -0800 Subject: Is NAT can provide some kind of protection? In-Reply-To: References: <15191.1294852587@localhost> Message-ID: On Jan 12, 2011, at 6:13 PM, William Herrin wrote: > On Wed, Jan 12, 2011 at 12:16 PM, wrote: >> On Wed, 12 Jan 2011 12:04:01 EST, William Herrin said: >>> In a client (rather than server) scenario, the picture is different. >>> Depending on the specific "NAT" technology in use, the firewall may be >>> incapable of selecting a target for unsolicited communications inbound >>> from the public Internet. In fact, it may be theoretically impossible >>> for it to do so. In those scenarios, the presence of NAT in the >>> equation makes a large class of direct attacks on the interior host >>> impractical, requiring the attacker to fall back on other methods like >>> attempting to breach the firewall itself or indirectly polluting the >>> responses to communication initiated by the internal host. >> >> Note that the presence of a firewall with a 'default deny' rule for inbound >> packets provides the same level of impracticality. > > Hi Valdis, > > There's actually a large difference between something that's > impossible for a technology to do (even in theory), something that the > technology has been programmed not to do and something that a > technology is by default configured not to do. > > The hacker can't make the equipment do something impossible. He can > only go around it, try a different attack vector. To push through > something the technology has been programmed not to do, he needs to > identify a suitable bug: hard but not quite impractical. As for > default configurations... human error is a *major* part of the > security equation. Identifying and exploiting configuration errors is > a hacker's fertile hunting ground. > > NAT boxes without the ability to do port forwarding are few and far between. Human error can poke a hole in a NAT as easily as in a stateful firewall with a default deny. > On Wed, Jan 12, 2011 at 2:35 PM, Owen DeLong wrote: >> On Jan 12, 2011, at 9:36 AM, Jack Bates wrote: >>> As my corp IT guy put it to me, PAT forces a routing disconnect >>> between internal and external. There is no way to reach the hosts >>> without the firewall performing it's NAT function. Given that the >>> internal is exclusively PAT, the DMZ is public with stateful/proxy, >>> this provides protection for the internal network while limiting the >>> dmz exposure. >> >> The corp IT guy is delusional. The solution to the routing disconnect is >> map+encap or tunnels. > > Logical fallacy, ad hominem: the sanity of Jack's IT guy is not at issue. > The logical fallacy is believing that NAT provides any protection. > Logical fallacy, straw man: that a security technology failed to close > attack vectors it was not claimed to have closed makes no statement as > to whether the tech blocked the attack vectors it did claim to block. > The only technology which stops all possible network attack vectors is > the off switch. > It claimed to provide routing isolation. That alleged isolation is easily circumvented or even configured out of relevance by human error or deliberately. > Logical fallacy, circular reasoning: to bring your magic tunnels into > existence, the firewall must have already been breached. Yet you claim > the tunnels allow you to breach the firewall, allegedly proving that > the PAT routing disconnect is a no-op. > No, the firewall is presumably configured to intentionally allow access by end users to web sites. Once you allow that, point-click-pwnm3 takes over. > It took you only 17 words to get the trifecta. Congratulations, or something. > Seriously, Bill... Just because you keep repeating the same sophistry doesn't make it any more believable. > > On Wed, Jan 12, 2011 at 2:09 PM, Owen DeLong wrote: >> No, NAT doesn't provide additional security. The stateful inspection that >> NAT cannot operate without provides the security. Take away the >> address mangling and the stateful inspection still provides the same >> level of security. > > When you'd care to offer a refutation of my explanation (above) of > exactly how NAT impacts the security process beyond what the stateful > inspection does, a refutation that doesn't involve a bunch of bald > assertions, hand-waving and logical fallacies, you let me know. > Perhaps the "security expert" you tell me you relied on when > formulating your viewpoint could help you out with that? > Logical fallacy -- Circular argument. Since you call any refutation I offer "bald assertions" or "hand waving" when in reality they are behaviors I have observed in the real world, I doubt we'll ever come to agreement on this point. Also, saying things like `the "security expert" you tell me you relied on' come across as condescending. I have told you that I have discussed the matter with multiple security experts on multiple occasions. The fact that most of them have not given me permission to disclose their contact details to you does not render them any less correct. Finally, I've never told you that I relied on them in forming my viewpoint, only that I have discussed the matter at length and that they share my viewpoint. Owen > > On Wed, Jan 12, 2011 at 2:21 PM, Paul Ferguson wrote: >> There is a least one situation where NAT *does* provide a small amount of >> necessary security. >> >> Try this at home, with/without NAT: >> >> 1. Buy a new PC with Windows installed >> 2. Install all security patches needed since the OS was installed >> >> Without NAT, you're unpatched PC will get infected in less than 1 minute. > > Hi Paul, > > That doesn't really prove your point. Owen is correct that any > reasonably configured firewall of any type would tend to prevent such > infections. The different firewall types don't begin to exhibit a > major difference in security effectiveness until you factor in the > impact of human error in specific scenarios. > > Regards, > Bill Herrin > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 From mruiz at lstfinancial.com Wed Jan 12 21:13:51 2011 From: mruiz at lstfinancial.com (Michael Ruiz) Date: Wed, 12 Jan 2011 21:13:51 -0600 Subject: Message-ID: <16E58A1FE7C64A46BAD0FE1558C43D9201363CEE@es1.ic-sa.com> Hello all, I am having very unusual problem with the CSM. This is what my problems. I have my active CSM setup for a Fault Tolerance group with a priority of 100 and an alternate of 30 and set to preempt. Now for some reason I cannot get the standby configure to get the configuration from the Active. I did a debug and it appears the CSM on the standby is deleting it's configuration and the active fails to sends its configuration. So I know the Active is talking across the VLAN I have created for this purpose. I can see the information coming up on my debug from both ends. Below is my configuration. Any help on this is appreciated. Thank you in advance. DR01.SNATXDC1# show module csm 8 ft detail FT group 2, vlan 45 This box is active Configuration is out-of-sync priority 100, heartbeat 1, failover 3, preemption is on alternate priority 30 total buffer count 6214, illegal state transitions 0 receive buffers not committed 0, send buffers not committed 0 updates: sent 4, received 0, committed 0 coup msgs: sent 0, received 0 election msgs: sent 0, received 2 heartbeat msgs: sent 1057, received 594 relinquish msgs: sent 0, received 0 conn replicate msgs: sent 462, received 0 conn refresh msgs: sent 462, received 0 conn reset msgs: sent 61, received 0 conn redundancy errors: msgs lost 0, msgs rejected 0 packets: total received 0, total dropped 0, duplicates 0 checksum failed 0, dumped 0, buffer unavailable 0 number of state updates in last 8 transfers: 0 0 0 0 0 0 0 0 Critical device and interface tracking: DR01.SNATXDC1# DR02.SNATXDC1#show module csm 8 ft detail FT group 2, vlan 45 This box is in standby state Configuration is out-of-sync priority 10, heartbeat 1, failover 3, preemption is off total buffer count 6214, illegal state transitions 10 receive buffers not committed 0, send buffers not committed 0 updates: sent 4, received 0, committed 0 coup msgs: sent 0, received 0 election msgs: sent 2, received 0 heartbeat msgs: sent 0, received 984 relinquish msgs: sent 0, received 0 conn replicate msgs: sent 0, received 0 conn refresh msgs: sent 0, received 0 conn reset msgs: sent 0, received 0 conn redundancy errors: msgs lost 0, msgs rejected 0 packets: total received 5056012, total dropped 0, duplicates 0 checksum failed 0, dumped 0, buffer unavailable 0 number of state updates in last 8 transfers: 0 0 0 0 0 0 0 0 Critical device and interface tracking: DR02.SNATXDC1# ! ft group 2 vlan 45 priority 100 alt 30 preempt DR02.SNATXDC1#show run module 8 Building configuration... Current configuration : 5 bytes end DR02.SNATXDC1#???? M.A.R From thegameiam at yahoo.com Wed Jan 12 21:23:25 2011 From: thegameiam at yahoo.com (David Barak) Date: Wed, 12 Jan 2011 19:23:25 -0800 (PST) Subject: Is NAT can provide some kind of protection? In-Reply-To: References: <15191.1294852587@localhost> Message-ID: <924610.29401.qm@web31816.mail.mud.yahoo.com> I hesitate to venture into this thread, but while Owen is correct in the general case ("NAT qua NAT provides no more security than a stateful firewall"), there is a corner case in which security is improved via NAT. The case is that of an enterprise network which uses 1918 addressing for all internal hosts, and uses proxies or other bastions as middleboxes to relay outbound communication. The security provided is that in the event of an accidental bridging of "inside" and "outside" networks (i.e. engineer plugged a cable between the wrong two switches), the hosts will not be able to initiate communication with Internet hosts. Additionally, this same resiliency to accidental bridging does mean that the enterprise has a smaller number of possible Internet-facing machines, and thus can spend the time and effort to make them more robust. That benefit is not huge (and not relevant to the typical home user, who is not configuring a super-duper scanning proxy server), but it does exist, and it certainly fuels some of the pro-NAT feeling I've encountered among customers. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com From owen at delong.com Wed Jan 12 21:33:32 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 12 Jan 2011 19:33:32 -0800 Subject: Is NAT can provide some kind of protection? In-Reply-To: <924610.29401.qm@web31816.mail.mud.yahoo.com> References: <15191.1294852587@localhost> <924610.29401.qm@web31816.mail.mud.yahoo.com> Message-ID: <0F48ED38-0D21-4951-BBA6-71CF3E8F0EFE@delong.com> On Jan 12, 2011, at 7:23 PM, David Barak wrote: > I hesitate to venture into this thread, but while Owen is correct in the general > case ("NAT qua NAT provides no more security than a stateful firewall"), there > is a corner case in which security is improved via NAT. The case is that of an > enterprise network which uses 1918 addressing for all internal hosts, and uses > proxies or other bastions as middleboxes to relay outbound communication. > > The security provided is that in the event of an accidental bridging of "inside" > and "outside" networks (i.e. engineer plugged a cable between the wrong two > switches), the hosts will not be able to initiate communication with Internet > hosts. Additionally, this same resiliency to accidental bridging does mean that > the enterprise has a smaller number of possible Internet-facing machines, and > thus can spend the time and effort to make them more robust. > > That benefit is not huge (and not relevant to the typical home user, who is not > configuring a super-duper scanning proxy server), but it does exist, and it > certainly fuels some of the pro-NAT feeling I've encountered among customers. > David Barak > Need Geek Rock? Try The Franchise: > http://www.listentothefranchise.com > > > If you are proxying everything, then, there isn't any actual NAT. There are inside sessions and outside sessions. In that case, your security comes from the disconnected addresses and the proxy that sits in the middle interfacing every outside session with its related inside session. No packet is forwarded from inside to outside with only the address and port fields mangled. Each session is a separate and distinct interior and exterior session. There is a state machine between the internal client and the proxy server and a separate state machine between the external server and the proxy client. Separate sets of sequence numbers, etc. I am not denying that you may be able to get some additional isolation by having network numbers that aren't routable on the outside world if you don't have NAT. I'm saying that if you have NAT, it doesn't add to your security. Owen From richard.barnes at gmail.com Wed Jan 12 21:49:15 2011 From: richard.barnes at gmail.com (Richard Barnes) Date: Wed, 12 Jan 2011 22:49:15 -0500 Subject: IPv6 prefix lengths Message-ID: Hi all, What IPv6 prefix lengths are people accepting in BGP from peers/customers? My employer just got a /48 allocation from ARIN, and we're trying to figure out how to support multiple end sites out of this (probably around 10). I was thinking about assigning a /56 per site, but looking at the BGP table stats on potaroo.net [1], it looks like this is not too common (only .29% of prefixes). Thoughts? Thanks, --Richard [1] From ml at kenweb.org Wed Jan 12 21:54:23 2011 From: ml at kenweb.org (ML) Date: Wed, 12 Jan 2011 22:54:23 -0500 Subject: IPv6 prefix lengths In-Reply-To: References: Message-ID: <4D2E776F.2080400@kenweb.org> On 1/12/2011 10:49 PM, Richard Barnes wrote: > Hi all, > > What IPv6 prefix lengths are people accepting in BGP from > peers/customers? My employer just got a /48 allocation from ARIN, and > we're trying to figure out how to support multiple end sites out of > this (probably around 10). I was thinking about assigning a /56 per > site, but looking at the BGP table stats on potaroo.net [1], it looks > like this is not too common (only .29% of prefixes). Thoughts? > > Thanks, > --Richard > > > [1] > Are you talking about assigning /56s per POP, enterprise site? If /56s are just in your iBGP..shouldn't be a problem. You're going to aggregate and just announce your /48 to your eBGP peers, yes?? From marka at isc.org Wed Jan 12 22:01:13 2011 From: marka at isc.org (Mark Andrews) Date: Thu, 13 Jan 2011 15:01:13 +1100 Subject: IPv6 prefix lengths In-Reply-To: Your message of "Wed, 12 Jan 2011 22:54:23 CDT." <4D2E776F.2080400@kenweb.org> References: <4D2E776F.2080400@kenweb.org> Message-ID: <20110113040113.B46688BC750@drugs.dv.isc.org> In message <4D2E776F.2080400 at kenweb.org>, ML writes: > On 1/12/2011 10:49 PM, Richard Barnes wrote: > > Hi all, > > > > What IPv6 prefix lengths are people accepting in BGP from > > peers/customers? My employer just got a /48 allocation from ARIN, and > > we're trying to figure out how to support multiple end sites out of > > this (probably around 10). I was thinking about assigning a /56 per > > site, but looking at the BGP table stats on potaroo.net [1], it looks > > like this is not too common (only .29% of prefixes). Thoughts? > > > > Thanks, > > --Richard > > > > > > [1] > > > > Are you talking about assigning /56s per POP, enterprise site? > > If /56s are just in your iBGP..shouldn't be a problem. You're going to > aggregate and just announce your /48 to your eBGP peers, yes?? If there are multiple indendent end sites then get a /48 for each of them. A /48 is for a SITE not a ENTERPRISE. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From rcarpen at network1.net Wed Jan 12 22:02:33 2011 From: rcarpen at network1.net (Randy Carpenter) Date: Wed, 12 Jan 2011 23:02:33 -0500 (EST) Subject: IPv6 prefix lengths In-Reply-To: Message-ID: <365547814.2677.1294891353187.JavaMail.root@zimbra.network1.net> If you are going to have each site connected separately to the outside world, you will want a /48 for each site. If you are going to aggregate them internally, you can use whatever you want, although you should be able to get a /48 for each site anyway. You don't want to announce anything longer than a /48 to the outside world. -Randy -- | Randy Carpenter | Vice President - IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (800)578-6381, Opt. 1 ---- ----- Original Message ----- > Hi all, > > What IPv6 prefix lengths are people accepting in BGP from > peers/customers? My employer just got a /48 allocation from ARIN, and > we're trying to figure out how to support multiple end sites out of > this (probably around 10). I was thinking about assigning a /56 per > site, but looking at the BGP table stats on potaroo.net [1], it looks > like this is not too common (only .29% of prefixes). Thoughts? > > Thanks, > --Richard > > > [1] From jcdill.lists at gmail.com Wed Jan 12 22:28:51 2011 From: jcdill.lists at gmail.com (JC Dill) Date: Wed, 12 Jan 2011 20:28:51 -0800 Subject: co-location and access to your server In-Reply-To: <4D2E4748.2080504@mompl.net> References: <4D2E0DF2.4010301@mompl.net><4D2E1592.4090805@earthlink.net> <4D2E1DBE.7050500@mompl.net> <5A6D953473350C4B9995546AFE9939EE0BC13322@RWC-EX1.corp.seven.com> <4D2E272A.9040607@steadfast.net> <5A6D953473350C4B9995546AFE9939EE0BC1332C@RWC-EX1.corp.seven.com> <4D2E4748.2080504@mompl.net> Message-ID: <4D2E7F83.2020405@gmail.com> On 12/01/11 4:28 PM, Jeroen van Aart wrote: > George Bonser wrote: >> Awesome. It's good to know that there are still operations like that >> around. That is probably found more often in local providers and not >> so often in the big operations. The more community oriented >> providers would be much more accepting of such a situation than a >> large operation. > > Community oriented provider, that's what I am talking about. I just > couldn't find the right term. > >> but having someone "on call" probably isn't that bad if it is >> infrequently needed. > > I'd be willing to pay extra for access after hours, either a recurring > fee or on a case by case basis. I am not searching for the cheapest > option and demanding that in addition my car be detailed weekly. But > just some co-locating space for one or a few servers where I don't > have to plan a week ahead or miss half a day of $dayjob in order to > work on it (which would cost me more). Scruz is ~30-45 minutes from the heart of the internet on the west coast (Silicon Valley). If your $dayjob isn't in scruz, then it's most likely IN Silicon Valley. So locate your 1U server in Silicon Valley, where there are a plethora of colos with varying costs and access options. I suggest looking at layer42 - the last time I did a RFQ for a 1U server, they had the best price and most robust colo (providers and peering, adequate cooling, backup power, etc.) over other providers (offering 1U services) in the SF Bay Area. Yes, if you have an outage at night you have a longer drive to the colo. But it does no you good to locate your server in a "closer" colo if you can't access it at night anyway! From the colo provider's perspective, 1U clients are the least profitable clients. Setting them up and servicing them involves the most paperwork and communication "per dollar", and 1U clients tend to need more hand holding, ask stupid questions, etc. on average than bigger clients. To further complicate matters, 1U clients tend to be VERY cost conscious, so they don't want to pay what it really costs the colo to provide service to a 1U client (factoring in the sales time cost, the customer service time cost, etc.). jc From owen at delong.com Wed Jan 12 22:31:17 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 12 Jan 2011 20:31:17 -0800 Subject: IPv6 prefix lengths In-Reply-To: References: Message-ID: <4F00500B-6FCD-4879-98D1-59E98D674712@delong.com> If you have to route them separately, your best bet is to go back to ARIN under the Multiple Discreet Networks policy and get a block of /48s. Tastes great, fewer problems. Owen On Jan 12, 2011, at 7:49 PM, Richard Barnes wrote: > Hi all, > > What IPv6 prefix lengths are people accepting in BGP from > peers/customers? My employer just got a /48 allocation from ARIN, and > we're trying to figure out how to support multiple end sites out of > this (probably around 10). I was thinking about assigning a /56 per > site, but looking at the BGP table stats on potaroo.net [1], it looks > like this is not too common (only .29% of prefixes). Thoughts? > > Thanks, > --Richard > > > [1] From nenolod at systeminplace.net Wed Jan 12 22:39:47 2011 From: nenolod at systeminplace.net (William Pitcock) Date: Wed, 12 Jan 2011 22:39:47 -0600 Subject: IPv6 prefix lengths In-Reply-To: References: Message-ID: <20110112223947.1232d008@petrie.gateway.2wire.net> Hi, On Wed, 12 Jan 2011 22:49:15 -0500 Richard Barnes wrote: > Hi all, > > What IPv6 prefix lengths are people accepting in BGP from > peers/customers? My employer just got a /48 allocation from ARIN, and > we're trying to figure out how to support multiple end sites out of > this (probably around 10). I was thinking about assigning a /56 per > site, but looking at the BGP table stats on potaroo.net [1], it looks > like this is not too common (only .29% of prefixes). Thoughts? Traditionally, /48s are per-site. You should get a /48 for each site, in reality something like a /44 will do nicely giving you two additional /48 for growth. William From rdobbins at arbor.net Wed Jan 12 22:47:05 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 13 Jan 2011 04:47:05 +0000 Subject: Is NAT can provide some kind of protection? In-Reply-To: References: Message-ID: <2FAD474E-E339-46B3-9A46-7561DB518CCB@arbor.net> On Mar 21, 2007, at 5:41 AM, Tarig Ahmed wrote: > Security guy told me is not correct to assign public ip to a server, it should have private ip for security reasons. He's wrong. > Is it true that NAT can provide more security? No, it makes things worse from an availability perspective. Servers should never be NATted or placed behind a stateful firewall. ----------------------------------------------------------------------- Roland Dobbins // Sell your computer and buy a guitar. From leviathan at darktech.org Wed Jan 12 23:02:36 2011 From: leviathan at darktech.org (Justin Scott) Date: Thu, 13 Jan 2011 00:02:36 -0500 Subject: Is NAT can provide some kind of protection? In-Reply-To: <2FAD474E-E339-46B3-9A46-7561DB518CCB@arbor.net> References: <2FAD474E-E339-46B3-9A46-7561DB518CCB@arbor.net> Message-ID: Unfortunately there are some sets of requirements which require this type of configuration. The PCI-DSS comes to mind for those who deal with credit card transactions. -Justin On Wednesday, January 12, 2011, Dobbins, Roland wrote: > > On Mar 21, 2007, at 5:41 AM, Tarig Ahmed wrote: > >> Security guy told me is not correct to assign public ip to a server, it should have private ip for security reasons. > > He's wrong. > >> Is it true that NAT can provide more security? > > > No, it makes things worse from an availability perspective. ?Servers should never be NATted or placed behind a stateful firewall. > > ----------------------------------------------------------------------- > Roland Dobbins // > > ? ? ? ? ? ? Sell your computer and buy a guitar. > > > > > From cb.list6 at gmail.com Wed Jan 12 23:25:08 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Wed, 12 Jan 2011 21:25:08 -0800 Subject: IPv6 prefix lengths In-Reply-To: References: Message-ID: On Jan 12, 2011 7:50 PM, "Richard Barnes" wrote: > > Hi all, > > What IPv6 prefix lengths are people accepting in BGP from > peers/customers? My employer just got a /48 allocation from ARIN, and > we're trying to figure out how to support multiple end sites out of > this (probably around 10). I was thinking about assigning a /56 per > site, but looking at the BGP table stats on potaroo.net [1], it looks > like this is not too common (only .29% of prefixes). Thoughts? > Is it possible you should be using PA space from your ISP? An ISP would have no issue providing a /48 per site. Not too many details were given about your requirements or circumstances ... PA may fit. > Thanks, > --Richard > > > [1] > From rdobbins at arbor.net Wed Jan 12 23:24:24 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 13 Jan 2011 05:24:24 +0000 Subject: Is NAT can provide some kind of protection? In-Reply-To: References: <2FAD474E-E339-46B3-9A46-7561DB518CCB@arbor.net> Message-ID: <86D0FE79-5E2A-417A-8293-45D40C533F32@arbor.net> On Jan 13, 2011, at 12:02 AM, Justin Scott wrote: > The PCI-DSS comes to mind for those who deal with credit card transactions. Luckily, there are ways to 'comply' with the PCI-DSS security theater regime without placing the availability and overall security of one's public-facing servers at risk, starting with mod_security. ;> ----------------------------------------------------------------------- Roland Dobbins // Sell your computer and buy a guitar. From owen at delong.com Thu Jan 13 00:01:04 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 12 Jan 2011 22:01:04 -0800 Subject: Is NAT can provide some kind of protection? In-Reply-To: References: <2FAD474E-E339-46B3-9A46-7561DB518CCB@arbor.net> Message-ID: <4B795F7A-2D6F-4BCE-9261-725D82A98974@delong.com> PCI DSS does not require it. It suggests it. It allows you to do other things which show equivalent security. Also, the PCI DSS requirements for NAT are not on the web server, they are on the back-end processing machine which should NOT be the same machine that is talking to the customers. (I believe that's also part of the PCI DSS, but, I haven't read it recently). PCI DSS is in desperate need of revision and does not incorporate current knowledge. Owen On Jan 12, 2011, at 9:02 PM, Justin Scott wrote: > Unfortunately there are some sets of requirements which require this > type of configuration. The PCI-DSS comes to mind for those who deal > with credit card transactions. > > -Justin > > On Wednesday, January 12, 2011, Dobbins, Roland wrote: >> >> On Mar 21, 2007, at 5:41 AM, Tarig Ahmed wrote: >> >>> Security guy told me is not correct to assign public ip to a server, it should have private ip for security reasons. >> >> He's wrong. >> >>> Is it true that NAT can provide more security? >> >> >> No, it makes things worse from an availability perspective. Servers should never be NATted or placed behind a stateful firewall. >> >> ----------------------------------------------------------------------- >> Roland Dobbins // >> >> Sell your computer and buy a guitar. >> >> >> >> >> From surfer at mauigateway.com Thu Jan 13 01:10:16 2011 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 12 Jan 2011 23:10:16 -0800 Subject: Is Cisco equpiment de facto for you? Message-ID: <20110112231016.627D05AD@resin05.mta.everyone.net> --- brandon.kim at brandontek.com wrote: From: Brandon Kim To be fair to Cisco and maybe I'm way off here. But it seems they do come out with a way to do things first which then become a standard that they have to follow. ISL/DOT1Q HSRP/VRRP etherchannel/LACP ------------------------------------ A bit of a late response, but http://en.wikipedia.org/wiki/Multiprotocol_Label_Switching#History scott From dave.nanog at alfordmedia.com Thu Jan 13 01:29:59 2011 From: dave.nanog at alfordmedia.com (Dave Pooser) Date: Thu, 13 Jan 2011 01:29:59 -0600 Subject: Is NAT can provide some kind of protection? In-Reply-To: <17024986-9DA5-4244-BF31-759B075AFE0D@delong.com> Message-ID: On 1/12/11 1:03 PM, "Owen DeLong" wrote: > NATing IPv6 doesn't do anything good. There's no benefit, only cost. Except for making sure you can switch providers without renumbering, which can be a significant benefit. (Yes, PI space accomplishes the same thing, but that's harder to get for most SMBs.) -- Dave Pooser, ACSA Manager of Information Services Alford Media http://www.alfordmedia.com From kaeo at merike.com Thu Jan 13 01:44:53 2011 From: kaeo at merike.com (Merike Kaeo) Date: Wed, 12 Jan 2011 23:44:53 -0800 Subject: Is NAT can provide some kind of protection? In-Reply-To: <4B795F7A-2D6F-4BCE-9261-725D82A98974@delong.com> References: <2FAD474E-E339-46B3-9A46-7561DB518CCB@arbor.net> <4B795F7A-2D6F-4BCE-9261-725D82A98974@delong.com> Message-ID: <3FDC4B2B-4195-4B70-B2EB-11580D57C60F@merike.com> PCI DSS just came up with version 2 in October 2010 and one of the changes was: "Removed specific references to IP masquerading and use of network address translation (NAT) technologies and added examples of methods for preventing private IP address disclosure." - merike On Jan 12, 2011, at 10:01 PM, Owen DeLong wrote: > PCI DSS does not require it. It suggests it. It allows you to do other things > which show equivalent security. > > Also, the PCI DSS requirements for NAT are not on the web server, they > are on the back-end processing machine which should NOT be the same > machine that is talking to the customers. (I believe that's also part of the > PCI DSS, but, I haven't read it recently). > > PCI DSS is in desperate need of revision and does not incorporate > current knowledge. > > Owen > > On Jan 12, 2011, at 9:02 PM, Justin Scott wrote: > >> Unfortunately there are some sets of requirements which require this >> type of configuration. The PCI-DSS comes to mind for those who deal >> with credit card transactions. >> >> -Justin >> >> On Wednesday, January 12, 2011, Dobbins, Roland wrote: >>> >>> On Mar 21, 2007, at 5:41 AM, Tarig Ahmed wrote: >>> >>>> Security guy told me is not correct to assign public ip to a server, it should have private ip for security reasons. >>> >>> He's wrong. >>> >>>> Is it true that NAT can provide more security? >>> >>> >>> No, it makes things worse from an availability perspective. Servers should never be NATted or placed behind a stateful firewall. >>> >>> ----------------------------------------------------------------------- >>> Roland Dobbins // >>> >>> Sell your computer and buy a guitar. >>> >>> >>> >>> >>> > > From jsw at inconcepts.biz Thu Jan 13 02:40:37 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Thu, 13 Jan 2011 03:40:37 -0500 Subject: IPv6 prefix lengths In-Reply-To: References: Message-ID: Richard's employer is exactly the kind of organization that has not been able to effectively multi-home their discrete branch-offices on the IPv4 Internet, because RIR allocation policy set the bar for receiving IPv4 addresses for those small locations just high enough to steer us away from that "feature" or "problem," depending on how you look at it. If every Richard Barnes announces a few dozen /48s into the global BGP table, it will not be long before the 300k+ IPv4 BGP table looks neat and organized, and the CIDR Report will come out each week with a message begging e.g. Starbucks to aggregate their coffee shop wireless hot-spots, instead of shaming Bell South for having a large number of de-aggregates for their substantial ISP business. Most people do not know about the "multi-homing feature" designed into IPv6. Most people who do, seem to agree that it may not see enough practical use to have meaningful impact on routing table growth, which will no longer be kept in check by a limited pool of IP addresses and policies that make it a little difficult for a very small network to become multi-homed. This may be another looming IPv6 headache without a sufficient solution to set good practices now, before deployment sky-rockets. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From owen at delong.com Thu Jan 13 03:49:46 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 13 Jan 2011 01:49:46 -0800 Subject: IPv6 prefix lengths In-Reply-To: References: Message-ID: <3F57B570-4E67-4118-9DB4-03242AD9CACC@delong.com> > Most people do not know about the "multi-homing feature" designed into > IPv6. Most people who do, seem to agree that it may not see enough > practical use to have meaningful impact on routing table growth, which > will no longer be kept in check by a limited pool of IP addresses and > policies that make it a little difficult for a very small network to > become multi-homed. > > This may be another looming IPv6 headache without a sufficient > solution to set good practices now, before deployment sky-rockets. > It's well known that IPv6 will require a scalable routing solution and that one has not yet been developed. I'll be surprised if there isn't more progress out of IETF on this issue in the near future. Owen From michiel at klaver.it Thu Jan 13 04:09:13 2011 From: michiel at klaver.it (Michiel Klaver) Date: Thu, 13 Jan 2011 11:09:13 +0100 Subject: IPv6 prefix lengths In-Reply-To: References: Message-ID: <4D2ECF49.7050904@klaver.it> At 22-07-28164 20:59, Richard Barnes wrote: > Hi all, > > What IPv6 prefix lengths are people accepting in BGP from > peers/customers? My employer just got a /48 allocation from ARIN, and > we're trying to figure out how to support multiple end sites out of > this (probably around 10). I was thinking about assigning a /56 per > site, but looking at the BGP table stats on potaroo.net [1], it looks > like this is not too common (only .29% of prefixes). Thoughts? > > Thanks, > Hi Richard, Most major transit providers with IPv6 support filter at a maximum prefix length of /48 [1] Also, some guidance in subnetting can be found at several places on the web [2] [1] http://en.wikipedia.org/wiki/Comparison_of_IPv6_support_by_major_transit_providers [2] http://en.wikipedia.org/wiki/IPv6_subnetting_reference From mohacsi at niif.hu Thu Jan 13 04:13:21 2011 From: mohacsi at niif.hu (Mohacsi Janos) Date: Thu, 13 Jan 2011 11:13:21 +0100 (CET) Subject: IPv6 prefix lengths In-Reply-To: <3F57B570-4E67-4118-9DB4-03242AD9CACC@delong.com> References: <3F57B570-4E67-4118-9DB4-03242AD9CACC@delong.com> Message-ID: On Thu, 13 Jan 2011, Owen DeLong wrote: >> Most people do not know about the "multi-homing feature" designed into >> IPv6. Most people who do, seem to agree that it may not see enough >> practical use to have meaningful impact on routing table growth, which >> will no longer be kept in check by a limited pool of IP addresses and >> policies that make it a little difficult for a very small network to >> become multi-homed. >> >> This may be another looming IPv6 headache without a sufficient >> solution to set good practices now, before deployment sky-rockets. >> > It's well known that IPv6 will require a scalable routing solution and that > one has not yet been developed. I'll be surprised if there isn't more > progress out of IETF on this issue in the near future. Dear Owen, If you have some idea in your mind propose something for IETF. BoF sessions are open for completely new proposal: http://www.ietf.org/iesg/bof-procedures.html or you can directly propose something for the particular wg: http://datatracker.ietf.org/wg/ Best Regards, Janos Mohacsi From eugen at leitl.org Thu Jan 13 04:42:52 2011 From: eugen at leitl.org (Eugen Leitl) Date: Thu, 13 Jan 2011 11:42:52 +0100 Subject: anyone using Netgear GSM7352S-200 ? Message-ID: <20110113104252.GH16518@leitl.org> This is way offtopic, but I figured this would be a good place to ask. Anyone using Netgear GSM7352S-200 in production? http://www.netgear.com/images/GSM7328Sv2_GSM7352Sv2_23Sept1018-10817.pdf I know, it's Netgear, but how badly does it blow chunks? Inquiring minds, etc. (Disclaimer: I am currently using Netgear and HP ProCurve, and thought to upgrade to Juniper, or at least ProCurve, but have severe budget issues: 6 kEUR for 2x 48-port switches). From luigi at net.t-labs.tu-berlin.de Thu Jan 13 07:04:49 2011 From: luigi at net.t-labs.tu-berlin.de (Luigi Iannone) Date: Thu, 13 Jan 2011 14:04:49 +0100 Subject: IPv6 prefix lengths In-Reply-To: <3F57B570-4E67-4118-9DB4-03242AD9CACC@delong.com> References: <3F57B570-4E67-4118-9DB4-03242AD9CACC@delong.com> Message-ID: <28C0BE93-B038-4C70-8029-24C75D11E2EC@net.t-labs.tu-berlin.de> On Jan 13, 2011, at 10:49 , Owen DeLong wrote: >> Most people do not know about the "multi-homing feature" designed into >> IPv6. Most people who do, seem to agree that it may not see enough >> practical use to have meaningful impact on routing table growth, which >> will no longer be kept in check by a limited pool of IP addresses and >> policies that make it a little difficult for a very small network to >> become multi-homed. >> >> This may be another looming IPv6 headache without a sufficient >> solution to set good practices now, before deployment sky-rockets. >> > It's well known that IPv6 will require a scalable routing solution and that > one has not yet been developed. I'll be surprised if there isn't more > progress out of IETF on this issue in the near future. > The RRG of the IRTF has spent the last two years on this topic. A summary of the discussed solutions can be find in: http://tools.ietf.org/html/draft-irtf-rrg-recommendation-16 A spin off of that activity is the LISP WG in the IETF (https://datatracker.ietf.org/wg/lisp/charter/) Luigi > Owen > > From cra at WPI.EDU Thu Jan 13 07:18:00 2011 From: cra at WPI.EDU (Chuck Anderson) Date: Thu, 13 Jan 2011 08:18:00 -0500 Subject: Is Cisco equpiment de facto for you? In-Reply-To: <20110112231016.627D05AD@resin05.mta.everyone.net> References: <20110112231016.627D05AD@resin05.mta.everyone.net> Message-ID: <20110113131800.GG17336@angus.ind.WPI.EDU> On Wed, Jan 12, 2011 at 11:10:16PM -0800, Scott Weeks wrote: > To be fair to Cisco and maybe I'm way off here. But it seems they do > come out with a way to do things first which then become a standard > that they have to follow. > > ISL/DOT1Q > HSRP/VRRP > etherchannel/LACP Yes, and then they keep their proprietary implementation instead of phasing it out, and no one migrates to the standard one which leads to vendor lockin. From herro91 at gmail.com Thu Jan 13 08:01:40 2011 From: herro91 at gmail.com (Herro91) Date: Thu, 13 Jan 2011 09:01:40 -0500 Subject: Is Cisco equpiment de facto for you? In-Reply-To: <20110113131800.GG17336@angus.ind.WPI.EDU> References: <20110112231016.627D05AD@resin05.mta.everyone.net> <20110113131800.GG17336@angus.ind.WPI.EDU> Message-ID: >From my experience - A key thing to consider from any vendor is their support - Cisco has great support and a large support organization. I've seen them turn around complex problems very rapidly for their customers. Additionally, someone already mentioned investment protection and that Cisco keeps providing incremental improvements such that older 12000s are still up and running AND supported. When making an important purchase, these are among the top IMHO. HTH.... On Thu, Jan 13, 2011 at 8:18 AM, Chuck Anderson wrote: > On Wed, Jan 12, 2011 at 11:10:16PM -0800, Scott Weeks wrote: > > To be fair to Cisco and maybe I'm way off here. But it seems they do > > come out with a way to do things first which then become a standard > > that they have to follow. > > > > ISL/DOT1Q > > HSRP/VRRP > > etherchannel/LACP > > Yes, and then they keep their proprietary implementation instead of > phasing it out, and no one migrates to the standard one which leads to > vendor lockin. > > From brandon.kim at brandontek.com Thu Jan 13 08:46:19 2011 From: brandon.kim at brandontek.com (Brandon Kim) Date: Thu, 13 Jan 2011 09:46:19 -0500 Subject: Is Cisco equpiment de facto for you? In-Reply-To: <20110113131800.GG17336@angus.ind.WPI.EDU> References: <20110112231016.627D05AD@resin05.mta.everyone.net>, <20110113131800.GG17336@angus.ind.WPI.EDU> Message-ID: For ISL, I know they are trying to phase that out. For the exams, they are based on dot1q..... Even if I had all cisco equipment, I'd try to go with standards because you never know down the road where you may need to use another vendor. I wouldn't use EIGRP if given a choice, I'd go with OSPF or RIPv2. > Date: Thu, 13 Jan 2011 08:18:00 -0500 > From: cra at WPI.EDU > To: nanog at nanog.org > Subject: Re: Is Cisco equpiment de facto for you? > > On Wed, Jan 12, 2011 at 11:10:16PM -0800, Scott Weeks wrote: > > To be fair to Cisco and maybe I'm way off here. But it seems they do > > come out with a way to do things first which then become a standard > > that they have to follow. > > > > ISL/DOT1Q > > HSRP/VRRP > > etherchannel/LACP > > Yes, and then they keep their proprietary implementation instead of > phasing it out, and no one migrates to the standard one which leads to > vendor lockin. > From jim at reptiles.org Thu Jan 13 08:57:09 2011 From: jim at reptiles.org (Jim Mercer) Date: Thu, 13 Jan 2011 09:57:09 -0500 Subject: transit providers via FLAG fiber? Message-ID: <20110113145708.GZ80815@reptiles.org> I have been asked to investigate the costs of adding transit capacity for a national ISP in the middle east/asia. they have access to a FLAG landing station. can someone provide pointers as to where to start? private emails would be good, and i'll summarize. thanx. -- Jim Mercer jim at reptiles.org +1 416 410-5633 You are more likely to be arrested as a terrorist than you are to be blown up by one. -- Dianora From tvarriale at comcast.net Thu Jan 13 09:01:01 2011 From: tvarriale at comcast.net (Tony Varriale) Date: Thu, 13 Jan 2011 09:01:01 -0600 Subject: Is Cisco equpiment de facto for you? References: <20110112231016.627D05AD@resin05.mta.everyone.net> <20110113131800.GG17336@angus.ind.WPI.EDU> Message-ID: ----- Original Message ----- From: "Chuck Anderson" To: Sent: Thursday, January 13, 2011 7:18 AM Subject: Re: Is Cisco equpiment de facto for you? > On Wed, Jan 12, 2011 at 11:10:16PM -0800, Scott Weeks wrote: >> To be fair to Cisco and maybe I'm way off here. But it seems they do >> come out with a way to do things first which then become a standard >> that they have to follow. >> >> ISL/DOT1Q >> HSRP/VRRP >> etherchannel/LACP > > Yes, and then they keep their proprietary implementation instead of > phasing it out, and no one migrates to the standard one which leads to > vendor lockin. Which new Cisco gear has ISL support that you are using? And in case you haven't read any documentation or spoke to anyone over there in the last 5 years, Cisco pushes dot1q and lacp extensively. tv From tvarriale at comcast.net Thu Jan 13 09:04:38 2011 From: tvarriale at comcast.net (Tony Varriale) Date: Thu, 13 Jan 2011 09:04:38 -0600 Subject: Is Cisco equpiment de facto for you? References: <20110112231016.627D05AD@resin05.mta.everyone.net>, <20110113131800.GG17336@angus.ind.WPI.EDU> Message-ID: >----- Original Message ----- >From: "Brandon Kim" >To: ; "nanog group" >Sent: Thursday, January 13, 2011 8:46 AM >Subject: RE: Is Cisco equpiment de facto for you? > > >For ISL, I know they are trying to phase that out. For the exams, they are >based on dot1q..... > >Even if I had all cisco equipment, I'd try to go with standards because you >never know down the road where you may >need to use another vendor. > >I wouldn't use EIGRP if given a choice, I'd go with OSPF or RIPv2. The main problem with this is RIP sucks and there aren't a lot of people out there that are really good with OSPF. For every one legit design and implementation of OSPF, I've seen 50 with every thing in 0 and config statements everywhere. For companies that don't have real dedicated networking people, EIGRP is much more easy to admin and troubleshoot. tv From jbates at brightok.net Thu Jan 13 09:54:58 2011 From: jbates at brightok.net (Jack Bates) Date: Thu, 13 Jan 2011 09:54:58 -0600 Subject: Is Cisco equpiment de facto for you? In-Reply-To: References: <20110112231016.627D05AD@resin05.mta.everyone.net>, <20110113131800.GG17336@angus.ind.WPI.EDU> Message-ID: <4D2F2052.8030906@brightok.net> On 1/13/2011 8:46 AM, Brandon Kim wrote: > > For ISL, I know they are trying to phase that out. For the exams, they are based on dot1q..... > > Even if I had all cisco equipment, I'd try to go with standards because you never know down the road where you may > need to use another vendor. > > I wouldn't use EIGRP if given a choice, I'd go with OSPF or RIPv2. > Grrr, IS-IS. SP protocol of choice. Don't believe me, look at some juniper licensing (you'll need to pay us more for IS-IS, but OSPF is available on this cheap enterprise switch for freeeeeeee). Has an annoyance factor of not every vendor supporting it, but lack of IS-IS or some of it's features often shows the caliber of gear you are dealing with or it's current maturity (Brocade MLX had IS-IS v6 support, but didn't support multitopology when I last tested, which gives me an idea of their v6 support compared to vendors such as C/J). OT: Learned my first hard lesson on playing with routing protocols on production network in non-standard ways. MLX was interconnected using single topology to the cisco which was using multitopology. I didn't expect the v6 side to work naturally. Upon upgrading the MLX to a later code, the Juniper isolated by 2 cisco's from the MLX core dumped the routing process repeatedly. Unplugged the MLX, the Juniper stabilized. Gotta love them nasty bugs. Of course, I suspect the bug was related to interconnecting a single topology into a multi-topology, which you really aren't supposed to do. :) Jack From jbates at brightok.net Thu Jan 13 09:59:58 2011 From: jbates at brightok.net (Jack Bates) Date: Thu, 13 Jan 2011 09:59:58 -0600 Subject: Is NAT can provide some kind of protection? In-Reply-To: <0F48ED38-0D21-4951-BBA6-71CF3E8F0EFE@delong.com> References: <15191.1294852587@localhost> <924610.29401.qm@web31816.mail.mud.yahoo.com> <0F48ED38-0D21-4951-BBA6-71CF3E8F0EFE@delong.com> Message-ID: <4D2F217E.9060502@brightok.net> On 1/12/2011 9:33 PM, Owen DeLong wrote: > If you are proxying everything, then, there isn't any actual NAT. There are > inside sessions and outside sessions. > Depends on the proxy mechanism used. In a transparent firewall proxy layout, it generally is still considered NAT. The proxy capabilities of the firewall are additional security measures on top of the NAT (and definitely should be deployed for their higher security value). Jack From rdobbins at arbor.net Thu Jan 13 10:54:43 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 13 Jan 2011 16:54:43 +0000 Subject: Is NAT can provide some kind of protection? In-Reply-To: <4D2F217E.9060502@brightok.net> References: <15191.1294852587@localhost> <924610.29401.qm@web31816.mail.mud.yahoo.com> <0F48ED38-0D21-4951-BBA6-71CF3E8F0EFE@delong.com> <4D2F217E.9060502@brightok.net> Message-ID: <25C8C42F-7545-484B-BA79-E788915BAD33@arbor.net> On Jan 13, 2011, at 9:59 AM, Jack Bates wrote: > The proxy capabilities of the firewall are additional security measures on top of the NAT (and definitely should be deployed for their higher security value). Not in front of servers, they shouldn't - because they have a negative security value in that context. ----------------------------------------------------------------------- Roland Dobbins // Sell your computer and buy a guitar. From jbates at brightok.net Thu Jan 13 11:07:08 2011 From: jbates at brightok.net (Jack Bates) Date: Thu, 13 Jan 2011 11:07:08 -0600 Subject: Is NAT can provide some kind of protection? In-Reply-To: <25C8C42F-7545-484B-BA79-E788915BAD33@arbor.net> References: <15191.1294852587@localhost> <924610.29401.qm@web31816.mail.mud.yahoo.com> <0F48ED38-0D21-4951-BBA6-71CF3E8F0EFE@delong.com> <4D2F217E.9060502@brightok.net> <25C8C42F-7545-484B-BA79-E788915BAD33@arbor.net> Message-ID: <4D2F313C.6000005@brightok.net> On 1/13/2011 10:54 AM, Dobbins, Roland wrote: > > Not in front of servers, they shouldn't - because they have a negative security value in that context. > I agree. Any content checks and reporting should be handled by the server and not a firewall proxy which might have it's own security vulnerabilities (just as likely as the server app having them). That being said, a proxy setup is definitely not unheard of for web servers, though generally not for security purposes as much as content distribution purposes. Jack From info at arin.net Thu Jan 13 11:21:39 2011 From: info at arin.net (ARIN) Date: Thu, 13 Jan 2011 12:21:39 -0500 Subject: Call for ARIN XXVII Meeting Fellowship Applicants Message-ID: <4D2F34A3.3010509@arin.net> ARIN is pleased to offer a Meetings Fellowship Program to bring new voices and ideas to public policy discussions. This call is for Fellows to attend ARIN XXVII in San Juan, Puerto Rico from 10-13 April 2011. If you have never attended an ARIN meeting and are interested in participating in the program, please submit your application by 25 February. The application link, submission instructions, and a detailed description of the program can be found at: https://www.arin.net/participate/meetings/fellowship.html Three Fellows within ARIN's service region will be selected. Fellows receive financial support to attend the Public Policy and Members Meetings, and ARIN Advisory Council representatives will serve as mentors to the Fellows to help maximize their meeting experience. Individuals selected for the fellowship receive: ? Free meeting registration ? Round-trip economy class airfare to the meeting, booked directly by ARIN ? Hotel accommodations at the venue hotel, booked directly by ARIN ? A stipend to cover meals and incidental travel expenses Please contact info at arin.net if you have any questions concerning the program and the application process. Regards, Susan Hamlin Director, Communications and Member Services American Registry for Internet Numbers From bill at herrin.us Thu Jan 13 11:56:58 2011 From: bill at herrin.us (William Herrin) Date: Thu, 13 Jan 2011 12:56:58 -0500 Subject: Is NAT can provide some kind of protection? In-Reply-To: <25C8C42F-7545-484B-BA79-E788915BAD33@arbor.net> References: <15191.1294852587@localhost> <924610.29401.qm@web31816.mail.mud.yahoo.com> <0F48ED38-0D21-4951-BBA6-71CF3E8F0EFE@delong.com> <4D2F217E.9060502@brightok.net> <25C8C42F-7545-484B-BA79-E788915BAD33@arbor.net> Message-ID: On Thu, Jan 13, 2011 at 11:54 AM, Dobbins, Roland wrote: > On Jan 13, 2011, at 9:59 AM, Jack Bates wrote: >> The proxy capabilities of the firewall are additional security >> measures on top of the NAT (and definitely should be >> deployed for their higher security value). > > Not in front of servers, they shouldn't - because they have a negative security value in that context. So all the folks who use reverse proxies like an http accellerator are wrong? -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jbates at brightok.net Thu Jan 13 12:11:27 2011 From: jbates at brightok.net (Jack Bates) Date: Thu, 13 Jan 2011 12:11:27 -0600 Subject: Is NAT can provide some kind of protection? In-Reply-To: References: <15191.1294852587@localhost> <924610.29401.qm@web31816.mail.mud.yahoo.com> <0F48ED38-0D21-4951-BBA6-71CF3E8F0EFE@delong.com> <4D2F217E.9060502@brightok.net> <25C8C42F-7545-484B-BA79-E788915BAD33@arbor.net> Message-ID: <4D2F404F.90204@brightok.net> On 1/13/2011 11:56 AM, William Herrin wrote: > So all the folks who use reverse proxies like an http accellerator are wrong? > > They have their purpose. However, depending on the security rating of the accelerator versus the security rating of the backend server will depend on the negative or positive effect it has on overall security. 1) If backend server has low security rating and proxy also serves to protect backend server flaws, then the proxy has a positive security rating. 2) If backend server is similar or better security rating than the proxy, then the proxy server has a negative security rating, as it has introduced a second application in the channel which can possibly be exploited. ie, you have to worry about backend server security as well as the proxy security, and exploiting either can possibly compromise security for both. Jack From bill at herrin.us Thu Jan 13 12:14:27 2011 From: bill at herrin.us (William Herrin) Date: Thu, 13 Jan 2011 13:14:27 -0500 Subject: Is NAT can provide some kind of protection? In-Reply-To: <4D2F404F.90204@brightok.net> References: <15191.1294852587@localhost> <924610.29401.qm@web31816.mail.mud.yahoo.com> <0F48ED38-0D21-4951-BBA6-71CF3E8F0EFE@delong.com> <4D2F217E.9060502@brightok.net> <25C8C42F-7545-484B-BA79-E788915BAD33@arbor.net> <4D2F404F.90204@brightok.net> Message-ID: On Thu, Jan 13, 2011 at 1:11 PM, Jack Bates wrote: > On 1/13/2011 11:56 AM, William Herrin wrote: >> So all the folks who use reverse proxies like an http accellerator are >> wrong? > > They have their purpose. However, depending on the security rating of the > accelerator versus the security rating of the backend server will depend on > the negative or positive effect it has on overall security. > > 1) If backend server has low security rating and proxy also serves to > protect backend server flaws, then the proxy has a positive security rating. > > 2) If backend server is similar or better security rating than the proxy, > then the proxy server has a negative security rating, as it has introduced a > second application in the channel which can possibly be exploited. ie, you > have to worry about backend server security as well as the proxy security, > and exploiting either can possibly compromise security for both. That's what I think. I'm curious what Roland thinks. -Bill -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From joelja at bogus.com Thu Jan 13 01:17:41 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Thu, 13 Jan 2011 08:17:41 +0100 Subject: IPv6 prefix lengths In-Reply-To: References: Message-ID: <4D2EA715.4090103@bogus.com> if you have multiple sites you should request a direct assignmnet later than /48. previous $employer recieved a /44 direct assignment on the basis of north american footprint. On 1/13/11 4:49 AM, Richard Barnes wrote: > Hi all, > > What IPv6 prefix lengths are people accepting in BGP from > peers/customers? My employer just got a /48 allocation from ARIN, and > we're trying to figure out how to support multiple end sites out of > this (probably around 10). I was thinking about assigning a /56 per > site, but looking at the BGP table stats on potaroo.net [1], it looks > like this is not too common (only .29% of prefixes). Thoughts? > > Thanks, > --Richard > > > [1] > From lowen at pari.edu Thu Jan 13 13:28:15 2011 From: lowen at pari.edu (Lamar Owen) Date: Thu, 13 Jan 2011 14:28:15 -0500 Subject: Is NAT can provide some kind of protection? In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC132F5@RWC-EX1.corp.seven.com> References: Message-ID: <201101131428.15883.lowen@pari.edu> On Wednesday, January 12, 2011 12:01:27 pm George Bonser wrote: > With v4 PAT, you can not > be sure which address/port on the external IP maps to which address/port > on the inside IP at any given moment and PAT is stateful in that an > outbound packet is required to start the mapping. On Cisco at least you can set up static PAT rules and have multiple internal hosts on a single external IP address with static NATting. I've done this in the past, where a webcam application we were using absolutely insisted on binding port 80, and on another host the control application we were using also absolutely insisted on binding port 80, but, for several purposes, we wanted a single external address, so I set up an extendable NAT rule for port 80 on the external IP address to map to the webcam box's port 80, and port 8080 on the external IP address to map to the control application's port 80. Worked fine. But that wasn't for security, unless you consider that hiding the unused ports on those two machines is security. Since then we've found that a lot of firewalls blocked the connection to port 8080, and we had to have the developer restructure the app to handle being on two IP addresses, which was nontrivial thanks to cross-site-scripting blockers. Even my old Linksys WRT54G has 'port forwarding' rules that do static PAT. > NAT66 is just > straight static NAT that maps one prefix to a different prefix. I'm sure that PAT is on the horizon, simply for plumbing purposes to connect the gozinta to the gozouta where wierd application requirements are found (having two applications and javascripts on a single page that access two different backend servers gets blocked by some cross-site scripting 'protections' and thus having the second connection muxed onto the same address can alleviate this). Also, round-robin stateful PAT can be thought of as poor-man's load balancing, and has been used in that use case. And there is the straight NAT non-BGP multihoming use case. But that's also not for security, but for availability. If you wanted IPv6 PAT *now* you could contribute to the MAP66 project and write your own PAT66 (map66.sourceforge.net). But it will be provided by someone; since when have technical issues alone ever kept a feature from being implemented? From mruiz at lstfinancial.com Thu Jan 13 13:35:25 2011 From: mruiz at lstfinancial.com (Michael Ruiz) Date: Thu, 13 Jan 2011 13:35:25 -0600 Subject: Is Cisco equpiment de facto for you? Message-ID: <16E58A1FE7C64A46BAD0FE1558C43D9201363D2A@es1.ic-sa.com> I know where I have worked we have had a mixture of Juniper and Cisco equipment. Personally buying a Juniper Router like a M or a T series is like buying a Ferrari. I like Cisco personally and they are cheaper than buying a Juniper. For example a M-series is always going to cost some bucks after you factor the FPC and the PICS that need to be loaded. Personally I like the JUNOS system better than the Cisco IOS, it is more tech friendly when troubleshooting issues. I have not worked on the new IOS-NX system, but if I understand it correctly it is modular. If Cisco can the really cool Monitor command and the structure the command tree like a Juniper. I would think Cisco did something totally right. M.A.R From cmadams at hiwaay.net Thu Jan 13 13:40:12 2011 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 13 Jan 2011 13:40:12 -0600 Subject: Is Cisco equpiment de facto for you? In-Reply-To: <16E58A1FE7C64A46BAD0FE1558C43D9201363D2A@es1.ic-sa.com> References: <16E58A1FE7C64A46BAD0FE1558C43D9201363D2A@es1.ic-sa.com> Message-ID: <20110113194012.GD19019@hiwaay.net> Once upon a time, Michael Ruiz said: > I like Cisco personally and they are cheaper than > buying a Juniper. For example a M-series is always going to cost some > bucks after you factor the FPC and the PICS that need to be loaded. We didn't find that to be the case, after you factor in all the Cisco pieces that need to be loaded as well. Both make modular routers, so I don't see how saying that one requires modules is a valid argument. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From jbates at brightok.net Thu Jan 13 13:41:04 2011 From: jbates at brightok.net (Jack Bates) Date: Thu, 13 Jan 2011 13:41:04 -0600 Subject: Is Cisco equpiment de facto for you? In-Reply-To: <16E58A1FE7C64A46BAD0FE1558C43D9201363D2A@es1.ic-sa.com> References: <16E58A1FE7C64A46BAD0FE1558C43D9201363D2A@es1.ic-sa.com> Message-ID: <4D2F5550.1080805@brightok.net> On 1/13/2011 1:35 PM, Michael Ruiz wrote: > For example a M-series is always going to cost some > bucks after you factor the FPC and the PICS that need to be loaded. I find this usually has to do with the fact that there is no "backup to software processing" on a Juniper. Every feature it supports, it does so in hardware. If the hardware won't do it, then JUNOS won't do it. The exception has been the multiservices PIC, which is being obsoleted with the trio chipset. You are right, though. If you don't need the performance, you can settle for a cisco in many cases. Also, the MX Juniper line often has nicer performance than the M series if you do more ethernet than sonet. Jack From lowen at pari.edu Thu Jan 13 13:44:57 2011 From: lowen at pari.edu (Lamar Owen) Date: Thu, 13 Jan 2011 14:44:57 -0500 Subject: Is NAT can provide some kind of protection? In-Reply-To: <15191.1294852587@localhost> References: Message-ID: <201101131444.58029.lowen@pari.edu> On Wednesday, January 12, 2011 12:16:27 pm Valdis.Kletnieks at vt.edu wrote: > 140 million compromised PC's, most of them behind a NAT, can't be wrong. :) How many more would there be if most PC's were not behind NAT or stateful firewalling? Or, to turn it on its ear, "Windows is the best OS; 250 million Windows PC's can't be wrong." Uh, yes they can. The various implementations of NAT, the various implementations of stateless and stateful firewalling, and any other ingress protections only cover a few attack vectors; surf-by client-driven web bugs aren't in that set of vectors. However, mechanisms like PVLANs and internal firewalling can help mitigate those, as can host-based protections. From mruiz at lstfinancial.com Thu Jan 13 13:48:27 2011 From: mruiz at lstfinancial.com (Michael Ruiz) Date: Thu, 13 Jan 2011 13:48:27 -0600 Subject: Is Cisco equpiment de facto for you? In-Reply-To: <4D2F5550.1080805@brightok.net> References: <16E58A1FE7C64A46BAD0FE1558C43D9201363D2A@es1.ic-sa.com> <4D2F5550.1080805@brightok.net> Message-ID: <16E58A1FE7C64A46BAD0FE1558C43D9201363D2E@es1.ic-sa.com> >I find this usually has to do with the fact that there is no "backup to >software processing" on a Juniper. Every feature it supports, it does so >in hardware. If the hardware won't do it, then JUNOS won't do it. >The exception has been the multiservices PIC, which is being obsoleted >with the trio chipset. >You are right, though. If you don't need the performance, you can settle >for a cisco in many cases. Also, the MX Juniper line often has nicer >performance than the M series if you do more ethernet than sonet. Yeah another thing I love about the JUNOS is the rollback command. Whew I can tell you a few times where that has saved my bacon a few times and the commit and check command. :-) -----Original Message----- From: Jack Bates [mailto:jbates at brightok.net] Sent: Thursday, January 13, 2011 1:41 PM To: Michael Ruiz Cc: nanog at nanog.org Subject: Re: Is Cisco equpiment de facto for you? On 1/13/2011 1:35 PM, Michael Ruiz wrote: > For example a M-series is always going to cost some > bucks after you factor the FPC and the PICS that need to be loaded. I find this usually has to do with the fact that there is no "backup to software processing" on a Juniper. Every feature it supports, it does so in hardware. If the hardware won't do it, then JUNOS won't do it. The exception has been the multiservices PIC, which is being obsoleted with the trio chipset. You are right, though. If you don't need the performance, you can settle for a cisco in many cases. Also, the MX Juniper line often has nicer performance than the M series if you do more ethernet than sonet. Jack From jbates at brightok.net Thu Jan 13 13:51:22 2011 From: jbates at brightok.net (Jack Bates) Date: Thu, 13 Jan 2011 13:51:22 -0600 Subject: Is Cisco equpiment de facto for you? In-Reply-To: <16E58A1FE7C64A46BAD0FE1558C43D9201363D2E@es1.ic-sa.com> References: <16E58A1FE7C64A46BAD0FE1558C43D9201363D2A@es1.ic-sa.com> <4D2F5550.1080805@brightok.net> <16E58A1FE7C64A46BAD0FE1558C43D9201363D2E@es1.ic-sa.com> Message-ID: <4D2F57BA.3070102@brightok.net> On 1/13/2011 1:48 PM, Michael Ruiz wrote: > Yeah another thing I love about the JUNOS is the rollback command. Whew > I can tell you a few times where that has saved my bacon a few times and > the commit and check command.:-) Cisco IOS has a similar feature. reload in 5 make changes verify things are working reload cancel It's a little different on a redundant processor system, as you have to reload both processors. It's also a 2-20 minute outage while you reload, but it does beat 2 hour drives. Jack From streiner at cluebyfour.org Thu Jan 13 09:55:54 2011 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Thu, 13 Jan 2011 10:55:54 -0500 (EST) Subject: Is Cisco equpiment de facto for you? In-Reply-To: <16E58A1FE7C64A46BAD0FE1558C43D9201363D2E@es1.ic-sa.com> References: <16E58A1FE7C64A46BAD0FE1558C43D9201363D2A@es1.ic-sa.com> <4D2F5550.1080805@brightok.net> <16E58A1FE7C64A46BAD0FE1558C43D9201363D2E@es1.ic-sa.com> Message-ID: On Thu, 13 Jan 2011, Michael Ruiz wrote: > Yeah another thing I love about the JUNOS is the rollback command. Whew > I can tell you a few times where that has saved my bacon a few times and > the commit and check command. :-) Definite +1 for rollback and commit check - and also show | compare jms From swm at emanon.com Thu Jan 13 13:57:25 2011 From: swm at emanon.com (Scott Morris) Date: Thu, 13 Jan 2011 14:57:25 -0500 Subject: Is Cisco equpiment de facto for you? In-Reply-To: <4D2F57BA.3070102@brightok.net> References: <16E58A1FE7C64A46BAD0FE1558C43D9201363D2A@es1.ic-sa.com> <4D2F5550.1080805@brightok.net> <16E58A1FE7C64A46BAD0FE1558C43D9201363D2E@es1.ic-sa.com> <4D2F57BA.3070102@brightok.net> Message-ID: <4D2F5925.70306@emanon.com> The catch is being able to do it without reloading! "commit confirm" will help a lot as well. In case your commit annihilates your ssh session. ;) Scott On 1/13/11 2:51 PM, Jack Bates wrote: > On 1/13/2011 1:48 PM, Michael Ruiz wrote: >> Yeah another thing I love about the JUNOS is the rollback command. Whew >> I can tell you a few times where that has saved my bacon a few times and >> the commit and check command.:-) > > Cisco IOS has a similar feature. > > reload in 5 > make changes > verify things are working > reload cancel > > It's a little different on a redundant processor system, as you have > to reload both processors. It's also a 2-20 minute outage while you > reload, but it does beat 2 hour drives. > > > Jack > > > From bicknell at ufp.org Thu Jan 13 13:57:54 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 13 Jan 2011 11:57:54 -0800 Subject: Is Cisco equpiment de facto for you? In-Reply-To: <16E58A1FE7C64A46BAD0FE1558C43D9201363D2E@es1.ic-sa.com> References: <16E58A1FE7C64A46BAD0FE1558C43D9201363D2A@es1.ic-sa.com> <4D2F5550.1080805@brightok.net> <16E58A1FE7C64A46BAD0FE1558C43D9201363D2E@es1.ic-sa.com> Message-ID: <20110113195754.GA65449@ussenterprise.ufp.org> In a message written on Thu, Jan 13, 2011 at 01:48:27PM -0600, Michael Ruiz wrote: > Yeah another thing I love about the JUNOS is the rollback command. Whew > I can tell you a few times where that has saved my bacon a few times and > the commit and check command. :-) Cisco marketing seems to have dropped the ball on this one, but IOS has had a feature that allows you to save a number of configurations, do diff's, and generally behave similar to the JunOS method for quite a while. You'll want to check out the "archive" command. http://blogs.techrepublic.com.com/networking/?p=532 The only thing I can tell that's really missing is "commit confirmed" in JunOS, and of course it operates differently so people may or may not like it. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From mruiz at lstfinancial.com Thu Jan 13 14:03:00 2011 From: mruiz at lstfinancial.com (Michael Ruiz) Date: Thu, 13 Jan 2011 14:03:00 -0600 Subject: Is Cisco equpiment de facto for you? In-Reply-To: <20110113195754.GA65449@ussenterprise.ufp.org> References: <16E58A1FE7C64A46BAD0FE1558C43D9201363D2A@es1.ic-sa.com> <4D2F5550.1080805@brightok.net> <16E58A1FE7C64A46BAD0FE1558C43D9201363D2E@es1.ic-sa.com> <20110113195754.GA65449@ussenterprise.ufp.org> Message-ID: <16E58A1FE7C64A46BAD0FE1558C43D9201363D2F@es1.ic-sa.com> >Cisco marketing seems to have dropped the ball on this one, but IOS has had a feature that allows you to save a number of configurations, do diff's, and >generally behave similar to the JunOS method for quite a while. You'll want to check out the "archive" command. >http://blogs.techrepublic.com.com/networking/?p=532 >The only thing I can tell that's really missing is "commit confirmed" in JunOS, and of course it operates differently so people may or may not like it. >-- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ Yeah you are right it does have some JUNOS like feel. -----Original Message----- From: Leo Bicknell [mailto:bicknell at ufp.org] Sent: Thursday, January 13, 2011 1:58 PM To: Michael Ruiz Cc: Jack Bates; nanog at nanog.org Subject: Re: Is Cisco equpiment de facto for you? In a message written on Thu, Jan 13, 2011 at 01:48:27PM -0600, Michael Ruiz wrote: > Yeah another thing I love about the JUNOS is the rollback command. > Whew I can tell you a few times where that has saved my bacon a few > times and the commit and check command. :-) Cisco marketing seems to have dropped the ball on this one, but IOS has had a feature that allows you to save a number of configurations, do diff's, and generally behave similar to the JunOS method for quite a while. You'll want to check out the "archive" command. http://blogs.techrepublic.com.com/networking/?p=532 The only thing I can tell that's really missing is "commit confirmed" in JunOS, and of course it operates differently so people may or may not like it. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ From Greg.Whynott at oicr.on.ca Thu Jan 13 14:13:06 2011 From: Greg.Whynott at oicr.on.ca (Greg Whynott) Date: Thu, 13 Jan 2011 15:13:06 -0500 Subject: Is Cisco equpiment de facto for you? In-Reply-To: <20110113194012.GD19019@hiwaay.net> References: <16E58A1FE7C64A46BAD0FE1558C43D9201363D2A@es1.ic-sa.com> <20110113194012.GD19019@hiwaay.net> Message-ID: at one shop were i considered using Juniper instead of a Cisco internet edge router, the cost of the Juniper was so close to the Cisco it was a non consideration. The only reason we went with Cisco that time was due to the fact most of the other gear was Cisco, and it seemed to make more sense to stay with cisco instead of introducing a new vendor/methods into the mix without good reason. The hardware alone was cheaper than the Cisco kit, but after we said we needed to hold a million BGP routes, the prices became very similar. Juniper wants to license you on the amount of routes you intend to receive, if i remember correctly. -g On Jan 13, 2011, at 2:40 PM, Chris Adams wrote: > Once upon a time, Michael Ruiz said: >> I like Cisco personally and they are cheaper than >> buying a Juniper. For example a M-series is always going to cost some >> bucks after you factor the FPC and the PICS that need to be loaded. > > We didn't find that to be the case, after you factor in all the Cisco > pieces that need to be loaded as well. Both make modular routers, so I > don't see how saying that one requires modules is a valid argument. > > -- > Chris Adams > Systems and Network Administrator - HiWAAY Internet Services > I don't speak for anybody but myself - that's enough trouble. > -- This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization. From lowen at pari.edu Thu Jan 13 14:24:33 2011 From: lowen at pari.edu (Lamar Owen) Date: Thu, 13 Jan 2011 15:24:33 -0500 Subject: Is NAT can provide some kind of protection? In-Reply-To: References: Message-ID: <201101131524.34003.lowen@pari.edu> On Wednesday, March 21, 2007 05:41:00 am Tarig Ahmed wrote: > Is it true that NAT can provide more security? Blast from the past.... Whew, is there any subject more guaranteed to cause a long thread than this? :-) I have some ideas on this; there are some creative manglings one can do with NAT that specifically exist to break protocols used by black hats (and others; but if I know a Teredo tunnel isn't used by a server, I should try to break it in as many ways as I can, right?), but lets the desired bits out. Hey, if NAT can make desired protocols break, it can make undesired protocols break, too. Breakage can be considered a feature, depending upon how demented and devious you are. NAT is just another packet tool; like various types of firewalling, it requires intelligent application to be useful. Things like setting up a static PAT for the IRC port on the inside global address to get translated to the IP of an outside IRC server (whose operator has agreed to let you do this, of course!)....or a honeypot IRC server on a different internal network.... can do wonders for the rate of successful entries. I've found by trial and error that outright blocking an attack is far less effective in stopping an intruder than creatively and partially breaking the attack (tarpits, for instance). A quick block will be answered by a quick try at another attack; a tarpit makes nothing quick, and unless it's a targeted-at-you attack to own (most aren't) most attackers will go on to other, lower-hanging, fruit. And I'm sure that I'll continue seeing attacks, and seeing successful workstation exploits, for a long time to come, and neither NAT nor firewalling is much help for certain workstation operating systems in the hands of users who know enough to be dangerous. But one-to-one port-agnostic NAT for a server does nothing to improve security, and, as some have said, will probably make security worse. From tmagill at providecommerce.com Thu Jan 13 14:44:54 2011 From: tmagill at providecommerce.com (Thomas Magill) Date: Thu, 13 Jan 2011 20:44:54 +0000 Subject: Is Cisco equpiment de facto for you? In-Reply-To: <4D2F57BA.3070102@brightok.net> References: <16E58A1FE7C64A46BAD0FE1558C43D9201363D2A@es1.ic-sa.com> <4D2F5550.1080805@brightok.net> <16E58A1FE7C64A46BAD0FE1558C43D9201363D2E@es1.ic-sa.com> <4D2F57BA.3070102@brightok.net> Message-ID: >Cisco IOS has a similar feature. > >reload in 5 >make changes >verify things are working >reload cancel There seems to be a better way to do it in IOS that will not reload the router: http://www.cisco.com/en/US/docs/ios/12_3t/12_3t7/feature/guide/gtrollbk.html I haven't tried it since all my gear has OOB serial mgmt but it appears to let you rollback a config after a set time without a reboot. It still doesn't seem to be as nice as JUNOS rollback. From bblackford at gmail.com Thu Jan 13 14:54:04 2011 From: bblackford at gmail.com (Bill Blackford) Date: Thu, 13 Jan 2011 12:54:04 -0800 Subject: Is Cisco equpiment de facto for you? In-Reply-To: References: <16E58A1FE7C64A46BAD0FE1558C43D9201363D2A@es1.ic-sa.com> <4D2F5550.1080805@brightok.net> <16E58A1FE7C64A46BAD0FE1558C43D9201363D2E@es1.ic-sa.com> <4D2F57BA.3070102@brightok.net> Message-ID: Subway subs started offering toasted as an option in response to the success of Quiznos Subs. So many vendors have been chasing the "me too" feature match behind Cisco for so many years it interesting to see Cisco doing the same behind Juniper. -b -- Bill Blackford Network Engineer Logged into reality and abusing my sudo privileges..... ig after a set time without a reboot. ?It still doesn't seem to be as nice as JUNOS rollback. > > > > -- Bill Blackford Network Engineer Logged into reality and abusing my sudo privileges..... From owen at delong.com Thu Jan 13 14:54:15 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 13 Jan 2011 12:54:15 -0800 Subject: Is NAT can provide some kind of protection? In-Reply-To: <201101131444.58029.lowen@pari.edu> References: <201101131444.58029.lowen@pari.edu> Message-ID: On Jan 13, 2011, at 11:44 AM, Lamar Owen wrote: > On Wednesday, January 12, 2011 12:16:27 pm Valdis.Kletnieks at vt.edu wrote: >> 140 million compromised PC's, most of them behind a NAT, can't be wrong. :) > > How many more would there be if most PC's were not behind NAT or stateful firewalling? > Here you've hit the key... "or stateful firewalling". Stateful firewalling provides the security. NAT just mangles the header. Overloaded NAT depends inherently on the stateful firewall and this has lead to confusion where people don't realize that the term "NAT" is often (mis)used to refer to the combined process. Owen From owen at delong.com Thu Jan 13 14:58:49 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 13 Jan 2011 12:58:49 -0800 Subject: Is Cisco equpiment de facto for you? In-Reply-To: <4D2F57BA.3070102@brightok.net> References: <16E58A1FE7C64A46BAD0FE1558C43D9201363D2A@es1.ic-sa.com> <4D2F5550.1080805@brightok.net> <16E58A1FE7C64A46BAD0FE1558C43D9201363D2E@es1.ic-sa.com> <4D2F57BA.3070102@brightok.net> Message-ID: <53B1C18E-BC4A-4520-9C3C-3CEC45286C00@delong.com> On Jan 13, 2011, at 11:51 AM, Jack Bates wrote: > On 1/13/2011 1:48 PM, Michael Ruiz wrote: >> Yeah another thing I love about the JUNOS is the rollback command. Whew >> I can tell you a few times where that has saved my bacon a few times and >> the commit and check command.:-) > > Cisco IOS has a similar feature. > > reload in 5 > make changes > verify things are working > reload cancel > > It's a little different on a redundant processor system, as you have to reload both processors. It's also a 2-20 minute outage while you reload, but it does beat 2 hour drives. > > > Jack Not at all the same... With JunOS, I can have the changes I made running for days, but, when some problem is later discovered I can still rollback to the previous (or several revisions back). I can easily compare the current config to several previous revisions, etc. Additionally, with JunOS I can make all my changes, verify them syntactically, compare the changes made to the previous configuration all without having the changes take effect during the process. Then, when I'm satisfied I have it right, I commit the configuration. If you've ever had to play the IOS ACL rotation game, you know how wonderful this feature is. Cisco's half-hearted attempt to play catch-up here is woefully inadequate. Owen From jbates at brightok.net Thu Jan 13 15:03:50 2011 From: jbates at brightok.net (Jack Bates) Date: Thu, 13 Jan 2011 15:03:50 -0600 Subject: Is Cisco equpiment de facto for you? In-Reply-To: <53B1C18E-BC4A-4520-9C3C-3CEC45286C00@delong.com> References: <16E58A1FE7C64A46BAD0FE1558C43D9201363D2A@es1.ic-sa.com> <4D2F5550.1080805@brightok.net> <16E58A1FE7C64A46BAD0FE1558C43D9201363D2E@es1.ic-sa.com> <4D2F57BA.3070102@brightok.net> <53B1C18E-BC4A-4520-9C3C-3CEC45286C00@delong.com> Message-ID: <4D2F68B6.6080102@brightok.net> On 1/13/2011 2:58 PM, Owen DeLong wrote: >> reload in 5 >> make changes >> verify things are working >> reload cancel >> >> It's a little different on a redundant processor system, as you have to reload both processors. It's also a 2-20 minute outage while you reload, but it does beat 2 hour drives. > > Not at all the same... With JunOS, I can have the changes I made running for days, but, when some problem is later discovered I can still rollback to the previous (or several revisions back). I can easily compare the current config to several previous revisions, etc. > EDIT: From mruiz at lstfinancial.com Thu Jan 13 15:20:57 2011 From: mruiz at lstfinancial.com (Michael Ruiz) Date: Thu, 13 Jan 2011 15:20:57 -0600 Subject: Is Cisco equpiment de facto for you? In-Reply-To: <53B1C18E-BC4A-4520-9C3C-3CEC45286C00@delong.com> References: <16E58A1FE7C64A46BAD0FE1558C43D9201363D2A@es1.ic-sa.com> <4D2F5550.1080805@brightok.net> <16E58A1FE7C64A46BAD0FE1558C43D9201363D2E@es1.ic-sa.com> <4D2F57BA.3070102@brightok.net> <53B1C18E-BC4A-4520-9C3C-3CEC45286C00@delong.com> Message-ID: <16E58A1FE7C64A46BAD0FE1558C43D9201363D3C@es1.ic-sa.com> On Jan 13, 2011, at 11:51 AM, Jack Bates wrote: > On 1/13/2011 1:48 PM, Michael Ruiz wrote: >> Yeah another thing I love about the JUNOS is the rollback command. Whew >> I can tell you a few times where that has saved my bacon a few times and >> the commit and check command.:-) > > Cisco IOS has a similar feature. > > reload in 5 > make changes > verify things are working > reload cancel > > It's a little different on a redundant processor system, as you have to reload both processors. It's also a 2-20 minute outage while you reload, but it does beat 2 hour drives. > > > Jack >Not at all the same... With JunOS, I can have the changes I made running for days, but, when some problem is later discovered I can still rollback to >the previous (or several revisions back). I can easily compare the current config to several previous revisions, etc. >Additionally, with JunOS I can make all my changes, verify them syntactically, compare the changes made to the previous configuration all without having >the changes take effect during the process. Then, when I'm satisfied I have it right, I commit the configuration. If you've ever had to play the IOS ACL >rotation game, you know how wonderful this feature is. >Cisco's half-hearted attempt to play catch-up here is woefully inadequate. >Owen I agree. That is the really neat feature about the rollback command. Like I said before it has saved me more ways the one. :-) -----Original Message----- From: Owen DeLong [mailto:owen at delong.com] Sent: Thursday, January 13, 2011 2:59 PM To: Jack Bates Cc: Michael Ruiz; nanog at nanog.org Subject: Re: Is Cisco equpiment de facto for you? On Jan 13, 2011, at 11:51 AM, Jack Bates wrote: > On 1/13/2011 1:48 PM, Michael Ruiz wrote: >> Yeah another thing I love about the JUNOS is the rollback command. Whew >> I can tell you a few times where that has saved my bacon a few times and >> the commit and check command.:-) > > Cisco IOS has a similar feature. > > reload in 5 > make changes > verify things are working > reload cancel > > It's a little different on a redundant processor system, as you have to reload both processors. It's also a 2-20 minute outage while you reload, but it does beat 2 hour drives. > > > Jack Not at all the same... With JunOS, I can have the changes I made running for days, but, when some problem is later discovered I can still rollback to the previous (or several revisions back). I can easily compare the current config to several previous revisions, etc. Additionally, with JunOS I can make all my changes, verify them syntactically, compare the changes made to the previous configuration all without having the changes take effect during the process. Then, when I'm satisfied I have it right, I commit the configuration. If you've ever had to play the IOS ACL rotation game, you know how wonderful this feature is. Cisco's half-hearted attempt to play catch-up here is woefully inadequate. Owen From lowen at pari.edu Thu Jan 13 15:21:22 2011 From: lowen at pari.edu (Lamar Owen) Date: Thu, 13 Jan 2011 16:21:22 -0500 Subject: Is NAT can provide some kind of protection? In-Reply-To: <094D5B92-6EFA-4A42-9E95-79790EE95BBC@delong.com> References: Message-ID: <201101131621.22592.lowen@pari.edu> On Wednesday, January 12, 2011 03:50:28 pm Owen DeLong wrote: > That's simply not true. Every end user running NAT is running a stateful firewall with a default inbound deny. This is demonstrably not correct. Even in the case of dynamic overloaded NAT, at least on Cisco, there is no firewalling going on (if firewalling is defined as blocking something). It looks like there is, but that's an illusion, a sleight-of-hand, not reality. In the NAT order of operations in IOS at least you'll find NAT occurs before the routing decision does. Thus, if you change the address in the packet header, you change which routing table entry will be used to route that packet. It's the rewriting of the address that then causes the routing to send the packet in a different direction; in practice most of the time there is either no route or a null route to the inside global address or address block, but it doesn't have to be that way. You could easily set up a NAT where the inside local addresses are on, say, GigabitEthernet0/0 and the inside global address(es) are on Null0.... or GigabitEthernet0/1 (where the honeynet or tarpit resides, perhaps?), or whatnot. Packets that don't match the NAT can just be routed elsewhere, not just to a null route, easily enough. The default destination for most cases happens to be a null route; this is certainly a good imitation of a deny. From owen at delong.com Thu Jan 13 15:32:17 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 13 Jan 2011 13:32:17 -0800 Subject: Is NAT can provide some kind of protection? In-Reply-To: <201101131621.22592.lowen@pari.edu> References: <201101131621.22592.lowen@pari.edu> Message-ID: <7730BBF6-6FB4-44E9-A1BA-390C198C9115@delong.com> On Jan 13, 2011, at 1:21 PM, Lamar Owen wrote: > On Wednesday, January 12, 2011 03:50:28 pm Owen DeLong wrote: >> That's simply not true. Every end user running NAT is running a stateful firewall with a default inbound deny. > > This is demonstrably not correct. Even in the case of dynamic overloaded NAT, at least on Cisco, there is no firewalling going on (if firewalling is defined as blocking something). It looks like there is, but that's an illusion, a sleight-of-hand, not reality. In the NAT order of operations in IOS at least you'll find NAT occurs before the routing decision does. Thus, if you change the address in the packet header, you change which routing table entry will be used to route that packet. It's the rewriting of the address that then causes the routing to send the packet in a different direction; in practice most of the time there is either no route or a null route to the inside global address or address block, but it doesn't have to be that way. > The rewriting is done by matching the packet against a state table. No match, no rewrite, no forward. If you have a state table and packets have to match the state table to get forwarded, that is, by definition, a stateful firewall. > You could easily set up a NAT where the inside local addresses are on, say, GigabitEthernet0/0 and the inside global address(es) are on Null0.... or GigabitEthernet0/1 (where the honeynet or tarpit resides, perhaps?), or whatnot. Packets that don't match the NAT can just be routed elsewhere, not just to a null route, easily enough. The default destination for most cases happens to be a null route; this is certainly a good imitation of a deny. The difference between drop, deny, and forward to null0 is a subtlety that doesn't have much to do with the outcome of what happens to the packet. In all cases, the packet is discarded. The bottom line is that a default forward to null0 is a default deny. Yes, it can be overridden like most defaults. Yes, the mechanism for overriding a default deny in an ACL and overriding a default forward to null0 in a state table may be in different parts of the configuration or require different commands, but, it doesn't change the fact that you have a stateful firewall of one form or another. Owen From nickellman at gmail.com Thu Jan 13 16:13:38 2011 From: nickellman at gmail.com (b nickell) Date: Thu, 13 Jan 2011 15:13:38 -0700 Subject: Is Cisco equpiment de facto for you? In-Reply-To: <16E58A1FE7C64A46BAD0FE1558C43D9201363D2A@es1.ic-sa.com> References: <16E58A1FE7C64A46BAD0FE1558C43D9201363D2A@es1.ic-sa.com> Message-ID: Cheers.. to M.A.R.'s related view On Jan 13, 2011 12:37 PM, "Michael Ruiz" wrote: I know where I have worked we have had a mixture of Juniper and Cisco equipment. Personally buying a Juniper Router like a M or a T series is like buying a Ferrari. I like Cisco personally and they are cheaper than buying a Juniper. For example a M-series is always going to cost some bucks after you factor the FPC and the PICS that need to be loaded. Personally I like the JUNOS system better than the Cisco IOS, it is more tech friendly when troubleshooting issues. I have not worked on the new IOS-NX system, but if I understand it correctly it is modular. If Cisco can the really cool Monitor command and the structure the command tree like a Juniper. I would think Cisco did something totally right. M.A.R From lowen at pari.edu Thu Jan 13 16:14:20 2011 From: lowen at pari.edu (Lamar Owen) Date: Thu, 13 Jan 2011 17:14:20 -0500 Subject: Is NAT can provide some kind of protection? In-Reply-To: <7730BBF6-6FB4-44E9-A1BA-390C198C9115@delong.com> References: Message-ID: <201101131714.20446.lowen@pari.edu> On Thursday, January 13, 2011 04:32:17 pm Owen DeLong wrote: > No match, no rewrite, no forward. This is what you're missing; 'no rewrite' does not mean 'no forward'. Non-rewritten packets along with the rewritten *are* forwarded to routing; in a firewall they're not forwarded to routing. What routing does with either packet isn't the NAT's concern. The clever network engineer can take advantage of this to do things with NAT that are difficult to do with firewalls. Now, policy routing can do the same things that NAT can do in this context, without the packet header munging. But if you're already needing to do the translation, NAT kills two birds with one stone. But, you are correct in that most folks lump the words 'NAT' and 'firewall' into the same process, when they are not. I do look forward to the day when NAT will not be necessary for any reason; route-maps and policy routing are more easily understood and just as powerful for the type of packet redirection that NAT enables, with its twist. (route-maps can be the source of the NAT translation, for that matter, in Cisco IOS NAT past a fairly old IOS version). Policy routing doesn't break protocols, either. But policy routing isn't firewalling, any more than NAT is. Even if the route-map points to a next hop of Null0. :-) From jbates at brightok.net Thu Jan 13 16:19:10 2011 From: jbates at brightok.net (Jack Bates) Date: Thu, 13 Jan 2011 16:19:10 -0600 Subject: Is Cisco equpiment de facto for you? In-Reply-To: References: <16E58A1FE7C64A46BAD0FE1558C43D9201363D2A@es1.ic-sa.com> <4D2F5550.1080805@brightok.net> <16E58A1FE7C64A46BAD0FE1558C43D9201363D2E@es1.ic-sa.com> <4D2F57BA.3070102@brightok.net> Message-ID: <4D2F7A5E.6090801@brightok.net> On 1/13/2011 2:44 PM, Thomas Magill wrote: >> Cisco IOS has a similar feature. >> >> reload in 5 >> make changes >> verify things are working >> reload cancel > > There seems to be a better way to do it in IOS that will not reload the router: > > http://www.cisco.com/en/US/docs/ios/12_3t/12_3t7/feature/guide/gtrollbk.html > > I haven't tried it since all my gear has OOB serial mgmt but it appears to let you rollback a config after a set time without a reboot. It still doesn't seem to be as nice as JUNOS rollback. > > The problem is, it doesn't seem to support an automated rollback function. You'd need OOB to get access in many cases to do the rollback. Jack From jeroen at mompl.net Thu Jan 13 16:30:30 2011 From: jeroen at mompl.net (Jeroen van Aart) Date: Thu, 13 Jan 2011 14:30:30 -0800 Subject: co-location and access to your server In-Reply-To: <4D2E7F83.2020405@gmail.com> References: <4D2E0DF2.4010301@mompl.net><4D2E1592.4090805@earthlink.net> <4D2E1DBE.7050500@mompl.net> <5A6D953473350C4B9995546AFE9939EE0BC13322@RWC-EX1.corp.seven.com> <4D2E272A.9040607@steadfast.net> <5A6D953473350C4B9995546AFE9939EE0BC1332C@RWC-EX1.corp.seven.com> <4D2E4748.2080504@mompl.net> <4D2E7F83.2020405@gmail.com> Message-ID: <4D2F7D06.3010007@mompl.net> JC Dill wrote: > Scruz is ~30-45 minutes from the heart of the internet on the west coast > (Silicon Valley). If your $dayjob isn't in scruz, then it's most likely > IN Silicon Valley. So locate your 1U server in Silicon Valley, where Yes it's in the Valley and I do consider locating it there. But I would like to do the whole "support your local business" thing. And the idea of being able to get to the server within 10 minutes is appealing. > have a longer drive to the colo. But it does no you good to locate your > server in a "closer" colo if you can't access it at night anyway! True, it's one of the reasons I was nitpicking about it. No 24/7 access eliminates one big advantage. > From the colo provider's perspective, 1U clients are the least > profitable clients. Setting them up and servicing them involves the > most paperwork and communication "per dollar" I understand. I did emphasize in my communications I expect the 1U to expand in the future. It's just a starting point. Though so far no answer. Thanks for your pointer wrt layer42, I will certainly look into it. Greetings, Jeroen -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html From joelja at bogus.com Thu Jan 13 17:14:35 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Fri, 14 Jan 2011 00:14:35 +0100 Subject: co-location and access to your server In-Reply-To: <4D2F7D06.3010007@mompl.net> References: <4D2E0DF2.4010301@mompl.net><4D2E1592.4090805@earthlink.net> <4D2E1DBE.7050500@mompl.net> <5A6D953473350C4B9995546AFE9939EE0BC13322@RWC-EX1.corp.seven.com> <4D2E272A.9040607@steadfast.net> <5A6D953473350C4B9995546AFE9939EE0BC1332C@RWC-EX1.corp.seven.com> <4D2E4748.2080504@mompl.net> <4D2E7F83.2020405@gmail.com> <4D2F7D06.3010007@mompl.net> Message-ID: <4D2F875B.3050608@bogus.com> On 1/13/11 11:30 PM, Jeroen van Aart wrote: > JC Dill wrote: >> Scruz is ~30-45 minutes from the heart of the internet on the west >> coast (Silicon Valley). If your $dayjob isn't in scruz, then it's >> most likely IN Silicon Valley. So locate your 1U server in Silicon >> Valley, where > > Yes it's in the Valley and I do consider locating it there. But I would > like to do the whole "support your local business" thing. And the idea > of being able to get to the server within 10 minutes is appealing. Colos are where the fiber is, and if you want to know where the fiber is follow the flow of money. santa cruz is in fact not someplace with either a lot of carriers or a lot of fiber diversity. vixie had a wild hair at some point and created the personal colo registry a couple of years ago. http://www.vix.com/personalcolo/ it is not extensive but the port/power/transit business for quantity one box is not real profitable either and piecemeal expansion means you're reserving space for customers that aren't paying for it. >> have a longer drive to the colo. But it does no you good to locate >> your server in a "closer" colo if you can't access it at night anyway! > > True, it's one of the reasons I was nitpicking about it. No 24/7 access > eliminates one big advantage. > >> From the colo provider's perspective, 1U clients are the least >> profitable clients. Setting them up and servicing them involves the >> most paperwork and communication "per dollar" > > I understand. I did emphasize in my communications I expect the 1U to > expand in the future. It's just a starting point. Though so far no > answer. Thanks for your pointer wrt layer42, I will certainly look into it. > > Greetings, > Jeroen > From tmagill at providecommerce.com Thu Jan 13 18:48:26 2011 From: tmagill at providecommerce.com (Thomas Magill) Date: Fri, 14 Jan 2011 00:48:26 +0000 Subject: Is Cisco equpiment de facto for you? In-Reply-To: <4D2F7A5E.6090801@brightok.net> References: <16E58A1FE7C64A46BAD0FE1558C43D9201363D2A@es1.ic-sa.com> <4D2F5550.1080805@brightok.net> <16E58A1FE7C64A46BAD0FE1558C43D9201363D2E@es1.ic-sa.com> <4D2F57BA.3070102@brightok.net> <4D2F7A5E.6090801@brightok.net> Message-ID: > The problem is, it doesn't seem to support an automated rollback > function. You'd need OOB to get access in many cases to do the rollback. I thought that is what 'configure terminal revert timer x' did. It looks like you have to do a 'configure confirm' before the revert time expires or it reverts back to when you started. Maybe I'll actually try this out and find out for sure. From bill at herrin.us Thu Jan 13 19:48:40 2011 From: bill at herrin.us (William Herrin) Date: Thu, 13 Jan 2011 20:48:40 -0500 Subject: Is NAT can provide some kind of protection? In-Reply-To: <20110113030222.C79E58B9B35@drugs.dv.isc.org> References: <15191.1294852587@localhost> <20110113030222.C79E58B9B35@drugs.dv.isc.org> Message-ID: On Wed, Jan 12, 2011 at 10:02 PM, Mark Andrews wrote: > In message , William > ?Herrin writes: >> There's actually a large difference between something that's >> impossible for a technology to do (even in theory), something that the >> technology has been programmed not to do and something that a >> technology is by default configured not to do. > > Well ask the firewall vendor not to give you the knob to open it > up completely. Hi Mark, Why would I do that? I still have toes left; I *want* to be able to shoot myself in the foot. Still, you do follow the practical difference between can't, programmed not to and configured not to, right? Can't is 0% chance of a breach on that vector. The others are varying small percentages with "configured" the highest of the bunch. > Note the CPE NAT boxes I've seen all have the ability to send > anything that isn't being NAT'd to a internal box so it isn't like > NAT boxes don't already have the flaw you are complaining about. > Usually it's labeled as DMZ host or something similar. Fair enough. Implementations that can't target -something- for unsolicited inbound packets have gotten rare. The core point remains: a hacker trying to push packets at an arbitrary host behind a NAT firewall has to not only find flaws in the filtering rules, he also has to convince the firewall to send the packet to the "right" host. This is more difficult. The fact that the firewall doesn't automatically send the packet to the right host once the filtering flaw is discovered adds an extra layer of security. Practically speaking, the hacker will have better luck trying to corrupt data actually solicited by interior hosts that the difficulty getting the box to send unsolicited packets to the host the hacker wants to attack puts and end to the whole attack vector. On Thu, Jan 13, 2011 at 4:21 PM, Lamar Owen wrote: > On Wednesday, January 12, 2011 03:50:28 pm Owen DeLong wrote: >> That's simply not true. Every end user running NAT is >> running a stateful firewall with a default inbound deny. > > This is demonstrably not correct. Hi Lamar, I have to side with Owen on this one. When a packet arrives at the external interface of a NAT device, it's looked up in the NAT state table. If no matching state is found, the packet is discarded. However it came about, that describes a firewall and it is stateful. Even if you route the packets somewhere instead of discarding them, you've removed them from the data streams associated with the individual interior hosts that present on the same exterior address. Hence, a firewall. There's no such thing as a pure router any more. As blurry as the line has gotten it can be attractive to think of selectively acting on packets with the same IP address pairs as a routing function, but it's really not... and where the function is to divert undesired packets from the hosts that don't want them (or the inverse -- divert desired packets to the hosts that do want them), that's a firewall. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From mruiz at lstfinancial.com Thu Jan 13 19:58:10 2011 From: mruiz at lstfinancial.com (Michael Ruiz) Date: Thu, 13 Jan 2011 19:58:10 -0600 Subject: How are you aggregating WAN customers these days? Message-ID: <16E58A1FE7C64A46BAD0FE1558C43D9201363D4D@es1.ic-sa.com> I know the way I used to do it at a previous company is we deployed the Cisco 12000 series router with the CHOC12-DS1-IR-SC module so we can 336 T1 out of that puppy. The only down side is there is a limitation on the number of channel groups. If doing something other than just handing off full T1 circuits, i.e. channelized T1s, then that is where you run into the problem. Sorry I do not remember what the magic number is but it something like 360 channel groups. The price on those cards can been pretty steep at times, not counting the OC12 card you have to get for the DACS(usually those cards have LR type interface, so have to pad the laser, assuming you have your DACS J) If you do not care about QOS those cards are great. If you don't mind doing COS, which can be a little challenging of getting them setup for it, work ok. If you want to more fancier with QOS, now you have to move to the Engine 5 cards which cost some bucks. At this new company we use old faith full, Cisco 7206 VXR routers with the PA-MC2T3+ cards. Since they have come down a lot in price you can really load up the chassis with those cards. DS-3 cards for a DACS is fairly inexpensive (depending on the type of DACS you have). In short, if you have your own transport equipment, then really comes down to the interfaces cards, connection type, labor and time. I hope that helps. > Hello, > > I'm looking to put some feelers out there and see what people are > doing to aggregate WAN customers (T1,T3, etc...) these days. What > platforms/devices are you using? What seems to be working/not working? > Any insights would be great! > > Thanks, > > Chris M.A.R From mruiz at lstfinancial.com Thu Jan 13 20:05:46 2011 From: mruiz at lstfinancial.com (Michael Ruiz) Date: Thu, 13 Jan 2011 20:05:46 -0600 Subject: How are you aggregating WAN customers these days? Message-ID: <16E58A1FE7C64A46BAD0FE1558C43D9201363D4E@es1.ic-sa.com> We used that topology, with an Adtran MX 2800 19" rack version. We would take our channelize DS-3 from the Telco and the Cisco PA-MC2T3 cards and in turn wire those to a DSX-1 panel. We then did 1 to 1 DS1 X-connects on the panel. That was starting to get too much of a pain as services grew, so we went with a DACS and that took care of having to do all that DSX-1 wiring. Ugh. >The ASRs seem to be the consensus in a lot of places. Wondering if >anyone has tried anything like aggregating T1 customers onto a mux >box, then connecting that back to a 6500. >I work in that kind of topology all day long/ both in 6500 & ASR's. >All is well/ >On Mon, Jan 10, 2011 at 7:51 AM, Chris > wrote: > Hello, > > I'm looking to put some feelers out there and see what people are > doing to aggregate WAN customers (T1,T3, etc...) these days. What > platforms/devices are you using? What seems to be working/not working? > Any insights would be great! > > Thanks, > > Chris > > Michael Ruiz Senior Network Engineer LST Financial, Inc. Integrated Network Delivery Services, Inc. Integrated Components, Inc. Office 210-933-0212 Fax 210-892-2599 "Opportunities multiply as they are seized." - Sun Tzu -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 1651 bytes Desc: image001.jpg URL: From owen at delong.com Thu Jan 13 20:59:22 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 13 Jan 2011 18:59:22 -0800 Subject: Is NAT can provide some kind of protection? In-Reply-To: References: <15191.1294852587@localhost> <20110113030222.C79E58B9B35@drugs.dv.isc.org> Message-ID: <11FF9C7F-5DF3-4311-ADF7-F942365E1E0A@delong.com> On Jan 13, 2011, at 5:48 PM, William Herrin wrote: > On Wed, Jan 12, 2011 at 10:02 PM, Mark Andrews wrote: >> In message , William >> Herrin writes: >>> There's actually a large difference between something that's >>> impossible for a technology to do (even in theory), something that the >>> technology has been programmed not to do and something that a >>> technology is by default configured not to do. >> >> Well ask the firewall vendor not to give you the knob to open it >> up completely. > > Hi Mark, > > Why would I do that? I still have toes left; I *want* to be able to > shoot myself in the foot. > > Still, you do follow the practical difference between can't, > programmed not to and configured not to, right? Can't is 0% chance of > a breach on that vector. The others are varying small percentages with > "configured" the highest of the bunch. > Can't doesn't apply to any device which forwards packets. Programmed not to is the best you can do on a piece of hardware which is capable of forwarding packets, so, I'm not sure how you think can't applies to this discussion. If the manufacturer takes away the knob, at best you have programmed not to (hopefully). If you keep the knob, then, all you have is default configuration or manual configuration. > >> Note the CPE NAT boxes I've seen all have the ability to send >> anything that isn't being NAT'd to a internal box so it isn't like >> NAT boxes don't already have the flaw you are complaining about. >> Usually it's labeled as DMZ host or something similar. > > Fair enough. Implementations that can't target -something- for > unsolicited inbound packets have gotten rare. > > The core point remains: a hacker trying to push packets at an > arbitrary host behind a NAT firewall has to not only find flaws in the > filtering rules, he also has to convince the firewall to send the > packet to the "right" host. This is more difficult. The fact that the > firewall doesn't automatically send the packet to the right host once > the filtering flaw is discovered adds an extra layer of security. > Practically speaking, the hacker will have better luck trying to > corrupt data actually solicited by interior hosts that the difficulty > getting the box to send unsolicited packets to the host the hacker > wants to attack puts and end to the whole attack vector. > No, the flaws in the filtering rules have to send the packet to the right host just like a (mis)configured stateful firewall. > > On Thu, Jan 13, 2011 at 4:21 PM, Lamar Owen wrote: >> On Wednesday, January 12, 2011 03:50:28 pm Owen DeLong wrote: >>> That's simply not true. Every end user running NAT is >>> running a stateful firewall with a default inbound deny. >> >> This is demonstrably not correct. > > Hi Lamar, > > I have to side with Owen on this one. When a packet arrives at the > external interface of a NAT device, it's looked up in the NAT state > table. If no matching state is found, the packet is discarded. However > it came about, that describes a firewall and it is stateful. > Lamar pointed out that there are implementations where, apparently, things which don't match the state table are passed to routing without modification. I would call this a bug in the implementation, or at the very least, a very poor choice of default behavior. However, since such situations exist, what this boils down to is a NAT with a stateful firewall with a default permit any instead of a default deny. While that doesn't make a good firewall, I'd still call it a firewall and I'd still call it stateful inspection. > Even if you route the packets somewhere instead of discarding them, > you've removed them from the data streams associated with the > individual interior hosts that present on the same exterior address. > Hence, a firewall. > Unless that somewhere happens to be the individual interior hosts in question. (I've seen hosts with both inside and outside addresses configured on their interface. Yes, this is dumb. However, it's the kind of misconception-based mistake that tends to get made by the same kind of people who would bungle firewall rulesets in the ways you are claiming NAT protects you). > There's no such thing as a pure router any more. As blurry as the line > has gotten it can be attractive to think of selectively acting on > packets with the same IP address pairs as a routing function, but it's > really not... and where the function is to divert undesired packets > from the hosts that don't want them (or the inverse -- divert desired > packets to the hosts that do want them), that's a firewall. > There are at least lots of devices that can be configured to act as pure routers. Perhaps what we need is to agree on a standard set of definitions... I would propose: NAT -- The process of modifying the contents of either the source or destination address and possibly port numbers of an IP datagram prior to forwarding. May be stateful or stateless. Stateful NAT may include address overloading sometimes referred to as PAT or PNAT. Routing -- The process of forwarding packets between different layer 3 network segments. Bridging -- The process of forwarding packets between different layer 2 segments within the same layer 3 segment. Firewall -- A device which mimics the behavior of a router or a router or bridge, but, which forwards traffic only selectively based on a default or configured policy. Stateful Firewall -- A firewall which maintains a state table of active sessions and makes some of its forwarding decisions based on whether packets match the state table. Owen From dotis at mail-abuse.org Thu Jan 13 22:50:55 2011 From: dotis at mail-abuse.org (Douglas Otis) Date: Thu, 13 Jan 2011 20:50:55 -0800 Subject: Is NAT can provide some kind of protection? In-Reply-To: References: <15191.1294852587@localhost> <20110113030222.C79E58B9B35@drugs.dv.isc.org> Message-ID: <4D2FD62F.90305@mail-abuse.org> On 1/13/11 5:48 PM, William Herrin wrote: > On Wed, Jan 12, 2011 at 10:02 PM, Mark Andrews wrote: >> In message, William >> Herrin writes: >>> There's actually a large difference between something that's >>> impossible for a technology to do (even in theory), something that the >>> technology has been programmed not to do and something that a >>> technology is by default configured not to do. >> Well ask the firewall vendor not to give you the knob to open it >> up completely. > Hi Mark, > > Why would I do that? I still have toes left; I *want* to be able to > shoot myself in the foot. > > Still, you do follow the practical difference between can't, > programmed not to and configured not to, right? Can't is 0% chance of > a breach on that vector. The others are varying small percentages with > "configured" the highest of the bunch. > >> Note the CPE NAT boxes I've seen all have the ability to send >> anything that isn't being NAT'd to a internal box so it isn't like >> NAT boxes don't already have the flaw you are complaining about. >> Usually it's labeled as DMZ host or something similar. > Fair enough. Implementations that can't target -something- for > unsolicited inbound packets have gotten rare. > > The core point remains: a hacker trying to push packets at an > arbitrary host behind a NAT firewall has to not only find flaws in the > filtering rules, he also has to convince the firewall to send the > packet to the "right" host. This is more difficult. The fact that the > firewall doesn't automatically send the packet to the right host once > the filtering flaw is discovered adds an extra layer of security. > Practically speaking, the hacker will have better luck trying to > corrupt data actually solicited by interior hosts that the difficulty > getting the box to send unsolicited packets to the host the hacker > wants to attack puts and end to the whole attack vector. > > > On Thu, Jan 13, 2011 at 4:21 PM, Lamar Owen wrote: >> On Wednesday, January 12, 2011 03:50:28 pm Owen DeLong wrote: >>> That's simply not true. Every end user running NAT is >>> running a stateful firewall with a default inbound deny. >> This is demonstrably not correct. > Hi Lamar, > > I have to side with Owen on this one. When a packet arrives at the > external interface of a NAT device, it's looked up in the NAT state > table. If no matching state is found, the packet is discarded. However > it came about, that describes a firewall and it is stateful. > > Even if you route the packets somewhere instead of discarding them, > you've removed them from the data streams associated with the > individual interior hosts that present on the same exterior address. > Hence, a firewall. > > There's no such thing as a pure router any more. As blurry as the line > has gotten it can be attractive to think of selectively acting on > packets with the same IP address pairs as a routing function, but it's > really not... and where the function is to divert undesired packets > from the hosts that don't want them (or the inverse -- divert desired > packets to the hosts that do want them), that's a firewall. Hi Bill, Unfortunately, a large number of web sites have been compromised, where an unseen iFrame might be included in what is normally safe content. A device accessing the Internet through a NATs often creates opportunities for unknown sources to reach the device as well. Once an attacker invokes a response, exposures persist, where more can be discovered. There are also exposures related to malicious scripts enabled by a general desire to show users dancing fruit. Microsoft now offers a toolkit that allows users a means to 'decide' what should be allowed to see fruit dance. Users that assume local networks are safe are often disappointed when someone on their network wants an application do something that proves unsafe. Methods to penetrate firewalls are often designed into 'fun' applications or poorly considered OS features. -Doug From randy at psg.com Fri Jan 14 03:46:46 2011 From: randy at psg.com (Randy Bush) Date: Fri, 14 Jan 2011 01:46:46 -0800 Subject: co-location and access to your server In-Reply-To: <4D2E0DF2.4010301@mompl.net> References: <4D2E0DF2.4010301@mompl.net> Message-ID: > Cruzio in Santa Cruz ... > Their 1U offer comes with limited access to your server, only from 10AM > to 6 PM. I find that not acceptable. sheesh d00d, you ever been to cruz? randy From randy at psg.com Fri Jan 14 03:50:40 2011 From: randy at psg.com (Randy Bush) Date: Fri, 14 Jan 2011 01:50:40 -0800 Subject: Routing Suggestions In-Reply-To: References: Message-ID: i'm with jon and the static crew. brutal but simple. if you want no leakage, A can filter the prefix from it's upstreams, both can low-pref blackhole it, ... randy From harris.hui at gmail.com Fri Jan 14 03:58:37 2011 From: harris.hui at gmail.com (Harris Hui) Date: Fri, 14 Jan 2011 17:58:37 +0800 Subject: Single AS Number for multiple prefixes in different country Message-ID: Hi, We have an AS Number AS2XXXX and have 2 /24 subnets belongs to this AS Number. It is using in US and peering with US Service Providers now. We are going to deploy another site in Asia, can we use the same AS Number AS2XXXX and have 2 other /24 subnets and peering with other Asia Service Providers? Will it affect the routing or BGP Path of our existing subnets in US? Please advise. Thanks Harris :-) From patrick at ianai.net Fri Jan 14 04:06:55 2011 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 14 Jan 2011 05:06:55 -0500 Subject: Single AS Number for multiple prefixes in different country In-Reply-To: References: Message-ID: <409DB694-6C64-4EC3-A8B3-F31E362D0A33@ianai.net> On Jan 14, 2011, at 4:58 AM, Harris Hui wrote: > We have an AS Number AS2XXXX and have 2 /24 subnets belongs to this AS > Number. It is using in US and peering with US Service Providers now. > > We are going to deploy another site in Asia, can we use the same AS Number > AS2XXXX and have 2 other /24 subnets and peering with other Asia Service > Providers? > > Will it affect the routing or BGP Path of our existing subnets in US? It will not. There was a thread on this a short while ago, check the archives. The big question is whether the two sites will be able to talk to each other. There are ways to make that happen, but by default, a router in asXXXX will not accept eBGP announcements which include asXXXX (loop detection). -- TTFN, patrick From shoshon at shoshon.ro Fri Jan 14 05:33:48 2011 From: shoshon at shoshon.ro (Bogdan) Date: Fri, 14 Jan 2011 13:33:48 +0200 Subject: Single AS Number for multiple prefixes in different country In-Reply-To: <409DB694-6C64-4EC3-A8B3-F31E362D0A33@ianai.net> References: <409DB694-6C64-4EC3-A8B3-F31E362D0A33@ianai.net> Message-ID: <4D30349C.6050705@shoshon.ro> On 14.01.2011 12:06, Patrick W. Gilmore wrote: > On Jan 14, 2011, at 4:58 AM, Harris Hui wrote: > >> We have an AS Number AS2XXXX and have 2 /24 subnets belongs to this AS >> Number. It is using in US and peering with US Service Providers now. >> >> We are going to deploy another site in Asia, can we use the same AS Number >> AS2XXXX and have 2 other /24 subnets and peering with other Asia Service >> Providers? >> >> Will it affect the routing or BGP Path of our existing subnets in US? > > It will not. There was a thread on this a short while ago, check the archives. > > The big question is whether the two sites will be able to talk to each other. There are ways to make that happen, but by default, a router in asXXXX will not accept eBGP announcements which include asXXXX (loop detection). > allowas-in will do the trick From joe at nethead.com Fri Jan 14 05:50:05 2011 From: joe at nethead.com (Joe Hamelin) Date: Fri, 14 Jan 2011 03:50:05 -0800 Subject: Routing Suggestions In-Reply-To: References: Message-ID: On Fri, Jan 14, 2011 at 1:50 AM, Randy Bush wrote: > i'm with jon and the static crew. brutal but simple. My name is Joe, not jon, Randy. But what can I expect from a man that used the phrase "tell him to go fuck himself" when I put my hand out in greeting back at Atlanta NANOG in 2001, when your company sales person mentioned that I should meet you. (I was only the BGP driver and pipe buyer for Amazon at the time.) Even Vixie had a bit more class after I asked him a question at LISA 96 and all he said was "RTMfF. Next!" in his receiving line for questions about BIND.. (The same LISA where Larry was selling his first PERL book, signing shirts with Tom and Randal.) Six years later in Seattle he gave thoughtful consideration and an insightful answer to another question. (He had a bit of a cold that day and may have been off-game.) You Internet demigods need a clue stick to the head and understand that not all of us are as smart as you and we need your advice at times. We would much appreciate you not talking down to us when you do decide to send words from above. BTW: Do the clouds under Mt Olympus filter out caps? Randy, I know my solution was right. I don't need your blessing. Go fuck yourself. -Joe Hamelin PS: Thank you Jim. Always a pleasure working with (or interviewing) you. -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 From matthew at corp.crocker.com Fri Jan 14 06:42:00 2011 From: matthew at corp.crocker.com (Matthew S. Crocker) Date: Fri, 14 Jan 2011 07:42:00 -0500 (EST) Subject: Routing Suggestions In-Reply-To: Message-ID: <786604674.24724.1295008920177.JavaMail.root@zimbra1.crocker.com> ----- Original Message ----- > From: "Joe Hamelin" > To: "Randy Bush" , "NANOG list" > Sent: Friday, January 14, 2011 6:50:05 AM > Subject: Re: Routing Suggestions > On Fri, Jan 14, 2011 at 1:50 AM, Randy Bush wrote: > > i'm with jon and the static crew. brutal but simple. > > My name is Joe, not jon, Randy. I'm pretty sure Randy was responding to Jon Lewis... > [...] > > Go fuck yourself. Happy Friday to you too. -- Matthew S. Crocker President Crocker Communications, Inc. PO BOX 710 Greenfield, MA 01302-0710 http://www.crocker.com P: 413-746-2760 From jlewis at lewis.org Fri Jan 14 07:49:05 2011 From: jlewis at lewis.org (Jon Lewis) Date: Fri, 14 Jan 2011 08:49:05 -0500 (EST) Subject: Routing Suggestions In-Reply-To: References: Message-ID: On Fri, 14 Jan 2011, Joe Hamelin wrote: > On Fri, Jan 14, 2011 at 1:50 AM, Randy Bush wrote: >> i'm with jon and the static crew. brutal but simple. > > My name is Joe, not jon, Randy. > > But what can I expect from a man that used the phrase "tell him to go > fuck himself" when I put my hand out in greeting back at Atlanta NANOG > in 2001, when your company sales person mentioned that I should meet > you. (I was only the BGP driver and pipe buyer for Amazon at the > time.) Don't mind me. I'm invisible. I'll be at NANOG Miami in two weeks...only my second time attending one. I'll have to try meeting Randy in person this time and see if I rate better than a "fuck off". > Even Vixie had a bit more class after I asked him a question at LISA Perhaps you had him confused with someone else. > You Internet demigods need a clue stick to the head and understand My boss calls NANOG the Masters of the Universe conference. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From dhetzel at gmail.com Fri Jan 14 07:54:48 2011 From: dhetzel at gmail.com (Dorn Hetzel) Date: Fri, 14 Jan 2011 08:54:48 -0500 Subject: Routing Suggestions In-Reply-To: References: Message-ID: > > Randy, I know my solution was right. I don't need your blessing. > > Go fuck yourself. > > It's nice to see we've really elevated the level of discourse around here :) -dorn From randy at psg.com Fri Jan 14 07:58:54 2011 From: randy at psg.com (Randy Bush) Date: Fri, 14 Jan 2011 05:58:54 -0800 Subject: Routing Suggestions In-Reply-To: References: Message-ID: > My name is Joe, not jon, Randy. congrats. but i was speaking of jon lewis. randy From jbates at brightok.net Fri Jan 14 08:13:04 2011 From: jbates at brightok.net (Jack Bates) Date: Fri, 14 Jan 2011 08:13:04 -0600 Subject: Is NAT can provide some kind of protection? In-Reply-To: <4D2FD62F.90305@mail-abuse.org> References: <15191.1294852587@localhost> <20110113030222.C79E58B9B35@drugs.dv.isc.org> <4D2FD62F.90305@mail-abuse.org> Message-ID: <4D3059F0.6080104@brightok.net> On 1/13/2011 10:50 PM, Douglas Otis wrote: > Unfortunately, a large number of web sites have been compromised, where > an unseen iFrame might be included in what is normally safe content. A > device accessing the Internet through a NATs often creates opportunities > for unknown sources to reach the device as well. Once an attacker > invokes a response, exposures persist, where more can be discovered. > There are also exposures related to malicious scripts enabled by a > general desire to show users dancing fruit. Microsoft now offers a > toolkit that allows users a means to 'decide' what should be allowed to > see fruit dance. Users that assume local networks are safe are often > disappointed when someone on their network wants an application do > something that proves unsafe. Methods to penetrate firewalls are often > designed into 'fun' applications or poorly considered OS features. I have to agree with this, but I believe it is outside the scope of what NAT or stateful firewalls provide. Neither is designed to mitigate this attack. Application level filtering within such firewalls often are designed to protect users in this case. Application level filtering, however, does not protect from the cell phone hidden in a box which was sent to the wrong party and awaiting to be shipped back. There is not, and will probably never be, a single solution and approach to security. Jack From jbates at brightok.net Fri Jan 14 08:17:38 2011 From: jbates at brightok.net (Jack Bates) Date: Fri, 14 Jan 2011 08:17:38 -0600 Subject: Routing Suggestions In-Reply-To: References: Message-ID: <4D305B02.1090306@brightok.net> On 1/14/2011 7:49 AM, Jon Lewis wrote: > > My boss calls NANOG the Masters of the Universe conference. Beats "Unruly kids with toys" conference. ;) Jack From bill at herrin.us Fri Jan 14 08:24:58 2011 From: bill at herrin.us (William Herrin) Date: Fri, 14 Jan 2011 09:24:58 -0500 Subject: Is NAT can provide some kind of protection? In-Reply-To: <4D2FD62F.90305@mail-abuse.org> References: <15191.1294852587@localhost> <20110113030222.C79E58B9B35@drugs.dv.isc.org> <4D2FD62F.90305@mail-abuse.org> Message-ID: On Thu, Jan 13, 2011 at 11:50 PM, Douglas Otis wrote: > Unfortunately, a large number of web sites have been compromised, where an > unseen iFrame might be included in what is normally safe content. ?A device > accessing the Internet through a NATs often creates opportunities for > unknown sources to reach the device as well. ?Once an attacker invokes a > response, exposures persist, where more can be discovered. ?There are also > exposures related to malicious scripts enabled by a general desire to show > users dancing fruit. ?Microsoft now offers a toolkit that allows users a > means to 'decide' what should be allowed to see fruit dance. ?Users that > assume local networks are safe are often disappointed when someone on their > network wants an application do something that proves unsafe. ?Methods to > penetrate firewalls are often designed into 'fun' applications or poorly > considered OS features. Doug, Passive attacks. Very effective. Breeze past the firewall like it wasn't there. Hard to target though; work best when you're fishing for whatever you can get instead of trying to crack a particular system. Some success combining them with social engineering. Not terribly relevant to the discussion in this thread. Firewalls mostly block active attacks where a hacker is pushing unsolicited data at a host instead of waiting for the host to request data. Whether or not NAT is involved doesn't really change that larger picture of the general class of attacks firewalls obstruct. -Bill -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jml at packetpimp.org Fri Jan 14 09:10:51 2011 From: jml at packetpimp.org (Jason LeBlanc) Date: Fri, 14 Jan 2011 10:10:51 -0500 Subject: Cisco Sanitization In-Reply-To: <1294863447.2798.66.camel@home> References: <1B5DDAEC-F6B2-404B-AD45-0B8AB787B76D@oicr.on.ca> <4D2DD4AC.7040406@deaddrop.org> <4D2E03DE.8010009@gmail.com> <1294863447.2798.66.camel@home> Message-ID: <4D30677B.8070007@packetpimp.org> I was fired from eBay several years ago for posting to NANOG trying to help others deal with the dDoS issues of those days, nothing said was fair for termination IMO. Using a personal account may be prudent. Now I hardly ever even post. On 01/12/2011 03:17 PM, Michael Hallgren wrote: > Le mercredi 12 janvier 2011 ? 11:41 -0800, JC Dill a ?crit : > >> Randy, >> >> If you want to cite list policy, let's start by noting that it's a clear >> violation of the nanog list AUP to setup an autoresponder reply to list >> email[1], no matter if the autoresponder replies to the list or just to >> the poster. You must whitelist email from the list before applying an >> autoresponder. If you don't want to see the disclaimer-laden emails, >> then you can whitelist, then send posts with disclaimers (along with all >> other posts you don't care to read) to dev/null. >> >> OTOH, there is nothing in the AUP about disclaimers. Disclaimers, top >> posting, excessive quoting, etc. are discouraged (considered poor >> netiquette) but not outright forbidden. > Either way, a 15-50 or more lines legal notification style appendix to > a mail in an informal operation's forum... ... seems at the very best... > to be of... bad taste... (to me). (Who's reading these? :)) > > Cheers, > > mh > > > > From d.nostra at gmail.com Fri Jan 14 10:03:01 2011 From: d.nostra at gmail.com (Michel de Nostredame) Date: Fri, 14 Jan 2011 08:03:01 -0800 Subject: Single AS Number for multiple prefixes in different country In-Reply-To: <4D30349C.6050705@shoshon.ro> References: <409DB694-6C64-4EC3-A8B3-F31E362D0A33@ianai.net> <4D30349C.6050705@shoshon.ro> Message-ID: On Fri, Jan 14, 2011 at 3:33 AM, Bogdan wrote: > On 14.01.2011 12:06, Patrick W. Gilmore wrote: > allowas-in will do the trick > Provided your uplink ISP does not filter out that. -- Michel~ From morrowc.lists at gmail.com Fri Jan 14 10:11:48 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 14 Jan 2011 11:11:48 -0500 Subject: Routing Suggestions In-Reply-To: References: Message-ID: On Fri, Jan 14, 2011 at 8:54 AM, Dorn Hetzel wrote: >> >> Randy, I know my solution was right. ?I don't need your blessing. >> >> Go fuck yourself. >> >> > > It's nice to see we've really elevated the level of discourse around here :) yea... back to the coffee urn for me! (sometimes folks have hot-button-issues...) -chris From Greg.Whynott at oicr.on.ca Fri Jan 14 10:59:37 2011 From: Greg.Whynott at oicr.on.ca (Greg Whynott) Date: Fri, 14 Jan 2011 11:59:37 -0500 Subject: BGP route-map options Message-ID: Following a few documents on how to use route-maps to set preference of routes (related to my last thread regarding asymmetrical routing) all the ones I have looked at today (about 6or so) use the below method to apply the route map under the router section: router bgp YOURAS# neighbour x.x.x.x remote-as AS# neighbour x.x.x.x route-map MAPNAME in yet in the last line, "route-map" is not an option on my router, which is an ASR1004 running the version 15 line of code. is there a new way to do this? don't you love Cisco's consistency? thanks much for your time again, greg -- This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization. From ryan.landry at gmail.com Fri Jan 14 11:13:12 2011 From: ryan.landry at gmail.com (ryanL) Date: Fri, 14 Jan 2011 10:13:12 -0700 Subject: BGP route-map options In-Reply-To: References: Message-ID: 1) this is probably better posed over at cisco-nsp instead of NANOG. 2) i really hope you aren't using the canadian version of 'neighbor' On Fri, Jan 14, 2011 at 9:59 AM, Greg Whynott wrote: > Following a few documents on how to use route-maps to set preference of > routes (related to my last thread regarding asymmetrical routing) all the > ones I have looked at today (about 6or so) use the below method to apply the > route map under the router section: > > router bgp YOURAS# > neighbour x.x.x.x remote-as AS# > neighbour x.x.x.x route-map MAPNAME in > > yet in the last line, "route-map" is not an option on my router, which > is an ASR1004 running the version 15 line of code. > > is there a new way to do this? > > don't you love Cisco's consistency? > > thanks much for your time again, > greg > > > > > -- > > This message and any attachments may contain confidential and/or privileged > information for the sole use of the intended recipient. Any review or > distribution by anyone other than the person for whom it was originally > intended is strictly prohibited. If you have received this message in error, > please contact the sender and delete all copies. Opinions, conclusions or > other information contained in this message may not be that of the > organization. > > From tmagill at providecommerce.com Fri Jan 14 11:51:56 2011 From: tmagill at providecommerce.com (Thomas Magill) Date: Fri, 14 Jan 2011 17:51:56 +0000 Subject: BGP route-map options In-Reply-To: References: Message-ID: Try doing it under the 'address-family ipv4'? I've never seen any version of IOS not take it. -----Original Message----- From: Greg Whynott [mailto:Greg.Whynott at oicr.on.ca] Sent: Friday, January 14, 2011 9:00 AM To: nanog at nanog.org list Subject: BGP route-map options Following a few documents on how to use route-maps to set preference of routes (related to my last thread regarding asymmetrical routing) all the ones I have looked at today (about 6or so) use the below method to apply the route map under the router section: router bgp YOURAS# neighbour x.x.x.x remote-as AS# neighbour x.x.x.x route-map MAPNAME in yet in the last line, "route-map" is not an option on my router, which is an ASR1004 running the version 15 line of code. is there a new way to do this? don't you love Cisco's consistency? thanks much for your time again, greg -- This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization. From tmagill at providecommerce.com Fri Jan 14 11:52:55 2011 From: tmagill at providecommerce.com (Thomas Magill) Date: Fri, 14 Jan 2011 17:52:55 +0000 Subject: BGP route-map options In-Reply-To: References: Message-ID: Wait... Does the router even accept 'neighbour' instead of ' neighbor'? -----Original Message----- From: Greg Whynott [mailto:Greg.Whynott at oicr.on.ca] Sent: Friday, January 14, 2011 9:00 AM To: nanog at nanog.org list Subject: BGP route-map options Following a few documents on how to use route-maps to set preference of routes (related to my last thread regarding asymmetrical routing) all the ones I have looked at today (about 6or so) use the below method to apply the route map under the router section: router bgp YOURAS# neighbour x.x.x.x remote-as AS# neighbour x.x.x.x route-map MAPNAME in yet in the last line, "route-map" is not an option on my router, which is an ASR1004 running the version 15 line of code. is there a new way to do this? don't you love Cisco's consistency? thanks much for your time again, greg -- This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization. From Greg.Whynott at oicr.on.ca Fri Jan 14 11:57:40 2011 From: Greg.Whynott at oicr.on.ca (Greg Whynott) Date: Fri, 14 Jan 2011 12:57:40 -0500 Subject: BGP route-map options In-Reply-To: References: Message-ID: thanks Thomas, I opened a ticket with Cisco and am pestering other lists so i'm not bothering anyone with my operational issues. it does accept it under address-family, and doing a show bgp indicates something is going on: ASR1004#show bgp | inc \ \ 150\ *> 132.248.13.0/24 205.211.94.145 150 0 549 26677 6509 18592 278 i but the selected path is still going out via the other provider, not 549. if your intrested it'll let you know the outcome. thanks for taking the time to respond, greg On Jan 14, 2011, at 12:51 PM, Thomas Magill wrote: > Try doing it under the 'address-family ipv4'? > > I've never seen any version of IOS not take it. > > -----Original Message----- > From: Greg Whynott [mailto:Greg.Whynott at oicr.on.ca] > Sent: Friday, January 14, 2011 9:00 AM > To: nanog at nanog.org list > Subject: BGP route-map options > > Following a few documents on how to use route-maps to set preference of routes (related to my last thread regarding asymmetrical routing) all the ones I have looked at today (about 6or so) use the below method to apply the route map under the router section: > > router bgp YOURAS# > neighbour x.x.x.x remote-as AS# > neighbour x.x.x.x route-map MAPNAME in > > yet in the last line, "route-map" is not an option on my router, which is an ASR1004 running the version 15 line of code. > > is there a new way to do this? > > don't you love Cisco's consistency? > > thanks much for your time again, > greg > > > > > -- > > This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization. > -- This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization. From Greg.Whynott at oicr.on.ca Fri Jan 14 12:00:16 2011 From: Greg.Whynott at oicr.on.ca (Greg Whynott) Date: Fri, 14 Jan 2011 13:00:16 -0500 Subject: BGP route-map options In-Reply-To: References: Message-ID: haha? yeah that is not a copy and paste but rather me just typing that out. the proper spelling in the config is being used, or the american spelling? english is the worse language? thanks again, greg On Jan 14, 2011, at 12:52 PM, Thomas Magill wrote: > Wait... > > Does the router even accept 'neighbour' instead of ' neighbor'? > > > -----Original Message----- > From: Greg Whynott [mailto:Greg.Whynott at oicr.on.ca] > Sent: Friday, January 14, 2011 9:00 AM > To: nanog at nanog.org list > Subject: BGP route-map options > > Following a few documents on how to use route-maps to set preference of routes (related to my last thread regarding asymmetrical routing) all the ones I have looked at today (about 6or so) use the below method to apply the route map under the router section: > > router bgp YOURAS# > neighbour x.x.x.x remote-as AS# > neighbour x.x.x.x route-map MAPNAME in > > yet in the last line, "route-map" is not an option on my router, which is an ASR1004 running the version 15 line of code. > > is there a new way to do this? > > don't you love Cisco's consistency? > > thanks much for your time again, > greg > > > > > -- > > This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization. > -- This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization. From owen at delong.com Fri Jan 14 13:43:35 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 14 Jan 2011 11:43:35 -0800 Subject: Is NAT can provide some kind of protection? In-Reply-To: References: <15191.1294852587@localhost> <20110113030222.C79E58B9B35@drugs.dv.isc.org> <4D2FD62F.90305@mail-abuse.org> Message-ID: <72CA680B-D526-4C5F-8E0C-A124AA2EFC7F@delong.com> On Jan 14, 2011, at 6:24 AM, William Herrin wrote: > On Thu, Jan 13, 2011 at 11:50 PM, Douglas Otis wrote: >> Unfortunately, a large number of web sites have been compromised, where an >> unseen iFrame might be included in what is normally safe content. A device >> accessing the Internet through a NATs often creates opportunities for >> unknown sources to reach the device as well. Once an attacker invokes a >> response, exposures persist, where more can be discovered. There are also >> exposures related to malicious scripts enabled by a general desire to show >> users dancing fruit. Microsoft now offers a toolkit that allows users a >> means to 'decide' what should be allowed to see fruit dance. Users that >> assume local networks are safe are often disappointed when someone on their >> network wants an application do something that proves unsafe. Methods to >> penetrate firewalls are often designed into 'fun' applications or poorly >> considered OS features. > > Doug, > > Passive attacks. Very effective. Breeze past the firewall like it > wasn't there. Hard to target though; work best when you're fishing for > whatever you can get instead of trying to crack a particular system. > Some success combining them with social engineering. > Grabbing whatever you can get near the thing you're trying to crack is often a good first step. Afterall, once you pwn a system inside the firewall in the same security zone as your target, it becomes a lot easier to attack your target. > Not terribly relevant to the discussion in this thread. Firewalls > mostly block active attacks where a hacker is pushing unsolicited data > at a host instead of waiting for the host to request data. Whether or > not NAT is involved doesn't really change that larger picture of the > general class of attacks firewalls obstruct. > Ah, but, the point here is that NAT actually serves as an enabling technology for part of the attack he is describing. Another example where NAT can and is a security negative. The fact that you refuse to acknowledge these is exactly what you were accusing me of doing in my previous emails. Owen From jbates at brightok.net Fri Jan 14 13:49:07 2011 From: jbates at brightok.net (Jack Bates) Date: Fri, 14 Jan 2011 13:49:07 -0600 Subject: Is NAT can provide some kind of protection? In-Reply-To: <72CA680B-D526-4C5F-8E0C-A124AA2EFC7F@delong.com> References: <15191.1294852587@localhost> <20110113030222.C79E58B9B35@drugs.dv.isc.org> <4D2FD62F.90305@mail-abuse.org> <72CA680B-D526-4C5F-8E0C-A124AA2EFC7F@delong.com> Message-ID: <4D30A8B3.2020504@brightok.net> On 1/14/2011 1:43 PM, Owen DeLong wrote: > Ah, but, the point here is that NAT actually serves as an enabling > technology for part of the attack he is describing. Another example > where NAT can and is a security negative. The fact that you refuse > to acknowledge these is exactly what you were accusing me of > doing in my previous emails. > Explain how it acts as an enabler. Jack From EricMo at BarrettXplore.com Fri Jan 14 14:24:08 2011 From: EricMo at BarrettXplore.com (Eric Morin) Date: Fri, 14 Jan 2011 16:24:08 -0400 Subject: Single AS Number for multiple prefixes in different country References: Message-ID: I have 5 discrete networks across Canada using one ASN (will be down to 2 by end of year!). We accept a default (along with full tables) to route between discrete networks. Not very elegant but gets the job done. Eric -----Original Message----- From: Harris Hui [mailto:harris.hui at gmail.com] Sent: Friday, January 14, 2011 5:59 AM To: nanog at nanog.org Subject: Single AS Number for multiple prefixes in different country Hi, We have an AS Number AS2XXXX and have 2 /24 subnets belongs to this AS Number. It is using in US and peering with US Service Providers now. We are going to deploy another site in Asia, can we use the same AS Number AS2XXXX and have 2 other /24 subnets and peering with other Asia Service Providers? Will it affect the routing or BGP Path of our existing subnets in US? Please advise. Thanks Harris :-) -- This message has been scanned by MailScanner From patrick at ianai.net Fri Jan 14 14:30:54 2011 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 14 Jan 2011 15:30:54 -0500 Subject: Single AS Number for multiple prefixes in different country In-Reply-To: References: <409DB694-6C64-4EC3-A8B3-F31E362D0A33@ianai.net> <4D30349C.6050705@shoshon.ro> Message-ID: <53E1C7BE-0016-47D1-BDCB-C5F3E366033E@ianai.net> On Jan 14, 2011, at 11:03 AM, Michel de Nostredame wrote: > On Fri, Jan 14, 2011 at 3:33 AM, Bogdan wrote: >> allowas-in will do the trick > > Provided your uplink ISP does not filter out that. Why would your upstream filter that out? I would get a new upstream if they do. -- TTFN, patrick From cidr-report at potaroo.net Fri Jan 14 16:00:51 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 14 Jan 2011 22:00:51 GMT Subject: BGP Update Report Message-ID: <201101142200.p0EM0pCK045794@wattle.apnic.net> BGP Update Report Interval: 06-Jan-11 -to- 13-Jan-11 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS18025 25153 1.9% 1676.9 -- ACE-1-WIFI-AS-AP Ace-1 Wifi Network 2 - AS32528 19539 1.4% 4884.8 -- ABBOTT Abbot Labs 3 - AS14420 17361 1.3% 29.6 -- CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP 4 - AS35931 16418 1.2% 5472.7 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 5 - AS17974 15987 1.2% 14.6 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 6 - AS33475 15920 1.2% 74.0 -- RSN-1 - RockSolid Network, Inc. 7 - AS23700 13616 1.0% 34.1 -- BM-AS-ID PT. Broadband Multimedia, Tbk 8 - AS9829 12668 0.9% 33.6 -- BSNL-NIB National Internet Backbone 9 - AS24923 12108 0.9% 12108.0 -- SETTC South-East Transtelecom Joint Stock Co. 10 - AS8151 11298 0.8% 10.5 -- Uninet S.A. de C.V. 11 - AS24554 10985 0.8% 96.4 -- FIVE-NET-AS-IN Fivenetwork Solution India Pvt Ltd Internet 12 - AS45474 10479 0.8% 2619.8 -- NEXUSGUARD-AS-AP Tower 1 Millennium City 1 13 - AS31148 10141 0.8% 30.5 -- FREENET-AS FreeNet ISP 14 - AS7552 9961 0.7% 16.8 -- VIETEL-AS-AP Vietel Corporation 15 - AS5800 9820 0.7% 42.0 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 16 - AS10113 9801 0.7% 92.5 -- DATAFAST-AP DATAFAST TELECOMMUNICATIONS LTD 17 - AS45194 9607 0.7% 150.1 -- SIPL-AS Syscon Infoway Pvt. Ltd., Internet Service Provider, India 18 - AS25617 8982 0.7% 1283.1 -- SMITHNEPHEW - Smith and Nephew, Inc. 19 - AS11492 8811 0.7% 9.3 -- CABLEONE - CABLE ONE, INC. 20 - AS24627 7992 0.6% 285.4 -- SHOWNET-KW-AS GULFSATCOMMUNICATIONS COMPANY K.S.C. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS24923 12108 0.9% 12108.0 -- SETTC South-East Transtelecom Joint Stock Co. 2 - AS35931 16418 1.2% 5472.7 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 3 - AS32528 19539 1.4% 4884.8 -- ABBOTT Abbot Labs 4 - AS4454 2953 0.2% 2953.0 -- TNET-AS - State of Tennessee 5 - AS45474 10479 0.8% 2619.8 -- NEXUSGUARD-AS-AP Tower 1 Millennium City 1 6 - AS49776 2313 0.2% 2313.0 -- GORSET-AS Gorodskaya Set Ltd. 7 - AS28175 2205 0.2% 2205.0 -- 8 - AS18025 25153 1.9% 1676.9 -- ACE-1-WIFI-AS-AP Ace-1 Wifi Network 9 - AS1959 4968 0.4% 1656.0 -- DMSLABNET - DoD Network Information Center 10 - AS34239 1652 0.1% 1652.0 -- INTERAMERICAN General Insurance Company 11 - AS49600 1627 0.1% 1627.0 -- LASEDA La Seda de Barcelona, S.A 12 - AS25617 8982 0.7% 1283.1 -- SMITHNEPHEW - Smith and Nephew, Inc. 13 - AS31413 1079 0.1% 1079.0 -- UNICER-AS Unicer Bebidas SA 14 - AS45550 1066 0.1% 1066.0 -- NGT-AS-VN New Generations Telecommunications Corporation 15 - AS28666 4943 0.4% 823.8 -- HOSTLOCATION LTDA 16 - AS43534 3070 0.2% 767.5 -- CREDITCALL CreditCall Ltd 17 - AS27666 684 0.1% 684.0 -- INSTITUTO TECNOLOGICO DE TELEFONOS DE MEXICO 18 - AS17874 668 0.1% 668.0 -- NPC-AS-KR National Pension Corporation 19 - AS47865 633 0.1% 633.0 -- LIBERTYSIG-ASN Liberty Sigorta AS Num 20 - AS17408 3152 0.2% 630.4 -- ABOVE-AS-AP AboveNet Communications Taiwan TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 213.129.96.0/19 12108 0.8% AS24923 -- SETTC South-East Transtelecom Joint Stock Co. 2 - 63.211.68.0/22 10763 0.8% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 3 - 180.233.173.0/24 10469 0.7% AS45474 -- NEXUSGUARD-AS-AP Tower 1 Millennium City 1 4 - 130.36.35.0/24 9764 0.7% AS32528 -- ABBOTT Abbot Labs 5 - 130.36.34.0/24 9763 0.7% AS32528 -- ABBOTT Abbot Labs 6 - 202.182.78.0/23 9401 0.7% AS10113 -- DATAFAST-AP DATAFAST TELECOMMUNICATIONS LTD 7 - 194.126.34.0/24 7796 0.6% AS24627 -- SHOWNET-KW-AS GULFSATCOMMUNICATIONS COMPANY K.S.C. 8 - 198.140.43.0/24 5639 0.4% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 9 - 202.92.235.0/24 5357 0.4% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 10 - 27.123.248.0/22 5059 0.3% AS18025 -- ACE-1-WIFI-AS-AP Ace-1 Wifi Network 11 - 182.54.148.0/22 5047 0.3% AS18025 -- ACE-1-WIFI-AS-AP Ace-1 Wifi Network 12 - 182.54.140.0/22 5046 0.3% AS18025 -- ACE-1-WIFI-AS-AP Ace-1 Wifi Network 13 - 101.78.24.0/22 4969 0.3% AS18025 -- ACE-1-WIFI-AS-AP Ace-1 Wifi Network 14 - 101.78.20.0/22 4969 0.3% AS18025 -- ACE-1-WIFI-AS-AP Ace-1 Wifi Network 15 - 189.1.173.0/24 4890 0.3% AS28666 -- HOSTLOCATION LTDA 16 - 68.65.152.0/22 3690 0.3% AS11915 -- TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 17 - 206.184.16.0/24 3463 0.2% AS174 -- COGENT Cogent/PSI 18 - 202.153.174.0/24 3140 0.2% AS17408 -- ABOVE-AS-AP AboveNet Communications Taiwan 19 - 91.197.95.0/24 3054 0.2% AS43534 -- CREDITCALL CreditCall Ltd 20 - 208.54.82.0/24 3039 0.2% AS701 -- UUNET - MCI Communications Services, Inc. d/b/a Verizon Business Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu 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 Jan 14 16:00:00 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 14 Jan 2011 22:00:00 GMT Subject: The Cidr Report Message-ID: <201101142200.p0EM00x8045745@wattle.apnic.net> This report has been generated at Fri Jan 14 21:11:53 2011 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 07-01-11 342117 200981 08-01-11 342269 201014 09-01-11 342286 200968 10-01-11 342231 201082 11-01-11 342377 201006 12-01-11 342440 201317 13-01-11 342857 201389 14-01-11 343138 201394 AS Summary 36437 Number of ASes in routing system 15466 Number of ASes announcing only one prefix 3714 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 118804736 Largest address span announced by an AS (/32s) AS237 : MERIT-ASN Merit Network Inc. 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'). --- 14Jan11 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 342960 201370 141590 41.3% All ASes AS6389 3714 271 3443 92.7% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 2636 407 2229 84.6% TWTC - tw telecom holdings, inc. AS19262 1916 286 1630 85.1% VZGNI-TRANSIT - Verizon Online LLC AS4766 1909 539 1370 71.8% KIXS-AS-KR Korea Telecom AS22773 1268 82 1186 93.5% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS6478 1449 278 1171 80.8% ATT-INTERNET3 - AT&T Services, Inc. AS4755 1393 224 1169 83.9% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS1785 1788 769 1019 57.0% AS-PAETEC-NET - PaeTec Communications, Inc. AS28573 1229 299 930 75.7% NET Servicos de Comunicao S.A. AS7545 1569 725 844 53.8% TPG-INTERNET-AP TPG Internet Pty Ltd AS10620 1350 551 799 59.2% Telmex Colombia S.A. AS6503 1142 371 771 67.5% Axtel, S.A.B. de C.V. AS24560 1093 336 757 69.3% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS7303 866 124 742 85.7% Telecom Argentina S.A. AS18101 881 143 738 83.8% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS4808 1018 316 702 69.0% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS3356 1186 486 700 59.0% LEVEL3 Level 3 Communications AS17488 949 271 678 71.4% HATHWAY-NET-AP Hathway IP Over Cable Internet AS8151 1338 669 669 50.0% Uninet S.A. de C.V. AS9498 739 108 631 85.4% BBIL-AP BHARTI Airtel Ltd. AS18566 1117 486 631 56.5% COVAD - Covad Communications Co. AS11492 1277 684 593 46.4% CABLEONE - CABLE ONE, INC. AS17676 645 68 577 89.5% GIGAINFRA Softbank BB Corp. AS855 629 55 574 91.3% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS22047 566 31 535 94.5% VTR BANDA ANCHA S.A. AS14420 603 93 510 84.6% CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP AS3549 868 359 509 58.6% GBLX Global Crossing Ltd. AS9443 571 75 496 86.9% INTERNETPRIMUS-AS-AP Primus Telecommunications AS4804 571 77 494 86.5% MPX-AS Microplex PTY LTD AS7011 1171 683 488 41.7% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. Total 37451 9866 27585 73.7% Top 30 total Possible Bogus Routes 5.0.0.0/8 AS237 MERIT-ASN Merit Network Inc. 5.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 5.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 5.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 23.0.0.0/8 AS237 MERIT-ASN Merit Network Inc. 24.129.192.0/19 AS7922 COMCAST-7922 - Comcast Cable Communications, Inc. 37.0.0.0/8 AS237 MERIT-ASN Merit Network Inc. 37.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 37.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 37.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 46.253.112.0/20 AS29551 HGCOMP-ASN Aixit GmbH 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.21.192.0/20 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.212.0/22 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.216.0/21 AS11610 INETNEBR-1 - Internet Nebraska Corporation 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 69.6.81.0/24 AS13442 71.19.134.0/23 AS3313 INET-AS I.NET S.p.A. 72.22.32.0/19 AS33150 72.22.61.0/24 AS33150 72.22.62.0/24 AS33150 76.77.32.0/19 AS2828 XO-AS15 - XO Communications 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 96.45.161.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.162.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.163.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.164.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.165.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.166.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.167.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.168.0/21 AS3257 TINET-BACKBONE Tinet SpA 100.0.0.0/8 AS237 MERIT-ASN Merit Network Inc. 100.100.100.0/24 AS3549 GBLX Global Crossing Ltd. 105.0.0.0/8 AS237 MERIT-ASN Merit Network Inc. 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas 110.173.64.0/19 AS37963 CNNIC-ALIBABA-CN-NET-AP Alibaba (China) Technology Co., Ltd. 113.29.0.0/17 AS3549 GBLX Global Crossing Ltd. 113.29.0.0/20 AS3549 GBLX Global Crossing Ltd. 113.29.16.0/20 AS3549 GBLX Global Crossing Ltd. 113.29.32.0/20 AS3549 GBLX Global Crossing Ltd. 113.29.64.0/20 AS3549 GBLX Global Crossing Ltd. 115.42.28.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.30.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.40.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.42.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.43.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.44.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.47.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.48.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.49.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.50.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.51.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.52.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.53.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.54.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.55.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.56.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.57.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.58.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.59.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.61.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.62.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.63.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 116.68.136.0/21 AS28045 Pantel Communications 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 121.54.160.0/24 AS38890 121.54.161.0/24 AS38890 121.54.162.0/24 AS38890 121.54.163.0/24 AS38890 121.54.164.0/24 AS38890 121.54.166.0/24 AS38890 121.54.167.0/24 AS38890 121.200.192.0/24 AS17767 122.200.32.0/20 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 122.200.40.0/21 AS38272 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services Inc. 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 172.12.0.0/18 AS28665 PredialNet Provedor de Internet Ltda. 173.237.208.0/20 AS30176 AS-PRIORITYCOLO - Priority Colo Inc 176.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 176.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 176.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 190.102.32.0/20 AS30058 FDCSERVERS - FDCservers.net 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.101.46.0/24 AS6503 Axtel, S.A.B. de C.V. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 196.2.224.0/22 AS24863 LINKdotNET-AS 196.6.108.0/24 AS5713 SAIX-NET 196.13.201.0/24 AS2018 TENET-1 196.13.202.0/24 AS2018 TENET-1 196.13.203.0/24 AS2018 TENET-1 196.13.204.0/24 AS2018 TENET-1 196.110.105.0/24 AS8513 SKYVISION SkyVision Network Services 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.15.4.0/24 AS4323 TWTC - tw telecom holdings, inc. 198.15.5.0/24 AS4323 TWTC - tw telecom holdings, inc. 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.99.241.0/24 AS11797 AC-NIELSEN-AS AC NIELSEN 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 198.182.235.0/24 AS3356 LEVEL3 Level 3 Communications 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 199.185.130.0/23 AS19662 UNISERVE-ONLINE - Uniserve On Line 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.233.92.0/24 AS26896 D102-ITC - Data 102, LLC 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.24.73.0/24 AS26061 Equant Colombia 200.24.78.0/26 AS3549 GBLX Global Crossing Ltd. 200.24.78.64/26 AS3549 GBLX Global Crossing Ltd. 202.1.224.0/24 AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000 202.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.58.113.0/24 AS19161 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.66.128.0/18 AS9584 GENESIS-AP Diyixian.com Limited 202.66.160.0/19 AS9584 GENESIS-AP Diyixian.com Limited 202.66.160.0/20 AS9584 GENESIS-AP Diyixian.com Limited 202.66.176.0/20 AS9584 GENESIS-AP Diyixian.com Limited 202.66.184.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.186.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.188.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.189.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.190.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.133.37.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.146.186.0/24 AS23655 SNAP-NZ-AS Snap Internet Limited 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 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.130.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.131.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.133.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 202.179.144.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.149.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.150.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.18.156.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.22.78.0/24 AS18117 HARBOURMSP-AU-AP Harbour MSP Pty. Ltd 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.27.123.0/24 AS4739 CIX-ADELAIDE-AS Internode Systems Pty Ltd 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.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.142.219.0/24 AS45149 203.175.107.0/24 AS45595 PKTELECOM-AS-PK Pakistan Telecom Company Limited 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.10.232.0/21 AS33150 204.19.14.0/23 AS577 BACOM - Bell Canada 204.209.114.0/24 AS13768 PEER1 - Peer 1 Network Inc. 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 DISTRIBUTEL-AS11814 - DISTRIBUTEL COMMUNICATIONS LTD. 205.207.148.0/23 AS812 ROGERS-CABLE - Rogers Cable Communications Inc. 205.210.145.0/24 AS11814 DISTRIBUTEL-AS11814 - DISTRIBUTEL COMMUNICATIONS LTD. 206.72.192.0/23 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 206.72.194.0/23 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 206.123.129.0/24 AS10790 INREACH-AS - InReach Internet 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.188.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.189.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.190.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.191.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.64.200.0/22 AS11730 CIL-ASN - Circle Internet LTD 208.64.240.0/21 AS13871 TELEBYTE-NW - Telebyte NW 208.73.160.0/24 AS32767 208.78.165.0/24 AS16565 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.83.54.0/24 AS23485 SEI-LLC-AS-NUM - SEI LLC 208.92.196.0/22 AS10929 NETELLIGENT - Netelligent Hosting Services Inc. 208.92.199.0/24 AS26198 3MENATWORK - 3Men at Work Integrated Networks, Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.165.239.0/24 AS209 ASN-QWEST - Qwest Communications Company, LLC 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.213.1.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 209.213.4.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 216.10.235.0/24 AS13780 NTNCOMMUNICATIONS - NTN 216.10.236.0/24 AS13780 NTNCOMMUNICATIONS - NTN 216.21.196.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.201.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.202.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.206.0/23 AS12251 INVISION - Invision.com, Inc. 216.58.192.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.197.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.200.0/24 AS18530 ISOMEDIA-1 - Isomedia Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.250.112.0/20 AS7296 ALCHEMYNET - Alchemy Communications, Inc. Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From tdonahue at vonmail.vonworldwide.com Fri Jan 14 16:09:07 2011 From: tdonahue at vonmail.vonworldwide.com (Tim Donahue) Date: Fri, 14 Jan 2011 17:09:07 -0500 Subject: INDOSAT Internet Network Provider NOC Contact Message-ID: <4D30C983.4070906@vonmail.vonworldwide.com> Hi all, Sorry for the noise, but I was wondering if anyone has a NOC or BGP knowledgeable contact with INDOSAT Internet Network Provider (AS4761). I have emailed the hostmaster@ email address listed in the WHOIS contact, and tried calling the phone number listed as well (disconnect message). They are announcing one of our prefixes and I am trying to find a contact in their company who can fix the announcement. Tim From dotis at mail-abuse.org Fri Jan 14 16:52:09 2011 From: dotis at mail-abuse.org (Douglas Otis) Date: Fri, 14 Jan 2011 14:52:09 -0800 Subject: Is NAT can provide some kind of protection? In-Reply-To: <4D30A8B3.2020504@brightok.net> References: <15191.1294852587@localhost> <20110113030222.C79E58B9B35@drugs.dv.isc.org> <4D2FD62F.90305@mail-abuse.org> <72CA680B-D526-4C5F-8E0C-A124AA2EFC7F@delong.com> <4D30A8B3.2020504@brightok.net> Message-ID: <4D30D399.6030405@mail-abuse.org> On 1/14/11 11:49 AM, Jack Bates wrote: > On 1/14/2011 1:43 PM, Owen DeLong wrote: >> Ah, but, the point here is that NAT actually serves as an enabling >> technology for part of the attack he is describing. Another example >> where NAT can and is a security negative. The fact that you refuse >> to acknowledge these is exactly what you were accusing me of >> doing in my previous emails. > > Explain how it acts as an enabler. Consider the impact the typical NAT or "firewall" has on DNS. -Doug From sam.silvester at gmail.com Fri Jan 14 17:22:59 2011 From: sam.silvester at gmail.com (Sam Silvester) Date: Sat, 15 Jan 2011 09:52:59 +1030 Subject: Routing Suggestions In-Reply-To: References: Message-ID: On Fri, Jan 14, 2011 at 8:20 PM, Randy Bush wrote: > i'm with jon and the static crew. ?brutal but simple. Depending on how the interconnect is built, using the "permanent" keyword along with the static route may be worth investigating also if you want the static route to stay in place, if you wish to prevent the static being withdrawn if the interface goes down. Sam From bill at herrin.us Fri Jan 14 18:10:50 2011 From: bill at herrin.us (William Herrin) Date: Fri, 14 Jan 2011 19:10:50 -0500 Subject: Is NAT can provide some kind of protection? In-Reply-To: <72CA680B-D526-4C5F-8E0C-A124AA2EFC7F@delong.com> References: <15191.1294852587@localhost> <20110113030222.C79E58B9B35@drugs.dv.isc.org> <4D2FD62F.90305@mail-abuse.org> <72CA680B-D526-4C5F-8E0C-A124AA2EFC7F@delong.com> Message-ID: On Fri, Jan 14, 2011 at 2:43 PM, Owen DeLong wrote: > Ah, but, the point here is that NAT actually serves as an enabling > technology for part of the attack he is describing. Hi Owen, Doug's comments on that were pretty abstract, so let me try to ground it a little bit. He basically observed that if I originate a UDP packet from behind a NAT, there's a window of opportunity in which that port is somewhat open through the NAT firewall and could return packets originated by a hacker. I watch the movies too and I hang in suspense as the protagonist waits for the bad guy to make a network connection and then activates the phlebotinum that backhacks his tubes. And I know there are some real-life examples where giving a hacker a large file to download has kept him connected to a modem long enough to get a phone trace. But I haven't read of a _nonfiction_ example where the dynamic opening in a stateful firewall (NAT or otherwise) has directly provided the needed opening for an _active_ attack by a third party. Can you cite one? Even if such an attack is practical, I fail to see how a NAT firewall is any more vulnerable to it than a merely stateful firewall. Perhaps you can explain? As for strictly passive attacks, like the so-called drive by download, it is not obvious to me that they would operate differently in a NAT versus non-NAT stateful firewall environment. Please elucidate. On Fri, Jan 14, 2011 at 5:52 PM, Douglas Otis wrote: > On 1/14/11 11:49 AM, Jack Bates wrote: >> Explain how [NAT] acts as an enabler. > Consider the impact the typical NAT or "firewall" has on DNS. Hi Doug, You'd make the argument that NAT aggravates Kaminsky? If you have something else in mind, I'll have to ask you to spell it out for me. Interesting argument. Tough sell. The more hosts behind a NAT, the more likely they're relying on an interior resolver anyway which aggregates the query source regardless of the presence or absence of NAT. Worst case I can think of is you have a badly implemented NAT which negates the source port randomization. But you have a tougher sell if you want to convince me that NAT firewalls have a higher probability of being badly implemented. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From gbonser at seven.com Fri Jan 14 19:01:09 2011 From: gbonser at seven.com (George Bonser) Date: Fri, 14 Jan 2011 17:01:09 -0800 Subject: Is NAT can provide some kind of protection? In-Reply-To: References: <15191.1294852587@localhost><20110113030222.C79E58B9B35@drugs.dv.isc.org><4D2FD62F.90305@mail-abuse.org><72CA680B-D526-4C5F-8E0C-A124AA2EFC7F@delong.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC133C7@RWC-EX1.corp.seven.com> > From: William Herrin > Sent: Friday, January 14, 2011 4:11 PM > To: nanog at nanog.org > Subject: Re: Is NAT can provide some kind of protection? > > On Fri, Jan 14, 2011 at 2:43 PM, Owen DeLong wrote: > > Ah, but, the point here is that NAT actually serves as an enabling > > technology for part of the attack he is describing. > > > I watch the movies too and I hang in suspense as the protagonist waits > for the bad guy to make a network connection and then activates the > phlebotinum that backhacks his tubes. And I know there are some > real-life examples where giving a hacker a large file to download has > kept him connected to a modem long enough to get a phone trace. But I > haven't read of a _nonfiction_ example where the dynamic opening in a > stateful firewall (NAT or otherwise) has directly provided the needed > opening for an _active_ attack by a third party. Can you cite one? > The extent to which NAT is a security hazard in my experience is that it simply makes it harder to find a compromised machine. Someone might inform us that they are seeing suspicious traffic that matches a virus profile from an IP address but the NAT makes it difficult to determine the actual source of the traffic. In that case NAT isn't, in and of itself, the enabling mechanism, but it does offer the compromised host some additional time to do its malicious work while it is being tracked down and eliminated. It also adds more work for providers when someone wants to know who was responsible for certain traffic at certain times. This is particularly true of NAT devices that get their "outside" IP by DHCP. Now they have to search their records and sort out who had that IP at that time and then associate that with a specific customer. Then at the customer location, there might be several more devices (or a neighbor connected over an unsecured wireless) and at that point there is no telling where the traffic came from. So NAT itself isn't a security threat, but it sure gives a real security threat a lot of woodwork in which to hide. G From dotis at mail-abuse.org Fri Jan 14 20:52:09 2011 From: dotis at mail-abuse.org (Douglas Otis) Date: Fri, 14 Jan 2011 18:52:09 -0800 Subject: Is NAT can provide some kind of protection? In-Reply-To: References: <15191.1294852587@localhost> <20110113030222.C79E58B9B35@drugs.dv.isc.org> <4D2FD62F.90305@mail-abuse.org> <72CA680B-D526-4C5F-8E0C-A124AA2EFC7F@delong.com> Message-ID: <4D310BD9.9050204@mail-abuse.org> On 1/14/11 4:10 PM, William Herrin wrote: > On Fri, Jan 14, 2011 at 2:43 PM, Owen DeLong wrote: >> Ah, but, the point here is that NAT actually serves as an enabling >> technology for part of the attack he is describing. > As for strictly passive attacks, like the so-called drive by download, > it is not obvious to me that they would operate differently in a NAT > versus non-NAT stateful firewall environment. Please elucidate. Systems having poor integrity are often _incorrectly_ considered 'safe' behind typical firewalls, but their exposure often includes more than just IP address contacted in a URI. Once initiated, often internal hosts remain connected with any IP address on non-symmetric NATs for some period beyond an initial exchange. A behavior promoted to support teredo, for example. Don't think no one is using IPv6, even when there is only IPv4 access. http://www.symantec.com/avcenter/reference/Teredo_Security.pdf > Explain how [NAT] acts as an enabler. >> Consider the impact the typical NAT or "firewall" has on DNS. > Hi Doug, > > You'd make the argument that NAT aggravates Kaminsky? If you have > something else in mind, I'll have to ask you to spell it out for me. Many of these products themselves are insecure due to bugs in their reference design dutifully replicated by CPE manufactures. These devices often keep no logs, and might even redirect specific DNS queries when owned, where a power-cycling removes all evidence. Even Cisco firewalls were mapping a range of IP addresses, rather than port mapping, and exposed systems unable to endure this type of exposure to the Internet. While it is possible to have a well implemented NAT, many are unable to support DNS TCP exchanges or handle DNSsec. The same devices often restrict port ranges, where prior access to an attacker's authoritative servers gives significant poisoning clues on subsequent exchanges driven by injected iFrames. A system not safe on the Internet, often is also not safe behind the typical CPE NAT/firewall. -Doug From leen at consolejunkie.net Sat Jan 15 06:24:01 2011 From: leen at consolejunkie.net (Leen Besselink) Date: Sat, 15 Jan 2011 13:24:01 +0100 Subject: Is NAT can provide some kind of protection? In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC133C7@RWC-EX1.corp.seven.com> References: <15191.1294852587@localhost><20110113030222.C79E58B9B35@drugs.dv.isc.org><4D2FD62F.90305@mail-abuse.org><72CA680B-D526-4C5F-8E0C-A124AA2EFC7F@delong.com> <5A6D953473350C4B9995546AFE9939EE0BC133C7@RWC-EX1.corp.seven.com> Message-ID: <4D3191E1.9060300@consolejunkie.net> On 01/15/2011 02:01 AM, George Bonser wrote: > >> From: William Herrin >> Sent: Friday, January 14, 2011 4:11 PM >> To: nanog at nanog.org >> Subject: Re: Is NAT can provide some kind of protection? >> >> On Fri, Jan 14, 2011 at 2:43 PM, Owen DeLong wrote: >>> Ah, but, the point here is that NAT actually serves as an enabling >>> technology for part of the attack he is describing. >> >> I watch the movies too and I hang in suspense as the protagonist waits >> for the bad guy to make a network connection and then activates the >> phlebotinum that backhacks his tubes. And I know there are some >> real-life examples where giving a hacker a large file to download has >> kept him connected to a modem long enough to get a phone trace. But I >> haven't read of a _nonfiction_ example where the dynamic opening in a >> stateful firewall (NAT or otherwise) has directly provided the needed >> opening for an _active_ attack by a third party. Can you cite one? >> > > The extent to which NAT is a security hazard in my experience is that it > simply makes it harder to find a compromised machine. Someone might > inform us that they are seeing suspicious traffic that matches a virus > profile from an IP address but the NAT makes it difficult to determine > the actual source of the traffic. In that case NAT isn't, in and of > itself, the enabling mechanism, but it does offer the compromised host > some additional time to do its malicious work while it is being tracked > down and eliminated. > > It also adds more work for providers when someone wants to know who was > responsible for certain traffic at certain times. This is particularly > true of NAT devices that get their "outside" IP by DHCP. Now they have > to search their records and sort out who had that IP at that time and > then associate that with a specific customer. Then at the customer > location, there might be several more devices (or a neighbor connected > over an unsecured wireless) and at that point there is no telling where > the traffic came from. > > So NAT itself isn't a security threat, but it sure gives a real security > threat a lot of woodwork in which to hide. > > G > > I'm a full supported for getting rid of NAT when deploying IPv6, but have to say the alternative is not all that great either. Because what do people want, they want privacy, so they use the IPv6 privacy extensions. Which are enabled by default on Windows when IPv6 is used on XP, Vista and 7. And now you have no idea who had that IPv6-address at some point in time. The solution to that problem is ? I guess the only solution is to have the IPv6 equivalant of arpwatch to log the MAC-addresses/IPv6- address combinations ? Or is their an other solution I'm missing. From joelja at bogus.com Sat Jan 15 08:01:23 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Sat, 15 Jan 2011 15:01:23 +0100 Subject: Is NAT can provide some kind of protection? In-Reply-To: <4D3191E1.9060300@consolejunkie.net> References: <15191.1294852587@localhost><20110113030222.C79E58B9B35@drugs.dv.isc.org><4D2FD62F.90305@mail-abuse.org><72CA680B-D526-4C5F-8E0C-A124AA2EFC7F@delong.com> <5A6D953473350C4B9995546AFE9939EE0BC133C7@RWC-EX1.corp.seven.com> <4D3191E1.9060300@consolejunkie.net> Message-ID: <4D31A8B3.70201@bogus.com> On 1/15/11 1:24 PM, Leen Besselink wrote: > I'm a full supported for getting rid of NAT when deploying IPv6, but > have to say the alternative is not all that great either. > > Because what do people want, they want privacy, so they use the > IPv6 privacy extensions. Which are enabled by default on Windows > when IPv6 is used on XP, Vista and 7. There aren't enough hosts on most subnets that privacy extensions actually buy you that much. sort of like have a bunch of hosts behind a single ip, a bunch of hosts behind a single /64 aren't really insured much in the way of privacy, facebook is going to know that it's you. > And now you have no idea who had that IPv6-address at some point > in time. The solution to that problem is ? I guess the only solution is to > have the IPv6 equivalant of arpwatch to log the MAC-addresses/IPv6- > address combinations ? > > Or is their an other solution I'm missing. > > From leen at consolejunkie.net Sat Jan 15 08:19:17 2011 From: leen at consolejunkie.net (Leen Besselink) Date: Sat, 15 Jan 2011 15:19:17 +0100 Subject: Is NAT can provide some kind of protection? In-Reply-To: <4D31A8B3.70201@bogus.com> References: <15191.1294852587@localhost><20110113030222.C79E58B9B35@drugs.dv.isc.org><4D2FD62F.90305@mail-abuse.org><72CA680B-D526-4C5F-8E0C-A124AA2EFC7F@delong.com> <5A6D953473350C4B9995546AFE9939EE0BC133C7@RWC-EX1.corp.seven.com> <4D3191E1.9060300@consolejunkie.net> <4D31A8B3.70201@bogus.com> Message-ID: <4D31ACE5.2090205@consolejunkie.net> On 01/15/2011 03:01 PM, Joel Jaeggli wrote: > On 1/15/11 1:24 PM, Leen Besselink wrote: > >> I'm a full supported for getting rid of NAT when deploying IPv6, but >> have to say the alternative is not all that great either. >> >> Because what do people want, they want privacy, so they use the >> IPv6 privacy extensions. Which are enabled by default on Windows >> when IPv6 is used on XP, Vista and 7. > There aren't enough hosts on most subnets that privacy extensions > actually buy you that much. sort of like have a bunch of hosts behind a > single ip, a bunch of hosts behind a single /64 aren't really insured > much in the way of privacy, facebook is going to know that it's you. > Now this gets a bit a offtopic, but: If you already have a Facebook account, any site you visit which has "Facebook Connect" on it usually points directly at facebook.com for downloading the 'Facebook connect' image so the Facebook-cookies have already been sent to Facebook. Why would Facebook care about your IP-address ? >> And now you have no idea who had that IPv6-address at some point >> in time. The solution to that problem is ? I guess the only solution is to >> have the IPv6 equivalant of arpwatch to log the MAC-addresses/IPv6- >> address combinations ? >> >> Or is their an other solution I'm missing. >> >> From tme at americafree.tv Sat Jan 15 08:31:17 2011 From: tme at americafree.tv (Marshall Eubanks) Date: Sat, 15 Jan 2011 09:31:17 -0500 Subject: Is NAT can provide some kind of protection? In-Reply-To: <4D31ACE5.2090205@consolejunkie.net> References: <15191.1294852587@localhost><20110113030222.C79E58B9B35@drugs.dv.isc.org><4D2FD62F.90305@mail-abuse.org><72CA680B-D526-4C5F-8E0C-A124AA2EFC7F@delong.com> <5A6D953473350C4B9995546AFE9939EE0BC133C7@RWC-EX1.corp.seven.com> <4D3191E1.9060300@consolejunkie.net> <4D31A8B3.70201@bogus.com> <4D31ACE5.2090205@consolejunkie.net> Message-ID: <446A7368-D5CA-460E-B06D-EED38C6A05A1@americafree.tv> On Jan 15, 2011, at 9:19 AM, Leen Besselink wrote: > On 01/15/2011 03:01 PM, Joel Jaeggli wrote: >> On 1/15/11 1:24 PM, Leen Besselink wrote: >> >>> I'm a full supported for getting rid of NAT when deploying IPv6, but >>> have to say the alternative is not all that great either. >>> >>> Because what do people want, they want privacy, so they use the >>> IPv6 privacy extensions. Which are enabled by default on Windows >>> when IPv6 is used on XP, Vista and 7. >> There aren't enough hosts on most subnets that privacy extensions >> actually buy you that much. sort of like have a bunch of hosts behind a >> single ip, a bunch of hosts behind a single /64 aren't really insured >> much in the way of privacy, facebook is going to know that it's you. >> > > Now this gets a bit a offtopic, but: > > If you already have a Facebook account, any site you visit which has > "Facebook Connect" on it usually points directly at facebook.com for > downloading the 'Facebook connect' image so the Facebook-cookies have > already been sent to Facebook. That assumes that you use the same browser for Facebook as for other uses. I recommend not doing that, but to dedicate a browser for Facebook only, precisely because Facebook plays these sorts of games and is such a security hole. Regards Marshall > > Why would Facebook care about your IP-address ? > >>> And now you have no idea who had that IPv6-address at some point >>> in time. The solution to that problem is ? I guess the only solution is to >>> have the IPv6 equivalant of arpwatch to log the MAC-addresses/IPv6- >>> address combinations ? >>> >>> Or is their an other solution I'm missing. >>> >>> > > > From owen at delong.com Sat Jan 15 11:06:27 2011 From: owen at delong.com (Owen DeLong) Date: Sat, 15 Jan 2011 09:06:27 -0800 Subject: Is NAT can provide some kind of protection? In-Reply-To: <4D31A8B3.70201@bogus.com> References: <15191.1294852587@localhost><20110113030222.C79E58B9B35@drugs.dv.isc.org><4D2FD62F.90305@mail-abuse.org><72CA680B-D526-4C5F-8E0C-A124AA2EFC7F@delong.com> <5A6D953473350C4B9995546AFE9939EE0BC133C7@RWC-EX1.corp.seven.com> <4D3191E1.9060300@consolejunkie.net> <4D31A8B3.70201@bogus.com> Message-ID: <925581AD-F261-4E98-92B9-FADD4F94EA40@delong.com> On Jan 15, 2011, at 6:01 AM, Joel Jaeggli wrote: > On 1/15/11 1:24 PM, Leen Besselink wrote: > >> I'm a full supported for getting rid of NAT when deploying IPv6, but >> have to say the alternative is not all that great either. >> >> Because what do people want, they want privacy, so they use the >> IPv6 privacy extensions. Which are enabled by default on Windows >> when IPv6 is used on XP, Vista and 7. > > There aren't enough hosts on most subnets that privacy extensions > actually buy you that much. sort of like have a bunch of hosts behind a > single ip, a bunch of hosts behind a single /64 aren't really insured > much in the way of privacy, facebook is going to know that it's you. > Privacy extensions aren't intended to hide the location of the transaction. They are intended to prevent a given MAC address from being tracked across a variety of networks. All that they really solve is the problem of "I disabled my cookies, but, the website still knows who I am no matter where I go." Owen From surfer at mauigateway.com Sat Jan 15 11:48:49 2011 From: surfer at mauigateway.com (Scott Weeks) Date: Sat, 15 Jan 2011 09:48:49 -0800 Subject: INDOSAT Internet Network Provider NOC Contact Message-ID: <20110115094849.81EBFB50@resin18.mta.everyone.net> --- tdonahue at vonmail.vonworldwide.com wrote: From: Tim Donahue Sorry for the noise, but I was wondering if anyone has a NOC or BGP knowledgeable contact with INDOSAT Internet Network Provider (AS4761). I have emailed the hostmaster@ email address listed in the WHOIS contact, and tried calling the phone number listed as well (disconnect message). They are announcing one of our prefixes and I am trying to find a contact in their company who can fix the announcement. ----------------------------------------------------- It seems that they were announcing more than just your prefix: ------------------------------------------------------------- From: Aftab Siddiqui To: sanog at sanog.org Subject: [SANOG] ?Hijack? by AS4761 Date: Fri 01/14/11 09:50 PM Just got this news. Anyone in SA region felt anything? I assume many are using 8.8.8.8 these days. "The last 24 hours AS4761, INDOSAT-INP-AP, started to originate a large number of new prefixes. A quick check show that AS4761 originated approximately 2800 new unique prefixes of 824 unique Autonomous systems." Complete story. http://bgpmon.net/blog/?p=400&cpage=1#comment-1890 Regards, Aftab A. Siddiqui -- This is the SANOG (http://www.sanog.org/) mailing list. ------------------------------------------------------------- scott From ryan.finnesey at HarrierInvestments.com Sat Jan 15 12:34:42 2011 From: ryan.finnesey at HarrierInvestments.com (Ryan Finnesey) Date: Sat, 15 Jan 2011 10:34:42 -0800 Subject: Single AS Number for multiple prefixes in different country In-Reply-To: References: Message-ID: <6EFFEFBAC68377459A2E972105C759EC0342BC6D@EXVBE005-2.exch005intermedia.net> We are doing this now and it is working well -----Original Message----- From: Harris Hui [mailto:harris.hui at gmail.com] Sent: Friday, January 14, 2011 4:59 AM To: nanog at nanog.org Subject: Single AS Number for multiple prefixes in different country Hi, We have an AS Number AS2XXXX and have 2 /24 subnets belongs to this AS Number. It is using in US and peering with US Service Providers now. We are going to deploy another site in Asia, can we use the same AS Number AS2XXXX and have 2 other /24 subnets and peering with other Asia Service Providers? Will it affect the routing or BGP Path of our existing subnets in US? Please advise. Thanks Harris :-) From graham at g-rock.net Sat Jan 15 13:51:28 2011 From: graham at g-rock.net (Graham Wooden) Date: Sat, 15 Jan 2011 13:51:28 -0600 Subject: Single AS Number for multiple prefixes in different country In-Reply-To: <6EFFEFBAC68377459A2E972105C759EC0342BC6D@EXVBE005-2.exch005intermedia.net> Message-ID: Not to budge in here ... but I have always been curious of this type of setup, as in all my past BGP deployments its always been that all edges belong in the same ibgp peering group. Ryan, does the other edge(s) get confused when they see their same AS number in the path upon route determination from traffic sourced from another edge? Or are you doing some sort of BGP Confederation? I am progressing down the path (no pun intended) of deploying another edge in another location from which that 'remote' location will have it's own subnets to announce. But if I have a requirement not necessary having to announce the other subnets, I don't need to an expensive L2 back-haul between the two and do what is discussed here, no? -graham On 1/15/11 12:34 PM, "Ryan Finnesey" wrote: > We are doing this now and it is working well > > -----Original Message----- > From: Harris Hui [mailto:harris.hui at gmail.com] > Sent: Friday, January 14, 2011 4:59 AM > To: nanog at nanog.org > Subject: Single AS Number for multiple prefixes in different country > > Hi, > > We have an AS Number AS2XXXX and have 2 /24 subnets belongs to this AS > Number. It is using in US and peering with US Service Providers now. > > We are going to deploy another site in Asia, can we use the same AS > Number AS2XXXX and have 2 other /24 subnets and peering with other Asia > Service Providers? > > Will it affect the routing or BGP Path of our existing subnets in US? > > Please advise. > > Thanks > Harris :-) > From joelja at bogus.com Sat Jan 15 14:00:32 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Sat, 15 Jan 2011 21:00:32 +0100 Subject: Single AS Number for multiple prefixes in different country In-Reply-To: References: Message-ID: <4D31FCE0.8090902@bogus.com> On 1/15/11 8:51 PM, Graham Wooden wrote: > Not to budge in here ... but I have always been curious of this type of > setup, as in all my past BGP deployments its always been that all edges > belong in the same ibgp peering group. > > Ryan, does the other edge(s) get confused when they see their same AS number > in the path upon route determination from traffic sourced from another edge? you just need to defeat loop detection, which you can do on most any router. on junos it's nr_loops 2 > Or are you doing some sort of BGP Confederation? > > I am progressing down the path (no pun intended) of deploying another edge > in another location from which that 'remote' location will have it's own > subnets to announce. But if I have a requirement not necessary having to > announce the other subnets, I don't need to an expensive L2 back-haul > between the two and do what is discussed here, no? > > -graham > > > > On 1/15/11 12:34 PM, "Ryan Finnesey" > wrote: > >> We are doing this now and it is working well >> >> -----Original Message----- >> From: Harris Hui [mailto:harris.hui at gmail.com] >> Sent: Friday, January 14, 2011 4:59 AM >> To: nanog at nanog.org >> Subject: Single AS Number for multiple prefixes in different country >> >> Hi, >> >> We have an AS Number AS2XXXX and have 2 /24 subnets belongs to this AS >> Number. It is using in US and peering with US Service Providers now. >> >> We are going to deploy another site in Asia, can we use the same AS >> Number AS2XXXX and have 2 other /24 subnets and peering with other Asia >> Service Providers? >> >> Will it affect the routing or BGP Path of our existing subnets in US? >> >> Please advise. >> >> Thanks >> Harris :-) >> > > > From chort at smtps.net Sat Jan 15 15:16:14 2011 From: chort at smtps.net (Brian Keefer) Date: Sat, 15 Jan 2011 13:16:14 -0800 Subject: Is NAT can provide some kind of protection? In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC132F6@RWC-EX1.corp.seven.com> References: <5A6D953473350C4B9995546AFE9939EE0BC132F0@RWC-EX1.corp.seven.com> <4D2DDCBA.1050304@gont.com.ar> <5A6D953473350C4B9995546AFE9939EE0BC132F5@RWC-EX1.corp.seven.com> <4D2DDFCC.3020906@brightok.net> <5A6D953473350C4B9995546AFE9939EE0BC132F6@RWC-EX1.corp.seven.com> Message-ID: <20EB8EFD-44A4-49D2-9B3A-C55D133BFF21@smtps.net> On Jan 12, 2011, at 9:21 AM, George Bonser wrote: >> >> I'd eat a hat if a vendor didn't implement a PAT equivalent. It's >> demanded too much. There is money for it, so it will be there. >> >> >> Jack > > Yeah, I think you are right. But in really thinking about it, I wonder > why. The whole point of PAT was address conservation. You don't need > that with v6. All you need to do with v6 is basically have what amounts > to a firewall in transparent mode in the line and doesn't let a packet > in (except where explicitly configure to) unless it is associated with a > packet that went out. > > PAT makes little sense to me for v6, but I suspect you are correct. In > addition, we are putting the "fire suit" on each host in addition to the > firewall. Kernel firewall rules on each host for the *nix boxen. Actually there are a couple very compelling reasons why PAT will probably be implemented for IPv6: 1.) Allows you to redirect a privileged port (on UNIX) to a non-privileged port. For daemons that don't implement some form of privilege revoking after binding to a low port (and/or aren't allowed to run as root), this is very useful. It's much easier to have a firewall redirect than to implement robust privilege revoking. Example: PAT 25/tcp -> 2525/tcp. 2.) Allows you to redirect multiple ports to a single one, to support legacy implementations. Suppose your application used to require separate ports for different types of requests, but now is able to multiplex them. The new daemon only listens on one port, but other applications may not have updated their configuration. Example: PAT 4443/tcp -> 443/tcp & PAT 8443/tcp -> 443/tcp. Basically the idea is that implementing PAT for IPv6 allows smoother transition for apps that made use of it in IPv4, thus accelerating the adoption of IPv6. -- bk From bill at herrin.us Sat Jan 15 15:43:55 2011 From: bill at herrin.us (William Herrin) Date: Sat, 15 Jan 2011 16:43:55 -0500 Subject: Is NAT can provide some kind of protection? In-Reply-To: <20EB8EFD-44A4-49D2-9B3A-C55D133BFF21@smtps.net> References: <5A6D953473350C4B9995546AFE9939EE0BC132F0@RWC-EX1.corp.seven.com> <4D2DDCBA.1050304@gont.com.ar> <5A6D953473350C4B9995546AFE9939EE0BC132F5@RWC-EX1.corp.seven.com> <4D2DDFCC.3020906@brightok.net> <5A6D953473350C4B9995546AFE9939EE0BC132F6@RWC-EX1.corp.seven.com> <20EB8EFD-44A4-49D2-9B3A-C55D133BFF21@smtps.net> Message-ID: On Sat, Jan 15, 2011 at 4:16 PM, Brian Keefer wrote: > 1.) ?Allows you to redirect a privileged port (on UNIX) to a > non-privileged port.?For daemons that don't implement some > form of privilege revoking after binding to a low port (and/or aren't > allowed to run as root), this is very useful. ?It's much easier to > have a firewall redirect than to implement robust privilege revoking. > ?Example: PAT 25/tcp -> 2525/tcp. There was a patch offered for the Linux kernel years ago that exported the network ports as a filesystem where you could set who could bind which port by changing the ownership and permissions on the "files." I never understood why Linus rejected 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 warren at kumari.net Sat Jan 15 15:46:10 2011 From: warren at kumari.net (Warren Kumari) Date: Sat, 15 Jan 2011 16:46:10 -0500 Subject: co-location and access to your server In-Reply-To: References: <4D2E0DF2.4010301@mompl.net> Message-ID: <83FAE949-A92E-48DF-A3B3-4E770D983C25@kumari.net> On Jan 12, 2011, at 3:49 PM, david raistrick wrote: > On Wed, 12 Jan 2011, Jeroen van Aart wrote: > >> What is considered normal with regards to access to your co-located server(s)? Especially when you're just co-locating one or a few servers. > > For less than 1 rack, or specialty racks with lockable sections (1/2 or 1/3 or 1/4 racks with their own doors), I'd consider any physical access to simply be a plus. I wouldn't expect any at all. You're not paying for enough space to justify the costs involved in 24x7 independant access, and the risks to other customers gear. > > > When you get a full rack+, or cage+, I'd expect unfettered 24x7 access since your gear should be seperated and secured from other folks gear. You would think so, wouldn't you? Many years ago I had a cage in 811 10th, with the usual pile 'o goodies in it... I have simple script (aka "tail -f | grep -v" ;-)) that I leave running in the background that tails syslog and only shows me "interesting" messages. One day I notice messages scrolling by, so I go see what is grumping about. Apparently the CF / PCMCIA card in one of the Cisco 7507s has just unmounted. No! Wait, it's back. Nope, gone again. Back. Gone! Back! Yay! It's back... Whoop, I lied, gone.... still gone... still gone... Bah, I figure that the card has just died and the appearing / disappearing trick was just the death rattle, so I take a wander over, and notice that it didn't just unmount, it's completely missing... I manage to get one of the security folk to pull the camera footage for around that time and I see some chappie wanding up and down the aisles, looking in though the mesh at everyone's toys. After the third or forth circuit past our cage he suddenly perks up and hustles off camera. He comes back 2 minutes later with a broom and proceeds to poke the handle through the mesh and bang on the back of the router. Eventually he manages to thwack the eject button hard enough and the flash drops onto the floor -- he wiggles it over, slides it under the edge of the cage, grins like a monkey and scampers back to his cage... I guess when you *really* needs some flash, you *really* needs some flash... W (I have also learnt the hard way not to use the edge of the cage as cable management...) > Some specialty providers would be exceptions, of course (ie, I used to colo gear inside tv stations, satellite downlink stations, etc). > > > Telecom colo (switch and network gear in a dedicated but shared space for providers providing service) would be an exception, of course. > > > -- > david raistrick http://www.netmeister.org/news/learn2quote.html > drais at icantclick.org http://www.expita.com/nomime.html > > From owen at delong.com Sat Jan 15 16:01:46 2011 From: owen at delong.com (Owen DeLong) Date: Sat, 15 Jan 2011 14:01:46 -0800 Subject: Is NAT can provide some kind of protection? In-Reply-To: <20EB8EFD-44A4-49D2-9B3A-C55D133BFF21@smtps.net> References: <5A6D953473350C4B9995546AFE9939EE0BC132F0@RWC-EX1.corp.seven.com> <4D2DDCBA.1050304@gont.com.ar> <5A6D953473350C4B9995546AFE9939EE0BC132F5@RWC-EX1.corp.seven.com> <4D2DDFCC.3020906@brightok.net> <5A6D953473350C4B9995546AFE9939EE0BC132F6@RWC-EX1.corp.seven.com> <20EB8EFD-44A4-49D2-9B3A-C55D133BFF21@smtps.net> Message-ID: On Jan 15, 2011, at 1:16 PM, Brian Keefer wrote: > On Jan 12, 2011, at 9:21 AM, George Bonser wrote: > >>> >>> I'd eat a hat if a vendor didn't implement a PAT equivalent. It's >>> demanded too much. There is money for it, so it will be there. >>> >>> >>> Jack >> >> Yeah, I think you are right. But in really thinking about it, I wonder >> why. The whole point of PAT was address conservation. You don't need >> that with v6. All you need to do with v6 is basically have what amounts >> to a firewall in transparent mode in the line and doesn't let a packet >> in (except where explicitly configure to) unless it is associated with a >> packet that went out. >> >> PAT makes little sense to me for v6, but I suspect you are correct. In >> addition, we are putting the "fire suit" on each host in addition to the >> firewall. Kernel firewall rules on each host for the *nix boxen. > > Actually there are a couple very compelling reasons why PAT will probably be implemented for IPv6: > 1.) Allows you to redirect a privileged port (on UNIX) to a non-privileged port. For daemons that don't implement some form of privilege revoking after binding to a low port (and/or aren't allowed to run as root), this is very useful. It's much easier to have a firewall redirect than to implement robust privilege revoking. Example: PAT 25/tcp -> 2525/tcp. > Actually, that's just port rewriting which is mostly harmless. PAT refers, instead, to a stateful translation which is most definitely not harmless. > 2.) Allows you to redirect multiple ports to a single one, to support legacy implementations. Suppose your application used to require separate ports for different types of requests, but now is able to multiplex them. The new daemon only listens on one port, but other applications may not have updated their configuration. Example: PAT 4443/tcp -> 443/tcp & PAT 8443/tcp -> 443/tcp. > That's a pretty ugly situation, but, it would require a stateful mechanism to address it. I think it is much cleaner to have the daemon listen on the multiple ports. > Basically the idea is that implementing PAT for IPv6 allows smoother transition for apps that made use of it in IPv4, thus accelerating the adoption of IPv6. > I think the lack of IPv4 resources will soon serve as sufficient acceleration of IPv6 adoption. Owen From stephend at gmail.com Sat Jan 15 16:06:07 2011 From: stephend at gmail.com (Stephen Davis) Date: Sun, 16 Jan 2011 11:06:07 +1300 Subject: Is NAT can provide some kind of protection? In-Reply-To: <4D3191E1.9060300@consolejunkie.net> References: <15191.1294852587@localhost> <20110113030222.C79E58B9B35@drugs.dv.isc.org> <4D2FD62F.90305@mail-abuse.org> <72CA680B-D526-4C5F-8E0C-A124AA2EFC7F@delong.com> <5A6D953473350C4B9995546AFE9939EE0BC133C7@RWC-EX1.corp.seven.com> <4D3191E1.9060300@consolejunkie.net> Message-ID: > I'm a full supported for getting rid of NAT when deploying IPv6, but > have to say the alternative is not all that great either. > > Because what do people want, they want privacy, so they use the > IPv6 privacy extensions. Which are enabled by default on Windows > when IPv6 is used on XP, Vista and 7. > > And now you have no idea who had that IPv6-address at some point > in time. The solution to that problem is ? I guess the only solution is to > have the IPv6 equivalant of arpwatch to log the MAC-addresses/IPv6- > address combinations ? > > Or is their an other solution I'm missing. You can solve this problem any of the ways you could solve it in IPv4. Either assign static addresses from DHCPv6, or assign static addresses by hand. From bross at pobox.com Sat Jan 15 17:06:06 2011 From: bross at pobox.com (Brandon Ross) Date: Sat, 15 Jan 2011 18:06:06 -0500 (EST) Subject: Is NAT can provide some kind of protection? In-Reply-To: <20EB8EFD-44A4-49D2-9B3A-C55D133BFF21@smtps.net> References: <5A6D953473350C4B9995546AFE9939EE0BC132F0@RWC-EX1.corp.seven.com> <4D2DDCBA.1050304@gont.com.ar> <5A6D953473350C4B9995546AFE9939EE0BC132F5@RWC-EX1.corp.seven.com> <4D2DDFCC.3020906@brightok.net> <5A6D953473350C4B9995546AFE9939EE0BC132F6@RWC-EX1.corp.seven.com> <20EB8EFD-44A4-49D2-9B3A-C55D133BFF21@smtps.net> Message-ID: On Sat, 15 Jan 2011, Brian Keefer wrote: > Actually there are a couple very compelling reasons why PAT will > probably be implemented for IPv6: You are neglecting the most important reason, much to my own disdain. Service providers will continue to assign only a single IP address to residential users unless they pay an additional fee for additional addresses. Since many residential users won't stand for an additional fee, pressure will be placed on CPE vendors to include v6 PAT in their devices. -- Brandon Ross AIM: BrandonNRoss ICQ: 2269442 Skype: brandonross Yahoo: BrandonNRoss From owen at delong.com Sat Jan 15 17:17:27 2011 From: owen at delong.com (Owen DeLong) Date: Sat, 15 Jan 2011 15:17:27 -0800 Subject: Is NAT can provide some kind of protection? In-Reply-To: References: <5A6D953473350C4B9995546AFE9939EE0BC132F0@RWC-EX1.corp.seven.com> <4D2DDCBA.1050304@gont.com.ar> <5A6D953473350C4B9995546AFE9939EE0BC132F5@RWC-EX1.corp.seven.com> <4D2DDFCC.3020906@brightok.net> <5A6D953473350C4B9995546AFE9939EE0BC132F6@RWC-EX1.corp.seven.com> <20EB8EFD-44A4-49D2-9B3A-C55D133BFF21@smtps.net> Message-ID: <431CD585-5A99-4AB6-AC35-D2E080DAB578@delong.com> On Jan 15, 2011, at 3:06 PM, Brandon Ross wrote: > On Sat, 15 Jan 2011, Brian Keefer wrote: > >> Actually there are a couple very compelling reasons why PAT will probably be implemented for IPv6: > > You are neglecting the most important reason, much to my own disdain. Service providers will continue to assign only a single IP address to residential users unless they pay an additional fee for additional addresses. Since many residential users won't stand for an additional fee, pressure will be placed on CPE vendors to include v6 PAT in their devices. > > -- > Brandon Ross AIM: BrandonNRoss > ICQ: 2269442 > Skype: brandonross Yahoo: BrandonNRoss I really doubt this will be the case in IPv6. The few service providers that try this will rapidly find their customers moving to service providers that do not. I know that Comcast is not planning to do this to their customers. I can't imagine too many ISPs that might even attempt to get away with treating their customers worse than Comcast does. Owen From bross at pobox.com Sat Jan 15 17:24:01 2011 From: bross at pobox.com (Brandon Ross) Date: Sat, 15 Jan 2011 18:24:01 -0500 (EST) Subject: Is NAT can provide some kind of protection? In-Reply-To: <431CD585-5A99-4AB6-AC35-D2E080DAB578@delong.com> References: <5A6D953473350C4B9995546AFE9939EE0BC132F0@RWC-EX1.corp.seven.com> <4D2DDCBA.1050304@gont.com.ar> <5A6D953473350C4B9995546AFE9939EE0BC132F5@RWC-EX1.corp.seven.com> <4D2DDFCC.3020906@brightok.net> <5A6D953473350C4B9995546AFE9939EE0BC132F6@RWC-EX1.corp.seven.com> <20EB8EFD-44A4-49D2-9B3A-C55D133BFF21@smtps.net> <431CD585-5A99-4AB6-AC35-D2E080DAB578@delong.com> Message-ID: On Sat, 15 Jan 2011, Owen DeLong wrote: > I really doubt this will be the case in IPv6. I really hope you are right, because I don't want to see that either, however... Why do you suppose they did that before with IPv4? Sure you can make the argument NOW that v4 is in scarce supply, but 10 years ago it was still the case. Has Comcast actually come out and committed to allowing me to have as my IPs as I want on a consumer connection in the most basic, cheapest package? Has any other major provider? -- Brandon Ross AIM: BrandonNRoss ICQ: 2269442 Skype: brandonross Yahoo: BrandonNRoss From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sat Jan 15 17:30:00 2011 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sun, 16 Jan 2011 10:00:00 +1030 Subject: Is NAT can provide some kind of protection? In-Reply-To: References: <5A6D953473350C4B9995546AFE9939EE0BC132F0@RWC-EX1.corp.seven.com> <4D2DDCBA.1050304@gont.com.ar> <5A6D953473350C4B9995546AFE9939EE0BC132F5@RWC-EX1.corp.seven.com> <4D2DDFCC.3020906@brightok.net> <5A6D953473350C4B9995546AFE9939EE0BC132F6@RWC-EX1.corp.seven.com> <20EB8EFD-44A4-49D2-9B3A-C55D133BFF21@smtps.net> Message-ID: <20110116100000.47c4e40a@opy.nosense.org> On Sat, 15 Jan 2011 18:06:06 -0500 (EST) Brandon Ross wrote: > On Sat, 15 Jan 2011, Brian Keefer wrote: > > > Actually there are a couple very compelling reasons why PAT will > > probably be implemented for IPv6: > > You are neglecting the most important reason, much to my own disdain. > Service providers will continue to assign only a single IP address to > residential users unless they pay an additional fee for additional > addresses. How do you know - have you asked 100% of the service providers out there and they've said unanimously that they're only going to supply a single IPv6 address? > Since many residential users won't stand for an additional > fee, pressure will be placed on CPE vendors to include v6 PAT in their > devices. > > -- > Brandon Ross AIM: BrandonNRoss > ICQ: 2269442 > Skype: brandonross Yahoo: BrandonNRoss > From dotis at mail-abuse.org Sat Jan 15 17:38:17 2011 From: dotis at mail-abuse.org (Douglas Otis) Date: Sat, 15 Jan 2011 15:38:17 -0800 Subject: Is NAT can provide some kind of protection? In-Reply-To: References: <5A6D953473350C4B9995546AFE9939EE0BC132F0@RWC-EX1.corp.seven.com> <4D2DDCBA.1050304@gont.com.ar> <5A6D953473350C4B9995546AFE9939EE0BC132F5@RWC-EX1.corp.seven.com> <4D2DDFCC.3020906@brightok.net> <5A6D953473350C4B9995546AFE9939EE0BC132F6@RWC-EX1.corp.seven.com> <20EB8EFD-44A4-49D2-9B3A-C55D133BFF21@smtps.net> <431CD585-5A99-4AB6-AC35-D2E080DAB578@delong.com> Message-ID: <4D322FE9.8020403@mail-abuse.org> On 1/15/11 3:24 PM, Brandon Ross wrote: > On Sat, 15 Jan 2011, Owen DeLong wrote: > >> I really doubt this will be the case in IPv6. > I really hope you are right, because I don't want to see that either, > however... > > Why do you suppose they did that before with IPv4? Sure you can make > the argument NOW that v4 is in scarce supply, but 10 years ago it was > still the case. > > Has Comcast actually come out and committed to allowing me to have as > my IPs as I want on a consumer connection in the most basic, cheapest > package? Has any other major provider? As a customer of Comcast, you can set up a tunnel to he.net and obtain your own prefix which then enables 18 x 10^18 IP addresses at no additional cost. See: http://tunnelbroker.net/ and http://www.comcast6.net/ -Doug From bross at pobox.com Sat Jan 15 17:39:09 2011 From: bross at pobox.com (Brandon Ross) Date: Sat, 15 Jan 2011 18:39:09 -0500 (EST) Subject: Is NAT can provide some kind of protection? In-Reply-To: <20110116100000.47c4e40a@opy.nosense.org> References: <5A6D953473350C4B9995546AFE9939EE0BC132F0@RWC-EX1.corp.seven.com> <4D2DDCBA.1050304@gont.com.ar> <5A6D953473350C4B9995546AFE9939EE0BC132F5@RWC-EX1.corp.seven.com> <4D2DDFCC.3020906@brightok.net> <5A6D953473350C4B9995546AFE9939EE0BC132F6@RWC-EX1.corp.seven.com> <20EB8EFD-44A4-49D2-9B3A-C55D133BFF21@smtps.net> <20110116100000.47c4e40a@opy.nosense.org> Message-ID: On Sun, 16 Jan 2011, Mark Smith wrote: > How do you know - have you asked 100% of the service providers out > there and they've said unanimously that they're only going to supply a > single IPv6 address? Huh? Who said anything about 100%? It would take only a single reasonably sized provider that has a monopoly in a particular area (tell me that doesn't happen) or a pair of them that have a duopoly (almost everywhere in the US) and you instantly have huge incentive for someone to write some v6 PAT code. Believe me, I'm the last person who wants to see this happen. It's a horrible, moronic, bone-headed situation. Unfortunately, I'm pretty sure it's going to happen because it's been the status quo for so long, and because some marketing dweeb will make the case that the provider is leaving revenue on the table because there will always be some customers who aren't clever enough to use NAT and will buy the upgraded "5 pack" service. -- Brandon Ross AIM: BrandonNRoss ICQ: 2269442 Skype: brandonross Yahoo: BrandonNRoss From mpalmer at hezmatt.org Sat Jan 15 18:02:07 2011 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Sun, 16 Jan 2011 11:02:07 +1100 Subject: Is NAT can provide some kind of protection? In-Reply-To: References: <5A6D953473350C4B9995546AFE9939EE0BC132F0@RWC-EX1.corp.seven.com> <4D2DDCBA.1050304@gont.com.ar> <5A6D953473350C4B9995546AFE9939EE0BC132F5@RWC-EX1.corp.seven.com> <4D2DDFCC.3020906@brightok.net> <5A6D953473350C4B9995546AFE9939EE0BC132F6@RWC-EX1.corp.seven.com> <20EB8EFD-44A4-49D2-9B3A-C55D133BFF21@smtps.net> <431CD585-5A99-4AB6-AC35-D2E080DAB578@delong.com> Message-ID: <20110116000207.GT2766@hezmatt.org> On Sat, Jan 15, 2011 at 06:24:01PM -0500, Brandon Ross wrote: > On Sat, 15 Jan 2011, Owen DeLong wrote: > >> I really doubt this will be the case in IPv6. > > I really hope you are right, because I don't want to see that either, > however... > > Why do you suppose they did that before with IPv4? Sure you can make the > argument NOW that v4 is in scarce supply, but 10 years ago it was still > the case. The finest raisins of all: hysterical raisins. Widespread consumer internet access was dialup, with Trumpet or equivalent. The concept of "home networks" was, at best, for the uber, *uber* nerds (like most people on this list). The idea that an average home user would *ever* need more than one IP was ludicrous, so your basic dialup account provided one IP (although I recall being able to ask for more, for free, if I needed them). Then it became a "value add" to have more than one IP, and then NAT came along because the hackers at home had networks, and then the hackers at home went into IT and used consumer-grade ISPs, and so they deployed NAT in the enterprise, and then those people became the standards writers for PCI DSS... - Matt From frnkblk at iname.com Sat Jan 15 18:21:52 2011 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 15 Jan 2011 18:21:52 -0600 Subject: Is NAT can provide some kind of protection? In-Reply-To: <20110116100000.47c4e40a@opy.nosense.org> References: <5A6D953473350C4B9995546AFE9939EE0BC132F0@RWC-EX1.corp.seven.com> <4D2DDCBA.1050304@gont.com.ar> <5A6D953473350C4B9995546AFE9939EE0BC132F5@RWC-EX1.corp.seven.com> <4D2DDFCC.3020906@brightok.net> <5A6D953473350C4B9995546AFE9939EE0BC132F6@RWC-EX1.corp.seven.com> <20EB8EFD-44A4-49D2-9B3A-C55D133BFF21@smtps.net> <20110116100000.47c4e40a@opy.nosense.org> Message-ID: <002401cbb513$5fd9dab0$1f8d9010$@iname.com> I hope the engineers in the organization will just tell their marketing folk that it's not possible to hand out just one IPv6 address. "Our hardware doesn't support it." I think there's still room for ISPs to charge $10/month for a static prefix, though. And that's technically possible. Frank -----Original Message----- From: Mark Smith [mailto:nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org] Sent: Saturday, January 15, 2011 5:30 PM To: Brandon Ross Cc: NANOG list Subject: Re: Is NAT can provide some kind of protection? On Sat, 15 Jan 2011 18:06:06 -0500 (EST) Brandon Ross wrote: > On Sat, 15 Jan 2011, Brian Keefer wrote: > > > Actually there are a couple very compelling reasons why PAT will > > probably be implemented for IPv6: > > You are neglecting the most important reason, much to my own disdain. > Service providers will continue to assign only a single IP address to > residential users unless they pay an additional fee for additional > addresses. How do you know - have you asked 100% of the service providers out there and they've said unanimously that they're only going to supply a single IPv6 address? > Since many residential users won't stand for an additional > fee, pressure will be placed on CPE vendors to include v6 PAT in their > devices. > > -- > Brandon Ross AIM: BrandonNRoss > ICQ: 2269442 > Skype: brandonross Yahoo: BrandonNRoss > From hanoman at gmail.com Sat Jan 15 19:04:51 2011 From: hanoman at gmail.com (Willy Sutrisno) Date: Sun, 16 Jan 2011 09:04:51 +0800 Subject: INDOSAT Internet Network Provider NOC Contact In-Reply-To: <4D30C983.4070906@vonmail.vonworldwide.com> References: <4D30C983.4070906@vonmail.vonworldwide.com> Message-ID: Hi Try this: support at indosat.com Hope that help. Willy On Sat, Jan 15, 2011 at 6:09 AM, Tim Donahue < tdonahue at vonmail.vonworldwide.com> wrote: > Hi all, > > Sorry for the noise, but I was wondering if anyone has a NOC or BGP > knowledgeable contact with INDOSAT Internet Network Provider > (AS4761). I have emailed the hostmaster@ email address listed in the > WHOIS contact, and tried calling the phone number listed as well (disconnect > message). > > They are announcing one of our prefixes and I am trying to find a contact > in their company who can fix the announcement. > > Tim > > From owen at delong.com Sat Jan 15 19:19:46 2011 From: owen at delong.com (Owen DeLong) Date: Sat, 15 Jan 2011 17:19:46 -0800 Subject: Is NAT can provide some kind of protection? In-Reply-To: <20110116100000.47c4e40a@opy.nosense.org> References: <5A6D953473350C4B9995546AFE9939EE0BC132F0@RWC-EX1.corp.seven.com> <4D2DDCBA.1050304@gont.com.ar> <5A6D953473350C4B9995546AFE9939EE0BC132F5@RWC-EX1.corp.seven.com> <4D2DDFCC.3020906@brightok.net> <5A6D953473350C4B9995546AFE9939EE0BC132F6@RWC-EX1.corp.seven.com> <20EB8EFD-44A4-49D2-9B3A-C55D133BFF21@smtps.net> <20110116100000.47c4e40a@opy.nosense.org> Message-ID: On Jan 15, 2011, at 3:30 PM, Mark Smith wrote: > On Sat, 15 Jan 2011 18:06:06 -0500 (EST) > Brandon Ross wrote: > >> On Sat, 15 Jan 2011, Brian Keefer wrote: >> >>> Actually there are a couple very compelling reasons why PAT will >>> probably be implemented for IPv6: >> >> You are neglecting the most important reason, much to my own disdain. >> Service providers will continue to assign only a single IP address to >> residential users unless they pay an additional fee for additional >> addresses. > > How do you know - have you asked 100% of the service providers out > there and they've said unanimously that they're only going to supply a > single IPv6 address? > I've talked to a lot of them... None of the ones I've talked to have any plans to assign less than a /64 to an end-user. Hopefully the ones that are planning on less than a /48 will come to their senses. Owen From owen at delong.com Sat Jan 15 19:18:40 2011 From: owen at delong.com (Owen DeLong) Date: Sat, 15 Jan 2011 17:18:40 -0800 Subject: Is NAT can provide some kind of protection? In-Reply-To: References: <5A6D953473350C4B9995546AFE9939EE0BC132F0@RWC-EX1.corp.seven.com> <4D2DDCBA.1050304@gont.com.ar> <5A6D953473350C4B9995546AFE9939EE0BC132F5@RWC-EX1.corp.seven.com> <4D2DDFCC.3020906@brightok.net> <5A6D953473350C4B9995546AFE9939EE0BC132F6@RWC-EX1.corp.seven.com> <20EB8EFD-44A4-49D2-9B3A-C55D133BFF21@smtps.net> <431CD585-5A99-4AB6-AC35-D2E080DAB578@delong.com> Message-ID: On Jan 15, 2011, at 3:24 PM, Brandon Ross wrote: > On Sat, 15 Jan 2011, Owen DeLong wrote: > >> I really doubt this will be the case in IPv6. > > I really hope you are right, because I don't want to see that either, however... > > Why do you suppose they did that before with IPv4? Sure you can make the argument NOW that v4 is in scarce supply, but 10 years ago it was still the case. > 1. IPv4 provided no convenient way for them to dynamically assign more than a /32. DHCPv6 allows for DHCP-PD. 2. IPv4 addresses were known to be scarce before most of the current residential ISPs even existed at least in their current form. 10 years ago, we knew that we had gone a decade beyond the point when we recognized that IPv4 would runout if we kept issuing addresses to consumers. Frankly, we didn't, at the time, expect NAT + single address assignments to buy us more than about 10 years and it came as a bit of a surprise when we still had a bunch of space left at that point. > Has Comcast actually come out and committed to allowing me to have as my IPs as I want on a consumer connection in the most basic, cheapest package? Has any other major provider? > No. But they have said that they are issuing prefixes and not host addresses. I doubt any ISP will commit to offering you as many IPs as you want on the most basic consumer grade service as I don't think any ISP would make that commitment on their top of the line business class service, either. However, I think you will see most ISPs offering at least /56s and hopefully /48s. Free.fr is giving out /60s, but, that's due to their limitations on their 6rd deployment and I suspect that when they migrate to native IPv6, they may use larger prefixes. I don't think there's too much to worry about providers handing out individual addresses in IPv6. It's too hard to maintain and it doesn't scale like it did in IPv4. I do think that we have to worry about things like /60s and /56s getting entrenched. I think it is unfortunate that IETF has backed off of the /48 standard in their recent update to 3177. I think that clarification that it is for an end-site would have been better. The use of /56s will hamper innovation and prevent vendors from bringing some cool things to the market. Owen From owen at delong.com Sat Jan 15 19:27:07 2011 From: owen at delong.com (Owen DeLong) Date: Sat, 15 Jan 2011 17:27:07 -0800 Subject: Is NAT can provide some kind of protection? In-Reply-To: <002401cbb513$5fd9dab0$1f8d9010$@iname.com> References: <5A6D953473350C4B9995546AFE9939EE0BC132F0@RWC-EX1.corp.seven.com> <4D2DDCBA.1050304@gont.com.ar> <5A6D953473350C4B9995546AFE9939EE0BC132F5@RWC-EX1.corp.seven.com> <4D2DDFCC.3020906@brightok.net> <5A6D953473350C4B9995546AFE9939EE0BC132F6@RWC-EX1.corp.seven.com> <20EB8EFD-44A4-49D2-9B3A-C55D133BFF21@smtps.net> <20110116100000.47c4e40a@opy.nosense.org> <002401cbb513$5fd9dab0$1f8d9010$@iname.com> Message-ID: <0AC0D4B0-9AAD-45A0-A622-B06B90685412@delong.com> On Jan 15, 2011, at 4:21 PM, Frank Bulk wrote: > I hope the engineers in the organization will just tell their marketing folk > that it's not possible to hand out just one IPv6 address. "Our hardware > doesn't support it." > > I think there's still room for ISPs to charge $10/month for a static prefix, > though. And that's technically possible. > Unfortunate, but, true. Fortunately, I don't have that problem. I got my addresses elsewhere for less. ($100/year from ARIN is less than $120/year from your ISP.) Owen > Frank > > -----Original Message----- > From: Mark Smith > [mailto:nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org] > Sent: Saturday, January 15, 2011 5:30 PM > To: Brandon Ross > Cc: NANOG list > Subject: Re: Is NAT can provide some kind of protection? > > On Sat, 15 Jan 2011 18:06:06 -0500 (EST) > Brandon Ross wrote: > >> On Sat, 15 Jan 2011, Brian Keefer wrote: >> >>> Actually there are a couple very compelling reasons why PAT will >>> probably be implemented for IPv6: >> >> You are neglecting the most important reason, much to my own disdain. >> Service providers will continue to assign only a single IP address to >> residential users unless they pay an additional fee for additional >> addresses. > > How do you know - have you asked 100% of the service providers out > there and they've said unanimously that they're only going to supply a > single IPv6 address? > >> Since many residential users won't stand for an additional >> fee, pressure will be placed on CPE vendors to include v6 PAT in their >> devices. >> >> -- >> Brandon Ross AIM: > BrandonNRoss >> ICQ: > 2269442 >> Skype: brandonross Yahoo: > BrandonNRoss >> > > From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sat Jan 15 21:47:47 2011 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sun, 16 Jan 2011 14:17:47 +1030 Subject: Is NAT can provide some kind of protection? In-Reply-To: References: <5A6D953473350C4B9995546AFE9939EE0BC132F0@RWC-EX1.corp.seven.com> <4D2DDCBA.1050304@gont.com.ar> <5A6D953473350C4B9995546AFE9939EE0BC132F5@RWC-EX1.corp.seven.com> <4D2DDFCC.3020906@brightok.net> <5A6D953473350C4B9995546AFE9939EE0BC132F6@RWC-EX1.corp.seven.com> <20EB8EFD-44A4-49D2-9B3A-C55D133BFF21@smtps.net> <20110116100000.47c4e40a@opy.nosense.org> Message-ID: <20110116141747.7a324e3c@opy.nosense.org> On Sat, 15 Jan 2011 18:39:09 -0500 (EST) Brandon Ross wrote: > On Sun, 16 Jan 2011, Mark Smith wrote: > > > How do you know - have you asked 100% of the service providers out > > there and they've said unanimously that they're only going to supply a > > single IPv6 address? > > Huh? Who said anything about 100%? I think you did .. "Service providers will continue to assign only a single IP address to residential users unless they pay an additional fee for additional addresses." It would take only a single > reasonably sized provider that has a monopoly in a particular area (tell > me that doesn't happen) or a pair of them that have a duopoly (almost > everywhere in the US) and you instantly have huge incentive for someone to > write some v6 PAT code. > And that will create a "huge incentive" for people to acquire larger amounts of address space via other mechanisms, such as 6to4, tunnels, changing to another provider etc. > Believe me, I'm the last person who wants to see this happen. It's a > horrible, moronic, bone-headed situation. Unfortunately, I'm pretty sure > it's going to happen because it's been the status quo for so long, and > because some marketing dweeb will make the case that the provider is > leaving revenue on the table because there will always be some customers > who aren't clever enough to use NAT and will buy the upgraded "5 pack" > service. > I'm confident the opposite will happen. People on this list and similar ones usually understand the value of more than one public address for a home, and commonly enough have routed subnets to their homes, courtesy of their employer, and have probably also been burnt by NAT. They'll be the ones who tell their management "this is how IPv6 is deployed". If they're ignored, they should then say, "and this is how our competitors will be deploying IPv6". Even though customers may not completely understand what they're getting, if one provider has a marketing bullet point of "1 IPv6 address", and another has a marketing bullet point of "Millions of IPv6 addresses", people will just assume more is better and go with the latter. There is no point pretending IPv6 addresses are expensive or trying to make them artificially so. From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sat Jan 15 22:03:12 2011 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sun, 16 Jan 2011 14:33:12 +1030 Subject: Is NAT can provide some kind of protection? In-Reply-To: <002401cbb513$5fd9dab0$1f8d9010$@iname.com> References: <5A6D953473350C4B9995546AFE9939EE0BC132F0@RWC-EX1.corp.seven.com> <4D2DDCBA.1050304@gont.com.ar> <5A6D953473350C4B9995546AFE9939EE0BC132F5@RWC-EX1.corp.seven.com> <4D2DDFCC.3020906@brightok.net> <5A6D953473350C4B9995546AFE9939EE0BC132F6@RWC-EX1.corp.seven.com> <20EB8EFD-44A4-49D2-9B3A-C55D133BFF21@smtps.net> <20110116100000.47c4e40a@opy.nosense.org> <002401cbb513$5fd9dab0$1f8d9010$@iname.com> Message-ID: <20110116143312.131f9c67@opy.nosense.org> On Sat, 15 Jan 2011 18:21:52 -0600 "Frank Bulk" wrote: > I hope the engineers in the organization will just tell their marketing folk > that it's not possible to hand out just one IPv6 address. "Our hardware > doesn't support it." > > I think there's still room for ISPs to charge $10/month for a static prefix, > though. And that's technically possible. > I think it is important to define what "static" means. My definition is that no matter where the customer's network attachment point moves to, the customer retains the same addressing while they have a continued commercial relationship with the SP - in effect PI address space within the SPs network. There is a fairly significant cost to preserving that, a guaranteed route table slot. This is typically a business product offering. The only other alternative people seem to think there is is dynamic, where every time the customer reconnects they may get different addressing. This is the typical residential product offering. I think there is a useful middle point of "stable" addressing, where as long as their point of attachment (or point of service delivery - i.e. their home) doesn't change, a customer would continue to get the same addressing. This idea wasn't as useful or as applicable in IPv4, but would be quite beneficial in IPv6 when DHPCv6-PD is being used. It wouldn't be an assured address assignment, however the SP would endeavour to try to ensure the addressing stays stable over quite long periods of time. It's common enough for LNS/BRASes to do this anyway if the customer's connection lands on the same one. The trick is to expand this stability over the group of all LNS/BRASes that customers can attach to when they reconnect, such that is a SP designed behaviour, rather than an implementation behaviour of each individual LNS/BRAS. Regards, Mark. From jg at freedesktop.org Sat Jan 15 23:12:26 2011 From: jg at freedesktop.org (Jim Gettys) Date: Sun, 16 Jan 2011 00:12:26 -0500 Subject: Is NAT can provide some kind of protection? In-Reply-To: <20110116100000.47c4e40a@opy.nosense.org> References: <5A6D953473350C4B9995546AFE9939EE0BC132F0@RWC-EX1.corp.seven.com> <4D2DDCBA.1050304@gont.com.ar> <5A6D953473350C4B9995546AFE9939EE0BC132F5@RWC-EX1.corp.seven.com> <4D2DDFCC.3020906@brightok.net> <5A6D953473350C4B9995546AFE9939EE0BC132F6@RWC-EX1.corp.seven.com> <20EB8EFD-44A4-49D2-9B3A-C55D133BFF21@smtps.net> <20110116100000.47c4e40a@opy.nosense.org> Message-ID: <4D327E3A.3080207@freedesktop.org> On 01/15/2011 06:30 PM, Mark Smith wrote: > On Sat, 15 Jan 2011 18:06:06 -0500 (EST) > Brandon Ross wrote: > >> On Sat, 15 Jan 2011, Brian Keefer wrote: >> >>> Actually there are a couple very compelling reasons why PAT will >>> probably be implemented for IPv6: >> >> You are neglecting the most important reason, much to my own disdain. >> Service providers will continue to assign only a single IP address to >> residential users unless they pay an additional fee for additional >> addresses. > > How do you know - have you asked 100% of the service providers out > there and they've said unanimously that they're only going to supply a > single IPv6 address? > Can we *please* stop this pointless thread? If not, at least I will inject a fact into this pointless thread with a factoid from Comcast's IPv6 trial, e.g. my address.... I know it is sooo terrible to have the gall to do such a treacherous thing as injecting actual information with counterexample, when such high velocity hand waving is in progress, but such it will be. - Jim jg at jg:~$ /sbin/ifconfig wlan0 wlan0 Link encap:Ethernet HWaddr 00:23:14:4e:3f:50 inet addr:192.168.1.118 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: 2001:55c:62e5:6320:223:14ff:fe4e:3f50/64 Scope:Global inet6 addr: fe80::223:14ff:fe4e:3f50/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:2333470 errors:0 dropped:0 overruns:0 frame:0 TX packets:2117301 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:2474359067 (2.4 GB) TX bytes:1296861717 (1.2 GB) From owen at delong.com Sat Jan 15 23:40:41 2011 From: owen at delong.com (Owen DeLong) Date: Sat, 15 Jan 2011 21:40:41 -0800 Subject: Is NAT can provide some kind of protection? In-Reply-To: <20110116143312.131f9c67@opy.nosense.org> References: <5A6D953473350C4B9995546AFE9939EE0BC132F0@RWC-EX1.corp.seven.com> <4D2DDCBA.1050304@gont.com.ar> <5A6D953473350C4B9995546AFE9939EE0BC132F5@RWC-EX1.corp.seven.com> <4D2DDFCC.3020906@brightok.net> <5A6D953473350C4B9995546AFE9939EE0BC132F6@RWC-EX1.corp.seven.com> <20EB8EFD-44A4-49D2-9B3A-C55D133BFF21@smtps.net> <20110116100000.47c4e40a@opy.nosense.org> <002401cbb513$5fd9dab0$1f8d9010$@iname.com> <20110116143312.131f9c67@opy.nosense.org> Message-ID: <19B4C4E3-B4AA-4ADA-93FD-EFB4362526CD@delong.com> On Jan 15, 2011, at 8:03 PM, Mark Smith wrote: > On Sat, 15 Jan 2011 18:21:52 -0600 > "Frank Bulk" wrote: > >> I hope the engineers in the organization will just tell their marketing folk >> that it's not possible to hand out just one IPv6 address. "Our hardware >> doesn't support it." >> >> I think there's still room for ISPs to charge $10/month for a static prefix, >> though. And that's technically possible. >> > > I think it is important to define what "static" means. My definition is > that no matter where the customer's network attachment point moves to, > the customer retains the same addressing while they have a continued > commercial relationship with the SP - in effect PI address space within > the SPs network. There is a fairly significant cost to preserving that, > a guaranteed route table slot. This is typically a business product > offering. > Uh, yeah, I think most SPs will only provide that as long as the customer is attached at the same POP or possibly in the same Region, whatever their aggregation zone happens to be. If you're going to have the customer tying up a slot in the routing table, there's not much benefit (from an SP perspective) vs. having them go get an AS and a PI Prefix. > The only other alternative people seem to think there is is dynamic, > where every time the customer reconnects they may get different > addressing. This is the typical residential product offering. > Well, there's static as long as the customer stays where they are or moves within the same access aggregation facility. That's relatively easy for the provider and solves 99.99% of the residential customer's problems with dynamic. > I think there is a useful middle point of "stable" addressing, where as > long as their point of attachment (or point of service delivery - i.e. > their home) doesn't change, a customer would continue to get the > same addressing. This idea wasn't as useful or as applicable in IPv4, Frankly, that's what I thought you meant by "static" at first. > but would be quite beneficial in IPv6 when DHPCv6-PD is being used. It > wouldn't be an assured address assignment, however the SP would > endeavour to try to ensure the addressing stays stable over quite long > periods of time. It's common enough for LNS/BRASes to do this anyway if Hmmm... Now your going away from your definition of "stable" to what I would call "semi-sticky dynamic addressing". It's a darker shade of gray than "stable", but, still reasonably usable. > the customer's connection lands on the same one. The trick is to expand > this stability over the group of all LNS/BRASes that customers can > attach to when they reconnect, such that is a SP designed behaviour, > rather than an implementation behaviour of each individual LNS/BRAS. > You're making a rather large assumption here. Namely that all the world is DSL. Owen From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sun Jan 16 02:00:16 2011 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sun, 16 Jan 2011 18:30:16 +1030 Subject: Is NAT can provide some kind of protection? In-Reply-To: <4D327E3A.3080207@freedesktop.org> References: <5A6D953473350C4B9995546AFE9939EE0BC132F0@RWC-EX1.corp.seven.com> <4D2DDCBA.1050304@gont.com.ar> <5A6D953473350C4B9995546AFE9939EE0BC132F5@RWC-EX1.corp.seven.com> <4D2DDFCC.3020906@brightok.net> <5A6D953473350C4B9995546AFE9939EE0BC132F6@RWC-EX1.corp.seven.com> <20EB8EFD-44A4-49D2-9B3A-C55D133BFF21@smtps.net> <20110116100000.47c4e40a@opy.nosense.org> <4D327E3A.3080207@freedesktop.org> Message-ID: <20110116183016.022b2542@opy.nosense.org> On Sun, 16 Jan 2011 00:12:26 -0500 Jim Gettys wrote: > On 01/15/2011 06:30 PM, Mark Smith wrote: > > On Sat, 15 Jan 2011 18:06:06 -0500 (EST) > > Brandon Ross wrote: > > > >> On Sat, 15 Jan 2011, Brian Keefer wrote: > >> > >>> Actually there are a couple very compelling reasons why PAT will > >>> probably be implemented for IPv6: > >> > >> You are neglecting the most important reason, much to my own disdain. > >> Service providers will continue to assign only a single IP address to > >> residential users unless they pay an additional fee for additional > >> addresses. > > > > How do you know - have you asked 100% of the service providers out > > there and they've said unanimously that they're only going to supply a > > single IPv6 address? > > > > Can we *please* stop this pointless thread? > I don't think it pointless to network operators - NAT or not has operational impacts on troubleshooting, network design, addressing plans etc. I understand you aren't a network operator, so if you're not interested perhaps you should unsubscribe. Thanks, Mark. From jg at freedesktop.org Sun Jan 16 08:23:57 2011 From: jg at freedesktop.org (Jim Gettys) Date: Sun, 16 Jan 2011 09:23:57 -0500 Subject: Is NAT can provide some kind of protection? In-Reply-To: <20110116183016.022b2542@opy.nosense.org> References: <5A6D953473350C4B9995546AFE9939EE0BC132F0@RWC-EX1.corp.seven.com> <4D2DDCBA.1050304@gont.com.ar> <5A6D953473350C4B9995546AFE9939EE0BC132F5@RWC-EX1.corp.seven.com> <4D2DDFCC.3020906@brightok.net> <5A6D953473350C4B9995546AFE9939EE0BC132F6@RWC-EX1.corp.seven.com> <20EB8EFD-44A4-49D2-9B3A-C55D133BFF21@smtps.net> <20110116100000.47c4e40a@opy.nosense.org> <4D327E3A.3080207@freedesktop.org> <20110116183016.022b2542@opy.nosense.org> Message-ID: <4D32FF7D.6010704@freedesktop.org> On 01/16/2011 03:00 AM, Mark Smith wrote: >> Can we *please* stop this pointless thread? >> > > I don't think it pointless to network operators - NAT or not has > operational impacts on troubleshooting, network design, addressing plans > etc. I understand you aren't a network operator, so if you're not > interested perhaps you should unsubscribe. > I'm sorry; it is the piece of the thread about whether network operators are going to hand out only single IP addresses in IPv6 that had got my goat. I should have made that clear. - Jim From leen at consolejunkie.net Sun Jan 16 08:46:17 2011 From: leen at consolejunkie.net (Leen Besselink) Date: Sun, 16 Jan 2011 15:46:17 +0100 Subject: Is NAT can provide some kind of protection? In-Reply-To: References: <15191.1294852587@localhost> <20110113030222.C79E58B9B35@drugs.dv.isc.org> <4D2FD62F.90305@mail-abuse.org> <72CA680B-D526-4C5F-8E0C-A124AA2EFC7F@delong.com> <5A6D953473350C4B9995546AFE9939EE0BC133C7@RWC-EX1.corp.seven.com> <4D3191E1.9060300@consolejunkie.net> Message-ID: <4D3304B9.4020908@consolejunkie.net> On 01/15/2011 11:06 PM, Stephen Davis wrote: >> I'm a full supported for getting rid of NAT when deploying IPv6, but >> have to say the alternative is not all that great either. >> >> Because what do people want, they want privacy, so they use the >> IPv6 privacy extensions. Which are enabled by default on Windows >> when IPv6 is used on XP, Vista and 7. >> >> And now you have no idea who had that IPv6-address at some point >> in time. The solution to that problem is ? I guess the only solution is to >> have the IPv6 equivalant of arpwatch to log the MAC-addresses/IPv6- >> address combinations ? >> >> Or is their an other solution I'm missing. > You can solve this problem any of the ways you could solve it in IPv4. > Either assign static addresses from DHCPv6, or assign static addresses > by hand. If you like privacy, you don't need to even have static from DHCPv6, you could have a new address every day (if you turn off your machine daily). Everything else can just query DNS for the address. From d.nostra at gmail.com Sun Jan 16 23:32:56 2011 From: d.nostra at gmail.com (Michel de Nostredame) Date: Sun, 16 Jan 2011 21:32:56 -0800 Subject: Single AS Number for multiple prefixes in different country In-Reply-To: <53E1C7BE-0016-47D1-BDCB-C5F3E366033E@ianai.net> References: <409DB694-6C64-4EC3-A8B3-F31E362D0A33@ianai.net> <4D30349C.6050705@shoshon.ro> <53E1C7BE-0016-47D1-BDCB-C5F3E366033E@ianai.net> Message-ID: On Fri, Jan 14, 2011 at 12:30 PM, Patrick W. Gilmore wrote: > On Jan 14, 2011, at 11:03 AM, Michel de Nostredame wrote: >> On Fri, Jan 14, 2011 at 3:33 AM, Bogdan wrote: >>> allowas-in will do the trick >> Provided your uplink ISP does not filter out that. > Why would your upstream filter that out? > I would get a new upstream if they do. According to Juniper junos document, "BGP checks whether the neighboring AS matches the AS of the external peer to which the router is advertising. If there is a match, the route advertisement is suppressed. Advertisement suppression is enabled by default for BGP peers configured in non-VPN routing and forwarding (VRF) instances, including the master instance." We may not able to assume all ISP willing to or by-default add "advertise-peer-as" into configuration if they use a Juniper router. Also we may not able to assume ISP will not put a policy/route-map to prevent route been advertised to the same AS. If there is a need to use single-AS in multiple sites and these sites need to communicate each other via Internet ISP, statically route traffic to Internet (or a default route to Internet) would be safer. If there is a need on this kind of communication, or the communication been done via a tunnel with both sides using ISP's IP (interface IP) as tunnel source, then there should have no risk to use single-AS in multiple sites in terms of connectivity. -- Michel~ From patrick at ianai.net Mon Jan 17 02:20:32 2011 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 17 Jan 2011 03:20:32 -0500 Subject: Single AS Number for multiple prefixes in different country In-Reply-To: References: <409DB694-6C64-4EC3-A8B3-F31E362D0A33@ianai.net> <4D30349C.6050705@shoshon.ro> <53E1C7BE-0016-47D1-BDCB-C5F3E366033E@ianai.net> Message-ID: <71249BC8-18F0-4D44-B9E2-155C375FC9D3@ianai.net> On Jan 17, 2011, at 12:32 AM, Michel de Nostredame wrote: > On Fri, Jan 14, 2011 at 12:30 PM, Patrick W. Gilmore wrote: >> On Jan 14, 2011, at 11:03 AM, Michel de Nostredame wrote: >>> On Fri, Jan 14, 2011 at 3:33 AM, Bogdan wrote: >>>> allowas-in will do the trick >>> Provided your uplink ISP does not filter out that. >> Why would your upstream filter that out? >> I would get a new upstream if they do. > > According to Juniper junos document, > > "BGP checks whether the neighboring AS matches the AS of the external > peer to which the router is advertising. If there is a match, the > route advertisement is suppressed. Advertisement suppression is > enabled by default for BGP peers configured in non-VPN routing and > forwarding (VRF) instances, including the master instance." I do not think that paragraph means what you think it means. I've seen my own AS in full tables from upstreams using Juniper routers many times. -- TTFN, patrick > We may not able to assume all ISP willing to or by-default add > "advertise-peer-as" into configuration if they use a Juniper router. > Also we may not able to assume ISP will not put a policy/route-map to > prevent route been advertised to the same AS. > > If there is a need to use single-AS in multiple sites and these sites > need to communicate each other via Internet ISP, statically route > traffic to Internet (or a default route to Internet) would be safer. > > If there is a need on this kind of communication, or the communication > been done via a tunnel with both sides using ISP's IP (interface IP) > as tunnel source, then there should have no risk to use single-AS in > multiple sites in terms of connectivity. > > -- > Michel~ > From james at freedomnet.co.nz Mon Jan 17 07:58:37 2011 From: james at freedomnet.co.nz (James Jones) Date: Mon, 17 Jan 2011 08:58:37 -0500 Subject: Network Simulators Message-ID: <4D344B0D.3030602@freedomnet.co.nz> Are there any good Network Simulators/Trainers out there that support IPv6? I want play around with some IPv6 setup. -- James Jones +1-413-667-9199 james at freedomnet.co.nz From arturo.servin at gmail.com Mon Jan 17 08:20:13 2011 From: arturo.servin at gmail.com (Arturo Servin) Date: Mon, 17 Jan 2011 12:20:13 -0200 Subject: Network Simulators In-Reply-To: <4D344B0D.3030602@freedomnet.co.nz> References: <4D344B0D.3030602@freedomnet.co.nz> Message-ID: GNS3 http://www.gns3.net/ This is another network simulator, mainly for academic research. NS-2 http://www.isi.edu/nsnam/ns/ And you can always setup some virtual machines with DNSs, hosts and routers with open-source software. regards, -as On 17 Jan 2011, at 11:58, James Jones wrote: > Are there any good Network Simulators/Trainers out there that support IPv6? I want play around with some IPv6 setup. > > -- > James Jones > +1-413-667-9199 > james at freedomnet.co.nz > From jbates at brightok.net Mon Jan 17 08:17:09 2011 From: jbates at brightok.net (Jack Bates) Date: Mon, 17 Jan 2011 08:17:09 -0600 Subject: Single AS Number for multiple prefixes in different country In-Reply-To: <71249BC8-18F0-4D44-B9E2-155C375FC9D3@ianai.net> References: <409DB694-6C64-4EC3-A8B3-F31E362D0A33@ianai.net> <4D30349C.6050705@shoshon.ro> <53E1C7BE-0016-47D1-BDCB-C5F3E366033E@ianai.net> <71249BC8-18F0-4D44-B9E2-155C375FC9D3@ianai.net> Message-ID: <4D344F65.2030508@brightok.net> On 1/17/2011 2:20 AM, Patrick W. Gilmore wrote: > I do not think that paragraph means what you think it means. > > I've seen my own AS in full tables from upstreams using Juniper routers many times. > I think it's limited to we received from X, we will not send to X. It also probably gets turned off most of the time. However, that is not to say that some router implementation doesn't have an optimized viewpoint of "hey, this would be a loop, so let's not send the route". Such code goes against the nature of BGP, where it's the receiving AS's job to determine policy, including loops. Jack From regnauld at nsrc.org Mon Jan 17 08:26:00 2011 From: regnauld at nsrc.org (Phil Regnauld) Date: Mon, 17 Jan 2011 15:26:00 +0100 Subject: Network Simulators In-Reply-To: References: <4D344B0D.3030602@freedomnet.co.nz> Message-ID: <20110117142600.GJ12402@macbook.catpipe.net> Arturo Servin (arturo.servin) writes: > > GNS3 > http://www.gns3.net/ > > This is another network simulator, mainly for academic research. > > NS-2 > http://www.isi.edu/nsnam/ns/ > > And you can always setup some virtual machines with DNSs, hosts and routers with open-source software. Also to add: http://warriors.eecs.umich.edu/viz_tools/nam.html (referenced from ISI.edu/nsnam above), and the Java version, JAVIS Also worth looking at: http://www.csse.uwa.edu.au/cnet/ (more for pure network simulation, not tied to any particular protocol). And of course, as suggested above, just using a virtual network using something like VirtualBox/KVM and some Linux/BSD boxes, and throw in maybe Dynamips / Dynagen / GNS3 (http://www.gns3.net/) if you want to simulate some IOS. Finally something like Quagga/BIRD for the routing protocol part. Cheers, Phil From progamler-nanog at free.de Mon Jan 17 08:31:02 2011 From: progamler-nanog at free.de (Jan-Philipp Warmers) Date: Mon, 17 Jan 2011 15:31:02 +0100 Subject: Network Simulators In-Reply-To: <4D344B0D.3030602@freedomnet.co.nz> References: <4D344B0D.3030602@freedomnet.co.nz> Message-ID: <20110117143102.GF14290@progamler@free.de> James Jones Tippte am 2011-01-17T08:58-0500: > Are there any good Network Simulators/Trainers out there that support > IPv6? I want play around with some IPv6 setup. im using KVM with briged interfaces and JunOS Olive or vyatta Jan From remy.sanchez at hyperthese.net Mon Jan 17 08:31:12 2011 From: remy.sanchez at hyperthese.net (=?ISO-8859-1?Q?R=E9my_Sanchez?=) Date: Mon, 17 Jan 2011 15:31:12 +0100 Subject: Network Simulators In-Reply-To: <4D344B0D.3030602@freedomnet.co.nz> References: <4D344B0D.3030602@freedomnet.co.nz> Message-ID: <4D3452B0.20300@hyperthese.net> On 01/17/2011 02:58 PM, James Jones wrote: > Are there any good Network Simulators/Trainers out there that support > IPv6? I want play around with some IPv6 setup. I like Cloonix [1]. It still has some rough edges, but is quite easy to hack into. Used it for testing IPv6 configurations =) [1] http://clownix.net/ -- R?my Sanchez -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: From carlosm3011 at gmail.com Mon Jan 17 08:37:26 2011 From: carlosm3011 at gmail.com (Carlos Martinez-Cagnazzo) Date: Mon, 17 Jan 2011 12:37:26 -0200 Subject: Network Simulators In-Reply-To: References: <4D344B0D.3030602@freedomnet.co.nz> Message-ID: I am currently researching virtual simulation environments for the Networking courses that I teach. I am now interested in user-mode linux emulators as they provide more real environments. The one that I am liking the most right now is this one: http://wiki.netkit.org/index.php/Main_Page regards Carlos On Mon, Jan 17, 2011 at 12:20 PM, Arturo Servin wrote: > > GNS3 > http://www.gns3.net/ > > ? ? ? ?This is another network simulator, mainly for academic research. > > NS-2 > http://www.isi.edu/nsnam/ns/ > > ? ? ? ?And you can always setup some virtual machines with DNSs, hosts and routers with open-source software. > > regards, > -as > > On 17 Jan 2011, at 11:58, James Jones wrote: > >> Are there any good Network Simulators/Trainers out there that support IPv6? I want play around with some IPv6 setup. >> >> -- >> James Jones >> +1-413-667-9199 >> james at freedomnet.co.nz >> > > -- -- ========================= Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net ========================= From james at freedomnet.co.nz Mon Jan 17 09:05:21 2011 From: james at freedomnet.co.nz (James Jones) Date: Mon, 17 Jan 2011 10:05:21 -0500 Subject: Network Simulators In-Reply-To: References: <4D344B0D.3030602@freedomnet.co.nz> Message-ID: <4D345AB1.2060102@freedomnet.co.nz> So far GNS3 has won out so far. It seems to work on my Mac fairly well. trying it out now. On 17/01/11 9:37 AM, Carlos Martinez-Cagnazzo wrote: > I am currently researching virtual simulation environments for the > Networking courses that I teach. I am now interested in user-mode > linux emulators as they provide more real environments. > > The one that I am liking the most right now is this one: > http://wiki.netkit.org/index.php/Main_Page > > regards > > Carlos > > On Mon, Jan 17, 2011 at 12:20 PM, Arturo Servin wrote: >> GNS3 >> http://www.gns3.net/ >> >> This is another network simulator, mainly for academic research. >> >> NS-2 >> http://www.isi.edu/nsnam/ns/ >> >> And you can always setup some virtual machines with DNSs, hosts and routers with open-source software. >> >> regards, >> -as >> >> On 17 Jan 2011, at 11:58, James Jones wrote: >> >>> Are there any good Network Simulators/Trainers out there that support IPv6? I want play around with some IPv6 setup. >>> >>> -- >>> James Jones >>> +1-413-667-9199 >>> james at freedomnet.co.nz >>> >> > > From brandon.kim at brandontek.com Mon Jan 17 09:23:33 2011 From: brandon.kim at brandontek.com (Brandon Kim) Date: Mon, 17 Jan 2011 10:23:33 -0500 Subject: Network Simulators In-Reply-To: <4D345AB1.2060102@freedomnet.co.nz> References: <4D344B0D.3030602@freedomnet.co.nz> , , <4D345AB1.2060102@freedomnet.co.nz> Message-ID: James: I've been resisting GNS3 for the longest time, because I like real equipment and to get my hands a little dirty. But for the purpose of simulation, GNS3 helped me identify a BGP issue last week. If it weren't for GNS3, I would not have been able to figure it out. I will be using GNS3 in the future now for as much I can. Remember it is more router oriented than switch. So you can't do any fancy L3 switching...... > Date: Mon, 17 Jan 2011 10:05:21 -0500 > From: james at freedomnet.co.nz > To: nanog at nanog.org > Subject: Re: Network Simulators > > So far GNS3 has won out so far. It seems to work on my Mac fairly well. > trying it out now. > > On 17/01/11 9:37 AM, Carlos Martinez-Cagnazzo wrote: > > I am currently researching virtual simulation environments for the > > Networking courses that I teach. I am now interested in user-mode > > linux emulators as they provide more real environments. > > > > The one that I am liking the most right now is this one: > > http://wiki.netkit.org/index.php/Main_Page > > > > regards > > > > Carlos > > > > On Mon, Jan 17, 2011 at 12:20 PM, Arturo Servin wrote: > >> GNS3 > >> http://www.gns3.net/ > >> > >> This is another network simulator, mainly for academic research. > >> > >> NS-2 > >> http://www.isi.edu/nsnam/ns/ > >> > >> And you can always setup some virtual machines with DNSs, hosts and routers with open-source software. > >> > >> regards, > >> -as > >> > >> On 17 Jan 2011, at 11:58, James Jones wrote: > >> > >>> Are there any good Network Simulators/Trainers out there that support IPv6? I want play around with some IPv6 setup. > >>> > >>> -- > >>> James Jones > >>> +1-413-667-9199 > >>> james at freedomnet.co.nz > >>> > >> > > > > > From Thomas.Weible at flexoptix.net Mon Jan 17 10:14:17 2011 From: Thomas.Weible at flexoptix.net (Thomas Weible) Date: Mon, 17 Jan 2011 17:14:17 +0100 Subject: Cisco Nexus 5000 with 4G FC module - initialization ? Message-ID: Hi, I got some trouble to get the 8-port (4/2/1 FC module) up and running in a Nexus 5000. The module itself is shown in the inventory but when I want to have a detailed look on an interface than there is no option "Fibre Channel". Is there anything else to do with this module (activation, initialization, etc. ?) Thanks Thomas From mwalter at 3z.net Mon Jan 17 10:18:26 2011 From: mwalter at 3z.net (Mike Walter) Date: Mon, 17 Jan 2011 16:18:26 +0000 Subject: Cisco Nexus 5000 with 4G FC module - initialization ? In-Reply-To: References: Message-ID: When you do a show running, do the interfaces show there at all as fc x/x? Do you have the FCOE feature enabled? -Mike -----Original Message----- From: Thomas Weible [mailto:Thomas.Weible at flexoptix.net] Sent: Monday, January 17, 2011 11:14 AM To: nanog at nanog.org Subject: Cisco Nexus 5000 with 4G FC module - initialization ? Hi, I got some trouble to get the 8-port (4/2/1 FC module) up and running in a Nexus 5000. The module itself is shown in the inventory but when I want to have a detailed look on an interface than there is no option "Fibre Channel". Is there anything else to do with this module (activation, initialization, etc. ?) Thanks Thomas From sfischer1967 at gmail.com Mon Jan 17 12:24:51 2011 From: sfischer1967 at gmail.com (Steve Fischer) Date: Mon, 17 Jan 2011 13:24:51 -0500 Subject: Cisco Nexus 5000 with 4G FC module - initialization ? In-Reply-To: References: Message-ID: <007701cbb673$d5728ea0$8057abe0$@gmail.com> Thomas - If I'm not mistaken, there is an additional license needed to activate Fibre-Channel services on the Nexus family of switches. God bless, Steve -----Original Message----- From: Thomas Weible [mailto:Thomas.Weible at flexoptix.net] Sent: Monday, January 17, 2011 11:14 AM To: nanog at nanog.org Subject: Cisco Nexus 5000 with 4G FC module - initialization ? Hi, I got some trouble to get the 8-port (4/2/1 FC module) up and running in a Nexus 5000. The module itself is shown in the inventory but when I want to have a detailed look on an interface than there is no option "Fibre Channel". Is there anything else to do with this module (activation, initialization, etc. ?) Thanks Thomas From d.nostra at gmail.com Mon Jan 17 14:00:53 2011 From: d.nostra at gmail.com (Michel de Nostredame) Date: Mon, 17 Jan 2011 12:00:53 -0800 Subject: Single AS Number for multiple prefixes in different country In-Reply-To: <71249BC8-18F0-4D44-B9E2-155C375FC9D3@ianai.net> References: <409DB694-6C64-4EC3-A8B3-F31E362D0A33@ianai.net> <4D30349C.6050705@shoshon.ro> <53E1C7BE-0016-47D1-BDCB-C5F3E366033E@ianai.net> <71249BC8-18F0-4D44-B9E2-155C375FC9D3@ianai.net> Message-ID: On Mon, Jan 17, 2011 at 12:20 AM, Patrick W. Gilmore wrote: > On Jan 17, 2011, at 12:32 AM, Michel de Nostredame wrote: > I do not think that paragraph means what you think it means. > I've seen my own AS in full tables from upstreams using Juniper routers many times. According to the problem I had, the behavior is more like "when I receive asX from 1st direct link, I will not send to asX on 2nd direct link by default." For example, I (say as#65001) advertised "10.1.0.0/16 ^65001$" on 1st link to my ISP, say as#65000. and advertise "10.2.0.0/16 ^65001$" to the same ISP on 2nd link. Then, I will not receive "10.2.0.0/16 ^65000 65001$" on 1st link, and will not receive "10.1.0.0/16 ^65000 65001$" on 2nd link. I believe my ISP did not intentionally filter out my routes, but it more like default behavior as described in document. Setting up default-route on both of my border routers addressed the needs. After we established the leased line between two sites, we no longer need to send cross site traffic via ISP. -- Michel~ From randy at psg.com Mon Jan 17 14:12:17 2011 From: randy at psg.com (Randy Bush) Date: Mon, 17 Jan 2011 12:12:17 -0800 Subject: Network Simulators In-Reply-To: <4D344B0D.3030602@freedomnet.co.nz> References: <4D344B0D.3030602@freedomnet.co.nz> Message-ID: > Are there any good Network Simulators/Trainers out there that support > IPv6? I want play around with some IPv6 setup. what are you trying to simulate? o control plane? o traffic? o interfaces and layers 1-3? o ... makes a big difference randy From jeffrey.lyon at blacklotus.net Mon Jan 17 14:15:03 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 17 Jan 2011 15:15:03 -0500 Subject: Request Spamhaus contact Message-ID: Someone at Spamhaus please contact me concerning your second consecutive preemptive strike against our IP space. Fun Fact: No one at Spamhaus has ever successfully sent us an abuse complaint. Also, some rocket scientist decided that their sbl-removals@ box should also filter e-mail so blocked parties can't even get in touch. As such, it will be necessary to reply to jeffrey.lyon at gmail.com vs. @blacklotus.net . You claim to monitor sbl-removals@ but it seems i've been ignored for several hours. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From mehmet at akcin.net Mon Jan 17 15:04:41 2011 From: mehmet at akcin.net (Mehmet Akcin) Date: Mon, 17 Jan 2011 13:04:41 -0800 Subject: Donating servers.. where? Message-ID: Hi, I have got some dell servers ( 860s and 1425s ) in mint condition. what's the best way to donate this hardware to someone who can use it for educational research? feel free to contact me directly mehmet From m.hallgren at free.fr Mon Jan 17 15:06:26 2011 From: m.hallgren at free.fr (Michael Hallgren) Date: Mon, 17 Jan 2011 22:06:26 +0100 Subject: Single AS Number for multiple prefixes in different country In-Reply-To: References: <409DB694-6C64-4EC3-A8B3-F31E362D0A33@ianai.net> <4D30349C.6050705@shoshon.ro> <53E1C7BE-0016-47D1-BDCB-C5F3E366033E@ianai.net> <71249BC8-18F0-4D44-B9E2-155C375FC9D3@ianai.net> Message-ID: <1295298386.2800.9.camel@home> Le lundi 17 janvier 2011 ? 12:00 -0800, Michel de Nostredame a ?crit : > On Mon, Jan 17, 2011 at 12:20 AM, Patrick W. Gilmore wrote: > > On Jan 17, 2011, at 12:32 AM, Michel de Nostredame wrote: > > I do not think that paragraph means what you think it means. > > I've seen my own AS in full tables from upstreams using Juniper routers many times. > > According to the problem I had, the behavior is more like > "when I receive asX from 1st direct link, I will not send to asX on > 2nd direct link by default." > > For example, > I (say as#65001) advertised "10.1.0.0/16 ^65001$" on 1st link to my > ISP, say as#65000. > and advertise "10.2.0.0/16 ^65001$" to the same ISP on 2nd link. > > Then, > I will not receive "10.2.0.0/16 ^65000 65001$" on 1st link, > and will not receive "10.1.0.0/16 ^65000 65001$" on 2nd link. > > I believe my ISP did not intentionally filter out my routes, > but it more like default behavior as described in document. > Setting up default-route on both of my border routers addressed the needs. > > After we established the leased line between two sites, > we no longer need to send cross site traffic via ISP. I feel, asking to recieve (and use) default route appears "cleaner" than hacking routing protocol ways. Unless, one does as you just did. Right? Cheers, mh > > -- > Michel~ > From trelane at trelane.net Mon Jan 17 15:23:48 2011 From: trelane at trelane.net (Andrew Kirch) Date: Mon, 17 Jan 2011 16:23:48 -0500 Subject: Request Spamhaus contact In-Reply-To: References: Message-ID: <4D34B364.6060105@trelane.net> I'm not Spamhaus. I don't necessarily agree with their listing policies, but reading your SBL record, http://www.spamhaus.org/sbl/sbl.lasso?query=SBL100691, it appears that someone from your ISP has been in contact with Spamhaus, and were less than thorough in removing the spam gang you guys signed on (PTR records?), or were less than honest about removing them in the first place. For the rest of my life I will mentally equate "DDoS protection solutions" with "foonet". It hasn't failed me since 2001, and doesn't seem to fail me today. Andrew On 1/17/2011 3:15 PM, Jeffrey Lyon wrote: > Someone at Spamhaus please contact me concerning your second > consecutive preemptive strike against our IP space. > > Fun Fact: No one at Spamhaus has ever successfully sent us an abuse > complaint. Also, some rocket scientist decided that their > sbl-removals@ box should also filter e-mail so blocked parties can't > even get in touch. As such, it will be necessary to reply to > jeffrey.lyon at gmail.com vs. @blacklotus.net . > > You claim to monitor sbl-removals@ but it seems i've been ignored for > several hours. > From kevin at steadfast.net Mon Jan 17 15:37:11 2011 From: kevin at steadfast.net (Kevin Stange) Date: Mon, 17 Jan 2011 15:37:11 -0600 Subject: Request Spamhaus contact In-Reply-To: References: Message-ID: <4D34B687.1090003@steadfast.net> On 01/17/2011 02:15 PM, Jeffrey Lyon wrote: > Someone at Spamhaus please contact me concerning your second > consecutive preemptive strike against our IP space. > > Fun Fact: No one at Spamhaus has ever successfully sent us an abuse > complaint. Also, some rocket scientist decided that their > sbl-removals@ box should also filter e-mail so blocked parties can't > even get in touch. As such, it will be necessary to reply to > jeffrey.lyon at gmail.com vs. @blacklotus.net . > > You claim to monitor sbl-removals@ but it seems i've been ignored for > several hours. Spamhaus does monitor sbl-removals@ but they like to do research before they just remove listings. You'll have less luck getting yourself off the listings if they feel you're just there to yell at them for being stupid and don't care enough to take their listing seriously. They were willing to send us automated notifications about new listings matching our IP space as they are added, and you can request this via the removal address when you get a response. They do not file abuse complaints. If you care to explain why you think they made a mistake in a reasonable fashion, it's pretty likely you'll get removed and they'll probably be inclined to give you a bit of extra trust in the future. We started out very defensive against Spamhaus early on, sending angry, demanding messages to sbl-removals at . We found things went much better when we started showing that we considered the information in the listing and explained what we did to investigate and/or why we felt the listing was not warranted (either because we cleaned up the issue or because we felt it was a mistake). There are many RBLs which demand we wait weeks for the possibility of an unfriendly and unhelpful response. Spamhaus is by far the easiest to get along with and most responsive for our network. -- Kevin Stange Chief Technology Officer Steadfast Networks http://steadfast.net Phone: 312-602-2689 ext. 203 | Fax: 312-602-2688 | Cell: 312-320-5867 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 261 bytes Desc: OpenPGP digital signature URL: From davea at staff.gwi.net Mon Jan 17 15:54:26 2011 From: davea at staff.gwi.net (Dave Allen) Date: Mon, 17 Jan 2011 16:54:26 -0500 Subject: Cyan Message-ID: Is there anyone out there using Cyan (cyanoptics.com) who would be willing to share their experiences? I'm looking for any sort of feedback on interoperability issues, bugs, support issues, etc. Z-series products in particular. From jeffrey.lyon at blacklotus.net Mon Jan 17 16:09:07 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 17 Jan 2011 17:09:07 -0500 Subject: Request Spamhaus contact In-Reply-To: <4D34B687.1090003@steadfast.net> References: <4D34B687.1090003@steadfast.net> Message-ID: That's fine, but the listings don't even make sense. There is no evidence in the listing and i'm still trying to figure out a) why they think that these new listings have anything to do with the ones we already cleaned and b) which customers actually need to be removed and for specifically what reasons. Their entire mentality is "the site is pharmacy which means its part of a criminal spammer gang," regardless of whether or not that is true. My initial reply to sbl-removals@ was rather civil, my second reply not so much. At this point I just need them to check their e-mail and answer a few questions. I need intelligence to work with if they expect me to cooperate with them. I have no problem removing customers that need to be removed but I need to have all of the details to act on the request. Thanks, Jeff On Mon, Jan 17, 2011 at 4:37 PM, Kevin Stange wrote: > On 01/17/2011 02:15 PM, Jeffrey Lyon wrote: >> Someone at Spamhaus please contact me concerning your second >> consecutive preemptive strike against our IP space. >> >> Fun Fact: No one at Spamhaus has ever successfully sent us an abuse >> complaint. Also, some rocket scientist decided that their >> sbl-removals@ box should also filter e-mail so blocked parties can't >> even get in touch. As such, it will be necessary to reply to >> jeffrey.lyon at gmail.com vs. @blacklotus.net . >> >> You claim to monitor sbl-removals@ but it seems i've been ignored for >> several hours. > > Spamhaus does monitor sbl-removals@ but they like to do research before > they just remove listings. ?You'll have less luck getting yourself off > the listings if they feel you're just there to yell at them for being > stupid and don't care enough to take their listing seriously. ?They were > willing to send us automated notifications about new listings matching > our IP space as they are added, and you can request this via the removal > address when you get a response. ?They do not file abuse complaints. > > If you care to explain why you think they made a mistake in a reasonable > fashion, it's pretty likely you'll get removed and they'll probably be > inclined to give you a bit of extra trust in the future. > > We started out very defensive against Spamhaus early on, sending angry, > demanding messages to sbl-removals at . ?We found things went much better > when we started showing that we considered the information in the > listing and explained what we did to investigate and/or why we felt the > listing was not warranted (either because we cleaned up the issue or > because we felt it was a mistake). > > There are many RBLs which demand we wait weeks for the possibility of an > unfriendly and unhelpful response. ?Spamhaus is by far the easiest to > get along with and most responsive for our network. > > -- > Kevin Stange > Chief Technology Officer > Steadfast Networks > http://steadfast.net > Phone: 312-602-2689 ext. 203 | Fax: 312-602-2688 | Cell: 312-320-5867 > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From jeffrey.lyon at blacklotus.net Mon Jan 17 16:12:27 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 17 Jan 2011 17:12:27 -0500 Subject: Request Spamhaus contact In-Reply-To: <4D34B364.6060105@trelane.net> References: <4D34B364.6060105@trelane.net> Message-ID: Our listing is misleading. They show me specifically what needs to be done and why and we will act on it. The problem is that they expect me to dig through our customer database and correlate various customers to ROKSO listings. I don't have the resources for this. If they show me where the problem exists I will fix it but so far they do nothing but preemptively block our entire /21 in an attempt to scare us into mass removal of customers. Someone there needs to reply to my questions so I can act on their request. Also, they need to get in touch with ME DIRECTLY before they ban an entire ISP on multiple occasions. I liken their strategy to setting ants on fire and watching them scurry. I've showed a willingness to work with them and correct problems but they think their only option is to list the entire company each time they need something done. Jeff On Mon, Jan 17, 2011 at 4:23 PM, Andrew Kirch wrote: > I'm not Spamhaus. ?I don't necessarily agree with their listing > policies, but reading your SBL record, > http://www.spamhaus.org/sbl/sbl.lasso?query=SBL100691, it appears that > someone from your ISP has been in contact with Spamhaus, and were less > than thorough in removing the spam gang you guys signed on (PTR > records?), or were less than honest about removing them in the first > place. ?For the rest of my life I will mentally equate "DDoS protection > solutions" with "foonet". ?It hasn't failed me since 2001, and doesn't > seem to fail me today. > > Andrew > > > > On 1/17/2011 3:15 PM, Jeffrey Lyon wrote: >> Someone at Spamhaus please contact me concerning your second >> consecutive preemptive strike against our IP space. >> >> Fun Fact: No one at Spamhaus has ever successfully sent us an abuse >> complaint. Also, some rocket scientist decided that their >> sbl-removals@ box should also filter e-mail so blocked parties can't >> even get in touch. As such, it will be necessary to reply to >> jeffrey.lyon at gmail.com vs. @blacklotus.net . >> >> You claim to monitor sbl-removals@ but it seems i've been ignored for >> several hours. >> > > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From rhys at rhavenindustrys.com Mon Jan 17 16:48:56 2011 From: rhys at rhavenindustrys.com (Rhys Rhaven) Date: Mon, 17 Jan 2011 16:48:56 -0600 Subject: Donating servers.. where? In-Reply-To: References: Message-ID: <4D34C758.9090105@rhavenindustrys.com> Donate them to your local hackerspace. http://hackerspaces.org/wiki/Hackerspaces On 01/17/2011 03:04 PM, Mehmet Akcin wrote: > Hi, > > I have got some dell servers ( 860s and 1425s ) in mint condition. > > what's the best way to donate this hardware to someone who can use it for educational research? > > feel free to contact me directly > > mehmet From tom at ninjabadger.net Mon Jan 17 16:57:25 2011 From: tom at ninjabadger.net (Tom Hill) Date: Mon, 17 Jan 2011 22:57:25 +0000 Subject: Request Spamhaus contact In-Reply-To: References: <4D34B364.6060105@trelane.net> Message-ID: <1295305045.2675.5.camel@teh-desktop> On Mon, 2011-01-17 at 17:12 -0500, Jeffrey Lyon wrote: > Our listing is misleading. They show me specifically what needs to be > done and why and we will act on it. The problem is that they expect me > to dig through our customer database and correlate various customers > to ROKSO listings. I don't have the resources for this. Is it really? They list the domains in question and the IPs they resolve to. You should not need such resources, if you have a system that ties the accountability of your users to either a domain name OR an IP address. (Or at the very least, narrows it down to the point where you have little to no guesswork remaining.) I agree that this can be highly frustrating, but it sounds more like a hosting company unprepared for the inevitable 'oh god the sales guys have sold servers to a ROKSO spammer!'. Good luck. :) Tom From jeffrey.lyon at blacklotus.net Mon Jan 17 16:59:36 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 17 Jan 2011 17:59:36 -0500 Subject: Request Spamhaus contact In-Reply-To: References: <4D34B364.6060105@trelane.net> Message-ID: Spamhaus, I just blocked a bunch of customer space without any form of due process or evidence from you: 208.64.123.176/30 208.64.127.64/27 This should resolve SBL101835, SBL101662, and SBL100691. Let me know if any of our customers have any outstanding parking tickets, because I would like to null route them as well. If at any point you would like to actually explain why we were compelled to do this please feel free to contact us at any time that is most convenient to you. Don't worry about our customers, they'll be OK. They understand that that you need to arbitrarily block their e-mail for the common good. Thanks, Jeff On Mon, Jan 17, 2011 at 5:12 PM, Jeffrey Lyon wrote: > Our listing is misleading. They show me specifically what needs to be > done and why and we will act on it. The problem is that they expect me > to dig through our customer database and correlate various customers > to ROKSO listings. I don't have the resources for this. If they show > me where the problem exists I will fix it but so far they do nothing > but preemptively block our entire /21 in an attempt to scare us into > mass removal of customers. > > Someone there needs to reply to my questions so I can act on their > request. Also, they need to get in touch with ME DIRECTLY before they > ban an entire ISP on multiple occasions. I liken their strategy to > setting ants on fire and watching them scurry. I've showed a > willingness to work with them and correct problems but they think > their only option is to list the entire company each time they need > something done. > > Jeff > > On Mon, Jan 17, 2011 at 4:23 PM, Andrew Kirch wrote: >> I'm not Spamhaus. ?I don't necessarily agree with their listing >> policies, but reading your SBL record, >> http://www.spamhaus.org/sbl/sbl.lasso?query=SBL100691, it appears that >> someone from your ISP has been in contact with Spamhaus, and were less >> than thorough in removing the spam gang you guys signed on (PTR >> records?), or were less than honest about removing them in the first >> place. ?For the rest of my life I will mentally equate "DDoS protection >> solutions" with "foonet". ?It hasn't failed me since 2001, and doesn't >> seem to fail me today. >> >> Andrew >> >> >> >> On 1/17/2011 3:15 PM, Jeffrey Lyon wrote: >>> Someone at Spamhaus please contact me concerning your second >>> consecutive preemptive strike against our IP space. >>> >>> Fun Fact: No one at Spamhaus has ever successfully sent us an abuse >>> complaint. Also, some rocket scientist decided that their >>> sbl-removals@ box should also filter e-mail so blocked parties can't >>> even get in touch. As such, it will be necessary to reply to >>> jeffrey.lyon at gmail.com vs. @blacklotus.net . >>> >>> You claim to monitor sbl-removals@ but it seems i've been ignored for >>> several hours. >>> >> >> >> > > > > -- > Jeffrey Lyon, Leadership Team > jeffrey.lyon at blacklotus.net | http://www.blacklotus.net > Black Lotus Communications - AS32421 > First and Leading in DDoS Protection Solutions > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From jeffrey.lyon at blacklotus.net Mon Jan 17 17:06:13 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 17 Jan 2011 18:06:13 -0500 Subject: Request Spamhaus contact In-Reply-To: <1295305045.2675.5.camel@teh-desktop> References: <4D34B364.6060105@trelane.net> <1295305045.2675.5.camel@teh-desktop> Message-ID: Tom, They list domains. For one, these listings are recent and I had no idea they existed until now. One of them was actually received by our abuse@ (the first one ever!) on the 14th and the complaint was already sent to the customer for action. Meanwhile back at Camp Spamhaus, they can't wait three days for us to sort this out despite the sites having been online for months. Second, I still have no idea why they're being listed. I don't see any spam records and I guarantee you that none of the spam came from our network. Oh wait, that's right, Spamhaus' policy is to punish us and thousands of customers for hosting people who are somehow projected to spam at some future point in time based on a top secret formula for which only the holiest of spam crusaders are allowed to bear witness. No actual abuse is required, just the projected possibility of abuse. Highly frustrating is one way of putting it. I prefer the terms "tortuous" and "libelous to go along side "asinine" and "ridiculous." I reached out to them about 5 hours ago, still no response but certainly tens of thousands of mailings rejected. I can only imagine that this would entail a substantial amount of business our non-possible-spammers are losing at the moment. Jeff On Mon, Jan 17, 2011 at 5:57 PM, Tom Hill wrote: > On Mon, 2011-01-17 at 17:12 -0500, Jeffrey Lyon wrote: >> Our listing is misleading. They show me specifically what needs to be >> done and why and we will act on it. The problem is that they expect me >> to dig through our customer database and correlate various customers >> to ROKSO listings. I don't have the resources for this. > > Is it really? They list the domains in question and the IPs they resolve > to. > > You should not need such resources, if you have a system that ties the > accountability of your users to either a domain name OR an IP address. > > (Or at the very least, narrows it down to the point where you have > little to no guesswork remaining.) > > I agree that this can be highly frustrating, but it sounds more like a > hosting company unprepared for the inevitable 'oh god the sales guys > have sold servers to a ROKSO spammer!'. > > Good luck. :) > > Tom > > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From matthew at matthew.at Mon Jan 17 17:16:00 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 17 Jan 2011 15:16:00 -0800 Subject: Cruzio peering In-Reply-To: <4D2E0B9F.9090506@mompl.net> References: <4D2BC2BB.6030608@mompl.net> <4D2BC629.5050105@matthew.at> <4D2E0B9F.9090506@mompl.net> Message-ID: <4D34CDB0.5010104@matthew.at> On 1/12/2011 12:14 PM, Jeroen van Aart wrote: > Matthew Kaufman wrote: >> Have you considered simply asking them? > > Sadly the person I contacted with regards to some colocation business > wasn't able to answer the simplest of question (i.e. from which > netblock do they assign IPs). Or at least the question was met with > silence (he may still be researching the answer :-). So I felt that > asking about peering would be met with even more silence. This is why I said you might consider asking me off-list. > > Someone sent me this link: http://bgp.he.net/AS11994#_peers > AS11994 is the old Gatespeed Broadband (fixed wireless) network that I owned for some time. The main Cruzio network is AS10683. And Cruzio's ADSL network blocks are announced directly by the upstream AS7065. Look at http://whois.arin.net/rest/orgs;q=CZIO?showDetails=true and then check each block out using one of the looking glass servers if you want to do this yourself in the future. Matthew Kaufman From d.nostra at gmail.com Mon Jan 17 17:15:10 2011 From: d.nostra at gmail.com (Michel de Nostredame) Date: Mon, 17 Jan 2011 15:15:10 -0800 Subject: Single AS Number for multiple prefixes in different country In-Reply-To: <1295298386.2800.9.camel@home> References: <409DB694-6C64-4EC3-A8B3-F31E362D0A33@ianai.net> <4D30349C.6050705@shoshon.ro> <53E1C7BE-0016-47D1-BDCB-C5F3E366033E@ianai.net> <71249BC8-18F0-4D44-B9E2-155C375FC9D3@ianai.net> <1295298386.2800.9.camel@home> Message-ID: On Mon, Jan 17, 2011 at 1:06 PM, Michael Hallgren wrote: >> I believe my ISP did not intentionally filter out my routes, >> but it more like default behavior as described in document. >> Setting up default-route on both of my border routers addressed the needs. > > I feel, asking to recieve (and use) default route appears "cleaner" than > hacking routing protocol ways. Unless, one does as you just did. Right? > Yes, asking ISP to send out default-route via BGP sessions will be better then manually setup one. A default-route from dynamic routing protocol can disappear properly in case something wrong over the link, while manual one could possibly create a black hole. BTW, this thread was talking about the use of single-AS in different sites. I think it is no doubt doable. -- Michel~ From nenolod at systeminplace.net Mon Jan 17 17:31:59 2011 From: nenolod at systeminplace.net (William Pitcock) Date: Mon, 17 Jan 2011 17:31:59 -0600 Subject: Request Spamhaus contact In-Reply-To: References: <4D34B687.1090003@steadfast.net> Message-ID: <20110117173159.3fdcd46c@petrie.gateway.2wire.net> Hi, On Mon, 17 Jan 2011 17:09:07 -0500 Jeffrey Lyon wrote: > That's fine, but the listings don't even make sense. There is no > evidence in the listing and i'm still trying to figure out a) why they > think that these new listings have anything to do with the ones we > already cleaned and b) which customers actually need to be removed and > for specifically what reasons. Their entire mentality is "the site is > pharmacy which means its part of a criminal spammer gang," regardless > of whether or not that is true. > Please stop pretending that you're not hosting e-trash. 208.64.122.114 is still hosting an active SEO poisoning site (myspace-codes.com). I think, frankly, it would make your life a lot simpler if you just accepted the fact that BlackLotus sells to e-trash, just like the rest of the "ddos-protected hosting solutions" companies do. > My initial reply to sbl-removals@ was rather civil, my second reply > not so much. At this point I just need them to check their e-mail and > answer a few questions. I need intelligence to work with if they > expect me to cooperate with them. I have no problem removing customers > that need to be removed but I need to have all of the details to act > on the request. You have all the intelligence you need. You host e-trash script kiddies and SEO poisoners. Just go get some wirecutters and snip the wires coming out of that busted up 6509 you used to tout on WHT and the problem will be solved. I have a slogan by the way, "Blacklotus AKA The IRC Company - making EFnet more trashy since FooNet got raided". William From jeffrey.lyon at blacklotus.net Mon Jan 17 17:35:22 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 17 Jan 2011 18:35:22 -0500 Subject: Request Spamhaus contact In-Reply-To: <20110117173159.3fdcd46c@petrie.gateway.2wire.net> References: <4D34B687.1090003@steadfast.net> <20110117173159.3fdcd46c@petrie.gateway.2wire.net> Message-ID: William, I'm not certain that any Black Lotus IP's are even connected to EFnet. Secondly, we're more than happy to act on any data presented to us if they actually care to present it to us before listing the entire ISP. I'm not sure what non-spam related "e-trash" has to do this any of this. Thanks, Jeff On Mon, Jan 17, 2011 at 6:31 PM, William Pitcock wrote: > Hi, > > On Mon, 17 Jan 2011 17:09:07 -0500 > Jeffrey Lyon wrote: > >> That's fine, but the listings don't even make sense. There is no >> evidence in the listing and i'm still trying to figure out a) why they >> think that these new listings have anything to do with the ones we >> already cleaned and b) which customers actually need to be removed and >> for specifically what reasons. Their entire mentality is "the site is >> pharmacy which means its part of a criminal spammer gang," regardless >> of whether or not that is true. >> > > Please stop pretending that you're not hosting e-trash. ?208.64.122.114 > is still hosting an active SEO poisoning site (myspace-codes.com). ?I > think, frankly, it would make your life a lot simpler if you just > accepted the fact that BlackLotus sells to e-trash, just like the rest > of the "ddos-protected hosting solutions" companies do. > >> My initial reply to sbl-removals@ was rather civil, my second reply >> not so much. At this point I just need them to check their e-mail and >> answer a few questions. I need intelligence to work with if they >> expect me to cooperate with them. I have no problem removing customers >> that need to be removed but I need to have all of the details to act >> on the request. > > You have all the intelligence you need. ?You host e-trash script > kiddies and SEO poisoners. ?Just go get some wirecutters and snip the > wires coming out of that busted up 6509 you used to tout on WHT and the > problem will be solved. > > I have a slogan by the way, "Blacklotus AKA The IRC Company - making > EFnet more trashy since FooNet got raided". > > William > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From raymond at prolocation.net Mon Jan 17 17:46:24 2011 From: raymond at prolocation.net (Raymond Dijkxhoorn) Date: Tue, 18 Jan 2011 00:46:24 +0100 (CET) Subject: Request Spamhaus contact In-Reply-To: <20110117173159.3fdcd46c@petrie.gateway.2wire.net> References: <4D34B687.1090003@steadfast.net> <20110117173159.3fdcd46c@petrie.gateway.2wire.net> Message-ID: Hi! >> That's fine, but the listings don't even make sense. There is no >> evidence in the listing and i'm still trying to figure out a) why they >> think that these new listings have anything to do with the ones we >> already cleaned and b) which customers actually need to be removed and >> for specifically what reasons. Their entire mentality is "the site is >> pharmacy which means its part of a criminal spammer gang," regardless >> of whether or not that is true. > Please stop pretending that you're not hosting e-trash. 208.64.122.114 > is still hosting an active SEO poisoning site (myspace-codes.com). I > think, frankly, it would make your life a lot simpler if you just > accepted the fact that BlackLotus sells to e-trash, just like the rest > of the "ddos-protected hosting solutions" companies do. viagra-shopping .com potenzmittel-at .com medicin-24 .com apothekeohnerezept .at [root at noc log]# whois 208.64.122.234 [Querying whois.arin.net] [Redirected to rwhois.blacklotus.net:4321] [Querying rwhois.blacklotus.net] [rwhois.blacklotus.net] %rwhois V-1.0,V-1.5:00090h:00 support.blacklotus.net (Ubersmith RWhois Server V-1.8.0) autharea=208.64.120.0/21 xautharea=208.64.120.0/21 network:Class-Name:network network:Auth-Area:208.64.120.0/21 network:ID:NET-481.208.64.122.232/30 network:Network-Name:Nameserver IP Addresses network:IP-Network:208.64.122.232/30 network:IP-Network-Block:208.64.122.232 - 208.64.122.235 network:Org-Name:Aloli LTD network:Street-Address:3321 Road Town, Drake Chambers network:City:Tortola network:State:- network:Postal-Code:3321 network:Country-Code: network:Tech-Contact:MAINT-481.208.64.122.232/30 network:Created:20101015124139000 network:Updated:20101015124139000 network:Updated-By:support at blacklotus.net network:POC-Name:Network Operations Center network:POC-Email:support at blacklotus.net network:POC-Phone:(323) 657-5944 network:Tech-Name:Network Operations Center network:Tech-Email:support at blacklotus.net network:Tech-Phone:(323) 657-5944 This thread doesnt belong here. But hey, seems they are asking for it. Oh and yes all these botnet landing pages are still up... If i look back at November 2010 archives there is a whole bunch and its adding new domains daily. brandviagra23 .com brandviagra27 .com brandcialis26 .com brandviagra25 .com ... Neh, clean as it can be cough ... Bye, Raymond. From jeffrey.lyon at blacklotus.net Mon Jan 17 17:49:47 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 17 Jan 2011 18:49:47 -0500 Subject: Request Spamhaus contact In-Reply-To: References: <4D34B687.1090003@steadfast.net> <20110117173159.3fdcd46c@petrie.gateway.2wire.net> Message-ID: 1) The sites were already null routed. The problem is with Spamhaus' inability to contact me prior to impacting other legitimate customers. 2) The presumed cleanness of a customer really isn't any of mine or your business, as long as they're not spamming or engaged in any other type of abuse they're free to host web content like anyone else. Jeff On Mon, Jan 17, 2011 at 6:46 PM, Raymond Dijkxhoorn wrote: > Hi! > >>> That's fine, but the listings don't even make sense. There is no >>> evidence in the listing and i'm still trying to figure out a) why they >>> think that these new listings have anything to do with the ones we >>> already cleaned and b) which customers actually need to be removed and >>> for specifically what reasons. Their entire mentality is "the site is >>> pharmacy which means its part of a criminal spammer gang," regardless >>> of whether or not that is true. > >> Please stop pretending that you're not hosting e-trash. ?208.64.122.114 >> is still hosting an active SEO poisoning site (myspace-codes.com). ?I >> think, frankly, it would make your life a lot simpler if you just >> accepted the fact that BlackLotus sells to e-trash, just like the rest >> of the "ddos-protected hosting solutions" companies do. > > viagra-shopping .com > potenzmittel-at .com > medicin-24 .com > apothekeohnerezept .at > > [root at noc log]# whois 208.64.122.234 > [Querying whois.arin.net] > [Redirected to rwhois.blacklotus.net:4321] > [Querying rwhois.blacklotus.net] > [rwhois.blacklotus.net] > %rwhois V-1.0,V-1.5:00090h:00 support.blacklotus.net (Ubersmith RWhois > Server V-1.8.0) > autharea=208.64.120.0/21 > xautharea=208.64.120.0/21 > network:Class-Name:network > network:Auth-Area:208.64.120.0/21 > network:ID:NET-481.208.64.122.232/30 > network:Network-Name:Nameserver IP Addresses > network:IP-Network:208.64.122.232/30 > network:IP-Network-Block:208.64.122.232 - 208.64.122.235 > network:Org-Name:Aloli LTD > network:Street-Address:3321 Road Town, Drake Chambers > network:City:Tortola > network:State:- > network:Postal-Code:3321 > network:Country-Code: > network:Tech-Contact:MAINT-481.208.64.122.232/30 > network:Created:20101015124139000 > network:Updated:20101015124139000 > network:Updated-By:support at blacklotus.net > network:POC-Name:Network Operations Center > network:POC-Email:support at blacklotus.net > network:POC-Phone:(323) 657-5944 > network:Tech-Name:Network Operations Center > network:Tech-Email:support at blacklotus.net > network:Tech-Phone:(323) 657-5944 > > This thread doesnt belong here. But hey, seems they are asking for it. > Oh and yes all these botnet landing pages are still up... > > If i look back at November 2010 archives there is a whole bunch and its > adding new domains daily. > > brandviagra23 .com > brandviagra27 .com > brandcialis26 .com > brandviagra25 .com > ... > > Neh, clean as it can be cough ... > > Bye, > Raymond. > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From nenolod at systeminplace.net Mon Jan 17 17:49:42 2011 From: nenolod at systeminplace.net (William Pitcock) Date: Mon, 17 Jan 2011 17:49:42 -0600 Subject: Request Spamhaus contact In-Reply-To: References: <4D34B687.1090003@steadfast.net> <20110117173159.3fdcd46c@petrie.gateway.2wire.net> Message-ID: <20110117174942.217933fa@petrie.gateway.2wire.net> On Mon, 17 Jan 2011 18:35:22 -0500 Jeffrey Lyon wrote: > William, > > I'm not certain that any Black Lotus IP's are even connected to EFnet. Maybe not presently, but your company has a history in the IRC community. And it's not a history I would define as "good." A history of selling "protection" which was in reality not a technical measure (infact, we know this because back then your employees said outright that DDoS mitigation was being done after the point, so no fancy IntruGuard-like stuff going on there.) but instead an intimidation measure. As in, "DDoS wars", "mutually-assured DoS", so on. Kinda like FooNet/Atrivo/etc. Actually, *exactly* like FooNet/Atrivo/etc. > Secondly, we're more than happy to act on any data presented to us if > they actually care to present it to us before listing the entire ISP. When you keep in mind that many people involved in the anti-abuse community originate from the IRC community, then it should be no surprise that they would not wish to waste their time dealing with people who were part of the "protection racket" of olden days. > > I'm not sure what non-spam related "e-trash" has to do this any of > this. The fact that you willingly pollute the internet as a whole with SEO "optimization" pages says a lot about your company. In my opinion SEO "optimization" pages like myspace-codes.com *are* spam. That is the same opinion held by many others. Do not expect any pity from the rest of us who bust our proverbial asses to keep our netspace clean. William From jeffrey.lyon at blacklotus.net Mon Jan 17 17:54:37 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 17 Jan 2011 18:54:37 -0500 Subject: Request Spamhaus contact In-Reply-To: <20110117174942.217933fa@petrie.gateway.2wire.net> References: <4D34B687.1090003@steadfast.net> <20110117173159.3fdcd46c@petrie.gateway.2wire.net> <20110117174942.217933fa@petrie.gateway.2wire.net> Message-ID: William, Our company is primarily focused on the filtering of DDoS traffic. A significant amount of our IP space is routed elsewhere via proxy or GRE. If a customer pollutes, they pollute and thats their own business. If they abuse, we take action. If Spamhaus contacts us before ruining the business of others, we still take action (believe it or not). We don't actively decide to host any of this content. It sprouts up and really is not a concern of ours until it becomes an actual problem. Comparing us to FOONET and especially Atrivo is ignorant and short sighted. Perhaps you would understand if you were targeted by attacks. Jeff On Mon, Jan 17, 2011 at 6:49 PM, William Pitcock wrote: > On Mon, 17 Jan 2011 18:35:22 -0500 > Jeffrey Lyon wrote: > >> William, >> >> I'm not certain that any Black Lotus IP's are even connected to EFnet. > > Maybe not presently, but your company has a history in the IRC > community. ?And it's not a history I would define as "good." > > A history of selling "protection" which was in reality not a technical > measure (infact, we know this because back then your employees said > outright that DDoS mitigation was being done after the point, so no > fancy IntruGuard-like stuff going on there.) but instead an > intimidation measure. ?As in, "DDoS wars", "mutually-assured DoS", so > on. ?Kinda like FooNet/Atrivo/etc. ?Actually, *exactly* like > FooNet/Atrivo/etc. > >> Secondly, we're more than happy to act on any data presented to us if >> they actually care to present it to us before listing the entire ISP. > > When you keep in mind that many people involved in the anti-abuse > community originate from the IRC community, then it should be no > surprise that they would not wish to waste their time dealing with > people who were part of the "protection racket" of olden days. > >> >> I'm not sure what non-spam related "e-trash" has to do this any of >> this. > > The fact that you willingly pollute the internet as a whole with SEO > "optimization" pages says a lot about your company. ?In my opinion SEO > "optimization" pages like myspace-codes.com *are* spam. ?That is the > same opinion held by many others. > > Do not expect any pity from the rest of us who bust our proverbial > asses to keep our netspace clean. > > William > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From raymond at prolocation.net Mon Jan 17 17:55:00 2011 From: raymond at prolocation.net (Raymond Dijkxhoorn) Date: Tue, 18 Jan 2011 00:55:00 +0100 (CET) Subject: Request Spamhaus contact In-Reply-To: References: <4D34B687.1090003@steadfast.net> <20110117173159.3fdcd46c@petrie.gateway.2wire.net> Message-ID: Hi! > 1) The sites were already null routed. The problem is with Spamhaus' > inability to contact me prior to impacting other legitimate customers. Null routed????? Its up! [root at master tmp]# host www.viagra-shopping.com www.viagra-shopping.com has address 208.64.127.78 >> viagra-shopping .com >> potenzmittel-at .com >> medicin-24 .com >> apothekeohnerezept .at Please take more then 2 seconds to reply and clean up your act first! Jan 17 15:20:08 CET potenzmittel-at.com: [208.64.127.87] You didnt shut down what i put in this mail. Please act now, clean it. Clean more, there is zillions.... You seriously need to check your network first before complaining. Bye, Raymond. From bill at herrin.us Mon Jan 17 17:58:31 2011 From: bill at herrin.us (William Herrin) Date: Mon, 17 Jan 2011 18:58:31 -0500 Subject: Request Spamhaus contact In-Reply-To: References: <4D34B364.6060105@trelane.net> Message-ID: On Mon, Jan 17, 2011 at 5:12 PM, Jeffrey Lyon wrote: > Our listing is misleading. They show me specifically what needs to be > done and why and we will act on it. The problem is that they expect me > to dig through our customer database and correlate various customers > to ROKSO listings. I don't have the resources for this. If they show > me where the problem exists I will fix it but so far they do nothing > but preemptively block our entire /21 in an attempt to scare us into > mass removal of customers. Jeff, I pulled up http://www.spamhaus.org/sbl/sbl.lasso?query=SBL100691 . There is a rather long list at that page of offending IP addresses and names. Just for grins, I picked one at random: 208.64.120.186 canadian-rx-store.org I connected to 208.64.120.186 on TCP port 80 and finger-boned an HTTP request for http://canadian-rx-store.org/ and the server responded as I would expect a server configured with that name to respond. canadian-rx-store.org? Really? Before you cast too many stones, I think you have some work to do. Regards, Bill Herrin P.S. Once this is all done and over with, may I respectfully suggest you carefully review your customer acquisition process? The object lessons are likely to get more expensive. Principals of a Virginia company are not well shielded against liability for facilitating unlawful prescription drug scams. Civil or criminal. -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jeffrey.lyon at blacklotus.net Mon Jan 17 18:01:50 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 17 Jan 2011 19:01:50 -0500 Subject: Request Spamhaus contact In-Reply-To: References: <4D34B364.6060105@trelane.net> Message-ID: Bill, That is not in our IP space. These are the only SBL's we have outstanding: SBL101835 208.64.127.64/27 blacklotus.net 17-Jan-2011 14:44 GMT Drug spam domain hosting SBL101662 208.64.123.176/28 blacklotus.net 14-Jan-2011 10:31 GMT Drug spam domain hosting Those assignments have been null routed (/30 instead of /28 on the latter, since the remaining space is not assigned). Thanks, Jeff On Mon, Jan 17, 2011 at 6:58 PM, William Herrin wrote: > On Mon, Jan 17, 2011 at 5:12 PM, Jeffrey Lyon > wrote: >> Our listing is misleading. They show me specifically what needs to be >> done and why and we will act on it. The problem is that they expect me >> to dig through our customer database and correlate various customers >> to ROKSO listings. I don't have the resources for this. If they show >> me where the problem exists I will fix it but so far they do nothing >> but preemptively block our entire /21 in an attempt to scare us into >> mass removal of customers. > > Jeff, > > I pulled up http://www.spamhaus.org/sbl/sbl.lasso?query=SBL100691 . > There is a rather long list at that page of offending IP addresses and > names. Just for grins, I picked one at random: > > 208.64.120.186 canadian-rx-store.org > > I connected to 208.64.120.186 on TCP port 80 and finger-boned an HTTP > request for http://canadian-rx-store.org/ and the server responded as > I would expect a server configured with that name to respond. > > canadian-rx-store.org? Really? > > Before you cast too many stones, I think you have some work to do. > > Regards, > Bill Herrin > > > P.S. Once this is all done and over with, may I respectfully suggest > you carefully review your customer acquisition process? The object > lessons are likely to get more expensive. Principals of a Virginia > company are not well shielded against liability for facilitating > unlawful prescription drug scams. Civil or criminal. > > > -- > William D. Herrin ................ herrin at dirtside.com? bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From nenolod at systeminplace.net Mon Jan 17 18:07:16 2011 From: nenolod at systeminplace.net (William Pitcock) Date: Mon, 17 Jan 2011 18:07:16 -0600 Subject: Request Spamhaus contact In-Reply-To: References: <4D34B687.1090003@steadfast.net> <20110117173159.3fdcd46c@petrie.gateway.2wire.net> <20110117174942.217933fa@petrie.gateway.2wire.net> Message-ID: <20110117180716.73086697@petrie.gateway.2wire.net> Hi, On Mon, 17 Jan 2011 18:54:37 -0500 Jeffrey Lyon wrote: > William, > > Our company is primarily focused on the filtering of DDoS traffic. A > significant amount of our IP space is routed elsewhere via proxy or > GRE. If a customer pollutes, they pollute and thats their own > business. If they abuse, we take action. If Spamhaus contacts us > before ruining the business of others, we still take action (believe > it or not). > Maybe that is the case now. It was not the case 8 years ago with IRCCo. > We don't actively decide to host any of this content. It sprouts up > and really is not a concern of ours until it becomes an actual > problem. Comparing us to FOONET and especially Atrivo is ignorant and > short sighted. Perhaps you would understand if you were targeted by > attacks. I used to operate DroneBL. DroneBL's DNSBL servers are basically under permanent DDoS attack, which is why Cisco/IronPort and other providers have to sponsor them now. While I understand the current aspect of your operation, you must understand that IRCCo did not make you many friends in the anti-abuse community. Sorry, that's just how it is. We look at BL/IRCCo and it does not make us feel warm and fuzzy. Being proactive by say, checking out your customers before lighting them up would go a long way toward improving the fuzziness perception in the anti-abuse community. But you don't do that. It's clear you don't do that. William From tshaw at oitc.com Mon Jan 17 18:10:25 2011 From: tshaw at oitc.com (TR Shaw) Date: Mon, 17 Jan 2011 19:10:25 -0500 Subject: Request Spamhaus contact In-Reply-To: References: <4D34B687.1090003@steadfast.net> <20110117173159.3fdcd46c@petrie.gateway.2wire.net> Message-ID: I just have to chime in here besides Raymond and others data, I can attest that blacklotus abuse contact is worthless. I have tried to report abuse to blacklotus many times. My last attempt was back in September when I tried for a week to report Canadian Pharmacy pill spam on a blacklotus IP. No response from abuse (not really expected) but no takedown either after a week of reporting over and over again. We don't bother to report to you any more because your abuse email appears to us that its /dev/null'ed Tom On Jan 17, 2011, at 6:55 PM, Raymond Dijkxhoorn wrote: > Hi! > >> 1) The sites were already null routed. The problem is with Spamhaus' >> inability to contact me prior to impacting other legitimate customers. > > Null routed????? > > Its up! > > [root at master tmp]# host www.viagra-shopping.com > www.viagra-shopping.com has address 208.64.127.78 > >>> viagra-shopping .com >>> potenzmittel-at .com >>> medicin-24 .com >>> apothekeohnerezept .at > > Please take more then 2 seconds to reply and clean up your act first! > > Jan 17 15:20:08 CET potenzmittel-at.com: [208.64.127.87] > > You didnt shut down what i put in this mail. Please act now, clean it. Clean more, there is zillions.... > > You seriously need to check your network first before complaining. > > Bye, > Raymond. > > > From bill at herrin.us Mon Jan 17 18:10:16 2011 From: bill at herrin.us (William Herrin) Date: Mon, 17 Jan 2011 19:10:16 -0500 Subject: Request Spamhaus contact In-Reply-To: References: <4D34B364.6060105@trelane.net> Message-ID: On Mon, Jan 17, 2011 at 7:01 PM, Jeffrey Lyon wrote: > On Mon, Jan 17, 2011 at 6:58 PM, William Herrin wrote: >> I pulled up http://www.spamhaus.org/sbl/sbl.lasso?query=SBL100691 . >> There is a rather long list at that page of offending IP addresses and >> names. Just for grins, I picked one at random: >> >> 208.64.120.186 canadian-rx-store.org > > That is not in our IP space. http://whois.arin.net/rest/nets;q=208.64.120.186?showDetails=true&showARIN=false Respectfully yours, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jeffrey.lyon at blacklotus.net Mon Jan 17 18:11:37 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 17 Jan 2011 19:11:37 -0500 Subject: Request Spamhaus contact In-Reply-To: <20110117180716.73086697@petrie.gateway.2wire.net> References: <4D34B687.1090003@steadfast.net> <20110117173159.3fdcd46c@petrie.gateway.2wire.net> <20110117174942.217933fa@petrie.gateway.2wire.net> <20110117180716.73086697@petrie.gateway.2wire.net> Message-ID: William, You're quite right, we don't. We presume that our customers are honorable until proven otherwise. We're a legitimate U.S. based corporation and we make ourselves available to the pertinent RBL's and authorities as appropriate. We take action where action needs to be taken. I take offense, however, to the assumption that our entire company is bad and that all of our customers should suffer because of the actions of a few. I've given Larry @ Spamhaus a direct link to myself and our VP of Ops. If he choose to use it all of these problems can be nipped in the bud. You're quite fortunate to be under the protection of a major corporation, most do not have that luxury. Jeff On Mon, Jan 17, 2011 at 7:07 PM, William Pitcock wrote: > Hi, > > On Mon, 17 Jan 2011 18:54:37 -0500 > Jeffrey Lyon wrote: > >> William, >> >> Our company is primarily focused on the filtering of DDoS traffic. A >> significant amount of our IP space is routed elsewhere via proxy or >> GRE. If a customer pollutes, they pollute and thats their own >> business. If they abuse, we take action. If Spamhaus contacts us >> before ruining the business of others, we still take action (believe >> it or not). >> > > Maybe that is the case now. ?It was not the case 8 years ago with IRCCo. > >> We don't actively decide to host any of this content. It sprouts up >> and really is not a concern of ours until it becomes an actual >> problem. Comparing us to FOONET and especially Atrivo is ignorant and >> short sighted. Perhaps you would understand if you were targeted by >> attacks. > > I used to operate DroneBL. ?DroneBL's DNSBL servers are basically under > permanent DDoS attack, which is why Cisco/IronPort and other providers > have to sponsor them now. > > While I understand the current aspect of your operation, you must > understand that IRCCo did not make you many friends in the anti-abuse > community. ?Sorry, that's just how it is. ?We look at BL/IRCCo and it > does not make us feel warm and fuzzy. > > Being proactive by say, checking out your customers before lighting > them up would go a long way toward improving the fuzziness perception in > the anti-abuse community. ?But you don't do that. ?It's clear you don't > do that. > > William > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From jeffrey.lyon at blacklotus.net Mon Jan 17 18:13:16 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 17 Jan 2011 19:13:16 -0500 Subject: Request Spamhaus contact In-Reply-To: References: <4D34B364.6060105@trelane.net> Message-ID: Bill, I'm getting 72.215.225.9 for that host. Jeff On Mon, Jan 17, 2011 at 7:10 PM, William Herrin wrote: > On Mon, Jan 17, 2011 at 7:01 PM, Jeffrey Lyon > wrote: >> On Mon, Jan 17, 2011 at 6:58 PM, William Herrin wrote: >>> I pulled up http://www.spamhaus.org/sbl/sbl.lasso?query=SBL100691 . >>> There is a rather long list at that page of offending IP addresses and >>> names. Just for grins, I picked one at random: >>> >>> 208.64.120.186 canadian-rx-store.org >> >> That is not in our IP space. > > http://whois.arin.net/rest/nets;q=208.64.120.186?showDetails=true&showARIN=false > > Respectfully yours, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com? bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From raymond at prolocation.net Mon Jan 17 18:12:58 2011 From: raymond at prolocation.net (Raymond Dijkxhoorn) Date: Tue, 18 Jan 2011 01:12:58 +0100 (CET) Subject: Request Spamhaus contact In-Reply-To: References: <4D34B364.6060105@trelane.net> Message-ID: Hi! > That is not in our IP space. These are the only SBL's we have outstanding: > > SBL101835 > 208.64.127.64/27 blacklotus.net > 17-Jan-2011 14:44 GMT > Drug spam domain hosting > > > SBL101662 > 208.64.123.176/28 blacklotus.net > 14-Jan-2011 10:31 GMT > Drug spam domain hosting >> 208.64.120.186 canadian-rx-store.org >> >> I connected to 208.64.120.186 on TCP port 80 and finger-boned an HTTP >> request for http://canadian-rx-store.org/ and the server responded as >> I would expect a server configured with that name to respond. >> >> canadian-rx-store .org? Really? So they need, and will add more. NetRange: 208.64.120.0 - 208.64.127.255 CIDR: 208.64.120.0/21 OriginAS: AS32421 NetName: NET-208-64-120-0-1 NetHandle: NET-208-64-120-0-1 Parent: NET-208-0-0-0-0 NetType: Direct Allocation NameServer: NS1.ENTERPRISE.BLACKLOTUS.NET NameServer: NS2.ENTERPRISE.BLACKLOTUS.NET RegDate: 2005-12-22 Updated: 2009-11-11 Ref: http://whois.arin.net/rest/net/NET-208-64-120-0-1 OrgName: Black Lotus Communications OrgId: BLC-92 Address: 3419 Virginia Beach Blvd. #D5 Thats not your IP space? Really? How come. apothekeosterreich .at -> 208.64.120.197 vertrouwdeapotheek .nl -> 208.64.120.197 viagra-shopping .com -> 208.64.127.78 medicin-24 .com -> 208.64.127.78 apothekeohnerezept .at -> 208.64.127.66 www.medicin-24 .com -> 208.64.127.78 www.viagra-shopping .com -> 208.64.127.78 This is just like 3 minutes digging in todays spamfolders. Instead of typing here, i would be rather nervous and placing null routes wherever i could. Bye, Raymond. From jeffrey.lyon at blacklotus.net Mon Jan 17 18:14:54 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 17 Jan 2011 19:14:54 -0500 Subject: Request Spamhaus contact In-Reply-To: References: <4D34B364.6060105@trelane.net> Message-ID: Raymond, Spam does not make me nervous, it's a practical matter that we will address in due course. The null routes we have set are pretty recent so you may have received some spam prior to that time but I absolutely guarantee you that it did not come from our network, otherwise we would have detected it and stopped it on the spot. Thanks, Jeff On Mon, Jan 17, 2011 at 7:12 PM, Raymond Dijkxhoorn wrote: > Hi! > >> That is not in our IP space. These are the only SBL's we have outstanding: >> >> SBL101835 >> 208.64.127.64/27 ? ? ? ?blacklotus.net >> 17-Jan-2011 14:44 GMT >> Drug spam domain hosting >> >> >> SBL101662 >> 208.64.123.176/28 ? ? ? blacklotus.net >> 14-Jan-2011 10:31 GMT >> Drug spam domain hosting > >>> 208.64.120.186 canadian-rx-store.org >>> >>> I connected to 208.64.120.186 on TCP port 80 and finger-boned an HTTP >>> request for http://canadian-rx-store.org/ and the server responded as >>> I would expect a server configured with that name to respond. >>> >>> canadian-rx-store .org? Really? > > So they need, and will add more. > > NetRange: ? ? ? 208.64.120.0 - 208.64.127.255 > CIDR: ? ? ? ? ? 208.64.120.0/21 > OriginAS: ? ? ? AS32421 > NetName: ? ? ? ?NET-208-64-120-0-1 > NetHandle: ? ? ?NET-208-64-120-0-1 > Parent: ? ? ? ? NET-208-0-0-0-0 > NetType: ? ? ? ?Direct Allocation > NameServer: ? ? NS1.ENTERPRISE.BLACKLOTUS.NET > NameServer: ? ? NS2.ENTERPRISE.BLACKLOTUS.NET > RegDate: ? ? ? ?2005-12-22 > Updated: ? ? ? ?2009-11-11 > Ref: ? ? ? ? ? ?http://whois.arin.net/rest/net/NET-208-64-120-0-1 > > OrgName: ? ? ? ?Black Lotus Communications > OrgId: ? ? ? ? ?BLC-92 > Address: ? ? ? ?3419 Virginia Beach Blvd. #D5 > > Thats not your IP space? Really? How come. > > apothekeosterreich .at -> 208.64.120.197 > vertrouwdeapotheek .nl -> 208.64.120.197 > > viagra-shopping .com -> 208.64.127.78 > medicin-24 .com -> 208.64.127.78 > > apothekeohnerezept .at -> 208.64.127.66 > > www.medicin-24 .com -> 208.64.127.78 > www.viagra-shopping .com -> 208.64.127.78 > > This is just like 3 minutes digging in todays spamfolders. > > Instead of typing here, i would be rather nervous and placing null routes > wherever i could. > > Bye, > Raymond. > > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From raymond at prolocation.net Mon Jan 17 18:14:38 2011 From: raymond at prolocation.net (Raymond Dijkxhoorn) Date: Tue, 18 Jan 2011 01:14:38 +0100 (CET) Subject: Request Spamhaus contact In-Reply-To: References: <4D34B364.6060105@trelane.net> Message-ID: Hi! >> 208.64.120.186 canadian-rx-store.org >> >> That is not in our IP space. > http://whois.arin.net/rest/nets;q=208.64.120.186?showDetails=true&showARIN=false If they claim its not theirs lets ask ARIN to revoke the space. Bye, Raymond. From ml at kenweb.org Mon Jan 17 18:16:36 2011 From: ml at kenweb.org (ML) Date: Mon, 17 Jan 2011 19:16:36 -0500 Subject: [***** SPAM 5.8 *****] Re: Request Spamhaus contact In-Reply-To: References: <4D34B687.1090003@steadfast.net> <20110117173159.3fdcd46c@petrie.gateway.2wire.net> Message-ID: <4D34DBE4.2060702@kenweb.org> On 1/17/2011 6:55 PM, Raymond Dijkxhoorn wrote: > Hi! > >> 1) The sites were already null routed. The problem is with Spamhaus' >> inability to contact me prior to impacting other legitimate customers. > > Null routed????? > > Its up! > > [root at master tmp]# host www.viagra-shopping.com > www.viagra-shopping.com has address 208.64.127.78 > >>> >>> potenzmittel-at .com >>> medicin-24 .com >>> apothekeohnerezept .at > > Please take more then 2 seconds to reply and clean up your act first! > > Jan 17 15:20:08 CET potenzmittel-at.com: [208.64.127.87] > > You didnt shut down what i put in this mail. Please act now, clean it. > Clean more, there is zillions.... > > You seriously need to check your network first before complaining. > > Bye, > Raymond. > > > To be fair. At the time of this email: You can forward resolve viagra-shopping.com but I can't seem to ping the host. Traceroute shows traffic to that IP dying at presumably the edge of Black Lotus network after a handoff from PCCW in LAX. Or did I miss something? From nenolod at systeminplace.net Mon Jan 17 18:17:21 2011 From: nenolod at systeminplace.net (William Pitcock) Date: Mon, 17 Jan 2011 18:17:21 -0600 Subject: Request Spamhaus contact In-Reply-To: References: <4D34B687.1090003@steadfast.net> <20110117173159.3fdcd46c@petrie.gateway.2wire.net> <20110117174942.217933fa@petrie.gateway.2wire.net> <20110117180716.73086697@petrie.gateway.2wire.net> Message-ID: <20110117181721.7004a185@petrie.gateway.2wire.net> Hi, On Mon, 17 Jan 2011 19:11:37 -0500 Jeffrey Lyon wrote: > William, > > You're quite right, we don't. We presume that our customers are > honorable until proven otherwise. We're a legitimate U.S. based > corporation and we make ourselves available to the pertinent RBL's and > authorities as appropriate. We take action where action needs to be > taken. How does refusing service to known spammers/spam operations make you any less of a legitimate U.S. corporation? How come all of the resources mentioned in this thread are still online? > > I take offense, however, to the assumption that our entire company is > bad and that all of our customers should suffer because of the actions > of a few. I've given Larry @ Spamhaus a direct link to myself and our > VP of Ops. If he choose to use it all of these problems can be nipped > in the bud. I do not assume your company is bad. I assume that trying to get anything shut down at BL is a waste of my time. A majority of the people posting on this thread seem to also attest to this point. Just because you're proxying to other networks does not make you unresponsible for their activity. > > You're quite fortunate to be under the protection of a major > corporation, most do not have that luxury. I am not under anyone's protection. DroneBL is, but I no longer operate it due to it being a timesink. Nor should my opinions reflect them in any way. I just wanted to make it clear that I am aware of what it is like to be under permanent DDoS attack. William From jeffrey.lyon at blacklotus.net Mon Jan 17 18:21:19 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 17 Jan 2011 19:21:19 -0500 Subject: Request Spamhaus contact In-Reply-To: <20110117181721.7004a185@petrie.gateway.2wire.net> References: <4D34B687.1090003@steadfast.net> <20110117173159.3fdcd46c@petrie.gateway.2wire.net> <20110117174942.217933fa@petrie.gateway.2wire.net> <20110117180716.73086697@petrie.gateway.2wire.net> <20110117181721.7004a185@petrie.gateway.2wire.net> Message-ID: William, It depends, we have criteria. You can't just e-mail abuse at blacklotus.net and expect any given web site to be immediately shut down. There is due process and we need to make a decision on the matter and serve it to our customer. If a customer is listed at Spamhaus this is sufficient. Being a legitimate corporation means that we're accountable for maintaining certain standards. Everyone assumes that because we mitigate DDoS that we're no better than some offshore spam haven. Jeff BTW: IP space is still null routed, still waiting on Spamhaus to stop nailing innocent customers. On Mon, Jan 17, 2011 at 7:17 PM, William Pitcock wrote: > Hi, > > On Mon, 17 Jan 2011 19:11:37 -0500 > Jeffrey Lyon wrote: > >> William, >> >> You're quite right, we don't. We presume that our customers are >> honorable until proven otherwise. We're a legitimate U.S. based >> corporation and we make ourselves available to the pertinent RBL's and >> authorities as appropriate. We take action where action needs to be >> taken. > > How does refusing service to known spammers/spam operations make you > any less of a legitimate U.S. corporation? ?How come all of the > resources mentioned in this thread are still online? > >> >> I take offense, however, to the assumption that our entire company is >> bad and that all of our customers should suffer because of the actions >> of a few. I've given Larry @ Spamhaus a direct link to myself and our >> VP of Ops. If he choose to use it all of these problems can be nipped >> in the bud. > > I do not assume your company is bad. ?I assume that trying to get > anything shut down at BL is a waste of my time. ?A majority of the > people posting on this thread seem to also attest to this point. > > Just because you're proxying to other networks does not make you > unresponsible for their activity. > >> >> You're quite fortunate to be under the protection of a major >> corporation, most do not have that luxury. > > I am not under anyone's protection. ?DroneBL is, but I no longer > operate it due to it being a timesink. ?Nor should my opinions reflect > them in any way. ?I just wanted to make it clear that I am aware of > what it is like to be under permanent DDoS attack. > > William > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From raymond at prolocation.net Mon Jan 17 18:25:27 2011 From: raymond at prolocation.net (Raymond Dijkxhoorn) Date: Tue, 18 Jan 2011 01:25:27 +0100 (CET) Subject: Request Spamhaus contact In-Reply-To: References: <4D34B364.6060105@trelane.net> Message-ID: Hi! > Spam does not make me nervous, it's a practical matter that we will > address in due course. The null routes we have set are pretty recent > so you may have received some spam prior to that time but I absolutely > guarantee you that it did not come from our network, otherwise we > would have detected it and stopped it on the spot. >> Thats not your IP space? Really? How come. >> >> apothekeosterreich .at -> 208.64.120.197 >> vertrouwdeapotheek .nl -> 208.64.120.197 >> >> viagra-shopping .com -> 208.64.127.78 >> medicin-24 .com -> 208.64.127.78 >> >> apothekeohnerezept .at -> 208.64.127.66 >> >> www.medicin-24 .com -> 208.64.127.78 >> www.viagra-shopping .com -> 208.64.127.78 >> >> This is just like 3 minutes digging in todays spamfolders. www.apothekeosterreich .at is still up at the mentioned ip. Instead of telling you are soooo good on terminating stuff. Can you walk over the list and act? I have sended in many requests for termination. You or your network dont respond to this at all. Its a waste of time even telling it seems. I will stop posting here, spam-l is a much better place for this. But please dont act like you dont know anything whats going on. You have been warned. You have gotten many many reports. But we dont see stuff changing. Good luck with your listing at SpamHaus. Bye, Raymond. From nenolod at systeminplace.net Mon Jan 17 18:26:40 2011 From: nenolod at systeminplace.net (William Pitcock) Date: Mon, 17 Jan 2011 18:26:40 -0600 Subject: Request Spamhaus contact In-Reply-To: References: <4D34B364.6060105@trelane.net> Message-ID: <20110117182640.69bb1531@petrie.gateway.2wire.net> Hi, On Mon, 17 Jan 2011 19:13:16 -0500 Jeffrey Lyon wrote: > Bill, > > I'm getting 72.215.225.9 for that host. The nameservers just changed to ns2/ns4.codiz.net. ns2 is a bogon, the real deal is ns4 hosted at corbina.ru, which has an abuse@ that goes to /dev/null so whatever. Man. Hosting Yandex. Really? How did you manage to not catch that? William From tshaw at oitc.com Mon Jan 17 18:30:04 2011 From: tshaw at oitc.com (TR Shaw) Date: Mon, 17 Jan 2011 19:30:04 -0500 Subject: Request Spamhaus contact In-Reply-To: References: <4D34B364.6060105@trelane.net> Message-ID: <9DB2D57D-832F-4D3F-9B93-18F1947EDC0F@oitc.com> So the fact that you host the spamvertized pill and other spam sites makes it OK because the spamming email came from residential machines that were coopted? That's weird logic but maybe that's why your abuse never responded to us nor shuts them down. Tom On Jan 17, 2011, at 7:14 PM, Jeffrey Lyon wrote: > Raymond, > > Spam does not make me nervous, it's a practical matter that we will > address in due course. The null routes we have set are pretty recent > so you may have received some spam prior to that time but I absolutely > guarantee you that it did not come from our network, otherwise we > would have detected it and stopped it on the spot. > > Thanks, Jeff > > > On Mon, Jan 17, 2011 at 7:12 PM, Raymond Dijkxhoorn > wrote: >> Hi! >> >>> That is not in our IP space. These are the only SBL's we have outstanding: >>> >>> SBL101835 >>> 208.64.127.64/27 blacklotus.net >>> 17-Jan-2011 14:44 GMT >>> Drug spam domain hosting >>> >>> >>> SBL101662 >>> 208.64.123.176/28 blacklotus.net >>> 14-Jan-2011 10:31 GMT >>> Drug spam domain hosting >> >>>> 208.64.120.186 canadian-rx-store.org >>>> >>>> I connected to 208.64.120.186 on TCP port 80 and finger-boned an HTTP >>>> request for http://canadian-rx-store.org/ and the server responded as >>>> I would expect a server configured with that name to respond. >>>> >>>> canadian-rx-store .org? Really? >> >> So they need, and will add more. >> >> NetRange: 208.64.120.0 - 208.64.127.255 >> CIDR: 208.64.120.0/21 >> OriginAS: AS32421 >> NetName: NET-208-64-120-0-1 >> NetHandle: NET-208-64-120-0-1 >> Parent: NET-208-0-0-0-0 >> NetType: Direct Allocation >> NameServer: NS1.ENTERPRISE.BLACKLOTUS.NET >> NameServer: NS2.ENTERPRISE.BLACKLOTUS.NET >> RegDate: 2005-12-22 >> Updated: 2009-11-11 >> Ref: http://whois.arin.net/rest/net/NET-208-64-120-0-1 >> >> OrgName: Black Lotus Communications >> OrgId: BLC-92 >> Address: 3419 Virginia Beach Blvd. #D5 >> >> Thats not your IP space? Really? How come. >> >> apothekeosterreich .at -> 208.64.120.197 >> vertrouwdeapotheek .nl -> 208.64.120.197 >> >> viagra-shopping .com -> 208.64.127.78 >> medicin-24 .com -> 208.64.127.78 >> >> apothekeohnerezept .at -> 208.64.127.66 >> >> www.medicin-24 .com -> 208.64.127.78 >> www.viagra-shopping .com -> 208.64.127.78 >> >> This is just like 3 minutes digging in todays spamfolders. >> >> Instead of typing here, i would be rather nervous and placing null routes >> wherever i could. >> >> Bye, >> Raymond. >> >> >> > > > > -- > Jeffrey Lyon, Leadership Team > jeffrey.lyon at blacklotus.net | http://www.blacklotus.net > Black Lotus Communications - AS32421 > First and Leading in DDoS Protection Solutions > From jeffrey.lyon at blacklotus.net Mon Jan 17 18:30:56 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 17 Jan 2011 19:30:56 -0500 Subject: Request Spamhaus contact In-Reply-To: <9DB2D57D-832F-4D3F-9B93-18F1947EDC0F@oitc.com> References: <4D34B364.6060105@trelane.net> <9DB2D57D-832F-4D3F-9B93-18F1947EDC0F@oitc.com> Message-ID: Actually, that was just a brain lapse. The domain didn't resolve at all (misspelled?) and it returned the Cox default resolution. Jeff On Mon, Jan 17, 2011 at 7:30 PM, TR Shaw wrote: > So the fact that you host the spamvertized pill and other spam sites makes it OK because the spamming email came from residential machines that were coopted? > > That's weird logic but maybe that's why your abuse never responded to us nor shuts them down. > > Tom > > On Jan 17, 2011, at 7:14 PM, Jeffrey Lyon wrote: > >> Raymond, >> >> Spam does not make me nervous, it's a practical matter that we will >> address in due course. The null routes we have set are pretty recent >> so you may have received some spam prior to that time but I absolutely >> guarantee you that it did not come from our network, otherwise we >> would have detected it and stopped it on the spot. >> >> Thanks, Jeff >> >> >> On Mon, Jan 17, 2011 at 7:12 PM, Raymond Dijkxhoorn >> wrote: >>> Hi! >>> >>>> That is not in our IP space. These are the only SBL's we have outstanding: >>>> >>>> SBL101835 >>>> 208.64.127.64/27 ? ? ? ?blacklotus.net >>>> 17-Jan-2011 14:44 GMT >>>> Drug spam domain hosting >>>> >>>> >>>> SBL101662 >>>> 208.64.123.176/28 ? ? ? blacklotus.net >>>> 14-Jan-2011 10:31 GMT >>>> Drug spam domain hosting >>> >>>>> 208.64.120.186 canadian-rx-store.org >>>>> >>>>> I connected to 208.64.120.186 on TCP port 80 and finger-boned an HTTP >>>>> request for http://canadian-rx-store.org/ and the server responded as >>>>> I would expect a server configured with that name to respond. >>>>> >>>>> canadian-rx-store .org? Really? >>> >>> So they need, and will add more. >>> >>> NetRange: ? ? ? 208.64.120.0 - 208.64.127.255 >>> CIDR: ? ? ? ? ? 208.64.120.0/21 >>> OriginAS: ? ? ? AS32421 >>> NetName: ? ? ? ?NET-208-64-120-0-1 >>> NetHandle: ? ? ?NET-208-64-120-0-1 >>> Parent: ? ? ? ? NET-208-0-0-0-0 >>> NetType: ? ? ? ?Direct Allocation >>> NameServer: ? ? NS1.ENTERPRISE.BLACKLOTUS.NET >>> NameServer: ? ? NS2.ENTERPRISE.BLACKLOTUS.NET >>> RegDate: ? ? ? ?2005-12-22 >>> Updated: ? ? ? ?2009-11-11 >>> Ref: ? ? ? ? ? ?http://whois.arin.net/rest/net/NET-208-64-120-0-1 >>> >>> OrgName: ? ? ? ?Black Lotus Communications >>> OrgId: ? ? ? ? ?BLC-92 >>> Address: ? ? ? ?3419 Virginia Beach Blvd. #D5 >>> >>> Thats not your IP space? Really? How come. >>> >>> apothekeosterreich .at -> 208.64.120.197 >>> vertrouwdeapotheek .nl -> 208.64.120.197 >>> >>> viagra-shopping .com -> 208.64.127.78 >>> medicin-24 .com -> 208.64.127.78 >>> >>> apothekeohnerezept .at -> 208.64.127.66 >>> >>> www.medicin-24 .com -> 208.64.127.78 >>> www.viagra-shopping .com -> 208.64.127.78 >>> >>> This is just like 3 minutes digging in todays spamfolders. >>> >>> Instead of typing here, i would be rather nervous and placing null routes >>> wherever i could. >>> >>> Bye, >>> Raymond. >>> >>> >>> >> >> >> >> -- >> Jeffrey Lyon, Leadership Team >> jeffrey.lyon at blacklotus.net | http://www.blacklotus.net >> Black Lotus Communications - AS32421 >> First and Leading in DDoS Protection Solutions >> > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From jeffrey.lyon at blacklotus.net Mon Jan 17 18:33:42 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 17 Jan 2011 19:33:42 -0500 Subject: Request Spamhaus contact In-Reply-To: References: <4D34B364.6060105@trelane.net> Message-ID: Raymond, We've acted on every report that we're aware of and instead you want to play pharmacy domain scavenger hunt. This domain at 208.64.120.197 redirects to IP space we already null routed. It's the same customer. Just to calm your nerves we'll also null route that space (208.64.120.176/28) Thanks, Jeff P.S. Someone at Spamhaus PLEASE remove the /21 listing? On Mon, Jan 17, 2011 at 7:25 PM, Raymond Dijkxhoorn wrote: > Hi! > >> Spam does not make me nervous, it's a practical matter that we will >> address in due course. The null routes we have set are pretty recent >> so you may have received some spam prior to that time but I absolutely >> guarantee you that it did not come from our network, otherwise we >> would have detected it and stopped it on the spot. > >>> Thats not your IP space? Really? How come. >>> >>> apothekeosterreich .at -> 208.64.120.197 >>> vertrouwdeapotheek .nl -> 208.64.120.197 >>> >>> viagra-shopping .com -> 208.64.127.78 >>> medicin-24 .com -> 208.64.127.78 >>> >>> apothekeohnerezept .at -> 208.64.127.66 >>> >>> www.medicin-24 .com -> 208.64.127.78 >>> www.viagra-shopping .com -> 208.64.127.78 >>> >>> This is just like 3 minutes digging in todays spamfolders. > > www.apothekeosterreich .at is still up at the mentioned ip. Instead of > telling you are soooo good on terminating stuff. Can you walk over the list > and act? > > I have sended in many requests for termination. You or your network dont > respond to this at all. > > Its a waste of time even telling it seems. > > I will stop posting here, spam-l is a much better place for this. But please > dont act like you dont know anything whats going on. You have been warned. > You have gotten many many reports. But we dont see stuff changing. > > Good luck with your listing at SpamHaus. > > Bye, > Raymond. > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From raymond at prolocation.net Mon Jan 17 18:35:01 2011 From: raymond at prolocation.net (Raymond Dijkxhoorn) Date: Tue, 18 Jan 2011 01:35:01 +0100 (CET) Subject: {Spam?} Re: Request Spamhaus contact In-Reply-To: References: <4D34B364.6060105@trelane.net> <9DB2D57D-832F-4D3F-9B93-18F1947EDC0F@oitc.com> Message-ID: Hi! > Actually, that was just a brain lapse. The domain didn't resolve at > all (misspelled?) and it returned the Cox default resolution. Instead of looking at typo's or misspelled stuff, can you null route the rest of the abuse reports that came in? Or should we get it added on the SBL listing since it seems thats the only way to get your attention. >>>> apothekeosterreich .at -> 208.64.120.197 >>>> vertrouwdeapotheek .nl -> 208.64.120.197 >>>> >>>> viagra-shopping .com -> 208.64.127.78 >>>> medicin-24 .com -> 208.64.127.78 >>>> >>>> apothekeohnerezept .at -> 208.64.127.66 >>>> >>>> www.medicin-24 .com -> 208.64.127.78 >>>> www.viagra-shopping .com -> 208.64.127.78 >>>> >>>> This is just like 3 minutes digging in todays spamfolders. >>>> >>>> Instead of typing here, i would be rather nervous and placing null routes >>>> wherever i could. Bye, Raymond. From jeffrey.lyon at blacklotus.net Mon Jan 17 18:38:55 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 17 Jan 2011 19:38:55 -0500 Subject: {Spam?} Re: Request Spamhaus contact In-Reply-To: References: <4D34B364.6060105@trelane.net> <9DB2D57D-832F-4D3F-9B93-18F1947EDC0F@oitc.com> Message-ID: Raymond, All of this IP space is null routed. The customer has been served with notice to vacate. What more are you asking for? Best regards, Jeff On Mon, Jan 17, 2011 at 7:35 PM, Raymond Dijkxhoorn wrote: > Hi! > >> Actually, that was just a brain lapse. The domain didn't resolve at >> all (misspelled?) and it returned the Cox default resolution. > > Instead of looking at typo's or misspelled stuff, can you null route the > rest of the abuse reports that came in? Or should we get it added on the SBL > listing since it seems thats the only way to get your attention. > >>>>> apothekeosterreich .at -> 208.64.120.197 >>>>> vertrouwdeapotheek .nl -> 208.64.120.197 >>>>> >>>>> viagra-shopping .com -> 208.64.127.78 >>>>> medicin-24 .com -> 208.64.127.78 >>>>> >>>>> apothekeohnerezept .at -> 208.64.127.66 >>>>> >>>>> www.medicin-24 .com -> 208.64.127.78 >>>>> www.viagra-shopping .com -> 208.64.127.78 >>>>> >>>>> This is just like 3 minutes digging in todays spamfolders. >>>>> >>>>> Instead of typing here, i would be rather nervous and placing null >>>>> routes >>>>> wherever i could. > > Bye, > Raymond. > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From nenolod at systeminplace.net Mon Jan 17 18:38:54 2011 From: nenolod at systeminplace.net (William Pitcock) Date: Mon, 17 Jan 2011 18:38:54 -0600 Subject: Request Spamhaus contact In-Reply-To: References: <4D34B687.1090003@steadfast.net> <20110117173159.3fdcd46c@petrie.gateway.2wire.net> <20110117174942.217933fa@petrie.gateway.2wire.net> <20110117180716.73086697@petrie.gateway.2wire.net> <20110117181721.7004a185@petrie.gateway.2wire.net> Message-ID: <20110117183854.6e14a19b@petrie.gateway.2wire.net> Hi, On Mon, 17 Jan 2011 19:21:19 -0500 Jeffrey Lyon wrote: > William, > > It depends, we have criteria. You can't just e-mail > abuse at blacklotus.net and expect any given web site to be immediately > shut down. There is due process and we need to make a decision on the > matter and serve it to our customer. If a customer is listed at > Spamhaus this is sufficient. In other words, your abuse policy is strictly designed to avoid RBL listings and nothing else. > > Being a legitimate corporation means that we're accountable for > maintaining certain standards. Everyone assumes that because we > mitigate DDoS that we're no better than some offshore spam haven. No, we think that you're no better than some offshore spam haven because you're hosting spammers with an abuse policy strictly designed to avoid "getting listed in spamhaus" with nothing going above and beyond that. Most abuse contacts I e-mail will shut down a customer after looking at Netflow data. But you're not doing that. So you get classified as such. It is really simple. William From raymond at prolocation.net Mon Jan 17 18:39:08 2011 From: raymond at prolocation.net (Raymond Dijkxhoorn) Date: Tue, 18 Jan 2011 01:39:08 +0100 (CET) Subject: Request Spamhaus contact In-Reply-To: References: <4D34B364.6060105@trelane.net> Message-ID: Hi! > We've acted on every report that we're aware of and instead you want > to play pharmacy domain scavenger hunt. This domain at 208.64.120.197 > redirects to IP space we already null routed. It's the same customer. Either you place strange nullroutes or you did not at all. [root at mi10 tmp]# wget -S www.vertrouwdeapotheek.nl --01:37:29-- http://www.vertrouwdeapotheek.nl/ => `index.html' Resolving www.vertrouwdeapotheek.nl... done. Connecting to www.vertrouwdeapotheek.nl[208.64.120.197]:80... connected. HTTP request sent, awaiting response... 1 HTTP/1.1 301 Moved Permanently 2 Cache-Control: private 3 Content-Length: 0 4 Location: http://www.vertrouwdeapotheek.nl/Home.aspx 5 Server: Microsoft-IIS/7.0 6 X-AspNet-Version: 4.0.30319 7 X-Powered-By: ASP.NET 8 Date: Tue, 18 Jan 2011 00:37:04 GMT 9 Connection: close Location: http://www.vertrouwdeapotheek.nl/Home.aspx [following] --01:37:29-- http://www.vertrouwdeapotheek.nl/Home.aspx => `Home.aspx' Connecting to www.vertrouwdeapotheek.nl[208.64.120.197]:80... connected. HTTP request sent, awaiting response... Does this look as its nullrouted? > P.S. Someone at Spamhaus PLEASE remove the /21 listing? I highly doubt. There is much more to clean on your network before i hope they would even reconsider. Bye, Raymond. From jeffrey.lyon at blacklotus.net Mon Jan 17 18:42:22 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 17 Jan 2011 19:42:22 -0500 Subject: Request Spamhaus contact In-Reply-To: References: <4D34B364.6060105@trelane.net> Message-ID: I fat fingered the netmask, try now. Thanks, Jeff On Mon, Jan 17, 2011 at 7:39 PM, Raymond Dijkxhoorn wrote: > Hi! > >> We've acted on every report that we're aware of and instead you want >> to play pharmacy domain scavenger hunt. This domain at 208.64.120.197 >> redirects to IP space we already null routed. It's the same customer. > > Either you place strange nullroutes or you did not at all. > > [root at mi10 tmp]# wget -S www.vertrouwdeapotheek.nl > --01:37:29-- ?http://www.vertrouwdeapotheek.nl/ > ? ? ? ? ? => `index.html' > Resolving www.vertrouwdeapotheek.nl... done. > Connecting to www.vertrouwdeapotheek.nl[208.64.120.197]:80... connected. > HTTP request sent, awaiting response... > ?1 HTTP/1.1 301 Moved Permanently > ?2 Cache-Control: private > ?3 Content-Length: 0 > ?4 Location: http://www.vertrouwdeapotheek.nl/Home.aspx > ?5 Server: Microsoft-IIS/7.0 > ?6 X-AspNet-Version: 4.0.30319 > ?7 X-Powered-By: ASP.NET > ?8 Date: Tue, 18 Jan 2011 00:37:04 GMT > ?9 Connection: close > Location: http://www.vertrouwdeapotheek.nl/Home.aspx [following] > --01:37:29-- ?http://www.vertrouwdeapotheek.nl/Home.aspx > ? ? ? ? ? => `Home.aspx' > Connecting to www.vertrouwdeapotheek.nl[208.64.120.197]:80... connected. > HTTP request sent, awaiting response... > > Does this look as its nullrouted? > >> P.S. Someone at Spamhaus PLEASE remove the /21 listing? > > I highly doubt. There is much more to clean on your network before i hope > they would even reconsider. > > Bye, > Raymond. > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From tshaw at oitc.com Mon Jan 17 18:42:29 2011 From: tshaw at oitc.com (TR Shaw) Date: Mon, 17 Jan 2011 19:42:29 -0500 Subject: {Spam?} Re: Request Spamhaus contact In-Reply-To: References: <4D34B364.6060105@trelane.net> <9DB2D57D-832F-4D3F-9B93-18F1947EDC0F@oitc.com> Message-ID: <877959C4-774F-467F-8437-D9375CEBE1D1@oitc.com> Hmmm. Null routed? Lets see.... http://www.apothekeosterreich.at/Home.aspx http://www.viagra-shopping.com/Home.aspx Do I really need to show you more? Tom On Jan 17, 2011, at 7:38 PM, Jeffrey Lyon wrote: > Raymond, > > All of this IP space is null routed. The customer has been served with > notice to vacate. What more are you asking for? > > Best regards, Jeff > > > On Mon, Jan 17, 2011 at 7:35 PM, Raymond Dijkxhoorn > wrote: >> Hi! >> >>> Actually, that was just a brain lapse. The domain didn't resolve at >>> all (misspelled?) and it returned the Cox default resolution. >> >> Instead of looking at typo's or misspelled stuff, can you null route the >> rest of the abuse reports that came in? Or should we get it added on the SBL >> listing since it seems thats the only way to get your attention. >> >>>>>> apothekeosterreich .at -> 208.64.120.197 >>>>>> vertrouwdeapotheek .nl -> 208.64.120.197 >>>>>> >>>>>> viagra-shopping .com -> 208.64.127.78 >>>>>> medicin-24 .com -> 208.64.127.78 >>>>>> >>>>>> apothekeohnerezept .at -> 208.64.127.66 >>>>>> >>>>>> www.medicin-24 .com -> 208.64.127.78 >>>>>> www.viagra-shopping .com -> 208.64.127.78 >>>>>> >>>>>> This is just like 3 minutes digging in todays spamfolders. >>>>>> >>>>>> Instead of typing here, i would be rather nervous and placing null >>>>>> routes >>>>>> wherever i could. >> >> Bye, >> Raymond. >> > > > > -- > Jeffrey Lyon, Leadership Team > jeffrey.lyon at blacklotus.net | http://www.blacklotus.net > Black Lotus Communications - AS32421 > First and Leading in DDoS Protection Solutions From jeffrey.lyon at blacklotus.net Mon Jan 17 18:43:46 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 17 Jan 2011 19:43:46 -0500 Subject: Request Spamhaus contact In-Reply-To: <20110117182640.69bb1531@petrie.gateway.2wire.net> References: <4D34B364.6060105@trelane.net> <20110117182640.69bb1531@petrie.gateway.2wire.net> Message-ID: William, I had no idea what "Yandex" was until Spamhaus brought it to my attention. I still don't really know, taking them at their word at this point. Jeff On Mon, Jan 17, 2011 at 7:26 PM, William Pitcock wrote: > Hi, > > On Mon, 17 Jan 2011 19:13:16 -0500 > Jeffrey Lyon wrote: > >> Bill, >> >> I'm getting 72.215.225.9 for that host. > > The nameservers just changed to ns2/ns4.codiz.net. > > ns2 is a bogon, the real deal is ns4 hosted at corbina.ru, which has an > abuse@ that goes to /dev/null so whatever. > > Man. ?Hosting Yandex. ?Really? ?How did you manage to not catch that? > > William > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From raymond at prolocation.net Mon Jan 17 18:45:01 2011 From: raymond at prolocation.net (Raymond Dijkxhoorn) Date: Tue, 18 Jan 2011 01:45:01 +0100 (CET) Subject: Request Spamhaus contact In-Reply-To: References: <4D34B364.6060105@trelane.net> Message-ID: Hi! > I fat fingered the netmask, try now. >> HTTP request sent, awaiting response... >> ?1 HTTP/1.1 301 Moved Permanently >> ?2 Cache-Control: private >> ?3 Content-Length: 0 >> ?4 Location: http://www.vertrouwdeapotheek.nl/Home.aspx >> ?5 Server: Microsoft-IIS/7.0 >> ?6 X-AspNet-Version: 4.0.30319 >> ?7 X-Powered-By: ASP.NET >> ?8 Date: Tue, 18 Jan 2011 00:37:04 GMT >> ?9 Connection: close >> Location: http://www.vertrouwdeapotheek.nl/Home.aspx [following] >> --01:37:29-- ?http://www.vertrouwdeapotheek.nl/Home.aspx >> ? ? ? ? ? => `Home.aspx' >> Connecting to www.vertrouwdeapotheek.nl[208.64.120.197]:80... connected. >> HTTP request sent, awaiting response... >> >> Does this look as its nullrouted? >> >>> P.S. Someone at Spamhaus PLEASE remove the /21 listing? >> >> I highly doubt. There is much more to clean on your network before i hope >> they would even reconsider. Resolving www.vertrouwdeapotheek.nl... done. Connecting to www.vertrouwdeapotheek.nl[208.64.120.197]:80... connected. HTTP request sent, awaiting response... 1 HTTP/1.1 301 Moved Permanently 2 Cache-Control: private 3 Content-Length: 0 4 Location: http://www.vertrouwdeapotheek.nl/Home.aspx 5 Server: Microsoft-IIS/7.0 6 X-AspNet-Version: 4.0.30319 7 X-Powered-By: ASP.NET 8 Date: Tue, 18 Jan 2011 00:43:18 GMT 9 Connection: close Location: http://www.vertrouwdeapotheek.nl/Home.aspx [following] --01:43:43-- http://www.vertrouwdeapotheek.nl/Home.aspx => `Home.aspx.1' Connecting to www.vertrouwdeapotheek.nl[208.64.120.197]:80... connected. HTTP request sent, awaiting response... 1 HTTP/1.1 200 OK 2 Cache-Control: private 3 Content-Length: 126007 4 Content-Type: text/html; charset=utf-8 5 Server: Microsoft-IIS/7.0 6 X-AspNet-Version: 4.0.30319 7 WL-Version: 2475.0 8 Set-Cookie: ASP.NET_SessionId=4o3uhvfkqw3uanvriystoe2d; path=/; HttpOnly 9 X-Powered-By: ASP.NET 10 Date: Tue, 18 Jan 2011 00:43:19 GMT 11 Connection: close Still there. All the best Jeffrey ... you are playing games with the wrong people. Bye, Raymond. From jeffrey.lyon at blacklotus.net Mon Jan 17 18:46:55 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 17 Jan 2011 19:46:55 -0500 Subject: Request Spamhaus contact In-Reply-To: References: <4D34B364.6060105@trelane.net> Message-ID: Raymond, I do not take you for a fool, the assignment is legitimately null routed. My traceroutes are dropping at my home ISP. Jeff On Mon, Jan 17, 2011 at 7:45 PM, Raymond Dijkxhoorn wrote: > Hi! > >> I fat fingered the netmask, try now. > >>> HTTP request sent, awaiting response... >>> ?1 HTTP/1.1 301 Moved Permanently >>> ?2 Cache-Control: private >>> ?3 Content-Length: 0 >>> ?4 Location: http://www.vertrouwdeapotheek.nl/Home.aspx >>> ?5 Server: Microsoft-IIS/7.0 >>> ?6 X-AspNet-Version: 4.0.30319 >>> ?7 X-Powered-By: ASP.NET >>> ?8 Date: Tue, 18 Jan 2011 00:37:04 GMT >>> ?9 Connection: close >>> Location: http://www.vertrouwdeapotheek.nl/Home.aspx [following] >>> --01:37:29-- ?http://www.vertrouwdeapotheek.nl/Home.aspx >>> ? ? ? ? ? => `Home.aspx' >>> Connecting to www.vertrouwdeapotheek.nl[208.64.120.197]:80... connected. >>> HTTP request sent, awaiting response... >>> >>> Does this look as its nullrouted? >>> >>>> P.S. Someone at Spamhaus PLEASE remove the /21 listing? >>> >>> I highly doubt. There is much more to clean on your network before i hope >>> they would even reconsider. > > Resolving www.vertrouwdeapotheek.nl... done. > Connecting to www.vertrouwdeapotheek.nl[208.64.120.197]:80... connected. > HTTP request sent, awaiting response... > ?1 HTTP/1.1 301 Moved Permanently > ?2 Cache-Control: private > ?3 Content-Length: 0 > ?4 Location: http://www.vertrouwdeapotheek.nl/Home.aspx > ?5 Server: Microsoft-IIS/7.0 > ?6 X-AspNet-Version: 4.0.30319 > ?7 X-Powered-By: ASP.NET > ?8 Date: Tue, 18 Jan 2011 00:43:18 GMT > ?9 Connection: close > Location: http://www.vertrouwdeapotheek.nl/Home.aspx [following] > --01:43:43-- ?http://www.vertrouwdeapotheek.nl/Home.aspx > ? ? ? ? ? => `Home.aspx.1' > Connecting to www.vertrouwdeapotheek.nl[208.64.120.197]:80... connected. > HTTP request sent, awaiting response... > ?1 HTTP/1.1 200 OK > ?2 Cache-Control: private > ?3 Content-Length: 126007 > ?4 Content-Type: text/html; charset=utf-8 > ?5 Server: Microsoft-IIS/7.0 > ?6 X-AspNet-Version: 4.0.30319 > ?7 WL-Version: 2475.0 > ?8 Set-Cookie: ASP.NET_SessionId=4o3uhvfkqw3uanvriystoe2d; path=/; HttpOnly > ?9 X-Powered-By: ASP.NET > 10 Date: Tue, 18 Jan 2011 00:43:19 GMT > 11 Connection: close > > Still there. > > All the best Jeffrey ... you are playing games with the wrong people. > > Bye, > Raymond. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From trelane at trelane.net Mon Jan 17 18:51:23 2011 From: trelane at trelane.net (Andrew Kirch) Date: Mon, 17 Jan 2011 19:51:23 -0500 Subject: Request Spamhaus contact In-Reply-To: References: <4D34B687.1090003@steadfast.net> <20110117173159.3fdcd46c@petrie.gateway.2wire.net> <20110117174942.217933fa@petrie.gateway.2wire.net> <20110117180716.73086697@petrie.gateway.2wire.net> <20110117181721.7004a185@petrie.gateway.2wire.net> Message-ID: <4D34E40B.1030809@trelane.net> I've got no experience running a DNSBL, nor does William, but it seems to me that I'm not getting told the truth. Now, as I said, I don't always agree with Spamhaus' policies, but I'd bet a ham sandwich that you don't get delisted any time soon. Andrew > William, > > It depends, we have criteria. You can't just e-mail > abuse at blacklotus.net and expect any given web site to be immediately > shut down. There is due process and we need to make a decision on the > matter and serve it to our customer. If a customer is listed at > Spamhaus this is sufficient. > > Being a legitimate corporation means that we're accountable for > maintaining certain standards. Everyone assumes that because we > mitigate DDoS that we're no better than some offshore spam haven. > > Jeff > > BTW: IP space is still null routed, still waiting on Spamhaus to stop > nailing innocent customers. > > From tshaw at oitc.com Mon Jan 17 18:57:03 2011 From: tshaw at oitc.com (TR Shaw) Date: Mon, 17 Jan 2011 19:57:03 -0500 Subject: Request Spamhaus contact In-Reply-To: References: <4D34B364.6060105@trelane.net> Message-ID: <0E75D743-0CF0-43A8-9316-5DA7191E1709@oitc.com> Actually, it does not: $ host apothekeosterreich.at apothekeosterreich.at has address 208.64.120.197 apothekeosterreich.at mail is handled by 10 mail.apothekeosterreich.at. $ curl -I -L apothekeosterreich.at HTTP/1.1 301 Moved Permanently Cache-Control: private Content-Length: 0 Location: http://www.apothekeosterreich.at/Home.aspx Server: Microsoft-IIS/7.0 X-AspNet-Version: 4.0.30319 X-Powered-By: ASP.NET Date: Tue, 18 Jan 2011 00:54:59 GMT Connection: close HTTP/1.1 200 OK Cache-Control: private Content-Length: 126574 Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.0 X-AspNet-Version: 4.0.30319 WL-Version: 2475.0 Set-Cookie: ASP.NET_SessionId=a3brplvgwfsdk3pd1g1zgdtj; path=/; HttpOnly X-Powered-By: ASP.NET Date: Tue, 18 Jan 2011 00:55:00 GMT Connection: close On Jan 17, 2011, at 7:33 PM, Jeffrey Lyon wrote: > Raymond, > > We've acted on every report that we're aware of and instead you want > to play pharmacy domain scavenger hunt. This domain at 208.64.120.197 > redirects to IP space we already null routed. It's the same customer. > > Just to calm your nerves we'll also null route that space (208.64.120.176/28) > > Thanks, Jeff > > P.S. Someone at Spamhaus PLEASE remove the /21 listing? > > > > On Mon, Jan 17, 2011 at 7:25 PM, Raymond Dijkxhoorn > wrote: >> Hi! >> >>> Spam does not make me nervous, it's a practical matter that we will >>> address in due course. The null routes we have set are pretty recent >>> so you may have received some spam prior to that time but I absolutely >>> guarantee you that it did not come from our network, otherwise we >>> would have detected it and stopped it on the spot. >> >>>> Thats not your IP space? Really? How come. >>>> >>>> apothekeosterreich .at -> 208.64.120.197 >>>> vertrouwdeapotheek .nl -> 208.64.120.197 >>>> >>>> viagra-shopping .com -> 208.64.127.78 >>>> medicin-24 .com -> 208.64.127.78 >>>> >>>> apothekeohnerezept .at -> 208.64.127.66 >>>> >>>> www.medicin-24 .com -> 208.64.127.78 >>>> www.viagra-shopping .com -> 208.64.127.78 >>>> >>>> This is just like 3 minutes digging in todays spamfolders. >> >> www.apothekeosterreich .at is still up at the mentioned ip. Instead of >> telling you are soooo good on terminating stuff. Can you walk over the list >> and act? >> >> I have sended in many requests for termination. You or your network dont >> respond to this at all. >> >> Its a waste of time even telling it seems. >> >> I will stop posting here, spam-l is a much better place for this. But please >> dont act like you dont know anything whats going on. You have been warned. >> You have gotten many many reports. But we dont see stuff changing. >> >> Good luck with your listing at SpamHaus. >> >> Bye, >> Raymond. >> > > > > -- > Jeffrey Lyon, Leadership Team > jeffrey.lyon at blacklotus.net | http://www.blacklotus.net > Black Lotus Communications - AS32421 > First and Leading in DDoS Protection Solutions > From jeffrey.lyon at blacklotus.net Mon Jan 17 18:58:01 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 17 Jan 2011 19:58:01 -0500 Subject: Request Spamhaus contact In-Reply-To: <0E75D743-0CF0-43A8-9316-5DA7191E1709@oitc.com> References: <4D34B364.6060105@trelane.net> <0E75D743-0CF0-43A8-9316-5DA7191E1709@oitc.com> Message-ID: TR, Again, it's been null routed. Customer has been served with notice. Unless you guys can help find some more related IP space I think the issue has been solved. Thanks, Jeff On Mon, Jan 17, 2011 at 7:57 PM, TR Shaw wrote: > Actually, it does not: > > $ host apothekeosterreich.at > apothekeosterreich.at has address 208.64.120.197 > apothekeosterreich.at mail is handled by 10 mail.apothekeosterreich.at. > $ curl -I -L apothekeosterreich.at > HTTP/1.1 301 Moved Permanently > Cache-Control: private > Content-Length: 0 > Location: http://www.apothekeosterreich.at/Home.aspx > Server: Microsoft-IIS/7.0 > X-AspNet-Version: 4.0.30319 > X-Powered-By: ASP.NET > Date: Tue, 18 Jan 2011 00:54:59 GMT > Connection: close > > HTTP/1.1 200 OK > Cache-Control: private > Content-Length: 126574 > Content-Type: text/html; charset=utf-8 > Server: Microsoft-IIS/7.0 > X-AspNet-Version: 4.0.30319 > WL-Version: 2475.0 > Set-Cookie: ASP.NET_SessionId=a3brplvgwfsdk3pd1g1zgdtj; path=/; HttpOnly > X-Powered-By: ASP.NET > Date: Tue, 18 Jan 2011 00:55:00 GMT > Connection: close > > On Jan 17, 2011, at 7:33 PM, Jeffrey Lyon wrote: > >> Raymond, >> >> We've acted on every report that we're aware of and instead you want >> to play pharmacy domain scavenger hunt. This domain at 208.64.120.197 >> redirects to IP space we already null routed. It's the same customer. >> >> Just to calm your nerves we'll also null route that space (208.64.120.176/28) >> >> Thanks, Jeff >> >> P.S. Someone at Spamhaus PLEASE remove the /21 listing? >> >> >> >> On Mon, Jan 17, 2011 at 7:25 PM, Raymond Dijkxhoorn >> wrote: >>> Hi! >>> >>>> Spam does not make me nervous, it's a practical matter that we will >>>> address in due course. The null routes we have set are pretty recent >>>> so you may have received some spam prior to that time but I absolutely >>>> guarantee you that it did not come from our network, otherwise we >>>> would have detected it and stopped it on the spot. >>> >>>>> Thats not your IP space? Really? How come. >>>>> >>>>> apothekeosterreich .at -> 208.64.120.197 >>>>> vertrouwdeapotheek .nl -> 208.64.120.197 >>>>> >>>>> viagra-shopping .com -> 208.64.127.78 >>>>> medicin-24 .com -> 208.64.127.78 >>>>> >>>>> apothekeohnerezept .at -> 208.64.127.66 >>>>> >>>>> www.medicin-24 .com -> 208.64.127.78 >>>>> www.viagra-shopping .com -> 208.64.127.78 >>>>> >>>>> This is just like 3 minutes digging in todays spamfolders. >>> >>> www.apothekeosterreich .at is still up at the mentioned ip. Instead of >>> telling you are soooo good on terminating stuff. Can you walk over the list >>> and act? >>> >>> I have sended in many requests for termination. You or your network dont >>> respond to this at all. >>> >>> Its a waste of time even telling it seems. >>> >>> I will stop posting here, spam-l is a much better place for this. But please >>> dont act like you dont know anything whats going on. You have been warned. >>> You have gotten many many reports. But we dont see stuff changing. >>> >>> Good luck with your listing at SpamHaus. >>> >>> Bye, >>> Raymond. >>> >> >> >> >> -- >> Jeffrey Lyon, Leadership Team >> jeffrey.lyon at blacklotus.net | http://www.blacklotus.net >> Black Lotus Communications - AS32421 >> First and Leading in DDoS Protection Solutions >> > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From nick at foobar.org Mon Jan 17 19:04:30 2011 From: nick at foobar.org (Nick Hilliard) Date: Tue, 18 Jan 2011 01:04:30 +0000 Subject: {Spam?} Re: Request Spamhaus contact In-Reply-To: References: <4D34B364.6060105@trelane.net> <9DB2D57D-832F-4D3F-9B93-18F1947EDC0F@oitc.com> Message-ID: <4D34E71E.4060706@foobar.org> On 18/01/2011 00:38, Jeffrey Lyon wrote: > All of this IP space is null routed. The customer has been served with > notice to vacate. What more are you asking for? Summarising other people positions: a functional abuse desk, a less defensive attitude when people point out serious abuse going on in your network, and the slightest inclination to investigate really serious crap on your network when it's brought to your attention in the clearest terms possible. E&OE Nick -- p.s. less megaphone diplomacy would help, if you can clean enough egg off your face to manage this. From jeroen at mompl.net Mon Jan 17 19:05:11 2011 From: jeroen at mompl.net (Jeroen van Aart) Date: Mon, 17 Jan 2011 17:05:11 -0800 Subject: Request Spamhaus contact In-Reply-To: References: <4D34B687.1090003@steadfast.net> <20110117173159.3fdcd46c@petrie.gateway.2wire.net> Message-ID: <4D34E747.80005@mompl.net> Raymond Dijkxhoorn wrote: >> of the "ddos-protected hosting solutions" companies do. > > viagra-shopping .com > potenzmittel-at .com > medicin-24 .com > apothekeohnerezept .at > # whois 208.64.122.234 > [Querying whois.arin.net] > [Redirected to rwhois.blacklotus.net:4321] > [Querying rwhois.blacklotus.net] > [rwhois.blacklotus.net] > %rwhois V-1.0,V-1.5:00090h:00 support.blacklotus.net (Ubersmith RWhois > Server V-1.8.0) > autharea=208.64.120.0/21 > xautharea=208.64.120.0/21 Thanks for the info, I will add 208.64.120.0/21 to my permanent blocklist (just in case spamhaus removes them at some point, or until it's re-assigned to a more well-behaving organisation) and will recommend others to do so too. Regards, Jeroen -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html From raymond at prolocation.net Mon Jan 17 19:05:42 2011 From: raymond at prolocation.net (Raymond Dijkxhoorn) Date: Tue, 18 Jan 2011 02:05:42 +0100 (CET) Subject: Request Spamhaus contact In-Reply-To: References: <4D34B364.6060105@trelane.net> <0E75D743-0CF0-43A8-9316-5DA7191E1709@oitc.com> Message-ID: Hi! > Unless you guys can help find some more related IP space I think the > issue has been solved. You are not able to even shutdown one thats mentioned. You keep telling us its down and null routed. Its simply not. Its alive and kicking. Bullet proof hosting rocks doesnt it? This is now: [root at fallback ~]# wget -S www.vertrouwdeapotheek.nl --2011-01-18 02:02:20-- http://www.vertrouwdeapotheek.nl/ Resolving www.vertrouwdeapotheek.nl... 208.64.120.197 Connecting to www.vertrouwdeapotheek.nl|208.64.120.197|:80... connected. HTTP request sent, awaiting response... HTTP/1.1 301 Moved Permanently Cache-Control: private Content-Length: 0 Location: http://www.vertrouwdeapotheek.nl/Home.aspx Server: Microsoft-IIS/7.0 X-AspNet-Version: 4.0.30319 X-Powered-By: ASP.NET Date: Tue, 18 Jan 2011 01:02:02 GMT Connection: close Location: http://www.vertrouwdeapotheek.nl/Home.aspx [following] --2011-01-18 02:02:21-- http://www.vertrouwdeapotheek.nl/Home.aspx Connecting to www.vertrouwdeapotheek.nl|208.64.120.197|:80... connected. HTTP request sent, awaiting response... HTTP/1.1 200 OK Cache-Control: private Content-Length: 126007 Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.0 X-AspNet-Version: 4.0.30319 WL-Version: 2475.0 Set-Cookie: ASP.NET_SessionId=eknnhn43j4kcqxzqwk24ewjs; path=/; HttpOnly X-Powered-By: ASP.NET Date: Tue, 18 Jan 2011 01:02:03 GMT Connection: close Length: 126007 (123K) [text/html] Saving to: "Home.aspx.2" 100%[===========================================================================================================================================================>] 126,007 162K/s in 0.8s 2011-01-18 02:02:22 (162 KB/s) - "Home.aspx.2" saved [126007/126007] [root at fallback ~]# more Home.aspx.2 Vertrouwde Apotheek - Viagra ... You either have a funny way of nullrouting stuff. OR someone just stole your netspace and put the same content online ;) Bye, Raymond. From trelane at trelane.net Mon Jan 17 19:06:24 2011 From: trelane at trelane.net (Andrew Kirch) Date: Mon, 17 Jan 2011 20:06:24 -0500 Subject: Request Spamhaus contact In-Reply-To: <AANLkTin0x=Pu7m5J2EL0pOWimEWht3h46rgTBS5Bj0OQ@mail.gmail.com> References: <AANLkTimG4vpRagh3P8Cke=v_vUuPC4e3XMA9jKny8188@mail.gmail.com> <4D34B364.6060105@trelane.net> <AANLkTiks93QZeuw5k3xvz4-krBtGcdfEvUOXrc1Hx0=1@mail.gmail.com> <AANLkTikm6xcaKA=+tYzrX-Q5EL-qCbvR0CJmEEKfR4KD@mail.gmail.com> <AANLkTinHKhkkOtHpy6=nUPv4onz3-Boh7o0oXBg5G+fM@mail.gmail.com> <alpine.LFD.2.00.1101180105170.26930@noc.prolocation.net> <AANLkTikRv=Hvr+5_N-axq6OH-spbvybtyPBu9x1s+zY6@mail.gmail.com> <alpine.LFD.2.00.1101180120230.19534@noc.prolocation.net> <AANLkTin0x=Pu7m5J2EL0pOWimEWht3h46rgTBS5Bj0OQ@mail.gmail.com> Message-ID: <4D34E790.1090704@trelane.net> > Raymond, > > We've acted on every report that we're aware of and instead you want > to play pharmacy domain scavenger hunt. This domain at 208.64.120.197 > redirects to IP space we already null routed. It's the same customer. > > Just to calm your nerves we'll also null route that space (208.64.120.176/28) > > Thanks, Jeff > > P.S. Someone at Spamhaus PLEASE remove the /21 listing? > I agree with Jeff here, the listing should be removed. Would the admins @ PCCW and TeliaSonera please be so kind as to delist this person... via BGP? Short of me making another reference to firearms on this list and getting banned, I have no other way to prove that blacklotus.net is essentially bulletproof hosting. Andrew From owenc at hubris.net Mon Jan 17 19:07:19 2011 From: owenc at hubris.net (Chris Owen) Date: Mon, 17 Jan 2011 19:07:19 -0600 Subject: Request Spamhaus contact In-Reply-To: <AANLkTinhN9e7OqJ1i0LwsaeqQDJoLOf3PTHtDMb5=fMJ@mail.gmail.com> References: <AANLkTimG4vpRagh3P8Cke=v_vUuPC4e3XMA9jKny8188@mail.gmail.com> <4D34B364.6060105@trelane.net> <AANLkTiks93QZeuw5k3xvz4-krBtGcdfEvUOXrc1Hx0=1@mail.gmail.com> <AANLkTikm6xcaKA=+tYzrX-Q5EL-qCbvR0CJmEEKfR4KD@mail.gmail.com> <AANLkTinHKhkkOtHpy6=nUPv4onz3-Boh7o0oXBg5G+fM@mail.gmail.com> <alpine.LFD.2.00.1101180105170.26930@noc.prolocation.net> <AANLkTikRv=Hvr+5_N-axq6OH-spbvybtyPBu9x1s+zY6@mail.gmail.com> <alpine.LFD.2.00.1101180120230.19534@noc.prolocation.net> <AANLkTin0x=Pu7m5J2EL0pOWimEWht3h46rgTBS5Bj0OQ@mail.gmail.com> <alpine.LFD.2.00.1101180137010.27337@noc.prolocation.net> <AANLkTinhN9e7OqJ1i0LwsaeqQDJoLOf3PTHtDMb5=fMJ@mail.gmail.com> Message-ID: <8938753C-2B8D-496E-B5C7-9FE09A18C339@hubris.net> On Jan 17, 2011, at 6:42 PM, Jeffrey Lyon wrote: > I fat fingered the netmask, try now. I've asked privately but would it really be too much to take this off NANOG? Spammer complaining he is on a RBL is hardly relevant. Chris -- ------------------------------------------------------------------------- Chris Owen - Garden City (620) 275-1900 - Lottery (noun): President - Wichita (316) 858-3000 - A stupidity tax Hubris Communications Inc www.hubris.net ------------------------------------------------------------------------- From gem at rellim.com Mon Jan 17 19:08:50 2011 From: gem at rellim.com (Gary E. Miller) Date: Mon, 17 Jan 2011 17:08:50 -0800 (PST) Subject: Request Spamhaus contact In-Reply-To: <AANLkTinhN9e7OqJ1i0LwsaeqQDJoLOf3PTHtDMb5=fMJ@mail.gmail.com> References: <AANLkTimG4vpRagh3P8Cke=v_vUuPC4e3XMA9jKny8188@mail.gmail.com> <4D34B364.6060105@trelane.net> <AANLkTiks93QZeuw5k3xvz4-krBtGcdfEvUOXrc1Hx0=1@mail.gmail.com> <AANLkTikm6xcaKA=+tYzrX-Q5EL-qCbvR0CJmEEKfR4KD@mail.gmail.com> <AANLkTinHKhkkOtHpy6=nUPv4onz3-Boh7o0oXBg5G+fM@mail.gmail.com> <alpine.LFD.2.00.1101180105170.26930@noc.prolocation.net> <AANLkTikRv=Hvr+5_N-axq6OH-spbvybtyPBu9x1s+zY6@mail.gmail.com> <alpine.LFD.2.00.1101180120230.19534@noc.prolocation.net> <AANLkTin0x=Pu7m5J2EL0pOWimEWht3h46rgTBS5Bj0OQ@mail.gmail.com> <alpine.LFD.2.00.1101180137010.27337@noc.prolocation.net> <AANLkTinhN9e7OqJ1i0LwsaeqQDJoLOf3PTHtDMb5=fMJ@mail.gmail.com> Message-ID: <alpine.LNX.1.00.1101171708130.16375@catbert.rellim.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yo Jeffrey! On Mon, 17 Jan 2011, Jeffrey Lyon wrote: > I fat fingered the netmask, try now. Still up: # nmap -sS 208.64.120.197 Starting Nmap 5.21 ( http://nmap.org ) at 2011-01-17 17:07 PST Nmap scan report for 208.64.120.197 Host is up (0.033s latency). Not shown: 989 filtered ports PORT STATE SERVICE 21/tcp open ftp 80/tcp open http 135/tcp open msrpc 443/tcp open https 1723/tcp open pptp 1801/tcp open unknown 2103/tcp open zephyr-clt 2105/tcp open eklogin 2107/tcp open unknown 49154/tcp open unknown 49157/tcp open unknown Nmap done: 1 IP address (1 host up) scanned in 4.77 seconds RGDS GARY - --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701 gem at rellim.com Tel:+1(541)382-8588 > > Thanks, Jeff > > > On Mon, Jan 17, 2011 at 7:39 PM, Raymond Dijkxhoorn > <raymond at prolocation.net> wrote: > > Hi! > > > >> We've acted on every report that we're aware of and instead you want > >> to play pharmacy domain scavenger hunt. This domain at 208.64.120.197 > >> redirects to IP space we already null routed. It's the same customer. > > > > Either you place strange nullroutes or you did not at all. > > > > [root at mi10 tmp]# wget -S www.vertrouwdeapotheek.nl > > --01:37:29-- ?http://www.vertrouwdeapotheek.nl/ > > ? ? ? ? ? => `index.html' > > Resolving www.vertrouwdeapotheek.nl... done. > > Connecting to www.vertrouwdeapotheek.nl[208.64.120.197]:80... connected. > > HTTP request sent, awaiting response... > > ?1 HTTP/1.1 301 Moved Permanently > > ?2 Cache-Control: private > > ?3 Content-Length: 0 > > ?4 Location: http://www.vertrouwdeapotheek.nl/Home.aspx > > ?5 Server: Microsoft-IIS/7.0 > > ?6 X-AspNet-Version: 4.0.30319 > > ?7 X-Powered-By: ASP.NET > > ?8 Date: Tue, 18 Jan 2011 00:37:04 GMT > > ?9 Connection: close > > Location: http://www.vertrouwdeapotheek.nl/Home.aspx [following] > > --01:37:29-- ?http://www.vertrouwdeapotheek.nl/Home.aspx > > ? ? ? ? ? => `Home.aspx' > > Connecting to www.vertrouwdeapotheek.nl[208.64.120.197]:80... connected. > > HTTP request sent, awaiting response... > > > > Does this look as its nullrouted? > > > >> P.S. Someone at Spamhaus PLEASE remove the /21 listing? > > > > I highly doubt. There is much more to clean on your network before i hope > > they would even reconsider. > > > > Bye, > > Raymond. > > > > > > -- > Jeffrey Lyon, Leadership Team > jeffrey.lyon at blacklotus.net | http://www.blacklotus.net > Black Lotus Communications - AS32421 > First and Leading in DDoS Protection Solutions > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFNNOgkBmnRqz71OvMRAlvyAJ9iB4xleue08ZFvUXhDc+/vmga4KwCeKsEQ 556DfEqv3CINUxO2GyxmBJ0= =8XnB -----END PGP SIGNATURE----- From nenolod at systeminplace.net Mon Jan 17 19:09:23 2011 From: nenolod at systeminplace.net (William Pitcock) Date: Mon, 17 Jan 2011 19:09:23 -0600 Subject: Request Spamhaus contact In-Reply-To: <AANLkTinhN9e7OqJ1i0LwsaeqQDJoLOf3PTHtDMb5=fMJ@mail.gmail.com> References: <AANLkTimG4vpRagh3P8Cke=v_vUuPC4e3XMA9jKny8188@mail.gmail.com> <4D34B364.6060105@trelane.net> <AANLkTiks93QZeuw5k3xvz4-krBtGcdfEvUOXrc1Hx0=1@mail.gmail.com> <AANLkTikm6xcaKA=+tYzrX-Q5EL-qCbvR0CJmEEKfR4KD@mail.gmail.com> <AANLkTinHKhkkOtHpy6=nUPv4onz3-Boh7o0oXBg5G+fM@mail.gmail.com> <alpine.LFD.2.00.1101180105170.26930@noc.prolocation.net> <AANLkTikRv=Hvr+5_N-axq6OH-spbvybtyPBu9x1s+zY6@mail.gmail.com> <alpine.LFD.2.00.1101180120230.19534@noc.prolocation.net> <AANLkTin0x=Pu7m5J2EL0pOWimEWht3h46rgTBS5Bj0OQ@mail.gmail.com> <alpine.LFD.2.00.1101180137010.27337@noc.prolocation.net> <AANLkTinhN9e7OqJ1i0LwsaeqQDJoLOf3PTHtDMb5=fMJ@mail.gmail.com> Message-ID: <20110117190923.03c3af5c@petrie.gateway.2wire.net> On Mon, 17 Jan 2011 19:42:22 -0500 Jeffrey Lyon <jeffrey.lyon at blacklotus.net> wrote: > I fat fingered the netmask, try now. $ wget -S www.vertrouwdeapotheek.nl --2011-01-17 19:07:59-- http://www.vertrouwdeapotheek.nl/ Resolving www.vertrouwdeapotheek.nl... 208.64.120.197 Connecting to www.vertrouwdeapotheek.nl|208.64.120.197|:80... connected. HTTP request sent, awaiting response... HTTP/1.1 301 Moved Permanently Cache-Control: private Content-Length: 0 Location: http://www.vertrouwdeapotheek.nl/Home.aspx Server: Microsoft-IIS/7.0 X-AspNet-Version: 4.0.30319 X-Powered-By: ASP.NET Date: Tue, 18 Jan 2011 01:07:46 GMT Connection: close Location: http://www.vertrouwdeapotheek.nl/Home.aspx [following] --2011-01-17 19:08:00-- http://www.vertrouwdeapotheek.nl/Home.aspx Connecting to www.vertrouwdeapotheek.nl|208.64.120.197|:80... connected. HTTP request sent, awaiting response... HTTP/1.1 200 OK Cache-Control: private Content-Length: 126007 Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.0 X-AspNet-Version: 4.0.30319 WL-Version: 2475.0 Set-Cookie: ASP.NET_SessionId=bcs4bluvt3dqdfqd1udupey3; path=/; HttpOnly X-Powered-By: ASP.NET Date: Tue, 18 Jan 2011 01:07:47 GMT Connection: close Length: 126007 (123K) [text/html] Saving to: `Home.aspx' 100%[======================================================================================================================================================================>] 126,007 364K/s in 0.3s 2011-01-17 19:08:01 (364 KB/s) - `Home.aspx' saved [126007/126007] How hard is it really to type in "ip route 208.64.120.197 255.255.255.255 Null0" on your busted up 6509? Don't forget to "conf t"! William > > Thanks, Jeff > > > On Mon, Jan 17, 2011 at 7:39 PM, Raymond Dijkxhoorn > <raymond at prolocation.net> wrote: > > Hi! > > > >> We've acted on every report that we're aware of and instead you > >> want to play pharmacy domain scavenger hunt. This domain at > >> 208.64.120.197 redirects to IP space we already null routed. It's > >> the same customer. > > > > Either you place strange nullroutes or you did not at all. > > > > [root at mi10 tmp]# wget -S www.vertrouwdeapotheek.nl > > --01:37:29-- ?http://www.vertrouwdeapotheek.nl/ > > ? ? ? ? ? => `index.html' > > Resolving www.vertrouwdeapotheek.nl... done. > > Connecting to www.vertrouwdeapotheek.nl[208.64.120.197]:80... > > connected. HTTP request sent, awaiting response... > > ?1 HTTP/1.1 301 Moved Permanently > > ?2 Cache-Control: private > > ?3 Content-Length: 0 > > ?4 Location: http://www.vertrouwdeapotheek.nl/Home.aspx > > ?5 Server: Microsoft-IIS/7.0 > > ?6 X-AspNet-Version: 4.0.30319 > > ?7 X-Powered-By: ASP.NET > > ?8 Date: Tue, 18 Jan 2011 00:37:04 GMT > > ?9 Connection: close > > Location: http://www.vertrouwdeapotheek.nl/Home.aspx [following] > > --01:37:29-- ?http://www.vertrouwdeapotheek.nl/Home.aspx > > ? ? ? ? ? => `Home.aspx' > > Connecting to www.vertrouwdeapotheek.nl[208.64.120.197]:80... > > connected. HTTP request sent, awaiting response... > > > > Does this look as its nullrouted? > > > >> P.S. Someone at Spamhaus PLEASE remove the /21 listing? > > > > I highly doubt. There is much more to clean on your network before > > i hope they would even reconsider. > > > > Bye, > > Raymond. > > > > > From steve at blighty.com Mon Jan 17 19:10:02 2011 From: steve at blighty.com (Steve Atkins) Date: Mon, 17 Jan 2011 17:10:02 -0800 Subject: Request Spamhaus contact In-Reply-To: <AANLkTinhN9e7OqJ1i0LwsaeqQDJoLOf3PTHtDMb5=fMJ@mail.gmail.com> References: <AANLkTimG4vpRagh3P8Cke=v_vUuPC4e3XMA9jKny8188@mail.gmail.com> <4D34B364.6060105@trelane.net> <AANLkTiks93QZeuw5k3xvz4-krBtGcdfEvUOXrc1Hx0=1@mail.gmail.com> <AANLkTikm6xcaKA=+tYzrX-Q5EL-qCbvR0CJmEEKfR4KD@mail.gmail.com> <AANLkTinHKhkkOtHpy6=nUPv4onz3-Boh7o0oXBg5G+fM@mail.gmail.com> <alpine.LFD.2.00.1101180105170.26930@noc.prolocation.net> <AANLkTikRv=Hvr+5_N-axq6OH-spbvybtyPBu9x1s+zY6@mail.gmail.com> <alpine.LFD.2.00.1101180120230.19534@noc.prolocation.net> <AANLkTin0x=Pu7m5J2EL0pOWimEWht3h46rgTBS5Bj0OQ@mail.gmail.com> <alpine.LFD.2.00.1101180137010.27337@noc.prolocation.net> <AANLkTinhN9e7OqJ1i0LwsaeqQDJoLOf3PTHtDMb5=fMJ@mail.gmail.com> Message-ID: <7EB79F7E-67A7-4D0B-9DE1-86DF484D45A0@blighty.com> On Jan 17, 2011, at 4:42 PM, Jeffrey Lyon wrote: > I fat fingered the netmask, try now. Mmm hmm. platter steve$ telnet 208.64.127.78 80 Trying 208.64.127.78... Connected to 208.64.127.78. Escape character is '^]'. HEAD / HTTP/1.1 Host: viagra-shopping.com HTTP/1.1 301 Moved Permanently Cache-Control: private Content-Length: 0 Location: http://www.viagra-shopping.com/Home.aspx Server: Microsoft-IIS/7.0 X-AspNet-Version: 4.0.30319 X-Powered-By: ASP.NET Date: Tue, 18 Jan 2011 00:57:55 GMT Connection: close If you've given spamhaus the same sort of response you're showing here I'm not surprised they're not prioritizing dealing with you. Cheers, Steve > > Thanks, Jeff > > > On Mon, Jan 17, 2011 at 7:39 PM, Raymond Dijkxhoorn > <raymond at prolocation.net> wrote: >> Hi! >> >>> We've acted on every report that we're aware of and instead you want >>> to play pharmacy domain scavenger hunt. This domain at 208.64.120.197 >>> redirects to IP space we already null routed. It's the same customer. >> >> Either you place strange nullroutes or you did not at all. >> >> [root at mi10 tmp]# wget -S www.vertrouwdeapotheek.nl >> --01:37:29-- http://www.vertrouwdeapotheek.nl/ >> => `index.html' >> Resolving www.vertrouwdeapotheek.nl... done. >> Connecting to www.vertrouwdeapotheek.nl[208.64.120.197]:80... connected. >> HTTP request sent, awaiting response... >> 1 HTTP/1.1 301 Moved Permanently >> 2 Cache-Control: private >> 3 Content-Length: 0 >> 4 Location: http://www.vertrouwdeapotheek.nl/Home.aspx >> 5 Server: Microsoft-IIS/7.0 >> 6 X-AspNet-Version: 4.0.30319 >> 7 X-Powered-By: ASP.NET >> 8 Date: Tue, 18 Jan 2011 00:37:04 GMT >> 9 Connection: close >> Location: http://www.vertrouwdeapotheek.nl/Home.aspx [following] >> --01:37:29-- http://www.vertrouwdeapotheek.nl/Home.aspx >> => `Home.aspx' >> Connecting to www.vertrouwdeapotheek.nl[208.64.120.197]:80... connected. >> HTTP request sent, awaiting response... >> >> Does this look as its nullrouted? >> >>> P.S. Someone at Spamhaus PLEASE remove the /21 listing? >> >> I highly doubt. There is much more to clean on your network before i hope >> they would even reconsider. >> >> Bye, >> Raymond. >> > > > > -- > Jeffrey Lyon, Leadership Team > jeffrey.lyon at blacklotus.net | http://www.blacklotus.net > Black Lotus Communications - AS32421 > First and Leading in DDoS Protection Solutions > From jeffrey.lyon at blacklotus.net Mon Jan 17 19:10:20 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 17 Jan 2011 20:10:20 -0500 Subject: Request Spamhaus contact In-Reply-To: <alpine.LFD.2.00.1101180202510.22908@noc.prolocation.net> References: <AANLkTimG4vpRagh3P8Cke=v_vUuPC4e3XMA9jKny8188@mail.gmail.com> <4D34B364.6060105@trelane.net> <AANLkTiks93QZeuw5k3xvz4-krBtGcdfEvUOXrc1Hx0=1@mail.gmail.com> <AANLkTikm6xcaKA=+tYzrX-Q5EL-qCbvR0CJmEEKfR4KD@mail.gmail.com> <AANLkTinHKhkkOtHpy6=nUPv4onz3-Boh7o0oXBg5G+fM@mail.gmail.com> <alpine.LFD.2.00.1101180105170.26930@noc.prolocation.net> <AANLkTikRv=Hvr+5_N-axq6OH-spbvybtyPBu9x1s+zY6@mail.gmail.com> <alpine.LFD.2.00.1101180120230.19534@noc.prolocation.net> <AANLkTin0x=Pu7m5J2EL0pOWimEWht3h46rgTBS5Bj0OQ@mail.gmail.com> <0E75D743-0CF0-43A8-9316-5DA7191E1709@oitc.com> <AANLkTi==xwrZefBcqannLgDx1BdTiHmmOCa1qXOoMEFQ@mail.gmail.com> <alpine.LFD.2.00.1101180202510.22908@noc.prolocation.net> Message-ID: <AANLkTinrtL=A7-YMtDoi4z-a-6zqnp1xnX91wSF=Kpvg@mail.gmail.com> Raymond, Negative, it is null routed: http://lg.level3.net Show Level 3 (San Diego, CA) Traceroute to 208.64.120.197 1 ae-5-5.ebr1.LosAngeles1.Level3.net (4.69.133.206) 4 msec 4 msec 12 msec 2 ae-4-90.edge1.LosAngeles9.Level3.net (4.69.144.202) 4 msec 4 msec ae-3-80.edge1.LosAngeles9.Level3.net (4.69.144.138) 4 msec 3 * * * 4 * * * Jeff On Mon, Jan 17, 2011 at 8:05 PM, Raymond Dijkxhoorn <raymond at prolocation.net> wrote: > Hi! > >> Unless you guys can help find some more related IP space I think the >> issue has been solved. > > You are not able to even shutdown one thats mentioned. You keep telling us > its down and null routed. Its simply not. Its alive and kicking. Bullet > proof hosting rocks doesnt it? > > This is now: > > [root at fallback ~]# wget -S www.vertrouwdeapotheek.nl > --2011-01-18 02:02:20-- ?http://www.vertrouwdeapotheek.nl/ > Resolving www.vertrouwdeapotheek.nl... 208.64.120.197 > Connecting to www.vertrouwdeapotheek.nl|208.64.120.197|:80... connected. > HTTP request sent, awaiting response... > ?HTTP/1.1 301 Moved Permanently > ?Cache-Control: private > ?Content-Length: 0 > ?Location: http://www.vertrouwdeapotheek.nl/Home.aspx > ?Server: Microsoft-IIS/7.0 > ?X-AspNet-Version: 4.0.30319 > ?X-Powered-By: ASP.NET > ?Date: Tue, 18 Jan 2011 01:02:02 GMT > ?Connection: close > Location: http://www.vertrouwdeapotheek.nl/Home.aspx [following] > --2011-01-18 02:02:21-- ?http://www.vertrouwdeapotheek.nl/Home.aspx > Connecting to www.vertrouwdeapotheek.nl|208.64.120.197|:80... connected. > HTTP request sent, awaiting response... > ?HTTP/1.1 200 OK > ?Cache-Control: private > ?Content-Length: 126007 > ?Content-Type: text/html; charset=utf-8 > ?Server: Microsoft-IIS/7.0 > ?X-AspNet-Version: 4.0.30319 > ?WL-Version: 2475.0 > ?Set-Cookie: ASP.NET_SessionId=eknnhn43j4kcqxzqwk24ewjs; path=/; HttpOnly > ?X-Powered-By: ASP.NET > ?Date: Tue, 18 Jan 2011 01:02:03 GMT > ?Connection: close > Length: 126007 (123K) [text/html] > Saving to: "Home.aspx.2" > > 100%[===========================================================================================================================================================>] > 126,007 ? ? ?162K/s ? in 0.8s > > 2011-01-18 02:02:22 (162 KB/s) - "Home.aspx.2" saved [126007/126007] > > [root at fallback ~]# more Home.aspx.2 > > <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> > <html xmlns="http://www.w3.org/1999/xhtml"> > <head> > ? ?<title>Vertrouwde Apotheek - Viagra ... > > You either have a funny way of nullrouting stuff. OR someone just stole your > netspace and put the same content online ;) > > Bye, > Raymond. > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From bill at herrin.us Mon Jan 17 19:18:29 2011 From: bill at herrin.us (William Herrin) Date: Mon, 17 Jan 2011 20:18:29 -0500 Subject: Request Spamhaus contact In-Reply-To: <AANLkTinhN9e7OqJ1i0LwsaeqQDJoLOf3PTHtDMb5=fMJ@mail.gmail.com> References: <AANLkTimG4vpRagh3P8Cke=v_vUuPC4e3XMA9jKny8188@mail.gmail.com> <4D34B364.6060105@trelane.net> <AANLkTiks93QZeuw5k3xvz4-krBtGcdfEvUOXrc1Hx0=1@mail.gmail.com> <AANLkTikm6xcaKA=+tYzrX-Q5EL-qCbvR0CJmEEKfR4KD@mail.gmail.com> <AANLkTinHKhkkOtHpy6=nUPv4onz3-Boh7o0oXBg5G+fM@mail.gmail.com> <alpine.LFD.2.00.1101180105170.26930@noc.prolocation.net> <AANLkTikRv=Hvr+5_N-axq6OH-spbvybtyPBu9x1s+zY6@mail.gmail.com> <alpine.LFD.2.00.1101180120230.19534@noc.prolocation.net> <AANLkTin0x=Pu7m5J2EL0pOWimEWht3h46rgTBS5Bj0OQ@mail.gmail.com> <alpine.LFD.2.00.1101180137010.27337@noc.prolocation.net> <AANLkTinhN9e7OqJ1i0LwsaeqQDJoLOf3PTHtDMb5=fMJ@mail.gmail.com> Message-ID: <AANLkTikLDPbR1M22c2jq_RWnon1wZN9SGDo=3tdV-j=3@mail.gmail.com> On Mon, Jan 17, 2011 at 7:42 PM, Jeffrey Lyon <jeffrey.lyon at blacklotus.net> wrote: > I fat fingered the netmask, try now. Jeff, You have some work left to do. Much of it is exhibited in the Spamhaus listing. wget -nd http://eros-pharmacy.com/ --2011-01-17 19:54:44-- http://eros-pharmacy.com/ Resolving eros-pharmacy.com... 208.64.120.206 Connecting to eros-pharmacy.com|208.64.120.206|:80... connected. HTTP request sent, awaiting response... 301 Moved Permanently Location: http://www.eros-pharmacy.com/Home.aspx [following] --2011-01-17 19:54:45-- http://www.eros-pharmacy.com/Home.aspx Resolving www.eros-pharmacy.com... 208.64.120.206 Connecting to www.eros-pharmacy.com|208.64.120.206|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 128759 (126K) [text/html] Saving to: `index.html' 100%[======================================>] 128,759 328K/s in 0.4s 2011-01-17 19:54:46 (328 KB/s) - `index.html' saved [128759/128759] lynx --dump index.html [...] Join eros-pharmacy.com's top affiliate program. We offer our affiliates more than ever, 3rd tier payouts, high comissions and much more. Want to join us and start earning top $$$ ? Contact us today. More Info [...] http://whois.arin.net/rest/nets;q=208.64.120.206?showDetails=true&showARIN=false CIDR 208.64.120.0/21 Organization Black Lotus Communications (BLC-92) On Mon, Jan 17, 2011 at 7:33 PM, Jeffrey Lyon <jeffrey.lyon at blacklotus.net> wrote: > We've acted on every report that we're aware of and instead you want > to play pharmacy domain scavenger hunt. In the situation in which you find yourself, passive reaction to precise reports is not good enough. You've been careless and you're paying the price. If getting on top of the situation means you have to play pharmacy domain scavenger hunt then that's what you need to spend the next 24 hours doing. Not criticizing Spamhaus or debating on NANOG. Respectfully, Bill Herrin P.S. I don't mean to add to your woes, but top-posting on a mailing list is generally considered faux pas. It makes it difficult to follow a conversation. Notice how the rest of us place our replies directly below the text we're replying to? -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004 From nathan at robotics.net Mon Jan 17 19:22:05 2011 From: nathan at robotics.net (Nathan Stratton) Date: Mon, 17 Jan 2011 19:22:05 -0600 (CST) Subject: Request Spamhaus contact In-Reply-To: <AANLkTimUaF-5jfsgMT7DegcCeo9=wnpTnE7ipmC1UkPW@mail.gmail.com> References: <AANLkTimG4vpRagh3P8Cke=v_vUuPC4e3XMA9jKny8188@mail.gmail.com> <4D34B687.1090003@steadfast.net> <AANLkTi=2nniFnV3P3mMJ8j1eb3VUzXTrcY7H5gST54Wy@mail.gmail.com> <20110117173159.3fdcd46c@petrie.gateway.2wire.net> <AANLkTinE40=QKp5fBiMveEu9VxSvkoUMRTHFpz8ODxfw@mail.gmail.com> <20110117174942.217933fa@petrie.gateway.2wire.net> <AANLkTims+F_bm6YcY9-ruKAjevRKUCzoh5aWrkCS-Ywh@mail.gmail.com> <20110117180716.73086697@petrie.gateway.2wire.net> <AANLkTinB5w1DbLv=wAoMcoY=Z23qipd6WKdoxbJOvunw@mail.gmail.com> <20110117181721.7004a185@petrie.gateway.2wire.net> <AANLkTimUaF-5jfsgMT7DegcCeo9=wnpTnE7ipmC1UkPW@mail.gmail.com> Message-ID: <alpine.LFD.2.00.1101171921100.25174@bart.robotics.net> On Mon, 17 Jan 2011, Jeffrey Lyon wrote: > Being a legitimate corporation means that we're accountable for > maintaining certain standards. Everyone assumes that because we > mitigate DDoS that we're no better than some offshore spam haven. Will you please stop using "legitimate corporation" for what you guys are doing? ><> Nathan Stratton CTO, BlinkMind, Inc. nathan at robotics.net nathan at blinkmind.com http://www.robotics.net http://www.blinkmind.com From nenolod at systeminplace.net Mon Jan 17 19:21:54 2011 From: nenolod at systeminplace.net (William Pitcock) Date: Mon, 17 Jan 2011 19:21:54 -0600 Subject: Request Spamhaus contact In-Reply-To: <AANLkTinb=7NYDdht1iciQJLsCsM7GYULvjHvYBL7+P7r@mail.gmail.com> References: <AANLkTimG4vpRagh3P8Cke=v_vUuPC4e3XMA9jKny8188@mail.gmail.com> <4D34B364.6060105@trelane.net> <AANLkTiks93QZeuw5k3xvz4-krBtGcdfEvUOXrc1Hx0=1@mail.gmail.com> <AANLkTikm6xcaKA=+tYzrX-Q5EL-qCbvR0CJmEEKfR4KD@mail.gmail.com> <AANLkTinHKhkkOtHpy6=nUPv4onz3-Boh7o0oXBg5G+fM@mail.gmail.com> <alpine.LFD.2.00.1101180105170.26930@noc.prolocation.net> <AANLkTikRv=Hvr+5_N-axq6OH-spbvybtyPBu9x1s+zY6@mail.gmail.com> <alpine.LFD.2.00.1101180120230.19534@noc.prolocation.net> <AANLkTin0x=Pu7m5J2EL0pOWimEWht3h46rgTBS5Bj0OQ@mail.gmail.com> <alpine.LFD.2.00.1101180137010.27337@noc.prolocation.net> <AANLkTinhN9e7OqJ1i0LwsaeqQDJoLOf3PTHtDMb5=fMJ@mail.gmail.com> <alpine.LFD.2.00.1101180143560.27337@noc.prolocation.net> <AANLkTinb=7NYDdht1iciQJLsCsM7GYULvjHvYBL7+P7r@mail.gmail.com> Message-ID: <20110117192154.5a41689a@petrie.gateway.2wire.net> Hi, On Mon, 17 Jan 2011 19:46:55 -0500 Jeffrey Lyon <jeffrey.lyon at blacklotus.net> wrote: > Raymond, > > I do not take you for a fool, the assignment is legitimately null > routed. My traceroutes are dropping at my home ISP. I call bollocks. It's alive and kicking via BGP here. edge1.lax01# show ip bgp 208.64.120.197/32 BGP routing table entry for 208.64.120.0/24, version 2014041464 Paths: (6 available, best #3, table default) [...] And I can reach it from my house. William From jeffrey.lyon at blacklotus.net Mon Jan 17 19:22:33 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 17 Jan 2011 20:22:33 -0500 Subject: Request Spamhaus contact In-Reply-To: <AANLkTikLDPbR1M22c2jq_RWnon1wZN9SGDo=3tdV-j=3@mail.gmail.com> References: <AANLkTimG4vpRagh3P8Cke=v_vUuPC4e3XMA9jKny8188@mail.gmail.com> <4D34B364.6060105@trelane.net> <AANLkTiks93QZeuw5k3xvz4-krBtGcdfEvUOXrc1Hx0=1@mail.gmail.com> <AANLkTikm6xcaKA=+tYzrX-Q5EL-qCbvR0CJmEEKfR4KD@mail.gmail.com> <AANLkTinHKhkkOtHpy6=nUPv4onz3-Boh7o0oXBg5G+fM@mail.gmail.com> <alpine.LFD.2.00.1101180105170.26930@noc.prolocation.net> <AANLkTikRv=Hvr+5_N-axq6OH-spbvybtyPBu9x1s+zY6@mail.gmail.com> <alpine.LFD.2.00.1101180120230.19534@noc.prolocation.net> <AANLkTin0x=Pu7m5J2EL0pOWimEWht3h46rgTBS5Bj0OQ@mail.gmail.com> <alpine.LFD.2.00.1101180137010.27337@noc.prolocation.net> <AANLkTinhN9e7OqJ1i0LwsaeqQDJoLOf3PTHtDMb5=fMJ@mail.gmail.com> <AANLkTikLDPbR1M22c2jq_RWnon1wZN9SGDo=3tdV-j=3@mail.gmail.com> Message-ID: <AANLkTikbhduTxwLEEMa_NM87-Z-iE_Qp_49HQfJq+U+r@mail.gmail.com> On Mon, Jan 17, 2011 at 8:18 PM, William Herrin <bill at herrin.us> wrote: > On Mon, Jan 17, 2011 at 7:42 PM, Jeffrey Lyon > <jeffrey.lyon at blacklotus.net> wrote: >> I fat fingered the netmask, try now. > > Jeff, > > You have some work left to do. Much of it is exhibited in the Spamhaus listing. > > wget -nd http://eros-pharmacy.com/ > --2011-01-17 19:54:44-- ?http://eros-pharmacy.com/ > Resolving eros-pharmacy.com... 208.64.120.206 > Connecting to eros-pharmacy.com|208.64.120.206|:80... connected. > HTTP request sent, awaiting response... 301 Moved Permanently > Location: http://www.eros-pharmacy.com/Home.aspx [following] > --2011-01-17 19:54:45-- ?http://www.eros-pharmacy.com/Home.aspx > Resolving www.eros-pharmacy.com... 208.64.120.206 > Connecting to www.eros-pharmacy.com|208.64.120.206|:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: 128759 (126K) [text/html] > Saving to: `index.html' > > 100%[======================================>] 128,759 ? ? ?328K/s ? in 0.4s > > 2011-01-17 19:54:46 (328 KB/s) - `index.html' saved [128759/128759] > > lynx --dump index.html > [...] > ? Join eros-pharmacy.com's top affiliate program. We offer our affiliates > ? more than ever, 3rd tier payouts, high comissions and much more. Want > ? to join us and start earning top $$$ ? Contact us today. > ? More Info > [...] > > > http://whois.arin.net/rest/nets;q=208.64.120.206?showDetails=true&showARIN=false > > CIDR ? ?208.64.120.0/21 > Organization ? ?Black Lotus Communications (BLC-92) > > > > > On Mon, Jan 17, 2011 at 7:33 PM, Jeffrey Lyon > <jeffrey.lyon at blacklotus.net> wrote: >> We've acted on every report that we're aware of and instead you want >> to play pharmacy domain scavenger hunt. > > In the situation in which you find yourself, passive reaction to > precise reports is not good enough. You've been careless and you're > paying the price. If getting on top of the situation means you have to > play pharmacy domain scavenger hunt then that's what you need to spend > the next 24 hours doing. Not criticizing Spamhaus or debating on > NANOG. > > Respectfully, > Bill Herrin > > > P.S. I don't mean to add to your woes, but top-posting on a mailing > list is generally considered faux pas. It makes it difficult to follow > a conversation. Notice how the rest of us place our replies directly > below the text we're replying to? > > > -- > William D. Herrin ................ herrin at dirtside.com? bill at herrin.us > 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> > Falls Church, VA 22042-3004 > Bill, Is it NANOG/Spamhaus' job to punish us or perhaps its better to simply be satisfied that we're listening to what is being said? Andrew, If they're not going to delist us we will lose all of our legitimate customers, at which point the only ones we would have left are the ones you expect me to remove. How does that make any sense? -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From jeffrey.lyon at blacklotus.net Mon Jan 17 19:23:17 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 17 Jan 2011 20:23:17 -0500 Subject: Request Spamhaus contact In-Reply-To: <20110117192154.5a41689a@petrie.gateway.2wire.net> References: <AANLkTimG4vpRagh3P8Cke=v_vUuPC4e3XMA9jKny8188@mail.gmail.com> <4D34B364.6060105@trelane.net> <AANLkTiks93QZeuw5k3xvz4-krBtGcdfEvUOXrc1Hx0=1@mail.gmail.com> <AANLkTikm6xcaKA=+tYzrX-Q5EL-qCbvR0CJmEEKfR4KD@mail.gmail.com> <AANLkTinHKhkkOtHpy6=nUPv4onz3-Boh7o0oXBg5G+fM@mail.gmail.com> <alpine.LFD.2.00.1101180105170.26930@noc.prolocation.net> <AANLkTikRv=Hvr+5_N-axq6OH-spbvybtyPBu9x1s+zY6@mail.gmail.com> <alpine.LFD.2.00.1101180120230.19534@noc.prolocation.net> <AANLkTin0x=Pu7m5J2EL0pOWimEWht3h46rgTBS5Bj0OQ@mail.gmail.com> <alpine.LFD.2.00.1101180137010.27337@noc.prolocation.net> <AANLkTinhN9e7OqJ1i0LwsaeqQDJoLOf3PTHtDMb5=fMJ@mail.gmail.com> <alpine.LFD.2.00.1101180143560.27337@noc.prolocation.net> <AANLkTinb=7NYDdht1iciQJLsCsM7GYULvjHvYBL7+P7r@mail.gmail.com> <20110117192154.5a41689a@petrie.gateway.2wire.net> Message-ID: <AANLkTinxkU9hzw-PaSX4GCcnXefGo0c--HDRhk9RU8Ss@mail.gmail.com> On Mon, Jan 17, 2011 at 8:21 PM, William Pitcock <nenolod at systeminplace.net> wrote: > Hi, > > On Mon, 17 Jan 2011 19:46:55 -0500 > Jeffrey Lyon <jeffrey.lyon at blacklotus.net> wrote: > >> Raymond, >> >> I do not take you for a fool, the assignment is legitimately null >> routed. My traceroutes are dropping at my home ISP. > > I call bollocks. ?It's alive and kicking via BGP here. > > edge1.lax01# show ip bgp 208.64.120.197/32 > BGP routing table entry for 208.64.120.0/24, version 2014041464 > Paths: (6 available, best #3, table default) > [...] > > And I can reach it from my house. > > William > So it's dead on Cox Cable and the L3 Looking Glass but not at your house? How is that possible? -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From mark at streamservice.nl Mon Jan 17 19:23:14 2011 From: mark at streamservice.nl (Mark Scholten) Date: Tue, 18 Jan 2011 02:23:14 +0100 Subject: Request Spamhaus contact In-Reply-To: <AANLkTinhN9e7OqJ1i0LwsaeqQDJoLOf3PTHtDMb5=fMJ@mail.gmail.com> References: <AANLkTimG4vpRagh3P8Cke=v_vUuPC4e3XMA9jKny8188@mail.gmail.com> <4D34B364.6060105@trelane.net> <AANLkTiks93QZeuw5k3xvz4-krBtGcdfEvUOXrc1Hx0=1@mail.gmail.com> <AANLkTikm6xcaKA=+tYzrX-Q5EL-qCbvR0CJmEEKfR4KD@mail.gmail.com> <AANLkTinHKhkkOtHpy6=nUPv4onz3-Boh7o0oXBg5G+fM@mail.gmail.com> <alpine.LFD.2.00.1101180105170.26930@noc.prolocation.net> <AANLkTikRv=Hvr+5_N-axq6OH-spbvybtyPBu9x1s+zY6@mail.gmail.com> <alpine.LFD.2.00.1101180120230.19534@noc.prolocation.net> <AANLkTin0x=Pu7m5J2EL0pOWimEWht3h46rgTBS5Bj0OQ@mail.gmail.com> <alpine.LFD.2.00.1101180137010.27337@noc.prolocation.net> <AANLkTinhN9e7OqJ1i0LwsaeqQDJoLOf3PTHtDMb5=fMJ@mail.gmail.com> Message-ID: <0e3701cbb6ae$4750bf30$d5f23d90$@nl> > From: Jeffrey Lyon [mailto:jeffrey.lyon at blacklotus.net] > Sent: Tuesday, January 18, 2011 1:42 AM > > I fat fingered the netmask, try now. > > Thanks, Jeff I don't think it is yet solved. The listed time is CET (GMT+1). tmp at support:~$ wget -S www.vertrouwdeapotheek.nl --2011-01-18 02:18:15-- http://www.vertrouwdeapotheek.nl/ Resolving www.vertrouwdeapotheek.nl... 208.64.120.197 Connecting to www.vertrouwdeapotheek.nl|208.64.120.197|:80... connected. HTTP request sent, awaiting response... HTTP/1.1 301 Moved Permanently Cache-Control: private Content-Length: 0 Location: http://www.vertrouwdeapotheek.nl/Home.aspx Server: Microsoft-IIS/7.0 X-AspNet-Version: 4.0.30319 X-Powered-By: ASP.NET Date: Tue, 18 Jan 2011 01:17:50 GMT Connection: close Location: http://www.vertrouwdeapotheek.nl/Home.aspx [following] --2011-01-18 02:18:15-- http://www.vertrouwdeapotheek.nl/Home.aspx Connecting to www.vertrouwdeapotheek.nl|208.64.120.197|:80... connected. HTTP request sent, awaiting response... HTTP/1.1 200 OK Cache-Control: private Content-Length: 126007 Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.0 X-AspNet-Version: 4.0.30319 WL-Version: 2475.0 Set-Cookie: ASP.NET_SessionId=olbzhbkanrerwwzqeoho22ws; path=/; HttpOnly X-Powered-By: ASP.NET Date: Tue, 18 Jan 2011 01:17:51 GMT Connection: close Length: 126007 (123K) [text/html] Saving to: `index.html' 100%[======================================================================= ============>] 126,007 154K/s in 0.8s 2011-01-18 02:18:17 (154 KB/s) - `index.html' saved [126007/126007] I did check the content of index.html and it shows a page I expect at that domain. Giving a suspend page is also acceptable for me (or a page with a message that the site was removed). How difficult is it for you to nullroute it? For me (and probably for others) it is also acceptable if you put a firewall between them and the internet with the rule to DROP everything for that IP. I'm even prepared to give an example config (based on Debian 5) to drop the traffic for all IPs mentioned on this list and on SBL. How you do it isn't important for me, but please clean your network for as far as possible with the given information (and looking through your clients). Regards, Mark From jeffrey.lyon at blacklotus.net Mon Jan 17 19:26:16 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 17 Jan 2011 20:26:16 -0500 Subject: Request Spamhaus contact In-Reply-To: <alpine.LFD.2.00.1101180221540.11065@noc.prolocation.net> References: <AANLkTimG4vpRagh3P8Cke=v_vUuPC4e3XMA9jKny8188@mail.gmail.com> <4D34B364.6060105@trelane.net> <AANLkTiks93QZeuw5k3xvz4-krBtGcdfEvUOXrc1Hx0=1@mail.gmail.com> <AANLkTikm6xcaKA=+tYzrX-Q5EL-qCbvR0CJmEEKfR4KD@mail.gmail.com> <AANLkTinHKhkkOtHpy6=nUPv4onz3-Boh7o0oXBg5G+fM@mail.gmail.com> <alpine.LFD.2.00.1101180105170.26930@noc.prolocation.net> <AANLkTikRv=Hvr+5_N-axq6OH-spbvybtyPBu9x1s+zY6@mail.gmail.com> <alpine.LFD.2.00.1101180120230.19534@noc.prolocation.net> <AANLkTin0x=Pu7m5J2EL0pOWimEWht3h46rgTBS5Bj0OQ@mail.gmail.com> <0E75D743-0CF0-43A8-9316-5DA7191E1709@oitc.com> <AANLkTi==xwrZefBcqannLgDx1BdTiHmmOCa1qXOoMEFQ@mail.gmail.com> <alpine.LFD.2.00.1101180202510.22908@noc.prolocation.net> <AANLkTinrtL=A7-YMtDoi4z-a-6zqnp1xnX91wSF=Kpvg@mail.gmail.com> <alpine.LFD.2.00.1101180211530.4889@noc.prolocation.net> <AANLkTinThcbxhySmb_H844t8ixO0xXHZLX=T3i_hoZTG@mail.gmail.com> <alpine.LFD.2.00.1101180221540.11065@noc.prolocation.net> Message-ID: <AANLkTimnTarrgYSL=g_etYRLoZfxC9vRBO1oj4tf+wet@mail.gmail.com> Perhaps PCCW is not accepting the null routes? I'll have the DC power down the pertinent machines. Jeff On Mon, Jan 17, 2011 at 8:24 PM, Raymond Dijkxhoorn <raymond at prolocation.net> wrote: > Hi! > >> How are you seeing this? It is null routed from my home connection, it >> is null routed from the L3 Looking Glass. Please show me evidence that >> something is wrong with my null routes. >> >> Or perhaps this is just funny to you? > > I mailed you evidence, its up, still. Hey, its your network, look on the > boxes there. > > What more evidence you need then the actual pages??????? > > [root at ratsack ~]# wget -S www.vertrouwdeapotheek.nl > --2011-01-18 02:22:34-- ?http://www.vertrouwdeapotheek.nl/ > Resolving www.vertrouwdeapotheek.nl... 208.64.120.197 > Connecting to www.vertrouwdeapotheek.nl|208.64.120.197|:80... connected. > HTTP request sent, awaiting response... > ?HTTP/1.1 301 Moved Permanently > ?Cache-Control: private > ?Content-Length: 0 > ?Location: http://www.vertrouwdeapotheek.nl/Home.aspx > ?Server: Microsoft-IIS/7.0 > ?X-AspNet-Version: 4.0.30319 > ?X-Powered-By: ASP.NET > ?Date: Tue, 18 Jan 2011 01:22:16 GMT > ?Connection: close > Location: http://www.vertrouwdeapotheek.nl/Home.aspx [following] > --2011-01-18 02:22:35-- ?http://www.vertrouwdeapotheek.nl/Home.aspx > Connecting to www.vertrouwdeapotheek.nl|208.64.120.197|:80... connected. > HTTP request sent, awaiting response... > ?HTTP/1.1 200 OK > ?Cache-Control: private > ?Content-Length: 126007 > ?Content-Type: text/html; charset=utf-8 > ?Server: Microsoft-IIS/7.0 > ?X-AspNet-Version: 4.0.30319 > ?WL-Version: 2475.0 > ?Set-Cookie: ASP.NET_SessionId=aqvgayz5c23hmfrvksqk30y1; path=/; HttpOnly > ?X-Powered-By: ASP.NET > ?Date: Tue, 18 Jan 2011 01:22:16 GMT > ?Connection: close > Length: 126007 (123K) [text/html] > Saving to: "Home.aspx.1" > > Thats your network. > > ?4. Te2-2.ar2.AMS1.gblx.net 0.0% ? ? 3 ? ?1.3 ? 1.3 ? 1.3 ? 1.3 ? 0.0 > ?5. 64.213.176.242 0.0% ? ? 3 ? 99.2 ?99.2 ?99.2 ?99.3 ? 0.0 > ?6. irc.ge9-7.br01.lax04.pccwbtn.net 0.0% ? ? 3 ?162.3 162.3 162.3 162.4 > 0.1 > ?7. 208.64.120.17 0.0% ? ? 3 ?155.2 155.1 155.0 155.2 ? 0.1 > > Its up. Period. > > Bye, > Raymond. > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From raymond at prolocation.net Mon Jan 17 19:26:12 2011 From: raymond at prolocation.net (Raymond Dijkxhoorn) Date: Tue, 18 Jan 2011 02:26:12 +0100 (CET) Subject: Request Spamhaus contact In-Reply-To: <AANLkTinxkU9hzw-PaSX4GCcnXefGo0c--HDRhk9RU8Ss@mail.gmail.com> References: <AANLkTimG4vpRagh3P8Cke=v_vUuPC4e3XMA9jKny8188@mail.gmail.com> <4D34B364.6060105@trelane.net> <AANLkTiks93QZeuw5k3xvz4-krBtGcdfEvUOXrc1Hx0=1@mail.gmail.com> <AANLkTikm6xcaKA=+tYzrX-Q5EL-qCbvR0CJmEEKfR4KD@mail.gmail.com> <AANLkTinHKhkkOtHpy6=nUPv4onz3-Boh7o0oXBg5G+fM@mail.gmail.com> <alpine.LFD.2.00.1101180105170.26930@noc.prolocation.net> <AANLkTikRv=Hvr+5_N-axq6OH-spbvybtyPBu9x1s+zY6@mail.gmail.com> <alpine.LFD.2.00.1101180120230.19534@noc.prolocation.net> <AANLkTin0x=Pu7m5J2EL0pOWimEWht3h46rgTBS5Bj0OQ@mail.gmail.com> <alpine.LFD.2.00.1101180137010.27337@noc.prolocation.net> <AANLkTinhN9e7OqJ1i0LwsaeqQDJoLOf3PTHtDMb5=fMJ@mail.gmail.com> <alpine.LFD.2.00.1101180143560.27337@noc.prolocation.net> <AANLkTinb=7NYDdht1iciQJLsCsM7GYULvjHvYBL7+P7r@mail.gmail.com> <20110117192154.5a41689a@petrie.gateway.2wire.net> <AANLkTinxkU9hzw-PaSX4GCcnXefGo0c--HDRhk9RU8Ss@mail.gmail.com> Message-ID: <alpine.LFD.2.00.1101180225130.11065@noc.prolocation.net> Hi! >>> I do not take you for a fool, the assignment is legitimately null >>> routed. My traceroutes are dropping at my home ISP. >> I call bollocks. ?It's alive and kicking via BGP here. >> >> edge1.lax01# show ip bgp 208.64.120.197/32 >> BGP routing table entry for 208.64.120.0/24, version 2014041464 >> Paths: (6 available, best #3, table default) >> [...] >> >> And I can reach it from my house. >> >> William > So it's dead on Cox Cable and the L3 Looking Glass but not at your > house? How is that possible? Its your network isnt it. If you dont know whats happening. ... Mail me your router logins and i'll make sure its peoperly null routed. And some more. Bye, Raymond. From jeffrey.lyon at blacklotus.net Mon Jan 17 19:28:55 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 17 Jan 2011 20:28:55 -0500 Subject: Request Spamhaus contact In-Reply-To: <alpine.LFD.2.00.1101180225130.11065@noc.prolocation.net> References: <AANLkTimG4vpRagh3P8Cke=v_vUuPC4e3XMA9jKny8188@mail.gmail.com> <4D34B364.6060105@trelane.net> <AANLkTiks93QZeuw5k3xvz4-krBtGcdfEvUOXrc1Hx0=1@mail.gmail.com> <AANLkTikm6xcaKA=+tYzrX-Q5EL-qCbvR0CJmEEKfR4KD@mail.gmail.com> <AANLkTinHKhkkOtHpy6=nUPv4onz3-Boh7o0oXBg5G+fM@mail.gmail.com> <alpine.LFD.2.00.1101180105170.26930@noc.prolocation.net> <AANLkTikRv=Hvr+5_N-axq6OH-spbvybtyPBu9x1s+zY6@mail.gmail.com> <alpine.LFD.2.00.1101180120230.19534@noc.prolocation.net> <AANLkTin0x=Pu7m5J2EL0pOWimEWht3h46rgTBS5Bj0OQ@mail.gmail.com> <alpine.LFD.2.00.1101180137010.27337@noc.prolocation.net> <AANLkTinhN9e7OqJ1i0LwsaeqQDJoLOf3PTHtDMb5=fMJ@mail.gmail.com> <alpine.LFD.2.00.1101180143560.27337@noc.prolocation.net> <AANLkTinb=7NYDdht1iciQJLsCsM7GYULvjHvYBL7+P7r@mail.gmail.com> <20110117192154.5a41689a@petrie.gateway.2wire.net> <AANLkTinxkU9hzw-PaSX4GCcnXefGo0c--HDRhk9RU8Ss@mail.gmail.com> <alpine.LFD.2.00.1101180225130.11065@noc.prolocation.net> Message-ID: <AANLkTikOqePOPkv1HLbb3GOisZWm255sEKFifX=mppOd@mail.gmail.com> Rhetorical question. Probably PCCW isn't accepting the null routes. Why not blacklist them for having messed up communities? Jeff On Mon, Jan 17, 2011 at 8:26 PM, Raymond Dijkxhoorn <raymond at prolocation.net> wrote: > Hi! > >>>> I do not take you for a fool, the assignment is legitimately null >>>> routed. My traceroutes are dropping at my home ISP. > >>> I call bollocks. ?It's alive and kicking via BGP here. >>> >>> edge1.lax01# show ip bgp 208.64.120.197/32 >>> BGP routing table entry for 208.64.120.0/24, version 2014041464 >>> Paths: (6 available, best #3, table default) >>> [...] >>> >>> And I can reach it from my house. >>> >>> William > >> So it's dead on Cox Cable and the L3 Looking Glass but not at your >> house? How is that possible? > > Its your network isnt it. If you dont know whats happening. ... > > Mail me your router logins and i'll make sure its peoperly null routed. And > some more. > > Bye, > Raymond. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From trelane at trelane.net Mon Jan 17 19:29:07 2011 From: trelane at trelane.net (Andrew Kirch) Date: Mon, 17 Jan 2011 20:29:07 -0500 Subject: Request Spamhaus contact In-Reply-To: <AANLkTinb=7NYDdht1iciQJLsCsM7GYULvjHvYBL7+P7r@mail.gmail.com> References: <AANLkTimG4vpRagh3P8Cke=v_vUuPC4e3XMA9jKny8188@mail.gmail.com> <4D34B364.6060105@trelane.net> <AANLkTiks93QZeuw5k3xvz4-krBtGcdfEvUOXrc1Hx0=1@mail.gmail.com> <AANLkTikm6xcaKA=+tYzrX-Q5EL-qCbvR0CJmEEKfR4KD@mail.gmail.com> <AANLkTinHKhkkOtHpy6=nUPv4onz3-Boh7o0oXBg5G+fM@mail.gmail.com> <alpine.LFD.2.00.1101180105170.26930@noc.prolocation.net> <AANLkTikRv=Hvr+5_N-axq6OH-spbvybtyPBu9x1s+zY6@mail.gmail.com> <alpine.LFD.2.00.1101180120230.19534@noc.prolocation.net> <AANLkTin0x=Pu7m5J2EL0pOWimEWht3h46rgTBS5Bj0OQ@mail.gmail.com> <alpine.LFD.2.00.1101180137010.27337@noc.prolocation.net> <AANLkTinhN9e7OqJ1i0LwsaeqQDJoLOf3PTHtDMb5=fMJ@mail.gmail.com> <alpine.LFD.2.00.1101180143560.27337@noc.prolocation.net> <AANLkTinb=7NYDdht1iciQJLsCsM7GYULvjHvYBL7+P7r@mail.gmail.com> Message-ID: <4D34ECE3.40408@trelane.net> > Raymond, > > I do not take you for a fool, the assignment is legitimately null > routed. My traceroutes are dropping at my home ISP. > > Jeff Come on Jeff, I googled the listed address for blacklotus.net, and look what comes up: http://www.google.com/search?sourceid=chrome&ie=UTF-8&q=3419+Virginia+Beach+Blvd.+%23D5 <http://www.google.com/search?sourceid=chrome&ie=UTF-8&q=3419+Virginia+Beach+Blvd.+%23D5> Scams, spam, garbage, etc. Guys, it looks like we are dealing with the spammer/scammer himself. The quicker his peering turfs him, the better. Incidentally, this /21 is being announced using MZIMA's AS number... (providing our much needed EFNet Connection) This is very interesting. Couldn't you afford your own? Andrew From nenolod at systeminplace.net Mon Jan 17 19:29:36 2011 From: nenolod at systeminplace.net (William Pitcock) Date: Mon, 17 Jan 2011 19:29:36 -0600 Subject: Request Spamhaus contact In-Reply-To: <AANLkTinxkU9hzw-PaSX4GCcnXefGo0c--HDRhk9RU8Ss@mail.gmail.com> References: <AANLkTimG4vpRagh3P8Cke=v_vUuPC4e3XMA9jKny8188@mail.gmail.com> <4D34B364.6060105@trelane.net> <AANLkTiks93QZeuw5k3xvz4-krBtGcdfEvUOXrc1Hx0=1@mail.gmail.com> <AANLkTikm6xcaKA=+tYzrX-Q5EL-qCbvR0CJmEEKfR4KD@mail.gmail.com> <AANLkTinHKhkkOtHpy6=nUPv4onz3-Boh7o0oXBg5G+fM@mail.gmail.com> <alpine.LFD.2.00.1101180105170.26930@noc.prolocation.net> <AANLkTikRv=Hvr+5_N-axq6OH-spbvybtyPBu9x1s+zY6@mail.gmail.com> <alpine.LFD.2.00.1101180120230.19534@noc.prolocation.net> <AANLkTin0x=Pu7m5J2EL0pOWimEWht3h46rgTBS5Bj0OQ@mail.gmail.com> <alpine.LFD.2.00.1101180137010.27337@noc.prolocation.net> <AANLkTinhN9e7OqJ1i0LwsaeqQDJoLOf3PTHtDMb5=fMJ@mail.gmail.com> <alpine.LFD.2.00.1101180143560.27337@noc.prolocation.net> <AANLkTinb=7NYDdht1iciQJLsCsM7GYULvjHvYBL7+P7r@mail.gmail.com> <20110117192154.5a41689a@petrie.gateway.2wire.net> <AANLkTinxkU9hzw-PaSX4GCcnXefGo0c--HDRhk9RU8Ss@mail.gmail.com> Message-ID: <20110117192936.5820145b@petrie.gateway.2wire.net> On Mon, 17 Jan 2011 20:23:17 -0500 Jeffrey Lyon <jeffrey.lyon at blacklotus.net> wrote: > On Mon, Jan 17, 2011 at 8:21 PM, William Pitcock > <nenolod at systeminplace.net> wrote: > > Hi, > > > > On Mon, 17 Jan 2011 19:46:55 -0500 > > Jeffrey Lyon <jeffrey.lyon at blacklotus.net> wrote: > > > >> Raymond, > >> > >> I do not take you for a fool, the assignment is legitimately null > >> routed. My traceroutes are dropping at my home ISP. > > > > I call bollocks. ?It's alive and kicking via BGP here. > > > > edge1.lax01# show ip bgp 208.64.120.197/32 > > BGP routing table entry for 208.64.120.0/24, version 2014041464 > > Paths: (6 available, best #3, table default) > > [...] > > > > And I can reach it from my house. > > > > William > > > > So it's dead on Cox Cable and the L3 Looking Glass but not at your > house? How is that possible? > Because you haven't nullrouted shit. You're just tagging the IP with a specific BGP community and not all networks will respect your tagging. The ones that don't allow the traffic to pass right on through to your network, and due to BGP convergence that there will always be a working route this way. Again, I ask: how hard is it to type "ip route 208.64.120.197 255.255.255.255 Null0"? For someone who is "first and leading in DDoS Protection Solutions" you sure seem to not be able to effectively nullroute, no offense. William From mark at streamservice.nl Mon Jan 17 19:30:18 2011 From: mark at streamservice.nl (Mark Scholten) Date: Tue, 18 Jan 2011 02:30:18 +0100 Subject: Request Spamhaus contact In-Reply-To: <AANLkTi==xwrZefBcqannLgDx1BdTiHmmOCa1qXOoMEFQ@mail.gmail.com> References: <AANLkTimG4vpRagh3P8Cke=v_vUuPC4e3XMA9jKny8188@mail.gmail.com> <4D34B364.6060105@trelane.net> <AANLkTiks93QZeuw5k3xvz4-krBtGcdfEvUOXrc1Hx0=1@mail.gmail.com> <AANLkTikm6xcaKA=+tYzrX-Q5EL-qCbvR0CJmEEKfR4KD@mail.gmail.com> <AANLkTinHKhkkOtHpy6=nUPv4onz3-Boh7o0oXBg5G+fM@mail.gmail.com> <alpine.LFD.2.00.1101180105170.26930@noc.prolocation.net> <AANLkTikRv=Hvr+5_N-axq6OH-spbvybtyPBu9x1s+zY6@mail.gmail.com> <alpine.LFD.2.00.1101180120230.19534@noc.prolocation.net> <AANLkTin0x=Pu7m5J2EL0pOWimEWht3h46rgTBS5Bj0OQ@mail.gmail.com> <0E75D743-0CF0-43A8-9316-5DA7191E1709@oitc.com> <AANLkTi==xwrZefBcqannLgDx1BdTiHmmOCa1qXOoMEFQ@mail.gmail.com> Message-ID: <0e3d01cbb6af$4404fa20$cc0eee60$@nl> > -----Original Message----- > From: Jeffrey Lyon [mailto:jeffrey.lyon at blacklotus.net] > Sent: Tuesday, January 18, 2011 1:58 AM > To: TR Shaw > Cc: nanog at nanog.org > Subject: Re: Request Spamhaus contact > > TR, > > Again, it's been null routed. Customer has been served with notice. > Unless you guys can help find some more related IP space I think the > issue has been solved. > > Thanks, Jeff Hello Jeffrey, At least a few moments back (after receiving the message above) it was possible to get the page at www . vertrouwdeapotheek . nl at IP 208.64.120.197. Do you really know if it has been solved? Regards, Mark From jeffrey.lyon at blacklotus.net Mon Jan 17 19:31:58 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 17 Jan 2011 20:31:58 -0500 Subject: Request Spamhaus contact In-Reply-To: <0e3d01cbb6af$4404fa20$cc0eee60$@nl> References: <AANLkTimG4vpRagh3P8Cke=v_vUuPC4e3XMA9jKny8188@mail.gmail.com> <4D34B364.6060105@trelane.net> <AANLkTiks93QZeuw5k3xvz4-krBtGcdfEvUOXrc1Hx0=1@mail.gmail.com> <AANLkTikm6xcaKA=+tYzrX-Q5EL-qCbvR0CJmEEKfR4KD@mail.gmail.com> <AANLkTinHKhkkOtHpy6=nUPv4onz3-Boh7o0oXBg5G+fM@mail.gmail.com> <alpine.LFD.2.00.1101180105170.26930@noc.prolocation.net> <AANLkTikRv=Hvr+5_N-axq6OH-spbvybtyPBu9x1s+zY6@mail.gmail.com> <alpine.LFD.2.00.1101180120230.19534@noc.prolocation.net> <AANLkTin0x=Pu7m5J2EL0pOWimEWht3h46rgTBS5Bj0OQ@mail.gmail.com> <0E75D743-0CF0-43A8-9316-5DA7191E1709@oitc.com> <AANLkTi==xwrZefBcqannLgDx1BdTiHmmOCa1qXOoMEFQ@mail.gmail.com> <0e3d01cbb6af$4404fa20$cc0eee60$@nl> Message-ID: <AANLkTi=UVDzicaPeajMy8Rk7eKjCa+kDgOrQ_8TGNSMU@mail.gmail.com> I've already stated that i'm having the server powered down. What else do you people want? Why not focus your energy on the providers who are NOT responding to complaints? Jeff On Mon, Jan 17, 2011 at 8:30 PM, Mark Scholten <mark at streamservice.nl> wrote: > > >> -----Original Message----- >> From: Jeffrey Lyon [mailto:jeffrey.lyon at blacklotus.net] >> Sent: Tuesday, January 18, 2011 1:58 AM >> To: TR Shaw >> Cc: nanog at nanog.org >> Subject: Re: Request Spamhaus contact >> >> TR, >> >> Again, it's been null routed. Customer has been served with notice. >> Unless you guys can help find some more related IP space I think the >> issue has been solved. >> >> Thanks, Jeff > > Hello Jeffrey, > > At least a few moments back (after receiving the message above) it was > possible to get the page at www . vertrouwdeapotheek . nl at IP > 208.64.120.197. > > Do you really know if it has been solved? > > Regards, Mark > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From patrick at zill.net Mon Jan 17 19:32:17 2011 From: patrick at zill.net (Patrick Giagnocavo) Date: Mon, 17 Jan 2011 20:32:17 -0500 Subject: Request Spamhaus contact In-Reply-To: <AANLkTinB5w1DbLv=wAoMcoY=Z23qipd6WKdoxbJOvunw@mail.gmail.com> References: <AANLkTimG4vpRagh3P8Cke=v_vUuPC4e3XMA9jKny8188@mail.gmail.com> <4D34B687.1090003@steadfast.net> <AANLkTi=2nniFnV3P3mMJ8j1eb3VUzXTrcY7H5gST54Wy@mail.gmail.com> <20110117173159.3fdcd46c@petrie.gateway.2wire.net> <AANLkTinE40=QKp5fBiMveEu9VxSvkoUMRTHFpz8ODxfw@mail.gmail.com> <20110117174942.217933fa@petrie.gateway.2wire.net> <AANLkTims+F_bm6YcY9-ruKAjevRKUCzoh5aWrkCS-Ywh@mail.gmail.com> <20110117180716.73086697@petrie.gateway.2wire.net> <AANLkTinB5w1DbLv=wAoMcoY=Z23qipd6WKdoxbJOvunw@mail.gmail.com> Message-ID: <4D34EDA1.7090602@zill.net> On 1/17/2011 7:11 PM, Jeffrey Lyon wrote: > William, > > You're quite right, we don't. We presume that our customers are > honorable until proven otherwise. We're a legitimate U.S. based > corporation and we make ourselves available to the pertinent RBL's and > authorities as appropriate. We take action where action needs to be > taken. I don't have a "dog in this fight" but could I point out, that somehow SpamHaus was able to determine more about what was going on in your network, than you were? Perhaps that should indicate to you (at the least) that you need to invest a little more in your monitoring infrastructure. Cordially Patrick From jeffrey.lyon at blacklotus.net Mon Jan 17 19:32:53 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 17 Jan 2011 20:32:53 -0500 Subject: {Spam?} Re: Request Spamhaus contact In-Reply-To: <4D34E71E.4060706@foobar.org> References: <AANLkTimG4vpRagh3P8Cke=v_vUuPC4e3XMA9jKny8188@mail.gmail.com> <4D34B364.6060105@trelane.net> <AANLkTiks93QZeuw5k3xvz4-krBtGcdfEvUOXrc1Hx0=1@mail.gmail.com> <AANLkTikm6xcaKA=+tYzrX-Q5EL-qCbvR0CJmEEKfR4KD@mail.gmail.com> <AANLkTinHKhkkOtHpy6=nUPv4onz3-Boh7o0oXBg5G+fM@mail.gmail.com> <alpine.LFD.2.00.1101180105170.26930@noc.prolocation.net> <AANLkTikRv=Hvr+5_N-axq6OH-spbvybtyPBu9x1s+zY6@mail.gmail.com> <9DB2D57D-832F-4D3F-9B93-18F1947EDC0F@oitc.com> <AANLkTimXJoJ00VYvQs=JVA0Hn7ieFtArHSwn92K32q8f@mail.gmail.com> <alpine.LFD.2.00.1101180133450.27337@noc.prolocation.net> <AANLkTikQ+xjBNt5G-FzGg2+P2T-n3jqQ203_-EfDGUYQ@mail.gmail.com> <4D34E71E.4060706@foobar.org> Message-ID: <AANLkTim6-tY4bCZuAk15cyjH-ZJ-2O7Q5uQ2oezWu7qo@mail.gmail.com> I've tried taking it to Spamhaus directly on a few occasions but we continue to get treated like crap. At least this way the public can see that we have infact acted on the complaints. Jeff On Mon, Jan 17, 2011 at 8:04 PM, Nick Hilliard <nick at foobar.org> wrote: > On 18/01/2011 00:38, Jeffrey Lyon wrote: >> >> All of this IP space is null routed. The customer has been served with >> notice to vacate. What more are you asking for? > > Summarising other people positions: a functional abuse desk, a less > defensive attitude when people point out serious abuse going on in your > network, and the slightest inclination to investigate really serious crap on > your network when it's brought to your attention in the clearest terms > possible. > > E&OE > > > Nick > -- > p.s. less megaphone diplomacy would help, if you can clean enough egg off > your face to manage this. > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From jeroen at mompl.net Mon Jan 17 19:34:30 2011 From: jeroen at mompl.net (Jeroen van Aart) Date: Mon, 17 Jan 2011 17:34:30 -0800 Subject: {Spam?} Re: Request Spamhaus contact In-Reply-To: <4D34E71E.4060706@foobar.org> References: <AANLkTimG4vpRagh3P8Cke=v_vUuPC4e3XMA9jKny8188@mail.gmail.com> <4D34B364.6060105@trelane.net> <AANLkTiks93QZeuw5k3xvz4-krBtGcdfEvUOXrc1Hx0=1@mail.gmail.com> <AANLkTikm6xcaKA=+tYzrX-Q5EL-qCbvR0CJmEEKfR4KD@mail.gmail.com> <AANLkTinHKhkkOtHpy6=nUPv4onz3-Boh7o0oXBg5G+fM@mail.gmail.com> <alpine.LFD.2.00.1101180105170.26930@noc.prolocation.net> <AANLkTikRv=Hvr+5_N-axq6OH-spbvybtyPBu9x1s+zY6@mail.gmail.com> <9DB2D57D-832F-4D3F-9B93-18F1947EDC0F@oitc.com> <AANLkTimXJoJ00VYvQs=JVA0Hn7ieFtArHSwn92K32q8f@mail.gmail.com> <alpine.LFD.2.00.1101180133450.27337@noc.prolocation.net> <AANLkTikQ+xjBNt5G-FzGg2+P2T-n3jqQ203_-EfDGUYQ@mail.gmail.com> <4D34E71E.4060706@foobar.org> Message-ID: <4D34EE26.9010004@mompl.net> Nick Hilliard wrote: > Summarising other people positions: a functional abuse desk, a less > defensive attitude when people point out serious abuse going on in your > network, and the slightest inclination to investigate really serious > crap on your network when it's brought to your attention in the clearest > terms possible. > p.s. less megaphone diplomacy would help, if you can clean enough egg > off your face to manage this. I appreciate the effort, but it's pretty much impossible to "convert" someone who is a spammer or who hosts spammmers, or both, and make them behave in an appropriate manner. The best approach is to block and forget. Regards, Jeroen -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html From nenolod at systeminplace.net Mon Jan 17 19:36:04 2011 From: nenolod at systeminplace.net (William Pitcock) Date: Mon, 17 Jan 2011 19:36:04 -0600 Subject: Request Spamhaus contact In-Reply-To: <AANLkTikOqePOPkv1HLbb3GOisZWm255sEKFifX=mppOd@mail.gmail.com> References: <AANLkTimG4vpRagh3P8Cke=v_vUuPC4e3XMA9jKny8188@mail.gmail.com> <AANLkTikm6xcaKA=+tYzrX-Q5EL-qCbvR0CJmEEKfR4KD@mail.gmail.com> <AANLkTinHKhkkOtHpy6=nUPv4onz3-Boh7o0oXBg5G+fM@mail.gmail.com> <alpine.LFD.2.00.1101180105170.26930@noc.prolocation.net> <AANLkTikRv=Hvr+5_N-axq6OH-spbvybtyPBu9x1s+zY6@mail.gmail.com> <alpine.LFD.2.00.1101180120230.19534@noc.prolocation.net> <AANLkTin0x=Pu7m5J2EL0pOWimEWht3h46rgTBS5Bj0OQ@mail.gmail.com> <alpine.LFD.2.00.1101180137010.27337@noc.prolocation.net> <AANLkTinhN9e7OqJ1i0LwsaeqQDJoLOf3PTHtDMb5=fMJ@mail.gmail.com> <alpine.LFD.2.00.1101180143560.27337@noc.prolocation.net> <AANLkTinb=7NYDdht1iciQJLsCsM7GYULvjHvYBL7+P7r@mail.gmail.com> <20110117192154.5a41689a@petrie.gateway.2wire.net> <AANLkTinxkU9hzw-PaSX4GCcnXefGo0c--HDRhk9RU8Ss@mail.gmail.com> <alpine.LFD.2.00.1101180225130.11065@noc.prolocation.net> <AANLkTikOqePOPkv1HLbb3GOisZWm255sEKFifX=mppOd@mail.gmail.com> Message-ID: <20110117193604.3d86ee37@petrie.gateway.2wire.net> On Mon, 17 Jan 2011 20:28:55 -0500 Jeffrey Lyon <jeffrey.lyon at blacklotus.net> wrote: > Rhetorical question. Probably PCCW isn't accepting the null routes. > Why not blacklist them for having messed up communities? Why not actually nullroute the IPs instead of depending on BGP tagging? Again: "ip route 208.64.120.197 255.255.255.255 Null0" William From jeffrey.lyon at blacklotus.net Mon Jan 17 19:38:54 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 17 Jan 2011 20:38:54 -0500 Subject: Request Spamhaus contact In-Reply-To: <20110117193604.3d86ee37@petrie.gateway.2wire.net> References: <AANLkTimG4vpRagh3P8Cke=v_vUuPC4e3XMA9jKny8188@mail.gmail.com> <AANLkTikm6xcaKA=+tYzrX-Q5EL-qCbvR0CJmEEKfR4KD@mail.gmail.com> <AANLkTinHKhkkOtHpy6=nUPv4onz3-Boh7o0oXBg5G+fM@mail.gmail.com> <alpine.LFD.2.00.1101180105170.26930@noc.prolocation.net> <AANLkTikRv=Hvr+5_N-axq6OH-spbvybtyPBu9x1s+zY6@mail.gmail.com> <alpine.LFD.2.00.1101180120230.19534@noc.prolocation.net> <AANLkTin0x=Pu7m5J2EL0pOWimEWht3h46rgTBS5Bj0OQ@mail.gmail.com> <alpine.LFD.2.00.1101180137010.27337@noc.prolocation.net> <AANLkTinhN9e7OqJ1i0LwsaeqQDJoLOf3PTHtDMb5=fMJ@mail.gmail.com> <alpine.LFD.2.00.1101180143560.27337@noc.prolocation.net> <AANLkTinb=7NYDdht1iciQJLsCsM7GYULvjHvYBL7+P7r@mail.gmail.com> <20110117192154.5a41689a@petrie.gateway.2wire.net> <AANLkTinxkU9hzw-PaSX4GCcnXefGo0c--HDRhk9RU8Ss@mail.gmail.com> <alpine.LFD.2.00.1101180225130.11065@noc.prolocation.net> <AANLkTikOqePOPkv1HLbb3GOisZWm255sEKFifX=mppOd@mail.gmail.com> <20110117193604.3d86ee37@petrie.gateway.2wire.net> Message-ID: <AANLkTinuwrb7Ger6JVRPHXurSanVToYE5+REFTUNKETy@mail.gmail.com> It's a problem with PCCW not accepting the tags, we've had this issue with them occasionally and will need to address it with them directly. The machine itself has also been shut down so there should not be any further heartache. Jeff On Mon, Jan 17, 2011 at 8:36 PM, William Pitcock <nenolod at systeminplace.net> wrote: > On Mon, 17 Jan 2011 20:28:55 -0500 > Jeffrey Lyon <jeffrey.lyon at blacklotus.net> wrote: > >> Rhetorical question. Probably PCCW isn't accepting the null routes. >> Why not blacklist them for having messed up communities? > > Why not actually nullroute the IPs instead of depending on BGP tagging? > Again: "ip route 208.64.120.197 255.255.255.255 Null0" > > William > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From ops.lists at gmail.com Mon Jan 17 19:40:27 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 18 Jan 2011 07:10:27 +0530 Subject: Donating servers.. where? In-Reply-To: <E9404D46-1C87-46FA-8042-618DE4987006@akcin.net> References: <E9404D46-1C87-46FA-8042-618DE4987006@akcin.net> Message-ID: <AANLkTinvwa0n9pRkgj54NfL13U5QCx+_eOpwQwvv=qbr@mail.gmail.com> http://www.nsrc.org is always a good place On Tue, Jan 18, 2011 at 2:34 AM, Mehmet Akcin <mehmet at akcin.net> wrote: > > I have got some dell servers ( 860s and 1425s ) in mint condition. > > what's the best way to donate this hardware to someone who can use it for educational research? > > feel free to contact me directly -- Suresh Ramasubramanian (ops.lists at gmail.com) From jeffrey.lyon at blacklotus.net Mon Jan 17 19:40:38 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 17 Jan 2011 20:40:38 -0500 Subject: Request Spamhaus contact In-Reply-To: <8938753C-2B8D-496E-B5C7-9FE09A18C339@hubris.net> References: <AANLkTimG4vpRagh3P8Cke=v_vUuPC4e3XMA9jKny8188@mail.gmail.com> <4D34B364.6060105@trelane.net> <AANLkTiks93QZeuw5k3xvz4-krBtGcdfEvUOXrc1Hx0=1@mail.gmail.com> <AANLkTikm6xcaKA=+tYzrX-Q5EL-qCbvR0CJmEEKfR4KD@mail.gmail.com> <AANLkTinHKhkkOtHpy6=nUPv4onz3-Boh7o0oXBg5G+fM@mail.gmail.com> <alpine.LFD.2.00.1101180105170.26930@noc.prolocation.net> <AANLkTikRv=Hvr+5_N-axq6OH-spbvybtyPBu9x1s+zY6@mail.gmail.com> <alpine.LFD.2.00.1101180120230.19534@noc.prolocation.net> <AANLkTin0x=Pu7m5J2EL0pOWimEWht3h46rgTBS5Bj0OQ@mail.gmail.com> <alpine.LFD.2.00.1101180137010.27337@noc.prolocation.net> <AANLkTinhN9e7OqJ1i0LwsaeqQDJoLOf3PTHtDMb5=fMJ@mail.gmail.com> <8938753C-2B8D-496E-B5C7-9FE09A18C339@hubris.net> Message-ID: <AANLkTikTogMoo5ebrx+vPyDU+9jyq0boTOR+Wks4xHFE@mail.gmail.com> I'm not a spammer. I'm an ISP asking to be removed from Spamhaus for having fixed the SBL listings set in the last < 72 hours. I'm not exactally ROKSO material. Jeff On Mon, Jan 17, 2011 at 8:07 PM, Chris Owen <owenc at hubris.net> wrote: > On Jan 17, 2011, at 6:42 PM, Jeffrey Lyon wrote: > >> I fat fingered the netmask, try now. > > I've asked privately but would it really be too much to take this off NANOG? > > Spammer complaining he is on a RBL is hardly relevant. > > Chris > > -- > ------------------------------------------------------------------------- > Chris Owen ? ? ? ? - Garden City (620) 275-1900 - ?Lottery (noun): > President ? ? ? ? ?- Wichita ? ? (316) 858-3000 - ? ?A stupidity tax > Hubris Communications Inc ? ? ?www.hubris.net > ------------------------------------------------------------------------- > > > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From bill at herrin.us Mon Jan 17 19:43:45 2011 From: bill at herrin.us (William Herrin) Date: Mon, 17 Jan 2011 20:43:45 -0500 Subject: Request Spamhaus contact In-Reply-To: <AANLkTikbhduTxwLEEMa_NM87-Z-iE_Qp_49HQfJq+U+r@mail.gmail.com> References: <AANLkTimG4vpRagh3P8Cke=v_vUuPC4e3XMA9jKny8188@mail.gmail.com> <4D34B364.6060105@trelane.net> <AANLkTiks93QZeuw5k3xvz4-krBtGcdfEvUOXrc1Hx0=1@mail.gmail.com> <AANLkTikm6xcaKA=+tYzrX-Q5EL-qCbvR0CJmEEKfR4KD@mail.gmail.com> <AANLkTinHKhkkOtHpy6=nUPv4onz3-Boh7o0oXBg5G+fM@mail.gmail.com> <alpine.LFD.2.00.1101180105170.26930@noc.prolocation.net> <AANLkTikRv=Hvr+5_N-axq6OH-spbvybtyPBu9x1s+zY6@mail.gmail.com> <alpine.LFD.2.00.1101180120230.19534@noc.prolocation.net> <AANLkTin0x=Pu7m5J2EL0pOWimEWht3h46rgTBS5Bj0OQ@mail.gmail.com> <alpine.LFD.2.00.1101180137010.27337@noc.prolocation.net> <AANLkTinhN9e7OqJ1i0LwsaeqQDJoLOf3PTHtDMb5=fMJ@mail.gmail.com> <AANLkTikLDPbR1M22c2jq_RWnon1wZN9SGDo=3tdV-j=3@mail.gmail.com> <AANLkTikbhduTxwLEEMa_NM87-Z-iE_Qp_49HQfJq+U+r@mail.gmail.com> Message-ID: <AANLkTikPfEz2D6cUxHH1afH_5gTXkm1KuhDqnF93Y0GL@mail.gmail.com> On Mon, Jan 17, 2011 at 8:22 PM, Jeffrey Lyon <jeffrey.lyon at blacklotus.net> wrote: > Is it NANOG/Spamhaus' job to punish us or perhaps its better to simply > be satisfied that we're listening to what is being said? Jeff, Neither is correct. It's Spamhaus' job to flag the folks who haven't done a rudimentary job of keeping criminals off their network so that the rest of us can more easily keep them out of ours. It's NANOG's job to help us all communicate so that those who have a desire to fix operational problems can find and understand the key knowledge we need to do so. Spamhaus has provided you with the keys to the knowledge you need to fix the criminal intrusion into your network and these past few messages on NANOG have hopefully helped you understand that knowledge. If you have a desire to fix the operational problem, the rest is really up to you. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004 From mark at streamservice.nl Mon Jan 17 19:44:08 2011 From: mark at streamservice.nl (Mark Scholten) Date: Tue, 18 Jan 2011 02:44:08 +0100 Subject: Request Spamhaus contact In-Reply-To: <AANLkTi=UVDzicaPeajMy8Rk7eKjCa+kDgOrQ_8TGNSMU@mail.gmail.com> References: <AANLkTimG4vpRagh3P8Cke=v_vUuPC4e3XMA9jKny8188@mail.gmail.com> <4D34B364.6060105@trelane.net> <AANLkTiks93QZeuw5k3xvz4-krBtGcdfEvUOXrc1Hx0=1@mail.gmail.com> <AANLkTikm6xcaKA=+tYzrX-Q5EL-qCbvR0CJmEEKfR4KD@mail.gmail.com> <AANLkTinHKhkkOtHpy6=nUPv4onz3-Boh7o0oXBg5G+fM@mail.gmail.com> <alpine.LFD.2.00.1101180105170.26930@noc.prolocation.net> <AANLkTikRv=Hvr+5_N-axq6OH-spbvybtyPBu9x1s+zY6@mail.gmail.com> <alpine.LFD.2.00.1101180120230.19534@noc.prolocation.net> <AANLkTin0x=Pu7m5J2EL0pOWimEWht3h46rgTBS5Bj0OQ@mail.gmail.com> <0E75D743-0CF0-43A8-9316-5DA7191E1709@oitc.com> <AANLkTi==xwrZefBcqannLgDx1BdTiHmmOCa1qXOoMEFQ@mail.gmail.com> <0e3d01cbb6af$4404fa20$cc0eee60$@nl> <AANLkTi=UVDzicaPeajMy8Rk7eKjCa+kDgOrQ_8TGNSMU@mail.gmail.com> Message-ID: <0e4001cbb6b1$32c0bdb0$98423910$@nl> > From: jeffrey.lyon at gmail.com [mailto:jeffrey.lyon at gmail.com] On Behalf Of Jeffrey Lyon > Sent: Tuesday, January 18, 2011 2:32 AM > > I've already stated that i'm having the server powered down. What else > do you people want? Why not focus your energy on the providers who are > NOT responding to complaints? > > Jeff Actual action taken would be nice idea. After the server is powered down feel free to inform us about that fact. Don't say that you did nullroute something that we can see that that is a lie. If you need to wait for someone else mention that it will be solved within XX hours and inform everyone when it is done. I (and probably others) would like to know when the nullroute will be in place or the server is taken down. Sometimes I also need some time to process something, in such cases I mention that it could take X hour or reply after it has been fixed. Regards, Mark PS.: If providers don't reply at all we have our own (internal) blacklist. If they reply and say that they'll fix it within a day we normally don't put them on the internal blacklist. From jeffrey.lyon at blacklotus.net Mon Jan 17 19:45:16 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 17 Jan 2011 20:45:16 -0500 Subject: Request Spamhaus contact In-Reply-To: <AANLkTikPfEz2D6cUxHH1afH_5gTXkm1KuhDqnF93Y0GL@mail.gmail.com> References: <AANLkTimG4vpRagh3P8Cke=v_vUuPC4e3XMA9jKny8188@mail.gmail.com> <4D34B364.6060105@trelane.net> <AANLkTiks93QZeuw5k3xvz4-krBtGcdfEvUOXrc1Hx0=1@mail.gmail.com> <AANLkTikm6xcaKA=+tYzrX-Q5EL-qCbvR0CJmEEKfR4KD@mail.gmail.com> <AANLkTinHKhkkOtHpy6=nUPv4onz3-Boh7o0oXBg5G+fM@mail.gmail.com> <alpine.LFD.2.00.1101180105170.26930@noc.prolocation.net> <AANLkTikRv=Hvr+5_N-axq6OH-spbvybtyPBu9x1s+zY6@mail.gmail.com> <alpine.LFD.2.00.1101180120230.19534@noc.prolocation.net> <AANLkTin0x=Pu7m5J2EL0pOWimEWht3h46rgTBS5Bj0OQ@mail.gmail.com> <alpine.LFD.2.00.1101180137010.27337@noc.prolocation.net> <AANLkTinhN9e7OqJ1i0LwsaeqQDJoLOf3PTHtDMb5=fMJ@mail.gmail.com> <AANLkTikLDPbR1M22c2jq_RWnon1wZN9SGDo=3tdV-j=3@mail.gmail.com> <AANLkTikbhduTxwLEEMa_NM87-Z-iE_Qp_49HQfJq+U+r@mail.gmail.com> <AANLkTikPfEz2D6cUxHH1afH_5gTXkm1KuhDqnF93Y0GL@mail.gmail.com> Message-ID: <AANLkTinbCdNUPxvgxPJFEiFCV-bh_=scqMLV_TrKaTwH@mail.gmail.com> On Mon, Jan 17, 2011 at 8:43 PM, William Herrin <bill at herrin.us> wrote: > On Mon, Jan 17, 2011 at 8:22 PM, Jeffrey Lyon > <jeffrey.lyon at blacklotus.net> wrote: >> Is it NANOG/Spamhaus' job to punish us or perhaps its better to simply >> be satisfied that we're listening to what is being said? > > Jeff, > > Neither is correct. It's Spamhaus' job to flag the folks who haven't > done a rudimentary job of keeping criminals off their network so that > the rest of us can more easily keep them out of ours. It's NANOG's job > to help us all communicate so that those who have a desire to fix > operational problems can find and understand the key knowledge we need > to do so. > > Spamhaus has provided you with the keys to the knowledge you need to > fix the criminal intrusion into your network and these past few > messages on NANOG have hopefully helped you understand that knowledge. > If you have a desire to fix the operational problem, the rest is > really up to you. > > Regards, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com? bill at herrin.us > 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> > Falls Church, VA 22042-3004 > Bill, Each issue has been addressed. We're just waiting for Spamhaus' "around the clock" delisting service to pull through. Jeff -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From joelja at bogus.com Mon Jan 17 19:45:50 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Mon, 17 Jan 2011 17:45:50 -0800 Subject: Network Simulators In-Reply-To: <m239or1e8u.wl%randy@psg.com> References: <4D344B0D.3030602@freedomnet.co.nz> <m239or1e8u.wl%randy@psg.com> Message-ID: <4D34F0CE.1080901@bogus.com> On 1/17/11 12:12 PM, Randy Bush wrote: >> Are there any good Network Simulators/Trainers out there that support >> IPv6? I want play around with some IPv6 setup. > > what are you trying to simulate? > o control plane? > o traffic? > o interfaces and layers 1-3? > o ... products which I've recently evaluated for use in network simulation with relevance to ipv6. shunra - latency simulator nework property simulator. ixia - traffic generation, protocol simulation, control plane traffic spirent - see above. all three have v6 support. > makes a big difference > > randy > From nenolod at systeminplace.net Mon Jan 17 19:47:32 2011 From: nenolod at systeminplace.net (William Pitcock) Date: Mon, 17 Jan 2011 19:47:32 -0600 Subject: Request Spamhaus contact In-Reply-To: <AANLkTinuwrb7Ger6JVRPHXurSanVToYE5+REFTUNKETy@mail.gmail.com> References: <AANLkTimG4vpRagh3P8Cke=v_vUuPC4e3XMA9jKny8188@mail.gmail.com> <AANLkTinHKhkkOtHpy6=nUPv4onz3-Boh7o0oXBg5G+fM@mail.gmail.com> <alpine.LFD.2.00.1101180105170.26930@noc.prolocation.net> <AANLkTikRv=Hvr+5_N-axq6OH-spbvybtyPBu9x1s+zY6@mail.gmail.com> <alpine.LFD.2.00.1101180120230.19534@noc.prolocation.net> <AANLkTin0x=Pu7m5J2EL0pOWimEWht3h46rgTBS5Bj0OQ@mail.gmail.com> <alpine.LFD.2.00.1101180137010.27337@noc.prolocation.net> <AANLkTinhN9e7OqJ1i0LwsaeqQDJoLOf3PTHtDMb5=fMJ@mail.gmail.com> <alpine.LFD.2.00.1101180143560.27337@noc.prolocation.net> <AANLkTinb=7NYDdht1iciQJLsCsM7GYULvjHvYBL7+P7r@mail.gmail.com> <20110117192154.5a41689a@petrie.gateway.2wire.net> <AANLkTinxkU9hzw-PaSX4GCcnXefGo0c--HDRhk9RU8Ss@mail.gmail.com> <alpine.LFD.2.00.1101180225130.11065@noc.prolocation.net> <AANLkTikOqePOPkv1HLbb3GOisZWm255sEKFifX=mppOd@mail.gmail.com> <20110117193604.3d86ee37@petrie.gateway.2wire.net> <AANLkTinuwrb7Ger6JVRPHXurSanVToYE5+REFTUNKETy@mail.gmail.com> Message-ID: <20110117194732.68e7526b@petrie.gateway.2wire.net> On Mon, 17 Jan 2011 20:38:54 -0500 Jeffrey Lyon <jeffrey.lyon at blacklotus.net> wrote: > It's a problem with PCCW not accepting the tags, we've had this issue > with them occasionally and will need to address it with them directly. > The machine itself has also been shut down so there should not be any > further heartache. $ wget -S yourdrugsdiscount.com --2011-01-17 19:46:57-- http://yourdrugsdiscount.com/ Resolving yourdrugsdiscount.com... 208.64.122.10 Connecting to yourdrugsdiscount.com|208.64.122.10|:80... connected. HTTP request sent, awaiting response... HTTP/1.1 200 OK Date: Tue, 18 Jan 2011 01:47:10 GMT Server: Apache/2.2.17 (CentOS) X-Powered-By: PHP/5.2.17 P3P: CP="IDC DSP COR CURa ADMa OUR IND PHY ONL COM STA" ETag: PUB1295315230 Last-Modified: Wed, 03 Nov 2010 13:01:01 GMT Expires: Tue, 18 Jan 2011 04:47:10 GMT Pragma: no-cache Cache-Control: public, max-age=10800 Set-Cookie: __store_sid=66ofgeqrfa51nt20nc63j9o003; path=/ Set-Cookie: token=7d010443693eec253a121e2aa2ba177c; expires=Wed, 19-Jan-2011 01:47:11 GMT; path=/ Connection: close Content-Type: text/html; charset=utf-8 Length: unspecified [text/html] Saving to: `index.html' [ <=> ] 57,377 225K/s in 0.2s 2011-01-17 19:46:59 (225 KB/s) - `index.html' saved [57377] Wow you managed to sure clean up your spam problem. One box down, hundreds to go? William From jeffrey.lyon at blacklotus.net Mon Jan 17 19:48:28 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 17 Jan 2011 20:48:28 -0500 Subject: Request Spamhaus contact In-Reply-To: <0e4001cbb6b1$32c0bdb0$98423910$@nl> References: <AANLkTimG4vpRagh3P8Cke=v_vUuPC4e3XMA9jKny8188@mail.gmail.com> <4D34B364.6060105@trelane.net> <AANLkTiks93QZeuw5k3xvz4-krBtGcdfEvUOXrc1Hx0=1@mail.gmail.com> <AANLkTikm6xcaKA=+tYzrX-Q5EL-qCbvR0CJmEEKfR4KD@mail.gmail.com> <AANLkTinHKhkkOtHpy6=nUPv4onz3-Boh7o0oXBg5G+fM@mail.gmail.com> <alpine.LFD.2.00.1101180105170.26930@noc.prolocation.net> <AANLkTikRv=Hvr+5_N-axq6OH-spbvybtyPBu9x1s+zY6@mail.gmail.com> <alpine.LFD.2.00.1101180120230.19534@noc.prolocation.net> <AANLkTin0x=Pu7m5J2EL0pOWimEWht3h46rgTBS5Bj0OQ@mail.gmail.com> <0E75D743-0CF0-43A8-9316-5DA7191E1709@oitc.com> <AANLkTi==xwrZefBcqannLgDx1BdTiHmmOCa1qXOoMEFQ@mail.gmail.com> <0e3d01cbb6af$4404fa20$cc0eee60$@nl> <AANLkTi=UVDzicaPeajMy8Rk7eKjCa+kDgOrQ_8TGNSMU@mail.gmail.com> <0e4001cbb6b1$32c0bdb0$98423910$@nl> Message-ID: <AANLkTineFE+XSRPtD+55jSo1eQLNua4vT0Ws6Vbb13TP@mail.gmail.com> On Mon, Jan 17, 2011 at 8:44 PM, Mark Scholten <mark at streamservice.nl> wrote: >> From: jeffrey.lyon at gmail.com [mailto:jeffrey.lyon at gmail.com] On Behalf Of > Jeffrey Lyon >> Sent: Tuesday, January 18, 2011 2:32 AM >> >> I've already stated that i'm having the server powered down. What else >> do you people want? Why not focus your energy on the providers who are >> NOT responding to complaints? >> >> Jeff > > Actual action taken would be nice idea. After the server is powered down > feel free to inform us about that fact. Don't say that you did nullroute > something that we can see that that is a lie. If you need to wait for > someone else mention that it will be solved within XX hours and inform > everyone when it is done. > > I (and probably others) would like to know when the nullroute will be in > place or the server is taken down. > > Sometimes I also need some time to process something, in such cases I > mention that it could take X hour or reply after it has been fixed. > > Regards, Mark > > PS.: If providers don't reply at all we have our own (internal) blacklist. > If they reply and say that they'll fix it within a day we normally don't put > them on the internal blacklist. > > Mark, All of my sources were routing through Telia, I had no idea that PCCW was not accepting the tags. The null routes were set immediately once this issue came to my attention and the server was powered down immediately once I determined that PCCW was not accepting the discard tags. I've listened to and acted on every single Spamhaus listing since the founding of this company and all of a sudden in late 2010 a couple of pharmacy spammers pick up a dedicated server, thus warranting full blown witch trials on our company. I was very polite with Spamhaus at first but so far i've been treated like garbage. You would be angry as well. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From grobe0ba at gmail.com Mon Jan 17 20:23:49 2011 From: grobe0ba at gmail.com (Atticus) Date: Mon, 17 Jan 2011 21:23:49 -0500 Subject: Request Spamhaus contact In-Reply-To: <AANLkTi=UVDzicaPeajMy8Rk7eKjCa+kDgOrQ_8TGNSMU@mail.gmail.com> References: <AANLkTimG4vpRagh3P8Cke=v_vUuPC4e3XMA9jKny8188@mail.gmail.com> <4D34B364.6060105@trelane.net> <AANLkTiks93QZeuw5k3xvz4-krBtGcdfEvUOXrc1Hx0=1@mail.gmail.com> <AANLkTikm6xcaKA=+tYzrX-Q5EL-qCbvR0CJmEEKfR4KD@mail.gmail.com> <AANLkTinHKhkkOtHpy6=nUPv4onz3-Boh7o0oXBg5G+fM@mail.gmail.com> <alpine.LFD.2.00.1101180105170.26930@noc.prolocation.net> <AANLkTikRv=Hvr+5_N-axq6OH-spbvybtyPBu9x1s+zY6@mail.gmail.com> <alpine.LFD.2.00.1101180120230.19534@noc.prolocation.net> <AANLkTin0x=Pu7m5J2EL0pOWimEWht3h46rgTBS5Bj0OQ@mail.gmail.com> <0E75D743-0CF0-43A8-9316-5DA7191E1709@oitc.com> <AANLkTi==xwrZefBcqannLgDx1BdTiHmmOCa1qXOoMEFQ@mail.gmail.com> <0e3d01cbb6af$4404fa20$cc0eee60$@nl> <AANLkTi=UVDzicaPeajMy8Rk7eKjCa+kDgOrQ_8TGNSMU@mail.gmail.com> Message-ID: <AANLkTimhaPH1apfFuZr=dJJF-5Vqd1SjWEfEOZwJbM0N@mail.gmail.com> They /are/ focusing on a provider that doesnt respond to complaints. On Jan 17, 2011 9:20 PM, "Jeffrey Lyon" <jeffrey.lyon at blacklotus.net> wrote: I've already stated that i'm having the server powered down. What else do you people want? Why not focus your energy on the providers who are NOT responding to complaints? Jeff On Mon, Jan 17, 2011 at 8:30 PM, Mark Scholten <mark at streamservice.nl> wrote: > > >> -----Original ... -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Co... From ospfisisis at gmail.com Mon Jan 17 20:28:28 2011 From: ospfisisis at gmail.com (Mark Wall) Date: Mon, 17 Jan 2011 21:28:28 -0500 Subject: {Spam?} Re: Request Spamhaus contact In-Reply-To: <AANLkTim6-tY4bCZuAk15cyjH-ZJ-2O7Q5uQ2oezWu7qo@mail.gmail.com> References: <AANLkTimG4vpRagh3P8Cke=v_vUuPC4e3XMA9jKny8188@mail.gmail.com> <4D34B364.6060105@trelane.net> <AANLkTiks93QZeuw5k3xvz4-krBtGcdfEvUOXrc1Hx0=1@mail.gmail.com> <AANLkTikm6xcaKA=+tYzrX-Q5EL-qCbvR0CJmEEKfR4KD@mail.gmail.com> <AANLkTinHKhkkOtHpy6=nUPv4onz3-Boh7o0oXBg5G+fM@mail.gmail.com> <alpine.LFD.2.00.1101180105170.26930@noc.prolocation.net> <AANLkTikRv=Hvr+5_N-axq6OH-spbvybtyPBu9x1s+zY6@mail.gmail.com> <9DB2D57D-832F-4D3F-9B93-18F1947EDC0F@oitc.com> <AANLkTimXJoJ00VYvQs=JVA0Hn7ieFtArHSwn92K32q8f@mail.gmail.com> <alpine.LFD.2.00.1101180133450.27337@noc.prolocation.net> <AANLkTikQ+xjBNt5G-FzGg2+P2T-n3jqQ203_-EfDGUYQ@mail.gmail.com> <4D34E71E.4060706@foobar.org> <AANLkTim6-tY4bCZuAk15cyjH-ZJ-2O7Q5uQ2oezWu7qo@mail.gmail.com> Message-ID: <AANLkTi=t+RVtX+VSu9Z5-Ve7A0Yg_zp9+OAj5sPbWsK2@mail.gmail.com> On Mon, Jan 17, 2011 at 8:32 PM, Jeffrey Lyon <jeffrey.lyon at blacklotus.net>wrote: > I've tried taking it to Spamhaus directly on a few occasions but we > continue to get treated like crap. At least this way the public can > see that we have infact acted on the complaints. > > We have found Spamhaus to work well with us. In the bringing we had to prove responsibly but after that they are one of the easier to work with. > Jeff > > On Mon, Jan 17, 2011 at 8:04 PM, Nick Hilliard <nick at foobar.org> wrote: > > On 18/01/2011 00:38, Jeffrey Lyon wrote: > >> > >> All of this IP space is null routed. The customer has been served with > >> notice to vacate. What more are you asking for? > > > > Summarising other people positions: a functional abuse desk, a less > > defensive attitude when people point out serious abuse going on in your > > network, and the slightest inclination to investigate really serious crap > on > > your network when it's brought to your attention in the clearest terms > > possible. > > > > E&OE > > > > > > Nick > > -- > > p.s. less megaphone diplomacy would help, if you can clean enough egg off > > your face to manage this. > > > > > > > > -- > Jeffrey Lyon, Leadership Team > jeffrey.lyon at blacklotus.net | http://www.blacklotus.net > Black Lotus Communications - AS32421 > First and Leading in DDoS Protection Solutions > > From stitch at zimmy.co.uk Mon Jan 17 20:29:46 2011 From: stitch at zimmy.co.uk (Chris Fuenty) Date: Mon, 17 Jan 2011 20:29:46 -0600 Subject: Request Spamhaus contact In-Reply-To: <AANLkTi=UVDzicaPeajMy8Rk7eKjCa+kDgOrQ_8TGNSMU@mail.gmail.com> References: <AANLkTimG4vpRagh3P8Cke=v_vUuPC4e3XMA9jKny8188@mail.gmail.com> <4D34B364.6060105@trelane.net> <AANLkTiks93QZeuw5k3xvz4-krBtGcdfEvUOXrc1Hx0=1@mail.gmail.com> <AANLkTikm6xcaKA=+tYzrX-Q5EL-qCbvR0CJmEEKfR4KD@mail.gmail.com> <AANLkTinHKhkkOtHpy6=nUPv4onz3-Boh7o0oXBg5G+fM@mail.gmail.com> <alpine.LFD.2.00.1101180105170.26930@noc.prolocation.net> <AANLkTikRv=Hvr+5_N-axq6OH-spbvybtyPBu9x1s+zY6@mail.gmail.com> <alpine.LFD.2.00.1101180120230.19534@noc.prolocation.net> <AANLkTin0x=Pu7m5J2EL0pOWimEWht3h46rgTBS5Bj0OQ@mail.gmail.com> <0E75D743-0CF0-43A8-9316-5DA7191E1709@oitc.com> <AANLkTi==xwrZefBcqannLgDx1BdTiHmmOCa1qXOoMEFQ@mail.gmail.com> <0e3d01cbb6af$4404fa20$cc0eee60$@nl> <AANLkTi=UVDzicaPeajMy8Rk7eKjCa+kDgOrQ_8TGNSMU@mail.gmail.com> Message-ID: <4D34FB1A.5060201@zimmy.co.uk> We don't want things like http://bit.ly/gGlKbF c On 1/17/2011 19:31, Jeffrey Lyon wrote: > I've already stated that i'm having the server powered down. What else > do you people want? Why not focus your energy on the providers who are > NOT responding to complaints? > > Jeff > > On Mon, Jan 17, 2011 at 8:30 PM, Mark Scholten <mark at streamservice.nl> wrote: >> >> >>> -----Original Message----- >>> From: Jeffrey Lyon [mailto:jeffrey.lyon at blacklotus.net] >>> Sent: Tuesday, January 18, 2011 1:58 AM >>> To: TR Shaw >>> Cc: nanog at nanog.org >>> Subject: Re: Request Spamhaus contact >>> >>> TR, >>> >>> Again, it's been null routed. Customer has been served with notice. >>> Unless you guys can help find some more related IP space I think the >>> issue has been solved. >>> >>> Thanks, Jeff >> >> Hello Jeffrey, >> >> At least a few moments back (after receiving the message above) it was >> possible to get the page at www . vertrouwdeapotheek . nl at IP >> 208.64.120.197. >> >> Do you really know if it has been solved? >> >> Regards, Mark >> >> > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110117/27e6612a/attachment.bin> From ospfisisis at gmail.com Mon Jan 17 20:32:03 2011 From: ospfisisis at gmail.com (Mark Wall) Date: Mon, 17 Jan 2011 21:32:03 -0500 Subject: Request Spamhaus contact In-Reply-To: <20110117193604.3d86ee37@petrie.gateway.2wire.net> References: <AANLkTimG4vpRagh3P8Cke=v_vUuPC4e3XMA9jKny8188@mail.gmail.com> <AANLkTikm6xcaKA=+tYzrX-Q5EL-qCbvR0CJmEEKfR4KD@mail.gmail.com> <AANLkTinHKhkkOtHpy6=nUPv4onz3-Boh7o0oXBg5G+fM@mail.gmail.com> <alpine.LFD.2.00.1101180105170.26930@noc.prolocation.net> <AANLkTikRv=Hvr+5_N-axq6OH-spbvybtyPBu9x1s+zY6@mail.gmail.com> <alpine.LFD.2.00.1101180120230.19534@noc.prolocation.net> <AANLkTin0x=Pu7m5J2EL0pOWimEWht3h46rgTBS5Bj0OQ@mail.gmail.com> <alpine.LFD.2.00.1101180137010.27337@noc.prolocation.net> <AANLkTinhN9e7OqJ1i0LwsaeqQDJoLOf3PTHtDMb5=fMJ@mail.gmail.com> <alpine.LFD.2.00.1101180143560.27337@noc.prolocation.net> <AANLkTinb=7NYDdht1iciQJLsCsM7GYULvjHvYBL7+P7r@mail.gmail.com> <20110117192154.5a41689a@petrie.gateway.2wire.net> <AANLkTinxkU9hzw-PaSX4GCcnXefGo0c--HDRhk9RU8Ss@mail.gmail.com> <alpine.LFD.2.00.1101180225130.11065@noc.prolocation.net> <AANLkTikOqePOPkv1HLbb3GOisZWm255sEKFifX=mppOd@mail.gmail.com> <20110117193604.3d86ee37@petrie.gateway.2wire.net> Message-ID: <AANLkTinh6C6cHFUXS3pYiaj69xjqQF+=_ng_04mkjeah@mail.gmail.com> On Mon, Jan 17, 2011 at 8:36 PM, William Pitcock <nenolod at systeminplace.net>wrote: > On Mon, 17 Jan 2011 20:28:55 -0500 > Jeffrey Lyon <jeffrey.lyon at blacklotus.net> wrote: > > > Rhetorical question. Probably PCCW isn't accepting the null routes. > > Why not blacklist them for having messed up communities? > > Why not actually nullroute the IPs instead of depending on BGP tagging? > Again: "ip route 208.64.120.197 255.255.255.255 Null0" > > William > > I prefer ip route 208.64.120.197 255.255.255.255 Null0 tag <nullroute community> Serves both purposes well From jeffrey.lyon at blacklotus.net Mon Jan 17 20:34:49 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 17 Jan 2011 21:34:49 -0500 Subject: Request Spamhaus contact In-Reply-To: <4D34ECE3.40408@trelane.net> References: <AANLkTimG4vpRagh3P8Cke=v_vUuPC4e3XMA9jKny8188@mail.gmail.com> <4D34B364.6060105@trelane.net> <AANLkTiks93QZeuw5k3xvz4-krBtGcdfEvUOXrc1Hx0=1@mail.gmail.com> <AANLkTikm6xcaKA=+tYzrX-Q5EL-qCbvR0CJmEEKfR4KD@mail.gmail.com> <AANLkTinHKhkkOtHpy6=nUPv4onz3-Boh7o0oXBg5G+fM@mail.gmail.com> <alpine.LFD.2.00.1101180105170.26930@noc.prolocation.net> <AANLkTikRv=Hvr+5_N-axq6OH-spbvybtyPBu9x1s+zY6@mail.gmail.com> <alpine.LFD.2.00.1101180120230.19534@noc.prolocation.net> <AANLkTin0x=Pu7m5J2EL0pOWimEWht3h46rgTBS5Bj0OQ@mail.gmail.com> <alpine.LFD.2.00.1101180137010.27337@noc.prolocation.net> <AANLkTinhN9e7OqJ1i0LwsaeqQDJoLOf3PTHtDMb5=fMJ@mail.gmail.com> <alpine.LFD.2.00.1101180143560.27337@noc.prolocation.net> <AANLkTinb=7NYDdht1iciQJLsCsM7GYULvjHvYBL7+P7r@mail.gmail.com> <4D34ECE3.40408@trelane.net> Message-ID: <AANLkTi=0dMHnkpLFoqkw=vqY8wV3ecLpfkOrMR9gOC6P@mail.gmail.com> We were offering a privacy protected domain registration service at one point which we have since discontinued for obvious reasons. Jeff On Mon, Jan 17, 2011 at 8:29 PM, Andrew Kirch <trelane at trelane.net> wrote: >> Raymond, >> >> I do not take you for a fool, the assignment is legitimately null >> routed. My traceroutes are dropping at my home ISP. >> >> Jeff > Come on Jeff, I googled the listed address for blacklotus.net, and look > what comes up: > http://www.google.com/search?sourceid=chrome&ie=UTF-8&q=3419+Virginia+Beach+Blvd.+%23D5 > <http://www.google.com/search?sourceid=chrome&ie=UTF-8&q=3419+Virginia+Beach+Blvd.+%23D5> > Scams, spam, garbage, etc. ?Guys, it looks like we are dealing with the > spammer/scammer himself. > The quicker his peering turfs him, the better. ?Incidentally, this /21 > is being announced using MZIMA's > AS number... (providing our much needed EFNet Connection) This is very > interesting. ?Couldn't you > afford your own? > > Andrew > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From dedelman at iname.com Mon Jan 17 20:45:08 2011 From: dedelman at iname.com (Dave Edelman) Date: Mon, 17 Jan 2011 21:45:08 -0500 Subject: Network Simulators In-Reply-To: <m239or1e8u.wl%randy@psg.com> References: <4D344B0D.3030602@freedomnet.co.nz> <m239or1e8u.wl%randy@psg.com> Message-ID: <7DF8A222-54F7-4537-8DE5-75D632DE45D4@iname.com> If you have access to IOS images, look at GNS3 -Dave From jeffrey.lyon at blacklotus.net Mon Jan 17 20:45:40 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 17 Jan 2011 21:45:40 -0500 Subject: Request Spamhaus contact In-Reply-To: <AANLkTi=0dMHnkpLFoqkw=vqY8wV3ecLpfkOrMR9gOC6P@mail.gmail.com> References: <AANLkTimG4vpRagh3P8Cke=v_vUuPC4e3XMA9jKny8188@mail.gmail.com> <4D34B364.6060105@trelane.net> <AANLkTiks93QZeuw5k3xvz4-krBtGcdfEvUOXrc1Hx0=1@mail.gmail.com> <AANLkTikm6xcaKA=+tYzrX-Q5EL-qCbvR0CJmEEKfR4KD@mail.gmail.com> <AANLkTinHKhkkOtHpy6=nUPv4onz3-Boh7o0oXBg5G+fM@mail.gmail.com> <alpine.LFD.2.00.1101180105170.26930@noc.prolocation.net> <AANLkTikRv=Hvr+5_N-axq6OH-spbvybtyPBu9x1s+zY6@mail.gmail.com> <alpine.LFD.2.00.1101180120230.19534@noc.prolocation.net> <AANLkTin0x=Pu7m5J2EL0pOWimEWht3h46rgTBS5Bj0OQ@mail.gmail.com> <alpine.LFD.2.00.1101180137010.27337@noc.prolocation.net> <AANLkTinhN9e7OqJ1i0LwsaeqQDJoLOf3PTHtDMb5=fMJ@mail.gmail.com> <alpine.LFD.2.00.1101180143560.27337@noc.prolocation.net> <AANLkTinb=7NYDdht1iciQJLsCsM7GYULvjHvYBL7+P7r@mail.gmail.com> <4D34ECE3.40408@trelane.net> <AANLkTi=0dMHnkpLFoqkw=vqY8wV3ecLpfkOrMR9gOC6P@mail.gmail.com> Message-ID: <AANLkTim7=b_w17VrK71-D9rG==ukGode7krBQRX9woMN@mail.gmail.com> All, I would like to extend a special thanks to one of the Spamhaus team members for reaching out to me and offering dialogue on this matter. He was quite polite and understanding of the situation and we came to terms on what needed to occur on both sides. I didn't catch his name as the connection was bad but I would like to say "Thank You" and express my gratitude that we can potentially resolve future issues on more familiar terms. Thanks, -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From jeffrey.lyon at blacklotus.net Mon Jan 17 20:58:37 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 17 Jan 2011 21:58:37 -0500 Subject: {Spam?} Re: Request Spamhaus contact In-Reply-To: <AANLkTi=t+RVtX+VSu9Z5-Ve7A0Yg_zp9+OAj5sPbWsK2@mail.gmail.com> References: <AANLkTimG4vpRagh3P8Cke=v_vUuPC4e3XMA9jKny8188@mail.gmail.com> <4D34B364.6060105@trelane.net> <AANLkTiks93QZeuw5k3xvz4-krBtGcdfEvUOXrc1Hx0=1@mail.gmail.com> <AANLkTikm6xcaKA=+tYzrX-Q5EL-qCbvR0CJmEEKfR4KD@mail.gmail.com> <AANLkTinHKhkkOtHpy6=nUPv4onz3-Boh7o0oXBg5G+fM@mail.gmail.com> <alpine.LFD.2.00.1101180105170.26930@noc.prolocation.net> <AANLkTikRv=Hvr+5_N-axq6OH-spbvybtyPBu9x1s+zY6@mail.gmail.com> <9DB2D57D-832F-4D3F-9B93-18F1947EDC0F@oitc.com> <AANLkTimXJoJ00VYvQs=JVA0Hn7ieFtArHSwn92K32q8f@mail.gmail.com> <alpine.LFD.2.00.1101180133450.27337@noc.prolocation.net> <AANLkTikQ+xjBNt5G-FzGg2+P2T-n3jqQ203_-EfDGUYQ@mail.gmail.com> <4D34E71E.4060706@foobar.org> <AANLkTim6-tY4bCZuAk15cyjH-ZJ-2O7Q5uQ2oezWu7qo@mail.gmail.com> <AANLkTi=t+RVtX+VSu9Z5-Ve7A0Yg_zp9+OAj5sPbWsK2@mail.gmail.com> Message-ID: <AANLkTikzNcPNgs_dBEoF5Lf0gOWR7i=RCyG0H_qnrqA3@mail.gmail.com> On Mon, Jan 17, 2011 at 9:28 PM, Mark Wall <ospfisisis at gmail.com> wrote: > On Mon, Jan 17, 2011 at 8:32 PM, Jeffrey Lyon > <jeffrey.lyon at blacklotus.net>wrote: > >> I've tried taking it to Spamhaus directly on a few occasions but we >> continue to get treated like crap. At least this way the public can >> see that we have infact acted on the complaints. >> >> > > We have found Spamhaus to work well with us. In the bringing we had to > prove responsibly but after that they are one of the easier to work with. > > > >> Jeff >> >> On Mon, Jan 17, 2011 at 8:04 PM, Nick Hilliard <nick at foobar.org> wrote: >> > On 18/01/2011 00:38, Jeffrey Lyon wrote: >> >> >> >> All of this IP space is null routed. The customer has been served with >> >> notice to vacate. What more are you asking for? >> > >> > Summarising other people positions: a functional abuse desk, a less >> > defensive attitude when people point out serious abuse going on in your >> > network, and the slightest inclination to investigate really serious crap >> on >> > your network when it's brought to your attention in the clearest terms >> > possible. >> > >> > E&OE >> > >> > >> > Nick >> > -- >> > p.s. less megaphone diplomacy would help, if you can clean enough egg off >> > your face to manage this. >> > >> > >> >> >> >> -- >> Jeffrey Lyon, Leadership Team >> jeffrey.lyon at blacklotus.net | http://www.blacklotus.net >> Black Lotus Communications - AS32421 >> First and Leading in DDoS Protection Solutions >> >> > Mark, Indeed, despite my angry ranting one of their staff was kind enough to reach out by telephone and I believe all outstanding concerns have been resolved. Thanks, Jeff -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From jfbeam at gmail.com Mon Jan 17 21:08:45 2011 From: jfbeam at gmail.com (Ricky Beam) Date: Mon, 17 Jan 2011 22:08:45 -0500 Subject: Request Spamhaus contact In-Reply-To: <AANLkTimTuKA4UUki6TP1vsStRLWw6afK-DE9ks_aan+6@mail.gmail.com> References: <AANLkTimG4vpRagh3P8Cke=v_vUuPC4e3XMA9jKny8188@mail.gmail.com> <4D34B364.6060105@trelane.net> <AANLkTiks93QZeuw5k3xvz4-krBtGcdfEvUOXrc1Hx0=1@mail.gmail.com> <AANLkTikm6xcaKA=+tYzrX-Q5EL-qCbvR0CJmEEKfR4KD@mail.gmail.com> <AANLkTinHKhkkOtHpy6=nUPv4onz3-Boh7o0oXBg5G+fM@mail.gmail.com> <AANLkTiky_CvCsUbTfaw6emK_yiL1DXmio5CN0p0tuBfg@mail.gmail.com> <AANLkTimTuKA4UUki6TP1vsStRLWw6afK-DE9ks_aan+6@mail.gmail.com> Message-ID: <op.vphhovwotfhldh@rbeam.xactional.com> On Mon, 17 Jan 2011 19:13:16 -0500, Jeffrey Lyon <jeffrey.lyon at blacklotus.net> wrote: > I'm getting 72.215.225.9 for that host. [root:pts/0{4}]debian1:~/[09:53 PM]:whois canadian-rx-store.org | grep ^Name Name Server:NS2.CODIZ.NET Name Server:NS4.CODIZ.NET ... [root:pts/0{4}]debian1:~/[09:53 PM]:host canadian-rx-store.org. NS2.CODIZ.NET Using domain server: Name: NS2.CODIZ.NET Address: 76.76.96.42#53 Aliases: Host canadian-rx-store.org not found: 5(REFUSED) [root:pts/0{4}]debian1:~/[09:53 PM]:host canadian-rx-store.org. NS4.CODIZ.NET Using domain server: Name: NS4.CODIZ.NET Address: 95.31.133.201#53 Aliases: Host canadian-rx-store.org not found: 5(REFUSED) The reason a /21 is listed is because you have trash all over the space. *I* do the same thing all the time. I'm not paying whack-a-mole with spammers. (Granted, that only effects my own networks.) --Ricky From bdantzig at medline.com Mon Jan 17 21:16:26 2011 From: bdantzig at medline.com (Dantzig, Brian) Date: 17 Jan 2011 21:16:26 -0600 Subject: Nexus 5000 with 4G FC module - initialization ? Message-ID: <C8064C97-180C-459C-851E-349D983FE158@medline.com> You need to turn on fcoe support with the configuration command "feature fcoe". You will also need the appropriate license for fabric services. But even without the license you should be able to enter fc commands. They just won't work until you add the license. Without the"feature fcoe", the interface type won't even show up in command help. There are other storage fabric related services that you may want to turn on with the feature command as well. Brian Dantzig Senior Network Engineer Medline Industries From nenolod at systeminplace.net Mon Jan 17 21:18:16 2011 From: nenolod at systeminplace.net (William Pitcock) Date: Mon, 17 Jan 2011 21:18:16 -0600 Subject: Request Spamhaus contact In-Reply-To: <AANLkTi=0dMHnkpLFoqkw=vqY8wV3ecLpfkOrMR9gOC6P@mail.gmail.com> References: <AANLkTimG4vpRagh3P8Cke=v_vUuPC4e3XMA9jKny8188@mail.gmail.com> <4D34B364.6060105@trelane.net> <AANLkTiks93QZeuw5k3xvz4-krBtGcdfEvUOXrc1Hx0=1@mail.gmail.com> <AANLkTikm6xcaKA=+tYzrX-Q5EL-qCbvR0CJmEEKfR4KD@mail.gmail.com> <AANLkTinHKhkkOtHpy6=nUPv4onz3-Boh7o0oXBg5G+fM@mail.gmail.com> <alpine.LFD.2.00.1101180105170.26930@noc.prolocation.net> <AANLkTikRv=Hvr+5_N-axq6OH-spbvybtyPBu9x1s+zY6@mail.gmail.com> <alpine.LFD.2.00.1101180120230.19534@noc.prolocation.net> <AANLkTin0x=Pu7m5J2EL0pOWimEWht3h46rgTBS5Bj0OQ@mail.gmail.com> <alpine.LFD.2.00.1101180137010.27337@noc.prolocation.net> <AANLkTinhN9e7OqJ1i0LwsaeqQDJoLOf3PTHtDMb5=fMJ@mail.gmail.com> <alpine.LFD.2.00.1101180143560.27337@noc.prolocation.net> <AANLkTinb=7NYDdht1iciQJLsCsM7GYULvjHvYBL7+P7r@mail.gmail.com> <4D34ECE3.40408@trelane.net> <AANLkTi=0dMHnkpLFoqkw=vqY8wV3ecLpfkOrMR9gOC6P@mail.gmail.com> Message-ID: <20110117211816.2acc0e8d@petrie.gateway.2wire.net> On Mon, 17 Jan 2011 21:34:49 -0500 Jeffrey Lyon <jeffrey.lyon at blacklotus.net> wrote: > We were offering a privacy protected domain registration service at > one point which we have since discontinued for obvious reasons. Ah yes! That *was* you guys. Did you know that you're still being recommended on 4chan /b/ for no-questions-asked fully-anonymous bullet-proof hosting? Is there a reason why /b/ seems to be recommending you still? I would figure they wouldn't be recommending something you're no longer doing. William From nenolod at systeminplace.net Mon Jan 17 21:27:38 2011 From: nenolod at systeminplace.net (William Pitcock) Date: Mon, 17 Jan 2011 21:27:38 -0600 Subject: Request Spamhaus contact In-Reply-To: <AANLkTim7=b_w17VrK71-D9rG==ukGode7krBQRX9woMN@mail.gmail.com> References: <AANLkTimG4vpRagh3P8Cke=v_vUuPC4e3XMA9jKny8188@mail.gmail.com> <4D34B364.6060105@trelane.net> <AANLkTiks93QZeuw5k3xvz4-krBtGcdfEvUOXrc1Hx0=1@mail.gmail.com> <AANLkTikm6xcaKA=+tYzrX-Q5EL-qCbvR0CJmEEKfR4KD@mail.gmail.com> <AANLkTinHKhkkOtHpy6=nUPv4onz3-Boh7o0oXBg5G+fM@mail.gmail.com> <alpine.LFD.2.00.1101180105170.26930@noc.prolocation.net> <AANLkTikRv=Hvr+5_N-axq6OH-spbvybtyPBu9x1s+zY6@mail.gmail.com> <alpine.LFD.2.00.1101180120230.19534@noc.prolocation.net> <AANLkTin0x=Pu7m5J2EL0pOWimEWht3h46rgTBS5Bj0OQ@mail.gmail.com> <alpine.LFD.2.00.1101180137010.27337@noc.prolocation.net> <AANLkTinhN9e7OqJ1i0LwsaeqQDJoLOf3PTHtDMb5=fMJ@mail.gmail.com> <alpine.LFD.2.00.1101180143560.27337@noc.prolocation.net> <AANLkTinb=7NYDdht1iciQJLsCsM7GYULvjHvYBL7+P7r@mail.gmail.com> <4D34ECE3.40408@trelane.net> <AANLkTi=0dMHnkpLFoqkw=vqY8wV3ecLpfkOrMR9gOC6P@mail.gmail.com> <AANLkTim7=b_w17VrK71-D9rG==ukGode7krBQRX9woMN@mail.gmail.com> Message-ID: <20110117212738.08e230c1@petrie.gateway.2wire.net> Hi, On Mon, 17 Jan 2011 21:45:40 -0500 Jeffrey Lyon <jeffrey.lyon at blacklotus.net> wrote: > All, > > I would like to extend a special thanks to one of the Spamhaus team > members for reaching out to me and offering dialogue on this matter. > He was quite polite and understanding of the situation and we came to > terms on what needed to occur on both sides. I didn't catch his name > as the connection was bad but I would like to say "Thank You" and > express my gratitude that we can potentially resolve future issues on > more familiar terms. > > Thanks, Still waiting on clarification on your abuse policy. Is a spamhaus SBL listing mandatory for you to shutdown cyber-criminals or have you learned *anything* at all from this? We don't *care* if you got this issue with Spamhaus resolved. You turned it into a much *larger* problem than that. William From jfbeam at gmail.com Mon Jan 17 21:38:45 2011 From: jfbeam at gmail.com (Ricky Beam) Date: Mon, 17 Jan 2011 22:38:45 -0500 Subject: Request Spamhaus contact In-Reply-To: <AANLkTi=UVDzicaPeajMy8Rk7eKjCa+kDgOrQ_8TGNSMU@mail.gmail.com> References: <AANLkTimG4vpRagh3P8Cke=v_vUuPC4e3XMA9jKny8188@mail.gmail.com> <4D34B364.6060105@trelane.net> <AANLkTiks93QZeuw5k3xvz4-krBtGcdfEvUOXrc1Hx0=1@mail.gmail.com> <AANLkTikm6xcaKA=+tYzrX-Q5EL-qCbvR0CJmEEKfR4KD@mail.gmail.com> <AANLkTinHKhkkOtHpy6=nUPv4onz3-Boh7o0oXBg5G+fM@mail.gmail.com> <alpine.LFD.2.00.1101180105170.26930@noc.prolocation.net> <AANLkTikRv=Hvr+5_N-axq6OH-spbvybtyPBu9x1s+zY6@mail.gmail.com> <alpine.LFD.2.00.1101180120230.19534@noc.prolocation.net> <AANLkTin0x=Pu7m5J2EL0pOWimEWht3h46rgTBS5Bj0OQ@mail.gmail.com> <0E75D743-0CF0-43A8-9316-5DA7191E1709@oitc.com> <AANLkTi==xwrZefBcqannLgDx1BdTiHmmOCa1qXOoMEFQ@mail.gmail.com> <0e3d01cbb6af$4404fa20$cc0eee60$@nl> <AANLkTi=UVDzicaPeajMy8Rk7eKjCa+kDgOrQ_8TGNSMU@mail.gmail.com> Message-ID: <op.vphi2vrytfhldh@rbeam.xactional.com> On Mon, 17 Jan 2011 20:31:58 -0500, Jeffrey Lyon <jeffrey.lyon at blacklotus.net> wrote: > I've already stated that i'm having the server powered down. What else > do you people want? That's a fine first step, but then tomorrow when everyone has forgotten about all this, that server gets turned back on and the trash continues... On Mon, 17 Jan 2011 20:48:28 -0500, Jeffrey Lyon <jeffrey.lyon at blacklotus.net> wrote: > I've listened to and acted on every single Spamhaus listing since the > founding of this company and all of a sudden in late 2010 a couple of > pharmacy spammers pick up a dedicated server, thus warranting full > blown witch trials on our company. If that were true, then we clearly would not have had this mess on NANOG. SBL lists are easy to find. And just as easy to understand. And yet we have any entire day of this BS because you wouldn't pull the plug on a customer. (as I read the thread, it's because you couldn't be bothered to track down what customer(s) were at the root of it???) I'd call it a comedy of errors, but nothing about it is funny. --Ricky PS: For the record, the only people I've ever seen publicly complain about an SBL listing *ARE SPAMMERS*. You've done nothing today that changes that perception. From jcdill.lists at gmail.com Mon Jan 17 22:59:20 2011 From: jcdill.lists at gmail.com (JC Dill) Date: Mon, 17 Jan 2011 20:59:20 -0800 Subject: Request Spamhaus contact In-Reply-To: <AANLkTikTogMoo5ebrx+vPyDU+9jyq0boTOR+Wks4xHFE@mail.gmail.com> References: <AANLkTimG4vpRagh3P8Cke=v_vUuPC4e3XMA9jKny8188@mail.gmail.com> <4D34B364.6060105@trelane.net> <AANLkTiks93QZeuw5k3xvz4-krBtGcdfEvUOXrc1Hx0=1@mail.gmail.com> <AANLkTikm6xcaKA=+tYzrX-Q5EL-qCbvR0CJmEEKfR4KD@mail.gmail.com> <AANLkTinHKhkkOtHpy6=nUPv4onz3-Boh7o0oXBg5G+fM@mail.gmail.com> <alpine.LFD.2.00.1101180105170.26930@noc.prolocation.net> <AANLkTikRv=Hvr+5_N-axq6OH-spbvybtyPBu9x1s+zY6@mail.gmail.com> <alpine.LFD.2.00.1101180120230.19534@noc.prolocation.net> <AANLkTin0x=Pu7m5J2EL0pOWimEWht3h46rgTBS5Bj0OQ@mail.gmail.com> <alpine.LFD.2.00.1101180137010.27337@noc.prolocation.net> <AANLkTinhN9e7OqJ1i0LwsaeqQDJoLOf3PTHtDMb5=fMJ@mail.gmail.com> <8938753C-2B8D-496E-B5C7-9FE09A18C339@hubris.net> <AANLkTikTogMoo5ebrx+vPyDU+9jyq0boTOR+Wks4xHFE@mail.gmail.com> Message-ID: <4D351E28.50101@gmail.com> On 17/01/11 5:40 PM, Jeffrey Lyon wrote: > I'm not a spammer. I'm an ISP asking to be removed from Spamhaus for > having fixed the SBL listings set in the last< 72 hours. I'm not > exactally ROKSO material. > > Jeff > > On Mon, Jan 17, 2011 at 8:07 PM, Chris Owen<owenc at hubris.net> wrote: >> On Jan 17, 2011, at 6:42 PM, Jeffrey Lyon wrote: >> >>> I fat fingered the netmask, try now. >> I've asked privately but would it really be too much to take this off NANOG? >> >> Spammer complaining he is on a RBL is hardly relevant. >> >> Chris Sigh. First, please quit with the top posting Jeff. (I refer you to the NANOG FAQ for elaboration on why this is not an acceptable format for posting to this list.) Second, this entire thread IS OFF TOPIC for NANOG. Which you would know if you had bothered to read the FAQ before posting. There are many discussion forums for talking about spam and RBLs, and NANOG is not one of them. http://www.nanog.org/mailinglist/listfaqs/otherlists.php Third, you are not doing your reputation any good with this thread. Your entire tone is one of "I'm so important that the rules don't apply to me. They need to stop blocking me right now. Even when I'm wrong (when spammer's sites are still active because I don't know how to properly null-route their IPs, or shut down their server, or I fat fingered the "fix" and didn't bother to double check that it's really blocked now. They still need to stop blocking me Right Now." You may not be aware that this list is publicly archived on the web in several different locations. Anyone who bothers to google your name (e.g. a future employer) is likely to discover this thread and be less than impressed. Any future posts are only going to add to the problem, not help fix it. jc From jeffrey.lyon at blacklotus.net Tue Jan 18 02:08:57 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Tue, 18 Jan 2011 03:08:57 -0500 Subject: Request Spamhaus contact In-Reply-To: <4D351E28.50101@gmail.com> References: <AANLkTimG4vpRagh3P8Cke=v_vUuPC4e3XMA9jKny8188@mail.gmail.com> <4D34B364.6060105@trelane.net> <AANLkTiks93QZeuw5k3xvz4-krBtGcdfEvUOXrc1Hx0=1@mail.gmail.com> <AANLkTikm6xcaKA=+tYzrX-Q5EL-qCbvR0CJmEEKfR4KD@mail.gmail.com> <AANLkTinHKhkkOtHpy6=nUPv4onz3-Boh7o0oXBg5G+fM@mail.gmail.com> <alpine.LFD.2.00.1101180105170.26930@noc.prolocation.net> <AANLkTikRv=Hvr+5_N-axq6OH-spbvybtyPBu9x1s+zY6@mail.gmail.com> <alpine.LFD.2.00.1101180120230.19534@noc.prolocation.net> <AANLkTin0x=Pu7m5J2EL0pOWimEWht3h46rgTBS5Bj0OQ@mail.gmail.com> <alpine.LFD.2.00.1101180137010.27337@noc.prolocation.net> <AANLkTinhN9e7OqJ1i0LwsaeqQDJoLOf3PTHtDMb5=fMJ@mail.gmail.com> <8938753C-2B8D-496E-B5C7-9FE09A18C339@hubris.net> <AANLkTikTogMoo5ebrx+vPyDU+9jyq0boTOR+Wks4xHFE@mail.gmail.com> <4D351E28.50101@gmail.com> Message-ID: <AANLkTim4yOTCGhcQbM+8zE67zs3dUGOk2B-ji1KQYVJ=@mail.gmail.com> On Mon, Jan 17, 2011 at 11:59 PM, JC Dill <jcdill.lists at gmail.com> wrote: > > > On 17/01/11 5:40 PM, Jeffrey Lyon wrote: >> >> I'm not a spammer. I'm an ISP asking to be removed from Spamhaus for >> having fixed the SBL listings set in the last< ?72 hours. I'm not >> exactally ROKSO material. >> >> Jeff >> >> On Mon, Jan 17, 2011 at 8:07 PM, Chris Owen<owenc at hubris.net> ?wrote: >>> >>> On Jan 17, 2011, at 6:42 PM, Jeffrey Lyon wrote: >>> >>>> I fat fingered the netmask, try now. >>> >>> I've asked privately but would it really be too much to take this off >>> NANOG? >>> >>> Spammer complaining he is on a RBL is hardly relevant. >>> >>> Chris > > Sigh. > > First, please quit with the top posting Jeff. ?(I refer you to the NANOG FAQ > for elaboration on why this is not an acceptable format for posting to this > list.) > > Second, this entire thread IS OFF TOPIC for NANOG. ?Which you would know if > you had bothered to read the FAQ before posting. ?There are many discussion > forums for talking about spam and RBLs, and NANOG is not one of them. > > http://www.nanog.org/mailinglist/listfaqs/otherlists.php > > Third, you are not doing your reputation any good with this thread. ?Your > entire tone is one of "I'm so important that the rules don't apply to me. > ?They need to stop blocking me right now. ?Even when I'm wrong (when > spammer's sites are still active because I don't know how to properly > null-route their IPs, or shut down their server, or I fat fingered the "fix" > and didn't bother to double check that it's really blocked now. ?They still > need to stop blocking me Right Now." ?You may not be aware that this list is > publicly archived on the web in several different locations. ?Anyone who > bothers to google your name (e.g. a future employer) is likely to discover > this thread and be less than impressed. ?Any future posts are only going to > add to the problem, not help fix it. > > jc > > > JC, It was blocked and I did verify it. A very small amount of our traffic comes in on PCCW and *they* were not honoring a tag that they've contractually agreed to honor. I can understand why it may be fun to make this look like a product of my own incompetence, and perhaps it is something I would have noticed if I wasn't busy responding to flames. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From tvhawaii at shaka.com Tue Jan 18 03:00:25 2011 From: tvhawaii at shaka.com (Michael Painter) Date: Mon, 17 Jan 2011 23:00:25 -1000 Subject: Request Spamhaus contact References: <AANLkTimG4vpRagh3P8Cke=v_vUuPC4e3XMA9jKny8188@mail.gmail.com><4D34B364.6060105@trelane.net><AANLkTiks93QZeuw5k3xvz4-krBtGcdfEvUOXrc1Hx0=1@mail.gmail.com><AANLkTikm6xcaKA=+tYzrX-Q5EL-qCbvR0CJmEEKfR4KD@mail.gmail.com><AANLkTinHKhkkOtHpy6=nUPv4onz3-Boh7o0oXBg5G+fM@mail.gmail.com><alpine.LFD.2.00.1101180105170.26930@noc.prolocation.net><AANLkTikRv=Hvr+5_N-axq6OH-spbvybtyPBu9x1s+zY6@mail.gmail.com><alpine.LFD.2.00.1101180120230.19534@noc.prolocation.net><AANLkTin0x=Pu7m5J2EL0pOWimEWht3h46rgTBS5Bj0OQ@mail.gmail.com><alpine.LFD.2.00.1101180137010.27337@noc.prolocation.net><AANLkTinhN9e7OqJ1i0LwsaeqQDJoLOf3PTHtDMb5=fMJ@mail.gmail.com><8938753C-2B8D-496E-B5C7-9FE09A18C339@hubris.net><AANLkTikTogMoo5ebrx+vPyDU+9jyq0boTOR+Wks4xHFE@mail.gmail.com><4D351E28.50101@gmail.com> <AANLkTim4yOTCGhcQbM+8zE67zs3dUGOk2B-ji1KQYVJ=@mail.gmail.com> Message-ID: <EB1191041F0045899800B834B64D85C3@DELL16> >> On 17/01/11 5:40 PM, Jeffrey Lyon wrote: >>> >>> I'm not a spammer. I'm an ISP asking to be removed from Spamhaus for >>> having fixed the SBL listings set in the last< 72 hours. I'm not >>> exactally ROKSO material. >>> >>> Jeff http://safebrowsing.clients.google.com/safebrowsing/diagnostic?site=AS:32421 Safe Browsing Diagnostic page for AS32421 (BLCC) What happened when Google visited sites hosted on this network? Of the 837 site(s) we tested on this network over the past 90 days, 13 site(s), including, for example, temagay.com/, inndir.com/, ivbux.com/, served content that resulted in malicious software being downloaded and installed without user consent. The last time Google tested a site on this network was on 2011-01-17, and the last time suspicious content was found was on 2011-01-17. Has this network hosted sites acting as intermediaries for further malware distribution? Over the past 90 days, this network has not hosted any sites that appeared to function as intermediaries for the infection of any other sites. Has this network hosted sites that have distributed malware? Yes, this network has hosted sites that have distributed malicious software in the past 90 days. We found 2 site(s), including, for example, aresdownload.net/, xvid.com/, that infected 74 other site(s), including, for example, just4cruisers.com/, filmindirsene.tk/, skootterini.com/. From nathan at atlasnetworks.us Tue Jan 18 03:25:42 2011 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Tue, 18 Jan 2011 09:25:42 +0000 Subject: Request Spamhaus contact In-Reply-To: <AANLkTim4yOTCGhcQbM+8zE67zs3dUGOk2B-ji1KQYVJ=@mail.gmail.com> References: <AANLkTimG4vpRagh3P8Cke=v_vUuPC4e3XMA9jKny8188@mail.gmail.com> <4D34B364.6060105@trelane.net> <AANLkTiks93QZeuw5k3xvz4-krBtGcdfEvUOXrc1Hx0=1@mail.gmail.com> <AANLkTikm6xcaKA=+tYzrX-Q5EL-qCbvR0CJmEEKfR4KD@mail.gmail.com> <AANLkTinHKhkkOtHpy6=nUPv4onz3-Boh7o0oXBg5G+fM@mail.gmail.com> <alpine.LFD.2.00.1101180105170.26930@noc.prolocation.net> <AANLkTikRv=Hvr+5_N-axq6OH-spbvybtyPBu9x1s+zY6@mail.gmail.com> <alpine.LFD.2.00.1101180120230.19534@noc.prolocation.net> <AANLkTin0x=Pu7m5J2EL0pOWimEWht3h46rgTBS5Bj0OQ@mail.gmail.com> <alpine.LFD.2.00.1101180137010.27337@noc.prolocation.net> <AANLkTinhN9e7OqJ1i0LwsaeqQDJoLOf3PTHtDMb5=fMJ@mail.gmail.com> <8938753C-2B8D-496E-B5C7-9FE09A18C339@hubris.net> <AANLkTikTogMoo5ebrx+vPyDU+9jyq0boTOR+Wks4xHFE@mail.gmail.com> <4D351E28.50101@gmail.com> <AANLkTim4yOTCGhcQbM+8zE67zs3dUGOk2B-ji1KQYVJ=@mail.gmail.com> Message-ID: <8C26A4FDAE599041A13EB499117D3C286B31CF3D@ex-mb-1.corp.atlasnetworks.us> > It was blocked and I did verify it. A very small amount of our traffic > comes in on PCCW and *they* were not honoring a tag that they've > contractually agreed to honor. I can understand why it may be fun to > make this look like a product of my own incompetence, and perhaps it > is something I would have noticed if I wasn't busy responding to > flames. It may be a good policy going forward to do your own null-routes. I realize that for a DDOS protection company, the ability to tag nullroutes upstream is handy, but you also need to nullroute the traffic on your own gear, or shut down the switch port. Something that is completely independent of another organization, regardless of their contractual obligations to you. If you were my employee, I would find the fact that you fat-fingered a nullroute to be highly concerning. I would recommend that in addition to changing the way you do nullroutes, you also implement a change control policy which screens commands for approval before making configuration changes upon which your public declarations, and your reputation as a decent operator, rely. Nathan Eisenberg From ken.gilmour at gmail.com Tue Jan 18 05:46:53 2011 From: ken.gilmour at gmail.com (Ken Gilmour) Date: Tue, 18 Jan 2011 12:46:53 +0100 Subject: Request Spamhaus contact In-Reply-To: <EB1191041F0045899800B834B64D85C3@DELL16> References: <AANLkTimG4vpRagh3P8Cke=v_vUuPC4e3XMA9jKny8188@mail.gmail.com> <4D34B364.6060105@trelane.net> <AANLkTiks93QZeuw5k3xvz4-krBtGcdfEvUOXrc1Hx0=1@mail.gmail.com> <AANLkTikm6xcaKA=+tYzrX-Q5EL-qCbvR0CJmEEKfR4KD@mail.gmail.com> <AANLkTinHKhkkOtHpy6=nUPv4onz3-Boh7o0oXBg5G+fM@mail.gmail.com> <alpine.LFD.2.00.1101180105170.26930@noc.prolocation.net> <AANLkTikRv=Hvr+5_N-axq6OH-spbvybtyPBu9x1s+zY6@mail.gmail.com> <alpine.LFD.2.00.1101180120230.19534@noc.prolocation.net> <AANLkTin0x=Pu7m5J2EL0pOWimEWht3h46rgTBS5Bj0OQ@mail.gmail.com> <alpine.LFD.2.00.1101180137010.27337@noc.prolocation.net> <AANLkTinhN9e7OqJ1i0LwsaeqQDJoLOf3PTHtDMb5=fMJ@mail.gmail.com> <8938753C-2B8D-496E-B5C7-9FE09A18C339@hubris.net> <AANLkTikTogMoo5ebrx+vPyDU+9jyq0boTOR+Wks4xHFE@mail.gmail.com> <4D351E28.50101@gmail.com> <AANLkTim4yOTCGhcQbM+8zE67zs3dUGOk2B-ji1KQYVJ=@mail.gmail.com> <EB1191041F0045899800B834B64D85C3@DELL16> Message-ID: <AANLkTin6K2L=8tcerRn=-x3NCvvMwB58j8VHaYDGA6dk@mail.gmail.com> On 18 January 2011 10:00, Michael Painter <tvhawaii at shaka.com> wrote: > >> http://safebrowsing.clients.google.com/safebrowsing/diagnostic?site=AS:32421 >> >> I'm completely neutral in all of this but to be fair to BL - Here's the well respected Level3's results: http://safebrowsing.clients.google.com/safebrowsing/diagnostic?site=AS:3356 (who also actually provide bandwidth for google) 231 malicious sites, 14 infection intermediaries and has hosted 29 sites that have infected 111 other sites. Then we have Global Crossing http://safebrowsing.clients.google.com/safebrowsing/diagnostic?site=AS:3549. Should we all stop using these ISPs because they have hosted some bad guys? Obviously they know about them because google has the information. Does this mean they don't have proper monitoring or control of their network? (FTR those are rhetorical questions) I used to work for a company that had some mailing lists that users explicitly and knowingly signed up for, and lazy people used to click the "Spam" button on AOL and other providers - either because it was right beside "delete" or because they were too lazy to click the unsubscribe link. As a result, Level 3 used to forward on the automated spam compaints to our abuse department and we would usually act on them by unsubscribing the person ourselves (although they usually tried to munge most of the complainants identifiable credentials from the forwarded emails). They were very responsive and demanded "respect" (in the sense that they don't like spammers), yet they are hosting hundreds of malicious sites. Had they shut us down due to a few spam complaints (which were never actually unsolicited) I have no doubt they would be immediately encountering severe legal action. Black Lotus are pretty much in the same boat but are in a bit of a worse situation since people rely on them for "protection" so they are more exposed to the transparency limelight. They provide clean pipe bandwidth for some sites but might not always know what is on those sites. Regards, Ken From simonw at zynet.net Tue Jan 18 06:10:00 2011 From: simonw at zynet.net (Simon Waters) Date: Tue, 18 Jan 2011 12:10:00 +0000 Subject: Request Spamhaus contact In-Reply-To: <AANLkTin6K2L=8tcerRn=-x3NCvvMwB58j8VHaYDGA6dk@mail.gmail.com> References: <AANLkTimG4vpRagh3P8Cke=v_vUuPC4e3XMA9jKny8188@mail.gmail.com> <EB1191041F0045899800B834B64D85C3@DELL16> <AANLkTin6K2L=8tcerRn=-x3NCvvMwB58j8VHaYDGA6dk@mail.gmail.com> Message-ID: <201101181210.00344.simonw@zynet.net> On Tuesday 18 January 2011 11:46:53 Ken Gilmour wrote: > > Obviously they know about them because google has the information. I'm not sure this is a reasonable deduction. From ken.gilmour at gmail.com Tue Jan 18 06:21:50 2011 From: ken.gilmour at gmail.com (Ken Gilmour) Date: Tue, 18 Jan 2011 13:21:50 +0100 Subject: Request Spamhaus contact In-Reply-To: <201101181210.00344.simonw@zynet.net> References: <AANLkTimG4vpRagh3P8Cke=v_vUuPC4e3XMA9jKny8188@mail.gmail.com> <EB1191041F0045899800B834B64D85C3@DELL16> <AANLkTin6K2L=8tcerRn=-x3NCvvMwB58j8VHaYDGA6dk@mail.gmail.com> <201101181210.00344.simonw@zynet.net> Message-ID: <AANLkTik_EUWJ4ugS9am0EMgxqLyjU1LFDfLpu=DndGOY@mail.gmail.com> On 18 January 2011 13:10, Simon Waters <simonw at zynet.net> wrote: > > Obviously they know about them because google has the information. > > I'm not sure this is a reasonable deduction. > > Correct - It is completely unreasonable. I was using it as an example in reference to a larger, well known provider since earlier someone had mentioned that obviously since google had this information that BL's monitoring was inadequate as they didn't know about it themselves. Google knows about lots of things that people in general probably don't know about themselves. FTR - I have no doubt that Level 3 have amazing monitoring and infrastructure, and think I understand why it might be hard to find 231 bad apples in a basket of over 292492. From jgreco at ns.sol.net Tue Jan 18 09:39:32 2011 From: jgreco at ns.sol.net (Joe Greco) Date: Tue, 18 Jan 2011 09:39:32 -0600 (CST) Subject: Request Spamhaus contact In-Reply-To: <20110117212738.08e230c1@petrie.gateway.2wire.net> Message-ID: <201101181539.p0IFdWlT060991@aurora.sol.net> > We don't *care* if you got this issue with Spamhaus resolved. You > turned it into a much *larger* problem than that. Really? Problem solved: % cat - >> sendmail-access From:jeffrey.lyon at gmail.com 550 Mail refused From:jeffrey.lyon at blacklotus.net 550 Mail refused Connect:199.59.160 550 Mail refused Connect:199.59.161 550 Mail refused Connect:199.59.162 550 Mail refused Connect:199.59.163 550 Mail refused Connect:199.59.164 550 Mail refused Connect:199.59.165 550 Mail refused Connect:199.59.166 550 Mail refused Connect:199.59.167 550 Mail refused Connect:208.64.120 550 Mail refused Connect:208.64.121 550 Mail refused Connect:208.64.122 550 Mail refused Connect:208.64.123 550 Mail refused Connect:208.64.124 550 Mail refused Connect:208.64.125 550 Mail refused Connect:208.64.126 550 Mail refused Connect:208.64.127 550 Mail refused ^D % sh update-mxers % Life simplification through automation / shell scripting. (Which reminds me, I really need a tool to add an ASN to the Sendmail access file automatically.) ... Oh, wait, you meant a problem for *Jeffrey.* Yes, that could be. ... 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 Thomas.Weible at flexoptix.net Tue Jan 18 09:56:36 2011 From: Thomas.Weible at flexoptix.net (Thomas Weible) Date: Tue, 18 Jan 2011 16:56:36 +0100 Subject: AW: Nexus 5000 with 4G FC module - initialization ? In-Reply-To: <C8064C97-180C-459C-851E-349D983FE158@medline.com> References: <C8064C97-180C-459C-851E-349D983FE158@medline.com> Message-ID: <B6C5ED365F33694B8E8D7D04314246A41A28C0@mimmi2.intranet.flexoptix.net> Steve Fischer <sfischer1967 at gmail.com> wrote: > If I'm not mistaken, there is an additional license needed to activate Fibre- > Channel services on the Nexus family of switches. Dantzig, Brian <bdantzig at medline.com> wrote: > You need to turn on fcoe support with the configuration command "feature > fcoe". You will also need the appropriate license for fabric services. But even > without the license you should be able to enter fc commands. They just > won't work until you add the license. Without the"feature fcoe", the > interface type won't even show up in command help. There are other > storage fabric related services that you may want to turn on with the feature > command as well. This did the trick. After enabling "feature FCOE" the ports show up! It might be important for some others. With the regular "show interface" the Nexus only show the Ethernet-ports. You have to do a "show interface brief" to see the FC-ports aswell. Anyways.. it is still a question for me if everybody wants to have FCoE when FC only is needed? Thanks for your fast help Thomas From nick at flhsi.com Tue Jan 18 11:34:51 2011 From: nick at flhsi.com (Nick Olsen) Date: Tue, 18 Jan 2011 12:34:51 -0500 Subject: Looking for fiber Message-ID: <1450b3c0$7ba01d08$7c55b40a$@com> We are looking for fiber in the Port St Lucie/Stuart area of Florida, Maybe as north as Fort Pierce. Anyone have, Or know who has fiber in this area? Feel free to hit me on or offlist. Thanks. Nick Olsen Network Operations (855) FLSPEED x106 From serge.devorop at gmail.com Tue Jan 18 11:42:29 2011 From: serge.devorop at gmail.com (Sergey Voropaev) Date: Tue, 18 Jan 2011 20:42:29 +0300 Subject: Software DNS hghi availability and load balancer solution Message-ID: <AANLkTimyQDGp9fBiuVE3FEhSJKo-8jzrXHUF+1+aYqpX@mail.gmail.com> Does any one know software sollutions (free is preferable) like as cisco GSS and F5 BIG-IP? The main point is that DNS-server (or dns server plugin) must be able to monitor server availability (for example by TCP connect) and from DNS-reply depends on it. I know that it is possible by BIND with set of script. But we are trying to find more usable solution with frendly interface. Thanks a lot. From jbates at brightok.net Tue Jan 18 12:31:32 2011 From: jbates at brightok.net (Jack Bates) Date: Tue, 18 Jan 2011 12:31:32 -0600 Subject: Software DNS hghi availability and load balancer solution In-Reply-To: <AANLkTimyQDGp9fBiuVE3FEhSJKo-8jzrXHUF+1+aYqpX@mail.gmail.com> References: <AANLkTimyQDGp9fBiuVE3FEhSJKo-8jzrXHUF+1+aYqpX@mail.gmail.com> Message-ID: <4D35DC84.8020508@brightok.net> On 1/18/2011 11:42 AM, Sergey Voropaev wrote: > I know that it is possible by BIND with set of script. But we are trying to > find more usable solution with frendly interface. > I think powerdns is more flexible in this regard. Not sure about a friendly interface, though. Jack From ayousuf0079 at gmail.com Tue Jan 18 12:32:03 2011 From: ayousuf0079 at gmail.com (Ahmed Yousuf) Date: Tue, 18 Jan 2011 18:32:03 -0000 Subject: Dual Homed BGP for failover Message-ID: <003001cbb73e$0106a860$0313f920$@gmail.com> Hi, I'm looking at a setup where we use BGP to announce PI space to two upstream ISPs. ISP A provides a 30Mb/s connection and ISP B provides a 10Mb/s. Originally the plan was to use ISP B's link as a backup and local pref traffic outbound via ISP A and pref inbound using AS prepend via ISP A. It has now been requested to be able to distribute traffic across both links rather than preference traffic to the higher speed link. We are going to be using Juniper SRX210s to do this. I have some questions: - Is this really a good idea, as the BGP process won't care what the utilisation of the links are and you will see situations where the lower speed link gets used even though the high speed link utilisation is 0? - If we are doing this, I don't want to take a full routing table, I would rather just take the ISPs routes and perhaps their connected customers. One ISP has said they will only provide full routing table or default. I really don't want to take a full table, is receiving default only going to be a problem for my setup? - Any advice on how to avoid situations where the low bandwidth link is being used even though there is 0 utilisation on the high bandwidth link? Thanks Ahmed From jack at crepinc.com Tue Jan 18 12:40:56 2011 From: jack at crepinc.com (Jack Carrozzo) Date: Tue, 18 Jan 2011 13:40:56 -0500 Subject: Dual Homed BGP for failover In-Reply-To: <003001cbb73e$0106a860$0313f920$@gmail.com> References: <003001cbb73e$0106a860$0313f920$@gmail.com> Message-ID: <AANLkTiktwmM=bhNzQADH60O+rJUKHE3hPztA8TodQRGQ@mail.gmail.com> You can just accept directly-connected peers from each network (or within 2 AS's, etc) then point a default at each one with different preferences. You can do with with two edges if you like also: iBGP between the edges, and push default into OSPF from both. WRT dynamic load balancing... generally if your network is large enough for two upstreams you'll have a pretty good distribution of flows so once you get the prefs and prepends setup the way you like, thing won't shift that rapidly. In my experience at least... -Jack Carrozzo On Tue, Jan 18, 2011 at 1:32 PM, Ahmed Yousuf <ayousuf0079 at gmail.com> wrote: > Hi, > > > > I'm looking at a setup where we use BGP to announce PI space to two > upstream > ISPs. ISP A provides a 30Mb/s connection and ISP B provides a 10Mb/s. > Originally the plan was to use ISP B's link as a backup and local pref > traffic outbound via ISP A and pref inbound using AS prepend via ISP A. > It > has now been requested to be able to distribute traffic across both links > rather than preference traffic to the higher speed link. We are going to > be > using Juniper SRX210s to do this. I have some questions: > > > > - Is this really a good idea, as the BGP process won't care what > the utilisation of the links are and you will see situations where the > lower > speed link gets used even though the high speed link utilisation is 0? > > > > - If we are doing this, I don't want to take a full routing table, > I would rather just take the ISPs routes and perhaps their connected > customers. One ISP has said they will only provide full routing table or > default. I really don't want to take a full table, is receiving default > only going to be a problem for my setup? > > > > - Any advice on how to avoid situations where the low bandwidth > link is being used even though there is 0 utilisation on the high bandwidth > link? > > > > Thanks > > > > Ahmed > > From bill at herrin.us Tue Jan 18 12:45:30 2011 From: bill at herrin.us (William Herrin) Date: Tue, 18 Jan 2011 13:45:30 -0500 Subject: Software DNS hghi availability and load balancer solution In-Reply-To: <AANLkTimyQDGp9fBiuVE3FEhSJKo-8jzrXHUF+1+aYqpX@mail.gmail.com> References: <AANLkTimyQDGp9fBiuVE3FEhSJKo-8jzrXHUF+1+aYqpX@mail.gmail.com> Message-ID: <AANLkTimnmc-wc8N1V+DzYq2WFuP-jQHPMJ3dqqUqA66L@mail.gmail.com> On Tue, Jan 18, 2011 at 12:42 PM, Sergey Voropaev <serge.devorop at gmail.com> wrote: > Does any one know software sollutions (free is preferable) like as cisco GSS > and F5 BIG-IP? The main point is that DNS-server (or dns server plugin) must > be able to monitor server availability (for example by TCP connect) and from > DNS-reply depends on it. Sergey, I have no suggestions that directly answer your question. I'd write a script against bind myself. But if you're trying to fail over a web server, you're walking into a nasty trap. "DNS pinning" obstructs web browsers from finding a server on an alternate IP address regardless of the DNS TTL. The core issue is that allowing a browser running javascript to connect to a server other than the one from which the script came is a gigantic security hole. Someone realized you could do that by changing the IP address the host name pointed to, so now there's a convoluted and not entirely standardized set of rules for when and whether the browser allows it. Net result is that in some cases a user's long-running browser will indefinitely ignore the change you made to the DNS. I've seen such things persist for months. For better or for worse, the way you -reliably- fail over a web server is with routing and middleboxes like a load balancer. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004 From nmaxpierson at gmail.com Tue Jan 18 12:54:34 2011 From: nmaxpierson at gmail.com (Max Pierson) Date: Tue, 18 Jan 2011 12:54:34 -0600 Subject: Dual Homed BGP for failover In-Reply-To: <003001cbb73e$0106a860$0313f920$@gmail.com> References: <003001cbb73e$0106a860$0313f920$@gmail.com> Message-ID: <AANLkTikXLqKpuQdbe232DKxMpmeRZ9Lo1XtVApK8J_o0@mail.gmail.com> You really limit yourself when you just take a default from a provider. If you take 2 default's (one from each provider) for whatever reason, once you change the local pref on one of them, it's all your traffic outbound or none. I always request a full table + default, so you can filter to best suit your needs. This way, you can just accept /8's and get some sort of balancing at least (even if you just say all even /8's pref'd on one gateway and all odd /8's from the other provider, etc). Of course this won't be symmetrical, but thats the nature eBGP on the internet. You'll have to watch it and adjust as needed so that you won't saturate your slower link. Max On Tue, Jan 18, 2011 at 12:32 PM, Ahmed Yousuf <ayousuf0079 at gmail.com>wrote: > Hi, > > > > I'm looking at a setup where we use BGP to announce PI space to two > upstream > ISPs. ISP A provides a 30Mb/s connection and ISP B provides a 10Mb/s. > Originally the plan was to use ISP B's link as a backup and local pref > traffic outbound via ISP A and pref inbound using AS prepend via ISP A. > It > has now been requested to be able to distribute traffic across both links > rather than preference traffic to the higher speed link. We are going to > be > using Juniper SRX210s to do this. I have some questions: > > > > - Is this really a good idea, as the BGP process won't care what > the utilisation of the links are and you will see situations where the > lower > speed link gets used even though the high speed link utilisation is 0? > > > > - If we are doing this, I don't want to take a full routing table, > I would rather just take the ISPs routes and perhaps their connected > customers. One ISP has said they will only provide full routing table or > default. I really don't want to take a full table, is receiving default > only going to be a problem for my setup? > > > > - Any advice on how to avoid situations where the low bandwidth > link is being used even though there is 0 utilisation on the high bandwidth > link? > > > > Thanks > > > > Ahmed > > From marco.schrieck at internetx.de Tue Jan 18 12:58:39 2011 From: marco.schrieck at internetx.de (InterNetX - Marco Schrieck) Date: Tue, 18 Jan 2011 19:58:39 +0100 Subject: Software DNS hghi availability and load balancer solution In-Reply-To: <4D35DC84.8020508@brightok.net> References: <AANLkTimyQDGp9fBiuVE3FEhSJKo-8jzrXHUF+1+aYqpX@mail.gmail.com> <4D35DC84.8020508@brightok.net> Message-ID: <4D35E2DF.8010205@internetx.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Am 18.01.11 19:31, schrieb Jack Bates: > On 1/18/2011 11:42 AM, Sergey Voropaev wrote: >> I know that it is possible by BIND with set of script. But we are >> trying to >> find more usable solution with frendly interface. >> > > I think powerdns is more flexible in this regard. Not sure about a > friendly interface, though. > > Jack > for powerdns exists also an user interface poweradmin. Marco -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNNeLeAAoJEN9yMHEBd2HnQ4MIAKJNX1jKpU+ps3GpXee6IUcH 1TlPlfGHVFK89P/y3LFBC85QYM/71aRW/KlmxehpwluOUDl0BzqqElweqQOT9+nz 8nDQVYRpLQQ1OogAVqKoBE4Ij2mtNzTd2ulaATxnWuwPA23lnUxzWMFo2xjqE+30 poUhKLWQIcYcoW2zgjizN6n+llylOLfcrTx/enCMxiVXr/vBIWFue+AiTanGPBGZ W0lAH0Fr9wx40Ys4ls4cykQ23RUEvrSS5Gj3s5u6m6XJfn/AspE74afCi7FVETgI BBAMnkpqJYcRwdfhw9zhU6cTZM3pzHdJIS77lFGKYGNUZ3FzjsEo7tIG3sEn8Ls= =vwpM -----END PGP SIGNATURE----- From gbonser at seven.com Tue Jan 18 12:59:55 2011 From: gbonser at seven.com (George Bonser) Date: Tue, 18 Jan 2011 10:59:55 -0800 Subject: Dual Homed BGP for failover In-Reply-To: <003001cbb73e$0106a860$0313f920$@gmail.com> References: <003001cbb73e$0106a860$0313f920$@gmail.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC1341C@RWC-EX1.corp.seven.com> > From: Ahmed Yousuf > Sent: Tuesday, January 18, 2011 10:32 AM > To: nanog at nanog.org > Subject: Dual Homed BGP for failover > > > > - Is this really a good idea, as the BGP process won't care > what > the utilisation of the links are and you will see situations where the > lower > speed link gets used even though the high speed link utilisation is 0? It is possible. But one thing, and I know it is a semantics nit but it is really important. There is no difference in the "speed" of the links. There is a difference in the capacity of the two but the traffic flows at the same "speed" across both. That said, have you actually tried seeing what the "natural" breakdown of the traffic is? Without any AS prepend or local pref adjustment, what is the natural ratio of traffic on the two links? Generally different ISPs have different connectivity and some destinations will be favored via one path and others via the other path. It might be useful to determine how BGP naturally routes things first and then you can get an idea of what needs adjusting. > > > - If we are doing this, I don't want to take a full routing > table, > I would rather just take the ISPs routes and perhaps their connected > customers. One ISP has said they will only provide full routing table > or > default. I really don't want to take a full table, is receiving > default > only going to be a problem for my setup? Interesting. Most ISPs offer "default", "full", or "customer routes". You can take a full table but simply filter out any that aren't from your ISPs ASN or within one hop of it and only install the routes that meet those criteria. In addition to using AS prepending, your providers might offer communities that allow you to control redistribution of your routing information to their peers. You might want to tell the ISP on the smaller link not to announce your routes to a major peer. That major peer will now find its path to you via the larger pipe. > > > - Any advice on how to avoid situations where the low > bandwidth > link is being used even though there is 0 utilisation on the high > bandwidth > link? If that happens, it would mean that the world does not see your path via the high bandwidth pipe as being an attractive path. As mentioned above, you might be able to append communities to your routes to the lower bandwidth ISP that control how they redistribute your routes. One example might be something like "don't redistribute my routes if you see them coming from another source" in which case that ISP only redistributes your routes when they don't see the announcement via the high bandwidth provider and effectively acts as a backup outside of their own AS but you would still receive traffic originated within their AS over the low bandwidth connection. > Ahmed G From bill at herrin.us Tue Jan 18 13:00:30 2011 From: bill at herrin.us (William Herrin) Date: Tue, 18 Jan 2011 14:00:30 -0500 Subject: Dual Homed BGP for failover In-Reply-To: <003001cbb73e$0106a860$0313f920$@gmail.com> References: <003001cbb73e$0106a860$0313f920$@gmail.com> Message-ID: <AANLkTimF=uTuuPPhE7ouuw8gOMK7qq7QhN18zP_prinG@mail.gmail.com> On Tue, Jan 18, 2011 at 1:32 PM, Ahmed Yousuf <ayousuf0079 at gmail.com> wrote: > ?It > has now been requested to be able to distribute traffic across both links > rather than preference traffic to the higher speed link. > - ? ? ? ? ?Is this really a good idea, as the BGP process won't care what > the utilisation of the links are and you will see situations where the lower > speed link gets used even though the high speed link utilisation is 0? Hi Ahmed, This really isn't an either/or situation. You can prefer the higher speed link without excluding the lower speed link. One common way to do this (there are better ones but this one is easy) is to prepend the AS path you send and receive on the lower speed link so that it's longer. > - ? ? ? ? ?If we are doing this, I don't want to take a full routing table, > I would rather just take the ISPs routes and perhaps their connected > customers. ?One ISP has said they will only provide full routing table or > default. ?I really don't want to take a full table, is receiving default > only going to be a problem for my setup? IMO, that would be a mistake. Taking significantly less than a full table severely limits your options for balancing traffic between the links. > - ? ? ? ? ?Any advice on how to avoid situations where the low bandwidth > link is being used even though there is 0 utilisation on the high bandwidth > link? Any particular communication is either going to go through one link or the other. I'm generalizing here, ignoring some subtleties, but if packets between two particular hosts have picked the low speed link, they will take that one instead of the high speed link. So in a sense it isn't possible to prevent that situation. However, you can adjust the preferences for one path versus the other so that you're not leaving either circuit underused overall and the disparity between your circuits (30 and 10) is not enough to cause major performance issues in and of itself. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004 From rhys at rhavenindustrys.com Tue Jan 18 13:07:57 2011 From: rhys at rhavenindustrys.com (Rhys Rhaven) Date: Tue, 18 Jan 2011 13:07:57 -0600 Subject: Software DNS hghi availability and load balancer solution In-Reply-To: <AANLkTimnmc-wc8N1V+DzYq2WFuP-jQHPMJ3dqqUqA66L@mail.gmail.com> References: <AANLkTimyQDGp9fBiuVE3FEhSJKo-8jzrXHUF+1+aYqpX@mail.gmail.com> <AANLkTimnmc-wc8N1V+DzYq2WFuP-jQHPMJ3dqqUqA66L@mail.gmail.com> Message-ID: <4D35E50D.5060905@rhavenindustrys.com> Having hit these issues myself, I heavily recommend a real frontend proxy like nginx or varnish. On 01/18/2011 12:45 PM, William Herrin wrote: > On Tue, Jan 18, 2011 at 12:42 PM, Sergey Voropaev > <serge.devorop at gmail.com> wrote: >> Does any one know software sollutions (free is preferable) like as cisco GSS >> and F5 BIG-IP? The main point is that DNS-server (or dns server plugin) must >> be able to monitor server availability (for example by TCP connect) and from >> DNS-reply depends on it. > Sergey, > > I have no suggestions that directly answer your question. I'd write a > script against bind myself. But if you're trying to fail over a web > server, you're walking into a nasty trap. > > "DNS pinning" obstructs web browsers from finding a server on an > alternate IP address regardless of the DNS TTL. The core issue is that > allowing a browser running javascript to connect to a server other > than the one from which the script came is a gigantic security hole. > Someone realized you could do that by changing the IP address the host > name pointed to, so now there's a convoluted and not entirely > standardized set of rules for when and whether the browser allows it. > > Net result is that in some cases a user's long-running browser will > indefinitely ignore the change you made to the DNS. I've seen such > things persist for months. > > For better or for worse, the way you -reliably- fail over a web server > is with routing and middleboxes like a load balancer. > > Regards, > Bill Herrin > > From brwatters at absfoc.com Tue Jan 18 13:12:12 2011 From: brwatters at absfoc.com (Brian R. Watters) Date: Tue, 18 Jan 2011 11:12:12 -0800 (PST) Subject: Auto ACL blocker Message-ID: <29286818.215.1295377932987.JavaMail.root@mail.absfoc.com> We are looking for the following solution. Honey pot that collects attacks against SSH/FTP and so on Said attacks are then sent to a master ACL on a edge Cisco router to block all traffic from these offenders .. Of course we would require a master whitelist as well as to not be blocked from our own networks. Any current solutions or ideas ?? -- BRW From dharmachris at gmail.com Tue Jan 18 13:12:18 2011 From: dharmachris at gmail.com (Christopher Hunt) Date: Tue, 18 Jan 2011 11:12:18 -0800 Subject: Software DNS hghi availability and load balancer solution Message-ID: <4D35E612.1010505@gmail.com> >Message: 7 >Date: Tue, 18 Jan 2011 12:31:32 -0600 >From: Jack Bates <jbates at brightok.net> >Subject: Re: Software DNS hghi availability and load balancer solution >To: Sergey Voropaev <serge.devorop at gmail.com> >Cc: NANOG list <nanog at nanog.org> >Message-ID: <4D35DC84.8020508 at brightok.net> >Content-Type: text/plain; charset=ISO-8859-1; format=flowed > >On 1/18/2011 11:42 AM, Sergey Voropaev wrote: >> I know that it is possible by BIND with set of script. But we are trying to >> find more usable solution with frendly interface. > > >I think powerdns is more flexible in this regard. Not sure about a >friendly interface, though. > > >Jack > > I find Poweradmin quite usable. See https://www.poweradmin.org/trac/ for details. -Christopher Hunt From jbates at brightok.net Tue Jan 18 13:12:18 2011 From: jbates at brightok.net (Jack Bates) Date: Tue, 18 Jan 2011 13:12:18 -0600 Subject: Dual Homed BGP for failover In-Reply-To: <AANLkTimF=uTuuPPhE7ouuw8gOMK7qq7QhN18zP_prinG@mail.gmail.com> References: <003001cbb73e$0106a860$0313f920$@gmail.com> <AANLkTimF=uTuuPPhE7ouuw8gOMK7qq7QhN18zP_prinG@mail.gmail.com> Message-ID: <4D35E612.6010200@brightok.net> On 1/18/2011 1:00 PM, William Herrin wrote: > IMO, that would be a mistake. Taking significantly less than a full > table severely limits your options for balancing traffic between the > links. > It should also be noted that taking a full table, doesn't mean you have to use the full table. Apply filters to smaller routes or long ASPATHs that you don't want, and then assign preferences, communities, prepends, etc as necessary for the routes you actually accept. This means your sync time is longer and you'll have more updates, but it will still keep the local routing table much lower. Jack From Ruben.Guerra at arrisi.com Tue Jan 18 13:28:20 2011 From: Ruben.Guerra at arrisi.com (Guerra, Ruben) Date: Tue, 18 Jan 2011 13:28:20 -0600 Subject: Auto ACL blocker In-Reply-To: <29286818.215.1295377932987.JavaMail.root@mail.absfoc.com> References: <29286818.215.1295377932987.JavaMail.root@mail.absfoc.com> Message-ID: <8BC9AA1D1BA4494F83F8205415225CE826171BBF6B@CHIEXMAIL1.ARRS.ARRISI.COM> Dionaea (nephentes successor) and Kippo (ssh honeypot) are a good start for the honeypot side. http://carnivore.it/ http://dionaea.carnivore.it/ http://code.google.com/p/kippo/ Watching the tty logs in kippo is great entertainment. Perfect way to collect the skiddies tools. As far as the automation of ACLs if you find a script out in the wild please share. I do know of the following SNORT to Cisco PIX perl script. Hope this helps. http://www.chaotic.org/guardian/ http://www.chaotic.org/guardian/scripts/pix-block.pl Regards, Ruben Guerra -----Original Message----- From: Brian R. Watters [mailto:brwatters at absfoc.com] Sent: Tuesday, January 18, 2011 1:12 PM To: nanog at nanog.org Subject: Auto ACL blocker We are looking for the following solution. Honey pot that collects attacks against SSH/FTP and so on Said attacks are then sent to a master ACL on a edge Cisco router to block all traffic from these offenders .. Of course we would require a master whitelist as well as to not be blocked from our own networks. Any current solutions or ideas ?? -- BRW From rdobbins at arbor.net Tue Jan 18 13:29:42 2011 From: rdobbins at arbor.net (Roland Dobbins) Date: Tue, 18 Jan 2011 13:29:42 -0600 Subject: Auto ACL blocker In-Reply-To: <29286818.215.1295377932987.JavaMail.root@mail.absfoc.com> References: <29286818.215.1295377932987.JavaMail.root@mail.absfoc.com> Message-ID: <53D48146-38C6-4A70-923C-9C6974E2C7AA@arbor.net> On Jan 18, 2011, at 1:12 PM, Brian R. Watters wrote: > Any current solutions or ideas ?? This sort of thing can be gamed by attackers to cause DoS on your network/for your users/for others trying to access resources on your network. It's a Bad Idea. Set up S/RTBH and do it by hand. ------------------------------------------------------------------------ Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com> Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay From Greg.Whynott at oicr.on.ca Tue Jan 18 13:31:10 2011 From: Greg.Whynott at oicr.on.ca (Greg Whynott) Date: Tue, 18 Jan 2011 14:31:10 -0500 Subject: Auto ACL blocker In-Reply-To: <29286818.215.1295377932987.JavaMail.root@mail.absfoc.com> References: <29286818.215.1295377932987.JavaMail.root@mail.absfoc.com> Message-ID: <71A7E2AB-2C21-491C-97E8-C03D54E0C4E0@oicr.on.ca> send/expect? On Jan 18, 2011, at 2:12 PM, Brian R. Watters wrote: > We are looking for the following solution. > > Honey pot that collects attacks against SSH/FTP and so on > > Said attacks are then sent to a master ACL on a edge Cisco router to block all traffic from these offenders .. > > Of course we would require a master whitelist as well as to not be blocked from our own networks. > > Any current solutions or ideas ?? > > -- > > BRW -- This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization. From lesmith at ecsis.net Tue Jan 18 13:31:30 2011 From: lesmith at ecsis.net (Larry Smith) Date: Tue, 18 Jan 2011 13:31:30 -0600 Subject: Auto ACL blocker In-Reply-To: <29286818.215.1295377932987.JavaMail.root@mail.absfoc.com> References: <29286818.215.1295377932987.JavaMail.root@mail.absfoc.com> Message-ID: <201101181331.31022.lesmith@ecsis.net> On Tue January 18 2011 13:12, Brian R. Watters wrote: > We are looking for the following solution. > > Honey pot that collects attacks against SSH/FTP and so on > > Said attacks are then sent to a master ACL on a edge Cisco router to block > all traffic from these offenders .. > > Of course we would require a master whitelist as well as to not be blocked > from our own networks. > > Any current solutions or ideas ?? Private BGP session with Zebra or Quagga on a linux box adding the selected IP to a null route. -- Larry Smith lesmith at ecsis.net From tmagill at providecommerce.com Tue Jan 18 13:32:01 2011 From: tmagill at providecommerce.com (Thomas Magill) Date: Tue, 18 Jan 2011 19:32:01 +0000 Subject: Auto ACL blocker In-Reply-To: <29286818.215.1295377932987.JavaMail.root@mail.absfoc.com> References: <29286818.215.1295377932987.JavaMail.root@mail.absfoc.com> Message-ID: <A1B9BAEA8FE39847BCD6C473E894B595027A47E2@SDEXMB02.Proflowers.com> I would consider doing it through BGP via quagga or such. Nullrouting with BGP is much cleaner than ACLs as your config stays static and only your routing table changes. I also imagine due to existing BGP blacklisting methods, that much of the work is already done and all you need is to get the honeypot to export the right format. -----Original Message----- From: Brian R. Watters [mailto:brwatters at absfoc.com] Sent: Tuesday, January 18, 2011 11:12 AM To: nanog at nanog.org Subject: Auto ACL blocker We are looking for the following solution. Honey pot that collects attacks against SSH/FTP and so on Said attacks are then sent to a master ACL on a edge Cisco router to block all traffic from these offenders .. Of course we would require a master whitelist as well as to not be blocked from our own networks. Any current solutions or ideas ?? -- BRW From drais at icantclick.org Tue Jan 18 13:37:57 2011 From: drais at icantclick.org (david raistrick) Date: Tue, 18 Jan 2011 14:37:57 -0500 (EST) Subject: Software DNS hghi availability and load balancer solution In-Reply-To: <AANLkTimnmc-wc8N1V+DzYq2WFuP-jQHPMJ3dqqUqA66L@mail.gmail.com> References: <AANLkTimyQDGp9fBiuVE3FEhSJKo-8jzrXHUF+1+aYqpX@mail.gmail.com> <AANLkTimnmc-wc8N1V+DzYq2WFuP-jQHPMJ3dqqUqA66L@mail.gmail.com> Message-ID: <alpine.BSF.2.00.1101181434580.46939@murf.icantclick.org> On Tue, 18 Jan 2011, William Herrin wrote: > Net result is that in some cases a user's long-running browser will > indefinitely ignore the change you made to the DNS. I've seen such > things persist for months. Do you have any recent evidence to support this? The what-browsers-do-with-what world changes daily... and my understanding is that a lot of these things that used to be problems have been changed. > For better or for worse, the way you -reliably- fail over a web server > is with routing and middleboxes like a load balancer. Alas, sometimes that's just not possible - try doing that @ EC2, for example (which is why I've recently been on the hunt for GSLB solutions that don't involve appliances...). -- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html From drais at icantclick.org Tue Jan 18 13:42:57 2011 From: drais at icantclick.org (david raistrick) Date: Tue, 18 Jan 2011 14:42:57 -0500 (EST) Subject: Software DNS hghi availability and load balancer solution In-Reply-To: <4D35E50D.5060905@rhavenindustrys.com> References: <AANLkTimyQDGp9fBiuVE3FEhSJKo-8jzrXHUF+1+aYqpX@mail.gmail.com> <AANLkTimnmc-wc8N1V+DzYq2WFuP-jQHPMJ3dqqUqA66L@mail.gmail.com> <4D35E50D.5060905@rhavenindustrys.com> Message-ID: <alpine.BSF.2.00.1101181438200.46939@murf.icantclick.org> On Tue, 18 Jan 2011, Rhys Rhaven wrote: > Having hit these issues myself, I heavily recommend a real frontend > proxy like nginx or varnish. A frontend proxy (nginx, varnish, haproxy, or anything else) doesnt give you HA any more than any other loadbalancer solution does. You need a way to send traffic to another frontend server when the primary frontend server fails, or is overloaded, transparently. The tools we have available these days to do this are VRRP-like solutions (which all of the appliances use) that use multicast, some amount of NAT and routing magic (which I've often not seen done sanely), or DNS solutions (better known as GSLB) that dynamicly change the DNS responses depending on conditions (which could be source location, or could be server availability, or whatever). Normally, VRRP would be the way to go. But these days multicast isn't supported everywhere (major example - Amazon EC2), leaving DNS... -- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html From brandon.kim at brandontek.com Tue Jan 18 13:57:19 2011 From: brandon.kim at brandontek.com (Brandon Kim) Date: Tue, 18 Jan 2011 14:57:19 -0500 Subject: Dual Homed BGP for failover In-Reply-To: <4D35E612.6010200@brightok.net> References: <003001cbb73e$0106a860$0313f920$@gmail.com>, <AANLkTimF=uTuuPPhE7ouuw8gOMK7qq7QhN18zP_prinG@mail.gmail.com>, <4D35E612.6010200@brightok.net> Message-ID: <BLU158-w48D8FEABCAD84C7FE4896ADCF70@phx.gbl> Someone should advise him that if he wants to take in a full BGP routing table that he makes sure his router can handle it! I would hate for him to open the floodgates and his production router shuts down. LOL.... > Date: Tue, 18 Jan 2011 13:12:18 -0600 > From: jbates at brightok.net > To: bill at herrin.us > Subject: Re: Dual Homed BGP for failover > CC: ayousuf0079 at gmail.com; nanog at nanog.org > > > > On 1/18/2011 1:00 PM, William Herrin wrote: > > IMO, that would be a mistake. Taking significantly less than a full > > table severely limits your options for balancing traffic between the > > links. > > > > It should also be noted that taking a full table, doesn't mean you have > to use the full table. Apply filters to smaller routes or long ASPATHs > that you don't want, and then assign preferences, communities, prepends, > etc as necessary for the routes you actually accept. > > This means your sync time is longer and you'll have more updates, but it > will still keep the local routing table much lower. > > > Jack > From rbonica at juniper.net Tue Jan 18 13:55:28 2011 From: rbonica at juniper.net (Ronald Bonica) Date: Tue, 18 Jan 2011 14:55:28 -0500 Subject: Auto ACL blocker In-Reply-To: <29286818.215.1295377932987.JavaMail.root@mail.absfoc.com> References: <29286818.215.1295377932987.JavaMail.root@mail.absfoc.com> Message-ID: <13205C286662DE4387D9AF3AC30EF456B040CE78A4@EMBX01-WF.jnpr.net> Brian, Have you thought about what a bad guy might do if he knew that you had such a policy deployed? Is there a way that the bad guy might turn the policy against you? Ron > -----Original Message----- > From: Brian R. Watters [mailto:brwatters at absfoc.com] > Sent: Tuesday, January 18, 2011 2:12 PM > To: nanog at nanog.org > Subject: Auto ACL blocker > > We are looking for the following solution. > > Honey pot that collects attacks against SSH/FTP and so on > > Said attacks are then sent to a master ACL on a edge Cisco router to > block all traffic from these offenders .. > > Of course we would require a master whitelist as well as to not be > blocked from our own networks. > > Any current solutions or ideas ?? > > -- > > BRW From brwatters at absfoc.com Tue Jan 18 14:01:27 2011 From: brwatters at absfoc.com (Brian R. Watters) Date: Tue, 18 Jan 2011 12:01:27 -0800 (PST) Subject: Auto ACL blocker In-Reply-To: <13205C286662DE4387D9AF3AC30EF456B040CE78A4@EMBX01-WF.jnpr.net> Message-ID: <17456042.244.1295380887539.JavaMail.root@mail.absfoc.com> Ron, I am sure any solution given enough time could be used against you, However my hope was that a whitelist could help in that regard however I know your correct. ----- Original Message ----- From: "Ronald Bonica" <rbonica at juniper.net> To: "Brian R. Watters" <brwatters at absfoc.com>, nanog at nanog.org Sent: Tuesday, January 18, 2011 11:55:28 AM Subject: RE: Auto ACL blocker Brian, Have you thought about what a bad guy might do if he knew that you had such a policy deployed? Is there a way that the bad guy might turn the policy against you? Ron > -----Original Message----- > From: Brian R. Watters [mailto:brwatters at absfoc.com] > Sent: Tuesday, January 18, 2011 2:12 PM > To: nanog at nanog.org > Subject: Auto ACL blocker > > We are looking for the following solution. > > Honey pot that collects attacks against SSH/FTP and so on > > Said attacks are then sent to a master ACL on a edge Cisco router to > block all traffic from these offenders .. > > Of course we would require a master whitelist as well as to not be > blocked from our own networks. > > Any current solutions or ideas ?? > > -- > > BRW -- Brian R. Watters Director American Broadband Family of Companies 5718 East Shields Ave Fresno, CA. 93727 brwatters at absfoc.com http://www.americanbroadbandservice.com tel: 559-420-0205 fax:559-272-5266 toll free: 866-827-4638 ABS offers T-1's starting at $289 in over 450 cities. Is your city on the list? Click here to find out. This message and any attachment(s) are solely for the use of intended recipients. They may contain privileged and/or confidential information legally protected from disclosure. If you are not the intended recipient, you are hereby notified that you received this e-mail in error and that any review, dissemination, distribution or copying of this e-mail and any attachment(s) is strictly prohibited. If you have received this e-mail in error, please contact the sender and delete the message and any attachment(s) from your system. Thank you for your cooperation. From gbonser at seven.com Tue Jan 18 14:05:28 2011 From: gbonser at seven.com (George Bonser) Date: Tue, 18 Jan 2011 12:05:28 -0800 Subject: Dual Homed BGP for failover In-Reply-To: <BLU158-w48D8FEABCAD84C7FE4896ADCF70@phx.gbl> References: <003001cbb73e$0106a860$0313f920$@gmail.com>, <AANLkTimF=uTuuPPhE7ouuw8gOMK7qq7QhN18zP_prinG@mail.gmail.com>, <4D35E612.6010200@brightok.net> <BLU158-w48D8FEABCAD84C7FE4896ADCF70@phx.gbl> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13424@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Brandon Kim > Sent: Tuesday, January 18, 2011 11:57 AM > To: jbates at brightok.net; bill at herrin.us > Cc: ayousuf0079 at gmail.com; nanog group > Subject: RE: Dual Homed BGP for failover > > > Someone should advise him that if he wants to take in a full BGP > routing table > that he makes sure his router can handle it! I would hate for him to > open the floodgates > and his production router shuts down. LOL.... One can take a full feed but filter so only a subset of the routes are actually installed. For example, filter all routes that are more than one AS away from the immediate upstream. From jbfixurpc at gmail.com Tue Jan 18 14:19:24 2011 From: jbfixurpc at gmail.com (Joe Blanchard) Date: Tue, 18 Jan 2011 14:19:24 -0600 Subject: Auto ACL blocker In-Reply-To: <29286818.215.1295377932987.JavaMail.root@mail.absfoc.com> References: <29286818.215.1295377932987.JavaMail.root@mail.absfoc.com> Message-ID: <AANLkTimb9O5C06MM4M-ZDWRzH1c6ge_FRijRN3XycPrn@mail.gmail.com> On Tue, Jan 18, 2011 at 1:12 PM, Brian R. Watters <brwatters at absfoc.com>wrote: > We are looking for the following solution. > > Honey pot that collects attacks against SSH/FTP and so on > > Said attacks are then sent to a master ACL on a edge Cisco router to block > all traffic from these offenders .. > > Of course we would require a master whitelist as well as to not be blocked > from our own networks. > > Any current solutions or ideas ?? > > -- > > BRW > A good start from the honeypot would be sshguard. I'm sure that it could be adapted to script out an ACL or such, as well in my usage of it it has timed values to release the block after X_amount_of_time . I'd be curious as to what other(s) you find for this. -Joe Blanchard From brwatters at absfoc.com Tue Jan 18 14:30:37 2011 From: brwatters at absfoc.com (Brian R. Watters) Date: Tue, 18 Jan 2011 12:30:37 -0800 (PST) Subject: Auto ACL blocker In-Reply-To: <AANLkTimb9O5C06MM4M-ZDWRzH1c6ge_FRijRN3XycPrn@mail.gmail.com> Message-ID: <25445636.265.1295382637125.JavaMail.root@mail.absfoc.com> We have used this solution for some time and find it works pretty well .. http://www.rfxn.com/projects/ However need to find a way to pass this info off to a router, this project used to hold promise however its dead now .. www.ipblocker.org ----- Original Message ----- From: "Joe Blanchard" <jbfixurpc at gmail.com> To: "Brian R. Watters" <brwatters at absfoc.com> Cc: nanog at nanog.org Sent: Tuesday, January 18, 2011 12:19:24 PM Subject: Re: Auto ACL blocker On Tue, Jan 18, 2011 at 1:12 PM, Brian R. Watters < brwatters at absfoc.com > wrote: We are looking for the following solution. Honey pot that collects attacks against SSH/FTP and so on Said attacks are then sent to a master ACL on a edge Cisco router to block all traffic from these offenders .. Of course we would require a master whitelist as well as to not be blocked from our own networks. Any current solutions or ideas ?? -- BRW A good start from the honeypot would be sshguard. I'm sure that it could be adapted to script out an ACL or such, as well in my usage of it it has timed values to release the block after X_amount_of_time . I'd be curious as to what other(s) you find for this. -Joe Blanchard -- Brian R. Watters Director American Broadband Family of Companies 5718 East Shields Ave Fresno, CA. 93727 brwatters at absfoc.com http://www.americanbroadbandservice.com tel: 559-420-0205 fax:559-272-5266 toll free: 866-827-4638 ABS offers T-1's starting at $289 in over 450 cities. Is your city on the list? Click here to find out. This message and any attachment(s) are solely for the use of intended recipients. They may contain privileged and/or confidential information legally protected from disclosure. If you are not the intended recipient, you are hereby notified that you received this e-mail in error and that any review, dissemination, distribution or copying of this e-mail and any attachment(s) is strictly prohibited. If you have received this e-mail in error, please contact the sender and delete the message and any attachment(s) from your system. Thank you for your cooperation. From jbates at brightok.net Tue Jan 18 14:55:02 2011 From: jbates at brightok.net (Jack Bates) Date: Tue, 18 Jan 2011 14:55:02 -0600 Subject: Software DNS hghi availability and load balancer solution In-Reply-To: <alpine.BSF.2.00.1101181438200.46939@murf.icantclick.org> References: <AANLkTimyQDGp9fBiuVE3FEhSJKo-8jzrXHUF+1+aYqpX@mail.gmail.com> <AANLkTimnmc-wc8N1V+DzYq2WFuP-jQHPMJ3dqqUqA66L@mail.gmail.com> <4D35E50D.5060905@rhavenindustrys.com> <alpine.BSF.2.00.1101181438200.46939@murf.icantclick.org> Message-ID: <4D35FE26.2050306@brightok.net> On 1/18/2011 1:42 PM, david raistrick wrote: > Normally, VRRP would be the way to go. But these days multicast isn't > supported everywhere (major example - Amazon EC2), leaving DNS... Many HA environments use both, and F5 is designed to do both, supporting DNS tricks (of which, you could possibly run host based monitoring and dynamic updates to accomplish), anycast routing, and vrrp-like DSR/NAT load balancing. Jack From jbates at brightok.net Tue Jan 18 14:57:16 2011 From: jbates at brightok.net (Jack Bates) Date: Tue, 18 Jan 2011 14:57:16 -0600 Subject: Dual Homed BGP for failover In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13424@RWC-EX1.corp.seven.com> References: <003001cbb73e$0106a860$0313f920$@gmail.com>, <AANLkTimF=uTuuPPhE7ouuw8gOMK7qq7QhN18zP_prinG@mail.gmail.com>, <4D35E612.6010200@brightok.net> <BLU158-w48D8FEABCAD84C7FE4896ADCF70@phx.gbl> <5A6D953473350C4B9995546AFE9939EE0BC13424@RWC-EX1.corp.seven.com> Message-ID: <4D35FEAC.9040705@brightok.net> On 1/18/2011 2:05 PM, George Bonser wrote: > One can take a full feed but filter so only a subset of the routes are > actually installed. For example, filter all routes that are more than > one AS away from the immediate upstream. > You should still be careful, as most processors keep a copy of filtered routes as well, so while your forwarding table may not increase, your route processor memory most likely will. I haven't checked, but I presume IOS and Junos have a knob to disable this feature? Jack From drais at icantclick.org Tue Jan 18 15:01:48 2011 From: drais at icantclick.org (david raistrick) Date: Tue, 18 Jan 2011 16:01:48 -0500 (EST) Subject: Software DNS hghi availability and load balancer solution In-Reply-To: <4D35FE26.2050306@brightok.net> References: <AANLkTimyQDGp9fBiuVE3FEhSJKo-8jzrXHUF+1+aYqpX@mail.gmail.com> <AANLkTimnmc-wc8N1V+DzYq2WFuP-jQHPMJ3dqqUqA66L@mail.gmail.com> <4D35E50D.5060905@rhavenindustrys.com> <alpine.BSF.2.00.1101181438200.46939@murf.icantclick.org> <4D35FE26.2050306@brightok.net> Message-ID: <alpine.BSF.2.00.1101181601010.46939@murf.icantclick.org> On Tue, 18 Jan 2011, Jack Bates wrote: > > On 1/18/2011 1:42 PM, david raistrick wrote: >> Normally, VRRP would be the way to go. But these days multicast isn't >> supported everywhere (major example - Amazon EC2), leaving DNS... > > Many HA environments use both, and F5 is designed to do both, supporting DNS > tricks (of which, you could possibly run host based monitoring and dynamic > updates to accomplish), anycast routing, and vrrp-like DSR/NAT load > balancing. Agreed. But sometimes you can't do both. ;) Now if F5 would sell me an "appliance" that runs their GSLB code I could run @ EC2. ;) -- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html From jack at crepinc.com Tue Jan 18 15:03:04 2011 From: jack at crepinc.com (Jack Carrozzo) Date: Tue, 18 Jan 2011 16:03:04 -0500 Subject: Dual Homed BGP for failover In-Reply-To: <4D35FEAC.9040705@brightok.net> References: <003001cbb73e$0106a860$0313f920$@gmail.com> <AANLkTimF=uTuuPPhE7ouuw8gOMK7qq7QhN18zP_prinG@mail.gmail.com> <4D35E612.6010200@brightok.net> <BLU158-w48D8FEABCAD84C7FE4896ADCF70@phx.gbl> <5A6D953473350C4B9995546AFE9939EE0BC13424@RWC-EX1.corp.seven.com> <4D35FEAC.9040705@brightok.net> Message-ID: <AANLkTin+fWS-XjEDQ_Ybx8EOeP7ESenbU8KmUaubdQ=K@mail.gmail.com> On Tue, Jan 18, 2011 at 3:57 PM, Jack Bates <jbates at brightok.net> wrote: > You should still be careful, as most processors keep a copy of filtered > routes as well, so while your forwarding table may not increase, your route > processor memory most likely will. > > I don't think this is the case, on IOS at least. Some years ago I was rocking some 7500s with $not_enough ram for multiple full tables, but with a prefix list to accept le 23 they worked fine. -Jack Carrozzo From brwatters at absfoc.com Tue Jan 18 15:13:55 2011 From: brwatters at absfoc.com (Brian R. Watters) Date: Tue, 18 Jan 2011 13:13:55 -0800 (PST) Subject: Auto ACL blocker In-Reply-To: <AANLkTi=OBia6+nQU=_2wcK=8P-stLWPdPgJZvZrJBT-K@mail.gmail.com> Message-ID: <25448366.280.1295385235874.JavaMail.root@mail.absfoc.com> Agreed, time to live in the ACL is critical as well .. this is primary to be used to stop sweeps and penetration testing .. We have SNORT deployed now but the process is still manual on the back end and of course does not respond in the time required. ----- Original Message ----- From: " Dorn Hetzel " < dorn @ hetzel .org> To: "Brian R. Watters " < brwatters @ absfoc .com> Cc: nanog @ nanog .org, "Ronald Bonica " < rbonica @juniper.net> Sent: Tuesday, January 18, 2011 1:01:43 PM Subject: Re: Auto ACL blocker One suspects this sort of automated defense should only be used against attack styles that eliminate the likelihood of a forged source ip and that the acl needs to be pruned and compacted for size. Nearby bad ips can be collected into a larger mask but there is then risk of collateral damage (how many bad source ips in a /24 or whatever before you nuke the whole thing for a while? Does the length of a prefixes "rap sheet" change its treatment? Etc) On Jan 18, 2011 3:03 PM, "Brian R. Watters " < brwatters @ absfoc .com > wrote: > Ron, > > I am sure any solution given enough time could be used against you, However my hope was that a whitelist could help in that regard however I know your correct. > > > ----- Original Message ----- > From: "Ronald Bonica " < rbonica @juniper.net > > To: "Brian R. Watters " < brwatters @ absfoc .com >, nanog @ nanog .org > Sent: Tuesday, January 18, 2011 11:55:28 AM > Subject: RE: Auto ACL blocker > > Brian, > > Have you thought about what a bad guy might do if he knew that you had such a policy deployed? Is there a way that the bad guy might turn the policy against you? > > Ron > >> -----Original Message----- >> From: Brian R. Watters [ mailto : brwatters @ absfoc .com ] >> Sent: Tuesday, January 18, 2011 2:12 PM >> To: nanog @ nanog .org >> Subject: Auto ACL blocker >> >> We are looking for the following solution. >> >> Honey pot that collects attacks against SSH/FTP and so on >> >> Said attacks are then sent to a master ACL on a edge Cisco router to >> block all traffic from these offenders .. >> >> Of course we would require a master whitelist as well as to not be >> blocked from our own networks. >> >> Any current solutions or ideas ?? >> >> -- >> >> BRW > > -- > > Brian R. Watters > Director > American Broadband Family of Companies > 5718 East Shields Ave > Fresno, CA. 93727 > brwatters @ absfoc .com > http :// www . americanbroadbandservice .com > tel: 559-420-0205 > fax:559-272-5266 > toll free: 866-827-4638 > > ABS offers T-1's starting at $289 in over 450 cities. Is your city on the list? Click here to find out. > > This message and any attachment(s) are solely for the use of intended recipients. They may contain privileged and/or confidential information legally protected from disclosure. If you are not the intended recipient, you are hereby notified that you received this e-mail in error and that any review, dissemination, distribution or copying of this e-mail and any attachment(s) is strictly prohibited. If you have received this e-mail in error, please contact the sender and delete the message and any attachment(s) from your system. Thank you for your cooperation. > -- Brian R. Watters Director American Broadband Family of Companies 5718 East Shields Ave Fresno, CA. 93727 brwatters @ absfoc .com http :// www . americanbroadbandservice .com tel: 559-420-0205 fax:559-272-5266 toll free: 866-827-4638 ABS offers T-1's starting at $289 in over 450 cities. Is your city on the list? Click here to find out. This message and any attachment(s) are solely for the use of intended recipients. They may contain privileged and/or confidential information legally protected from disclosure. If you are not the intended recipient, you are hereby notified that you received this e-mail in error and that any review, dissemination, distribution or copying of this e-mail and any attachment(s) is strictly prohibited. If you have received this e-mail in error, please contact the sender and delete the message and any attachment(s) from your system. Thank you for your cooperation. From mruiz at lstfinancial.com Tue Jan 18 15:15:08 2011 From: mruiz at lstfinancial.com (Michael Ruiz) Date: Tue, 18 Jan 2011 15:15:08 -0600 Subject: Authentication using Microsoft 2008 Active directory for Cisco RADIUS login Message-ID: <16E58A1FE7C64A46BAD0FE1558C43D9201363DB9@es1.ic-sa.com> Hello all, I am having some trouble getting my Cisco routers to use Active directory to authenticate users. I have searched on Google and so far I am coming up dry on good documentation that will work. I have used these links. http://briandesmond.com/blog/how-to-authenticate-against-active-director y-from-cisco-ios/ http://filedb.experts-exchange.com/incoming/2008/12_w51/87700/TA0001-Win dows-2008-RADIUS-for-C.pdf When I am doing a debug against the AAA I am getting the "Response (32) failed decrypt" error. Any thoughts? Thank you in advance. M.A.R From jbates at brightok.net Tue Jan 18 15:19:48 2011 From: jbates at brightok.net (Jack Bates) Date: Tue, 18 Jan 2011 15:19:48 -0600 Subject: Dual Homed BGP for failover In-Reply-To: <AANLkTin+fWS-XjEDQ_Ybx8EOeP7ESenbU8KmUaubdQ=K@mail.gmail.com> References: <003001cbb73e$0106a860$0313f920$@gmail.com> <AANLkTimF=uTuuPPhE7ouuw8gOMK7qq7QhN18zP_prinG@mail.gmail.com> <4D35E612.6010200@brightok.net> <BLU158-w48D8FEABCAD84C7FE4896ADCF70@phx.gbl> <5A6D953473350C4B9995546AFE9939EE0BC13424@RWC-EX1.corp.seven.com> <4D35FEAC.9040705@brightok.net> <AANLkTin+fWS-XjEDQ_Ybx8EOeP7ESenbU8KmUaubdQ=K@mail.gmail.com> Message-ID: <4D3603F4.5020501@brightok.net> On 1/18/2011 3:03 PM, Jack Carrozzo wrote: > I don't think this is the case, on IOS at least. Some years ago I was > rocking some 7500s with $not_enough ram for multiple full tables, but > with a prefix list to accept le 23 they worked fine. > On JunOS, I know I can view pre and post filtered bgp updates ingress and egress. I seem to recall seeing similar functionality introduced into IOS, though I'm less certain. It's still always advisable to be careful. :) Jack From gbonser at seven.com Tue Jan 18 15:21:46 2011 From: gbonser at seven.com (George Bonser) Date: Tue, 18 Jan 2011 13:21:46 -0800 Subject: Auto ACL blocker In-Reply-To: <25448366.280.1295385235874.JavaMail.root@mail.absfoc.com> References: <AANLkTi=OBia6+nQU=_2wcK=8P-stLWPdPgJZvZrJBT-K@mail.gmail.com> <25448366.280.1295385235874.JavaMail.root@mail.absfoc.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13437@RWC-EX1.corp.seven.com> > From: Brian R. Watters > Sent: Tuesday, January 18, 2011 1:14 PM > To: Dorn Hetzel > Cc: nanog at nanog.org > Subject: Re: Auto ACL blocker > > Agreed, time to live in the ACL is critical as well .. this is primary > to be used to stop sweeps and penetration testing .. We have SNORT > deployed now but the process is still manual on the back end and of > course does not respond in the time required. I suppose you could use tcp wrappers to be creative and launch netcat to "bend" the connection right back to the originator so they spend all their time hacking themselves. From jack at crepinc.com Tue Jan 18 15:21:52 2011 From: jack at crepinc.com (Jack Carrozzo) Date: Tue, 18 Jan 2011 16:21:52 -0500 Subject: Dual Homed BGP for failover In-Reply-To: <4D3603F4.5020501@brightok.net> References: <003001cbb73e$0106a860$0313f920$@gmail.com> <AANLkTimF=uTuuPPhE7ouuw8gOMK7qq7QhN18zP_prinG@mail.gmail.com> <4D35E612.6010200@brightok.net> <BLU158-w48D8FEABCAD84C7FE4896ADCF70@phx.gbl> <5A6D953473350C4B9995546AFE9939EE0BC13424@RWC-EX1.corp.seven.com> <4D35FEAC.9040705@brightok.net> <AANLkTin+fWS-XjEDQ_Ybx8EOeP7ESenbU8KmUaubdQ=K@mail.gmail.com> <4D3603F4.5020501@brightok.net> Message-ID: <AANLkTikjZbVFBbzEyfbuvh2Ua8A3jTf+hcQ9LeGU+E1X@mail.gmail.com> Yep, the great thing about IOS without 'commit confirmed' is when you remove a bgp filter, it runs out of memory, reboots, brings up peers, runs out of memory, reboots... meanwhile if you're trying to get in over a public interface you're cursing John Chamber's very existence. Not that that's ever happened to me of course... -Jack Carrozzo On Tue, Jan 18, 2011 at 4:19 PM, Jack Bates <jbates at brightok.net> wrote: > > > On 1/18/2011 3:03 PM, Jack Carrozzo wrote: > >> I don't think this is the case, on IOS at least. Some years ago I was >> rocking some 7500s with $not_enough ram for multiple full tables, but >> with a prefix list to accept le 23 they worked fine. >> >> > On JunOS, I know I can view pre and post filtered bgp updates ingress and > egress. I seem to recall seeing similar functionality introduced into IOS, > though I'm less certain. It's still always advisable to be careful. :) > > > Jack > From Bryan.Welch at arrisi.com Tue Jan 18 15:23:11 2011 From: Bryan.Welch at arrisi.com (Welch, Bryan) Date: Tue, 18 Jan 2011 13:23:11 -0800 Subject: Authentication using Microsoft 2008 Active directory for Cisco RADIUS login In-Reply-To: <16E58A1FE7C64A46BAD0FE1558C43D9201363DB9@es1.ic-sa.com> References: <16E58A1FE7C64A46BAD0FE1558C43D9201363DB9@es1.ic-sa.com> Message-ID: <DFA5AECDEC85EE4087D45C463C19B375134D703B0B@KWAEXMAIL1.ARRS.ARRISI.COM> Can you post your config on the router? Also, this may be better to post over at cisco-nsp. B -----Original Message----- From: Michael Ruiz [mailto:mruiz at lstfinancial.com] Sent: Tuesday, January 18, 2011 1:15 PM To: nanog at nanog.org Subject: Authentication using Microsoft 2008 Active directory for Cisco RADIUS login Hello all, I am having some trouble getting my Cisco routers to use Active directory to authenticate users. I have searched on Google and so far I am coming up dry on good documentation that will work. I have used these links. http://briandesmond.com/blog/how-to-authenticate-against-active-director y-from-cisco-ios/ http://filedb.experts-exchange.com/incoming/2008/12_w51/87700/TA0001-Win dows-2008-RADIUS-for-C.pdf When I am doing a debug against the AAA I am getting the "Response (32) failed decrypt" error. Any thoughts? Thank you in advance. M.A.R From rcarpen at network1.net Tue Jan 18 15:28:01 2011 From: rcarpen at network1.net (Randy Carpenter) Date: Tue, 18 Jan 2011 16:28:01 -0500 (EST) Subject: Dual Homed BGP for failover In-Reply-To: <4D35E612.6010200@brightok.net> Message-ID: <1262885550.4080.1295386081889.JavaMail.root@zimbra.network1.net> I would be hesitant to do full tables on an SRX210, particularly if you only have an SRX210B with 512MB of RAM. I'm not sure what filtering would do in terms of memory usage, because I have not tried it. I generally put a separate edge device in to handle the upstream and BGP, and use the SRX purely for firewall. You can even have completely redundant edge routers and redundant firewalls, and mesh them with iBGP. This is the setup we are using in our office (2 Cisco 2821 routers on the edge, and 2 Juniper SRX240H firewalls right behind them). Since each of the 2 uplinks we have are ethernet, I have both routers connected to both providers. This gives us ultimate redundancy at very low cost. -Randy -- | Randy Carpenter | Vice President - IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (800)578-6381, Opt. 1 ---- ----- Original Message ----- > On 1/18/2011 1:00 PM, William Herrin wrote: > > IMO, that would be a mistake. Taking significantly less than a full > > table severely limits your options for balancing traffic between the > > links. > > > > It should also be noted that taking a full table, doesn't mean you > have > to use the full table. Apply filters to smaller routes or long ASPATHs > that you don't want, and then assign preferences, communities, > prepends, > etc as necessary for the routes you actually accept. > > This means your sync time is longer and you'll have more updates, but > it > will still keep the local routing table much lower. > > > Jack From nmaxpierson at gmail.com Tue Jan 18 15:29:58 2011 From: nmaxpierson at gmail.com (Max Pierson) Date: Tue, 18 Jan 2011 15:29:58 -0600 Subject: Dual Homed BGP for failover In-Reply-To: <AANLkTikjZbVFBbzEyfbuvh2Ua8A3jTf+hcQ9LeGU+E1X@mail.gmail.com> References: <003001cbb73e$0106a860$0313f920$@gmail.com> <AANLkTimF=uTuuPPhE7ouuw8gOMK7qq7QhN18zP_prinG@mail.gmail.com> <4D35E612.6010200@brightok.net> <BLU158-w48D8FEABCAD84C7FE4896ADCF70@phx.gbl> <5A6D953473350C4B9995546AFE9939EE0BC13424@RWC-EX1.corp.seven.com> <4D35FEAC.9040705@brightok.net> <AANLkTin+fWS-XjEDQ_Ybx8EOeP7ESenbU8KmUaubdQ=K@mail.gmail.com> <4D3603F4.5020501@brightok.net> <AANLkTikjZbVFBbzEyfbuvh2Ua8A3jTf+hcQ9LeGU+E1X@mail.gmail.com> Message-ID: <AANLkTik7HqPc2hnt640PO20vpvbXKrM1=U--2fXkW1i0@mail.gmail.com> Me <3's "commit confirmed" ... maybe someone from Cisco should be watching :) On Tue, Jan 18, 2011 at 3:21 PM, Jack Carrozzo <jack at crepinc.com> wrote: > Yep, the great thing about IOS without 'commit confirmed' is when you > remove > a bgp filter, it runs out of memory, reboots, brings up peers, runs out of > memory, reboots... meanwhile if you're trying to get in over a public > interface you're cursing John Chamber's very existence. Not that that's > ever > happened to me of course... > > -Jack Carrozzo > > On Tue, Jan 18, 2011 at 4:19 PM, Jack Bates <jbates at brightok.net> wrote: > > > > > > > On 1/18/2011 3:03 PM, Jack Carrozzo wrote: > > > >> I don't think this is the case, on IOS at least. Some years ago I was > >> rocking some 7500s with $not_enough ram for multiple full tables, but > >> with a prefix list to accept le 23 they worked fine. > >> > >> > > On JunOS, I know I can view pre and post filtered bgp updates ingress and > > egress. I seem to recall seeing similar functionality introduced into > IOS, > > though I'm less certain. It's still always advisable to be careful. :) > > > > > > Jack > > > From bill at herrin.us Tue Jan 18 15:44:04 2011 From: bill at herrin.us (William Herrin) Date: Tue, 18 Jan 2011 16:44:04 -0500 Subject: Software DNS hghi availability and load balancer solution In-Reply-To: <AANLkTimQ9LzpnT1AhO6Njg_t3nq6KchwgEN5kFbdUWsp@mail.gmail.com> References: <AANLkTimyQDGp9fBiuVE3FEhSJKo-8jzrXHUF+1+aYqpX@mail.gmail.com> <AANLkTimnmc-wc8N1V+DzYq2WFuP-jQHPMJ3dqqUqA66L@mail.gmail.com> <AANLkTimQ9LzpnT1AhO6Njg_t3nq6KchwgEN5kFbdUWsp@mail.gmail.com> Message-ID: <AANLkTimdGkWcgP422AzjmJ8wOnfew4NA--08KDac4Wun@mail.gmail.com> On Tue, Jan 18, 2011 at 3:49 PM, Dorn Hetzel <dorn at hetzel.org> wrote: > If it wouldn't be too ugly, could this be circumvented by having the web > application continually do its next operation against an incrementing > subhost name like syymmddhhmmss or snnnnnnn.www.foo.com in order to convince > the local browser and client os to do a fresh lookup? Hi Dorn, There's an efficiency problem where you can no longer pipeline http requests and have to delay every http request while a DNS lookup happens. Also it'd probably crush your google pagerank. And you still wouldn't get around the javascript in your web 2.0 pages needing to go back to the same server name it came from in order to update the content on those pages. The custom name strategy does have some other really neat applications though. You can track a session without setting a cookie. And consider a large email system: suppose you encode the account name in the server name and then point that encoded name to the server which actually holds that user's account? You can eliminate the expensive front-end that multiplexes user access to the backend servers. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004 From trelane at trelane.net Tue Jan 18 16:22:05 2011 From: trelane at trelane.net (Andrew Kirch) Date: Tue, 18 Jan 2011 17:22:05 -0500 Subject: PCCW Admin Message-ID: <4D36128D.9050809@trelane.net> Would a PCCW admin contact me off-list regarding one of your customers? Andrew From randy at psg.com Tue Jan 18 17:23:43 2011 From: randy at psg.com (Randy Bush) Date: Wed, 19 Jan 2011 08:23:43 +0900 Subject: adaptec 5405 wedged Message-ID: <m2ei89yeww.wl%randy@psg.com> any adaptec bios-level fu out there? if so, please see http://archive.psg.com/110119.adaptec.pdf thanks randy From d.nostra at gmail.com Tue Jan 18 17:14:23 2011 From: d.nostra at gmail.com (Michel de Nostredame) Date: Tue, 18 Jan 2011 15:14:23 -0800 Subject: Dual Homed BGP for failover In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13424@RWC-EX1.corp.seven.com> References: <003001cbb73e$0106a860$0313f920$@gmail.com> <AANLkTimF=uTuuPPhE7ouuw8gOMK7qq7QhN18zP_prinG@mail.gmail.com> <4D35E612.6010200@brightok.net> <BLU158-w48D8FEABCAD84C7FE4896ADCF70@phx.gbl> <5A6D953473350C4B9995546AFE9939EE0BC13424@RWC-EX1.corp.seven.com> Message-ID: <AANLkTi=Fz2r7HLVKz5D_NHypVPZx=T1zZHcKGAoEHurF@mail.gmail.com> On Tue, Jan 18, 2011 at 12:05 PM, George Bonser <gbonser at seven.com> wrote: >> -----Original Message----- >> From: Brandon Kim >> Sent: Tuesday, January 18, 2011 11:57 AM >> To: jbates at brightok.net; bill at herrin.us >> Cc: ayousuf0079 at gmail.com; nanog group >> Subject: RE: Dual Homed BGP for failover > One can take a full feed but filter so only a subset of the routes are > actually installed. ?For example, filter all routes that are more than > one AS away from the immediate upstream. I remember in IOS the BGP config should not have "soft-reconfiguration inbound" for this uplink session, otherwise routing-engine will still keep one copy of full table in memory. -- Michel~ From kevin at steadfast.net Tue Jan 18 17:33:36 2011 From: kevin at steadfast.net (Kevin Stange) Date: Tue, 18 Jan 2011 17:33:36 -0600 Subject: Request Spamhaus contact In-Reply-To: <AANLkTik_EUWJ4ugS9am0EMgxqLyjU1LFDfLpu=DndGOY@mail.gmail.com> References: <AANLkTimG4vpRagh3P8Cke=v_vUuPC4e3XMA9jKny8188@mail.gmail.com> <EB1191041F0045899800B834B64D85C3@DELL16> <AANLkTin6K2L=8tcerRn=-x3NCvvMwB58j8VHaYDGA6dk@mail.gmail.com> <201101181210.00344.simonw@zynet.net> <AANLkTik_EUWJ4ugS9am0EMgxqLyjU1LFDfLpu=DndGOY@mail.gmail.com> Message-ID: <4D362350.4010104@steadfast.net> On 01/18/2011 06:21 AM, Ken Gilmour wrote: > On 18 January 2011 13:10, Simon Waters <simonw at zynet.net> wrote: > >>> Obviously they know about them because google has the information. >> >> I'm not sure this is a reasonable deduction. >> >> > Correct - It is completely unreasonable. I was using it as an example in > reference to a larger, well known provider since earlier someone had > mentioned that obviously since google had this information that BL's > monitoring was inadequate as they didn't know about it themselves. > > Google knows about lots of things that people in general probably don't know > about themselves. > > FTR - I have no doubt that Level 3 have amazing monitoring and > infrastructure, and think I understand why it might be hard to find 231 bad > apples in a basket of over 292492. I think it's important to point out that this statistic is "over the past 90 days" as well. It doesn't identify enough sites to make it possible to verify whether it's representative of current problems. The 231 sites may have been cleaned relatively quickly and still count in the statistic if Google ever found them to be doing something malicious. I do not think this report is a useful one unless the number is constantly growing and is a large percentage of sites Google has spidered on the network. -- Kevin Stange Chief Technology Officer Steadfast Networks http://steadfast.net Phone: 312-602-2689 ext. 203 | Fax: 312-602-2688 | Cell: 312-320-5867 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 261 bytes Desc: OpenPGP digital signature URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110118/1f8f16b1/attachment.bin> From mark at streamservice.nl Tue Jan 18 17:35:15 2011 From: mark at streamservice.nl (Mark Scholten) Date: Wed, 19 Jan 2011 00:35:15 +0100 Subject: Auto ACL blocker In-Reply-To: <201101181331.31022.lesmith@ecsis.net> References: <29286818.215.1295377932987.JavaMail.root@mail.absfoc.com> <201101181331.31022.lesmith@ecsis.net> Message-ID: <0f2201cbb768$5bff4950$13fddbf0$@nl> > From: Larry Smith [mailto:lesmith at ecsis.net] > Sent: Tuesday, January 18, 2011 8:32 PM > > On Tue January 18 2011 13:12, Brian R. Watters wrote: > > We are looking for the following solution. > > > > Honey pot that collects attacks against SSH/FTP and so on > > > > Said attacks are then sent to a master ACL on a edge Cisco router to > block > > all traffic from these offenders .. > > > > Of course we would require a master whitelist as well as to not be > blocked > > from our own networks. > > > > Any current solutions or ideas ?? > > Private BGP session with Zebra or Quagga on a linux box > adding the selected IP to a null route. As we currently do it by putting new rules automatically in firewalls (iptables) it should be easy to change it a little bit I think. After the change it should be able to put rules in Zebra/Quagga (or something similar based on Linux/Unix). As long as telnet access is available it should also be doable to put it automatically in routers without the need of a setup with BGP and Zebra/Quagga. We are currently looking for ways to increase the list with "abusive" systems to block. If someone wants to work together with us on increasing the mentioned options feel free to contact me offlist. How we get the data currently (from multiple sources) or how the process currently work isn't something I can currently mention here (at least not the details). Regards, Mark From regnauld at nsrc.org Tue Jan 18 17:44:20 2011 From: regnauld at nsrc.org (Phil Regnauld) Date: Wed, 19 Jan 2011 00:44:20 +0100 Subject: adaptec 5405 wedged In-Reply-To: <m2ei89yeww.wl%randy@psg.com> References: <m2ei89yeww.wl%randy@psg.com> Message-ID: <1D87AC38-C9DB-4199-B7E0-306662379EFD@nsrc.org> On 19/01/2011, at 00.23, Randy Bush <randy at psg.com> wrote: > any adaptec bios-level fu out there? if so, please see > http://archive.psg.com/110119.adaptec.pdf > Hi Randy, Did you see this bit about transfer speed issues? http://ask.adaptec.com/scripts/adaptec_tic.cfg/php.exe/enduser/std_adp.php?p_faqid=16913 For those customers that are unable to update, or have a Series 2 (2045, 2405, 2405Q, 2805) or a low-port Series 5 (5405, 5405Z, 5445, 5805, 5805Z, 5085, 5805Z, 5805ZQ) controller, the Western Digital WD20EADS and WD2002FYPS drives will need to be jumpered down to 1.5Gb/sec in order to function properly (please refer to the specific jumper settings provided below). From tmagill at providecommerce.com Tue Jan 18 17:48:45 2011 From: tmagill at providecommerce.com (Thomas Magill) Date: Tue, 18 Jan 2011 23:48:45 +0000 Subject: Auto ACL blocker In-Reply-To: <29286818.215.1295377932987.JavaMail.root@mail.absfoc.com> References: <29286818.215.1295377932987.JavaMail.root@mail.absfoc.com> Message-ID: <A1B9BAEA8FE39847BCD6C473E894B595027A50AB@SDEXMB02.Proflowers.com> Also, have you considered just using the spamhaus DROP list? They even have code to have the list pushed to IOS available. You could simply substitute your file for their list if you only want to use IPs caught by your honeypot. http://www.spamhaus.org/faq/answers.lasso?section=DROP%20FAQ -----Original Message----- From: Brian R. Watters [mailto:brwatters at absfoc.com] Sent: Tuesday, January 18, 2011 11:12 AM To: nanog at nanog.org Subject: Auto ACL blocker We are looking for the following solution. Honey pot that collects attacks against SSH/FTP and so on Said attacks are then sent to a master ACL on a edge Cisco router to block all traffic from these offenders .. Of course we would require a master whitelist as well as to not be blocked from our own networks. Any current solutions or ideas ?? -- BRW From charles at knownelement.com Tue Jan 18 17:56:38 2011 From: charles at knownelement.com (Charles N Wyble) Date: Tue, 18 Jan 2011 15:56:38 -0800 Subject: Software DNS hghi availability and load balancer solution In-Reply-To: <AANLkTimyQDGp9fBiuVE3FEhSJKo-8jzrXHUF+1+aYqpX@mail.gmail.com> References: <AANLkTimyQDGp9fBiuVE3FEhSJKo-8jzrXHUF+1+aYqpX@mail.gmail.com> Message-ID: <4D3628B6.40709@knownelement.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ha-proxy and linux virtual server are popular packages. On 01/18/2011 09:42 AM, Sergey Voropaev wrote: > Does any one know software sollutions (free is preferable) like as cisco GSS > and F5 BIG-IP? The main point is that DNS-server (or dns server plugin) must > be able to monitor server availability (for example by TCP connect) and from > DNS-reply depends on it. > > I know that it is possible by BIND with set of script. But we are trying to > find more usable solution with frendly interface. > > Thanks a lot. - -- Charles N Wyble (charles at knownelement.com) Systems craftsman for the stars http://www.knownelement.com Mobile: 626 539 4344 Office: 310 929 8793 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNNiivAAoJEMvvG/TyLEAtnnIQAIYceJh4o1HdFqg0sEc7wBmH W6JejIsI/mrOXaODXLrLjsEuAqGMB9F0For8o3ZTXshnPFldbOcKedAgg0xvZNN6 YlKvvfrrqjRJbIa9ZgeJ9Tqe7/HMPDXWtfxWjzdVIlQE9xuIMIZVZ7F9HHyLfUwU eyWrfEWqjWFlDGSUOqQzlNGt0QoGSEataRNjQX4S4juEmPxN6L+owAvK3dbO61ff 74Nt+KNLBqycbGOcGdiyAIt18GDrR7T35S2hoJ/igcF22Ik76d3pJQNKPgR7dXY6 RPaEftL4W5Kyabhmi6KsBreyeIEqPKq1J9xLlsgujnqHwIw9M/dr+yuVwPGnxiqU f72TreyrLL2ctqX/VrlJWLUdSNQ8YaHmdUVWOrN8STc922AGc3gnpBWrc4GsR3pj d1839gYtgP5niqeMaEw+k/089G9YuIdDETW2a64AFYsa0p/DUy11Zco30ioDuymo UYtJ6X+arJuoD2QtO7onDb0kI3HnzR7xsGyV14KuglSlXF4D3PtveaETEHAWLefr L3uC+WhDZWkaZJKmA60UAiRP0tRbQYEzoCYKEOdS324odeLmnfvNQhzhiEfuABQq quHBhnHjNNr+V9AT10VSd3jXmOoa0oZnuJyD6v94MqzX/M8/TDgvCi8awxXapVpa 2/ldrIuwMeTJBrgamMmm =UzNz -----END PGP SIGNATURE----- From drais at icantclick.org Tue Jan 18 18:01:19 2011 From: drais at icantclick.org (david raistrick) Date: Tue, 18 Jan 2011 19:01:19 -0500 (EST) Subject: Software DNS hghi availability and load balancer solution In-Reply-To: <4D3628B6.40709@knownelement.com> References: <AANLkTimyQDGp9fBiuVE3FEhSJKo-8jzrXHUF+1+aYqpX@mail.gmail.com> <4D3628B6.40709@knownelement.com> Message-ID: <alpine.BSF.2.00.1101181859590.46939@murf.icantclick.org> > On 01/18/2011 09:42 AM, Sergey Voropaev wrote: >> Does any one know software sollutions (free is preferable) like as cisco GSS >> and F5 BIG-IP? The main point is that DNS-server (or dns server plugin) must >> be able to monitor server availability (for example by TCP connect) and from >> DNS-reply depends on it. >> On Tue, 18 Jan 2011, Charles N Wyble wrote: > > Ha-proxy and linux virtual server are popular packages. Neither of these do DNS. He asked about DNS based loadbalancing (also known as GSLB, among other things) software packages.... -- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html From networks at steersnet.org.uk Tue Jan 18 18:09:42 2011 From: networks at steersnet.org.uk (Gary Steers) Date: Wed, 19 Jan 2011 00:09:42 +0000 Subject: Software DNS hghi availability and load balancer solution In-Reply-To: <4D3628B6.40709@knownelement.com> References: <AANLkTimyQDGp9fBiuVE3FEhSJKo-8jzrXHUF+1+aYqpX@mail.gmail.com> <4D3628B6.40709@knownelement.com> Message-ID: <AANLkTik_fX9zYtv+qSXPtOWEDZ0LAex4wcvussrNHPaa@mail.gmail.com> Hi Guys, First time post so please excuse. * * I think you can get a free Citrix NetScaler virtual applicance (VPX) that will do this with GSLB. other then that PowerDNS has a very good geolocation plugin, so they may also have an availabiliy plugin for checks... * * I am also looking for a combined open source geolocation and availability checking DNS Platform. * * Gary On 18 January 2011 23:56, Charles N Wyble <charles at knownelement.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Ha-proxy and linux virtual server are popular packages. > > On 01/18/2011 09:42 AM, Sergey Voropaev wrote: > > Does any one know software sollutions (free is preferable) like as cisco > GSS > > and F5 BIG-IP? The main point is that DNS-server (or dns server plugin) > must > > be able to monitor server availability (for example by TCP connect) and > from > > DNS-reply depends on it. > > > > I know that it is possible by BIND with set of script. But we are trying > to > > find more usable solution with frendly interface. > > > > Thanks a lot. > > > - -- > Charles N Wyble (charles at knownelement.com) > Systems craftsman for the stars > http://www.knownelement.com > Mobile: 626 539 4344 > Office: 310 929 8793 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQIcBAEBAgAGBQJNNiivAAoJEMvvG/TyLEAtnnIQAIYceJh4o1HdFqg0sEc7wBmH > W6JejIsI/mrOXaODXLrLjsEuAqGMB9F0For8o3ZTXshnPFldbOcKedAgg0xvZNN6 > YlKvvfrrqjRJbIa9ZgeJ9Tqe7/HMPDXWtfxWjzdVIlQE9xuIMIZVZ7F9HHyLfUwU > eyWrfEWqjWFlDGSUOqQzlNGt0QoGSEataRNjQX4S4juEmPxN6L+owAvK3dbO61ff > 74Nt+KNLBqycbGOcGdiyAIt18GDrR7T35S2hoJ/igcF22Ik76d3pJQNKPgR7dXY6 > RPaEftL4W5Kyabhmi6KsBreyeIEqPKq1J9xLlsgujnqHwIw9M/dr+yuVwPGnxiqU > f72TreyrLL2ctqX/VrlJWLUdSNQ8YaHmdUVWOrN8STc922AGc3gnpBWrc4GsR3pj > d1839gYtgP5niqeMaEw+k/089G9YuIdDETW2a64AFYsa0p/DUy11Zco30ioDuymo > UYtJ6X+arJuoD2QtO7onDb0kI3HnzR7xsGyV14KuglSlXF4D3PtveaETEHAWLefr > L3uC+WhDZWkaZJKmA60UAiRP0tRbQYEzoCYKEOdS324odeLmnfvNQhzhiEfuABQq > quHBhnHjNNr+V9AT10VSd3jXmOoa0oZnuJyD6v94MqzX/M8/TDgvCi8awxXapVpa > 2/ldrIuwMeTJBrgamMmm > =UzNz > -----END PGP SIGNATURE----- > > From rcarpen at network1.net Tue Jan 18 18:22:49 2011 From: rcarpen at network1.net (Randy Carpenter) Date: Tue, 18 Jan 2011 19:22:49 -0500 (EST) Subject: adaptec 5405 wedged In-Reply-To: <1D87AC38-C9DB-4199-B7E0-306662379EFD@nsrc.org> Message-ID: <463757264.4124.1295396569640.JavaMail.root@zimbra.network1.net> Not sure, but I have seen issues with keyboard input on IPMI or serial-port console systems not working very well in controller BIOS screens. Has this worked before using the same method? Also, were you able to flash the BIOS of the WD drives with a hacked firmware that has TLER enabled? If not, I would highly suggest not using those drives in a RAID array. Stick with the RAID Edition drives for that. I have had a multitude of issues with drives (particularly Western Digital) that were not designed for RAID use. -Randy -- | Randy Carpenter | Vice President - IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (800)578-6381, Opt. 1 ---- ----- Original Message ----- > On 19/01/2011, at 00.23, Randy Bush <randy at psg.com> wrote: > > > any adaptec bios-level fu out there? if so, please see > > http://archive.psg.com/110119.adaptec.pdf > > > > Hi Randy, > > Did you see this bit about transfer speed issues? > > > http://ask.adaptec.com/scripts/adaptec_tic.cfg/php.exe/enduser/std_adp.php?p_faqid=16913 > > For those customers that are unable to update, or have a Series 2 > (2045, 2405, 2405Q, 2805) or a low-port Series 5 (5405, 5405Z, 5445, > 5805, 5805Z, 5085, 5805Z, 5805ZQ) controller, the Western Digital > WD20EADS and WD2002FYPS drives will need to be jumpered down to > 1.5Gb/sec in order to function properly (please refer to the specific > jumper settings provided below). From ml at kenweb.org Tue Jan 18 18:27:42 2011 From: ml at kenweb.org (ML) Date: Tue, 18 Jan 2011 19:27:42 -0500 Subject: Auto ACL blocker In-Reply-To: <A1B9BAEA8FE39847BCD6C473E894B595027A50AB@SDEXMB02.Proflowers.com> References: <29286818.215.1295377932987.JavaMail.root@mail.absfoc.com> <A1B9BAEA8FE39847BCD6C473E894B595027A50AB@SDEXMB02.Proflowers.com> Message-ID: <4D362FFE.5030102@kenweb.org> On 1/18/2011 6:48 PM, Thomas Magill wrote: > Also, have you considered just using the spamhaus DROP list? They even have code to have the list pushed to IOS available. You could simply substitute your file for their list if you only want to use IPs caught by your honeypot. > > http://www.spamhaus.org/faq/answers.lasso?section=DROP%20FAQ > > I know Spamhaus doesn't offer a BGP feed of the DROP list. Has anyone made a homegrown solution? There is a PHP script that pull the DROP list and make a Cisco ACL or IPtables rules. http://www.potato-people.com/code/misctools/spamhausdrop.phps From ml at kenweb.org Tue Jan 18 18:30:24 2011 From: ml at kenweb.org (ML) Date: Tue, 18 Jan 2011 19:30:24 -0500 Subject: Authentication using Microsoft 2008 Active directory for Cisco RADIUS login In-Reply-To: <16E58A1FE7C64A46BAD0FE1558C43D9201363DB9@es1.ic-sa.com> References: <16E58A1FE7C64A46BAD0FE1558C43D9201363DB9@es1.ic-sa.com> Message-ID: <4D3630A0.4070506@kenweb.org> On 1/18/2011 4:15 PM, Michael Ruiz wrote: > Hello all, > > > > I am having some trouble getting my Cisco routers to use > Active directory to authenticate users. I have searched on Google and so > far I am coming up dry on good documentation that will work. > > I know $myemployer Uses Cisco ACS to hit AD for logins. Maybe use tac+ to then query AD. From networks at steersnet.org.uk Tue Jan 18 18:38:40 2011 From: networks at steersnet.org.uk (Gary Steers) Date: Wed, 19 Jan 2011 00:38:40 +0000 Subject: Authentication using Microsoft 2008 Active directory for Cisco RADIUS login In-Reply-To: <4D3630A0.4070506@kenweb.org> References: <16E58A1FE7C64A46BAD0FE1558C43D9201363DB9@es1.ic-sa.com> <4D3630A0.4070506@kenweb.org> Message-ID: <AANLkTimQScJwMQYPgoL9851CfaLwksCftvE=AzKDnvyX@mail.gmail.com> I've set it up on 2003 before, found this article... http://social.technet.microsoft.com/Forums/en-US/winserverNIS/thread/bfbbbae4-a280-4b3f-b214-02867b7d33e3/ <http://social.technet.microsoft.com/Forums/en-US/winserverNIS/thread/bfbbbae4-a280-4b3f-b214-02867b7d33e3/>it may be of use. Essentially on 2k3 it was a case of IAS and setting up the Cisco to use auth-port 1645 Looking at this you use NPS and change the port * * Gary * * On 19 January 2011 00:30, ML <ml at kenweb.org> wrote: > On 1/18/2011 4:15 PM, Michael Ruiz wrote: > >> Hello all, >> >> >> >> I am having some trouble getting my Cisco routers to use >> Active directory to authenticate users. I have searched on Google and so >> far I am coming up dry on good documentation that will work. >> >> >> > I know $myemployer Uses Cisco ACS to hit AD for logins. Maybe use tac+ to > then query AD. > > From charles at knownelement.com Tue Jan 18 18:39:29 2011 From: charles at knownelement.com (Charles N Wyble) Date: Tue, 18 Jan 2011 16:39:29 -0800 Subject: Software DNS hghi availability and load balancer solution In-Reply-To: <alpine.BSF.2.00.1101181859590.46939@murf.icantclick.org> References: <AANLkTimyQDGp9fBiuVE3FEhSJKo-8jzrXHUF+1+aYqpX@mail.gmail.com> <4D3628B6.40709@knownelement.com> <alpine.BSF.2.00.1101181859590.46939@murf.icantclick.org> Message-ID: <4D3632C1.2010800@knownelement.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/18/2011 04:01 PM, david raistrick wrote: > >> On 01/18/2011 09:42 AM, Sergey Voropaev wrote: >>> Does any one know software sollutions (free is preferable) like as >>> cisco GSS >>> and F5 BIG-IP? The main point is that DNS-server (or dns server >>> plugin) must >>> be able to monitor server availability (for example by TCP connect) >>> and from >>> DNS-reply depends on it. >>> > > On Tue, 18 Jan 2011, Charles N Wyble wrote: >> >> Ha-proxy and linux virtual server are popular packages. > > Neither of these do DNS. What does that mean? Load balance DNS lookups across multiple servers? Or use DNS to load balance? I've never setup a load balancer for DNS before. Always just had one server and moved the VM in event of failure/maintenance. He asked about DNS based loadbalancing (also > known as GSLB, among other things) software packages.... Ah. DNS based load balancing. I've heard good things about powerdns for that. - -- Charles N Wyble (charles at knownelement.com) Systems craftsman for the stars http://www.knownelement.com Mobile: 626 539 4344 Office: 310 929 8793 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNNjK6AAoJEMvvG/TyLEAtT1gQALYOb8mYK8llulRAikXo0Nij nTaBSq8Bj/DnTA85iZpa1MZ0WCQY6ofXnOjvvfUvqM3idFzQC4I5R/gPgPgZrfYg ZKZFuaEIiqT0zMzufzM4rAZk96zH/BkgcXK0M7foS1vLijxWCo06Ba2Srga1Uawo JpZXp2WZILZc1VRCdvxBioU3UHWSdjiDjVZ9p+uMXTDjh/O7VpPNh4LhP0fdfY/P K/WMpTTm8djCyTuzgnx0KXucjp7uqmdy+7LrvROQ67avqcooDzM7P8amw8OI+SyC Y2ipe7iHREenH1Cr9V8bABUn3qJuHwEgQxObu5SS+mZsCH3YpjCsog3j9TWpwNZd 34Jm+/viYCxEYvPM9j2r3ABJPGsQQcjbkE1mGqEKxsWSNIss9wTuqDDofc0JfnN/ GkZpZZLjpxdA7DCV1gioaVVhUNPELg/qSM/3DfVnW1EA24PIyfLOeZcwC9jHS0X/ DjgnjpktoFu1gVIZTKf4jOGEqdbympYabr/NhYRSKrA1uLJUOHAHN47QJonP5CkI YuEPM3uEmmO5/S2C1gKYKa3hHFQpfMcqjSwdGnCrcJ/G+j6PyU/YmTOy+2RMJI6A UKgP1IK7hYeBScPB/qibfkgNeakBjg+WIO3djps7lqxR2QSUzK6qIqQSGeK1euxt GqK3Q9I7rh+tDEtA3t4Y =PTkN -----END PGP SIGNATURE----- From bonomi at mail.r-bonomi.com Tue Jan 18 18:54:59 2011 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Tue, 18 Jan 2011 18:54:59 -0600 (CST) Subject: Routing Suggestions In-Reply-To: <m239ov95lb.wl%randy@psg.com> Message-ID: <201101190054.p0J0sxBF081763@mail.r-bonomi.com> > Date: Fri, 14 Jan 2011 01:50:40 -0800 > From: Randy Bush <randy at psg.com> > Subject: Re: Routing Suggestions > > i'm with jon and the static crew. brutal but simple. > > if you want no leakage, A can filter the prefix from it's upstreams, both > can low-pref blackhole it, ... > One late comment -- OP stated that the companies were exchanging 'sensitive' traffic. I suspect that they di *NOT* want this traffic to route over the public internet -if- he private point-to-point link goes down. if they're running any sort of a dynamic/active routing protocol then -that- route is going to disappear if/*WHEN* the private link goes down, and the packets will be subject to whatever other routing rules -- e.g. a 'default' route -- are in place. This would seem to be a compelling reason to use a static route -- insuring that traffic _fails_ to route, instead of failing over to a public internet route, in the event of a link failure. From networks at steersnet.org.uk Tue Jan 18 19:17:03 2011 From: networks at steersnet.org.uk (Gary Steers) Date: Wed, 19 Jan 2011 01:17:03 +0000 Subject: Software DNS hghi availability and load balancer solution In-Reply-To: <4D3632C1.2010800@knownelement.com> References: <AANLkTimyQDGp9fBiuVE3FEhSJKo-8jzrXHUF+1+aYqpX@mail.gmail.com> <4D3628B6.40709@knownelement.com> <alpine.BSF.2.00.1101181859590.46939@murf.icantclick.org> <4D3632C1.2010800@knownelement.com> Message-ID: <AANLkTiny5m313VtYueSBAd0HGN4EPoenPVXF8Mvx1+7x@mail.gmail.com> >What does that mean? Load balance DNS lookups across multiple servers? >Or use DNS to load balance? I've never setup a load balancer for DNS >before. Always just had one server and moved the VM in event of >failure/maintenance. * * I think using DNS to load balance is what was meant, PowerDNS can do this, but most DNS servers can to basic load balancing/round robin (it will just give out a different/multiple A Records each time. I've done this with bind and Microsoft before. PowerDNS has an awsome geolocation plugin, and that probably can be tied to a check to see if the IP is up so it's actually checking the status of IPs to make it more automated. Gary On 19 January 2011 00:39, Charles N Wyble <charles at knownelement.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 01/18/2011 04:01 PM, david raistrick wrote: > > > >> On 01/18/2011 09:42 AM, Sergey Voropaev wrote: > >>> Does any one know software sollutions (free is preferable) like as > >>> cisco GSS > >>> and F5 BIG-IP? The main point is that DNS-server (or dns server > >>> plugin) must > >>> be able to monitor server availability (for example by TCP connect) > >>> and from > >>> DNS-reply depends on it. > >>> > > > > On Tue, 18 Jan 2011, Charles N Wyble wrote: > >> > >> Ha-proxy and linux virtual server are popular packages. > > > > Neither of these do DNS. > > What does that mean? Load balance DNS lookups across multiple servers? > Or use DNS to load balance? I've never setup a load balancer for DNS > before. Always just had one server and moved the VM in event of > failure/maintenance. > > He asked about DNS based loadbalancing (also > > known as GSLB, among other things) software packages.... > > Ah. DNS based load balancing. I've heard good things about powerdns for > that. > > > > - -- > Charles N Wyble (charles at knownelement.com) > Systems craftsman for the stars > http://www.knownelement.com > Mobile: 626 539 4344 > Office: 310 929 8793 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQIcBAEBAgAGBQJNNjK6AAoJEMvvG/TyLEAtT1gQALYOb8mYK8llulRAikXo0Nij > nTaBSq8Bj/DnTA85iZpa1MZ0WCQY6ofXnOjvvfUvqM3idFzQC4I5R/gPgPgZrfYg > ZKZFuaEIiqT0zMzufzM4rAZk96zH/BkgcXK0M7foS1vLijxWCo06Ba2Srga1Uawo > JpZXp2WZILZc1VRCdvxBioU3UHWSdjiDjVZ9p+uMXTDjh/O7VpPNh4LhP0fdfY/P > K/WMpTTm8djCyTuzgnx0KXucjp7uqmdy+7LrvROQ67avqcooDzM7P8amw8OI+SyC > Y2ipe7iHREenH1Cr9V8bABUn3qJuHwEgQxObu5SS+mZsCH3YpjCsog3j9TWpwNZd > 34Jm+/viYCxEYvPM9j2r3ABJPGsQQcjbkE1mGqEKxsWSNIss9wTuqDDofc0JfnN/ > GkZpZZLjpxdA7DCV1gioaVVhUNPELg/qSM/3DfVnW1EA24PIyfLOeZcwC9jHS0X/ > DjgnjpktoFu1gVIZTKf4jOGEqdbympYabr/NhYRSKrA1uLJUOHAHN47QJonP5CkI > YuEPM3uEmmO5/S2C1gKYKa3hHFQpfMcqjSwdGnCrcJ/G+j6PyU/YmTOy+2RMJI6A > UKgP1IK7hYeBScPB/qibfkgNeakBjg+WIO3djps7lqxR2QSUzK6qIqQSGeK1euxt > GqK3Q9I7rh+tDEtA3t4Y > =PTkN > -----END PGP SIGNATURE----- > > From tmagill at providecommerce.com Tue Jan 18 19:23:12 2011 From: tmagill at providecommerce.com (Thomas Magill) Date: Wed, 19 Jan 2011 01:23:12 +0000 Subject: Auto ACL blocker In-Reply-To: <4D362FFE.5030102@kenweb.org> References: <29286818.215.1295377932987.JavaMail.root@mail.absfoc.com> <A1B9BAEA8FE39847BCD6C473E894B595027A50AB@SDEXMB02.Proflowers.com> <4D362FFE.5030102@kenweb.org> Message-ID: <A1B9BAEA8FE39847BCD6C473E894B595027A65AD@SDEXMB02.Proflowers.com> -----Original Message----- From: ML [mailto:ml at kenweb.org] Sent: Tuesday, January 18, 2011 4:28 PM To: nanog at nanog.org Subject: Re: Auto ACL blocker > I know Spamhaus doesn't offer a BGP feed of the DROP list. Has anyone > made a homegrown solution? "DROP is currently available only as a simple text list but may be available in the future by BGP, announced via an Autonomous System Number (ASN). DROP users could then choose to peer with that ASN to null those prefixes as being ranges for which they do not wish to route traffic." I considered giving it a shot until I read that. It doesn't seem very difficult but don't have the free time to work on things that someone else claims is coming. I also don?t have a spare ASN to share it externally which would be the ultimate goal, like the Cymru bogon peering. From tmagill at providecommerce.com Tue Jan 18 19:24:32 2011 From: tmagill at providecommerce.com (Thomas Magill) Date: Wed, 19 Jan 2011 01:24:32 +0000 Subject: Auto ACL blocker In-Reply-To: <A1B9BAEA8FE39847BCD6C473E894B595027A65AD@SDEXMB02.Proflowers.com> References: <29286818.215.1295377932987.JavaMail.root@mail.absfoc.com> <A1B9BAEA8FE39847BCD6C473E894B595027A50AB@SDEXMB02.Proflowers.com> <4D362FFE.5030102@kenweb.org> <A1B9BAEA8FE39847BCD6C473E894B595027A65AD@SDEXMB02.Proflowers.com> Message-ID: <A1B9BAEA8FE39847BCD6C473E894B595027A65C7@SDEXMB02.Proflowers.com> LOL.. oops.. I guess I could just use 65xxx. -----Original Message----- From: Thomas Magill [mailto:tmagill at providecommerce.com] Sent: Tuesday, January 18, 2011 5:23 PM To: ml at kenweb.org; nanog at nanog.org Subject: RE: Auto ACL blocker -----Original Message----- From: ML [mailto:ml at kenweb.org] Sent: Tuesday, January 18, 2011 4:28 PM To: nanog at nanog.org Subject: Re: Auto ACL blocker > I know Spamhaus doesn't offer a BGP feed of the DROP list. Has anyone > made a homegrown solution? "DROP is currently available only as a simple text list but may be available in the future by BGP, announced via an Autonomous System Number (ASN). DROP users could then choose to peer with that ASN to null those prefixes as being ranges for which they do not wish to route traffic." I considered giving it a shot until I read that. It doesn't seem very difficult but don't have the free time to work on things that someone else claims is coming. I also don?t have a spare ASN to share it externally which would be the ultimate goal, like the Cymru bogon peering. From owen at delong.com Tue Jan 18 19:26:26 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 18 Jan 2011 17:26:26 -0800 Subject: Routing Suggestions In-Reply-To: <201101190054.p0J0sxBF081763@mail.r-bonomi.com> References: <201101190054.p0J0sxBF081763@mail.r-bonomi.com> Message-ID: <D4C33BC0-EAB2-49FC-8863-22C26D7155B2@delong.com> On Jan 18, 2011, at 4:54 PM, Robert Bonomi wrote: > >> Date: Fri, 14 Jan 2011 01:50:40 -0800 >> From: Randy Bush <randy at psg.com> >> Subject: Re: Routing Suggestions >> >> i'm with jon and the static crew. brutal but simple. >> >> if you want no leakage, A can filter the prefix from it's upstreams, both >> can low-pref blackhole it, ... >> > > One late comment -- > > OP stated that the companies were exchanging 'sensitive' traffic. I suspect > that they di *NOT* want this traffic to route over the public internet -if- > he private point-to-point link goes down. if they're running any sort of a > dynamic/active routing protocol then -that- route is going to disappear > if/*WHEN* the private link goes down, and the packets will be subject to > whatever other routing rules -- e.g. a 'default' route -- are in place. > > This would seem to be a compelling reason to use a static route -- insuring > that traffic _fails_ to route, instead of failing over to a public internet > route, in the event of a link failure. > > That's why I always prefer to put this traffic inside an IPSEC VPN. Then, you gain the advantage of being able to let the internet serve as a backup for your preferred private path while still protecting your sensitive information. Then I use dynamic routing and take advantage of the diverse path capabilities. Owen From jreitz at gmail.com Tue Jan 18 19:50:51 2011 From: jreitz at gmail.com (Jay Reitz) Date: Tue, 18 Jan 2011 17:50:51 -0800 Subject: Software DNS hghi availability and load balancer solution In-Reply-To: <AANLkTiny5m313VtYueSBAd0HGN4EPoenPVXF8Mvx1+7x@mail.gmail.com> References: <AANLkTimyQDGp9fBiuVE3FEhSJKo-8jzrXHUF+1+aYqpX@mail.gmail.com> <4D3628B6.40709@knownelement.com> <alpine.BSF.2.00.1101181859590.46939@murf.icantclick.org> <4D3632C1.2010800@knownelement.com> <AANLkTiny5m313VtYueSBAd0HGN4EPoenPVXF8Mvx1+7x@mail.gmail.com> Message-ID: <AANLkTi=0xyMSQTFecMLnuatsg2h+GkZK6eLkL04MKpkR@mail.gmail.com> > PowerDNS has an awsome geolocation plugin, and that probably can be tied to > a check to see if the IP is up so it's actually checking the status of IPs > to make it more automated. > > Gary > gdnsd is very robust and fast and has an interface that a networking engineer won't mind. It comes with a geolocation plugin with health-check failover via HTTP. http://code.google.com/p/gdnsd/ >j. From paul at paulgraydon.co.uk Tue Jan 18 20:25:28 2011 From: paul at paulgraydon.co.uk (Paul Graydon) Date: Tue, 18 Jan 2011 16:25:28 -1000 Subject: Software DNS hghi availability and load balancer solution In-Reply-To: <AANLkTimyQDGp9fBiuVE3FEhSJKo-8jzrXHUF+1+aYqpX@mail.gmail.com> References: <AANLkTimyQDGp9fBiuVE3FEhSJKo-8jzrXHUF+1+aYqpX@mail.gmail.com> Message-ID: <4D364B98.40803@paulgraydon.co.uk> On 01/18/2011 07:42 AM, Sergey Voropaev wrote: > Does any one know software sollutions (free is preferable) like as cisco GSS > and F5 BIG-IP? The main point is that DNS-server (or dns server plugin) must > be able to monitor server availability (for example by TCP connect) and from > DNS-reply depends on it. > > I know that it is possible by BIND with set of script. But we are trying to > find more usable solution with frendly interface. > > Thanks a lot. If you want to get fancy you could try an Anycast DNS setup, using GNU's Zebra tool to automatically alter routing tables. http://www.netlinxinc.com/netlinx-blog/45-dns/118-introduction-to-anycast-dns.html Paul From jlewis at lewis.org Tue Jan 18 20:41:27 2011 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 18 Jan 2011 21:41:27 -0500 (EST) Subject: Software DNS hghi availability and load balancer solution In-Reply-To: <4D3632C1.2010800@knownelement.com> References: <AANLkTimyQDGp9fBiuVE3FEhSJKo-8jzrXHUF+1+aYqpX@mail.gmail.com> <4D3628B6.40709@knownelement.com> <alpine.BSF.2.00.1101181859590.46939@murf.icantclick.org> <4D3632C1.2010800@knownelement.com> Message-ID: <Pine.LNX.4.61.1101182137380.5148@soloth.lewis.org> On Tue, 18 Jan 2011, Charles N Wyble wrote: > He asked about DNS based loadbalancing (also >> known as GSLB, among other things) software packages.... > > Ah. DNS based load balancing. I've heard good things about powerdns for > that. I assume the "good things" is that with powerdns and the gmysql backend, it's trivial to have a script do some SQL updates as often as you need to change the content and change_date of the records you're using for the DNS based load balancing. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From alex.wilkinson at dsto.defence.gov.au Tue Jan 18 21:43:55 2011 From: alex.wilkinson at dsto.defence.gov.au (Wilkinson, Alex) Date: Wed, 19 Jan 2011 11:43:55 +0800 Subject: Software DNS hghi availability and load balancer solution [SEC=UNCLASSIFIED] In-Reply-To: <alpine.BSF.2.00.1101181438200.46939@murf.icantclick.org> References: <AANLkTimyQDGp9fBiuVE3FEhSJKo-8jzrXHUF+1+aYqpX@mail.gmail.com> <AANLkTimnmc-wc8N1V+DzYq2WFuP-jQHPMJ3dqqUqA66L@mail.gmail.com> <4D35E50D.5060905@rhavenindustrys.com> <alpine.BSF.2.00.1101181438200.46939@murf.icantclick.org> Message-ID: <20110119034355.GB33644@stlux503.dsto.defence.gov.au> 0n Tue, Jan 18, 2011 at 02:42:57PM -0500, david raistrick wrote: >On Tue, 18 Jan 2011, Rhys Rhaven wrote: > >> Having hit these issues myself, I heavily recommend a real frontend >> proxy like nginx or varnish. > >A frontend proxy (nginx, varnish, haproxy, or anything else) doesnt give >you HA any more than any other loadbalancer solution does. You need a way >to send traffic to another frontend server when the primary frontend >server fails, or is overloaded, transparently. freebsd + varnish + carp (http://www.openbsd.org/faq/pf/carp.html) -Alex IMPORTANT: This email remains the property of the Department of Defence and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From trelane at trelane.net Tue Jan 18 23:19:21 2011 From: trelane at trelane.net (Andrew Kirch) Date: Wed, 19 Jan 2011 00:19:21 -0500 Subject: PacketExchange/Mzima Message-ID: <4D367459.2020302@trelane.net> Need a PacketExchange/Mzima admin to contact me off list regarding an AS Number issue. Andrwe From jarod.smouth at gmail.com Wed Jan 19 03:18:14 2011 From: jarod.smouth at gmail.com (jarod smith) Date: Wed, 19 Jan 2011 10:18:14 +0100 Subject: NAT-PT or NAT64 in real life Message-ID: <AANLkTik1twjfBnhcyLYvx+RBHs63hi2siCE6R9SLMgfv@mail.gmail.com> Although it would seem that double-stack is still the preferred method of linux distribution, I want my next deployed in IPv6 only. For linux there is NAT-PT tomicki and NAT64 Viagenie. I don't have Cisco equipment although I'd like tested their NAT-PT, even if it's obsolete. Are some of you have installed one of these two implementations in production on recent versions of linux? Is it stable, secure, ... ? Regards From swmike at swm.pp.se Wed Jan 19 03:26:31 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 19 Jan 2011 10:26:31 +0100 (CET) Subject: NAT-PT or NAT64 in real life In-Reply-To: <AANLkTik1twjfBnhcyLYvx+RBHs63hi2siCE6R9SLMgfv@mail.gmail.com> References: <AANLkTik1twjfBnhcyLYvx+RBHs63hi2siCE6R9SLMgfv@mail.gmail.com> Message-ID: <alpine.DEB.1.10.1101191023120.13151@uplift.swm.pp.se> On Wed, 19 Jan 2011, jarod smith wrote: > Are some of you have installed one of these two implementations in > production on recent versions of linux? Is it stable, secure, ... ? Not in production, but we've installed it for testing. We immediately ran into problems that was MTU related where viagenie mismatched the 2 byte MTU in IPv4 with 4 byte in IPv6 and didn't handle that. After reporting this we quickly received a patch that fixed the problem. They also seem to have other fixes not available in the public distribution (this was a month ago, might have changed). So my take on this is that viagenie responds well to mail and will fix things, but the software has not been widely tested and is not production quality right now. -- Mikael Abrahamsson email: swmike at swm.pp.se From ayousuf0079 at gmail.com Wed Jan 19 04:23:47 2011 From: ayousuf0079 at gmail.com (Ahmed Yousuf) Date: Wed, 19 Jan 2011 10:23:47 -0000 Subject: Dual Homed BGP for failover In-Reply-To: <AANLkTik7HqPc2hnt640PO20vpvbXKrM1=U--2fXkW1i0@mail.gmail.com> References: <003001cbb73e$0106a860$0313f920$@gmail.com> <AANLkTimF=uTuuPPhE7ouuw8gOMK7qq7QhN18zP_prinG@mail.gmail.com> <4D35E612.6010200@brightok.net> <BLU158-w48D8FEABCAD84C7FE4896ADCF70@phx.gbl> <5A6D953473350C4B9995546AFE9939EE0BC13424@RWC-EX1.corp.seven.com> <4D35FEAC.9040705@brightok.net> <AANLkTin+fWS-XjEDQ_Ybx8EOeP7ESenbU8KmUaubdQ=K@mail.gmail.com> <4D3603F4.5020501@brightok.net> <AANLkTikjZbVFBbzEyfbuvh2Ua8A3jTf+hcQ9LeGU+E1X@mail.gmail.com> <AANLkTik7HqPc2hnt640PO20vpvbXKrM1=U--2fXkW1i0@mail.gmail.com> Message-ID: <007301cbb7c2$f5a63500$e0f29f00$@gmail.com> Thanks to all for the responses, certainly illuminating. I'm now more aware of what I can do and what tools are available. The following makes sense to me: - Take full routing tables and default from both ISPs and decide how I filter the routes that get installed in my routers. - Originally apply the same filters on both and monitor the links to see what the natural distribution is, when we let the BGP process decide how the traffic is routed. Need to think more about which filters to apply here, the SRX210s are quoted as having capacity for 16k routes. - Once we have a better idea of the traffic profiles start changing the filters to preference certain traffic over the higher speed link. One way this might be done, is to filter based on RIPE or ARIN addresses. We are most concerned about maintaining capacity for European traffic, so install RIPE routes on the higher capacity link and ARIN routes on the lower capacity links. - Accept that we are never going to get an ideal distribution of traffic and continue monitoring and adjusting local pref/prepends etc. as and when we need to change the distribution of traffic. Hopefully we don't need to do this that often. Thoughts? Ahmed From: Max Pierson [mailto:nmaxpierson at gmail.com] Sent: 18 January 2011 21:30 To: Jack Carrozzo Cc: Jack Bates; ayousuf0079 at gmail.com; nanog group Subject: Re: Dual Homed BGP for failover Me <3's "commit confirmed" ... maybe someone from Cisco should be watching :) On Tue, Jan 18, 2011 at 3:21 PM, Jack Carrozzo <jack at crepinc.com> wrote: Yep, the great thing about IOS without 'commit confirmed' is when you remove a bgp filter, it runs out of memory, reboots, brings up peers, runs out of memory, reboots... meanwhile if you're trying to get in over a public interface you're cursing John Chamber's very existence. Not that that's ever happened to me of course... -Jack Carrozzo On Tue, Jan 18, 2011 at 4:19 PM, Jack Bates <jbates at brightok.net> wrote: > > > On 1/18/2011 3:03 PM, Jack Carrozzo wrote: > >> I don't think this is the case, on IOS at least. Some years ago I was >> rocking some 7500s with $not_enough ram for multiple full tables, but >> with a prefix list to accept le 23 they worked fine. >> >> > On JunOS, I know I can view pre and post filtered bgp updates ingress and > egress. I seem to recall seeing similar functionality introduced into IOS, > though I'm less certain. It's still always advisable to be careful. :) > > > Jack > From jarod.smouth at gmail.com Wed Jan 19 06:02:33 2011 From: jarod.smouth at gmail.com (jarod smith) Date: Wed, 19 Jan 2011 13:02:33 +0100 Subject: NAT-PT or NAT64 in real life In-Reply-To: <AANLkTik1twjfBnhcyLYvx+RBHs63hi2siCE6R9SLMgfv@mail.gmail.com> References: <AANLkTik1twjfBnhcyLYvx+RBHs63hi2siCE6R9SLMgfv@mail.gmail.com> Message-ID: <AANLkTing2SOssk-yNLOVKSPS4nTRjEwcq+itVWkhrJZC@mail.gmail.com> Thanks for your reply. In summary it's not possible to deployed IPv6 only if I want to access the whole internet :) On Wed, Jan 19, 2011 at 10:18 AM, jarod smith <jarod.smouth at gmail.com>wrote: > Although it would seem that double-stack is still the preferred method of linux > distribution, I want my next deployed in IPv6 only. > For linux there is NAT-PT tomicki and NAT64 Viagenie. > > I don't have Cisco equipment although I'd like tested their NAT-PT, even > if it's obsolete. > > Are some of you have installed one of these two implementations in > production on recent versions of linux? Is it stable, secure, ... ? > > > Regards > From jgreco at ns.sol.net Wed Jan 19 07:17:07 2011 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 19 Jan 2011 07:17:07 -0600 (CST) Subject: Software DNS hghi availability and load balancer solution In-Reply-To: <4D364B98.40803@paulgraydon.co.uk> Message-ID: <201101191317.p0JDH74H076996@aurora.sol.net> > On 01/18/2011 07:42 AM, Sergey Voropaev wrote: > > Does any one know software sollutions (free is preferable) like as cisco GSS > > and F5 BIG-IP? The main point is that DNS-server (or dns server plugin) must > > be able to monitor server availability (for example by TCP connect) and from > > DNS-reply depends on it. > > > > I know that it is possible by BIND with set of script. But we are trying to > > find more usable solution with frendly interface. > > > > Thanks a lot. > > If you want to get fancy you could try an Anycast DNS setup, using GNU's > Zebra tool to automatically alter routing tables. > http://www.netlinxinc.com/netlinx-blog/45-dns/118-introduction-to-anycast-dns.html You wouldn't use Zebra; it isn't actively developed anymore and has not been updated in many years. Use Quagga instead, which is the community-based offshoot. ... 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 jabley at hopcount.ca Wed Jan 19 07:23:09 2011 From: jabley at hopcount.ca (Joe Abley) Date: Wed, 19 Jan 2011 08:23:09 -0500 Subject: Software DNS hghi availability and load balancer solution In-Reply-To: <201101191317.p0JDH74H076996@aurora.sol.net> References: <201101191317.p0JDH74H076996@aurora.sol.net> Message-ID: <B3ABA767-D8DC-4806-A127-AD0BD5138960@hopcount.ca> On 2011-01-19, at 08:17, Joe Greco wrote: > You wouldn't use Zebra; it isn't actively developed anymore and has > not been updated in many years. Use Quagga instead, which is the > community-based offshoot. I don't think this is what the original post was asking about, but for the sake of completeness other alternatives to Zebra/Quagga (when using BGP between anycast origin servers and adjacent routers, e.g. with multipath configured on the routers) are OpenBGPd and BIRD. See earlier suggestions for bedtime reading, also: <http://www.merit.edu/mail.archives/nanog/msg06970.html>. Joe From juergen.gotteswinter at internetx.de Wed Jan 19 07:27:52 2011 From: juergen.gotteswinter at internetx.de (=?ISO-8859-1?Q?InterNetX_-_J=FCrgen_Gotteswinter?=) Date: Wed, 19 Jan 2011 14:27:52 +0100 Subject: Software DNS hghi availability and load balancer solution In-Reply-To: <alpine.BSF.2.00.1101181859590.46939@murf.icantclick.org> References: <AANLkTimyQDGp9fBiuVE3FEhSJKo-8jzrXHUF+1+aYqpX@mail.gmail.com> <4D3628B6.40709@knownelement.com> <alpine.BSF.2.00.1101181859590.46939@murf.icantclick.org> Message-ID: <4D36E6D8.9000408@internetx.de> Am 19.01.11 01:01, schrieb david raistrick: > >> On 01/18/2011 09:42 AM, Sergey Voropaev wrote: >>> Does any one know software sollutions (free is preferable) like as >>> cisco GSS >>> and F5 BIG-IP? The main point is that DNS-server (or dns server >>> plugin) must >>> be able to monitor server availability (for example by TCP connect) >>> and from >>> DNS-reply depends on it. >>> > > On Tue, 18 Jan 2011, Charles N Wyble wrote: >> >> Ha-proxy and linux virtual server are popular packages. > > Neither of these do DNS. He asked about DNS based loadbalancing (also > known as GSLB, among other things) software packages.... > haproxy doesnt, lvs works for dns very well, take a look at keepalived (www.keepalived.org). it supports lvs + vrrp. > > > -- > david raistrick http://www.netmeister.org/news/learn2quote.html > drais at icantclick.org http://www.expita.com/nomime.html > > > From ryanshea at google.com Wed Jan 19 07:36:31 2011 From: ryanshea at google.com (Ryan Shea) Date: Wed, 19 Jan 2011 08:36:31 -0500 Subject: Network Simulators In-Reply-To: <BLU158-w14E56F8349E461C62734E6DCF40@phx.gbl> References: <4D344B0D.3030602@freedomnet.co.nz> <F63C8E47-D81D-4633-B8E6-B2F94D8132A9@gmail.com> <AANLkTin0oSuSS5B41Y9C7OQUcK7dFQw=zTrH8+yZ-ZU9@mail.gmail.com> <4D345AB1.2060102@freedomnet.co.nz> <BLU158-w14E56F8349E461C62734E6DCF40@phx.gbl> Message-ID: <AANLkTinzXRVwa-sGirFLieDS6GJ7cH=YzbgOWKbXqbuJ@mail.gmail.com> You can do some switching by stuffing a virtual NM-16ESW into your faketastic 3660 in Dynamips. Then there are the built-in frame-relay and ethernet switches you could dump into the mix as well. -Ryan On Mon, Jan 17, 2011 at 10:23 AM, Brandon Kim <brandon.kim at brandontek.com>wrote: > > James: > > I've been resisting GNS3 for the longest time, because I like real > equipment and to get my hands a little dirty. > But for the purpose of simulation, GNS3 helped me identify a BGP issue last > week. If it weren't for GNS3, > I would not have been able to figure it out. > > I will be using GNS3 in the future now for as much I can. Remember it is > more router oriented than switch. > > So you can't do any fancy L3 switching...... > > > > > Date: Mon, 17 Jan 2011 10:05:21 -0500 > > From: james at freedomnet.co.nz > > To: nanog at nanog.org > > Subject: Re: Network Simulators > > > > So far GNS3 has won out so far. It seems to work on my Mac fairly well. > > trying it out now. > > > > On 17/01/11 9:37 AM, Carlos Martinez-Cagnazzo wrote: > > > I am currently researching virtual simulation environments for the > > > Networking courses that I teach. I am now interested in user-mode > > > linux emulators as they provide more real environments. > > > > > > The one that I am liking the most right now is this one: > > > http://wiki.netkit.org/index.php/Main_Page > > > > > > regards > > > > > > Carlos > > > > > > On Mon, Jan 17, 2011 at 12:20 PM, Arturo Servin< > arturo.servin at gmail.com> wrote: > > >> GNS3 > > >> http://www.gns3.net/ > > >> > > >> This is another network simulator, mainly for academic > research. > > >> > > >> NS-2 > > >> http://www.isi.edu/nsnam/ns/ > > >> > > >> And you can always setup some virtual machines with DNSs, > hosts and routers with open-source software. > > >> > > >> regards, > > >> -as > > >> > > >> On 17 Jan 2011, at 11:58, James Jones wrote: > > >> > > >>> Are there any good Network Simulators/Trainers out there that support > IPv6? I want play around with some IPv6 setup. > > >>> > > >>> -- > > >>> James Jones > > >>> +1-413-667-9199 <tel:+14136679199> > > >>> james at freedomnet.co.nz > > >>> > > >> > > > > > > > > > > From gladney at stsci.edu Wed Jan 19 07:52:20 2011 From: gladney at stsci.edu (Gary Gladney) Date: Wed, 19 Jan 2011 13:52:20 +0000 Subject: Network Simulators In-Reply-To: <AANLkTinzXRVwa-sGirFLieDS6GJ7cH=YzbgOWKbXqbuJ@mail.gmail.com> References: <4D344B0D.3030602@freedomnet.co.nz> <F63C8E47-D81D-4633-B8E6-B2F94D8132A9@gmail.com> <AANLkTin0oSuSS5B41Y9C7OQUcK7dFQw=zTrH8+yZ-ZU9@mail.gmail.com> <4D345AB1.2060102@freedomnet.co.nz> <BLU158-w14E56F8349E461C62734E6DCF40@phx.gbl> <AANLkTinzXRVwa-sGirFLieDS6GJ7cH=YzbgOWKbXqbuJ@mail.gmail.com> Message-ID: <1B0C5329DB4558419BE8B3440A66ADF306E2B432@EXCHMAIL1.stsci.edu> If you looking for network simulator for Cisco equipment it's been my experience that Boson (www.boson.com) has best network simulator for Cisco equipment. It behaves and process information the way real Cisco equipment does. I've tried GS3, it great for routing situations but lacks in simulating switches. Gary -----Original Message----- From: Ryan Shea [mailto:ryanshea at google.com] Sent: Wednesday, January 19, 2011 8:37 AM To: Brandon Kim Cc: nanog group Subject: Re: Network Simulators You can do some switching by stuffing a virtual NM-16ESW into your faketastic 3660 in Dynamips. Then there are the built-in frame-relay and ethernet switches you could dump into the mix as well. -Ryan On Mon, Jan 17, 2011 at 10:23 AM, Brandon Kim <brandon.kim at brandontek.com>wrote: > > James: > > I've been resisting GNS3 for the longest time, because I like real > equipment and to get my hands a little dirty. > But for the purpose of simulation, GNS3 helped me identify a BGP issue > last week. If it weren't for GNS3, I would not have been able to > figure it out. > > I will be using GNS3 in the future now for as much I can. Remember it > is more router oriented than switch. > > So you can't do any fancy L3 switching...... > > > > > Date: Mon, 17 Jan 2011 10:05:21 -0500 > > From: james at freedomnet.co.nz > > To: nanog at nanog.org > > Subject: Re: Network Simulators > > > > So far GNS3 has won out so far. It seems to work on my Mac fairly well. > > trying it out now. > > > > On 17/01/11 9:37 AM, Carlos Martinez-Cagnazzo wrote: > > > I am currently researching virtual simulation environments for the > > > Networking courses that I teach. I am now interested in user-mode > > > linux emulators as they provide more real environments. > > > > > > The one that I am liking the most right now is this one: > > > http://wiki.netkit.org/index.php/Main_Page > > > > > > regards > > > > > > Carlos > > > > > > On Mon, Jan 17, 2011 at 12:20 PM, Arturo Servin< > arturo.servin at gmail.com> wrote: > > >> GNS3 > > >> http://www.gns3.net/ > > >> > > >> This is another network simulator, mainly for academic > research. > > >> > > >> NS-2 > > >> http://www.isi.edu/nsnam/ns/ > > >> > > >> And you can always setup some virtual machines with DNSs, > hosts and routers with open-source software. > > >> > > >> regards, > > >> -as > > >> > > >> On 17 Jan 2011, at 11:58, James Jones wrote: > > >> > > >>> Are there any good Network Simulators/Trainers out there that > > >>> support > IPv6? I want play around with some IPv6 setup. > > >>> > > >>> -- > > >>> James Jones > > >>> +1-413-667-9199 <tel:+14136679199> > > >>> james at freedomnet.co.nz > > >>> > > >> > > > > > > > > > > From rsm at fast-serv.com Wed Jan 19 08:00:28 2011 From: rsm at fast-serv.com (Randy McAnally) Date: Wed, 19 Jan 2011 09:00:28 -0500 Subject: Dual Homed BGP for failover In-Reply-To: <007301cbb7c2$f5a63500$e0f29f00$@gmail.com> References: <003001cbb73e$0106a860$0313f920$@gmail.com> <AANLkTimF=uTuuPPhE7ouuw8gOMK7qq7QhN18zP_prinG@mail.gmail.com> <4D35E612.6010200@brightok.net> <BLU158-w48D8FEABCAD84C7FE4896ADCF70@phx.gbl> <5A6D953473350C4B9995546AFE9939EE0BC13424@RWC-EX1.corp.seven.com> <4D35FEAC.9040705@brightok.net> <AANLkTin+fWS-XjEDQ_Ybx8EOeP7ESenbU8KmUaubdQ=K@mail.gmail.com> <4D3603F4.5020501@brightok.net> <AANLkTikjZbVFBbzEyfbuvh2Ua8A3jTf+hcQ9LeGU+E1X@mail.gmail.com> <AANLkTik7HqPc2hnt640PO20vpvbXKrM1=U--2fXkW1i0@mail.gmail.com> <007301cbb7c2$f5a63500$e0f29f00$@gmail.com> Message-ID: <20110119140022.M30623@fast-serv.com> On Wed, 19 Jan 2011 10:23:47 -0000, Ahmed Yousuf wrote > - Accept that we are never going to get an ideal > distribution of traffic and continue monitoring and adjusting local > pref/prepends etc. as and when we need to change the distribution of > traffic. Hopefully we don't need to do this that often. ^ This. You're fighting a loosing battle with such slow links. Given the limited route capacity of your router you might as well set up statics aimed at each link and forget about BGP shaping. Just keep a floating default pointed at each peer. -Randy From carlosm3011 at gmail.com Wed Jan 19 08:27:27 2011 From: carlosm3011 at gmail.com (Carlos Martinez-Cagnazzo) Date: Wed, 19 Jan 2011 12:27:27 -0200 Subject: Network Simulators In-Reply-To: <1B0C5329DB4558419BE8B3440A66ADF306E2B432@EXCHMAIL1.stsci.edu> References: <4D344B0D.3030602@freedomnet.co.nz> <F63C8E47-D81D-4633-B8E6-B2F94D8132A9@gmail.com> <AANLkTin0oSuSS5B41Y9C7OQUcK7dFQw=zTrH8+yZ-ZU9@mail.gmail.com> <4D345AB1.2060102@freedomnet.co.nz> <BLU158-w14E56F8349E461C62734E6DCF40@phx.gbl> <AANLkTinzXRVwa-sGirFLieDS6GJ7cH=YzbgOWKbXqbuJ@mail.gmail.com> <1B0C5329DB4558419BE8B3440A66ADF306E2B432@EXCHMAIL1.stsci.edu> Message-ID: <AANLkTikkwtptwNxxC0CTHuJ+nHzs9SeFMZXeo13+KCBG@mail.gmail.com> Anything for Junipers ? On Wed, Jan 19, 2011 at 11:52 AM, Gary Gladney <gladney at stsci.edu> wrote: > If you looking for network simulator for Cisco equipment it's been my experience that Boson (www.boson.com) has best network simulator for Cisco equipment. ?It behaves and process information the way real Cisco equipment does. ?I've tried GS3, it great for routing situations but lacks in simulating switches. > > Gary > > -----Original Message----- > From: Ryan Shea [mailto:ryanshea at google.com] > Sent: Wednesday, January 19, 2011 8:37 AM > To: Brandon Kim > Cc: nanog group > Subject: Re: Network Simulators > > You can do some switching by stuffing a virtual NM-16ESW into your faketastic 3660 in Dynamips. Then there are the built-in frame-relay and ethernet switches you could dump into the mix as well. > > -Ryan > > On Mon, Jan 17, 2011 at 10:23 AM, Brandon Kim <brandon.kim at brandontek.com>wrote: > >> >> James: >> >> I've been resisting GNS3 for the longest time, because I like real >> equipment and to get my hands a little dirty. >> But for the purpose of simulation, GNS3 helped me identify a BGP issue >> last week. If it weren't for GNS3, I would not have been able to >> figure it out. >> >> I will be using GNS3 in the future now for as much I can. Remember it >> is more router oriented than switch. >> >> So you can't do any fancy L3 switching...... >> >> >> >> > Date: Mon, 17 Jan 2011 10:05:21 -0500 >> > From: james at freedomnet.co.nz >> > To: nanog at nanog.org >> > Subject: Re: Network Simulators >> > >> > So far GNS3 has won out so far. It seems to work on my Mac fairly well. >> > trying it out now. >> > >> > On 17/01/11 9:37 AM, Carlos Martinez-Cagnazzo wrote: >> > > I am currently researching virtual simulation environments for the >> > > Networking courses that I teach. I am now interested in user-mode >> > > linux emulators as they provide more real environments. >> > > >> > > The one that I am liking the most right now is this one: >> > > http://wiki.netkit.org/index.php/Main_Page >> > > >> > > regards >> > > >> > > Carlos >> > > >> > > On Mon, Jan 17, 2011 at 12:20 PM, Arturo Servin< >> arturo.servin at gmail.com> ?wrote: >> > >> GNS3 >> > >> http://www.gns3.net/ >> > >> >> > >> ? ? ? ? This is another network simulator, mainly for academic >> research. >> > >> >> > >> NS-2 >> > >> http://www.isi.edu/nsnam/ns/ >> > >> >> > >> ? ? ? ? And you can always setup some virtual machines with DNSs, >> hosts and routers with open-source software. >> > >> >> > >> regards, >> > >> -as >> > >> >> > >> On 17 Jan 2011, at 11:58, James Jones wrote: >> > >> >> > >>> Are there any good Network Simulators/Trainers out there that >> > >>> support >> IPv6? I want play around with some IPv6 setup. >> > >>> >> > >>> -- >> > >>> James Jones >> > >>> +1-413-667-9199 <tel:+14136679199> >> > >>> james at freedomnet.co.nz >> > >>> >> > >> >> > > >> > > >> > >> >> > > -- -- ========================= Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net ========================= From ayousuf0079 at gmail.com Wed Jan 19 08:26:32 2011 From: ayousuf0079 at gmail.com (Ahmed Yousuf) Date: Wed, 19 Jan 2011 14:26:32 -0000 Subject: Dual Homed BGP for failover In-Reply-To: <20110119140022.M30623@fast-serv.com> References: <003001cbb73e$0106a860$0313f920$@gmail.com> <AANLkTimF=uTuuPPhE7ouuw8gOMK7qq7QhN18zP_prinG@mail.gmail.com> <4D35E612.6010200@brightok.net> <BLU158-w48D8FEABCAD84C7FE4896ADCF70@phx.gbl> <5A6D953473350C4B9995546AFE9939EE0BC13424@RWC-EX1.corp.seven.com> <4D35FEAC.9040705@brightok.net> <AANLkTin+fWS-XjEDQ_Ybx8EOeP7ESenbU8KmUaubdQ=K@mail.gmail.com> <4D3603F4.5020501@brightok.net> <AANLkTikjZbVFBbzEyfbuvh2Ua8A3jTf+hcQ9LeGU+E1X@mail.gmail.com> <AANLkTik7HqPc2hnt640PO20vpvbXKrM1=U--2fXkW1i0@mail.gmail.com> <007301cbb7c2$f5a63500$e0f29f00$@gmail.com> <20110119140022.M30623@fast-serv.com> Message-ID: <008901cbb7e4$f1feb860$d5fc2920$@gmail.com> We're doing BGP to announce our PI space and make sure that our PI space is reachable through both ISPs in case one link goes down. This is the primary need to do the BGP here. Unfortunately my boss has requested that we make use of the capacity of both links, rather than pref traffic out of the higher capacity link. -----Original Message----- From: Randy McAnally [mailto:rsm at fast-serv.com] Sent: 19 January 2011 14:00 To: Ahmed Yousuf; 'nanog group' Subject: RE: Dual Homed BGP for failover On Wed, 19 Jan 2011 10:23:47 -0000, Ahmed Yousuf wrote > - Accept that we are never going to get an ideal > distribution of traffic and continue monitoring and adjusting local > pref/prepends etc. as and when we need to change the distribution of > traffic. Hopefully we don't need to do this that often. ^ This. You're fighting a loosing battle with such slow links. Given the limited route capacity of your router you might as well set up statics aimed at each link and forget about BGP shaping. Just keep a floating default pointed at each peer. -Randy From james at roketelkom.co.ug Wed Jan 19 08:45:45 2011 From: james at roketelkom.co.ug (James Byaruhanga) Date: Wed, 19 Jan 2011 17:45:45 +0300 Subject: Dual Homed BGP for failover (Ahmed Yousuf) In-Reply-To: <mailman.2071.1295447320.21807.nanog@nanog.org> Message-ID: <C95CD3BF.1FCAA%james@roketelkom.co.ug> On 2011/01/19 5:28 PM, "nanog-request at nanog.org" <nanog-request at nanog.org> wrote: >Send NANOG mailing list submissions to > nanog at nanog.org > >To subscribe or unsubscribe via the World Wide Web, visit > https://mailman.nanog.org/mailman/listinfo/nanog >or, via email, send a message with subject or body 'help' to > nanog-request at nanog.org > >You can reach the person managing the list at > nanog-owner at nanog.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of NANOG digest..." > > >Today's Topics: > > 1. Re: NAT-PT or NAT64 in real life (jarod smith) > 2. Re: Software DNS hghi availability and load balancer solution > (Joe Greco) > 3. Re: Software DNS hghi availability and load balancer solution > (Joe Abley) > 4. Re: Software DNS hghi availability and load balancer solution > (InterNetX - J?rgen Gotteswinter) > 5. Re: Network Simulators (Ryan Shea) > 6. RE: Network Simulators (Gary Gladney) > 7. RE: Dual Homed BGP for failover (Randy McAnally) > 8. Re: Network Simulators (Carlos Martinez-Cagnazzo) > 9. RE: Dual Homed BGP for failover (Ahmed Yousuf) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Wed, 19 Jan 2011 13:02:33 +0100 >From: jarod smith <jarod.smouth at gmail.com> >Subject: Re: NAT-PT or NAT64 in real life >To: nanog at nanog.org >Message-ID: > <AANLkTing2SOssk-yNLOVKSPS4nTRjEwcq+itVWkhrJZC at mail.gmail.com> >Content-Type: text/plain; charset=ISO-8859-1 > >Thanks for your reply. > >In summary it's not possible to deployed IPv6 only if I want to access the >whole internet :) > > > >On Wed, Jan 19, 2011 at 10:18 AM, jarod smith ><jarod.smouth at gmail.com>wrote: > >> Although it would seem that double-stack is still the preferred method >>of linux >> distribution, I want my next deployed in IPv6 only. >> For linux there is NAT-PT tomicki and NAT64 Viagenie. >> >> I don't have Cisco equipment although I'd like tested their NAT-PT, even >> if it's obsolete. >> >> Are some of you have installed one of these two implementations in >> production on recent versions of linux? Is it stable, secure, ... ? >> >> >> Regards >> > > >------------------------------ > >Message: 2 >Date: Wed, 19 Jan 2011 07:17:07 -0600 (CST) >From: Joe Greco <jgreco at ns.sol.net> >Subject: Re: Software DNS hghi availability and load balancer solution >To: paul at paulgraydon.co.uk (Paul Graydon) >Cc: nanog at nanog.org >Message-ID: <201101191317.p0JDH74H076996 at aurora.sol.net> >Content-Type: text/plain; charset=us-ascii > >> On 01/18/2011 07:42 AM, Sergey Voropaev wrote: >> > Does any one know software sollutions (free is preferable) like as >>cisco GSS >> > and F5 BIG-IP? The main point is that DNS-server (or dns server >>plugin) must >> > be able to monitor server availability (for example by TCP connect) >>and from >> > DNS-reply depends on it. >> > >> > I know that it is possible by BIND with set of script. But we are >>trying to >> > find more usable solution with frendly interface. >> > >> > Thanks a lot. >> >> If you want to get fancy you could try an Anycast DNS setup, using >>GNU's >> Zebra tool to automatically alter routing tables. >> >>http://www.netlinxinc.com/netlinx-blog/45-dns/118-introduction-to-anycast >>-dns.html > >You wouldn't use Zebra; it isn't actively developed anymore and has >not been updated in many years. Use Quagga instead, which is the >community-based offshoot. > >... 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. > > > >------------------------------ > >Message: 3 >Date: Wed, 19 Jan 2011 08:23:09 -0500 >From: Joe Abley <jabley at hopcount.ca> >Subject: Re: Software DNS hghi availability and load balancer solution >To: Joe Greco <jgreco at ns.sol.net> >Cc: nanog at nanog.org >Message-ID: <B3ABA767-D8DC-4806-A127-AD0BD5138960 at hopcount.ca> >Content-Type: text/plain; charset=us-ascii > > >On 2011-01-19, at 08:17, Joe Greco wrote: > >> You wouldn't use Zebra; it isn't actively developed anymore and has >> not been updated in many years. Use Quagga instead, which is the >> community-based offshoot. > >I don't think this is what the original post was asking about, but for >the sake of completeness other alternatives to Zebra/Quagga (when using >BGP between anycast origin servers and adjacent routers, e.g. with >multipath configured on the routers) are OpenBGPd and BIRD. > >See earlier suggestions for bedtime reading, also: ><http://www.merit.edu/mail.archives/nanog/msg06970.html>. > > >Joe > > > > >------------------------------ > >Message: 4 >Date: Wed, 19 Jan 2011 14:27:52 +0100 >From: InterNetX - J?rgen Gotteswinter > <juergen.gotteswinter at internetx.de> >Subject: Re: Software DNS hghi availability and load balancer solution >To: nanog at nanog.org >Message-ID: <4D36E6D8.9000408 at internetx.de> >Content-Type: text/plain; charset=ISO-8859-1; format=flowed > >Am 19.01.11 01:01, schrieb david raistrick: >> >>> On 01/18/2011 09:42 AM, Sergey Voropaev wrote: >>>> Does any one know software sollutions (free is preferable) like as >>>> cisco GSS >>>> and F5 BIG-IP? The main point is that DNS-server (or dns server >>>> plugin) must >>>> be able to monitor server availability (for example by TCP connect) >>>> and from >>>> DNS-reply depends on it. >>>> >> >> On Tue, 18 Jan 2011, Charles N Wyble wrote: >>> >>> Ha-proxy and linux virtual server are popular packages. >> >> Neither of these do DNS. He asked about DNS based loadbalancing (also >> known as GSLB, among other things) software packages.... >> > >haproxy doesnt, > > >lvs works for dns very well, take a look at keepalived >(www.keepalived.org). it supports lvs + vrrp. > >> >> >> -- >> david raistrick http://www.netmeister.org/news/learn2quote.html >> drais at icantclick.org http://www.expita.com/nomime.html >> >> >> > > > > >------------------------------ > >Message: 5 >Date: Wed, 19 Jan 2011 08:36:31 -0500 >From: Ryan Shea <ryanshea at google.com> >Subject: Re: Network Simulators >To: Brandon Kim <brandon.kim at brandontek.com> >Cc: nanog group <nanog at nanog.org> >Message-ID: > <AANLkTinzXRVwa-sGirFLieDS6GJ7cH=YzbgOWKbXqbuJ at mail.gmail.com> >Content-Type: text/plain; charset=ISO-8859-1 > >You can do some switching by stuffing a virtual NM-16ESW into your >faketastic 3660 in Dynamips. Then there are the built-in frame-relay and >ethernet switches you could dump into the mix as well. > >-Ryan > >On Mon, Jan 17, 2011 at 10:23 AM, Brandon Kim ><brandon.kim at brandontek.com>wrote: > >> >> James: >> >> I've been resisting GNS3 for the longest time, because I like real >> equipment and to get my hands a little dirty. >> But for the purpose of simulation, GNS3 helped me identify a BGP issue >>last >> week. If it weren't for GNS3, >> I would not have been able to figure it out. >> >> I will be using GNS3 in the future now for as much I can. Remember it is >> more router oriented than switch. >> >> So you can't do any fancy L3 switching...... >> >> >> >> > Date: Mon, 17 Jan 2011 10:05:21 -0500 >> > From: james at freedomnet.co.nz >> > To: nanog at nanog.org >> > Subject: Re: Network Simulators >> > >> > So far GNS3 has won out so far. It seems to work on my Mac fairly >>well. >> > trying it out now. >> > >> > On 17/01/11 9:37 AM, Carlos Martinez-Cagnazzo wrote: >> > > I am currently researching virtual simulation environments for the >> > > Networking courses that I teach. I am now interested in user-mode >> > > linux emulators as they provide more real environments. >> > > >> > > The one that I am liking the most right now is this one: >> > > http://wiki.netkit.org/index.php/Main_Page >> > > >> > > regards >> > > >> > > Carlos >> > > >> > > On Mon, Jan 17, 2011 at 12:20 PM, Arturo Servin< >> arturo.servin at gmail.com> wrote: >> > >> GNS3 >> > >> http://www.gns3.net/ >> > >> >> > >> This is another network simulator, mainly for academic >> research. >> > >> >> > >> NS-2 >> > >> http://www.isi.edu/nsnam/ns/ >> > >> >> > >> And you can always setup some virtual machines with DNSs, >> hosts and routers with open-source software. >> > >> >> > >> regards, >> > >> -as >> > >> >> > >> On 17 Jan 2011, at 11:58, James Jones wrote: >> > >> >> > >>> Are there any good Network Simulators/Trainers out there that >>support >> IPv6? I want play around with some IPv6 setup. >> > >>> >> > >>> -- >> > >>> James Jones >> > >>> +1-413-667-9199 <tel:+14136679199> >> > >>> james at freedomnet.co.nz >> > >>> >> > >> >> > > >> > > >> > >> >> > > >------------------------------ > >Message: 6 >Date: Wed, 19 Jan 2011 13:52:20 +0000 >From: Gary Gladney <gladney at stsci.edu> >Subject: RE: Network Simulators >To: Brandon Kim <brandon.kim at brandontek.com> >Cc: nanog group <nanog at nanog.org> >Message-ID: > <1B0C5329DB4558419BE8B3440A66ADF306E2B432 at EXCHMAIL1.stsci.edu> >Content-Type: text/plain; charset="us-ascii" > >If you looking for network simulator for Cisco equipment it's been my >experience that Boson (www.boson.com) has best network simulator for >Cisco equipment. It behaves and process information the way real Cisco >equipment does. I've tried GS3, it great for routing situations but >lacks in simulating switches. > >Gary > >-----Original Message----- >From: Ryan Shea [mailto:ryanshea at google.com] >Sent: Wednesday, January 19, 2011 8:37 AM >To: Brandon Kim >Cc: nanog group >Subject: Re: Network Simulators > >You can do some switching by stuffing a virtual NM-16ESW into your >faketastic 3660 in Dynamips. Then there are the built-in frame-relay and >ethernet switches you could dump into the mix as well. > >-Ryan > >On Mon, Jan 17, 2011 at 10:23 AM, Brandon Kim ><brandon.kim at brandontek.com>wrote: > >> >> James: >> >> I've been resisting GNS3 for the longest time, because I like real >> equipment and to get my hands a little dirty. >> But for the purpose of simulation, GNS3 helped me identify a BGP issue >> last week. If it weren't for GNS3, I would not have been able to >> figure it out. >> >> I will be using GNS3 in the future now for as much I can. Remember it >> is more router oriented than switch. >> >> So you can't do any fancy L3 switching...... >> >> >> >> > Date: Mon, 17 Jan 2011 10:05:21 -0500 >> > From: james at freedomnet.co.nz >> > To: nanog at nanog.org >> > Subject: Re: Network Simulators >> > >> > So far GNS3 has won out so far. It seems to work on my Mac fairly >>well. >> > trying it out now. >> > >> > On 17/01/11 9:37 AM, Carlos Martinez-Cagnazzo wrote: >> > > I am currently researching virtual simulation environments for the >> > > Networking courses that I teach. I am now interested in user-mode >> > > linux emulators as they provide more real environments. >> > > >> > > The one that I am liking the most right now is this one: >> > > http://wiki.netkit.org/index.php/Main_Page >> > > >> > > regards >> > > >> > > Carlos >> > > >> > > On Mon, Jan 17, 2011 at 12:20 PM, Arturo Servin< >> arturo.servin at gmail.com> wrote: >> > >> GNS3 >> > >> http://www.gns3.net/ >> > >> >> > >> This is another network simulator, mainly for academic >> research. >> > >> >> > >> NS-2 >> > >> http://www.isi.edu/nsnam/ns/ >> > >> >> > >> And you can always setup some virtual machines with DNSs, >> hosts and routers with open-source software. >> > >> >> > >> regards, >> > >> -as >> > >> >> > >> On 17 Jan 2011, at 11:58, James Jones wrote: >> > >> >> > >>> Are there any good Network Simulators/Trainers out there that >> > >>> support >> IPv6? I want play around with some IPv6 setup. >> > >>> >> > >>> -- >> > >>> James Jones >> > >>> +1-413-667-9199 <tel:+14136679199> >> > >>> james at freedomnet.co.nz >> > >>> >> > >> >> > > >> > > >> > >> >> > > > >------------------------------ > >Message: 7 >Date: Wed, 19 Jan 2011 09:00:28 -0500 >From: "Randy McAnally" <rsm at fast-serv.com> >Subject: RE: Dual Homed BGP for failover >To: "Ahmed Yousuf" <ayousuf0079 at gmail.com>,"'nanog group'" > <nanog at nanog.org> >Message-ID: <20110119140022.M30623 at fast-serv.com> >Content-Type: text/plain; charset=iso-8859-1 > >On Wed, 19 Jan 2011 10:23:47 -0000, Ahmed Yousuf wrote > >> - Accept that we are never going to get an ideal >> distribution of traffic and continue monitoring and adjusting local >> pref/prepends etc. as and when we need to change the distribution of >> traffic. Hopefully we don't need to do this that often. > > >^ This. You're fighting a loosing battle with such slow links. Given the >limited route capacity of your router you might as well set up statics >aimed >at each link and forget about BGP shaping. Just keep a floating default >pointed at each peer. > >-Randy > > > >------------------------------ > >Message: 8 >Date: Wed, 19 Jan 2011 12:27:27 -0200 >From: Carlos Martinez-Cagnazzo <carlosm3011 at gmail.com> >Subject: Re: Network Simulators >To: nanog at nanog.org >Message-ID: > <AANLkTikkwtptwNxxC0CTHuJ+nHzs9SeFMZXeo13+KCBG at mail.gmail.com> >Content-Type: text/plain; charset=ISO-8859-1 > >Anything for Junipers ? > >On Wed, Jan 19, 2011 at 11:52 AM, Gary Gladney <gladney at stsci.edu> wrote: >> If you looking for network simulator for Cisco equipment it's been my >>experience that Boson (www.boson.com) has best network simulator for >>Cisco equipment. ?It behaves and process information the way real Cisco >>equipment does. ?I've tried GS3, it great for routing situations but >>lacks in simulating switches. >> >> Gary >> >> -----Original Message----- >> From: Ryan Shea [mailto:ryanshea at google.com] >> Sent: Wednesday, January 19, 2011 8:37 AM >> To: Brandon Kim >> Cc: nanog group >> Subject: Re: Network Simulators >> >> You can do some switching by stuffing a virtual NM-16ESW into your >>faketastic 3660 in Dynamips. Then there are the built-in frame-relay and >>ethernet switches you could dump into the mix as well. >> >> -Ryan >> >> On Mon, Jan 17, 2011 at 10:23 AM, Brandon Kim >><brandon.kim at brandontek.com>wrote: >> >>> >>> James: >>> >>> I've been resisting GNS3 for the longest time, because I like real >>> equipment and to get my hands a little dirty. >>> But for the purpose of simulation, GNS3 helped me identify a BGP issue >>> last week. If it weren't for GNS3, I would not have been able to >>> figure it out. >>> >>> I will be using GNS3 in the future now for as much I can. Remember it >>> is more router oriented than switch. >>> >>> So you can't do any fancy L3 switching...... >>> >>> >>> >>> > Date: Mon, 17 Jan 2011 10:05:21 -0500 >>> > From: james at freedomnet.co.nz >>> > To: nanog at nanog.org >>> > Subject: Re: Network Simulators >>> > >>> > So far GNS3 has won out so far. It seems to work on my Mac fairly >>>well. >>> > trying it out now. >>> > >>> > On 17/01/11 9:37 AM, Carlos Martinez-Cagnazzo wrote: >>> > > I am currently researching virtual simulation environments for the >>> > > Networking courses that I teach. I am now interested in user-mode >>> > > linux emulators as they provide more real environments. >>> > > >>> > > The one that I am liking the most right now is this one: >>> > > http://wiki.netkit.org/index.php/Main_Page >>> > > >>> > > regards >>> > > >>> > > Carlos >>> > > >>> > > On Mon, Jan 17, 2011 at 12:20 PM, Arturo Servin< >>> arturo.servin at gmail.com> ?wrote: >>> > >> GNS3 >>> > >> http://www.gns3.net/ >>> > >> >>> > >> ? ? ? ? This is another network simulator, mainly for academic >>> research. >>> > >> >>> > >> NS-2 >>> > >> http://www.isi.edu/nsnam/ns/ >>> > >> >>> > >> ? ? ? ? And you can always setup some virtual machines with DNSs, >>> hosts and routers with open-source software. >>> > >> >>> > >> regards, >>> > >> -as >>> > >> >>> > >> On 17 Jan 2011, at 11:58, James Jones wrote: >>> > >> >>> > >>> Are there any good Network Simulators/Trainers out there that >>> > >>> support >>> IPv6? I want play around with some IPv6 setup. >>> > >>> >>> > >>> -- >>> > >>> James Jones >>> > >>> +1-413-667-9199 <tel:+14136679199> >>> > >>> james at freedomnet.co.nz >>> > >>> >>> > >> >>> > > >>> > > >>> > >>> >>> >> >> > > > >-- >-- >========================= >Carlos M. Martinez-Cagnazzo >http://www.labs.lacnic.net >========================= > > > >------------------------------ > >Message: 9 >Date: Wed, 19 Jan 2011 14:26:32 -0000 >From: "Ahmed Yousuf" <ayousuf0079 at gmail.com> >Subject: RE: Dual Homed BGP for failover >To: "'nanog group'" <nanog at nanog.org> >Message-ID: <008901cbb7e4$f1feb860$d5fc2920$@gmail.com> >Content-Type: text/plain; charset="us-ascii" > >We're doing BGP to announce our PI space and make sure that our PI space >is >reachable through both ISPs in case one link goes down. This is the >primary >need to do the BGP here. Unfortunately my boss has requested that we make >use of the capacity of both links, rather than pref traffic out of the >higher capacity link. > >-----Original Message----- >From: Randy McAnally [mailto:rsm at fast-serv.com] >Sent: 19 January 2011 14:00 >To: Ahmed Yousuf; 'nanog group' >Subject: RE: Dual Homed BGP for failover > >On Wed, 19 Jan 2011 10:23:47 -0000, Ahmed Yousuf wrote > >> - Accept that we are never going to get an ideal >> distribution of traffic and continue monitoring and adjusting local >> pref/prepends etc. as and when we need to change the distribution of >> traffic. Hopefully we don't need to do this that often. > > >^ This. You're fighting a loosing battle with such slow links. Given the >limited route capacity of your router you might as well set up statics >aimed >at each link and forget about BGP shaping. Just keep a floating default >pointed at each peer. > >-Randy > > > > >------------------------------ > >_______________________________________________ >NANOG mailing list >NANOG at nanog.org >https://mailman.nanog.org/mailman/listinfo/nanog > >End of NANOG Digest, Vol 36, Issue 120 >************************************** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, re-transmission, dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error please contact the sender immediately by returning electronic transmission and then immediately delete this transmission including all attachments without copying distributing or disclosing the same. Any views or opinions presented are solely those of the author and do not necessarily represent those of Roke Telkom. From rsm at fast-serv.com Wed Jan 19 08:55:29 2011 From: rsm at fast-serv.com (Randy McAnally) Date: Wed, 19 Jan 2011 09:55:29 -0500 Subject: Dual Homed BGP for failover In-Reply-To: <008901cbb7e4$f1feb860$d5fc2920$@gmail.com> References: <003001cbb73e$0106a860$0313f920$@gmail.com> <AANLkTimF=uTuuPPhE7ouuw8gOMK7qq7QhN18zP_prinG@mail.gmail.com> <4D35E612.6010200@brightok.net> <BLU158-w48D8FEABCAD84C7FE4896ADCF70@phx.gbl> <5A6D953473350C4B9995546AFE9939EE0BC13424@RWC-EX1.corp.seven.com> <4D35FEAC.9040705@brightok.net> <AANLkTin+fWS-XjEDQ_Ybx8EOeP7ESenbU8KmUaubdQ=K@mail.gmail.com> <4D3603F4.5020501@brightok.net> <AANLkTikjZbVFBbzEyfbuvh2Ua8A3jTf+hcQ9LeGU+E1X@mail.gmail.com> <AANLkTik7HqPc2hnt640PO20vpvbXKrM1=U--2fXkW1i0@mail.gmail.com> <007301cbb7c2$f5a63500$e0f29f00$@gmail.com> <20110119140022.M30623@fast-serv.com> <008901cbb7e4$f1feb860$d5fc2920$@gmail.com> Message-ID: <20110119144831.M81477@fast-serv.com> On Wed, 19 Jan 2011 14:26:32 -0000, Ahmed Yousuf wrote > We're doing BGP to announce our PI space and make sure that our PI > space is reachable through both ISPs in case one link goes down. > This is the primary need to do the BGP here. Unfortunately my boss > has requested that we make use of the capacity of both links, rather > than pref traffic out of the higher capacity link. Understood! you would _still_ take default BGP routes, I was implying more along the lines (in cisco speak): ! Tweak as necessary to get a good balance ip route 0.0.0.0 128.0.0.0 <peer1> ip route 128.0.0.0 128.0.0.0 <peer2> Set up SLA tracking on the peer IPs to retract the routes if either peer goes down. Either that or get more RAM on your router and go the BGP-only method. -Randy From jbates at brightok.net Wed Jan 19 09:20:45 2011 From: jbates at brightok.net (Jack Bates) Date: Wed, 19 Jan 2011 09:20:45 -0600 Subject: Network Simulators In-Reply-To: <AANLkTikkwtptwNxxC0CTHuJ+nHzs9SeFMZXeo13+KCBG@mail.gmail.com> References: <4D344B0D.3030602@freedomnet.co.nz> <F63C8E47-D81D-4633-B8E6-B2F94D8132A9@gmail.com> <AANLkTin0oSuSS5B41Y9C7OQUcK7dFQw=zTrH8+yZ-ZU9@mail.gmail.com> <4D345AB1.2060102@freedomnet.co.nz> <BLU158-w14E56F8349E461C62734E6DCF40@phx.gbl> <AANLkTinzXRVwa-sGirFLieDS6GJ7cH=YzbgOWKbXqbuJ@mail.gmail.com> <1B0C5329DB4558419BE8B3440A66ADF306E2B432@EXCHMAIL1.stsci.edu> <AANLkTikkwtptwNxxC0CTHuJ+nHzs9SeFMZXeo13+KCBG@mail.gmail.com> Message-ID: <4D37014D.8050602@brightok.net> On 1/19/2011 8:27 AM, Carlos Martinez-Cagnazzo wrote: > Anything for Junipers ? > Olive? Do you dare? > On Wed, Jan 19, 2011 at 11:52 AM, Gary Gladney<gladney at stsci.edu> wrote: >> If you looking for network simulator for Cisco equipment it's been my experience that Boson (www.boson.com) has best network simulator for Cisco equipment. It behaves and process information the way real Cisco equipment does. I've tried GS3, it great for routing situations but lacks in simulating switches. >> From dmm at 1-4-5.net Wed Jan 19 10:55:25 2011 From: dmm at 1-4-5.net (David Meyer) Date: Wed, 19 Jan 2011 08:55:25 -0800 Subject: NANOG 51 Agenda posted Message-ID: <AANLkTikCbJQvGamj6jfPkWkzjEjYs1qzuT5BgnEPKDoZ@mail.gmail.com> Folks, See http://www.nanog.org/meetings/nanog51/agenda.php See you in Miami, Dave (for the NANOG PC) From cb.list6 at gmail.com Wed Jan 19 10:56:44 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Wed, 19 Jan 2011 08:56:44 -0800 Subject: NAT-PT or NAT64 in real life In-Reply-To: <AANLkTik1twjfBnhcyLYvx+RBHs63hi2siCE6R9SLMgfv@mail.gmail.com> References: <AANLkTik1twjfBnhcyLYvx+RBHs63hi2siCE6R9SLMgfv@mail.gmail.com> Message-ID: <AANLkTikWHGg01SpfK0ijQHv7Q0jiwZvWLmxv==GNJj2M@mail.gmail.com> On Wed, Jan 19, 2011 at 1:18 AM, jarod smith <jarod.smouth at gmail.com> wrote: > Although it would seem that double-stack is still the preferred method of linux > distribution, I want my next deployed in IPv6 only. > For linux there is NAT-PT tomicki and NAT64 Viagenie. > > I don't have Cisco equipment although I'd like tested their NAT-PT, even if > it's obsolete. > There are some lessons learned here with NAT-PT http://www.civil-tongue.net/6and4/wiki But, i would only use NAT-PT for ... no ... i would never use NAT-PT. The implementations are really not good. > Are some of you have installed one of these two implementations in > production on recent versions of linux? Is it stable, secure, ... ? > I have tested 3 versions of DNS64 and 4 versions of NAT64. I am not sure what i can share about them. My experience has generally been good. I feel good with taking my selected vendors to production with this feature. Users in my beta trial have been happy with the results and performance. You mentioned Cisco. Cisco has stateless support today of NAT64, but i am not sure the value of that since it is one for one. I assume they will have stateful support soon. http://www.cisco.com/en/US/docs/ios/ios_xe/ipaddr/configuration/guide/iad_stateless_nat64_xe.html aka http://tinyurl.com/4gt9s9y Juniper has stateful NAT64 today in production code, i have not looked at this one yet, but it appears promising http://www.juniper.net/techpubs/en_US/junos10.4/information-products/topic-collections/nce/nat64-ipv6-ipv4-depletion/configuring-nat64-ipv6-ipv4-depletion.pdf aka http://tinyurl.com/4qxjahk If you are talking about servers, not users, most of the commercial load balancers have NAT64 functions for the IPv6 user to IPv4 legacy server use case. Cameron ====== http://groups.google.com/group/tmoipv6beta ====== > > Regards > From strizhov at netsec.colostate.edu Wed Jan 19 11:24:22 2011 From: strizhov at netsec.colostate.edu (Mikhail Strizhov) Date: Wed, 19 Jan 2011 10:24:22 -0700 Subject: NAT-PT or NAT64 in real life In-Reply-To: <AANLkTik1twjfBnhcyLYvx+RBHs63hi2siCE6R9SLMgfv@mail.gmail.com> References: <AANLkTik1twjfBnhcyLYvx+RBHs63hi2siCE6R9SLMgfv@mail.gmail.com> Message-ID: <4D371E46.7000201@netsec.colostate.edu> Hi, I didn't use NAT-PT, but have lot of experience with NAT64/DNS64. We've deployed NAT64 with DNS64 in our test lab with last Fedora linux workstations , so far, it works fine. -- Sincerely, Mikhail Strizhov Email: strizhov at netsec.colostate.edu <mailto:strizhov at netsec.colostate.edu> On 01/19/2011 02:18 AM, jarod smith wrote: > Although it would seem that double-stack is still the preferred method of linux > distribution, I want my next deployed in IPv6 only. > For linux there is NAT-PT tomicki and NAT64 Viagenie. > > I don't have Cisco equipment although I'd like tested their NAT-PT, even if > it's obsolete. > > Are some of you have installed one of these two implementations in > production on recent versions of linux? Is it stable, secure, ... ? > > > Regards From cburwell at gmail.com Wed Jan 19 14:56:15 2011 From: cburwell at gmail.com (Chris Burwell) Date: Wed, 19 Jan 2011 15:56:15 -0500 Subject: Verizon FiOS Distribution Switch Message-ID: <AANLkTi=4OBgA2sUZT8ZTB46hryE1K6cmiK5nQ3=ENRnT@mail.gmail.com> I have a question about a Verizon FiOS business connection with an ethernet hand off and I am hoping that someone out there has done the same thing. We have a FiOS business connection coming into our building. This includes an Ethernet hand off into the usual Actiontec router as well as a block of 13 public IP addresses. The Actiontec router needs to remain in place with its current Public IP address. We have some devices from a vendor plugged into it for Internet access, as well as numerous cable boxes across the building that get their guide information through the coax interface on the router. What we want to do is take the ethernet hand off out of the WAN (RJ-45) interface on the Actiontec router and plug it into a hardened Cisco switch such as a 2950. Our goal here is to use the Cisco switch as a Internet distribution switch since we will have numerous test devices that will need to have a direct connection to the Internet. Our preference is also not to have all of the traffic from these other devices traverse the Actiontec router. I have a few concerns with this setup: Some articles I have read indicate that the hand off from the Verizon ONT may not be a direct Ethernet hand off so the interface it connects to may require a different config (Dialer or something). I am also concerned about any issues if the ONT or some down stream Verizon device may cause if it sees multiple MAC addresses coming across our link. We're not trying to cheat the system or anything, just to modify the Verizon setup to better suit our needs. Any advice or tips would be helpful. - Chris From ed at edgeoc.net Wed Jan 19 15:07:57 2011 From: ed at edgeoc.net (Edward Salonia) Date: Wed, 19 Jan 2011 21:07:57 +0000 Subject: Verizon FiOS Distribution Switch In-Reply-To: <AANLkTi=4OBgA2sUZT8ZTB46hryE1K6cmiK5nQ3=ENRnT@mail.gmail.com> References: <AANLkTi=4OBgA2sUZT8ZTB46hryE1K6cmiK5nQ3=ENRnT@mail.gmail.com> Message-ID: <1495731216-1295471278-cardhu_decombobulator_blackberry.rim.net-1002804554-@bda522.bisx.prod.on.blackberry> I have done this exact thing. We had a client with a block of public ips and they needed the actiontec router to stay connected for the cable boxes. Just put the switch between the ONT ethernet port and the actiontec WAN port and you should be fine. Just make sure the ethernet port is active on the ONT and that they dont just have the MoCA port active as I have seen this. If that's the case a simple phonecall to verizon should solve this... Assuming you get a capable tech on the line. Good luck. - Ed -----Original Message----- From: Chris Burwell <cburwell at gmail.com> Date: Wed, 19 Jan 2011 15:56:15 To: NANOG<nanog at nanog.org> Subject: Verizon FiOS Distribution Switch I have a question about a Verizon FiOS business connection with an ethernet hand off and I am hoping that someone out there has done the same thing. We have a FiOS business connection coming into our building. This includes an Ethernet hand off into the usual Actiontec router as well as a block of 13 public IP addresses. The Actiontec router needs to remain in place with its current Public IP address. We have some devices from a vendor plugged into it for Internet access, as well as numerous cable boxes across the building that get their guide information through the coax interface on the router. What we want to do is take the ethernet hand off out of the WAN (RJ-45) interface on the Actiontec router and plug it into a hardened Cisco switch such as a 2950. Our goal here is to use the Cisco switch as a Internet distribution switch since we will have numerous test devices that will need to have a direct connection to the Internet. Our preference is also not to have all of the traffic from these other devices traverse the Actiontec router. I have a few concerns with this setup: Some articles I have read indicate that the hand off from the Verizon ONT may not be a direct Ethernet hand off so the interface it connects to may require a different config (Dialer or something). I am also concerned about any issues if the ONT or some down stream Verizon device may cause if it sees multiple MAC addresses coming across our link. We're not trying to cheat the system or anything, just to modify the Verizon setup to better suit our needs. Any advice or tips would be helpful. - Chris From graham at g-rock.net Wed Jan 19 15:28:56 2011 From: graham at g-rock.net (=?utf-8?B?R1AgV29vZGVu?=) Date: Wed, 19 Jan 2011 15:28:56 -0600 Subject: =?utf-8?B?UmU6IFZlcml6b24gRmlPUyBEaXN0cmlidXRpb24gU3dpdGNo?= Message-ID: <20110119212917.E0EE9FF81BE@sociald.mobis.leasedminds.com> Not that this is a requirement, but good practice none the less with this setup... Turn off cdp on the port facing the LEC... -graham ----- Reply message ----- From: "Chris Burwell" <cburwell at gmail.com> Date: Wed, Jan 19, 2011 2:56 pm Subject: Verizon FiOS Distribution Switch To: "NANOG" <nanog at nanog.org> I have a question about a Verizon FiOS business connection with an ethernet hand off and I am hoping that someone out there has done the same thing. We have a FiOS business connection coming into our building. This includes an Ethernet hand off into the usual Actiontec router as well as a block of 13 public IP addresses. The Actiontec router needs to remain in place with its current Public IP address. We have some devices from a vendor plugged into it for Internet access, as well as numerous cable boxes across the building that get their guide information through the coax interface on the router. What we want to do is take the ethernet hand off out of the WAN (RJ-45) interface on the Actiontec router and plug it into a hardened Cisco switch such as a 2950. Our goal here is to use the Cisco switch as a Internet distribution switch since we will have numerous test devices that will need to have a direct connection to the Internet. Our preference is also not to have all of the traffic from these other devices traverse the Actiontec router. I have a few concerns with this setup: Some articles I have read indicate that the hand off from the Verizon ONT may not be a direct Ethernet hand off so the interface it connects to may require a different config (Dialer or something). I am also concerned about any issues if the ONT or some down stream Verizon device may cause if it sees multiple MAC addresses coming across our link. We're not trying to cheat the system or anything, just to modify the Verizon setup to better suit our needs. Any advice or tips would be helpful. - Chris From mike-nanog at tiedyenetworks.com Wed Jan 19 16:25:34 2011 From: mike-nanog at tiedyenetworks.com (Mike) Date: Wed, 19 Jan 2011 14:25:34 -0800 Subject: Verizon FiOS Distribution Switch In-Reply-To: <20110119212917.E0EE9FF81BE@sociald.mobis.leasedminds.com> References: <20110119212917.E0EE9FF81BE@sociald.mobis.leasedminds.com> Message-ID: <4D3764DE.20703@tiedyenetworks.com> On 01/19/2011 01:28 PM, GP Wooden wrote: > Not that this is a requirement, but good practice none the less with this setup... Turn off cdp on the port facing the LEC... > +1 also add 'nonegotiate' and turn off spanning tree on the port while you're at it. There's a list somewhere of standard stuff when connecting to an untrusted l2 network, which is what you should treat anything (including FiOS) connecting to you that you don't own. From dholmes at mwdh2o.com Wed Jan 19 16:50:13 2011 From: dholmes at mwdh2o.com (Holmes,David A) Date: Wed, 19 Jan 2011 14:50:13 -0800 Subject: Is anyone Using Talari Networks WAN Optimizer? Message-ID: <922ACC42D498884AA02B3565688AF99531D8A8BF8B@USEXMBS01.mwd.h2o> Talari management apparently has experience at the old Routescience BGP load-balancer startup, so this warrants a closer look. Has anyone used their products? From sshafi at gmail.com Wed Jan 19 17:21:15 2011 From: sshafi at gmail.com (Shahid Shafi) Date: Wed, 19 Jan 2011 15:21:15 -0800 Subject: Is anyone Using Talari Networks WAN Optimizer? In-Reply-To: <922ACC42D498884AA02B3565688AF99531D8A8BF8B@USEXMBS01.mwd.h2o> References: <922ACC42D498884AA02B3565688AF99531D8A8BF8B@USEXMBS01.mwd.h2o> Message-ID: <AANLkTi=U7sdepaPCZiJyPEHfy5=ws3ViaC=-+6WEa34t@mail.gmail.com> We are considering them but bit concern as they do forwarding plane optimization instead of control plane in case of Route Science. thanks, Shahid On Wed, Jan 19, 2011 at 2:50 PM, Holmes,David A <dholmes at mwdh2o.com> wrote: > Talari management apparently has experience at the old Routescience BGP > load-balancer startup, so this warrants a closer look. Has anyone used their > products? > > From brandon.kim at brandontek.com Wed Jan 19 18:35:43 2011 From: brandon.kim at brandontek.com (Brandon Kim) Date: Wed, 19 Jan 2011 19:35:43 -0500 Subject: Securing Border Routers Message-ID: <BLU158-w13F6A3CA3CEC3895852E48DCF90@phx.gbl> Gents: What measures do you take to protect your border routers? Our routers are running BGP so I'm interested if there is any way to secure them without interfering with BGP? Is it normal to put a firewall in front of the border routers? I'm concerned about DDOS attacks mainly....although we haven't had any, I don't welcome them..... Brandon From Bryan.Welch at arrisi.com Wed Jan 19 18:38:43 2011 From: Bryan.Welch at arrisi.com (Welch, Bryan) Date: Wed, 19 Jan 2011 16:38:43 -0800 Subject: Securing Border Routers In-Reply-To: <BLU158-w13F6A3CA3CEC3895852E48DCF90@phx.gbl> References: <BLU158-w13F6A3CA3CEC3895852E48DCF90@phx.gbl> Message-ID: <DFA5AECDEC85EE4087D45C463C19B375134D703DE1@KWAEXMAIL1.ARRS.ARRISI.COM> I ALWAYS start with the CYMRU secure bgp templates, found here: http://www.team-cymru.org/ReadingRoom/Templates/secure-bgp-template.html I personally would not recommend a firewall in front of your router, sufficient ACL'ing should be enough for securing the router itself. Bryan -----Original Message----- From: Brandon Kim [mailto:brandon.kim at brandontek.com] Sent: Wednesday, January 19, 2011 4:36 PM To: nanog group Subject: Securing Border Routers Gents: What measures do you take to protect your border routers? Our routers are running BGP so I'm interested if there is any way to secure them without interfering with BGP? Is it normal to put a firewall in front of the border routers? I'm concerned about DDOS attacks mainly....although we haven't had any, I don't welcome them..... Brandon From ryanshea at google.com Wed Jan 19 19:11:08 2011 From: ryanshea at google.com (Ryan Shea) Date: Wed, 19 Jan 2011 20:11:08 -0500 Subject: Securing Border Routers In-Reply-To: <BLU158-w13F6A3CA3CEC3895852E48DCF90@phx.gbl> References: <BLU158-w13F6A3CA3CEC3895852E48DCF90@phx.gbl> Message-ID: <AANLkTikSTaxTduyw=yV=E9N1zMNM0Kkz35z62n9RqjpG@mail.gmail.com> A stateful firewall outside of your router may create a new bottleneck which increases your risk of DoS. Making sure that you know (and document, and test) how to effectively contact your service providers should you be attacked would be a good idea. Find out if your service providers have BGP communities for remote triggered black hole (document and test). A denial of service will break the weakest link in the chain toward your services, so make sure you have appropriate bandwidth, a reasonable server architecture, and if you have money to burn consider a DDoS mitigation service. -Ryan On Wed, Jan 19, 2011 at 7:35 PM, Brandon Kim <brandon.kim at brandontek.com>wrote: > > Gents: > > What measures do you take to protect your border routers? Our routers are > running BGP so I'm interested > if there is any way to secure them without interfering with BGP? Is it > normal to put a firewall in front of the > border routers? > > I'm concerned about DDOS attacks mainly....although we haven't had any, I > don't welcome them..... > > Brandon > > > > > From brandon.kim at brandontek.com Wed Jan 19 19:38:39 2011 From: brandon.kim at brandontek.com (Brandon Kim) Date: Wed, 19 Jan 2011 20:38:39 -0500 Subject: Securing Border Routers In-Reply-To: <DFA5AECDEC85EE4087D45C463C19B375134D703DE1@KWAEXMAIL1.ARRS.ARRISI.COM> References: <BLU158-w13F6A3CA3CEC3895852E48DCF90@phx.gbl>, <DFA5AECDEC85EE4087D45C463C19B375134D703DE1@KWAEXMAIL1.ARRS.ARRISI.COM> Message-ID: <BLU158-w57A22B157DAF65737032D8DCF90@phx.gbl> What an insightful link! Thank you, I am reading it now..... > From: Bryan.Welch at arrisi.com > To: nanog at nanog.org > Date: Wed, 19 Jan 2011 16:38:43 -0800 > Subject: RE: Securing Border Routers > > I ALWAYS start with the CYMRU secure bgp templates, found here: > http://www.team-cymru.org/ReadingRoom/Templates/secure-bgp-template.html > > I personally would not recommend a firewall in front of your router, sufficient ACL'ing should be enough for securing the router itself. > > > Bryan > > -----Original Message----- > From: Brandon Kim [mailto:brandon.kim at brandontek.com] > Sent: Wednesday, January 19, 2011 4:36 PM > To: nanog group > Subject: Securing Border Routers > > > Gents: > > What measures do you take to protect your border routers? Our routers are running BGP so I'm interested if there is any way to secure them without interfering with BGP? Is it normal to put a firewall in front of the border routers? > > I'm concerned about DDOS attacks mainly....although we haven't had any, I don't welcome them..... > > Brandon > > > > > > From deleskie at gmail.com Wed Jan 19 20:04:05 2011 From: deleskie at gmail.com (jim deleskie) Date: Wed, 19 Jan 2011 22:04:05 -0400 Subject: Securing Border Routers In-Reply-To: <BLU158-w57A22B157DAF65737032D8DCF90@phx.gbl> References: <BLU158-w13F6A3CA3CEC3895852E48DCF90@phx.gbl> <DFA5AECDEC85EE4087D45C463C19B375134D703DE1@KWAEXMAIL1.ARRS.ARRISI.COM> <BLU158-w57A22B157DAF65737032D8DCF90@phx.gbl> Message-ID: <AANLkTimd7o4wNop6ysJ5Ba0UTz-OOVBkrd-+wTwo5XBy@mail.gmail.com> Never put a firewall in front of a router, it will die first. The team CYMRU stuff is great make sure you have ACL's on your VTY and allow access only from trusted internal IPs. I also like using non world routable space on any interface I can. On Wed, Jan 19, 2011 at 9:38 PM, Brandon Kim <brandon.kim at brandontek.com>wrote: > > > > What an insightful link! Thank you, I am reading it now..... > > > > > > From: Bryan.Welch at arrisi.com > > To: nanog at nanog.org > > Date: Wed, 19 Jan 2011 16:38:43 -0800 > > Subject: RE: Securing Border Routers > > > > I ALWAYS start with the CYMRU secure bgp templates, found here: > > http://www.team-cymru.org/ReadingRoom/Templates/secure-bgp-template.html > > > > I personally would not recommend a firewall in front of your router, > sufficient ACL'ing should be enough for securing the router itself. > > > > > > Bryan > > > > -----Original Message----- > > From: Brandon Kim [mailto:brandon.kim at brandontek.com] > > Sent: Wednesday, January 19, 2011 4:36 PM > > To: nanog group > > Subject: Securing Border Routers > > > > > > Gents: > > > > What measures do you take to protect your border routers? Our routers are > running BGP so I'm interested if there is any way to secure them without > interfering with BGP? Is it normal to put a firewall in front of the border > routers? > > > > I'm concerned about DDOS attacks mainly....although we haven't had any, I > don't welcome them..... > > > > Brandon > > > > > > > > > > > > > > From tmagill at providecommerce.com Wed Jan 19 20:04:36 2011 From: tmagill at providecommerce.com (Thomas Magill) Date: Thu, 20 Jan 2011 02:04:36 +0000 Subject: Update Spamhaus DROP list from Cisco CLI (TCL) Message-ID: <A1B9BAEA8FE39847BCD6C473E894B595027BF5E0@SDEXMB02.Proflowers.com> Previous conversations made me decide this would be fun to do so I ignored all my real work today and made it happen. I built a TCL script that can be mapped to an alias ("alias exec updatedrop tclsh updatedrop.tcl") that will connect to the Spamhaus DROP list and route all of the prefixes to null0. It should alsbo be able to be mapped to a kron job, but I haven't tested that and I've heard there are issues with kron+tcl unless you tie it to an EEM event. It adds a name indicator (Spamhaus_SBLXXXXX) to all of the routes to show that they come from the DROP list. You can find the script at: http://tmagill.net/cisco_networking_ccie_studies/?p=83 There is also a script to remove all of the Spamhaus_SBLXXXXX null routes. If I were to redis these into BGP they could be propagated just like the CYMRU Bogons... I plan on doing that within the next week and start testing. Does anyone see that as a useful service to be offered? Thomas Magill Network Engineer Office: (858) 909-3777 Cell: (858) 869-9685 tmagill at providecommerce.com<mailto:tmagill at providecommerce.com> provide-commerce 4840 Eastgate Mall San Diego, CA 92121 ProFlowers<http://www.proflowers.com/> | redENVELOPE<http://www.redenvelope.com/> | Cherry Moon Farms<http://www.cherrymoonfarms.com/> | Shari's Berries<http://www.berries.com/> From jared at puck.nether.net Wed Jan 19 20:19:57 2011 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 19 Jan 2011 21:19:57 -0500 Subject: Update Spamhaus DROP list from Cisco CLI (TCL) In-Reply-To: <A1B9BAEA8FE39847BCD6C473E894B595027BF5E0@SDEXMB02.Proflowers.com> References: <A1B9BAEA8FE39847BCD6C473E894B595027BF5E0@SDEXMB02.Proflowers.com> Message-ID: <F3FE11D3-AF84-4A88-A3C1-466F18B9A08F@puck.nether.net> On Jan 19, 2011, at 9:04 PM, Thomas Magill wrote: > Previous conversations made me decide this would be fun to do so I ignored all my real work today and made it happen. > > I built a TCL script that can be mapped to an alias ("alias exec updatedrop tclsh updatedrop.tcl") that will connect to the Spamhaus DROP list and route all of the prefixes to null0. It should alsbo be able to be mapped to a kron job, but I haven't tested that and I've heard there are issues with kron+tcl unless you tie it to an EEM event. It adds a name indicator (Spamhaus_SBLXXXXX) to all of the routes to show that they come from the DROP list. You can find the script at: > > http://tmagill.net/cisco_networking_ccie_studies/?p=83 > > There is also a script to remove all of the Spamhaus_SBLXXXXX null routes. > > If I were to redis these into BGP they could be propagated just like the CYMRU Bogons... I plan on doing that within the next week and start testing. Does anyone see that as a useful service to be offered? This was done once before, it was called MAPS at the time. Using BGP as a signaling mechanic for this stuff can obviously be useful. The challenge has always been balancing the trust with a 3rd party with the other operational requirements. Typically business needs push this out such that it's harder to obtain. Smaller networks may participate as the cost may be higher proportionally upon them. Larger networks just do the triage the same way they always do, with their abuse desks. The business needs/concerns are typically something like "How do we trust them? Can it be hacked? etc." There are always sunsetting issues. Sometimes nobody knows that the network was peered with the bogons server, or has an old bogons list that needs to be updated. There will be a lot of fun soon as we attain the "end of ipv4 allocations" soon. Many people with old bogon lists will ultimately need to remove them. Some people won't notice, possibly for years. - Jared From ops.lists at gmail.com Wed Jan 19 20:20:28 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 20 Jan 2011 07:50:28 +0530 Subject: Update Spamhaus DROP list from Cisco CLI (TCL) In-Reply-To: <A1B9BAEA8FE39847BCD6C473E894B595027BF5E0@SDEXMB02.Proflowers.com> References: <A1B9BAEA8FE39847BCD6C473E894B595027BF5E0@SDEXMB02.Proflowers.com> Message-ID: <AANLkTin69Ji-8RXUDh5yOutXTaXDTF+4fGCa+E3yjv-L@mail.gmail.com> Did you try this http://www.spamhaus.org/faq/answers.lasso?section=DROP%20FAQ#168 LInks to Marco d'Itri's "cisco tools" package - http://www.linux.it/~md/software/cisco-tools-0.2.tgz Pretty neat, can update bogons as well On Thu, Jan 20, 2011 at 7:34 AM, Thomas Magill <tmagill at providecommerce.com> wrote: > Previous conversations made me decide this would be fun to do so I ignored all my real work today and made it happen. > > I built a TCL script that can be mapped to an alias ("alias exec updatedrop tclsh updatedrop.tcl") that will connect to the Spamhaus DROP list and route all of the prefixes to null0. ?It should alsbo be able to be mapped to a kron job, but I haven't tested that and I've heard there are issues with kron+tcl unless you tie it to an EEM event. ?It adds a name indicator (Spamhaus_SBLXXXXX) to all of the routes to show that they come from the DROP list. ?You can find the script at: > > http://tmagill.net/cisco_networking_ccie_studies/?p=83 > > There is also a script to remove all of the Spamhaus_SBLXXXXX null routes. > > If I were to redis these into BGP they could be propagated just like the CYMRU Bogons... ?I plan on doing that within the next week and start testing. ?Does anyone see that as a useful service to be offered? > > > Thomas Magill > Network Engineer > Office: (858) 909-3777 > Cell: (858) 869-9685 > tmagill at providecommerce.com<mailto:tmagill at providecommerce.com> > > provide-commerce > 4840 Eastgate Mall > San Diego, CA ?92121 > > ProFlowers<http://www.proflowers.com/> | redENVELOPE<http://www.redenvelope.com/> | Cherry Moon Farms<http://www.cherrymoonfarms.com/> | Shari's Berries<http://www.berries.com/> > > -- Suresh Ramasubramanian (ops.lists at gmail.com) From ncharles at gmail.com Wed Jan 19 21:20:25 2011 From: ncharles at gmail.com (Nathan Charles) Date: Thu, 20 Jan 2011 09:20:25 +0600 Subject: United Airlines Technical Contact Message-ID: <AANLkTincLPn7QZh_kfv_OmLV-1Ufxc0FS_KC580L8aSX@mail.gmail.com> Does anybody have a technical contact for United Airlines? I can't seem to get in touch with any of the phone numbers or email addresses listed in whois. Regards, Nathan Charles From ncharles at gmail.com Wed Jan 19 21:33:03 2011 From: ncharles at gmail.com (Nathan Charles) Date: Thu, 20 Jan 2011 09:33:03 +0600 Subject: United Airlines Technical Contact Message-ID: <AANLkTinxFaN07gpv856nd1NsDEz=+6c3ErvpmF3XUdoR@mail.gmail.com> Does anybody have a technical contact for United Airlines? I can't seem to get in touch with any of the phone numbers or email addresses listed in whois. Regards, Nathan Charles From owen at delong.com Wed Jan 19 22:22:50 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 19 Jan 2011 20:22:50 -0800 Subject: Securing Border Routers In-Reply-To: <AANLkTimd7o4wNop6ysJ5Ba0UTz-OOVBkrd-+wTwo5XBy@mail.gmail.com> References: <BLU158-w13F6A3CA3CEC3895852E48DCF90@phx.gbl> <DFA5AECDEC85EE4087D45C463C19B375134D703DE1@KWAEXMAIL1.ARRS.ARRISI.COM> <BLU158-w57A22B157DAF65737032D8DCF90@phx.gbl> <AANLkTimd7o4wNop6ysJ5Ba0UTz-OOVBkrd-+wTwo5XBy@mail.gmail.com> Message-ID: <694E2AED-AB8E-496F-A8B3-A4BF1CBAEA42@delong.com> Using non-world routable space on interfaces makes for difficulties in some situations with PMTU-D and with troubleshooting (useless information in traceroutes for example). Owen On Jan 19, 2011, at 6:04 PM, jim deleskie wrote: > Never put a firewall in front of a router, it will die first. The team > CYMRU stuff is great make sure you have ACL's on your VTY and allow access > only from trusted internal IPs. I also like using non world routable space > on any interface I can. > > > On Wed, Jan 19, 2011 at 9:38 PM, Brandon Kim <brandon.kim at brandontek.com>wrote: > >> >> >> >> What an insightful link! Thank you, I am reading it now..... >> >> >> >> >>> From: Bryan.Welch at arrisi.com >>> To: nanog at nanog.org >>> Date: Wed, 19 Jan 2011 16:38:43 -0800 >>> Subject: RE: Securing Border Routers >>> >>> I ALWAYS start with the CYMRU secure bgp templates, found here: >>> http://www.team-cymru.org/ReadingRoom/Templates/secure-bgp-template.html >>> >>> I personally would not recommend a firewall in front of your router, >> sufficient ACL'ing should be enough for securing the router itself. >>> >>> >>> Bryan >>> >>> -----Original Message----- >>> From: Brandon Kim [mailto:brandon.kim at brandontek.com] >>> Sent: Wednesday, January 19, 2011 4:36 PM >>> To: nanog group >>> Subject: Securing Border Routers >>> >>> >>> Gents: >>> >>> What measures do you take to protect your border routers? Our routers are >> running BGP so I'm interested if there is any way to secure them without >> interfering with BGP? Is it normal to put a firewall in front of the border >> routers? >>> >>> I'm concerned about DDOS attacks mainly....although we haven't had any, I >> don't welcome them..... >>> >>> Brandon >>> >>> >>> >>> >>> >>> >> >> From linux.yahoo at gmail.com Thu Jan 20 05:04:07 2011 From: linux.yahoo at gmail.com (Manu Chao) Date: Thu, 20 Jan 2011 12:04:07 +0100 Subject: WAAS CIFS Optimisation Message-ID: <AANLkTimaO_2disht6TcERTC6ezX0VG9ED2GOS_cH3QfL@mail.gmail.com> AFAIK, WAAS is not able to optimise CIFS when SMB signing or digital signatures are enabled (default!). Is it correct? Do i need to disable default Microsoft SMB signature to get optimal CIFS optimisation? Thanks for any feedback or recommandation Manu From progamler-nanog at free.de Thu Jan 20 05:21:45 2011 From: progamler-nanog at free.de (Jan-Philipp Warmers) Date: Thu, 20 Jan 2011 12:21:45 +0100 Subject: WAAS CIFS Optimisation In-Reply-To: <AANLkTimaO_2disht6TcERTC6ezX0VG9ED2GOS_cH3QfL@mail.gmail.com> References: <AANLkTimaO_2disht6TcERTC6ezX0VG9ED2GOS_cH3QfL@mail.gmail.com> Message-ID: <20110120112145.GE15269@progamler@free.de> Manu Chao <linux.yahoo at gmail.com> Tippte am 2011-01-20T12:04+0100: > AFAIK, WAAS is not able to optimise CIFS when SMB signing or digital > signatures are enabled (default!). Is it correct? > > Do i need to disable default Microsoft SMB signature to get optimal CIFS > optimisation? yes! its Recommened for Citrix WanScaler Jan From chris at nifry.com Thu Jan 20 07:02:45 2011 From: chris at nifry.com (Chris Russell) Date: Thu, 20 Jan 2011 13:02:45 +0000 Subject: WAAS CIFS Optimisation In-Reply-To: <AANLkTimaO_2disht6TcERTC6ezX0VG9ED2GOS_cH3QfL@mail.gmail.com> References: <AANLkTimaO_2disht6TcERTC6ezX0VG9ED2GOS_cH3QfL@mail.gmail.com> Message-ID: <0e4c1377a05e9f0d0307e11a3d38024a@localhost> > Do i need to disable default Microsoft SMB signature to get optimal CIFS > optimisation? > > Thanks for any feedback or recommandation > Manu IIRC Yes. Also ensure you're on one of the newer versions, older ones (< 4.1.7 maybe ?) have some known issues with Windows sharing. Chris From jbates at brightok.net Thu Jan 20 10:44:34 2011 From: jbates at brightok.net (Jack Bates) Date: Thu, 20 Jan 2011 10:44:34 -0600 Subject: Update Spamhaus DROP list from Cisco CLI (TCL) In-Reply-To: <F3FE11D3-AF84-4A88-A3C1-466F18B9A08F@puck.nether.net> References: <A1B9BAEA8FE39847BCD6C473E894B595027BF5E0@SDEXMB02.Proflowers.com> <F3FE11D3-AF84-4A88-A3C1-466F18B9A08F@puck.nether.net> Message-ID: <4D386672.1010803@brightok.net> On 1/19/2011 8:19 PM, Jared Mauch wrote: > This was done once before, it was called MAPS at the time. Using BGP > as a signaling mechanic for this stuff can obviously be useful. The > challenge has always been balancing the trust with a 3rd party with > the other operational requirements. It's only useful if you want to make troubleshooting problems more difficult and require remote parties to contact you off-net. Conditionals for such blocks are more difficult (abuse at domain whitelisted isn't enough, you have to have a specific @domain which the filters don't apply to). I agree that smaller networks are the ones more likely to participate in such things. Jack From tmagill at providecommerce.com Thu Jan 20 12:21:18 2011 From: tmagill at providecommerce.com (Thomas Magill) Date: Thu, 20 Jan 2011 18:21:18 +0000 Subject: Update Spamhaus DROP list from Cisco CLI (TCL) In-Reply-To: <AANLkTin69Ji-8RXUDh5yOutXTaXDTF+4fGCa+E3yjv-L@mail.gmail.com> References: <A1B9BAEA8FE39847BCD6C473E894B595027BF5E0@SDEXMB02.Proflowers.com> <AANLkTin69Ji-8RXUDh5yOutXTaXDTF+4fGCa+E3yjv-L@mail.gmail.com> Message-ID: <A1B9BAEA8FE39847BCD6C473E894B595027BF8C5@SDEXMB02.Proflowers.com> I saw that. I just wanted to do it in TCL so that it was completely self-contained and could be run like a command from IOS itself. It was mostly an exercise/challenge in scripting for myself, that yielded what I felt to be a useful product. -----Original Message----- From: Suresh Ramasubramanian [mailto:ops.lists at gmail.com] Sent: Wednesday, January 19, 2011 6:20 PM To: Thomas Magill Cc: nanog at nanog.org Subject: Re: Update Spamhaus DROP list from Cisco CLI (TCL) Did you try this http://www.spamhaus.org/faq/answers.lasso?section=DROP%20FAQ#168 LInks to Marco d'Itri's "cisco tools" package - http://www.linux.it/~md/software/cisco-tools-0.2.tgz Pretty neat, can update bogons as well On Thu, Jan 20, 2011 at 7:34 AM, Thomas Magill <tmagill at providecommerce.com> wrote: > Previous conversations made me decide this would be fun to do so I ignored all my real work today and made it happen. > > I built a TCL script that can be mapped to an alias ("alias exec updatedrop tclsh updatedrop.tcl") that will connect to the Spamhaus DROP list and route all of the prefixes to null0. ?It should alsbo be able to be mapped to a kron job, but I haven't tested that and I've heard there are issues with kron+tcl unless you tie it to an EEM event. ?It adds a name indicator (Spamhaus_SBLXXXXX) to all of the routes to show that they come from the DROP list. ?You can find the script at: > > http://tmagill.net/cisco_networking_ccie_studies/?p=83 > > There is also a script to remove all of the Spamhaus_SBLXXXXX null routes. > > If I were to redis these into BGP they could be propagated just like the CYMRU Bogons... ?I plan on doing that within the next week and start testing. ?Does anyone see that as a useful service to be offered? > > > Thomas Magill > Network Engineer > Office: (858) 909-3777 > Cell: (858) 869-9685 > tmagill at providecommerce.com<mailto:tmagill at providecommerce.com> > > provide-commerce > 4840 Eastgate Mall > San Diego, CA ?92121 > > ProFlowers<http://www.proflowers.com/> | redENVELOPE<http://www.redenvelope.com/> | Cherry Moon Farms<http://www.cherrymoonfarms.com/> | Shari's Berries<http://www.berries.com/> > > -- Suresh Ramasubramanian (ops.lists at gmail.com) From virendra.rode at gmail.com Thu Jan 20 12:56:28 2011 From: virendra.rode at gmail.com (virendra rode) Date: Thu, 20 Jan 2011 10:56:28 -0800 Subject: Securing Border Routers In-Reply-To: <BLU158-w13F6A3CA3CEC3895852E48DCF90@phx.gbl> References: <BLU158-w13F6A3CA3CEC3895852E48DCF90@phx.gbl> Message-ID: <4D38855C.7070606@gmail.com> Hi - On 01/19/2011 04:35 PM, Brandon Kim wrote: > > Gents: > > What measures do you take to protect your border routers? Our routers are running BGP so I'm interested > if there is any way to secure them without interfering with BGP? Is it normal to put a firewall in front of the > border routers? > > I'm concerned about DDOS attacks mainly....although we haven't had any, I don't welcome them..... > > Brandon > ------------------------- BCP 38 is worth implementing :-) regards, /virendra From jeff.richmond at gmail.com Thu Jan 20 13:24:21 2011 From: jeff.richmond at gmail.com (Jeff Richmond) Date: Thu, 20 Jan 2011 11:24:21 -0800 Subject: Good MPLS/VPLS book? In-Reply-To: <BLU158-w6171DD4A931A22207B526EDC1F0@phx.gbl> References: <alpine.BSF.2.00.1012231445520.57378@lorien.vbc-apt.ubertel.net>, <AANLkTikx9jtpO8-b=iO3L3pbuTmrm8Ac5qNvM0yrxTTv@mail.gmail.com>, <C1458FB9-3A80-4B8B-9D67-445DAAE96E4D@menards.ca> <BLU158-w6171DD4A931A22207B526EDC1F0@phx.gbl> Message-ID: <B5E9D971-3589-49AE-9EBA-9B2384E0CF8F@gmail.com> FYI, the 3rd edition was released early. Was delivered this morning from Amazon. It has a whole new chapter on MPLS-TP (Ch. 17). Hope this helps, -Jeff On Dec 26, 2010, at 7:29 AM, Brandon Kim wrote: > > Decisions decisions, I do have other MPLS books I have not finished. I suppose I can finish them before > picking this up and then getting the 3rd edition.....might be good timing. Good thing I didn't order the > 2nd edition the other day! > > > > > > >> Subject: Re: Good MPLS/VPLS book? >> From: francois at menards.ca >> Date: Sat, 25 Dec 2010 20:42:24 -0500 >> To: mounir.mohamed at gmail.com >> CC: nanog at nanog.org >> >> Looks like a third edition is on the way slated for March 2011 >> >> http://www.amazon.com/MPLS-Enabled-Applications-Developments-Technologies-Communications/dp/0470665459/ref=ntt_at_ep_dpt_2 >> >> I would expect it to cover MPLS-TP and the struggling evolution of PBB-TE ... anybody has any idea if this is in ? >> >> F. >> >> On 2010-12-24, at 7:47 AM, Mounir Mohamed wrote: >> >>> The most comprehensive text is MPLS Enabled Applications by Ina Minei >>> >>> http://www.amazon.com/MPLS-Enabled-Applications-Developments-Technologies-Communications/dp/0470986441/ref=sr_1_1?ie=UTF8&qid=1293194786&sr=8-1 >>> >>> >>> On Fri, Dec 24, 2010 at 12:49 AM, Michael Helmeste <mhelmest at uvic.ca> wrote: >>> >>>> Does anyone have a favorite book or resource discussing MPLS and all >>>> associated Lego blocks (e.g. LDP, TE, VPLS, martini, mBGP et. al.)? >>>> >>>> I understand the basics of what MPLS is and how you create a circuit from >>>> A to B but I'm afraid it still escapes me when trying to figure out how >>>> someone would, say, create a multicast capable VPN with 5 edge points. >>>> >>>> Any pointers to a good way to reduce my level of ignorance on this subject >>>> would be appreciated. Vendor literature doesn't bother me as long as the >>>> concepts are there. >>>> >>>> Regards, >>>> Michael H. >>>> >>>> >>>> >>> >>> >>> -- >>> Best Regards, >>> Mounir Mohamed, CCIE#19573 (R&S/SP) >>> Senior Network Engineer, Core Team. >>> NOOR Data Networks, SAE >>> Mobile# +2-010-2345-956 >>> http://mounirmohamed.wordpress.com >>> http://www.linkedin.com/in/mounirmohamed >> >> > From brandon.kim at brandontek.com Thu Jan 20 13:48:19 2011 From: brandon.kim at brandontek.com (Brandon Kim) Date: Thu, 20 Jan 2011 14:48:19 -0500 Subject: Good MPLS/VPLS book? In-Reply-To: <B5E9D971-3589-49AE-9EBA-9B2384E0CF8F@gmail.com> References: <alpine.BSF.2.00.1012231445520.57378@lorien.vbc-apt.ubertel.net>, <AANLkTikx9jtpO8-b=iO3L3pbuTmrm8Ac5qNvM0yrxTTv@mail.gmail.com>, <C1458FB9-3A80-4B8B-9D67-445DAAE96E4D@menards.ca> <BLU158-w6171DD4A931A22207B526EDC1F0@phx.gbl>, <B5E9D971-3589-49AE-9EBA-9B2384E0CF8F@gmail.com> Message-ID: <BLU158-w29A1B022E00D87E60B832DCF90@phx.gbl> Wow thanks for the heads up! I went ahead and bought the other MPLS books, I guess I'll have to go get this one too now... This is very early.....I wonder why the rush? > Subject: Re: Good MPLS/VPLS book? > From: jeff.richmond at gmail.com > Date: Thu, 20 Jan 2011 11:24:21 -0800 > CC: francois at menards.ca; mounir.mohamed at gmail.com; nanog at nanog.org > To: brandon.kim at brandontek.com > > FYI, the 3rd edition was released early. Was delivered this morning from Amazon. It has a whole new chapter on MPLS-TP (Ch. 17). > > Hope this helps, > -Jeff > > On Dec 26, 2010, at 7:29 AM, Brandon Kim wrote: > > > > > Decisions decisions, I do have other MPLS books I have not finished. I suppose I can finish them before > > picking this up and then getting the 3rd edition.....might be good timing. Good thing I didn't order the > > 2nd edition the other day! > > > > > > > > > > > > > >> Subject: Re: Good MPLS/VPLS book? > >> From: francois at menards.ca > >> Date: Sat, 25 Dec 2010 20:42:24 -0500 > >> To: mounir.mohamed at gmail.com > >> CC: nanog at nanog.org > >> > >> Looks like a third edition is on the way slated for March 2011 > >> > >> http://www.amazon.com/MPLS-Enabled-Applications-Developments-Technologies-Communications/dp/0470665459/ref=ntt_at_ep_dpt_2 > >> > >> I would expect it to cover MPLS-TP and the struggling evolution of PBB-TE ... anybody has any idea if this is in ? > >> > >> F. > >> > >> On 2010-12-24, at 7:47 AM, Mounir Mohamed wrote: > >> > >>> The most comprehensive text is MPLS Enabled Applications by Ina Minei > >>> > >>> http://www.amazon.com/MPLS-Enabled-Applications-Developments-Technologies-Communications/dp/0470986441/ref=sr_1_1?ie=UTF8&qid=1293194786&sr=8-1 > >>> > >>> > >>> On Fri, Dec 24, 2010 at 12:49 AM, Michael Helmeste <mhelmest at uvic.ca> wrote: > >>> > >>>> Does anyone have a favorite book or resource discussing MPLS and all > >>>> associated Lego blocks (e.g. LDP, TE, VPLS, martini, mBGP et. al.)? > >>>> > >>>> I understand the basics of what MPLS is and how you create a circuit from > >>>> A to B but I'm afraid it still escapes me when trying to figure out how > >>>> someone would, say, create a multicast capable VPN with 5 edge points. > >>>> > >>>> Any pointers to a good way to reduce my level of ignorance on this subject > >>>> would be appreciated. Vendor literature doesn't bother me as long as the > >>>> concepts are there. > >>>> > >>>> Regards, > >>>> Michael H. > >>>> > >>>> > >>>> > >>> > >>> > >>> -- > >>> Best Regards, > >>> Mounir Mohamed, CCIE#19573 (R&S/SP) > >>> Senior Network Engineer, Core Team. > >>> NOOR Data Networks, SAE > >>> Mobile# +2-010-2345-956 > >>> http://mounirmohamed.wordpress.com > >>> http://www.linkedin.com/in/mounirmohamed > >> > >> > > > From tbeecher at localnet.com Thu Jan 20 15:04:48 2011 From: tbeecher at localnet.com (Tom Beecher) Date: Thu, 20 Jan 2011 16:04:48 -0500 Subject: Looking for an Akamai contact, strange DoS traffic sourcing from Akamai sources Message-ID: <4D38A370.1060300@localnet.com> I'm looking for an Akamai contact to try and address a strange situation. We have multiple sites across the country that aggregate 56k dialup customers. Different sites are randomly experiencing inbound traffic spikes that are overwhelming the uplinks to our carriers, causing DoS situations. These spikes far exceed the bandwidth that could possibly be used by the number of dialup customers connected. We've been able to trace the source of the traffic to Akamai boxes, but so far have been unable to reach anyone at Akamai to discuss the situation. We're attempting to get payload information, but the traffic volume is making it slow going setting up packet captures at these sites remotely. Thanks in advance, Tom -- Thomas Beecher II Senior Network Administrator LocalNet Corp. CoreComm Internet Services tbeecher at localnet.com From mruiz at lstfinancial.com Thu Jan 20 15:06:58 2011 From: mruiz at lstfinancial.com (Michael Ruiz) Date: Thu, 20 Jan 2011 15:06:58 -0600 Subject: Authentication using Microsoft 2008 Active directory for Cisco RADIUS login Message-ID: <16E58A1FE7C64A46BAD0FE1558C43D9201363E43@es1.ic-sa.com> >Can you post your config on the router? >Also, this may be better to post over at cisco-nsp. >B I decided to move away from RADIUS via Active Directory and turn up a Ubuntu TACACS+ server. Now it works. HAHA. Now it is time to create the template files. M.A.R From rdobbins at arbor.net Thu Jan 20 16:21:21 2011 From: rdobbins at arbor.net (Roland Dobbins) Date: Thu, 20 Jan 2011 16:21:21 -0600 Subject: Securing Border Routers In-Reply-To: <BLU158-w13F6A3CA3CEC3895852E48DCF90@phx.gbl> References: <BLU158-w13F6A3CA3CEC3895852E48DCF90@phx.gbl> Message-ID: <4B43C6FB-E413-4B28-AF49-547879FC9C11@arbor.net> On Jan 19, 2011, at 6:35 PM, Brandon Kim wrote: > I'm concerned about DDOS attacks mainly....although we haven't had any, I don't welcome them..... <https://files.me.com/roland.dobbins/prguob> <https://files.me.com/roland.dobbins/k4zw3x> <https://files.me.com/roland.dobbins/dweagy> ------------------------------------------------------------------------ Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com> Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay From tbeecher at localnet.com Thu Jan 20 16:46:36 2011 From: tbeecher at localnet.com (Tom Beecher) Date: Thu, 20 Jan 2011 17:46:36 -0500 Subject: Looking for an Akamai contact, strange DoS traffic sourcing from Akamai sources In-Reply-To: <4D38A370.1060300@localnet.com> References: <4D38A370.1060300@localnet.com> Message-ID: <4D38BB4C.1070501@localnet.com> I've received a couple of responses off list, and am now in touch with Akamai directly. I appreciate everyone's assistance. On 1/20/2011 4:04 PM, Tom Beecher wrote: > I'm looking for an Akamai contact to try and address a strange situation. > > We have multiple sites across the country that aggregate 56k dialup > customers. Different sites are randomly experiencing inbound traffic > spikes that are overwhelming the uplinks to our carriers, causing DoS > situations. These spikes far exceed the bandwidth that could possibly > be used by the number of dialup customers connected. We've been able > to trace the source of the traffic to Akamai boxes, but so far have > been unable to reach anyone at Akamai to discuss the situation. We're > attempting to get payload information, but the traffic volume is > making it slow going setting up packet captures at these sites remotely. > > Thanks in advance, > > Tom > -- Thomas Beecher II Senior Network Administrator LocalNet Corp. CoreComm Internet Services tbeecher at localnet.com From jbates at brightok.net Fri Jan 21 07:45:22 2011 From: jbates at brightok.net (Jack Bates) Date: Fri, 21 Jan 2011 07:45:22 -0600 Subject: Looking for an Akamai contact, strange DoS traffic sourcing from Akamai sources In-Reply-To: <4D38BB4C.1070501@localnet.com> References: <4D38A370.1060300@localnet.com> <4D38BB4C.1070501@localnet.com> Message-ID: <4D398DF2.50607@brightok.net> I have a customer reporting the same thing. The traffic flood goes to offline modem bank IPs. So far, Akamai hasn't actually grasped what the problem is and says everything is fine. :( Luckily, most of the traffic (not all) is coming from my local cluster, so it's easier to monitor what's going on. Packet captures have shown the same packet being sent over and over, usually over 1400 bytes in size. Different floods may have different packets, but within a flood it's identical. I wouldn't think you'd have data prior to the 3-way, so I'm curious how the 3-way is being completed for the data to be sent. Jack On 1/20/2011 4:46 PM, Tom Beecher wrote: > I've received a couple of responses off list, and am now in touch with > Akamai directly. > > I appreciate everyone's assistance. > > On 1/20/2011 4:04 PM, Tom Beecher wrote: >> I'm looking for an Akamai contact to try and address a strange >> situation. >> >> We have multiple sites across the country that aggregate 56k dialup >> customers. Different sites are randomly experiencing inbound traffic >> spikes that are overwhelming the uplinks to our carriers, causing DoS >> situations. These spikes far exceed the bandwidth that could >> possibly be used by the number of dialup customers connected. We've >> been able to trace the source of the traffic to Akamai boxes, but so >> far have been unable to reach anyone at Akamai to discuss the >> situation. We're attempting to get payload information, but the >> traffic volume is making it slow going setting up packet captures at >> these sites remotely. >> >> Thanks in advance, >> >> Tom >> > From cmadams at hiwaay.net Fri Jan 21 08:21:20 2011 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 21 Jan 2011 08:21:20 -0600 Subject: Looking for an Akamai contact, strange DoS traffic sourcing from Akamai sources In-Reply-To: <4D398DF2.50607@brightok.net> References: <4D38A370.1060300@localnet.com> <4D38BB4C.1070501@localnet.com> <4D398DF2.50607@brightok.net> Message-ID: <20110121142120.GB15266@hiwaay.net> Once upon a time, Jack Bates <jbates at brightok.net> said: > I have a customer reporting the same thing. The traffic flood goes to > offline modem bank IPs. So far, Akamai hasn't actually grasped what the > problem is and says everything is fine. :( <aol>me too</aol> I hadn't captured the traffic during one of the floods yet, but now that you mention it, I'm seeing spikes on my Akamai graphs at the same time as the spikes on the dialup graphs. I wonder if some Microsoft PPP update triggered an Akamai bug or some such (why else would it just be hitting dialups)? -- Chris Adams <cmadams at hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From tbeecher at localnet.com Fri Jan 21 08:38:50 2011 From: tbeecher at localnet.com (Tom Beecher) Date: Fri, 21 Jan 2011 09:38:50 -0500 Subject: Looking for an Akamai contact, strange DoS traffic sourcing from Akamai sources In-Reply-To: <4D398DF2.50607@brightok.net> References: <4D38A370.1060300@localnet.com> <4D38BB4C.1070501@localnet.com> <4D398DF2.50607@brightok.net> Message-ID: <4D399A7A.5070909@localnet.com> Jack- This is exactly what we're seeing. The Akamai server starts a retransmission flood aimed at a specific address randomly. We're seeing thousands of retransmissions of the same packet over and over again, same sequence/ack numbers, all 1460 bytes. In the last capture I have, it was all JPEG data, although we weren't capturing entire packets. There is a slight difference in the capture payloads, two bytes each time. I had another dial-up provider contact me off list, and he's seeing the same thing. I'm wondering if this is actually more widespread, but only dial-up providers are really seeing the effects since a 3-5Mbps burst is most noticeable for us on our smaller upstream links. // On 1/21/2011 8:45 AM, Jack Bates wrote: > I have a customer reporting the same thing. The traffic flood goes to > offline modem bank IPs. So far, Akamai hasn't actually grasped what > the problem is and says everything is fine. :( > > Luckily, most of the traffic (not all) is coming from my local > cluster, so it's easier to monitor what's going on. Packet captures > have shown the same packet being sent over and over, usually over 1400 > bytes in size. Different floods may have different packets, but within > a flood it's identical. I wouldn't think you'd have data prior to the > 3-way, so I'm curious how the 3-way is being completed for the data to > be sent. > > > Jack > > On 1/20/2011 4:46 PM, Tom Beecher wrote: >> I've received a couple of responses off list, and am now in touch >> with Akamai directly. >> >> I appreciate everyone's assistance. >> >> On 1/20/2011 4:04 PM, Tom Beecher wrote: >>> I'm looking for an Akamai contact to try and address a strange >>> situation. >>> >>> We have multiple sites across the country that aggregate 56k dialup >>> customers. Different sites are randomly experiencing inbound traffic >>> spikes that are overwhelming the uplinks to our carriers, causing >>> DoS situations. These spikes far exceed the bandwidth that could >>> possibly be used by the number of dialup customers connected. We've >>> been able to trace the source of the traffic to Akamai boxes, but so >>> far have been unable to reach anyone at Akamai to discuss the >>> situation. We're attempting to get payload information, but the >>> traffic volume is making it slow going setting up packet captures at >>> these sites remotely. >>> >>> Thanks in advance, >>> >>> Tom >>> >> > > -- Thomas Beecher II Senior Network Administrator LocalNet Corp. CoreComm Internet Services tbeecher at localnet.com From jbates at brightok.net Fri Jan 21 08:43:48 2011 From: jbates at brightok.net (Jack Bates) Date: Fri, 21 Jan 2011 08:43:48 -0600 Subject: Looking for an Akamai contact, strange DoS traffic sourcing from Akamai sources In-Reply-To: <4D399A7A.5070909@localnet.com> References: <4D38A370.1060300@localnet.com> <4D38BB4C.1070501@localnet.com> <4D398DF2.50607@brightok.net> <4D399A7A.5070909@localnet.com> Message-ID: <4D399BA4.50101@brightok.net> On 1/21/2011 8:38 AM, Tom Beecher wrote: > Jack- > > This is exactly what we're seeing. The Akamai server starts a > retransmission flood aimed at a specific address randomly. We're seeing > thousands of retransmissions of the same packet over and over again, > same sequence/ack numbers, all 1460 bytes. In the last capture I have, > it was all JPEG data, although we weren't capturing entire packets. > There is a slight difference in the capture payloads, two bytes each time. > The content between attacks changes at times, as do the source IPs, as they send different content. We've noticed at least 2 different akamai hosted sites packets being sent. 1460 is definitely the number. What gets me is that the 3-way should be complete to allow the 1460, and the modem bank is spamming host unreachable ICMP messages since that IP is offline. > I had another dial-up provider contact me off list, and he's seeing the > same thing. I'm wondering if this is actually more widespread, but only > dial-up providers are really seeing the effects since a 3-5Mbps burst is > most noticeable for us on our smaller upstream links. // This was my thought, though in my downstream's case, it's saturating his DS-3. The 45mb spikes were just enough for me to barely make it out on the akamai gig-e graphs. He's also not always receiving from my local node. Sometimes his other transit links saturate due to remote nodes doing the same thing. Jack From KaeglerM at tessco.com Fri Jan 21 09:11:54 2011 From: KaeglerM at tessco.com (Kaegler, Mike) Date: Fri, 21 Jan 2011 10:11:54 -0500 Subject: Verizon FiOS Distribution Switch In-Reply-To: <4D3764DE.20703@tiedyenetworks.com> Message-ID: <C95F0C6A.24EE1%KaeglerM@tessco.com> On 1/19/11 3:56 PM, "Chris Burwell" <cburwell at gmail.com> wrote: > Any advice or tips would be helpful. If all you need the ActionTek for is a MoCA bridge (to make the cable boxes talk to the larger world), my experience is you can move it to the inside of your NAT if you like. One does not need to burn a routable IP for it. On 1/19/11 5:25 PM, "Mike" <mike-nanog at tiedyenetworks.com> wrote: > also add 'nonegotiate' and turn off spanning tree on the port while > you're at it. There's a list somewhere of standard stuff when connecting > to an untrusted l2 network, which is what you should treat anything > (including FiOS) connecting to you that you don't own. Nonegotiate doesn't touch STP. It stops the switchport from sending DTP frames, but one wouldn't be attempting to establish a trunk to a FiOS ONT. http://www.cisco.com/en/US/docs/switches/lan/catalyst2950/software/release/1 2.1_11_ea1/command/reference/cli2.html#wpmkr3005909 To stop a port from participating in spanning tree, one would want some combination of global and interface bpduguard and bpdufilter. Which combination you want seems to vary with every Cisco Press book and document, and every engineer has a different idea of which is correct. One is best off labbing it out themselves with the equipment they intend to use. -porkchop -- Michael Kaegler, TESSCO Technologies: Engineering, 410 229 1295 Your wireless success, nothing less. http://www.tessco.com/ From patrick at ianai.net Fri Jan 21 09:48:08 2011 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 21 Jan 2011 10:48:08 -0500 Subject: Looking for an Akamai contact, strange DoS traffic sourcing from Akamai sources In-Reply-To: <4D399BA4.50101@brightok.net> References: <4D38A370.1060300@localnet.com> <4D38BB4C.1070501@localnet.com> <4D398DF2.50607@brightok.net> <4D399A7A.5070909@localnet.com> <4D399BA4.50101@brightok.net> Message-ID: <421FB963-35B1-4B17-A216-A1B980A9697E@ianai.net> The issue has been reported to the proper people inside Akamai. They are investigating, we are not ignoring the issue. If any network with on-net Akamai servers has an issue, including this or any other, please e-mail NetSupport-tix at akamai.com and that will open a ticket with our Network Support group. -- TTFN, patrick On Jan 21, 2011, at 9:43 AM, Jack Bates wrote: > On 1/21/2011 8:38 AM, Tom Beecher wrote: >> Jack- >> >> This is exactly what we're seeing. The Akamai server starts a >> retransmission flood aimed at a specific address randomly. We're seeing >> thousands of retransmissions of the same packet over and over again, >> same sequence/ack numbers, all 1460 bytes. In the last capture I have, >> it was all JPEG data, although we weren't capturing entire packets. >> There is a slight difference in the capture payloads, two bytes each time. >> > > The content between attacks changes at times, as do the source IPs, as they send different content. We've noticed at least 2 different akamai hosted sites packets being sent. > > 1460 is definitely the number. What gets me is that the 3-way should be complete to allow the 1460, and the modem bank is spamming host unreachable ICMP messages since that IP is offline. > >> I had another dial-up provider contact me off list, and he's seeing the >> same thing. I'm wondering if this is actually more widespread, but only >> dial-up providers are really seeing the effects since a 3-5Mbps burst is >> most noticeable for us on our smaller upstream links. // > > This was my thought, though in my downstream's case, it's saturating his DS-3. The 45mb spikes were just enough for me to barely make it out on the akamai gig-e graphs. > > He's also not always receiving from my local node. Sometimes his other transit links saturate due to remote nodes doing the same thing. > > > Jack > From jbates at brightok.net Fri Jan 21 10:34:39 2011 From: jbates at brightok.net (Jack Bates) Date: Fri, 21 Jan 2011 10:34:39 -0600 Subject: Looking for an Akamai contact, strange DoS traffic sourcing from Akamai sources In-Reply-To: <421FB963-35B1-4B17-A216-A1B980A9697E@ianai.net> References: <4D38A370.1060300@localnet.com> <4D38BB4C.1070501@localnet.com> <4D398DF2.50607@brightok.net> <4D399A7A.5070909@localnet.com> <4D399BA4.50101@brightok.net> <421FB963-35B1-4B17-A216-A1B980A9697E@ianai.net> Message-ID: <4D39B59F.1050009@brightok.net> On 1/21/2011 9:48 AM, Patrick W. Gilmore wrote: > The issue has been reported to the proper people inside Akamai. They > are investigating, we are not ignoring the issue. > I agree. Akamai NOC is always great to work with. Jack From drais at icantclick.org Fri Jan 21 11:07:59 2011 From: drais at icantclick.org (david raistrick) Date: Fri, 21 Jan 2011 12:07:59 -0500 (EST) Subject: Software DNS hghi availability and load balancer solution [SEC=UNCLASSIFIED] In-Reply-To: <20110119034355.GB33644@stlux503.dsto.defence.gov.au> References: <AANLkTimyQDGp9fBiuVE3FEhSJKo-8jzrXHUF+1+aYqpX@mail.gmail.com> <AANLkTimnmc-wc8N1V+DzYq2WFuP-jQHPMJ3dqqUqA66L@mail.gmail.com> <4D35E50D.5060905@rhavenindustrys.com> <alpine.BSF.2.00.1101181438200.46939@murf.icantclick.org> <20110119034355.GB33644@stlux503.dsto.defence.gov.au> Message-ID: <alpine.BSF.2.00.1101211206430.46939@murf.icantclick.org> On Wed, 19 Jan 2011, Wilkinson, Alex wrote: > freebsd + varnish + carp (http://www.openbsd.org/faq/pf/carp.html) two of the three won't work @ EC2 (for my purposes, no idea about the original poster - but he did ask about DNS based solutions so I suspect he's in a similar boat) -- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html From drais at icantclick.org Fri Jan 21 11:08:56 2011 From: drais at icantclick.org (david raistrick) Date: Fri, 21 Jan 2011 12:08:56 -0500 (EST) Subject: Software DNS hghi availability and load balancer solution In-Reply-To: <AANLkTi=0xyMSQTFecMLnuatsg2h+GkZK6eLkL04MKpkR@mail.gmail.com> References: <AANLkTimyQDGp9fBiuVE3FEhSJKo-8jzrXHUF+1+aYqpX@mail.gmail.com> <4D3628B6.40709@knownelement.com> <alpine.BSF.2.00.1101181859590.46939@murf.icantclick.org> <4D3632C1.2010800@knownelement.com> <AANLkTiny5m313VtYueSBAd0HGN4EPoenPVXF8Mvx1+7x@mail.gmail.com> <AANLkTi=0xyMSQTFecMLnuatsg2h+GkZK6eLkL04MKpkR@mail.gmail.com> Message-ID: <alpine.BSF.2.00.1101211208130.46939@murf.icantclick.org> On Tue, 18 Jan 2011, Jay Reitz wrote: > gdnsd is very robust and fast and has an interface that a networking > engineer won't mind. It comes with a geolocation plugin with > health-check failover via HTTP. > > http://code.google.com/p/gdnsd/ Thanks Jay, that looks like a good option - I like single-focus-software for things like this. ;) -- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html From rs at seastrom.com Fri Jan 21 11:31:25 2011 From: rs at seastrom.com (Robert E. Seastrom) Date: Fri, 21 Jan 2011 12:31:25 -0500 Subject: anyone running GPS clocks in Southeastern Georgia? Message-ID: <8662tiupsi.fsf@seastrom.com> It is unclear from this NOTAM whether this is an intentional perturbation of the satellite signals vs. a terrestrial transmitter (my money is on the latter), but it illustrates why one might want geographically dispersed time sources on one's network, as well as why the current trend towards decommissioning LORAN (and in the future, other navaids) in favor of reliance on a single source is a Bad Plan. I'd be curious to see what effects (if any) those who use GPS-disciplined NTP references in Southeastern Georgia see from this experiment. https://www.faasafety.gov/files/notices/2011/Jan/GPS_Flight_Advisory_CSFTL11-01_Rel.pdf -r From jack at crepinc.com Fri Jan 21 11:35:32 2011 From: jack at crepinc.com (Jack Carrozzo) Date: Fri, 21 Jan 2011 12:35:32 -0500 Subject: anyone running GPS clocks in Southeastern Georgia? In-Reply-To: <8662tiupsi.fsf@seastrom.com> References: <8662tiupsi.fsf@seastrom.com> Message-ID: <AANLkTikHQ27Uoy0NO0K3R+FXxHU6qhiCA4MhgwumFsrk@mail.gmail.com> As I understand it, they're trying to get the WAAS sat back online and working properly after it went on walkabout some time ago. It's currently in a nonstandard orbit while they work on it. I suppose it's just pure speculation that they'd only be working on the WAAS service since the NOTAM doesn't say anything about it, but if that were the case there wouldn't be any effect to timing. -Jack Carrozzo On Fri, Jan 21, 2011 at 12:31 PM, Robert E. Seastrom <rs at seastrom.com>wrote: > > It is unclear from this NOTAM whether this is an intentional > perturbation of the satellite signals vs. a terrestrial transmitter > (my money is on the latter), but it illustrates why one might want > geographically dispersed time sources on one's network, as well as why > the current trend towards decommissioning LORAN (and in the future, > other navaids) in favor of reliance on a single source is a Bad Plan. > > I'd be curious to see what effects (if any) those who use > GPS-disciplined NTP references in Southeastern Georgia see from this > experiment. > > > https://www.faasafety.gov/files/notices/2011/Jan/GPS_Flight_Advisory_CSFTL11-01_Rel.pdf > > -r > > > From msa at latt.net Fri Jan 21 11:36:43 2011 From: msa at latt.net (Majdi S. Abbas) Date: Fri, 21 Jan 2011 10:36:43 -0700 Subject: anyone running GPS clocks in Southeastern Georgia? In-Reply-To: <AANLkTikHQ27Uoy0NO0K3R+FXxHU6qhiCA4MhgwumFsrk@mail.gmail.com> References: <8662tiupsi.fsf@seastrom.com> <AANLkTikHQ27Uoy0NO0K3R+FXxHU6qhiCA4MhgwumFsrk@mail.gmail.com> Message-ID: <20110121173643.GA1831@puck.nether.net> On Fri, Jan 21, 2011 at 12:35:32PM -0500, Jack Carrozzo wrote: > As I understand it, they're trying to get the WAAS sat back online and > working properly after it went on walkabout some time ago. It's currently in > a nonstandard orbit while they work on it. I suppose it's just pure > speculation that they'd only be working on the WAAS service since the NOTAM > doesn't say anything about it, but if that were the case there wouldn't be > any effect to timing. Nahh, that was the western WAAS sat, IIRC. This is...Something Else Entirely. --msa From matthew at matthew.at Fri Jan 21 11:39:03 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Fri, 21 Jan 2011 09:39:03 -0800 Subject: anyone running GPS clocks in Southeastern Georgia? In-Reply-To: <8662tiupsi.fsf@seastrom.com> References: <8662tiupsi.fsf@seastrom.com> Message-ID: <4D39C4B7.8050108@matthew.at> On 1/21/2011 9:31 AM, Robert E. Seastrom wrote: > It is unclear from this NOTAM whether this is an intentional > perturbation of the satellite signals vs. a terrestrial transmitter > (my money is on the latter) I'm not sure how you'd get increasing radius with altitude from anything but a jammer near sea level. Matthew Kaufman From jack at crepinc.com Fri Jan 21 11:40:10 2011 From: jack at crepinc.com (Jack Carrozzo) Date: Fri, 21 Jan 2011 12:40:10 -0500 Subject: anyone running GPS clocks in Southeastern Georgia? In-Reply-To: <20110121173643.GA1831@puck.nether.net> References: <8662tiupsi.fsf@seastrom.com> <AANLkTikHQ27Uoy0NO0K3R+FXxHU6qhiCA4MhgwumFsrk@mail.gmail.com> <20110121173643.GA1831@puck.nether.net> Message-ID: <AANLkTinWP9XK_otuV8xQrf3i2LwQ7e_ynS31DGSaanpP@mail.gmail.com> On Fri, Jan 21, 2011 at 12:36 PM, Majdi S. Abbas <msa at latt.net> wrote: > > Nahh, that was the western WAAS sat, IIRC. > > This is...Something Else Entirely. > Ahh, my mistake. Sitting in the back now, -Jack Carrozzo From MatlockK at exempla.org Fri Jan 21 12:19:23 2011 From: MatlockK at exempla.org (Matlock, Kenneth L) Date: Fri, 21 Jan 2011 11:19:23 -0700 Subject: anyone running GPS clocks in Southeastern Georgia? In-Reply-To: <AANLkTinWP9XK_otuV8xQrf3i2LwQ7e_ynS31DGSaanpP@mail.gmail.com> References: <8662tiupsi.fsf@seastrom.com><AANLkTikHQ27Uoy0NO0K3R+FXxHU6qhiCA4MhgwumFsrk@mail.gmail.com><20110121173643.GA1831@puck.nether.net> <AANLkTinWP9XK_otuV8xQrf3i2LwQ7e_ynS31DGSaanpP@mail.gmail.com> Message-ID: <4288131ED5E3024C9CD4782CECCAD2C70B9A32E2@LMC-MAIL2.exempla.org> Probably related to: http://www.engadget.com/2011/01/20/faa-warns-of-ongoing-gps-issues-in-so utheastern-us-due-to-defens/ Sounds like they're doing 'tests' on GPS near SE Georgia. Ken Matlock Network Analyst Exempla Healthcare (303) 467-4671 matlockk at exempla.org -----Original Message----- From: Jack Carrozzo [mailto:jack at crepinc.com] Sent: Friday, January 21, 2011 10:40 AM To: Majdi S. Abbas Cc: Robert E. Seastrom; nanog at nanog.org Subject: Re: anyone running GPS clocks in Southeastern Georgia? On Fri, Jan 21, 2011 at 12:36 PM, Majdi S. Abbas <msa at latt.net> wrote: > > Nahh, that was the western WAAS sat, IIRC. > > This is...Something Else Entirely. > Ahh, my mistake. Sitting in the back now, -Jack Carrozzo From gem at rellim.com Fri Jan 21 12:27:04 2011 From: gem at rellim.com (Gary E. Miller) Date: Fri, 21 Jan 2011 10:27:04 -0800 (PST) Subject: anyone running GPS clocks in Southeastern Georgia? In-Reply-To: <4D39C4B7.8050108@matthew.at> References: <8662tiupsi.fsf@seastrom.com> <4D39C4B7.8050108@matthew.at> Message-ID: <alpine.LNX.1.00.1101211020210.20342@catbert.rellim.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yo All! On Fri, 21 Jan 2011, Matthew Kaufman wrote: > I'm not sure how you'd get increasing radius with altitude from anything but a > jammer near sea level. Agreed. One of these tests was recently run in Utah and we saw the effects in Central Oregon well outside the NOTAMed area. During the tests, airplanes using GPS navigation would suddenly lose RAIM and had to abort their approach to landing. Not sure if they lost all GPS nav information or just RAIM. For non pilots, RAIM is an indicator that the GPS has a redundant solution that matches the barometrically measured altitude. GPS will continue to report a nav solution when lacking this redundancy but pilots are not allowed to shoot an approach when RAIM is off. Good thing most air carriers do not use GPS yet. No effects seen on the ground here, but we were several hundred miles from the test. RGDS GARY - --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701 gem at rellim.com Tel:+1(541)382-8588 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFNOc/9BmnRqz71OvMRAltbAKDW62I7B4Heg1KLAbZaYiShhro5vQCgu5fM WUWTwQhT5tTajslbe3GtuXY= =Czhk -----END PGP SIGNATURE----- From cscora at apnic.net Fri Jan 21 12:28:20 2011 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 22 Jan 2011 04:28:20 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201101211828.p0LISKgJ021065@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith <pfs at cisco.com>. Routing Table Report 04:00 +10GMT Sat 22 Jan, 2011 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 343083 Prefixes after maximum aggregation: 154693 Deaggregation factor: 2.22 Unique aggregates announced to Internet: 169275 Total ASes present in the Internet Routing Table: 35688 Prefixes per ASN: 9.61 Origin-only ASes present in the Internet Routing Table: 30754 Origin ASes announcing only one prefix: 14951 Transit ASes present in the Internet Routing Table: 4934 Transit-only ASes present in the Internet Routing Table: 119 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 33 Max AS path prepend of ASN (36992) 29 Prefixes from unregistered ASNs in the Routing Table: 316 Unregistered ASNs in the Routing Table: 128 Number of 32-bit ASNs allocated by the RIRs: 1028 Prefixes from 32-bit ASNs in the Routing Table: 5 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 209 Number of addresses announced to Internet: 2341691488 Equivalent to 139 /8s, 147 /16s and 96 /24s Percentage of available address space announced: 63.2 Percentage of allocated address space announced: 65.2 Percentage of available address space allocated: 96.8 Percentage of address space in use by end-sites: 87.7 Total number of prefixes smaller than registry allocations: 141157 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 85214 Total APNIC prefixes after maximum aggregation: 28749 APNIC Deaggregation factor: 2.96 Prefixes being announced from the APNIC address blocks: 82002 Unique aggregates announced from the APNIC address blocks: 35485 APNIC Region origin ASes present in the Internet Routing Table: 4304 APNIC Prefixes per ASN: 19.05 APNIC Region origin ASes announcing only one prefix: 1214 APNIC Region transit ASes present in the Internet Routing Table: 692 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 20 Number of APNIC addresses announced to Internet: 582320928 Equivalent to 34 /8s, 181 /16s and 131 /24s Percentage of available APNIC address space announced: 78.9 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 138032 Total ARIN prefixes after maximum aggregation: 70612 ARIN Deaggregation factor: 1.95 Prefixes being announced from the ARIN address blocks: 108815 Unique aggregates announced from the ARIN address blocks: 44359 ARIN Region origin ASes present in the Internet Routing Table: 14136 ARIN Prefixes per ASN: 7.70 ARIN Region origin ASes announcing only one prefix: 5402 ARIN Region transit ASes present in the Internet Routing Table: 1479 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 23 Number of ARIN addresses announced to Internet: 746005632 Equivalent to 44 /8s, 119 /16s and 36 /24s Percentage of available ARIN address space announced: 62.6 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, 47/8, 48/8, 50/8, 52/8, 54/8, 55/8, 56/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, 107/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 80701 Total RIPE prefixes after maximum aggregation: 46018 RIPE Deaggregation factor: 1.75 Prefixes being announced from the RIPE address blocks: 74128 Unique aggregates announced from the RIPE address blocks: 48092 RIPE Region origin ASes present in the Internet Routing Table: 15214 RIPE Prefixes per ASN: 4.87 RIPE Region origin ASes announcing only one prefix: 7769 RIPE Region transit ASes present in the Internet Routing Table: 2372 Average RIPE Region AS path length visible: 4.6 Max RIPE Region AS path length visible: 33 Number of RIPE addresses announced to Internet: 456088640 Equivalent to 27 /8s, 47 /16s and 92 /24s Percentage of available RIPE address space announced: 75.5 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 196608-198655 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 176/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 31439 Total LACNIC prefixes after maximum aggregation: 7222 LACNIC Deaggregation factor: 4.35 Prefixes being announced from the LACNIC address blocks: 30223 Unique aggregates announced from the LACNIC address blocks: 15725 LACNIC Region origin ASes present in the Internet Routing Table: 1419 LACNIC Prefixes per ASN: 21.30 LACNIC Region origin ASes announcing only one prefix: 429 LACNIC Region transit ASes present in the Internet Routing Table: 247 Average LACNIC Region AS path length visible: 4.4 Max LACNIC Region AS path length visible: 19 Number of LACNIC addresses announced to Internet: 79629312 Equivalent to 4 /8s, 191 /16s and 12 /24s Percentage of available LACNIC address space announced: 59.3 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 181/8, 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 7474 Total AfriNIC prefixes after maximum aggregation: 1973 AfriNIC Deaggregation factor: 3.79 Prefixes being announced from the AfriNIC address blocks: 5799 Unique aggregates announced from the AfriNIC address blocks: 1913 AfriNIC Region origin ASes present in the Internet Routing Table: 435 AfriNIC Prefixes per ASN: 13.33 AfriNIC Region origin ASes announcing only one prefix: 137 AfriNIC Region transit ASes present in the Internet Routing Table: 93 Average AfriNIC Region AS path length visible: 5.5 Max AfriNIC Region AS path length visible: 31 Number of AfriNIC addresses announced to Internet: 21744896 Equivalent to 1 /8s, 75 /16s and 205 /24s Percentage of available AfriNIC address space announced: 43.2 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 105/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1911 9485 522 Korea Telecom (KIX) 7545 1586 301 82 TPG Internet Pty Ltd 4755 1400 636 160 TATA Communications formerly 17974 1385 467 27 PT TELEKOMUNIKASI INDONESIA 24560 1095 317 181 Bharti Airtel Ltd., Telemedia 9583 1043 76 486 Sify Limited 4808 1019 2108 287 CNCGROUP IP network: China169 17488 949 162 103 Hathway IP Over Cable Interne 18101 920 116 140 Reliance Infocom Ltd Internet 9829 862 729 48 BSNL National Internet Backbo 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 3710 3855 266 bellsouth.net, inc. 4323 2648 1077 403 Time Warner Telecom 19262 1839 4943 283 Verizon Global Networks 1785 1790 697 133 PaeTec Communications, Inc. 20115 1525 1530 641 Charter Communications 6478 1465 290 89 AT&T Worldnet Services 7018 1369 5650 882 AT&T WorldNet Services 2386 1299 553 934 AT&T Data Communications Serv 22773 1275 2864 77 Cox Communications, Inc. 11492 1266 234 78 Cable One Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6830 500 1763 306 UPC Distribution Services 9198 462 266 14 Kazakhtelecom Data Network Ad 34984 457 97 137 BILISIM TELEKOM 3292 444 2010 387 TDC Tele Danmark 8866 439 137 24 Bulgarian Telecommunication C 12479 404 577 6 Uni2 Autonomous System 8551 402 353 46 Bezeq International 3320 399 7618 349 Deutsche Telekom AG 702 398 1833 311 UUNET - Commercial IP service 20940 387 90 299 Akamai Technologies European 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 1355 251 165 TVCABLE BOGOTA 8151 1329 2613 363 UniNet S.A. de C.V. 28573 1231 953 86 NET Servicos de Comunicao S.A 6503 1148 355 78 AVANTEL, S.A. 7303 886 461 113 Telecom Argentina Stet-France 14420 604 50 89 CORPORACION NACIONAL DE TELEC 22047 567 310 15 VTR PUNTO NET S.A. 3816 521 222 102 Empresa Nacional de Telecomun 7738 478 922 30 Telecomunicacoes da Bahia S.A 14117 455 33 33 Telefonica del Sur 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 755 147 39 LINKdotNET AS number 8452 744 445 11 TEDATA 36992 663 283 155 Etisalat MISR 3741 264 987 226 The Internet Solution 24835 216 78 10 RAYA Telecom - Egypt 6713 203 199 12 Itissalat Al-MAGHRIB 29571 194 19 11 Ci Telecom Autonomous system 33776 182 12 14 Starcomms Nigeria Limited 2018 167 277 64 Tertiary Education Network 16637 160 440 90 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 3710 3855 266 bellsouth.net, inc. 4323 2648 1077 403 Time Warner Telecom 4766 1911 9485 522 Korea Telecom (KIX) 19262 1839 4943 283 Verizon Global Networks 1785 1790 697 133 PaeTec Communications, Inc. 7545 1586 301 82 TPG Internet Pty Ltd 20115 1525 1530 641 Charter Communications 6478 1465 290 89 AT&T Worldnet Services 4755 1400 636 160 TATA Communications formerly 17974 1385 467 27 PT TELEKOMUNIKASI INDONESIA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4323 2648 2245 Time Warner Telecom 1785 1790 1657 PaeTec Communications, Inc. 19262 1839 1556 Verizon Global Networks 7545 1586 1504 TPG Internet Pty Ltd 4766 1911 1389 Korea Telecom (KIX) 6478 1465 1376 AT&T Worldnet Services 17974 1385 1358 PT TELEKOMUNIKASI INDONESIA 4755 1400 1240 TATA Communications formerly 22773 1275 1198 Cox Communications, Inc. 10620 1355 1190 TVCABLE BOGOTA Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 4323 Time Warner Telecom 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 4323 Time Warner Telecom 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.155.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 5.0.0.0/16 12654 RIPE NCC RIS Project 5.1.0.0/21 12654 RIPE NCC RIS Project 5.1.24.0/24 12654 RIPE NCC RIS Project 24.129.192.0/19 7922 Continental Cablevision 37.0.0.0/16 12654 RIPE NCC RIS Project 37.1.0.0/21 12654 RIPE NCC RIS Project 37.1.24.0/24 12654 RIPE NCC RIS Project 41.222.79.0/24 36938 >>UNKNOWN<< 41.223.92.0/22 36936 >>UNKNOWN<< 46.226.80.0/21 38927 Net-Build GmbH 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:19 /9:10 /10:25 /11:70 /12:214 /13:438 /14:762 /15:1355 /16:11484 /17:5608 /18:9296 /19:18931 /20:24183 /21:24581 /22:32450 /23:31398 /24:179439 /25:980 /26:1080 /27:574 /28:160 /29:16 /30:2 /31:0 /32:8 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2289 3710 bellsouth.net, inc. 4323 1430 2648 Time Warner Telecom 6478 1419 1465 AT&T Worldnet Services 10620 1246 1355 TVCABLE BOGOTA 11492 1222 1266 Cable One 18566 1118 1137 Covad Communications 7011 1068 1171 Citizens Utilities 1785 1061 1790 PaeTec Communications, Inc. 19262 952 1839 Verizon Global Networks 6503 934 1148 AVANTEL, S.A. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:165 2:26 4:13 5:1 8:330 12:2029 13:1 14:378 15:15 16:3 17:8 20:9 23:1 24:1456 27:544 32:61 33:5 34:2 36:1 37:1 38:688 40:101 41:2301 42:1 44:3 46:525 47:5 49:142 50:56 52:12 55:8 56:2 57:31 58:869 59:483 60:391 61:1136 62:1011 63:1925 64:3754 65:2339 66:4102 67:1752 68:998 69:2878 70:719 71:392 72:1990 73:1 74:2296 75:291 76:326 77:852 78:705 79:433 80:1038 81:815 82:529 83:456 84:644 85:1043 86:526 87:727 88:350 89:1565 90:154 91:3419 92:492 93:1050 94:1150 95:761 96:413 97:249 98:751 99:33 101:18 107:3 108:79 109:847 110:465 111:698 112:309 113:366 114:490 115:633 116:885 117:677 118:631 119:1035 120:240 121:707 122:1606 123:1044 124:1264 125:1210 128:247 129:157 130:171 131:569 132:110 133:20 134:217 135:50 136:216 137:146 138:292 139:127 140:488 141:198 142:361 143:379 144:486 145:52 146:425 147:199 148:625 149:304 150:151 151:230 152:303 153:175 154:3 155:346 156:173 157:341 158:126 159:377 160:314 161:200 162:278 163:159 164:469 165:334 166:599 167:421 168:742 169:151 170:747 171:69 172:2 173:1246 174:506 175:306 176:1 177:4 178:745 180:758 182:391 183:249 184:204 186:938 187:807 188:906 189:1026 190:4359 192:5783 193:4788 194:3497 195:2934 196:1243 197:2 198:3552 199:3737 200:5607 201:1574 202:8288 203:8434 204:4083 205:2335 206:2525 207:2970 208:3863 209:3468 210:2638 211:1333 212:1863 213:1722 214:742 215:62 216:4840 217:1623 218:547 219:373 220:1198 221:445 222:346 223:90 End of report From tariq198487 at hotmail.com Fri Jan 21 12:39:51 2011 From: tariq198487 at hotmail.com (Tarig Ahmed) Date: Fri, 21 Jan 2011 21:39:51 +0300 Subject: how statefull firewall works for udp? Message-ID: <BLU0-SMTP53809E496540FA4BD76743BBF80@phx.gbl> Dear All Hi Default configuration for statefull firewall is to allow traffic form TRUST ZONE to UNTRUST ZONE. As I Know those device will use some feilds in the TCP Header. But, how the firewall will handle this policy for none TCP traffics (udp, icmp, and IPsec)? I think understanding this will help me in the designing. Thanks -- Tarig Yassin A. Ahmed www.suin.edu.sd skype:tarig_sudan1 From righa.shake at gmail.com Fri Jan 21 13:05:38 2011 From: righa.shake at gmail.com (Righa Shake) Date: Fri, 21 Jan 2011 22:05:38 +0300 Subject: Global Crossing Contact Message-ID: <AANLkTimMbPcRaO8pWc=TNz3hNNU9=ZbXzzoyES_FwP8B@mail.gmail.com> Kindly anyone on Global crossing get in touch with me off list. I have a routing problem that i require assistance. Regards, Shake Righa From the.lists at mgm51.com Fri Jan 21 13:17:39 2011 From: the.lists at mgm51.com (Mike.) Date: Fri, 21 Jan 2011 14:17:39 -0500 Subject: how statefull firewall works for udp? In-Reply-To: <BLU0-SMTP53809E496540FA4BD76743BBF80@phx.gbl> References: <BLU0-SMTP53809E496540FA4BD76743BBF80@phx.gbl> Message-ID: <201101211417390477.0141ABA0@sentry.24cl.com> On 1/21/2011 at 9:39 PM Tarig Ahmed wrote: |Dear All |Hi | |Default configuration for statefull firewall is to allow traffic form |TRUST ZONE to UNTRUST ZONE. | |As I Know those device will use some feilds in the TCP Header. | |But, how the firewall will handle this policy for none TCP traffics |(udp, icmp, and IPsec)? | |I think understanding this will help me in the designing. | |Thanks ============= Here's one way it is done: http://www.openbsd.org/faq/pf/filter.html#udpstate From owen at delong.com Fri Jan 21 13:28:18 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 21 Jan 2011 11:28:18 -0800 Subject: anyone running GPS clocks in Southeastern Georgia? In-Reply-To: <alpine.LNX.1.00.1101211020210.20342@catbert.rellim.com> References: <8662tiupsi.fsf@seastrom.com> <4D39C4B7.8050108@matthew.at> <alpine.LNX.1.00.1101211020210.20342@catbert.rellim.com> Message-ID: <2A2FBA01-0EF0-4908-85C0-3900E0473B6A@delong.com> On Jan 21, 2011, at 10:27 AM, Gary E. Miller wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Yo All! > > On Fri, 21 Jan 2011, Matthew Kaufman wrote: > >> I'm not sure how you'd get increasing radius with altitude from anything but a >> jammer near sea level. > > Agreed. > > One of these tests was recently run in Utah and we saw the effects > in Central Oregon well outside the NOTAMed area. During the tests, > airplanes using GPS navigation would suddenly lose RAIM and had to > abort their approach to landing. Not sure if they lost all GPS nav > information or just RAIM. > > For non pilots, RAIM is an indicator that the GPS has a redundant > solution that matches the barometrically measured altitude. GPS will > continue to report a nav solution when lacking this redundancy but > pilots are not allowed to shoot an approach when RAIM is off. > > Good thing most air carriers do not use GPS yet. > Not true. Most air carriers do use GPS. Most airliners are even WAAS capable these days. Good news is that while RAIM appears to fail under these tests, the WAAS capable GPSs seem to not lose their ability to shoot LPV approaches. Not sure why that is, but, I've been on an LPV approach during one of these tests when other pilots were calling missed on the LNAV version of the approach due to RAIM loss and I was able to continue the approach down to minimums and land. Owen (Commercial Pilot, Airplane, Single Engine Land, Instrument Airplane) From rs at seastrom.com Fri Jan 21 13:37:44 2011 From: rs at seastrom.com (Robert E. Seastrom) Date: Fri, 21 Jan 2011 14:37:44 -0500 Subject: anyone running GPS clocks in Southeastern Georgia? In-Reply-To: <4288131ED5E3024C9CD4782CECCAD2C70B9A32E2@LMC-MAIL2.exempla.org> (Kenneth L. Matlock's message of "Fri, 21 Jan 2011 11:19:23 -0700") References: <8662tiupsi.fsf@seastrom.com> <AANLkTikHQ27Uoy0NO0K3R+FXxHU6qhiCA4MhgwumFsrk@mail.gmail.com> <20110121173643.GA1831@puck.nether.net> <AANLkTinWP9XK_otuV8xQrf3i2LwQ7e_ynS31DGSaanpP@mail.gmail.com> <4288131ED5E3024C9CD4782CECCAD2C70B9A32E2@LMC-MAIL2.exempla.org> Message-ID: <86mxmuf3p3.fsf@seastrom.com> "Matlock, Kenneth L" <MatlockK at exempla.org> writes: > Probably related to: > > http://www.engadget.com/2011/01/20/faa-warns-of-ongoing-gps-issues-in-so > utheastern-us-due-to-defens/ > > Sounds like they're doing 'tests' on GPS near SE Georgia. Yes, very likely related considering that the map from the NOTAM is published on the engadget site. :-) The questions I implied are twofold: Firstly (idle curiosity) - does anyone have further publicly divulgable details on what's apparently a terrestrial jammer test or maybe an operational exercise involving the Bermuda Triangle and making planes and ships disappear... Secondly (operationally motivated) - I'd be interested to hear of any issues experienced by folks using GPS as a (terrestrial) NTP discipline source. -r From blake at ispn.net Fri Jan 21 13:40:33 2011 From: blake at ispn.net (Blake Hudson) Date: Fri, 21 Jan 2011 13:40:33 -0600 Subject: how statefull firewall works for udp? In-Reply-To: <BLU0-SMTP53809E496540FA4BD76743BBF80@phx.gbl> References: <BLU0-SMTP53809E496540FA4BD76743BBF80@phx.gbl> Message-ID: <4D39E131.70508@ispn.net> These protocols have their own headers, as well as the IP header that the firewall can use to maintain state. The difference between them and TCP is that these protocols are connectionless. Thus, the firewall does not know when the connection has closed. The typical solution to this is to have an arbitrary (often user configurable) timer that allows the firewall to remove old connections from the firewall's state table. A similar process also occurs with TCP, albeit with a much longer timeout, because of the possibility of connections not being closed correctly. --Blake -------- Original Message -------- Subject: how statefull firewall works for udp? From: Tarig Ahmed <tariq198487 at hotmail.com> To: nanog at nanog.org list <nanog at nanog.org>, African Network Operators <afnog at afnog.org> Date: Friday, January 21, 2011 12:39:51 PM > Dear All > Hi > > Default configuration for statefull firewall is to allow traffic form > TRUST ZONE to UNTRUST ZONE. > > As I Know those device will use some feilds in the TCP Header. > > But, how the firewall will handle this policy for none TCP traffics > (udp, icmp, and IPsec)? > > I think understanding this will help me in the designing. > > Thanks > From laurens at daemon.be Fri Jan 21 13:50:35 2011 From: laurens at daemon.be (Laurens Vets) Date: Fri, 21 Jan 2011 20:50:35 +0100 Subject: how statefull firewall works for udp? In-Reply-To: <BLU0-SMTP53809E496540FA4BD76743BBF80@phx.gbl> References: <BLU0-SMTP53809E496540FA4BD76743BBF80@phx.gbl> Message-ID: <4D39E38B.2080403@daemon.be> Hello, > Default configuration for statefull firewall is to allow traffic form > TRUST ZONE to UNTRUST ZONE. > > As I Know those device will use some feilds in the TCP Header. > > But, how the firewall will handle this policy for none TCP traffics > (udp, icmp, and IPsec)? http://lmgtfy.com/?q=+how+do+stateful+firewall+works+for+udp%3F > I think understanding this will help me in the designing. Kr, Laurens From michael.holstein at csuohio.edu Fri Jan 21 15:23:52 2011 From: michael.holstein at csuohio.edu (Michael Holstein) Date: Fri, 21 Jan 2011 16:23:52 -0500 Subject: anyone running GPS clocks in Southeastern Georgia? In-Reply-To: <8662tiupsi.fsf@seastrom.com> References: <8662tiupsi.fsf@seastrom.com> Message-ID: <4D39F968.3040005@csuohio.edu> > I'd be curious to see what effects (if any) those who use > GPS-disciplined NTP references in Southeastern Georgia see from this > experiment. > Aren't CDMA BTS clocked off GPS? NTP isn't going to be the only "ripple". Regards, Michael Holstein Cleveland State University From gary.buhrmaster at gmail.com Fri Jan 21 15:45:59 2011 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Fri, 21 Jan 2011 21:45:59 +0000 Subject: anyone running GPS clocks in Southeastern Georgia? In-Reply-To: <4D39F968.3040005@csuohio.edu> References: <8662tiupsi.fsf@seastrom.com> <4D39F968.3040005@csuohio.edu> Message-ID: <AANLkTim=Rks3MH+ySoYHYKaauZkhgV1-xJ05wXLxi=wE@mail.gmail.com> > NTP isn't going to be the only "ripple". Most of the "brand name" GPS NTP solutions have a clock with is more than stable enough to survive without GPS lock for 45 minutes(*). Some of the more expensive units with temperature controlled oscillators have hold times in the many weeks. My guess is that the NTP ripples will be limited to those NTP servers just (or recently) booted which have not yet achieved a stable clock state. Gary (*) This presumes that this test results in loss of signal lock, and not intentionally injected false information. From james.cutler at consultant.com Fri Jan 21 15:52:32 2011 From: james.cutler at consultant.com (Cutler James R) Date: Fri, 21 Jan 2011 16:52:32 -0500 Subject: anyone running GPS clocks in Southeastern Georgia? In-Reply-To: <4D39F968.3040005@csuohio.edu> References: <8662tiupsi.fsf@seastrom.com> <4D39F968.3040005@csuohio.edu> Message-ID: <DDB66D1A-2B20-4E03-8560-72B5C58EBCC2@consultant.com> On Jan 21, 2011, at 4:23 PM, Michael Holstein wrote: > >> I'd be curious to see what effects (if any) those who use >> GPS-disciplined NTP references in Southeastern Georgia see from this >> experiment. >> > > Aren't CDMA BTS clocked off GPS? > > NTP isn't going to be the only "ripple". > > Regards, > > Michael Holstein > Cleveland State University > Possibly relevant section from Agilent Designing and Testing 3GPP W-CDMA Base Transceiver Stations (Including Femtocells) Application Note 1355 1.15 Asynchronous cell site acquisition One of the W-CDMA design goals was to remove the requirement for GPS synchronization. Without dependence on GPS, the system could potentially be deployed in locations where GPS is not readily available, such as in a basement of a building or in temporary locations. W-CDMA accomplishes this asynchronous cell site operation through the use of several techniques. First, the scrambling codes in W-CDMA are Gold codes, so precise cell site time synchronization is not required. There are, however, 512 unique Gold codes allocated for cell site separation that the UE must search through. To facilitate this task, the SSC in the S-SCH channel is used to instruct the UE to search through a given set of 64 Gold codes. Each set represents a group of eight scrambling codes (64 x 8 = 512). The UE then tries each of the eight codes within each code group, in an attempt to decode the BCH. The ability to recover the BCH information (system frame number) completes the synchronization process. James R. Cutler james.cutler at consultant.com From james.cutler at consultant.com Fri Jan 21 15:53:08 2011 From: james.cutler at consultant.com (Cutler James R) Date: Fri, 21 Jan 2011 16:53:08 -0500 Subject: anyone running GPS clocks in Southeastern Georgia? In-Reply-To: <AANLkTim=Rks3MH+ySoYHYKaauZkhgV1-xJ05wXLxi=wE@mail.gmail.com> References: <8662tiupsi.fsf@seastrom.com> <4D39F968.3040005@csuohio.edu> <AANLkTim=Rks3MH+ySoYHYKaauZkhgV1-xJ05wXLxi=wE@mail.gmail.com> Message-ID: <8832FC97-C6E7-45CE-8A1B-F9D6EC2E32B3@consultant.com> On Jan 21, 2011, at 4:45 PM, Gary Buhrmaster wrote: >> NTP isn't going to be the only "ripple". > > Most of the "brand name" GPS NTP solutions have a clock > with is more than stable enough to survive without GPS > lock for 45 minutes(*). Some of the more expensive units with > temperature controlled oscillators have hold times in the > many weeks. My guess is that the NTP ripples will be > limited to those NTP servers just (or recently) booted > which have not yet achieved a stable clock state. > > Gary > > (*) This presumes that this test results in loss of signal > lock, and not intentionally injected false information. > Even if there actually was an "NTP ripple", a properly designed NTP solution should rely on at least three geographically diverse sources. Given the ubiquity of the internet this is not difficult to achieve, barring extreme circumstances. James R. Cutler james.cutler at consultant.com From cidr-report at potaroo.net Fri Jan 21 16:00:02 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 21 Jan 2011 22:00:02 GMT Subject: BGP Update Report Message-ID: <201101212200.p0LM02KA063410@wattle.apnic.net> BGP Update Report Interval: 13-Jan-11 -to- 20-Jan-11 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS18025 26565 0.9% 737.9 -- ACE-1-WIFI-AS-AP Ace-1 Wifi Network 2 - AS32528 19139 0.7% 2392.4 -- ABBOTT Abbot Labs 3 - AS6389 19026 0.7% 5.1 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 4 - AS17974 17314 0.6% 10.2 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 5 - AS24560 15517 0.6% 14.2 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 6 - AS25019 15407 0.5% 69.7 -- SAUDINETSTC-AS Autonomus System Number for SaudiNet 7 - AS28573 13779 0.5% 11.0 -- NET Servicos de Comunicao S.A. 8 - AS35931 13685 0.5% 2280.8 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 9 - AS4761 13378 0.5% 2.6 -- INDOSAT-INP-AP INDOSAT Internet Network Provider 10 - AS1785 13017 0.5% 7.3 -- AS-PAETEC-NET - PaeTec Communications, Inc. 11 - AS9829 12961 0.5% 15.0 -- BSNL-NIB National Internet Backbone 12 - AS33475 12866 0.5% 59.8 -- RSN-1 - RockSolid Network, Inc. 13 - AS2386 12415 0.4% 9.6 -- INS-AS - AT&T Data Communications Services 14 - AS24923 11681 0.4% 1297.9 -- SETTC South-East Transtelecom Joint Stock Co. 15 - AS20115 11568 0.4% 7.6 -- CHARTER-NET-HKY-NC - Charter Communications 16 - AS8151 11370 0.4% 8.2 -- Uninet S.A. de C.V. 17 - AS45194 11191 0.4% 174.9 -- SIPL-AS Syscon Infoway Pvt. Ltd., Internet Service Provider, India 18 - AS4323 11112 0.4% 4.2 -- TWTC - tw telecom holdings, inc. 19 - AS17803 10964 0.4% 19.1 -- BSES-AS-AP BSES TeleCom Limited 20 - AS9498 10930 0.4% 14.5 -- BBIL-AP BHARTI Airtel Ltd. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS32528 19139 0.7% 2392.4 -- ABBOTT Abbot Labs 2 - AS35931 13685 0.5% 2280.8 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 3 - AS49776 2278 0.1% 2278.0 -- GORSET-AS Gorodskaya Set Ltd. 4 - AS34239 1759 0.1% 1759.0 -- INTERAMERICAN General Insurance Company 5 - AS49600 1739 0.1% 1739.0 -- LASEDA La Seda de Barcelona, S.A 6 - AS24923 11681 0.4% 1297.9 -- SETTC South-East Transtelecom Joint Stock Co. 7 - AS40772 1874 0.1% 937.0 -- VELOCITER-WIRELESS-INC - Velociter Wireless, Inc. 8 - AS17874 857 0.0% 857.0 -- NPC-AS-KR National Pension Corporation 9 - AS6401 838 0.0% 838.0 -- ALLST-6401 - Allstream Corp. 10 - AS25164 2452 0.1% 817.3 -- FLUGHAFEN-ZUERICH Flughafen Zuerich AG, Autonomous System, Switzerland 11 - AS47649 813 0.0% 813.0 -- EGELI-INFORMATIK-AS EGELI Informatik AG 12 - AS16215 3250 0.1% 812.5 -- ASN-GENOTEC Genotec AG 13 - AS48288 810 0.0% 810.0 -- YPLAY YplaY 14 - AS27771 1592 0.1% 796.0 -- Instituto Venezolano de Investigaciones Cientificas 15 - AS44635 767 0.0% 767.0 -- COMPARIS-AS Comparis.ch AG 16 - AS18025 26565 0.9% 737.9 -- ACE-1-WIFI-AS-AP Ace-1 Wifi Network 17 - AS24491 1404 0.1% 702.0 -- WORLDWEB-THAILAND-AS-AP Internet Service Provider Thailand 18 - AS43821 676 0.0% 676.0 -- WIKIMEDIA-EU Wikimedia European network 19 - AS8652 1980 0.1% 660.0 -- DATAS-AS DATAS AG 20 - AS39764 654 0.0% 654.0 -- DOLPHIN Dolphin Systems AG TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 213.129.96.0/19 11636 0.4% AS24923 -- SETTC South-East Transtelecom Joint Stock Co. 2 - 130.36.35.0/24 9548 0.3% AS32528 -- ABBOTT Abbot Labs 3 - 130.36.34.0/24 9546 0.3% AS32528 -- ABBOTT Abbot Labs 4 - 63.211.68.0/22 8788 0.3% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 5 - 202.182.78.0/23 8375 0.3% AS10113 -- DATAFAST-AP DATAFAST TELECOMMUNICATIONS LTD 6 - 180.233.173.0/24 8155 0.3% AS45474 -- NEXUSGUARD-AS-AP Tower 1 Millennium City 1 7 - 216.126.136.0/22 7273 0.2% AS6316 -- AS-PAETEC-NET - PaeTec Communications, Inc. 8 - 27.123.248.0/22 5293 0.2% AS18025 -- ACE-1-WIFI-AS-AP Ace-1 Wifi Network 9 - 182.54.140.0/22 5289 0.2% AS18025 -- ACE-1-WIFI-AS-AP Ace-1 Wifi Network 10 - 182.54.148.0/22 5289 0.2% AS18025 -- ACE-1-WIFI-AS-AP Ace-1 Wifi Network 11 - 101.78.24.0/22 5245 0.2% AS18025 -- ACE-1-WIFI-AS-AP Ace-1 Wifi Network 12 - 101.78.20.0/22 5244 0.2% AS18025 -- ACE-1-WIFI-AS-AP Ace-1 Wifi Network 13 - 198.140.43.0/24 4785 0.2% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 14 - 202.92.235.0/24 4191 0.1% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 15 - 68.65.152.0/22 3519 0.1% AS11915 -- TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 16 - 189.85.51.0/24 3387 0.1% AS28175 -- 17 - 202.153.174.0/24 3342 0.1% AS17408 -- ABOVE-AS-AP AboveNet Communications Taiwan 18 - 206.184.16.0/24 3268 0.1% AS174 -- COGENT Cogent/PSI 19 - 170.141.231.0/24 2911 0.1% AS4454 -- TNET-AS - State of Tennessee 20 - 189.1.173.0/24 2821 0.1% AS28666 -- HOSTLOCATION LTDA Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu 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 Jan 21 16:00:00 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 21 Jan 2011 22:00:00 GMT Subject: The Cidr Report Message-ID: <201101212200.p0LM00Na063402@wattle.apnic.net> This report has been generated at Fri Jan 21 21:11:51 2011 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 14-01-11 343138 201301 15-01-11 342924 201380 16-01-11 343104 201536 17-01-11 343217 201694 18-01-11 343694 201329 19-01-11 343826 201288 20-01-11 344234 201476 21-01-11 344825 201680 AS Summary 36513 Number of ASes in routing system 15493 Number of ASes announcing only one prefix 3709 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 106832384 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'). --- 21Jan11 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 344918 201695 143223 41.5% All ASes AS6389 3709 271 3438 92.7% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 2637 408 2229 84.5% TWTC - tw telecom holdings, inc. AS19262 1839 283 1556 84.6% VZGNI-TRANSIT - Verizon Online LLC AS4766 1911 540 1371 71.7% KIXS-AS-KR Korea Telecom AS22773 1275 86 1189 93.3% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS6478 1465 284 1181 80.6% ATT-INTERNET3 - AT&T Services, Inc. AS10620 1355 187 1168 86.2% Telmex Colombia S.A. AS4755 1400 340 1060 75.7% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS1785 1792 767 1025 57.2% AS-PAETEC-NET - PaeTec Communications, Inc. AS28573 1245 298 947 76.1% NET Servicos de Comunicao S.A. AS7545 1587 723 864 54.4% TPG-INTERNET-AP TPG Internet Pty Ltd AS6503 1149 374 775 67.4% Axtel, S.A.B. de C.V. AS18101 918 150 768 83.7% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS24560 1095 331 764 69.8% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS7303 887 125 762 85.9% Telecom Argentina S.A. AS4808 1023 316 707 69.1% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS3356 1185 487 698 58.9% LEVEL3 Level 3 Communications AS11492 1256 582 674 53.7% CABLEONE - CABLE ONE, INC. AS17488 949 282 667 70.3% HATHWAY-NET-AP Hathway IP Over Cable Internet AS8151 1335 669 666 49.9% Uninet S.A. de C.V. AS18566 1137 502 635 55.8% COVAD - Covad Communications Co. AS9498 740 109 631 85.3% BBIL-AP BHARTI Airtel Ltd. AS855 632 55 577 91.3% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS17676 645 68 577 89.5% GIGAINFRA Softbank BB Corp. AS4812 670 107 563 84.0% CHINANET-SH-AP China Telecom (Group) AS7552 658 112 546 83.0% VIETEL-AS-AP Vietel Corporation AS22047 567 31 536 94.5% VTR BANDA ANCHA S.A. AS14420 604 94 510 84.4% CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP AS3549 863 359 504 58.4% GBLX Global Crossing Ltd. AS9443 570 75 495 86.8% INTERNETPRIMUS-AS-AP Primus Telecommunications Total 37098 9015 28083 75.7% Top 30 total Possible Bogus Routes 5.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 5.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 5.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 24.129.192.0/19 AS7922 COMCAST-7922 - Comcast Cable Communications, Inc. 37.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 37.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 37.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 46.226.104.0/21 AS29169 GANDI-AS Gandi SAS - Domain name registrar - http://www.gandi.net 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.18.224.0/20 AS12129 123NET - 123.Net, Inc. 64.21.192.0/20 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.212.0/22 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.216.0/21 AS11610 INETNEBR-1 - Internet Nebraska Corporation 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 69.6.81.0/24 AS13442 71.19.134.0/23 AS3313 INET-AS I.NET S.p.A. 72.22.32.0/19 AS33150 72.22.61.0/24 AS33150 72.22.62.0/24 AS33150 76.77.32.0/19 AS2828 XO-AS15 - XO Communications 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 96.45.161.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.162.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.163.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.164.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.165.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.166.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.167.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.168.0/21 AS3257 TINET-BACKBONE Tinet SpA 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas 110.173.64.0/19 AS37963 CNNIC-ALIBABA-CN-NET-AP Alibaba (China) Technology Co., Ltd. 113.29.0.0/17 AS3549 GBLX Global Crossing Ltd. 113.29.0.0/20 AS3549 GBLX Global Crossing Ltd. 113.29.16.0/20 AS3549 GBLX Global Crossing Ltd. 113.29.32.0/20 AS3549 GBLX Global Crossing Ltd. 113.29.64.0/20 AS3549 GBLX Global Crossing Ltd. 115.42.28.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.30.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.40.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.42.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.44.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.47.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.48.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.49.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.50.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.51.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.52.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.53.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.54.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.55.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.56.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.57.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.58.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.59.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.61.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.62.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.63.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 116.68.136.0/21 AS28045 Pantel Communications 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 121.54.160.0/24 AS38890 121.54.161.0/24 AS38890 121.54.162.0/24 AS38890 121.54.163.0/24 AS38890 121.54.164.0/24 AS38890 121.54.166.0/24 AS38890 121.54.167.0/24 AS38890 121.200.192.0/24 AS17767 122.200.32.0/20 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services Inc. 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 172.12.0.0/18 AS28665 PredialNet Provedor de Internet Ltda. 176.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 176.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 176.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 190.102.32.0/20 AS30058 FDCSERVERS - FDCservers.net 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.101.46.0/24 AS6503 Axtel, S.A.B. de C.V. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 196.2.224.0/22 AS24863 LINKdotNET-AS 196.6.108.0/24 AS5713 SAIX-NET 196.13.201.0/24 AS2018 TENET-1 196.13.202.0/24 AS2018 TENET-1 196.13.203.0/24 AS2018 TENET-1 196.13.204.0/24 AS2018 TENET-1 196.110.105.0/24 AS8513 SKYVISION SkyVision Network Services 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.15.4.0/24 AS4323 TWTC - tw telecom holdings, inc. 198.15.5.0/24 AS4323 TWTC - tw telecom holdings, inc. 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.99.241.0/24 AS11797 AC-NIELSEN-AS AC NIELSEN 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.175.231.0/24 AS19262 VZGNI-TRANSIT - Verizon Online LLC 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 198.182.235.0/24 AS3356 LEVEL3 Level 3 Communications 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 199.185.130.0/23 AS19662 UNISERVE-ONLINE - Uniserve On Line 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.233.92.0/24 AS26896 D102-ITC - Data 102, LLC 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.24.73.0/24 AS26061 Equant Colombia 200.24.78.0/26 AS3549 GBLX Global Crossing Ltd. 200.24.78.64/26 AS3549 GBLX Global Crossing Ltd. 202.1.224.0/24 AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000 202.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.58.113.0/24 AS19161 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.66.128.0/18 AS9584 GENESIS-AP Diyixian.com Limited 202.66.160.0/19 AS9584 GENESIS-AP Diyixian.com Limited 202.66.160.0/20 AS9584 GENESIS-AP Diyixian.com Limited 202.66.176.0/20 AS9584 GENESIS-AP Diyixian.com Limited 202.66.184.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.186.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.188.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.189.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.190.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.133.37.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.146.186.0/24 AS23655 SNAP-NZ-AS Snap Internet Limited 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 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.130.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.131.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.133.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 202.179.144.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.149.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.150.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.18.156.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.22.78.0/24 AS18117 HARBOURMSP-AU-AP Harbour MSP Pty. Ltd 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.27.123.0/24 AS4739 CIX-ADELAIDE-AS Internode Systems Pty Ltd 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.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.142.219.0/24 AS45149 203.175.107.0/24 AS45595 PKTELECOM-AS-PK Pakistan Telecom Company Limited 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.10.232.0/21 AS33150 204.19.14.0/23 AS577 BACOM - Bell Canada 204.209.114.0/24 AS13768 PEER1 - Peer 1 Network Inc. 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 DISTRIBUTEL-AS11814 - DISTRIBUTEL COMMUNICATIONS LTD. 205.207.148.0/23 AS812 ROGERS-CABLE - Rogers Cable Communications Inc. 205.210.145.0/24 AS11814 DISTRIBUTEL-AS11814 - DISTRIBUTEL COMMUNICATIONS LTD. 206.72.192.0/23 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 206.72.194.0/23 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 206.123.129.0/24 AS10790 INREACH-AS - InReach Internet 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.188.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.189.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.190.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.191.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.64.200.0/22 AS11730 CIL-ASN - Circle Internet LTD 208.64.240.0/21 AS13871 TELEBYTE-NW - Telebyte NW 208.73.160.0/24 AS32767 208.78.165.0/24 AS16565 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.83.54.0/24 AS23485 SEI-LLC-AS-NUM - SEI LLC 208.89.60.0/22 AS40626 208.92.196.0/22 AS10929 NETELLIGENT - Netelligent Hosting Services Inc. 208.92.199.0/24 AS26198 3MENATWORK - 3Men at Work Integrated Networks, Inc. 208.94.48.0/21 AS19406 TWRS-MA - Towerstream I, Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.165.239.0/24 AS209 ASN-QWEST - Qwest Communications Company, LLC 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.213.1.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 209.213.4.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 216.10.235.0/24 AS13780 NTNCOMMUNICATIONS - NTN 216.10.236.0/24 AS13780 NTNCOMMUNICATIONS - NTN 216.21.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 216.21.196.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.201.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.202.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.206.0/23 AS12251 INVISION - Invision.com, Inc. 216.58.192.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.197.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.200.0/24 AS18530 ISOMEDIA-1 - Isomedia Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.194.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 216.250.112.0/20 AS7296 ALCHEMYNET - Alchemy Communications, Inc. Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From rs at seastrom.com Fri Jan 21 16:26:43 2011 From: rs at seastrom.com (Robert E. Seastrom) Date: Fri, 21 Jan 2011 17:26:43 -0500 Subject: anyone running GPS clocks in Southeastern Georgia? In-Reply-To: <4D39F968.3040005@csuohio.edu> (Michael Holstein's message of "Fri, 21 Jan 2011 16:23:52 -0500") References: <8662tiupsi.fsf@seastrom.com> <4D39F968.3040005@csuohio.edu> Message-ID: <86oc79c2qk.fsf@seastrom.com> Michael Holstein <michael.holstein at csuohio.edu> writes: >> I'd be curious to see what effects (if any) those who use >> GPS-disciplined NTP references in Southeastern Georgia see from this >> experiment. > > Aren't CDMA BTS clocked off GPS? > > NTP isn't going to be the only "ripple". Sure, and there are GPS-steered Rb clocks in telco-land too as well as a ton of stuff I don't know about yet until everyone else here chimes in; it's just that NTP is highly visible to NANOGers. -r From rs at seastrom.com Fri Jan 21 16:37:46 2011 From: rs at seastrom.com (Robert E. Seastrom) Date: Fri, 21 Jan 2011 17:37:46 -0500 Subject: anyone running GPS clocks in Southeastern Georgia? In-Reply-To: <AANLkTim=Rks3MH+ySoYHYKaauZkhgV1-xJ05wXLxi=wE@mail.gmail.com> (Gary Buhrmaster's message of "Fri, 21 Jan 2011 21:45:59 +0000") References: <8662tiupsi.fsf@seastrom.com> <4D39F968.3040005@csuohio.edu> <AANLkTim=Rks3MH+ySoYHYKaauZkhgV1-xJ05wXLxi=wE@mail.gmail.com> Message-ID: <8639olannp.fsf@seastrom.com> Gary Buhrmaster <gary.buhrmaster at gmail.com> writes: >> NTP isn't going to be the only "ripple". > > Most of the "brand name" GPS NTP solutions have a clock > with is more than stable enough to survive without GPS > lock for 45 minutes(*). Some of the more expensive units with > temperature controlled oscillators have hold times in the > many weeks. My guess is that the NTP ripples will be > limited to those NTP servers just (or recently) booted > which have not yet achieved a stable clock state. > > Gary > > (*) This presumes that this test results in loss of signal > lock, and not intentionally injected false information. Seeing the ripples also presumes that people are monitoring their NTP system health more closely than just looking at the output of ntpq -p. :) -r From jamesbbrown04 at gmail.com Fri Jan 21 16:44:47 2011 From: jamesbbrown04 at gmail.com (James Brown) Date: Fri, 21 Jan 2011 17:44:47 -0500 Subject: anyone running GPS clocks in Southeastern Georgia? In-Reply-To: <86oc79c2qk.fsf@seastrom.com> References: <8662tiupsi.fsf@seastrom.com> <4D39F968.3040005@csuohio.edu> <86oc79c2qk.fsf@seastrom.com> Message-ID: <AANLkTik4kr_sS59q8Wz5kM_R=qzjPrd27uZbcLsyOOBx@mail.gmail.com> On Fri, Jan 21, 2011 at 5:26 PM, Robert E. Seastrom <rs at seastrom.com> wrote: > Sure, and there are GPS-steered Rb clocks in telco-land too as well as > a ton of stuff I don't know about yet until everyone else here chimes > in; it's just that NTP is highly visible to NANOGers. > > > What about Modular DOCSIS 3.0 deployments with external timing sources between the QAM and CMTS From joelja at bogus.com Fri Jan 21 16:49:44 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Fri, 21 Jan 2011 14:49:44 -0800 Subject: anyone running GPS clocks in Southeastern Georgia? In-Reply-To: <86oc79c2qk.fsf@seastrom.com> References: <8662tiupsi.fsf@seastrom.com> <4D39F968.3040005@csuohio.edu> <86oc79c2qk.fsf@seastrom.com> Message-ID: <4D3A0D88.7000000@bogus.com> On 1/21/11 2:26 PM, Robert E. Seastrom wrote: > > Michael Holstein <michael.holstein at csuohio.edu> writes: > >>> I'd be curious to see what effects (if any) those who use >>> GPS-disciplined NTP references in Southeastern Georgia see from this >>> experiment. >> >> Aren't CDMA BTS clocked off GPS? >> >> NTP isn't going to be the only "ripple". > > Sure, and there are GPS-steered Rb clocks in telco-land too as well as > a ton of stuff I don't know about yet until everyone else here chimes > in; it's just that NTP is highly visible to NANOGers. if your high quality stratum one time source isn't capable of free-running for a little while then it's not really high quality... you can of course test this simply by disconnecting the antenna. if the dilution of precision gets sufficiently high or the boise floor climbs above the signal then it should fail the gps out of the mix. our symerticoms have upgraded ocxo and backup geographically distant ntp sources in the pool to account for localized gps failure... I'm way to cheap to spring for the rubidum upgrade, the ocxo holdover is supposed to be 1ms a day. > -r > > > From owen at delong.com Fri Jan 21 17:01:10 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 21 Jan 2011 15:01:10 -0800 Subject: anyone running GPS clocks in Southeastern Georgia? In-Reply-To: <AANLkTim=Rks3MH+ySoYHYKaauZkhgV1-xJ05wXLxi=wE@mail.gmail.com> References: <8662tiupsi.fsf@seastrom.com> <4D39F968.3040005@csuohio.edu> <AANLkTim=Rks3MH+ySoYHYKaauZkhgV1-xJ05wXLxi=wE@mail.gmail.com> Message-ID: <AF7A2AA8-2B3C-40CC-83B3-E7072D569260@delong.com> On Jan 21, 2011, at 1:45 PM, Gary Buhrmaster wrote: >> NTP isn't going to be the only "ripple". > > Most of the "brand name" GPS NTP solutions have a clock > with is more than stable enough to survive without GPS > lock for 45 minutes(*). Some of the more expensive units with > temperature controlled oscillators have hold times in the > many weeks. My guess is that the NTP ripples will be > limited to those NTP servers just (or recently) booted > which have not yet achieved a stable clock state. > > Gary > > (*) This presumes that this test results in loss of signal > lock, and not intentionally injected false information. Loss of lock is a non-issue. However, the tests they are doing do not necessarily cause loss of lock. Sometimes, instead, they give you a wrong enough time to insure that your navigational fix is off by, well, enough to guarantee that you don't hit what you're aiming at. Owen From rs at seastrom.com Fri Jan 21 18:06:15 2011 From: rs at seastrom.com (Robert E. Seastrom) Date: Fri, 21 Jan 2011 19:06:15 -0500 Subject: anyone running GPS clocks in Southeastern Georgia? In-Reply-To: <4D3A0D88.7000000@bogus.com> (Joel Jaeggli's message of "Fri, 21 Jan 2011 14:49:44 -0800") References: <8662tiupsi.fsf@seastrom.com> <4D39F968.3040005@csuohio.edu> <86oc79c2qk.fsf@seastrom.com> <4D3A0D88.7000000@bogus.com> Message-ID: <86y66diyyw.fsf@seastrom.com> Joel Jaeggli <joelja at bogus.com> writes: >> Sure, and there are GPS-steered Rb clocks in telco-land too as well as >> a ton of stuff I don't know about yet until everyone else here chimes >> in; it's just that NTP is highly visible to NANOGers. > > if your high quality stratum one time source isn't capable of > free-running for a little while then it's not really high quality... <cough> no comment. :-P > you can of course test this simply by disconnecting the antenna. if the > dilution of precision gets sufficiently high or the boise floor climbs > above the signal then it should fail the gps out of the mix. our > symerticoms have upgraded ocxo and backup geographically distant ntp > sources in the pool to account for localized gps failure... > > I'm way to cheap to spring for the rubidum upgrade, the ocxo holdover is > supposed to be 1ms a day. Actually, if you are rolling your own (admittedly not what you're doing when you buy Symmetricoms, but then again they are maintainable in the field as opposed to the mad scientist stuff we have in our basements), surplus Rb clocks are astonishingly cheap. I have seen used Datum LPROs (admittedly they are cheapies with higher Allan deviation over short intervals than the PRS10) for circa $100. -r From scubacuda at gmail.com Fri Jan 21 19:37:49 2011 From: scubacuda at gmail.com (Rogelio) Date: Fri, 21 Jan 2011 23:37:49 -0200 Subject: new subscription management tools driven by LTE? Message-ID: <4D3A34ED.5030202@gmail.com> With LTE picking up momentum, what type of new subscription management tools will operators need? (e.g. control complexities of billions of mobile data transactions, personalized billing, centralized control across various licensed and unlicensed bands, alerts when limits reached, etc.) Bridgewater is one that I have been looking at lately... http://www.bridgewatersystems.com/LTE.aspx ...but I would be curious as to what other companies are seeing out there. From lowen at pari.edu Fri Jan 21 15:29:03 2011 From: lowen at pari.edu (Lamar Owen) Date: Fri, 21 Jan 2011 16:29:03 -0500 Subject: anyone running GPS clocks in Southeastern Georgia? In-Reply-To: <4D39F968.3040005@csuohio.edu> References: <8662tiupsi.fsf@seastrom.com> Message-ID: <201101211629.03342.lowen@pari.edu> On Friday, January 21, 2011 04:23:52 pm Michael Holstein wrote: > Aren't CDMA BTS clocked off GPS? Yep; and many of the aftermarket GPS receivers commonly used for the disciplined clock for NTP originally came from that service (Agilent/HP Z3801 and Z3816, for instance). From pete at altadena.net Fri Jan 21 20:48:38 2011 From: pete at altadena.net (Pete Carah) Date: Fri, 21 Jan 2011 21:48:38 -0500 Subject: anyone running GPS clocks in Southeastern Georgia? In-Reply-To: <201101211629.03342.lowen@pari.edu> References: <8662tiupsi.fsf@seastrom.com> <201101211629.03342.lowen@pari.edu> Message-ID: <4D3A4586.6010602@altadena.net> On 01/21/2011 04:29 PM, Lamar Owen wrote: > On Friday, January 21, 2011 04:23:52 pm Michael Holstein wrote: >> Aren't CDMA BTS clocked off GPS? > Yep; and many of the aftermarket GPS receivers commonly used for the disciplined clock for NTP originally came from that service (Agilent/HP Z3801 and Z3816, for instance). Boo. You can't find the 3816 much anymore and the 3801 isn't as good (fine for most ntp purposes,though) (the difference is mostly in internal measurement software and how long it will hold without the gps signal). And Symmetricom bought that line from HP, still sells one comparable to the Z3801 but not like the 3816 for a decent price. Personally I'd build one up out of an LPRO, a Trimble timing receiver (current replacement for the Oncore used in the Z38xx units, last I checked it was under $100), a MSP430 (probably a fairly high-end one to get enough program space for a good PLL) and some external logic for phase comparators (I don't know if the timer capture modes in the 430 are good enough by themselves...) The most expensive single part would be a decent timing antenna (yes, timing antennas *are* different from the usual civilian positioning antennas; there is a reason why the base is larger diameter than the rest...) Actually, does anyone still do soft handoff with UMTS? That was much of the reason why old CDMA needed a GPS reference. -- Pete From beckman at angryox.com Fri Jan 21 22:54:34 2011 From: beckman at angryox.com (Peter Beckman) Date: Fri, 21 Jan 2011 23:54:34 -0500 Subject: anyone running GPS clocks in Southeastern Georgia? In-Reply-To: <86mxmuf3p3.fsf@seastrom.com> References: <8662tiupsi.fsf@seastrom.com> <AANLkTikHQ27Uoy0NO0K3R+FXxHU6qhiCA4MhgwumFsrk@mail.gmail.com> <20110121173643.GA1831@puck.nether.net> <AANLkTinWP9XK_otuV8xQrf3i2LwQ7e_ynS31DGSaanpP@mail.gmail.com> <4288131ED5E3024C9CD4782CECCAD2C70B9A32E2@LMC-MAIL2.exempla.org> <86mxmuf3p3.fsf@seastrom.com> Message-ID: <alpine.BSF.2.00.1101212349140.47306@nog.angryox.com> On Fri, 21 Jan 2011, Robert E. Seastrom wrote: > Firstly (idle curiosity) - does anyone have further publicly > divulgable details on what's apparently a terrestrial jammer test or > maybe an operational exercise involving the Bermuda Triangle and > making planes and ships disappear... My first thought was testing UAVs and what they do in situations where GPS is jammed, blocked or provides false information. Doing so in an area where a total loss of control of the aircraft would result in a drop in the ocean rather than in or around a populated area is a good idea. Maybe there are already unit tests for such situations. --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From townsley at cisco.com Sat Jan 22 04:56:49 2011 From: townsley at cisco.com (Mark Townsley) Date: Sat, 22 Jan 2011 11:56:49 +0100 Subject: World IPv6 Day In-Reply-To: <20110113075355.548b19bd@opy.nosense.org> References: <AANLkTik-Xk8Pk_i_3Mo6_2usU=3kAKh-X9mmxtKCVcxA@mail.gmail.com> <m2mxn6q6pg.wl%randy@psg.com> <20110113075355.548b19bd@opy.nosense.org> Message-ID: <4D3AB7F1.4040409@cisco.com> On 1/12/11 10:23 PM, Mark Smith wrote: > On Wed, 12 Jan 2011 11:10:03 -0800 > Randy Bush <randy at psg.com> wrote: > >> > the first global-scale trial of IPv6, the long-anticipated upgrade to >> > the Internet's main communications protocol known as IPv4. >> >> this phrasing is both amusing and deeply sad. amusing because many folk >> have been running ipv6 globaly for over a decade. deeply sad because >> this is taken to be shiny and new as we approach the end of the iana >> ipv4 free pool. what have people been smoking? >> > > IPv4. > > Every now and then it is worth remembering that IPv4 was a protocol > that was designed for a small experimental network that managed to > escape into production. How long it has been usable is actually quite > remarkable, and has only been achieved through a series of neat hacks > like classes, subnets and CIDR. And NAPT, and VPNs, and short IP leases, and... FWIW, Cisco's jumping in with Google, FB, et. al. http://blogs.cisco.com/news/world-ipv6-day-working-together-towards-a-new-internet-protocol/ Have a nice weekend, - Mark > > > Regards, > Mark. > > > From bross at pobox.com Sat Jan 22 06:10:49 2011 From: bross at pobox.com (Brandon Ross) Date: Sat, 22 Jan 2011 07:10:49 -0500 (EST) Subject: anyone running GPS clocks in Southeastern Georgia? In-Reply-To: <alpine.LNX.1.00.1101211020210.20342@catbert.rellim.com> References: <8662tiupsi.fsf@seastrom.com> <4D39C4B7.8050108@matthew.at> <alpine.LNX.1.00.1101211020210.20342@catbert.rellim.com> Message-ID: <Pine.OSX.4.64.1101220706020.336@cevin-2.local> On Fri, 21 Jan 2011, Gary E. Miller wrote: > For non pilots, RAIM is an indicator that the GPS has a redundant > solution that matches the barometrically measured altitude. I know this is off topic, but I don't like to let incorrect information float around uncorrected. RAIM never uses any data outside of GPS to confirm position, it is based entirely on more than the minimum number of satellites needed for a basic position to calculate redundant solutions, which means a minimum of 5 satellites. If this were not the case, it would be impossible to get a RAIM "prediction" (using data about out of service sats) in advance of a flight. -- Brandon Ross AIM: BrandonNRoss ICQ: 2269442 Skype: brandonross Yahoo: BrandonNRoss From roll at Stupi.SE Sat Jan 22 13:22:12 2011 From: roll at Stupi.SE (Peter Lothberg) Date: Sat, 22 Jan 2011 13:22:12 CET Subject: anyone running GPS clocks in Southeastern Georgia? In-Reply-To: <4D3A0D88.7000000@bogus.com> Message-ID: <CMM.0.95.0.1295698932.roll@rutten.stupi.se> > On 1/21/11 2:26 PM, Robert E. Seastrom wrote: > > > > Michael Holstein <michael.holstein at csuohio.edu> writes: > > > >>> I'd be curious to see what effects (if any) those who use > >>> GPS-disciplined NTP references in Southeastern Georgia see from this > >>> experiment. > >> > >> Aren't CDMA BTS clocked off GPS? > >> > >> NTP isn't going to be the only "ripple". > > > > Sure, and there are GPS-steered Rb clocks in telco-land too as well as > > a ton of stuff I don't know about yet until everyone else here chimes > > in; it's just that NTP is highly visible to NANOGers. > > if your high quality stratum one time source isn't capable of > free-running for a little while then it's not really high quality... > > you can of course test this simply by disconnecting the antenna. if the > dilution of precision gets sufficiently high or the boise floor climbs > above the signal then it should fail the gps out of the mix. our > symerticoms have upgraded ocxo and backup geographically distant ntp > sources in the pool to account for localized gps failure... > > I'm way to cheap to spring for the rubidum upgrade, the ocxo holdover is > supposed to be 1ms a day. The recomndation for a UTC timescales is to be within less than 1us of UTC at any given time. -P From jra at baylink.com Sat Jan 22 08:30:14 2011 From: jra at baylink.com (Jay Ashworth) Date: Sat, 22 Jan 2011 09:30:14 -0500 (EST) Subject: National Squirrel Appreciation Day Message-ID: <24237706.1572.1295706614360.JavaMail.root@benjamin.baylink.com> The holiday is today, according to holidayinsights.com http://www.holidayinsights.com/moreholidays/January/squirrelappreciation.htm Did anyone ever do the scope-sight T-shirt? No, wait; that was a backhoe. Cheers, -- jra From davidd at corp.nac.net Sat Jan 22 08:43:17 2011 From: davidd at corp.nac.net (David DiGiacomo) Date: Sat, 22 Jan 2011 09:43:17 -0500 Subject: National Squirrel Appreciation Day In-Reply-To: <24237706.1572.1295706614360.JavaMail.root@benjamin.baylink.com> References: <24237706.1572.1295706614360.JavaMail.root@benjamin.baylink.com> Message-ID: <391C0EEA-88E5-4B9D-B3A7-A95B68A94D1D@corp.nac.net> Just be sure to keep a close eye on your nuts today! Sent from my iPad On Jan 22, 2011, at 9:30 AM, "Jay Ashworth" <jra at baylink.com> wrote: > The holiday is today, according to holidayinsights.com > > http://www.holidayinsights.com/moreholidays/January/squirrelappreciation.htm > > Did anyone ever do the scope-sight T-shirt? No, wait; that was a backhoe. > > Cheers, > -- jra > From graham at g-rock.net Sat Jan 22 09:06:35 2011 From: graham at g-rock.net (Graham Wooden) Date: Sat, 22 Jan 2011 09:06:35 -0600 Subject: National Squirrel Appreciation Day In-Reply-To: <24237706.1572.1295706614360.JavaMail.root@benjamin.baylink.com> Message-ID: <C9604E9B.2A94E%graham@g-rock.net> I guess this then 'would not be' in the spirit of the holiday ... http://www.youtube.com/watch?v=M5-d3rZZ-_M -graham On 1/22/11 8:30 AM, "Jay Ashworth" <jra at baylink.com> wrote: > The holiday is today, according to holidayinsights.com > > http://www.holidayinsights.com/moreholidays/January/squirrelappreciation.htm > > Did anyone ever do the scope-sight T-shirt? No, wait; that was a backhoe. > > Cheers, > -- jra > From BaklarR at amtrak.com Sat Jan 22 09:15:12 2011 From: BaklarR at amtrak.com (Baklarz, Ron) Date: Sat, 22 Jan 2011 10:15:12 -0500 Subject: National Squirrel Appreciation Day In-Reply-To: <24237706.1572.1295706614360.JavaMail.root@benjamin.baylink.com> References: <24237706.1572.1295706614360.JavaMail.root@benjamin.baylink.com> Message-ID: <678962AA58F5D94FAC3329B7676FAEB73E762F0383@AMTMB05.amtrak.ad.nrpc> http://www.ehow.com/how_5050434_make-squirrel-poison.html ________________________________________ From: Jay Ashworth [jra at baylink.com] Sent: Saturday, January 22, 2011 9:30 AM To: NANOG Subject: National Squirrel Appreciation Day The holiday is today, according to holidayinsights.com http://www.holidayinsights.com/moreholidays/January/squirrelappreciation.htm Did anyone ever do the scope-sight T-shirt? No, wait; that was a backhoe. Cheers, -- jra From llynch at civil-tongue.net Sat Jan 22 12:53:34 2011 From: llynch at civil-tongue.net (Lucy Lynch) Date: Sat, 22 Jan 2011 10:53:34 -0800 (PST) Subject: National Squirrel Appreciation Day In-Reply-To: <391C0EEA-88E5-4B9D-B3A7-A95B68A94D1D@corp.nac.net> References: <24237706.1572.1295706614360.JavaMail.root@benjamin.baylink.com> <391C0EEA-88E5-4B9D-B3A7-A95B68A94D1D@corp.nac.net> Message-ID: <alpine.BSF.2.00.1101221038530.14751@hiroshima.bogus.com> On Sat, 22 Jan 2011, David DiGiacomo wrote: > Just be sure to keep a close eye on your nuts today! http://www.ibiblio.org/Dave/Dr-Fun/df200404/df20040423.jpg boy, do I miss Dr Fun http://www.ibiblio.org/Dave/Dr-Fun/df200206/df20020612.jpg > > > Sent from my iPad > > On Jan 22, 2011, at 9:30 AM, "Jay Ashworth" <jra at baylink.com> wrote: > >> The holiday is today, according to holidayinsights.com >> >> http://www.holidayinsights.com/moreholidays/January/squirrelappreciation.htm >> >> Did anyone ever do the scope-sight T-shirt? No, wait; that was a backhoe. >> >> Cheers, >> -- jra >> > From tkapela at gmail.com Sun Jan 23 10:26:06 2011 From: tkapela at gmail.com (Anton Kapela) Date: Sun, 23 Jan 2011 10:26:06 -0600 Subject: anyone running GPS clocks in Southeastern Georgia? In-Reply-To: <AANLkTik4kr_sS59q8Wz5kM_R=qzjPrd27uZbcLsyOOBx@mail.gmail.com> References: <8662tiupsi.fsf@seastrom.com> <4D39F968.3040005@csuohio.edu> <86oc79c2qk.fsf@seastrom.com> <AANLkTik4kr_sS59q8Wz5kM_R=qzjPrd27uZbcLsyOOBx@mail.gmail.com> Message-ID: <AANLkTi=qf=AH+dkL5hvXMq2TEkRsOBCnzU0Dfcie0ZBP@mail.gmail.com> > What about Modular DOCSIS 3.0 deployments with external timing sources > between the QAM and CMTS A CMTS DS payload is formatted as an MPEG TS (it even has PIDs; however, no PCR). This in turn establishes cadence for associated downstream devices (eg. they sync to whatever is within allowable tolerances). Any digital 'baseband' output from a so-called 'modular' CMTS (one with external QAM modulation) should likewise serve as a recoverable timing source for the modulator. Inter-DS cadence is allowably async; the only important coupling here are these associated US channels available for a given DS. Unless I've missed something horribly obvious, I can't see where strict timing is important, nor can I see where inter or intra-system synchronization would be critical either, save for corner-cases (i.e. US or DS dynamic channel change, DCC/UDC, etc). Even in these cases, the modem is more than able to rapidly resynchronize with a new/differing cadence in both frequency and phase domains. I guess, in short, don't worry (about this). -Tk From cb.list6 at gmail.com Sun Jan 23 10:32:52 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Sun, 23 Jan 2011 08:32:52 -0800 Subject: anyone running GPS clocks in Southeastern Georgia? In-Reply-To: <4D3A4586.6010602@altadena.net> References: <8662tiupsi.fsf@seastrom.com> <201101211629.03342.lowen@pari.edu> <4D3A4586.6010602@altadena.net> Message-ID: <AANLkTi=-HOnacXaa+f6hLULHeq2KgKZJ+26sWUcgyv2H@mail.gmail.com> On Jan 21, 2011 6:49 PM, "Pete Carah" <pete at altadena.net> wrote: > > On 01/21/2011 04:29 PM, Lamar Owen wrote: > > On Friday, January 21, 2011 04:23:52 pm Michael Holstein wrote: > >> Aren't CDMA BTS clocked off GPS? > > Yep; and many of the aftermarket GPS receivers commonly used for the disciplined clock for NTP originally came from that service (Agilent/HP Z3801 and Z3816, for instance). > Boo. You can't find the 3816 much anymore and the 3801 isn't as good > (fine for most ntp purposes,though) (the difference is mostly in > internal measurement software and how long it will hold without the gps > signal). > And Symmetricom bought that line from HP, still sells one comparable to > the Z3801 but not like the 3816 for a decent price. Personally I'd > build one up out of an LPRO, a Trimble timing receiver (current > replacement for the Oncore used in the > Z38xx units, last I checked it was under $100), a MSP430 (probably a > fairly high-end one to get enough program space for a good PLL) and some > external logic for phase comparators (I don't know if the timer capture > modes in the 430 are good enough by themselves...) The most expensive > single part would be a decent timing antenna (yes, timing antennas *are* > different from the usual civilian positioning antennas; there is a > reason why the base is larger diameter than the rest...) > > Actually, does anyone still do soft handoff with UMTS? That was much of Yes. Providing accurate clock to a cell site is critical for 2/3/4g. This usually requires a primary (GPS) and backup (1588). Cb > the reason why old CDMA needed a GPS reference. > > -- Pete > > From jra at baylink.com Sun Jan 23 16:58:06 2011 From: jra at baylink.com (Jay Ashworth) Date: Sun, 23 Jan 2011 17:58:06 -0500 (EST) Subject: anyone running GPS clocks in Southeastern Georgia? In-Reply-To: <AANLkTim=Rks3MH+ySoYHYKaauZkhgV1-xJ05wXLxi=wE@mail.gmail.com> Message-ID: <18083369.1784.1295823486098.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Gary Buhrmaster" <gary.buhrmaster at gmail.com> > > Most of the "brand name" GPS NTP solutions have a clock > with is more than stable enough to survive without GPS > lock for 45 minutes(*). Some of the more expensive units with > temperature controlled oscillators have hold times in the > many weeks. My guess is that the NTP ripples will be > limited to those NTP servers just (or recently) booted > which have not yet achieved a stable clock state. Do such clocks reduce their advertised stratum when doing so? Or are they always considered "GPS-steered", and therefore there's no meaningful change short-term? -- jra From daydomes at gmail.com Sun Jan 23 18:09:50 2011 From: daydomes at gmail.com (Day Domes) Date: Sun, 23 Jan 2011 19:09:50 -0500 Subject: anyone running GPS clocks in Southeastern Georgia? In-Reply-To: <8662tiupsi.fsf@seastrom.com> References: <8662tiupsi.fsf@seastrom.com> Message-ID: <AANLkTim4KRjjxECyqqpPoFShzY=FOui2=+ELjfGZ6jGC@mail.gmail.com> Sex On Jan 21, 2011 12:32 PM, "Robert E. Seastrom" <rs at seastrom.com> wrote: > > It is unclear from this NOTAM whether this is an intentional > perturbation of the satellite signals vs. a terrestrial transmitter > (my money is on the latter), but it illustrates why one might want > geographically dispersed time sources on one's network, as well as why > the current trend towards decommissioning LORAN (and in the future, > other navaids) in favor of reliance on a single source is a Bad Plan. > > I'd be curious to see what effects (if any) those who use > GPS-disciplined NTP references in Southeastern Georgia see from this > experiment. > > https://www.faasafety.gov/files/notices/2011/Jan/GPS_Flight_Advisory_CSFTL11-01_Rel.pdf > > -r > > From laja at telenor.dk Mon Jan 24 06:48:57 2011 From: laja at telenor.dk (Lasse Jarlskov) Date: Mon, 24 Jan 2011 13:48:57 +0100 Subject: IPv6: numbering of point-to-point-links Message-ID: <FC64B3384195884588D252343702D23F01854588@ICABEXCCLU01B.int.sonofon.dk> Hi all. While reading up on IPv6, I've seen numerous places that subnets are now all /64. I have even read that subnets defined as /127 are considered harmful. However while implementing IPv6 in our network, I've encountered several of our peering partners using /127 or /126 for point-to-point links. What is the Best Current Practice for this - if there is any? Would you recommend me to use /64, /126 or /127? What are the pros and cons? -- Best regards, Lasse Jarlskov Systems architect - IP Telenor DK From cfriacas at fccn.pt Mon Jan 24 06:59:36 2011 From: cfriacas at fccn.pt (Carlos Friacas) Date: Mon, 24 Jan 2011 12:59:36 +0000 (WET) Subject: IPv6: numbering of point-to-point-links In-Reply-To: <FC64B3384195884588D252343702D23F01854588@ICABEXCCLU01B.int.sonofon.dk> References: <FC64B3384195884588D252343702D23F01854588@ICABEXCCLU01B.int.sonofon.dk> Message-ID: <alpine.LFD.2.00.1101241255330.7767@gauntlet.id.fccn.pt> Hi Lasse, We use /64s. ::1 for one end, ::2 for the second end. Using /126s or /127s (or even /120s) is a result of going with the v4 mindset of conservation. With a /32 you have 65536 /48s, and then 65536 /64s. Guess you only need 1 /48 for all the p-to-p links, no? Regards, Carlos (portuguese NREN, 6deploy.eu project partner) On Mon, 24 Jan 2011, Lasse Jarlskov wrote: > Hi all. > > > > While reading up on IPv6, I've seen numerous places that subnets are now > all /64. > > I have even read that subnets defined as /127 are considered harmful. > > > > However while implementing IPv6 in our network, I've encountered several > of our peering partners using /127 or /126 for point-to-point links. > > > > What is the Best Current Practice for this - if there is any? > > Would you recommend me to use /64, /126 or /127? > > What are the pros and cons? > > > > > > -- > > Best regards, > > Lasse Jarlskov > > Systems architect - IP > > Telenor DK > From carlosm3011 at gmail.com Mon Jan 24 06:59:59 2011 From: carlosm3011 at gmail.com (Carlos Martinez-Cagnazzo) Date: Mon, 24 Jan 2011 10:59:59 -0200 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN Message-ID: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com> The subject says it all... anyone with experience with a setup like this ? I am particularly wondering about possible NDP breakage. cheers! Carlos -- -- ========================= Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net ========================= From mch-nanog at xs4all.nl Mon Jan 24 07:10:48 2011 From: mch-nanog at xs4all.nl (Marco Hogewoning) Date: Mon, 24 Jan 2011 14:10:48 +0100 Subject: IPv6: numbering of point-to-point-links In-Reply-To: <FC64B3384195884588D252343702D23F01854588@ICABEXCCLU01B.int.sonofon.dk> References: <FC64B3384195884588D252343702D23F01854588@ICABEXCCLU01B.int.sonofon.dk> Message-ID: <4E78852B-1695-4DEE-8B4D-C095446F2AEB@xs4all.nl> > While reading up on IPv6, I've seen numerous places that subnets are now > all /64. > > I have even read that subnets defined as /127 are considered harmful. RFC3627, with a lot of discussion in the IETF on this. See also https://datatracker.ietf.org/doc/draft-ietf-6man-prefixlen-p2p/ > However while implementing IPv6 in our network, I've encountered several > of our peering partners using /127 or /126 for point-to-point links. I personally don't any benefit in using /126 subnets. > What is the Best Current Practice for this - if there is any? > > Would you recommend me to use /64, /126 or /127? > > What are the pros and cons? From an operational point of view there is a risk that be using /64 somebody can eat away a lot of memory by either scanning or even changing addresses. This is also described in the draft above... I would personally recommend to at least always assign the /64, even if you would decide to configure the /127. RFC 3627 has been around long enough that you will keep running into equipment or software that won't like the /127. In which case you can always revert back to /64. This will also allow you to use easy to remember addresses like ::1 and ::2, saving you the headache of a lot of binary counting. Grtx, Marco From chris at timico.net Mon Jan 24 07:11:02 2011 From: chris at timico.net (Chris Nicholls) Date: Mon, 24 Jan 2011 13:11:02 +0000 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <20110124130956.GA12875@atsuko> References: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com> <20110124130956.GA12875@atsuko> Message-ID: <20110124131102.GA16998@atsuko> On Monday, 24 January 2011 at K:59:59 -0200, Carlos Martinez-Cagnazzo wrote: > I am particularly wondering about possible NDP breakage. +1 We allocate /64 per PtP but only configure /127 for NDP and secrity concerns, I figure we can always change the mask if the space is set asside from the get go. ta -- Chris Nicholls Timico Network Operations chris at timico.net From Grzegorz at Janoszka.pl Mon Jan 24 07:11:25 2011 From: Grzegorz at Janoszka.pl (Grzegorz Janoszka) Date: Mon, 24 Jan 2011 14:11:25 +0100 Subject: IPv6: numbering of point-to-point-links In-Reply-To: <alpine.LFD.2.00.1101241255330.7767@gauntlet.id.fccn.pt> References: <FC64B3384195884588D252343702D23F01854588@ICABEXCCLU01B.int.sonofon.dk> <alpine.LFD.2.00.1101241255330.7767@gauntlet.id.fccn.pt> Message-ID: <4D3D7A7D.5050601@Janoszka.pl> On 24-01-11 13:59, Carlos Friacas wrote: > Using /126s or /127s (or even /120s) is a result of going with the v4 > mindset of conservation. Not only, there are some other advantages of using /126's, like reducing number of ND requests on the link and the size of neighbor tables. -- Grzegorz Janoszka From bmanning at vacation.karoshi.com Mon Jan 24 07:18:20 2011 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 24 Jan 2011 13:18:20 +0000 Subject: IPv6: numbering of point-to-point-links In-Reply-To: <4E78852B-1695-4DEE-8B4D-C095446F2AEB@xs4all.nl> References: <FC64B3384195884588D252343702D23F01854588@ICABEXCCLU01B.int.sonofon.dk> <4E78852B-1695-4DEE-8B4D-C095446F2AEB@xs4all.nl> Message-ID: <20110124131820.GA10465@vacation.karoshi.com.> On Mon, Jan 24, 2011 at 02:10:48PM +0100, Marco Hogewoning wrote: > > While reading up on IPv6, I've seen numerous places that subnets are now > > all /64. > > > > I have even read that subnets defined as /127 are considered harmful. > > RFC3627, with a lot of discussion in the IETF on this. See also https://datatracker.ietf.org/doc/draft-ietf-6man-prefixlen-p2p/ > > > However while implementing IPv6 in our network, I've encountered several > > of our peering partners using /127 or /126 for point-to-point links. > > I personally don't any benefit in using /126 subnets. > > > What is the Best Current Practice for this - if there is any? > > > > Would you recommend me to use /64, /126 or /127? > > > > What are the pros and cons? > > >From an operational point of view there is a risk that be using /64 somebody can eat away a lot of memory by either scanning or even changing addresses. This is also described in the draft above... > > I would personally recommend to at least always assign the /64, even if you would decide to configure the /127. RFC 3627 has been around long enough that you will keep running into equipment or software that won't like the /127. In which case you can always revert back to /64. > This will also allow you to use easy to remember addresses like ::1 and ::2, saving you the headache of a lot of binary counting. > > Grtx, > > Marco this results in -very- sparse matrix allocation - which is fine, as long as you believe that you'll never run out/make mistakes. personally, i've use /126 for the past 12 years w/o any problems. there was never supposed to be a hard split at /64 - it was done as a means to simplify autoconfig. --bill From bmanning at vacation.karoshi.com Mon Jan 24 07:28:25 2011 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 24 Jan 2011 13:28:25 +0000 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com> References: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com> Message-ID: <20110124132825.GB10465@vacation.karoshi.com.> as a test case, i built a small home network out of /120. works just fine. my home network has been native IPv6 for about 5 years now, using a /96 and IVI. some thoughts. disable RD/RA/ND. none of the DHCPv6 code works like DHCP, so I re-wrote client and server code so that it does. static address assignment is a good thing for services like DNS/HTTP secure dynmaic update is your friend summary - its not easy, vendors don't want to help. but it can be done. --bill On Mon, Jan 24, 2011 at 10:59:59AM -0200, Carlos Martinez-Cagnazzo wrote: > The subject says it all... anyone with experience with a setup like this ? > > I am particularly wondering about possible NDP breakage. > > cheers! > > Carlos > > -- > -- > ========================= > Carlos M. Martinez-Cagnazzo > http://www.labs.lacnic.net > ========================= From rbonica at juniper.net Mon Jan 24 07:29:26 2011 From: rbonica at juniper.net (Ronald Bonica) Date: Mon, 24 Jan 2011 08:29:26 -0500 Subject: IPv6: numbering of point-to-point-links In-Reply-To: <FC64B3384195884588D252343702D23F01854588@ICABEXCCLU01B.int.sonofon.dk> References: <FC64B3384195884588D252343702D23F01854588@ICABEXCCLU01B.int.sonofon.dk> Message-ID: <13205C286662DE4387D9AF3AC30EF456B16E96863C@EMBX01-WF.jnpr.net> Lasse, draft-ietf-6man-prefixlen-p2p-01 provides some insights. Ron > -----Original Message----- > From: Lasse Jarlskov [mailto:laja at telenor.dk] > Sent: Monday, January 24, 2011 7:49 AM > To: nanog at nanog.org > Subject: IPv6: numbering of point-to-point-links > > Hi all. > > > > While reading up on IPv6, I've seen numerous places that subnets are > now > all /64. > > I have even read that subnets defined as /127 are considered harmful. > > > > However while implementing IPv6 in our network, I've encountered > several > of our peering partners using /127 or /126 for point-to-point links. > > > > What is the Best Current Practice for this - if there is any? > > Would you recommend me to use /64, /126 or /127? > > What are the pros and cons? > > > > > > -- > > Best regards, > > Lasse Jarlskov > > Systems architect - IP > > Telenor DK From Skeeve at eintellego.net Mon Jan 24 07:43:08 2011 From: Skeeve at eintellego.net (Skeeve Stevens) Date: Tue, 25 Jan 2011 00:43:08 +1100 Subject: IPv6: numbering of point-to-point-links In-Reply-To: <FC64B3384195884588D252343702D23F01854588@ICABEXCCLU01B.int.sonofon.dk> Message-ID: <C963C7E0.2EF80%skeeve@eintellego.net> Lasse, We use /112's ? last chazwazza being 65k addresses? Requires little effort in remembering the ranges?. With one end being :1 and the other :F This leaves more than enough addresses for HSRP/VRRP and all the other things like it. Also means we can introduce addressing on the link for diagnostics quite easily. We actually use the /96 of 1C (to mean 1nterConnect) - makes it recognisable to engineering staff. There is the issue of the pingpong affect, but I'm hoping vendors (if they haven't already) will introduce features to protect against it when (if) they implement RFC4443. ...Skeeve -- Skeeve Stevens, CEO eintellego Pty Ltd - The Networking Specialists skeeve at eintellego.net<mailto:skeeve at eintellego.net> / www.eintellego.net Phone: 1300 753 383, Fax: (+612) 8572 9954 Cell +61 (0)414 753 383 / skype://skeeve www.linkedin.com/in/skeeve ; facebook.com/eintellego -- eintellego - The Experts that the Experts call - Juniper - HP Networking - Cisco - Brocade - Arista - Allied Telesis Disclaimer: Limits of Liability and Disclaimer: This message is for the named person's use only. It may contain sensitive and private proprietary or legally privileged information. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. eintellego Pty Ltd and each legal entity in the Tefilah Pty Ltd group of companies reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of any such entity. Any reference to costs, fee quotations, contractual transactions and variations to contract terms is subject to separate confirmation in writing signed by an authorised representative of eintellego. Whilst all efforts are made to safeguard inbound and outbound e-mails, we cannot guarantee that attachments are virus-free or compatible with your systems and do not accept any liability in respect of viruses or computer problems experienced. On 24/01/11 11:48 PM, "Lasse Jarlskov" <laja at telenor.dk<mailto:laja at telenor.dk>> wrote: Hi all. While reading up on IPv6, I've seen numerous places that subnets are now all /64. I have even read that subnets defined as /127 are considered harmful. However while implementing IPv6 in our network, I've encountered several of our peering partners using /127 or /126 for point-to-point links. What is the Best Current Practice for this - if there is any? Would you recommend me to use /64, /126 or /127? What are the pros and cons? -- Best regards, Lasse Jarlskov Systems architect - IP Telenor DK From jbates at brightok.net Mon Jan 24 07:44:39 2011 From: jbates at brightok.net (Jack Bates) Date: Mon, 24 Jan 2011 07:44:39 -0600 Subject: IPv6: numbering of point-to-point-links In-Reply-To: <20110124131820.GA10465@vacation.karoshi.com.> References: <FC64B3384195884588D252343702D23F01854588@ICABEXCCLU01B.int.sonofon.dk> <4E78852B-1695-4DEE-8B4D-C095446F2AEB@xs4all.nl> <20110124131820.GA10465@vacation.karoshi.com.> Message-ID: <4D3D8247.7060802@brightok.net> On 1/24/2011 7:18 AM, bmanning at vacation.karoshi.com wrote: > this results in -very- sparse matrix allocation - which is fine, as long as you believe that > you'll never run out/make mistakes. personally, i've use /126 for the past 12 years w/o any > problems. > There isn't an increased mistake risk factor using /126 out of a /64 assigned and your mistake factor probably slightly increases just assigning a bunch of /126 out of a single /64. We use /126 internal links, /128 loopbacks (these we do streamline), and customer links are generally /64, as currently we have no choice but use SLAAC + DHCPv6 (thanks Cisco!). That being said, while renumbering my network, I noted several link address mistakes. Had nothing to do with the /126 or /64 boundaries. I just left out one of the nibblet sets, and :: notation gladly makes that into a valid address. This leads me to believe that using short hand is likely to lead to more mistakes. Jack From regnauld at nsrc.org Mon Jan 24 08:26:12 2011 From: regnauld at nsrc.org (Phil Regnauld) Date: Mon, 24 Jan 2011 15:26:12 +0100 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <20110124132825.GB10465@vacation.karoshi.com.> References: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com> <20110124132825.GB10465@vacation.karoshi.com.> Message-ID: <20110124142607.GA54584@macbook.catpipe.net> bmanning at vacation.karoshi.com (bmanning) writes: > as a test case, i built a small home network out of /120. works just fine. > my home network has been native IPv6 for about 5 years now, using a /96 and IVI. > > some thoughts. disable RD/RA/ND. > none of the DHCPv6 code works like DHCP, so I re-wrote > client and server code so that it does. > static address assignment is a good thing for services like DNS/HTTP > secure dynmaic update is your friend > > summary - its not easy, vendors don't want to help. but it can be done. Right - /64 is an assumption that's hardcoded many places. But it does work. From mir at ripe.net Mon Jan 24 08:34:14 2011 From: mir at ripe.net (Mirjam Kuehne) Date: Mon, 24 Jan 2011 15:34:14 +0100 Subject: Future of the IPv6 CPE survey on RIPE Labs - Your Input Needed Message-ID: <4D3D8DE6.2070806@ripe.net> [apologies for duplicates] Hello, Based on new information we received since the last publication, we updated the IPv6 CPE matrix: http://labs.ripe.net/Members/mirjam/ipv6-cpe-survey-updated-january-2011 In order to make this information more useful for a large user base, we are preparing a detailed survey to gather more structural feedback about the range of equipment that is currently in use. Not only would we like you to participate in this survey, but we also ask for your help in identifying the right survey questions. Please find a call for input on RIPE Labs: http://labs.ripe.net/Members/marco/future-of-the-ipv6-cpe-survey-more-input-needed Kind Regards, Mirjam Kuehne & Marco Hogewoning RIPE NCC From carlos at lacnic.net Mon Jan 24 08:35:17 2011 From: carlos at lacnic.net (Carlos Martinez-Cagnazzo) Date: Mon, 24 Jan 2011 12:35:17 -0200 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <20110124142607.GA54584@macbook.catpipe.net> References: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com> <20110124132825.GB10465@vacation.karoshi.com.> <20110124142607.GA54584@macbook.catpipe.net> Message-ID: <AANLkTimOX1Fsw1ADy6xXMGumuKm930rPY3Hg7GCkC4jz@mail.gmail.com> Doing a little introspection, I found myself realizing that one of the most bothersome aspects of the /64 boundary (for me, just speaking for myself here) is exactly that, the tendency to the hardcoding of boundaries. C. On Mon, Jan 24, 2011 at 12:26 PM, Phil Regnauld <regnauld at nsrc.org> wrote: > bmanning at vacation.karoshi.com (bmanning) writes: >> ?as a test case, i built a small home network out of ?/120. works just fine. >> my home network has been native IPv6 for about 5 years now, using a /96 and IVI. >> >> some thoughts. ?disable RD/RA/ND. >> ? ? ? ? ? ? ? none of the DHCPv6 code works like DHCP, so I re-wrote >> ? ? ? ? ? ? ? ? ? ? ? client and server code so that it does. >> ? ? ? ? ? ? ? static address assignment is a good thing for services like DNS/HTTP >> ? ? ? ? ? ? ? secure dynmaic update is your friend >> >> summary - its not easy, vendors don't want to help. ?but it can be done. > > ? ? ? ?Right - /64 is an assumption that's hardcoded many places. > > ? ? ? ?But it does work. > > > From cjp at 0x1.net Mon Jan 24 12:25:46 2011 From: cjp at 0x1.net (Christopher Pilkington) Date: Mon, 24 Jan 2011 13:25:46 -0500 Subject: Verizon local CFA sanity check Message-ID: <AANLkTi=+JTMUvP7D4F+zeypTL48p3y3sbiwkMjJZjhAf@mail.gmail.com> I'm writing a LOA/CFA doc for some DS1s to be delivered to us on a Verizon private OC12 ring, and I'm getting conflicting info (including from multiple people within Verizon) on how to address individual DS1s. For STS/DS3s, it's pretty obvious, just the STS number, i.e. <SCID>/OC12/<STS>/<CLLI_there>/<CLLI_here> Anyone know for certain how Verizon numbers DS1 channels on an OC on a CFA doc? For clarity, this is Verizon local, Manhattan. Thanks, -cjp From matthew at corp.crocker.com Mon Jan 24 12:31:29 2011 From: matthew at corp.crocker.com (Matthew S. Crocker) Date: Mon, 24 Jan 2011 13:31:29 -0500 (EST) Subject: Verizon local CFA sanity check In-Reply-To: <AANLkTi=+JTMUvP7D4F+zeypTL48p3y3sbiwkMjJZjhAf@mail.gmail.com> Message-ID: <1278952912.73553.1295893889503.JavaMail.root@zimbra1.crocker.com> Wouldn't you map the DS1 to the M13 mux that is connected to the STS1 on the OC? I didn't think Verizon did DS1 level xconnects directly into SONET. ----- Original Message ----- > From: "Christopher Pilkington" <cjp at 0x1.net> > To: nanog at nanog.org > Sent: Monday, January 24, 2011 1:25:46 PM > Subject: Verizon local CFA sanity check > I'm writing a LOA/CFA doc for some DS1s to be delivered to us on a > Verizon private OC12 ring, and I'm getting conflicting info (including > from multiple people within Verizon) on how to address individual > DS1s. For STS/DS3s, it's pretty obvious, just the STS number, i.e. > > <SCID>/OC12/<STS>/<CLLI_there>/<CLLI_here> > > Anyone know for certain how Verizon numbers DS1 channels on an OC on a > CFA doc? > > For clarity, this is Verizon local, Manhattan. > > Thanks, > -cjp -- Matthew S. Crocker President Crocker Communications, Inc. PO BOX 710 Greenfield, MA 01302-0710 http://www.crocker.com P: 413-746-2760 From cjp at 0x1.net Mon Jan 24 12:51:48 2011 From: cjp at 0x1.net (Christopher Pilkington) Date: Mon, 24 Jan 2011 13:51:48 -0500 Subject: Verizon local CFA sanity check In-Reply-To: <1278952912.73553.1295893889503.JavaMail.root@zimbra1.crocker.com> References: <1278952912.73553.1295893889503.JavaMail.root@zimbra1.crocker.com> Message-ID: <728428512294094583@unknownmsgid> On Jan 24, 2011, at 13:37, "Matthew S. Crocker" <matthew at corp.crocker.com> wrote: > Wouldn't you map the DS1 to the M13 mux that is connected to the STS1 on the OC? I didn't think Verizon did DS1 level xconnects directly into SONET. It's a Flashwave 4100, I'm told it has an integrated DS1 mux. (It's not on the prem here so I have to go by others' word.) I know our other Verizon customer ring that is all Cisco 15454 can deliver DS1 without external M13. -cjp From bmanning at vacation.karoshi.com Mon Jan 24 13:04:35 2011 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 24 Jan 2011 19:04:35 +0000 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <735BCAC6-4C3F-4BE9-BA1D-E412B3C043ED@delong.com> References: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com> <20110124132825.GB10465@vacation.karoshi.com.> <735BCAC6-4C3F-4BE9-BA1D-E412B3C043ED@delong.com> Message-ID: <20110124190435.GB11522@vacation.karoshi.com.> well... you are correct - he did say shorter. me - i'd hollar for my good friends Fred and Radia (helped w/ the old vitalink mess) on the best way to manage an arp storm and/or cam table of a /64 of MAC addresses. :) It was hard enough to manage a "lan"/single broadcast domain that was global in scope and had 300,000 devices on it. "route when you can, bridge when you must" --bill On Mon, Jan 24, 2011 at 08:58:25AM -0800, Owen DeLong wrote: > Bill... Last I looked, /120 was longer than /64, not shorter. > > What I'm not understanding would be why anyone would want to use > something shorter than /64 on a LAN. > > Owen > > On Jan 24, 2011, at 5:28 AM, bmanning at vacation.karoshi.com wrote: > > > as a test case, i built a small home network out of /120. works just fine. > > my home network has been native IPv6 for about 5 years now, using a /96 and IVI. > > > > some thoughts. disable RD/RA/ND. > > none of the DHCPv6 code works like DHCP, so I re-wrote > > client and server code so that it does. > > static address assignment is a good thing for services like DNS/HTTP > > secure dynmaic update is your friend > > > > summary - its not easy, vendors don't want to help. but it can be done. > > > > --bill > > > > > > On Mon, Jan 24, 2011 at 10:59:59AM -0200, Carlos Martinez-Cagnazzo wrote: > >> The subject says it all... anyone with experience with a setup like this ? > >> > >> I am particularly wondering about possible NDP breakage. > >> > >> cheers! > >> > >> Carlos > >> > >> -- > >> -- > >> ========================= > >> Carlos M. Martinez-Cagnazzo > >> http://www.labs.lacnic.net > >> ========================= > From jcurran at arin.net Mon Jan 24 14:33:09 2011 From: jcurran at arin.net (John Curran) Date: Mon, 24 Jan 2011 20:33:09 +0000 Subject: Fwd: [arin-announce] ARIN Resource Certification Update References: <EE59203D-907A-4AA2-BAE6-AEE7AADAC0A2@arin.net> Message-ID: <0BC31466-09EA-4734-96B2-152453A62B90@arin.net> Copy to NANOG for those who aren't on ARIN lists but may be interested in this info. FYI. /John Begin forwarded message: From: John Curran <jcurran at arin.net<mailto:jcurran at arin.net>> Date: January 24, 2011 2:58:52 PM EST To: "arin-announce at arin.net<mailto:arin-announce at arin.net>" <arin-announce at arin.net<mailto:arin-announce at arin.net>> Subject: [arin-announce] ARIN Resource Certification Update ARIN continues its preparations for offering production-grade resource certification services for Internet number resources in the region. ARIN recognizes the importance of Internet number resource certification in the region as a key element of further securing Internet routing, and plans to rollout Resource Public Key Infrastructure (RPKI) at the end of the second quarter of 2011 with support for the Up/Down protocol for those ISPs who wish to certify their subdelegations via their own RPKI infrastructure. ARIN continues to evaluate offering a Hosting Resource Certification service for this purpose (as an alternative to organizations having to run their own RPKI infrastructure), but at this time it remains under active consideration and is not committed. We look forward to discussing the need for this type of service and the organization implications atour upcoming ARIN Members Meeting in April in San Juan, PR. FYI, /John John Curran President and CEO ARIN _______________________________________________ ARIN-Announce You are receiving this message because you are subscribed to the ARIN Announce Mailing List (ARIN-announce at arin.net<mailto: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 rps at maine.edu Mon Jan 24 14:53:32 2011 From: rps at maine.edu (Ray Soucy) Date: Mon, 24 Jan 2011 15:53:32 -0500 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com> References: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com> Message-ID: <AANLkTimcZavnJN2gqayS2-piDvOAcw_nrJAREJ0EDTjp@mail.gmail.com> Every time I see this question it' usually related to a fundamental misunderstanding of IPv6 and the attempt to apply v4 logic to v6. That said. Any size prefix will likely work and is even permitted by the RFC. You do run the risk of encountering applications that assume a 64-bit prefix length, though. And you're often crippling the advantages of IPv6. But in terms of the "best practice" it is indeed 64-bit for every network, with the option of 126-bit prefixes for link networks and 128-bit loopback addresses. You should think of IPv6 as a 64-bit address that happens to include a 64-bit host identifier. The entire point of IPv6 having a 128-bit address space was to facilitate this and put an end to having to determine the network prefix length based on an (often incorrect) estimation of the number of hosts the network will need to accommodate. Use of 126-bit prefixes for point-to-point connections (link networks) is acceptable. Use of 127-bit prefixes should be avoided as outlined in RFC 3627. So it really comes down to keeping it simple. Remember, we're dealing with exponentials here. A 64-bit address space isn't twice as large as a 32-bit address space; it's roughly 4.2 billion times larger. The 340 undecillion (that's 340 with 36 zeros after it) unique identifiers available with a 128-bit address space is blatantly excessive if you don't factor in that the host segment is always intended to be 64 of those bits. So if conservation of address space isn't the logic behind using a smaller prefix, then the question becomes what is? Most people tunnel-vision on the fact that Stateless Address Auto-Configuration requires that a 64-bit prefix be advertised to work and assume that the best way to disable it is to use a prefix-length other than 64. While you could do this, a far better way would be to simply not announce the prefix with the Autonomous bit set to true. Every IPv6 implementation respects the value of the "A" bit on a prefix advertisement and will not use Stateless configuration if it is not true, just as outlined in the RFC. Another thing to consider is that most processors today lack operations for values that are larger than 64-bit. By separating the host and network segment at the 64-bit boundary you may be able to take advantage of performance optimizations that make the distinction between the two (and significantly reduce the cost of routing decisions, contributing to lower latency). Many cite concerns of potential DoS attacks by doing sweeps of IPv6 networks. I don't think this will be a common or wide-spread problem. The general feeling is that there is simply too much address space for it to be done in any reasonable amount of time, and there is almost nothing to be gained from it. But yes. Basic NDP, routing, forwarding, etc. should work fine with anything shorter than 126. Just not really sure the logic behind doing so. On Mon, Jan 24, 2011 at 7:59 AM, Carlos Martinez-Cagnazzo <carlosm3011 at gmail.com> wrote: > The subject says it all... anyone with experience with a setup like this ? > > I am particularly wondering about possible NDP breakage. > > cheers! > > Carlos > > -- > -- > ========================= > Carlos M. Martinez-Cagnazzo > http://www.labs.lacnic.net > ========================= > > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From rps at maine.edu Mon Jan 24 15:20:33 2011 From: rps at maine.edu (Ray Soucy) Date: Mon, 24 Jan 2011 16:20:33 -0500 Subject: IPv6: numbering of point-to-point-links In-Reply-To: <FC64B3384195884588D252343702D23F01854588@ICABEXCCLU01B.int.sonofon.dk> References: <FC64B3384195884588D252343702D23F01854588@ICABEXCCLU01B.int.sonofon.dk> Message-ID: <AANLkTinxHFz83ykca7VpVo=XRJts7WGFP6G6+i2OB7R2@mail.gmail.com> The only advantage of a 126-bit prefix is if you're using it to take advantage of the short address, and keep all your point-to-point networks in the same address space so that you can easily identify them. This is really only personal preference for network engineers who may not want to be dependent on DNS and like to have key link addresses committed to memory (we're only human, after all). Example: Prefix: 2001:DB8::/32 2001:DB8::4/126 (or 2001:DB8::5 and 2001:DB8::6) 2001:DB8::8/126 2001:DB8::B/126 etc. Though, you could accomplish almost the same thing with using a 64-bit prefix length: 2001:DB8:1::/64 (or 2001:DB8:1::1 and 2001:DB8:1::2 2001:DB8:2::/64 2001:DB8:3::/64 That said. By not using the 64-bit boundary you may be sacrificing performance optimizations with today's processors that lack operations for values larger than 64-bits. Either way is acceptable and is simply a matter of personal preference. Link networks do not contain a dynamic number of hosts, so logically there is no reason to accommodate more addresses than they originally call for. RFC 3627 recommends against using a 127-bit prefix-length due to potential (implementation specific) problems with DAD, and that is enough reason to avoid it for most people. Nobody is right. Nobody is wrong. It's just preference. We have a lot of link networks and opted early on to make use of 126-bit prefixes for them because that worked nicely for our allocation schema. On Mon, Jan 24, 2011 at 7:48 AM, Lasse Jarlskov <laja at telenor.dk> wrote: > Hi all. > > > > While reading up on IPv6, I've seen numerous places that subnets are now > all /64. > > I have even read that subnets defined as /127 are considered harmful. > > > > However while implementing IPv6 in our network, I've encountered several > of our peering partners using /127 or /126 for point-to-point links. > > > > What is the Best Current Practice for this - if there is any? > > Would you recommend me to use /64, /126 or /127? > > What are the pros and cons? > > > > > > -- > > Best regards, > > Lasse Jarlskov > > Systems architect - IP > > Telenor DK > > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From Skeeve at eintellego.net Mon Jan 24 15:44:57 2011 From: Skeeve at eintellego.net (Skeeve Stevens) Date: Tue, 25 Jan 2011 08:44:57 +1100 Subject: IPv6: numbering of point-to-point-links In-Reply-To: <C963C7E0.2EF80%skeeve@eintellego.net> Message-ID: <C9643DA9.2F05A%skeeve@eintellego.net> Doh, I meant the /80 of 1C for interconnects. xxxx:xxxx:zz::1C:YYYY:1 and :F in a /112 ...Skeeve -- Skeeve Stevens, CEO eintellego Pty Ltd - The Networking Specialists skeeve at eintellego.net<mailto:skeeve at eintellego.net> / www.eintellego.net Phone: 1300 753 383, Fax: (+612) 8572 9954 Cell +61 (0)414 753 383 / skype://skeeve www.linkedin.com/in/skeeve ; facebook.com/eintellego -- eintellego - The Experts that the Experts call - Juniper - HP Networking - Cisco - Brocade - Arista - Allied Telesis Disclaimer: Limits of Liability and Disclaimer: This message is for the named person's use only. It may contain sensitive and private proprietary or legally privileged information. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. eintellego Pty Ltd and each legal entity in the Tefilah Pty Ltd group of companies reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of any such entity. Any reference to costs, fee quotations, contractual transactions and variations to contract terms is subject to separate confirmation in writing signed by an authorised representative of eintellego. Whilst all efforts are made to safeguard inbound and outbound e-mails, we cannot guarantee that attachments are virus-free or compatible with your systems and do not accept any liability in respect of viruses or computer problems experienced. On 25/01/11 12:43 AM, "Skeeve Stevens" <Skeeve at eintellego.net<mailto:Skeeve at eintellego.net>> wrote: Lasse, We use /112's ? last chazwazza being 65k addresses? Requires little effort in remembering the ranges?. With one end being :1 and the other :F This leaves more than enough addresses for HSRP/VRRP and all the other things like it. Also means we can introduce addressing on the link for diagnostics quite easily. We actually use the /96 of 1C (to mean 1nterConnect) - makes it recognisable to engineering staff. There is the issue of the pingpong affect, but I'm hoping vendors (if they haven't already) will introduce features to protect against it when (if) they implement RFC4443. ...Skeeve -- Skeeve Stevens, CEO eintellego Pty Ltd - The Networking Specialists skeeve at eintellego.net<mailto:skeeve at eintellego.net><mailto:skeeve at eintellego.net> / www.eintellego.net Phone: 1300 753 383, Fax: (+612) 8572 9954 Cell +61 (0)414 753 383 / skype://skeeve www.linkedin.com/in/skeeve ; facebook.com/eintellego -- eintellego - The Experts that the Experts call - Juniper - HP Networking - Cisco - Brocade - Arista - Allied Telesis Disclaimer: Limits of Liability and Disclaimer: This message is for the named person's use only. It may contain sensitive and private proprietary or legally privileged information. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. eintellego Pty Ltd and each legal entity in the Tefilah Pty Ltd group of companies reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of any such entity. Any reference to costs, fee quotations, contractual transactions and variations to contract terms is subject to separate confirmation in writing signed by an authorised representative of eintellego. Whilst all efforts are made to safeguard inbound and outbound e-mails, we cannot guarantee that attachments are virus-free or compatible with your systems and do not accept any liability in respect of viruses or computer problems experienced. On 24/01/11 11:48 PM, "Lasse Jarlskov" <laja at telenor.dk<mailto:laja at telenor.dk><mailto:laja at telenor.dk>> wrote: Hi all. While reading up on IPv6, I've seen numerous places that subnets are now all /64. I have even read that subnets defined as /127 are considered harmful. However while implementing IPv6 in our network, I've encountered several of our peering partners using /127 or /126 for point-to-point links. What is the Best Current Practice for this - if there is any? Would you recommend me to use /64, /126 or /127? What are the pros and cons? -- Best regards, Lasse Jarlskov Systems architect - IP Telenor DK From lists at nexus6.co.za Mon Jan 24 16:04:25 2011 From: lists at nexus6.co.za (Andy Ashley) Date: Mon, 24 Jan 2011 22:04:25 +0000 Subject: DSL options in NYC for OOB access Message-ID: <4D3DF769.7060601@nexus6.co.za> Hi, Im looking for a little advice about DSL circuits in New York, specifically at 111 8th Ave. Going to locate a console server there for out-of-band serial management. The router will need connectivity for remote telnet/ssh access from the NOC. Looking for a low speed (and low cost) DSL line with a fixed IP. I searched some obvious providers but dont really want to deal with a huge company (Verizon, Qwest, ?) if it can be avoided. Also $80-100+ seems a lot for something that will be used very rarely, but maybe those prices are normal. Are there smaller/independent companies out there offering this sort of thing? I dont know much about the US DSL market, so any hints are welcome. Thanks. Andy. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From mloftis at wgops.com Mon Jan 24 16:41:27 2011 From: mloftis at wgops.com (Michael Loftis) Date: Mon, 24 Jan 2011 15:41:27 -0700 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <AANLkTimcZavnJN2gqayS2-piDvOAcw_nrJAREJ0EDTjp@mail.gmail.com> References: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com> <AANLkTimcZavnJN2gqayS2-piDvOAcw_nrJAREJ0EDTjp@mail.gmail.com> Message-ID: <AANLkTikHBb+cyfPxXftb5QZh136D04fkdWFMy3NFhDdi@mail.gmail.com> On Mon, Jan 24, 2011 at 1:53 PM, Ray Soucy <rps at maine.edu> wrote: > Many cite concerns of potential DoS attacks by doing sweeps of IPv6 > networks. ?I don't think this will be a common or wide-spread problem. > ?The general feeling is that there is simply too much address space > for it to be done in any reasonable amount of time, and there is > almost nothing to be gained from it. The problem I see is the opening of a new, simple, DoS/DDoS scenario. By repetitively sweeping a targets /64 you can cause EVERYTHING in that /64 to stop working by overflowing the ND/ND cache, depending on the specific ND cache implementation and how big it is/etc. Routers can also act as amplifiers too, DDoSing every host within a multicast ND directed solicitation group (and THAT is even assuming a correctly functioning switch thats limiting the multicast travel) Add to it the assumption that every router gets certain things right (like everything correctly decrementing TTLs as assumed in RFC 4861 11.2 in order for hosts to detect off-link RA/ND messages and guard themselves against those), in these ways it's certainly at least somewhat worse than ARP. If you're able to bring down, or severely limit, a site by sending a couple thousand PPS towards the /64 it's on, or by varying the upper parts of the /64 to flood all the hosts with multicast traffic while simultaneously floodign the routers LRU ND cache well thats a cheap and easy attack and it WILL be used, and that can be done with the protocols working as designed, at least from my reading. Granted I don't have an IPv6 lab to test any of this. But I'd be willing to bet this exact scenario is readily and easily possible, it already is with ARP tables (and it DOES happen, it's just harder to make happen with ARP and IPv4 since the space is so small, esp when compared to a /64) IPv6 ND LRU Caches/tables aren't going to be anywhere near big enough to handle a single /64's worth of hosts. And if they're any significant amt smaller then it'd be trivial to cause a DoS by sweeping the address space. It would depend on the ND table limits/sizes, and any implementation specific timers/etc and garbage collection, and a some other details I don't have, but, I bet it'd be a really small flow in the scheme of things to completely stomp out a /64....someone I'm sure knows more about the implementations, and I'm betting this has been brought up before about IPv6/ND... So I pretty strongly disagree about your statement. Repetitively sweeping an IPv6 network to DoS/DDoS the ND protocol thereby flooding the ND cache/LRUs could be extremely effective and if not payed serious attention will cause serious issues. From asr+nanog at latency.net Mon Jan 24 16:54:22 2011 From: asr+nanog at latency.net (Adam Rothschild) Date: Mon, 24 Jan 2011 17:54:22 -0500 Subject: DSL options in NYC for OOB access In-Reply-To: <4D3DF769.7060601@nexus6.co.za> References: <4D3DF769.7060601@nexus6.co.za> Message-ID: <20110124225422.GA86715@latency.net> On 2011-01-24-17:04:25, Andy Ashley <lists at nexus6.co.za> wrote: > Im looking for a little advice about DSL circuits in New York, > specifically at 111 8th Ave [...] You can get a CLEAR WiMAX fixed modem with static IP address for $50 (USD) monthly, or less if you opt for the low-bandwidth plan. Unscientific testing shows there's good coverage throughout most of the building, and no obvious shared risks from an IP or transport prospective. As an added bonus, you won't have any cross-connect opex to worry about. :-) HTH, -a From freed0 at shadowserver.org Mon Jan 24 16:55:48 2011 From: freed0 at shadowserver.org (freed0) Date: Mon, 24 Jan 2011 14:55:48 -0800 Subject: The Conficker Working Group Lessons Learned Document Message-ID: <4D3E0374.4080009@shadowserver.org> http://www.confickerworkinggroup.org/wiki/pmwiki.php/ANY/LessonsLearned http://www.confickerworkinggroup.org/wiki/uploads/Conficker_Working_Group_Lessons_Learned_17_June_2010_final.pdf The Conficker Working Group Lessons Learned Document Starting in late 2008, and continuing through June of 2010, a coalition of security researchers worked to resist an Internet borne attack carried out by malicious software known as Conficker. This coalition became known as ?The Conficker Working Group?, and seemed to be successful in a number of ways, not the least of which was unprecedented cooperation between organizations and individuals around the world, in both the public and private sectors. In 2009, The Department of Homeland Security funded a project to develop and produce a ?Lessons Learned? document that could serve as a permanent record of the events surrounding the creation and operation of the working group so that it could be used as an exemplar upon which similar groups in the future could build. This is the document. The Rendon Group conducted the research independently, and although a number of members of the Conficker Working Group were interviewed, and provided information to the authors, the report is the sole work product of the Rendon Group. The views and conclusions are not necessarily those of the Conficker Working Group, or any of its official or unofficial members. Nonetheless the Core Committee of the Conficker Working Group believes the report has substantial value and is pleased to provide access to the Rendon document via the Conficker Working Group Website. Rodney Joffe Chair Conficker Working Group Follow up questions can be directed to the Rendon Group at the address below, as well as the following members of the Conficker Working Group Core Committee: * The Rendon Group * Phone: +1 202-745-4900 * trginfo at rendon.com Conficker Working Group Core Committee: The ShadowServer Foundation * Andre' M. DiMino * Co-Founder and Director * Phone: +1 914-410-6480 * Email: adimino at shadowserver.org Neustar, Inc * Rodney Joffe * Senior Vice President * Phone: +1 202-533-2900 * Email: rodney.joffe at neustar.biz Verisign, Inc. * Ramses Martinez * Director of Information Security * Phone: +1 571-723-1874 * Email: ramartinez at verisign.com Arbor Networks * Kevin Whalen * kwhalen at arbor.net * Phone: +1 978-852-8432 Internet Software Consortium * Barry Greene * President * Phone: +1 650-423-1311 * Email: bgreene at isc.org From charles at knownelement.com Mon Jan 24 16:59:11 2011 From: charles at knownelement.com (Charles N Wyble) Date: Mon, 24 Jan 2011 14:59:11 -0800 Subject: DSL options in NYC for OOB access In-Reply-To: <20110124225422.GA86715@latency.net> References: <4D3DF769.7060601@nexus6.co.za> <20110124225422.GA86715@latency.net> Message-ID: <4D3E043F.3010008@knownelement.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/24/2011 02:54 PM, Adam Rothschild wrote: > On 2011-01-24-17:04:25, Andy Ashley <lists at nexus6.co.za> wrote: >> Im looking for a little advice about DSL circuits in New York, >> specifically at 111 8th Ave [...] > > You can get a CLEAR WiMAX fixed modem with static IP address for $50 > (USD) monthly, or less if you opt for the low-bandwidth plan. +1 for the clear stuff. I've spent the last couple of weeks doing extensive 3g/4g testing, and been incredibly impressed with Clear. (I'm doing video conferencing over it). - -- Charles N Wyble (charles at knownelement.com) Systems craftsman for the stars http://www.knownelement.com Mobile: 626 539 4344 Office: 310 929 8793 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNPgQ+AAoJEMvvG/TyLEAtDfwP/0x34BJg6W9QxK+bKGdKuE5w cYCM+X7FEhm7JNGVIv66kAIWCW7eA4kJNv6u2lZgfmsdsCKGBM+j+34I2lPv7bLP LWKaVd6lbssy9g9QcRxtg7Mg7kq8r2oq6WVjExcUw/DGZSEUt4KppUlOXEloPyKl vc3k2Y8TTctboOvTWhfhsIW5qAuq7W6/5HyX+SFMD6SB+gK3SfFzs+0BOErttcfy xv+PmMpoBk1VNsz2kn4ggLGBOd7X1yUXVukNvTDFmZJz2RbPh17eH/rnokYgH1jE TL4mouSmoGXiVhgX/33DoJ+GbRTGNwxhklN+5PGR4jideG8YsL0s/Hz4+YAVv82s JKF6hmLF+nTAe4Zz+pfBLbmFJx7fHh4xnZtejXIAX0R9g+M8o0OAV2KUOMjIOAjX eERYaqWrYHNkc+GbvV2LkBRS5XL3ETkmpSwXO58/cJgnMMTEQ3b0lNTn/JCloQ/x j5WV9B7LhUAxO61VWJANuCuq8SNwf59yHpuHTAx2WvG7A+f3EXuUSpGakIH8l+It tsLaSvL7of0Bkiq2smDstFR8irqNhxOXHsY2yiBkUwC9+HaC3YAnTMaEjGBTeuk8 Q5V/CoU1SQTCKjEJlxAqKtAWzqVTZZCPX9Y3RDBp3fdNiWq6OIIFZNMn2OTrHbrO 2VohYIThNjC7saRiwVLe =Ih+5 -----END PGP SIGNATURE----- From nathan at atlasnetworks.us Mon Jan 24 17:22:51 2011 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Mon, 24 Jan 2011 23:22:51 +0000 Subject: DSL options in NYC for OOB access In-Reply-To: <20110124225422.GA86715@latency.net> References: <4D3DF769.7060601@nexus6.co.za> <20110124225422.GA86715@latency.net> Message-ID: <8C26A4FDAE599041A13EB499117D3C286B334371@ex-mb-1.corp.atlasnetworks.us> > You can get a CLEAR WiMAX fixed modem with static IP address for $50 > (USD) monthly, or less if you opt for the low-bandwidth plan. I wouldn't dare rely on something of that nature for a lifeline connection. I'd spring for the extra $30/mo. It's expensive, but there ain't nothin' like a physical cable when it's 3AM on a Sunday. Nathan From dotis at mail-abuse.org Mon Jan 24 17:42:28 2011 From: dotis at mail-abuse.org (Douglas Otis) Date: Mon, 24 Jan 2011 15:42:28 -0800 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <20110124190435.GB11522@vacation.karoshi.com.> References: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com> <20110124132825.GB10465@vacation.karoshi.com.> <735BCAC6-4C3F-4BE9-BA1D-E412B3C043ED@delong.com> <20110124190435.GB11522@vacation.karoshi.com.> Message-ID: <4D3E0E64.4000001@mail-abuse.org> On 1/24/11 11:04 AM, bmanning at vacation.karoshi.com wrote: > well... you are correct - he did say shorter. me - i'd hollar for my good > friends Fred and Radia (helped w/ the old vitalink mess) on the best way to > manage an arp storm and/or cam table of a /64 of MAC addresses. :) It was > hard enough to manage a "lan"/single broadcast domain that was global in scope > and had 300,000 devices on it. > > "route when you can, bridge when you must" Bill, It seems efforts related to IP address specific policies are likely doomed by the sheer size of the address space, and to be pedantic, ARP has been replaced with multicast neighbor discovery which dramatically reduces the overall traffic involved. Secondly, doesn't Secure Neighbor Discovery implemented at layer 2 fully mitigate these issues? I too would be interested in hearing from Radia and Fred. -Doug From zaid at zaidali.com Mon Jan 24 17:55:38 2011 From: zaid at zaidali.com (Zaid Ali) Date: Mon, 24 Jan 2011 15:55:38 -0800 Subject: bestpath as-path multipath-relax Message-ID: <7E83A158-9141-4FA9-A811-B5164E19B9D5@zaidali.com> I am looking for some operational feedback of this undocumented feature, bgp bestpath as-path multipath-relax, for IOS. If you are using this for outbound load balancing I would like to hear your experiences. Also if you are running it across edges. Thanks, Zaid From jabley at hopcount.ca Mon Jan 24 18:10:33 2011 From: jabley at hopcount.ca (Joe Abley) Date: Mon, 24 Jan 2011 19:10:33 -0500 Subject: DSL options in NYC for OOB access In-Reply-To: <8C26A4FDAE599041A13EB499117D3C286B334371@ex-mb-1.corp.atlasnetworks.us> References: <4D3DF769.7060601@nexus6.co.za> <20110124225422.GA86715@latency.net> <8C26A4FDAE599041A13EB499117D3C286B334371@ex-mb-1.corp.atlasnetworks.us> Message-ID: <CA10625F-7D04-4C82-B121-41EABB53D0CF@hopcount.ca> On 2011-01-24, at 18:22, Nathan Eisenberg wrote: >> You can get a CLEAR WiMAX fixed modem with static IP address for $50 >> (USD) monthly, or less if you opt for the low-bandwidth plan. > > I wouldn't dare rely on something of that nature for a lifeline connection. I'd spring for the extra $30/mo. It's expensive, but there ain't nothin' like a physical cable when it's 3AM on a Sunday. At least with a wireless management network you don't have to worry about cable path diversity out of the rack/cage/suite though. Joe From jfbeam at gmail.com Mon Jan 24 18:10:42 2011 From: jfbeam at gmail.com (Ricky Beam) Date: Mon, 24 Jan 2011 19:10:42 -0500 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <AANLkTimcZavnJN2gqayS2-piDvOAcw_nrJAREJ0EDTjp@mail.gmail.com> References: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com> <AANLkTimcZavnJN2gqayS2-piDvOAcw_nrJAREJ0EDTjp@mail.gmail.com> Message-ID: <op.vpt734cxtfhldh@rbeam.xactional.com> On Mon, 24 Jan 2011 15:53:32 -0500, Ray Soucy <rps at maine.edu> wrote: > Every time I see this question it' usually related to a fundamental > misunderstanding of IPv6 and the attempt to apply v4 logic to v6. Not exactly. If it's a point-to-point link, then there are *TWO* machines on it -- one at each end; there will *always* be two machines on it. There's no sane reason to assign 18trillion addresses to it. Yes, in this respect it's like not wasting an IPv4 /24, but it's also The Right Tool For The Job.(tm) If one were to assign a /64 to every p-t-p link in the world, IPv6 address space would be used at an insane rate. (and those assignments aren't free.) Do people not remember the early days of IPv4 where /8's were handed out like Pez? > That said. Any size prefix will likely work and is even permitted by > the RFC. You do run the risk of encountering applications that assume > a 64-bit prefix length, though. And you're often crippling the > advantages of IPv6. And such applications are *BROKEN*. IPv6 is *classless* -- end of discussion. /64 (and /80 previous) is a lame optimization so really stupid devices can find an address in 4 bytes of machine code. This is quite lame given all the other complex baggage IPv6 requires. And then /64 is only required by SLAAC, which you are not required to use. > You should think of IPv6 as a 64-bit address that happens to include a > 64-bit host identifier. No, you should not. That underminds the fundamental concept of IPv6 being *classless*. And it will lead to idiots writing broken applications and protocols assuming that to be true. > Another thing to consider is that most processors today lack > operations for values that are larger than 64-bit. By separating the > host and network segment at the 64-bit boundary you may be able to > take advantage of performance optimizations that make the distinction > between the two (and significantly reduce the cost of routing > decisions, contributing to lower latency). IPv6 is classless; routers cannot blindly make that assumption for "performance optimization". > Many cite concerns of potential DoS attacks by doing sweeps of IPv6 > networks. I don't think this will be a common or wide-spread problem. Myopia doesn't make the problem go away. The point of such an attack is not to "find things", but to overload the router(s). (which can be done rather easily by a few dozen machines.) --Ricky From sethm at rollernet.us Mon Jan 24 18:14:32 2011 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 24 Jan 2011 16:14:32 -0800 Subject: DSL options in NYC for OOB access In-Reply-To: <8C26A4FDAE599041A13EB499117D3C286B334371@ex-mb-1.corp.atlasnetworks.us> References: <4D3DF769.7060601@nexus6.co.za> <20110124225422.GA86715@latency.net> <8C26A4FDAE599041A13EB499117D3C286B334371@ex-mb-1.corp.atlasnetworks.us> Message-ID: <4D3E15E8.9020404@rollernet.us> On 1/24/2011 15:22, Nathan Eisenberg wrote: >> You can get a CLEAR WiMAX fixed modem with static IP address for $50 >> (USD) monthly, or less if you opt for the low-bandwidth plan. > > I wouldn't dare rely on something of that nature for a lifeline connection. I'd spring for the extra $30/mo. It's expensive, but there ain't nothin' like a physical cable when it's 3AM on a Sunday. > For me it depends; if the OOB is related to some other physical cable that the OOB is for, wireless might have a better chance of still working if there's a cable cut. ~Seth From randy at psg.com Mon Jan 24 18:16:14 2011 From: randy at psg.com (Randy Bush) Date: Tue, 25 Jan 2011 09:16:14 +0900 Subject: Fwd: [arin-announce] ARIN Resource Certification Update In-Reply-To: <0BC31466-09EA-4734-96B2-152453A62B90@arin.net> References: <EE59203D-907A-4AA2-BAE6-AEE7AADAC0A2@arin.net> <0BC31466-09EA-4734-96B2-152453A62B90@arin.net> Message-ID: <m27hdtrg6p.wl%randy@psg.com> thanks john. your consideration to the ops community is appreciated. > ARIN continues its preparations for offering production-grade resource > certification services for Internet number resources in the region. > ARIN recognizes the importance of Internet number resource > certification in the region as a key element of further securing > Internet routing, and plans to rollout Resource Public Key > Infrastructure (RPKI) at the end of the second quarter of 2011 with > support for the Up/Down protocol for those ISPs who wish to certify > their subdelegations via their own RPKI infrastructure. way cool. and there are open source tool-sets the isps can run to handle their resources, generate roas, ... > ARIN continues to evaluate offering a Hosting Resource Certification > service for this purpose (as an alternative to organizations having to > run their own RPKI infrastructure), but at this time it remains under > active consideration and is not committed. We look forward to > discussing the need for this type of service and the organization > implications atour upcoming ARIN Members Meeting in April in San Juan, > PR. i understand fearing holding others' private keys and critical data. no blame there. <separate subject> but out of curiousity, how reality based are arin's general liability fears? in the last few years, how many times has arin been a named defendant in a law suit? how many times a [principal] plaintiff? randy From Crist.Clark at globalstar.com Mon Jan 24 18:22:58 2011 From: Crist.Clark at globalstar.com (Crist Clark) Date: Mon, 24 Jan 2011 16:22:58 -0800 Subject: IPv6: numbering of point-to-point-links In-Reply-To: <20110124131820.GA10465@vacation.karoshi.com.> References: <FC64B3384195884588D252343702D23F01854588@ICABEXCCLU01B.int.sonofon.dk> <4E78852B-1695-4DEE-8B4D-C095446F2AEB@xs4all.nl> <20110124131820.GA10465@vacation.karoshi.com.> Message-ID: <4D3DA762.33E4.0097.1@globalstar.com> >>> On 1/24/2011 at 5:18 AM, <bmanning at vacation.karoshi.com> wrote: > On Mon, Jan 24, 2011 at 02:10:48PM +0100, Marco Hogewoning wrote: >> > While reading up on IPv6, I've seen numerous places that subnets are now >> > all /64. >> > >> > I have even read that subnets defined as /127 are considered harmful. >> >> RFC3627, with a lot of discussion in the IETF on this. See also > https://datatracker.ietf.org/doc/draft-ietf-6man-prefixlen-p2p/ >> >> > However while implementing IPv6 in our network, I've encountered several >> > of our peering partners using /127 or /126 for point-to-point links. >> >> I personally don't any benefit in using /126 subnets. >> >> > What is the Best Current Practice for this - if there is any? >> > >> > Would you recommend me to use /64, /126 or /127? >> > >> > What are the pros and cons? >> >> >From an operational point of view there is a risk that be using /64 somebody > can eat away a lot of memory by either scanning or even changing addresses. > This is also described in the draft above... >> >> I would personally recommend to at least always assign the /64, even if you > would decide to configure the /127. RFC 3627 has been around long enough that > you will keep running into equipment or software that won't like the /127. In > which case you can always revert back to /64. >> This will also allow you to use easy to remember addresses like ::1 and ::2, > saving you the headache of a lot of binary counting. >> >> Grtx, >> >> Marco > > this results in -very- sparse matrix allocation - which is fine, as long as you > believe that > you'll never run out/make mistakes. personally, i've use /126 for the past > 12 years w/o any > problems. > > there was never supposed to be a hard split at /64 - it was done as a means > to simplify autoconfig. All of the (mostly religious) arguments about /64 versus any smaller subnets aside, I'm curious about why one would choose /126 over /127 for P-to-P links? Is this some kind of IPv4-think where the all-zeros and all-ones addresses are not usable unicast addresses? This isn't true in IPv6 (of course, it's not strictly true in IPv4 either). Is there another reason? -- Crist Clark Network Security Specialist, Information Systems Globalstar 408 933 4387 From marka at isc.org Mon Jan 24 18:36:01 2011 From: marka at isc.org (Mark Andrews) Date: Tue, 25 Jan 2011 11:36:01 +1100 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: Your message of "Mon, 24 Jan 2011 19:10:42 CDT." <op.vpt734cxtfhldh@rbeam.xactional.com> References: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com> <AANLkTimcZavnJN2gqayS2-piDvOAcw_nrJAREJ0EDTjp@mail.gmail.com><op.vpt734cxtfhldh@rbeam.xactional.com> Message-ID: <20110125003601.249BA921CAA@drugs.dv.isc.org> In message <op.vpt734cxtfhldh at rbeam.xactional.com>, "Ricky Beam" writes: > On Mon, 24 Jan 2011 15:53:32 -0500, Ray Soucy <rps at maine.edu> wrote: > > Every time I see this question it' usually related to a fundamental > > misunderstanding of IPv6 and the attempt to apply v4 logic to v6. > > Not exactly. If it's a point-to-point link, then there are *TWO* machines > on it -- one at each end; there will *always* be two machines on it. > There's no sane reason to assign 18trillion addresses to it. Yes, in this > respect it's like not wasting an IPv4 /24, but it's also The Right Tool > For The Job.(tm) If one were to assign a /64 to every p-t-p link in the > world, IPv6 address space would be used at an insane rate. (and those > assignments aren't free.) Do people not remember the early days of IPv4 > where /8's were handed out like Pez? > > > That said. Any size prefix will likely work and is even permitted by > > the RFC. You do run the risk of encountering applications that assume > > a 64-bit prefix length, though. And you're often crippling the > > advantages of IPv6. > > And such applications are *BROKEN*. IPv6 is *classless* -- end of > discussion. > > /64 (and /80 previous) is a lame optimization so really stupid devices can > find an address in 4 bytes of machine code. This is quite lame given all > the other complex baggage IPv6 requires. > > And then /64 is only required by SLAAC, which you are not required to use. > > > > You should think of IPv6 as a 64-bit address that happens to include a > > 64-bit host identifier. > > No, you should not. That underminds the fundamental concept of IPv6 being > *classless*. And it will lead to idiots writing broken applications and > protocols assuming that to be true. > > > Another thing to consider is that most processors today lack > > operations for values that are larger than 64-bit. By separating the > > host and network segment at the 64-bit boundary you may be able to > > take advantage of performance optimizations that make the distinction > > between the two (and significantly reduce the cost of routing > > decisions, contributing to lower latency). > > IPv6 is classless; routers cannot blindly make that assumption for > "performance optimization". > > > Many cite concerns of potential DoS attacks by doing sweeps of IPv6 > > networks. I don't think this will be a common or wide-spread problem. > > Myopia doesn't make the problem go away. The point of such an attack is > not to "find things", but to overload the router(s). (which can be done > rather easily by a few dozen machines.) > > --Ricky There will be two machines but not necessarially 2 addresses. For inter router links there will usually only be the two adresses. For port to point links to general purpose machines you should expect multiple address at least one end. Even routers can use CGAs. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From owen at delong.com Mon Jan 24 18:46:19 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 24 Jan 2011 16:46:19 -0800 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <op.vpt734cxtfhldh@rbeam.xactional.com> References: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com> <AANLkTimcZavnJN2gqayS2-piDvOAcw_nrJAREJ0EDTjp@mail.gmail.com> <op.vpt734cxtfhldh@rbeam.xactional.com> Message-ID: <8B0D83FB-38DD-4C4D-9870-5913425BA3A2@delong.com> On Jan 24, 2011, at 4:10 PM, Ricky Beam wrote: > On Mon, 24 Jan 2011 15:53:32 -0500, Ray Soucy <rps at maine.edu> wrote: >> Every time I see this question it' usually related to a fundamental >> misunderstanding of IPv6 and the attempt to apply v4 logic to v6. > > Not exactly. If it's a point-to-point link, then there are *TWO* machines on it -- one at each end; there will *always* be two machines on it. There's no sane reason to assign 18trillion addresses to it. Yes, in this respect it's like not wasting an IPv4 /24, but it's also The Right Tool For The Job.(tm) If one were to assign a /64 to every p-t-p link in the world, IPv6 address space would be used at an insane rate. (and those assignments aren't free.) Do people not remember the early days of IPv4 where /8's were handed out like Pez? > Dude... In IPv6, there are 18,446,744,073,709,551,616 /64s. To put this in perspective... There are roughly 30,000 ISPs on Earth. The largest ISPs have thousands (not tens of thousands) of point-to-point links. Even if we assume 30,000 Point to point links per ISP and 60,000 ISPs, you still only used 1,800,000,000 /64s. The remaining 18,446,744,071,909,551,616 are still available for other uses. I think a use that does not effect the first 11 significant digits of the total address space is hard to call "used at an insane rate". Yes, I remember the early days. Now, let's compare the population of the internet in those days (60+ organizations vs 256 /8s) to the current ratio we're talking about (let's be generous and say there are two end sites for every person on the planet... 12,000,000,000 vs. 281,474,976,710,656/48s). In the former case, we're talking about a known population representing 23% of all available address space. In the IPv6 case, we're talking about a generous potential estimate of the population being less than 0.0043% of the available address space. >> That said. Any size prefix will likely work and is even permitted by >> the RFC. You do run the risk of encountering applications that assume >> a 64-bit prefix length, though. And you're often crippling the >> advantages of IPv6. > > And such applications are *BROKEN*. IPv6 is *classless* -- end of discussion. > > /64 (and /80 previous) is a lame optimization so really stupid devices can find an address in 4 bytes of machine code. This is quite lame given all the other complex baggage IPv6 requires. > > And then /64 is only required by SLAAC, which you are not required to use. > I disagree. There are many useful optimizations that come from /64 other than just SLAAC. However, SLAAC is also a very useful tool. > >> You should think of IPv6 as a 64-bit address that happens to include a >> 64-bit host identifier. > > No, you should not. That underminds the fundamental concept of IPv6 being *classless*. And it will lead to idiots writing broken applications and protocols assuming that to be true. > True, but, in terms of deploying networks, unless you have a really good reason not to, it is best to use /64 for all segments. It preserves what I like to call the principle of least surprise (the less you surprise the operators, the less likely they are to make mistakes) and it provides a very clean, easy to comprehend boundary that works in virtually any application. You never have to worry about outgrowing your subnet. SLAAC works wherever you want it to. You don't have to keep track of complex tables of allocations and optimizations of how you carved things up at the individual subnet level. You can focus on optimizing how you carve up aggregates of /64s into regions or sites or whatever. Personally I'm also a fan of using a /48 per site as well, allowing better concentration on optimizing the higher levels of the addressing hierarchy without getting buried in the minutiae of individual subnets. >> Another thing to consider is that most processors today lack >> operations for values that are larger than 64-bit. By separating the >> host and network segment at the 64-bit boundary you may be able to >> take advantage of performance optimizations that make the distinction >> between the two (and significantly reduce the cost of routing >> decisions, contributing to lower latency). > > IPv6 is classless; routers cannot blindly make that assumption for "performance optimization". > Blindly, no. However, it's not impractical to implement fast path switching that handles things on /64s and push anything that requires something else to the slow path. >> Many cite concerns of potential DoS attacks by doing sweeps of IPv6 >> networks. I don't think this will be a common or wide-spread problem. > > Myopia doesn't make the problem go away. The point of such an attack is not to "find things", but to overload the router(s). (which can be done rather easily by a few dozen machines.) > Only if you don't deploy reasonable mitigation strategies. Owen From owen at delong.com Mon Jan 24 18:48:59 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 24 Jan 2011 16:48:59 -0800 Subject: IPv6: numbering of point-to-point-links In-Reply-To: <4D3DA762.33E4.0097.1@globalstar.com> References: <FC64B3384195884588D252343702D23F01854588@ICABEXCCLU01B.int.sonofon.dk> <4E78852B-1695-4DEE-8B4D-C095446F2AEB@xs4all.nl> <20110124131820.GA10465@vacation.karoshi.com.> <4D3DA762.33E4.0097.1@globalstar.com> Message-ID: <D8D89ABF-2429-4911-96F4-DA578972A5D2@delong.com> On Jan 24, 2011, at 4:22 PM, Crist Clark wrote: >> RFC 3627 Actually makes it pretty clear. It's IPv6 think where the subnet-router anycast address is the prefix followed by all zeros. So, while IPv6 does not reserve the all-ones address, the all-zeroes address is still reserved. Owen From danny at tcb.net Mon Jan 24 19:24:22 2011 From: danny at tcb.net (Danny McPherson) Date: Mon, 24 Jan 2011 20:24:22 -0500 Subject: [arin-announce] ARIN Resource Certification Update In-Reply-To: <m27hdtrg6p.wl%randy@psg.com> References: <EE59203D-907A-4AA2-BAE6-AEE7AADAC0A2@arin.net> <0BC31466-09EA-4734-96B2-152453A62B90@arin.net> <m27hdtrg6p.wl%randy@psg.com> Message-ID: <FFDCC932-AFD0-428F-9A50-B3B389D4532B@tcb.net> On Jan 24, 2011, at 7:16 PM, Randy Bush wrote: > > i understand fearing holding others' private keys and critical data. no > blame there. > > <separate subject> > but out of curiousity, how reality based are arin's general liability > fears? in the last few years, how many times has arin been a named > defendant in a law suit? how many times a [principal] plaintiff? How many times has the operational integrity of ARIN's infrastructure influenced actual routing on the Internet in the past? Seems like well-placed concern on behalf of the ARIN BoT, IMO. <separate subject> Beginning to wonder why, with work like DANE and certificates in DNS in the IETF, we need an RPKI and new hierarchical shared dependency system at all and can't just place ROAs in in-addr.arpa zone files that are DNSSEC-enabled. --but very happy we have some progress for Internet number resource certification. -danny From randy at psg.com Mon Jan 24 19:32:04 2011 From: randy at psg.com (Randy Bush) Date: Tue, 25 Jan 2011 10:32:04 +0900 Subject: [arin-announce] ARIN Resource Certification Update In-Reply-To: <FFDCC932-AFD0-428F-9A50-B3B389D4532B@tcb.net> References: <EE59203D-907A-4AA2-BAE6-AEE7AADAC0A2@arin.net> <0BC31466-09EA-4734-96B2-152453A62B90@arin.net> <m27hdtrg6p.wl%randy@psg.com> <FFDCC932-AFD0-428F-9A50-B3B389D4532B@tcb.net> Message-ID: <m2wrltpy3v.wl%randy@psg.com> > Beginning to wonder why, with work like DANE and certificates in DNS > in the IETF, we need an RPKI and new hierarchical shared dependency > system at all and can't just place ROAs in in-addr.arpa zone files > that are DNSSEC-enabled. let's wind the wayback machine to 1998 http://tools.ietf.org/html/draft-bates-bgp4-nlri-orig-verif-00 randy From randy at psg.com Mon Jan 24 19:32:47 2011 From: randy at psg.com (Randy Bush) Date: Tue, 25 Jan 2011 10:32:47 +0900 Subject: IPv6: numbering of point-to-point-links In-Reply-To: <4D3DA762.33E4.0097.1@globalstar.com> References: <FC64B3384195884588D252343702D23F01854588@ICABEXCCLU01B.int.sonofon.dk> <4E78852B-1695-4DEE-8B4D-C095446F2AEB@xs4all.nl> Message-ID: <m2vd1dpy2o.wl%randy@psg.com> >> https://datatracker.ietf.org/doc/draft-ietf-6man-prefixlen-p2p/ > All of the (mostly religious) arguments about /64 versus any > smaller subnets aside, I'm curious about why one would choose > /126 over /127 for P-to-P links? see above randy From danny at tcb.net Mon Jan 24 19:41:06 2011 From: danny at tcb.net (Danny McPherson) Date: Mon, 24 Jan 2011 20:41:06 -0500 Subject: [arin-announce] ARIN Resource Certification Update In-Reply-To: <m2wrltpy3v.wl%randy@psg.com> References: <EE59203D-907A-4AA2-BAE6-AEE7AADAC0A2@arin.net> <0BC31466-09EA-4734-96B2-152453A62B90@arin.net> <m27hdtrg6p.wl%randy@psg.com> <FFDCC932-AFD0-428F-9A50-B3B389D4532B@tcb.net> <m2wrltpy3v.wl%randy@psg.com> Message-ID: <5079ECE0-FB43-4284-ADE2-E3E4E7DE1F3D@tcb.net> On Jan 24, 2011, at 8:32 PM, Randy Bush wrote: > let's wind the wayback machine to 1998 > > http://tools.ietf.org/html/draft-bates-bgp4-nlri-orig-verif-00 Yep, read that way back when it was posted initially, and again a short while back, makes good sense, methinks. And now that DNSSEC is deployed and DANE is happening, you could even include certificates there in the event that relying parties want to employ them for dynamic secure routing in the future and we wouldn't have to build (or deal with the operational and political hurdles that are sure to arise) with RPKI at all. -danny From randy at psg.com Mon Jan 24 19:48:10 2011 From: randy at psg.com (Randy Bush) Date: Tue, 25 Jan 2011 10:48:10 +0900 Subject: [arin-announce] ARIN Resource Certification Update In-Reply-To: <5079ECE0-FB43-4284-ADE2-E3E4E7DE1F3D@tcb.net> References: <EE59203D-907A-4AA2-BAE6-AEE7AADAC0A2@arin.net> <0BC31466-09EA-4734-96B2-152453A62B90@arin.net> <m27hdtrg6p.wl%randy@psg.com> <FFDCC932-AFD0-428F-9A50-B3B389D4532B@tcb.net> <m2wrltpy3v.wl%randy@psg.com> <5079ECE0-FB43-4284-ADE2-E3E4E7DE1F3D@tcb.net> Message-ID: <m2pqrlpxd1.wl%randy@psg.com> > And now that DNSSEC is deployed and you are not sharing what you are smoking > and DANE is happening see above randy From danny at tcb.net Mon Jan 24 19:59:35 2011 From: danny at tcb.net (Danny McPherson) Date: Mon, 24 Jan 2011 20:59:35 -0500 Subject: [arin-announce] ARIN Resource Certification Update In-Reply-To: <m2pqrlpxd1.wl%randy@psg.com> References: <EE59203D-907A-4AA2-BAE6-AEE7AADAC0A2@arin.net> <0BC31466-09EA-4734-96B2-152453A62B90@arin.net> <m27hdtrg6p.wl%randy@psg.com> <FFDCC932-AFD0-428F-9A50-B3B389D4532B@tcb.net> <m2wrltpy3v.wl%randy@psg.com> <5079ECE0-FB43-4284-ADE2-E3E4E7DE1F3D@tcb.net> <m2pqrlpxd1.wl%randy@psg.com> Message-ID: <BA751A64-E737-436E-B210-A3A4BBDB6E69@tcb.net> On Jan 24, 2011, at 8:48 PM, Randy Bush wrote: >> And now that DNSSEC is deployed > > and you are not sharing what you are smoking root and .arpa are signed, well on the way, particularly relative to RPKI. Incremental cost of signing in-addr.arpa using a deployed DNS system as opposed to continuing development, deployment and operationalizing and dealing with all the political issues with deploying a new RPKI system -- hrmm. And again, I'm not opposed to RPKI and know we REQUIRE number resource certification before we can secure the routing system. I just don't like the notion of deploying a brand new system with data that at the end of the day is going to look an awful lot like the existing in-addr.arpa delegation system that's deployed, and introduce new hierarchical shared dependencies that don't exist today. Keep it simple? -danny From jabley at hopcount.ca Mon Jan 24 20:02:00 2011 From: jabley at hopcount.ca (Joe Abley) Date: Mon, 24 Jan 2011 21:02:00 -0500 Subject: [arin-announce] ARIN Resource Certification Update In-Reply-To: <FFDCC932-AFD0-428F-9A50-B3B389D4532B@tcb.net> References: <EE59203D-907A-4AA2-BAE6-AEE7AADAC0A2@arin.net> <0BC31466-09EA-4734-96B2-152453A62B90@arin.net> <m27hdtrg6p.wl%randy@psg.com> <FFDCC932-AFD0-428F-9A50-B3B389D4532B@tcb.net> Message-ID: <66D828AA-16DB-43D4-A6D1-D40C137DCDAA@hopcount.ca> On 2011-01-24, at 20:24, Danny McPherson wrote: > <separate subject> > Beginning to wonder why, with work like DANE and certificates in DNS > in the IETF, we need an RPKI and new hierarchical shared dependency > system at all and can't just place ROAs in in-addr.arpa zone files that are > DNSSEC-enabled. In the case where (say) RIR allocates 10.0.0.0/8 to A A allocates 10.1.0.0/16 to B B allocates 10.1.1.0/24 to C there's a clear path of delegations in the DNS under IN-ADDR.ARPA from RIR -> A -> B -> C and this matches the chain of address assignments. If you adopt the convention that a secure delegation (a signed DS RRSet) is analogous to an RPKI signature over a customer certificate, then this seems vaguely usable. But what about this case? RIR allocates 10.0.0.0/8 to A A allocates 10.0.0.0/16 to B B allocates 10.0.0.0/24 to C In this case the DNS delegations go directly from RIR to C; there's no opportunity for A or B to sign intermediate zones, and hence no opportunity for them to indicate the legitimacy of the allocation. As a thought experiment, how would you see this working? Joe From jabley at hopcount.ca Mon Jan 24 20:06:54 2011 From: jabley at hopcount.ca (Joe Abley) Date: Mon, 24 Jan 2011 21:06:54 -0500 Subject: [arin-announce] ARIN Resource Certification Update In-Reply-To: <BA751A64-E737-436E-B210-A3A4BBDB6E69@tcb.net> References: <EE59203D-907A-4AA2-BAE6-AEE7AADAC0A2@arin.net> <0BC31466-09EA-4734-96B2-152453A62B90@arin.net> <m27hdtrg6p.wl%randy@psg.com> <FFDCC932-AFD0-428F-9A50-B3B389D4532B@tcb.net> <m2wrltpy3v.wl%randy@psg.com> <5079ECE0-FB43-4284-ADE2-E3E4E7DE1F3D@tcb.net> <m2pqrlpxd1.wl%randy@psg.com> <BA751A64-E737-436E-B210-A3A4BBDB6E69@tcb.net> Message-ID: <961C2162-0645-47F4-B968-7376B9F73C70@hopcount.ca> On 2011-01-24, at 20:59, Danny McPherson wrote: > On Jan 24, 2011, at 8:48 PM, Randy Bush wrote: > >>> And now that DNSSEC is deployed >> >> and you are not sharing what you are smoking > > root and .arpa are signed, well on the way, particularly relative > to RPKI. > > Incremental cost of signing in-addr.arpa using a deployed DNS > system as opposed to continuing development, deployment and > operationalizing and dealing with all the political issues with > deploying a new RPKI system -- hrmm. IN-ADDR.ARPA will be signed relatively soon, as part of the work described here: http://in-addr-transition.icann.org/ Timeline to follow, here and other similar lists, some time relatively soon. But I'm curious about your thoughts on the case I mentioned in my last message. I don't think the existence of a secure delegation chain from the root down to operator of the last sub-allocated address block is all that is required, here. Joe From rdobbins at arbor.net Mon Jan 24 20:11:13 2011 From: rdobbins at arbor.net (Roland Dobbins) Date: Tue, 25 Jan 2011 09:11:13 +0700 Subject: [arin-announce] ARIN Resource Certification Update In-Reply-To: <BA751A64-E737-436E-B210-A3A4BBDB6E69@tcb.net> References: <EE59203D-907A-4AA2-BAE6-AEE7AADAC0A2@arin.net> <0BC31466-09EA-4734-96B2-152453A62B90@arin.net> <m27hdtrg6p.wl%randy@psg.com> <FFDCC932-AFD0-428F-9A50-B3B389D4532B@tcb.net> <m2wrltpy3v.wl%randy@psg.com> <5079ECE0-FB43-4284-ADE2-E3E4E7DE1F3D@tcb.net> <m2pqrlpxd1.wl%randy@psg.com> <BA751A64-E737-436E-B210-A3A4BBDB6E69@tcb.net> Message-ID: <9B23DC26-BA8C-4756-852D-A7D8502ABBE2@arbor.net> On Jan 25, 2011, at 8:59 AM, Danny McPherson wrote: > I just don't like the notion of deploying a brand new system with data that at the end of the day is going to look an awful lot like the existing in-addr.arpa delegation system that's deployed, and introduce new hierarchical shared dependencies that don't exist today. Right - so, the macro point here is that in order to make use of rPKI so as to ensure the integrity of the global routing system, the presupposition is that there's already sufficient integrity in said routing global system for the rPKI tree to be successfully walked in the first place, given that it's all in-band, right? And since it's all in-band, anyways, with the recursive dependencies that implies, why not make use of another, pre-existing inband hierarchical system which is explicitly designed to ensure the integrity of its answers, and which is already in the initial stages of its deployment - i.e., DNSSEC? Note I'm not advocating this position, per se, just being sure I understand the argument for purposes of discussion. ------------------------------------------------------------------------ Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com> Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay From randy at psg.com Mon Jan 24 20:14:28 2011 From: randy at psg.com (Randy Bush) Date: Tue, 25 Jan 2011 11:14:28 +0900 Subject: [arin-announce] ARIN Resource Certification Update In-Reply-To: <BA751A64-E737-436E-B210-A3A4BBDB6E69@tcb.net> References: <EE59203D-907A-4AA2-BAE6-AEE7AADAC0A2@arin.net> <0BC31466-09EA-4734-96B2-152453A62B90@arin.net> <m27hdtrg6p.wl%randy@psg.com> <FFDCC932-AFD0-428F-9A50-B3B389D4532B@tcb.net> <m2wrltpy3v.wl%randy@psg.com> <5079ECE0-FB43-4284-ADE2-E3E4E7DE1F3D@tcb.net> <m2pqrlpxd1.wl%randy@psg.com> <BA751A64-E737-436E-B210-A3A4BBDB6E69@tcb.net> Message-ID: <m2ipxdpw57.wl%randy@psg.com> > I just don't like the notion of deploying a brand new system you want certificates etc? or did you plan to reuse dns keys? if the former, than all you are discussing is changing the transport to make routing security rely on dns and dns security. not a really great plan. if the latter, then you have the problem that the dns trust model is not congruent with the routing and address trust model. randy From danny at tcb.net Mon Jan 24 20:16:27 2011 From: danny at tcb.net (Danny McPherson) Date: Mon, 24 Jan 2011 21:16:27 -0500 Subject: [arin-announce] ARIN Resource Certification Update In-Reply-To: <66D828AA-16DB-43D4-A6D1-D40C137DCDAA@hopcount.ca> References: <EE59203D-907A-4AA2-BAE6-AEE7AADAC0A2@arin.net> <0BC31466-09EA-4734-96B2-152453A62B90@arin.net> <m27hdtrg6p.wl%randy@psg.com> <FFDCC932-AFD0-428F-9A50-B3B389D4532B@tcb.net> <66D828AA-16DB-43D4-A6D1-D40C137DCDAA@hopcount.ca> Message-ID: <BD1C3FBF-F5E5-4D8A-A95F-263255EA8E0C@tcb.net> On Jan 24, 2011, at 9:02 PM, Joe Abley wrote: > > In this case the DNS delegations go directly from RIR to C; there's no opportunity for A or B to sign intermediate zones, and hence no opportunity for them to indicate the legitimacy of the allocation. > > As a thought experiment, how would you see this working? New prefix-based RRs? And perhaps even a new .arpa or in-addr.arpa subdomain, the draft Randy referenced even discussed the latter, IIRC. -danny From richard.barnes at gmail.com Mon Jan 24 20:19:12 2011 From: richard.barnes at gmail.com (Richard Barnes) Date: Mon, 24 Jan 2011 21:19:12 -0500 Subject: [arin-announce] ARIN Resource Certification Update In-Reply-To: <9B23DC26-BA8C-4756-852D-A7D8502ABBE2@arbor.net> References: <EE59203D-907A-4AA2-BAE6-AEE7AADAC0A2@arin.net> <0BC31466-09EA-4734-96B2-152453A62B90@arin.net> <m27hdtrg6p.wl%randy@psg.com> <FFDCC932-AFD0-428F-9A50-B3B389D4532B@tcb.net> <m2wrltpy3v.wl%randy@psg.com> <5079ECE0-FB43-4284-ADE2-E3E4E7DE1F3D@tcb.net> <m2pqrlpxd1.wl%randy@psg.com> <BA751A64-E737-436E-B210-A3A4BBDB6E69@tcb.net> <9B23DC26-BA8C-4756-852D-A7D8502ABBE2@arbor.net> Message-ID: <AANLkTinq-dQgkM+MTnqhEEeOVUFKChZnH2G1fKR1dm0O@mail.gmail.com> It's in-band only in the sense of delivery. The worst that a corruption of the underlying network can do to you is deny you updates; it can't convince you that a route validates when it shouldn't. And even denying updates to your RPKI cache isn't that bad, since the update process doesn't really need to be real-time. Things will stay the same until you start hitting expiration times. The ultimate worst case is that everything expires and there are no RPKI-validated routes ... just like today. --Richard On Mon, Jan 24, 2011 at 9:11 PM, Roland Dobbins <rdobbins at arbor.net> wrote: > > On Jan 25, 2011, at 8:59 AM, Danny McPherson wrote: > >> I just don't like the notion of deploying a brand new system with data that at the end of the day is going to look an awful lot like the existing in-addr.arpa delegation system that's deployed, and introduce new hierarchical shared dependencies that don't exist today. > > > Right - so, the macro point here is that in order to make use of rPKI so as to ensure the integrity of the global routing system, the presupposition is that there's already sufficient integrity in said routing global system for the rPKI tree to be successfully walked in the first place, given that it's all in-band, right? > > And since it's all in-band, anyways, with the recursive dependencies that implies, why not make use of another, pre-existing inband hierarchical system which is explicitly designed to ensure the integrity of its answers, and which is already in the initial stages of its deployment - i.e., DNSSEC? > > Note I'm not advocating this position, per se, just being sure I understand the argument for purposes of discussion. > > ------------------------------------------------------------------------ > Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com> > > Most software today is very much like an Egyptian pyramid, with millions > of bricks piled on top of each other, with no structural integrity, but > just done by brute force and thousands of slaves. > > ? ? ? ? ? ? ? ? ? ? ? ? ?-- Alan Kay > > > From richard.barnes at gmail.com Mon Jan 24 20:21:15 2011 From: richard.barnes at gmail.com (Richard Barnes) Date: Mon, 24 Jan 2011 21:21:15 -0500 Subject: [arin-announce] ARIN Resource Certification Update In-Reply-To: <BD1C3FBF-F5E5-4D8A-A95F-263255EA8E0C@tcb.net> References: <EE59203D-907A-4AA2-BAE6-AEE7AADAC0A2@arin.net> <0BC31466-09EA-4734-96B2-152453A62B90@arin.net> <m27hdtrg6p.wl%randy@psg.com> <FFDCC932-AFD0-428F-9A50-B3B389D4532B@tcb.net> <66D828AA-16DB-43D4-A6D1-D40C137DCDAA@hopcount.ca> <BD1C3FBF-F5E5-4D8A-A95F-263255EA8E0C@tcb.net> Message-ID: <AANLkTimv+d0RjMAa+j1oHDrj66Co-_5ApFT4JrvZMVJd@mail.gmail.com> On Mon, Jan 24, 2011 at 9:16 PM, Danny McPherson <danny at tcb.net> wrote: > > On Jan 24, 2011, at 9:02 PM, Joe Abley wrote: >> >> In this case the DNS delegations go directly from RIR to C; there's no opportunity for A or B to sign intermediate zones, and hence no opportunity for them to indicate the legitimacy of the allocation. >> >> As a thought experiment, how would you see this working? > > New prefix-based RRs? ?And perhaps even a new .arpa or > in-addr.arpa subdomain, the draft Randy referenced even > discussed the latter, IIRC. > > -danny The more you have to invent, though, the more this sounds like a bike-shed discussion. s/DNSSEC/X.509/g s/delegating reverse "prefix" zone/signing RPKI delegation certificate/g From danny at tcb.net Mon Jan 24 20:24:06 2011 From: danny at tcb.net (Danny McPherson) Date: Mon, 24 Jan 2011 21:24:06 -0500 Subject: [arin-announce] ARIN Resource Certification Update In-Reply-To: <m2ipxdpw57.wl%randy@psg.com> References: <EE59203D-907A-4AA2-BAE6-AEE7AADAC0A2@arin.net> <0BC31466-09EA-4734-96B2-152453A62B90@arin.net> <m27hdtrg6p.wl%randy@psg.com> <FFDCC932-AFD0-428F-9A50-B3B389D4532B@tcb.net> <m2wrltpy3v.wl%randy@psg.com> <5079ECE0-FB43-4284-ADE2-E3E4E7DE1F3D@tcb.net> <m2pqrlpxd1.wl%randy@psg.com> <BA751A64-E737-436E-B210-A3A4BBDB6E69@tcb.net> <m2ipxdpw57.wl%randy@psg.com> Message-ID: <01A0ED8C-B925-4748-89C0-95842A082EAC@tcb.net> On Jan 24, 2011, at 9:14 PM, Randy Bush wrote: > > you want certificates etc? or did you plan to reuse dns keys? I suspect the former, reusing much of the SIDR machinery perhaps, although.... > if the former, than all you are discussing is changing the transport to > make routing security rely on dns and dns security. not a really great > plan. Right, I've heard the circular dependency arguments. So, are you suggesting the RPKI isn't going to rely on DNS at all? I'm of the belief RPKI should NOT be on the critical path, but instead focus on Internet number resource certification - are you suggesting otherwise? > if the latter, then you have the problem that the dns trust model is not > congruent with the routing and address trust model. That could be easily fixed with trivial tweaks and transitive trust/ delegation graphs that are, I suspect. -danny From randy at psg.com Mon Jan 24 20:31:31 2011 From: randy at psg.com (Randy Bush) Date: Tue, 25 Jan 2011 11:31:31 +0900 Subject: [arin-announce] ARIN Resource Certification Update In-Reply-To: <01A0ED8C-B925-4748-89C0-95842A082EAC@tcb.net> References: <EE59203D-907A-4AA2-BAE6-AEE7AADAC0A2@arin.net> <0BC31466-09EA-4734-96B2-152453A62B90@arin.net> <m27hdtrg6p.wl%randy@psg.com> <FFDCC932-AFD0-428F-9A50-B3B389D4532B@tcb.net> <m2wrltpy3v.wl%randy@psg.com> <5079ECE0-FB43-4284-ADE2-E3E4E7DE1F3D@tcb.net> <m2pqrlpxd1.wl%randy@psg.com> <BA751A64-E737-436E-B210-A3A4BBDB6E69@tcb.net> <m2ipxdpw57.wl%randy@psg.com> <01A0ED8C-B925-4748-89C0-95842A082EAC@tcb.net> Message-ID: <m2d3nlpvcs.wl%randy@psg.com> > Right, I've heard the circular dependency arguments. So, are you > suggesting the RPKI isn't going to rely on DNS at all? correct. it need not. > I'm of the belief RPKI should NOT be on the critical path, but instead > focus on Internet number resource certification - are you suggesting > otherwise? <channeling steve kent> see the word 'certification'? guess where that leads. pki. add resources and stir. >> if the latter, then you have the problem that the dns trust model is >> not congruent with the routing and address trust model. > That could be easily fixed with trivial tweaks and transitive trust/ > delegation graphs that are, I suspect. not bloody likely. the folk who sign dns zones are not even in the same building as the folk who deal with address space. in large isps, not even in the same town. randy From rdobbins at arbor.net Mon Jan 24 20:32:39 2011 From: rdobbins at arbor.net (Roland Dobbins) Date: Tue, 25 Jan 2011 09:32:39 +0700 Subject: [arin-announce] ARIN Resource Certification Update In-Reply-To: <01A0ED8C-B925-4748-89C0-95842A082EAC@tcb.net> References: <EE59203D-907A-4AA2-BAE6-AEE7AADAC0A2@arin.net> <0BC31466-09EA-4734-96B2-152453A62B90@arin.net> <m27hdtrg6p.wl%randy@psg.com> <FFDCC932-AFD0-428F-9A50-B3B389D4532B@tcb.net> <m2wrltpy3v.wl%randy@psg.com> <5079ECE0-FB43-4284-ADE2-E3E4E7DE1F3D@tcb.net> <m2pqrlpxd1.wl%randy@psg.com> <BA751A64-E737-436E-B210-A3A4BBDB6E69@tcb.net> <m2ipxdpw57.wl%randy@psg.com> <01A0ED8C-B925-4748-89C0-95842A082EAC@tcb.net> Message-ID: <61D53C88-ED94-4D8E-8039-A2743109E699@arbor.net> On Jan 25, 2011, at 9:24 AM, Danny McPherson wrote: > So, are you suggesting the RPKI isn't going to rely on DNS at all? In terms of organic, real-time route validation performed by routers - which it is assumed is an ultimate goal of rPKI, at some point in the future - one should hope this wouldn't be the case, yes? ------------------------------------------------------------------------ Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com> Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay From rdobbins at arbor.net Mon Jan 24 20:35:16 2011 From: rdobbins at arbor.net (Roland Dobbins) Date: Tue, 25 Jan 2011 09:35:16 +0700 Subject: [arin-announce] ARIN Resource Certification Update In-Reply-To: <m2d3nlpvcs.wl%randy@psg.com> References: <EE59203D-907A-4AA2-BAE6-AEE7AADAC0A2@arin.net> <0BC31466-09EA-4734-96B2-152453A62B90@arin.net> <m27hdtrg6p.wl%randy@psg.com> <FFDCC932-AFD0-428F-9A50-B3B389D4532B@tcb.net> <m2wrltpy3v.wl%randy@psg.com> <5079ECE0-FB43-4284-ADE2-E3E4E7DE1F3D@tcb.net> <m2pqrlpxd1.wl%randy@psg.com> <BA751A64-E737-436E-B210-A3A4BBDB6E69@tcb.net> <m2ipxdpw57.wl%randy@psg.com> <01A0ED8C-B925-4748-89C0-95842A082EAC@tcb.net> <m2d3nlpvcs.wl%randy@psg.com> Message-ID: <DCE30D86-7376-484A-A169-6BF366CA0A49@arbor.net> On Jan 25, 2011, at 9:31 AM, Randy Bush wrote: > the folk who sign dns zones are not even in the same building as the folk who deal with address space. I think the idea is to effectuate de-siloing in this space to the point that the DNS folks would make the appropriate delegations to the addressing folks, who would then proceed to create/administer their RRs/certs without further day-to-day reference to the DNS folks. ------------------------------------------------------------------------ Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com> Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay From randy at psg.com Mon Jan 24 20:40:41 2011 From: randy at psg.com (Randy Bush) Date: Tue, 25 Jan 2011 11:40:41 +0900 Subject: [arin-announce] ARIN Resource Certification Update In-Reply-To: <DCE30D86-7376-484A-A169-6BF366CA0A49@arbor.net> References: <EE59203D-907A-4AA2-BAE6-AEE7AADAC0A2@arin.net> <0BC31466-09EA-4734-96B2-152453A62B90@arin.net> <m27hdtrg6p.wl%randy@psg.com> <FFDCC932-AFD0-428F-9A50-B3B389D4532B@tcb.net> <m2wrltpy3v.wl%randy@psg.com> <5079ECE0-FB43-4284-ADE2-E3E4E7DE1F3D@tcb.net> <m2pqrlpxd1.wl%randy@psg.com> <BA751A64-E737-436E-B210-A3A4BBDB6E69@tcb.net> <m2ipxdpw57.wl%randy@psg.com> <01A0ED8C-B925-4748-89C0-95842A082EAC@tcb.net> <m2d3nlpvcs.wl%randy@psg.com> <DCE30D86-7376-484A-A169-6BF366CA0A49@arbor.net> Message-ID: <m2aaippuxi.wl%randy@psg.com> >> the folk who sign dns zones are not even in the same building as the >> folk who deal with address space. > I think the idea is to effectuate de-siloing in this space to the > point that the DNS folks would make the appropriate delegations to the > addressing folks, who would then proceed to create/administer their > RRs/certs without further day-to-day reference to the DNS folks. read more carefully. i was responding to danny taking my bait of using dns keying for resource keys. randy From danny at tcb.net Mon Jan 24 20:42:31 2011 From: danny at tcb.net (Danny McPherson) Date: Mon, 24 Jan 2011 21:42:31 -0500 Subject: [arin-announce] ARIN Resource Certification Update In-Reply-To: <AANLkTimv+d0RjMAa+j1oHDrj66Co-_5ApFT4JrvZMVJd@mail.gmail.com> References: <EE59203D-907A-4AA2-BAE6-AEE7AADAC0A2@arin.net> <0BC31466-09EA-4734-96B2-152453A62B90@arin.net> <m27hdtrg6p.wl%randy@psg.com> <FFDCC932-AFD0-428F-9A50-B3B389D4532B@tcb.net> <66D828AA-16DB-43D4-A6D1-D40C137DCDAA@hopcount.ca> <BD1C3FBF-F5E5-4D8A-A95F-263255EA8E0C@tcb.net> <AANLkTimv+d0RjMAa+j1oHDrj66Co-_5ApFT4JrvZMVJd@mail.gmail.com> Message-ID: <A2F681FA-E8B0-4A09-96A9-F1F74C049B61@tcb.net> On Jan 24, 2011, at 9:21 PM, Richard Barnes wrote: > The more you have to invent, though, the more this sounds like a > bike-shed discussion. > s/DNSSEC/X.509/g > s/delegating reverse "prefix" zone/signing RPKI delegation certificate/g The difference is that we don't have an operational RPKI system, we do have an operational DNS one. It's most certainly NOT a bike shed discussion - at least with respect to how I'd configure my routers. I suspect I've sufficiently chummed the waters, I'll kick back and absorb all the reasons this is a whack idea :) -danny From morrowc.lists at gmail.com Mon Jan 24 21:31:30 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 24 Jan 2011 22:31:30 -0500 Subject: [arin-announce] ARIN Resource Certification Update In-Reply-To: <66D828AA-16DB-43D4-A6D1-D40C137DCDAA@hopcount.ca> References: <EE59203D-907A-4AA2-BAE6-AEE7AADAC0A2@arin.net> <0BC31466-09EA-4734-96B2-152453A62B90@arin.net> <m27hdtrg6p.wl%randy@psg.com> <FFDCC932-AFD0-428F-9A50-B3B389D4532B@tcb.net> <66D828AA-16DB-43D4-A6D1-D40C137DCDAA@hopcount.ca> Message-ID: <AANLkTikr+Lsh=zFNnupt4_8bW6tQqveJsseE6zXAkt3c@mail.gmail.com> On Mon, Jan 24, 2011 at 9:02 PM, Joe Abley <jabley at hopcount.ca> wrote: > > On 2011-01-24, at 20:24, Danny McPherson wrote: > >> <separate subject> >> Beginning to wonder why, with work like DANE and certificates in DNS >> in the IETF, we need an RPKI ?and new hierarchical shared dependency >> system at all and can't just place ROAs in in-addr.arpa zone files that are >> DNSSEC-enabled. <snip> > But what about this case? > > ?RIR allocates 10.0.0.0/8 to A > ?A allocates 10.0.0.0/16 to B > ?B allocates 10.0.0.0/24 to C > > In this case the DNS delegations go directly from RIR to C; there's no opportunity for A or B to sign intermediate zones, and > hence no opportunity for them to indicate the legitimacy of the allocation. it's not the best example, but I know that at UUNET there were plenty of examples of the in-addr tree not really following the BGP path. -chris From smb at cs.columbia.edu Mon Jan 24 22:27:48 2011 From: smb at cs.columbia.edu (Steven Bellovin) Date: Mon, 24 Jan 2011 23:27:48 -0500 Subject: [arin-announce] ARIN Resource Certification Update In-Reply-To: <AANLkTikr+Lsh=zFNnupt4_8bW6tQqveJsseE6zXAkt3c@mail.gmail.com> References: <EE59203D-907A-4AA2-BAE6-AEE7AADAC0A2@arin.net> <0BC31466-09EA-4734-96B2-152453A62B90@arin.net> <m27hdtrg6p.wl%randy@psg.com> <FFDCC932-AFD0-428F-9A50-B3B389D4532B@tcb.net> <66D828AA-16DB-43D4-A6D1-D40C137DCDAA@hopcount.ca> <AANLkTikr+Lsh=zFNnupt4_8bW6tQqveJsseE6zXAkt3c@mail.gmail.com> Message-ID: <81DB557A-6336-40AE-9F1A-2E4A2718B1C9@cs.columbia.edu> On Jan 24, 2011, at 10:31 30PM, Christopher Morrow wrote: > On Mon, Jan 24, 2011 at 9:02 PM, Joe Abley <jabley at hopcount.ca> wrote: >> >> On 2011-01-24, at 20:24, Danny McPherson wrote: >> >>> <separate subject> >>> Beginning to wonder why, with work like DANE and certificates in DNS >>> in the IETF, we need an RPKI and new hierarchical shared dependency >>> system at all and can't just place ROAs in in-addr.arpa zone files that are >>> DNSSEC-enabled. > <snip> >> But what about this case? >> >> RIR allocates 10.0.0.0/8 to A >> A allocates 10.0.0.0/16 to B >> B allocates 10.0.0.0/24 to C >> >> In this case the DNS delegations go directly from RIR to C; there's no opportunity for A or B to sign intermediate zones, and >> hence no opportunity for them to indicate the legitimacy of the allocation. > > it's not the best example, but I know that at UUNET there were plenty > of examples of the in-addr tree not really following the BGP path. > The other essential point is that routers don't do RPKI queries in real-time; rather, they have a copy of the entire RPKI database, which they update as needed. In other words, the operational model doesn't fit the way the DNS works. --Steve Bellovin, http://www.cs.columbia.edu/~smb From morrowc.lists at gmail.com Mon Jan 24 22:35:46 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 24 Jan 2011 23:35:46 -0500 Subject: [arin-announce] ARIN Resource Certification Update In-Reply-To: <81DB557A-6336-40AE-9F1A-2E4A2718B1C9@cs.columbia.edu> References: <EE59203D-907A-4AA2-BAE6-AEE7AADAC0A2@arin.net> <0BC31466-09EA-4734-96B2-152453A62B90@arin.net> <m27hdtrg6p.wl%randy@psg.com> <FFDCC932-AFD0-428F-9A50-B3B389D4532B@tcb.net> <66D828AA-16DB-43D4-A6D1-D40C137DCDAA@hopcount.ca> <AANLkTikr+Lsh=zFNnupt4_8bW6tQqveJsseE6zXAkt3c@mail.gmail.com> <81DB557A-6336-40AE-9F1A-2E4A2718B1C9@cs.columbia.edu> Message-ID: <AANLkTimfEqa6U5dgqNcca4h_OX4vDBq3CQOujo_fisJ+@mail.gmail.com> On Mon, Jan 24, 2011 at 11:27 PM, Steven Bellovin <smb at cs.columbia.edu> wrote: > > On Jan 24, 2011, at 10:31 30PM, Christopher Morrow wrote: >> it's not the best example, but I know that at UUNET there were plenty >> of examples of the in-addr tree not really following the BGP path. >> > The other essential point is that routers don't do RPKI queries in > real-time; rather, they have a copy of the entire RPKI database, which > they update as needed. ?In other words, the operational model doesn't > fit the way the DNS works. sure, I was just adding fuel to jabley's in-addr graphing. thinking of using DNS is tempting, but there seem to be some corner cases that would cause hackery, so why not try to do it 'right' originally instead of using that shoe-horn? -chris (eh.. for the record, I do participate in the SIDR-wg which is trying to do this with the rPKI, so I am a little biased I suppose) From rdobbins at arbor.net Mon Jan 24 22:52:03 2011 From: rdobbins at arbor.net (Roland Dobbins) Date: Tue, 25 Jan 2011 11:52:03 +0700 Subject: [arin-announce] ARIN Resource Certification Update In-Reply-To: <AANLkTimfEqa6U5dgqNcca4h_OX4vDBq3CQOujo_fisJ+@mail.gmail.com> References: <EE59203D-907A-4AA2-BAE6-AEE7AADAC0A2@arin.net> <0BC31466-09EA-4734-96B2-152453A62B90@arin.net> <m27hdtrg6p.wl%randy@psg.com> <FFDCC932-AFD0-428F-9A50-B3B389D4532B@tcb.net> <66D828AA-16DB-43D4-A6D1-D40C137DCDAA@hopcount.ca> <AANLkTikr+Lsh=zFNnupt4_8bW6tQqveJsseE6zXAkt3c@mail.gmail.com> <81DB557A-6336-40AE-9F1A-2E4A2718B1C9@cs.columbia.edu> <AANLkTimfEqa6U5dgqNcca4h_OX4vDBq3CQOujo_fisJ+@mail.gmail.com> Message-ID: <7C7F5D42-E73A-4556-BD5F-76F49838258C@arbor.net> On Jan 25, 2011, at 11:35 AM, Christopher Morrow wrote: > thinking of using DNS is tempting The main arguments I see against it are: 1. Circular dependencies. 2. The generally creaky, fragile, brittle, non-scalable state of the overall DNS infrastructure in general. Routing and DNS, which are the two essential elements of the Internet control plane, are e also its Achilles' heels. It can be argued that making routing validation dependent upon the DNS would make this situation worse. The main reasons for it are those Danny stated: 1. DNS exists. 2. DNSSEC is in the initial stages of deployment. 3. There's additional relevant work going on which would make DNS more suitable for this application. 4. Deployment inertia. ------------------------------------------------------------------------ Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com> Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay From ryan.finnesey at HarrierInvestments.com Mon Jan 24 23:34:56 2011 From: ryan.finnesey at HarrierInvestments.com (Ryan Finnesey) Date: Mon, 24 Jan 2011 21:34:56 -0800 Subject: DSL options in NYC for OOB access In-Reply-To: <4D3DF769.7060601@nexus6.co.za> References: <4D3DF769.7060601@nexus6.co.za> Message-ID: <6EFFEFBAC68377459A2E972105C759EC0353968C@EXVBE005-2.exch005intermedia.net> Hi Andy We use Wireless (at&t) on a custom APN for this, has worked great. Cheers Ryan -----Original Message----- From: Andy Ashley [mailto:lists at nexus6.co.za] Sent: Monday, January 24, 2011 5:04 PM To: nanog at nanog.org Subject: DSL options in NYC for OOB access Hi, Im looking for a little advice about DSL circuits in New York, specifically at 111 8th Ave. Going to locate a console server there for out-of-band serial management. The router will need connectivity for remote telnet/ssh access from the NOC. Looking for a low speed (and low cost) DSL line with a fixed IP. I searched some obvious providers but dont really want to deal with a huge company (Verizon, Qwest, ?) if it can be avoided. Also $80-100+ seems a lot for something that will be used very rarely, but maybe those prices are normal. Are there smaller/independent companies out there offering this sort of thing? I dont know much about the US DSL market, so any hints are welcome. Thanks. Andy. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From sthaug at nethelp.no Tue Jan 25 00:02:30 2011 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Tue, 25 Jan 2011 07:02:30 +0100 (CET) Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <8B0D83FB-38DD-4C4D-9870-5913425BA3A2@delong.com> References: <AANLkTimcZavnJN2gqayS2-piDvOAcw_nrJAREJ0EDTjp@mail.gmail.com> <op.vpt734cxtfhldh@rbeam.xactional.com> <8B0D83FB-38DD-4C4D-9870-5913425BA3A2@delong.com> Message-ID: <20110125.070230.74664425.sthaug@nethelp.no> > > IPv6 is classless; routers cannot blindly make that assumption for "performance optimization". > > > Blindly, no. However, it's not impractical to implement fast path switching that > handles things on /64s and push anything that requires something else > to the slow path. Any vendor who was stupid enough to do *hardware* switching for up to /64 and punted the rest to software would certainly not get any sales from us. 128 bits. No magic. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From morrowc.lists at gmail.com Tue Jan 25 00:25:49 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 25 Jan 2011 01:25:49 -0500 Subject: [arin-announce] ARIN Resource Certification Update In-Reply-To: <7C7F5D42-E73A-4556-BD5F-76F49838258C@arbor.net> References: <EE59203D-907A-4AA2-BAE6-AEE7AADAC0A2@arin.net> <0BC31466-09EA-4734-96B2-152453A62B90@arin.net> <m27hdtrg6p.wl%randy@psg.com> <FFDCC932-AFD0-428F-9A50-B3B389D4532B@tcb.net> <66D828AA-16DB-43D4-A6D1-D40C137DCDAA@hopcount.ca> <AANLkTikr+Lsh=zFNnupt4_8bW6tQqveJsseE6zXAkt3c@mail.gmail.com> <81DB557A-6336-40AE-9F1A-2E4A2718B1C9@cs.columbia.edu> <AANLkTimfEqa6U5dgqNcca4h_OX4vDBq3CQOujo_fisJ+@mail.gmail.com> <7C7F5D42-E73A-4556-BD5F-76F49838258C@arbor.net> Message-ID: <AANLkTik99aV_wd+_Lsgczp=trOZwnJqWuMiqH5rd3haa@mail.gmail.com> On Mon, Jan 24, 2011 at 11:52 PM, Roland Dobbins <rdobbins at arbor.net> wrote: > > On Jan 25, 2011, at 11:35 AM, Christopher Morrow wrote: > >> thinking of using DNS is tempting > > > The main arguments I see against it are: > > 1. ? ? ?Circular dependencies. in the end though... if you depend upon something off-box to get you going, you're screwed. What makes that slightly better, in the case of the planned work so far (sidr work), is that the router feeds from an operator-decided location (direct-link, pop-local, region-local, network-local, neighbor-network). At initial boot time (for a long time probably) having 'valid' routes is less important than 'some routes'. Failing to 'get routing up' before 'secureify things', I think is the goal. With the ability to ratchet down the validation knob at operator demand when they feel 'validated only' is a good choice. > 2. ? ? ?The generally creaky, fragile, brittle, non-scalable state of the overall DNS infrastructure in general. > this is getting better, no? I mean for the in-addr and larger folks, anycast + lots of other things are making DNS much more reliable than it was 10 years ago... or am I living in a fantasy world? NOTE: I leave out unprepared (or under-prepared) end-sites wrt dos/ddos ... though I suppose in last month's example: Mastercard.com probably would have had (has?) their PTR records served from servers on the same end-site as their attacked asset :( so that's a failure mode to keep in mind (and extra things for operators at sites to keep in mind as well). > Routing and DNS, which are the two essential elements of the Internet control plane, are e also its Achilles' heels. ?It can be argued that making routing validation dependent upon the DNS would make this situation worse. > to some extent it will be, folks won't revert to /etc/hosts for getting to publication points, cache servers, etc ... BUT there are timescales measured here not in 'milliseconds' but in hours. Small-scale outages aren't as damaging, and if your cache infra is planned such that once you get external data internally you can feed all your regional/pop/etc caches from there, hopefully things are simpler. > The main reasons for it are those Danny stated: > > 1. ? ? ?DNS exists. > > 2. ? ? ?DNSSEC is in the initial stages of deployment. > > 3. ? ? ?There's additional relevant work going on which would make DNS more suitable for this application. > > 4. ? ? ?Deployment inertia. > yea, but I see forking this into DNS as having to hack about in something where it doesn't really fit well, and may end up with more hackery after the initial thoughts of: "Ah! just toss some new RR foo in there, sign with dnssec, win!" now we have: o oh, and don't keep all of your DNS servers on your network, in case of an outage. o don't forget about TTLs on records, how do you expire something? (this is a perennial problem in dns...) o delegating of subnets around to customers, on gear they operate (or don't??) There are likely more things to keep in mind as well. -Chris From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Tue Jan 25 03:29:34 2011 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Tue, 25 Jan 2011 19:59:34 +1030 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <20110125.070230.74664425.sthaug@nethelp.no> References: <AANLkTimcZavnJN2gqayS2-piDvOAcw_nrJAREJ0EDTjp@mail.gmail.com> <op.vpt734cxtfhldh@rbeam.xactional.com> <8B0D83FB-38DD-4C4D-9870-5913425BA3A2@delong.com> <20110125.070230.74664425.sthaug@nethelp.no> Message-ID: <20110125195934.37209e77@opy.nosense.org> On Tue, 25 Jan 2011 07:02:30 +0100 (CET) sthaug at nethelp.no wrote: > > > IPv6 is classless; routers cannot blindly make that assumption for "performance optimization". > > > > > Blindly, no. However, it's not impractical to implement fast path switching that > > handles things on /64s and push anything that requires something else > > to the slow path. > > Any vendor who was stupid enough to do *hardware* switching for up to > /64 and punted the rest to software would certainly not get any sales > from us. > Actually, they'd most likely punt the rest to exact match rather than longest match cams. Exact match cams are cheaper because they're simpler, and have been made even more so because they've been for more than a decade layer 2 switches, and they're are far many more of them than there are routers. > 128 bits. No magic. > "magic" is another way of describing progress. Electric start cars would have been "magic" to owners of Motorwagens. From mc3401 at columbia.edu Tue Jan 25 08:01:02 2011 From: mc3401 at columbia.edu (Michael Costello) Date: Tue, 25 Jan 2011 09:01:02 -0500 Subject: DSL options in NYC for OOB access In-Reply-To: <4D3DF769.7060601@nexus6.co.za> References: <4D3DF769.7060601@nexus6.co.za> Message-ID: <20110125090102.05a4bff4@mead.decaying.org> On Mon, 24 Jan 2011 22:04:25 +0000 Andy Ashley <lists at nexus6.co.za> wrote: > Hi, > > Im looking for a little advice about DSL circuits in New York, > specifically at 111 8th Ave. > Going to locate a console server there for out-of-band serial > management. The router will need connectivity for remote telnet/ssh > access from the NOC. > > Looking for a low speed (and low cost) DSL line with a fixed IP. > I searched some obvious providers but dont really want to deal with a > huge company (Verizon, Qwest, ?) if it can be avoided. > Also $80-100+ seems a lot for something that will be used very > rarely, but maybe those prices are normal. > > Are there smaller/independent companies out there offering this sort > of thing? > I dont know much about the US DSL market, so any hints are welcome. Speakeasy/Covad/Megapath and Panix offer DSL. Speakeasy is mostly pleasant to deal with, but I've never used Panix. mc From ryan.finnesey at HarrierInvestments.com Tue Jan 25 08:14:27 2011 From: ryan.finnesey at HarrierInvestments.com (Ryan Finnesey) Date: Tue, 25 Jan 2011 06:14:27 -0800 Subject: DSL options in NYC for OOB access In-Reply-To: <20110125090102.05a4bff4@mead.decaying.org> References: <4D3DF769.7060601@nexus6.co.za> <20110125090102.05a4bff4@mead.decaying.org> Message-ID: <6EFFEFBAC68377459A2E972105C759EC035396A0@EXVBE005-2.exch005intermedia.net> Speakeasy/Covad/Megapath is now all one company. -----Original Message----- From: Michael Costello [mailto:mc3401 at columbia.edu] Sent: Tuesday, January 25, 2011 9:01 AM To: nanog at nanog.org Subject: Re: DSL options in NYC for OOB access On Mon, 24 Jan 2011 22:04:25 +0000 Andy Ashley <lists at nexus6.co.za> wrote: > Hi, > > Im looking for a little advice about DSL circuits in New York, > specifically at 111 8th Ave. > Going to locate a console server there for out-of-band serial > management. The router will need connectivity for remote telnet/ssh > access from the NOC. > > Looking for a low speed (and low cost) DSL line with a fixed IP. > I searched some obvious providers but dont really want to deal with a > huge company (Verizon, Qwest, ?) if it can be avoided. > Also $80-100+ seems a lot for something that will be used very rarely, > but maybe those prices are normal. > > Are there smaller/independent companies out there offering this sort > of thing? > I dont know much about the US DSL market, so any hints are welcome. Speakeasy/Covad/Megapath and Panix offer DSL. Speakeasy is mostly pleasant to deal with, but I've never used Panix. mc From caleb.tennis at gmail.com Tue Jan 25 08:30:51 2011 From: caleb.tennis at gmail.com (Caleb Tennis) Date: Tue, 25 Jan 2011 09:30:51 -0500 Subject: Understanding reverse DNS better Message-ID: <D65B039B-36B2-4936-BC2A-24E8A9938B64@gmail.com> We have a /24 from one of our upstream providers that we handoff to a customer. The /24 has been SWIPd to us, and we have nameservers setup with ARIN against that record. Twice now this information has just "disappeared". That is, if do reverse DNS lookups, they returns nothing, whereas they were just working fine earlier. If you do an NS lookup on the block, it returns nothing. The /24 blocks immediately surrounding us continue to work just fine. If we do a lookup directly against our nameserver, it works just fine. It's like the nameserver information against that reverse DNS is just magically gone. The ARIN record looks good, nothing has changed. Last time, our upstream resubmitted the info so it would repopulate, and it started working again soon there after. I admit to not being the smartest one with how these records work: is the problem with the upstream, or ARIN's database, or is there not enough information to tell? Thanks, Caleb From jared at puck.nether.net Tue Jan 25 08:34:45 2011 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 25 Jan 2011 09:34:45 -0500 Subject: Understanding reverse DNS better In-Reply-To: <D65B039B-36B2-4936-BC2A-24E8A9938B64@gmail.com> References: <D65B039B-36B2-4936-BC2A-24E8A9938B64@gmail.com> Message-ID: <AE81CBB4-6CE4-484C-BE53-FA96D29A28F2@puck.nether.net> I suggest doing something like: dig +trace -x 204.42.254.5 You can watch the delegation authority for the in-addr at each stage. - Jared On Jan 25, 2011, at 9:30 AM, Caleb Tennis wrote: > We have a /24 from one of our upstream providers that we handoff to a customer. The /24 has been SWIPd to us, and we have nameservers setup with ARIN against that record. > > Twice now this information has just "disappeared". That is, if do reverse DNS lookups, they returns nothing, whereas they were just working fine earlier. If you do an NS lookup on the block, it returns nothing. The /24 blocks immediately surrounding us continue to work just fine. If we do a lookup directly against our nameserver, it works just fine. > > It's like the nameserver information against that reverse DNS is just magically gone. > > The ARIN record looks good, nothing has changed. Last time, our upstream resubmitted the info so it would repopulate, and it started working again soon there after. I admit to not being the smartest one with how these records work: is the problem with the upstream, or ARIN's database, or is there not enough information to tell? > > Thanks, > Caleb From l at p8x.net Tue Jan 25 08:38:43 2011 From: l at p8x.net (p8x) Date: Tue, 25 Jan 2011 22:38:43 +0800 Subject: Understanding reverse DNS better In-Reply-To: <AE81CBB4-6CE4-484C-BE53-FA96D29A28F2@puck.nether.net> References: <D65B039B-36B2-4936-BC2A-24E8A9938B64@gmail.com> <AE81CBB4-6CE4-484C-BE53-FA96D29A28F2@puck.nether.net> Message-ID: <4D3EE073.3070603@p8x.net> +1, also a quick check to make sure your name servers are actually set can be done with host.. host -t ns 0.168.192.in-addr.arpa On 25/01/2011 10:34 PM, Jared Mauch wrote: > I suggest doing something like: > > dig +trace -x 204.42.254.5 > > You can watch the delegation authority for the in-addr at each stage. > > - Jared > > On Jan 25, 2011, at 9:30 AM, Caleb Tennis wrote: > >> We have a /24 from one of our upstream providers that we handoff to a customer. The /24 has been SWIPd to us, and we have nameservers setup with ARIN against that record. >> >> Twice now this information has just "disappeared". That is, if do reverse DNS lookups, they returns nothing, whereas they were just working fine earlier. If you do an NS lookup on the block, it returns nothing. The /24 blocks immediately surrounding us continue to work just fine. If we do a lookup directly against our nameserver, it works just fine. >> >> It's like the nameserver information against that reverse DNS is just magically gone. >> >> The ARIN record looks good, nothing has changed. Last time, our upstream resubmitted the info so it would repopulate, and it started working again soon there after. I admit to not being the smartest one with how these records work: is the problem with the upstream, or ARIN's database, or is there not enough information to tell? >> >> Thanks, >> Caleb > From caleb.tennis at gmail.com Tue Jan 25 08:44:37 2011 From: caleb.tennis at gmail.com (Caleb Tennis) Date: Tue, 25 Jan 2011 09:44:37 -0500 Subject: Understanding reverse DNS better In-Reply-To: <AE81CBB4-6CE4-484C-BE53-FA96D29A28F2@puck.nether.net> References: <D65B039B-36B2-4936-BC2A-24E8A9938B64@gmail.com> <AE81CBB4-6CE4-484C-BE53-FA96D29A28F2@puck.nether.net> Message-ID: <F4A88E82-EC0E-4FDA-9FEB-0A2D16372897@gmail.com> Excellent, the +trace option is most helpful, thank you. On Jan 25, 2011, at 9:34 AM, Jared Mauch wrote: > I suggest doing something like: > > dig +trace -x 204.42.254.5 > > You can watch the delegation authority for the in-addr at each stage. > > - Jared > > On Jan 25, 2011, at 9:30 AM, Caleb Tennis wrote: > >> We have a /24 from one of our upstream providers that we handoff to a customer. The /24 has been SWIPd to us, and we have nameservers setup with ARIN against that record. >> >> Twice now this information has just "disappeared". That is, if do reverse DNS lookups, they returns nothing, whereas they were just working fine earlier. If you do an NS lookup on the block, it returns nothing. The /24 blocks immediately surrounding us continue to work just fine. If we do a lookup directly against our nameserver, it works just fine. >> >> It's like the nameserver information against that reverse DNS is just magically gone. >> >> The ARIN record looks good, nothing has changed. Last time, our upstream resubmitted the info so it would repopulate, and it started working again soon there after. I admit to not being the smartest one with how these records work: is the problem with the upstream, or ARIN's database, or is there not enough information to tell? >> >> Thanks, >> Caleb > From rps at maine.edu Tue Jan 25 08:44:44 2011 From: rps at maine.edu (Ray Soucy) Date: Tue, 25 Jan 2011 09:44:44 -0500 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <op.vpt734cxtfhldh@rbeam.xactional.com> References: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com> <AANLkTimcZavnJN2gqayS2-piDvOAcw_nrJAREJ0EDTjp@mail.gmail.com> <op.vpt734cxtfhldh@rbeam.xactional.com> Message-ID: <AANLkTikMLTkYqXSAV-ZqiVAe9sS_qxQ6z4vYPY6Q-VFj@mail.gmail.com> On Mon, Jan 24, 2011 at 7:10 PM, Ricky Beam <jfbeam at gmail.com> wrote: > On Mon, 24 Jan 2011 15:53:32 -0500, Ray Soucy <rps at maine.edu> wrote: >> >> Every time I see this question it' usually related to a fundamental >> misunderstanding of IPv6 and the attempt to apply v4 logic to v6. > > Not exactly. ?If it's a point-to-point link, then there are *TWO* machines > on it -- one at each end; there will *always* be two machines on it. > ?There's no sane reason to assign 18trillion addresses to it. ?Yes, in this > respect it's like not wasting an IPv4 /24, but it's also The Right Tool For > The Job.(tm) ?If one were to assign a /64 to every p-t-p link in the world, > IPv6 address space would be used at an insane rate. (and those assignments > aren't free.) Do people not remember the early days of IPv4 where /8's were > handed out like Pez? Not sure we disagree? I happily use 126-bit prefixes on point-to-point networks. The discussion is on LAN networks, though. >> That said. ?Any size prefix will likely work and is even permitted by >> the RFC. ?You do run the risk of encountering applications that assume >> a 64-bit prefix length, though. ?And you're often crippling the >> advantages of IPv6. > > And such applications are *BROKEN*. ?IPv6 is *classless* -- end of > discussion. Yes, they are broken, but if you think the fact that 1% of users using prefixes smaller than 64-bit will make those bad developers change their ways I'm not sure what to tell you. The horse has already left the barn on that one. But I'm not going to stop you from using 120-bit prefixes on all your networks if that's what you want. Having to shuffle LAN networks around because they no longer have the address space to support the number of hosts on it goes away if you stick with the 64 rule. DoS problems exists regardless of the prefix length. I'd rather find a solution to the problem than simply try to mitigate it by turning IPv6 into IPv4. > /64 (and /80 previous) is a lame optimization so really stupid devices can > find an address in 4 bytes of machine code. ?This is quite lame given all > the other complex baggage IPv6 requires. > > And then /64 is only required by SLAAC, which you are not required to use. > > >> You should think of IPv6 as a 64-bit address that happens to include a >> 64-bit host identifier. > > No, you should not. ?That underminds the fundamental concept of IPv6 being > *classless*. ?And it will lead to idiots writing broken applications and > protocols assuming that to be true. IPv6 is classless. You can have any size prefix you want. Chopping off the last 64-bits and calling it a host segment essentially turns IPv6 into a 64-bit address that will never have a need for PAT (NAT overload) which was the reasoning to go with the 128-bit address space. You can use any size prefix you want for routing. Are you of the mindset that everyone should use a 120-bit prefix for each network, then advertise each of those into BGP without route aggregation? I'm not really sure where you're going here. The argument can also be made that using smaller prefixes with sequential host numbering will lead to making network sweeps and port scanning viable in IPv6 where it would otherwise be useless. At that point you just need evidence of one IPv6 address being in use and you know that a few hundred next to it have the interesting hosts connected. >> Another thing to consider is that most processors today lack >> operations for values that are larger than 64-bit. ?By separating the >> host and network segment at the 64-bit boundary you may be able to >> take advantage of performance optimizations that make the distinction >> between the two (and significantly reduce the cost of routing >> decisions, contributing to lower latency). > > IPv6 is classless; routers cannot blindly make that assumption for > "performance optimization". I'm not saying its make-or-break. It certainly does help. Especially when we're trying to shave nanoseconds off. I don't foresee 128-bit CPUs simply to accommodated IPv6 anytime soon. These kinds of optimizations happen every day already in other applications. IPv6 will likely be no different as vendors begin to compete on who has the best IPv6 hardware. >> Many cite concerns of potential DoS attacks by doing sweeps of IPv6 >> networks. ?I don't think this will be a common or wide-spread problem. > > Myopia doesn't make the problem go away. ?The point of such an attack is not > to "find things", but to overload the router(s). (which can be done rather > easily by a few dozen machines.) > > --Ricky > Neither does avoiding it until it gets ignored? There are plenty of solutions and best practices that have nothing to do with the prefix length. I'm saying that you shouldn't use the possibility of a specific type of DoS attack (that is less attractive to attackers than nearly every other type of DoS attack out there) be your determinant for what prefix length you use. If an attacker wants to DoS a router and has the capacity to use this attack vector, they also have the capacity to achieve it with a dozen other ones. -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From laja at telenor.dk Tue Jan 25 08:44:34 2011 From: laja at telenor.dk (Lasse Jarlskov) Date: Tue, 25 Jan 2011 15:44:34 +0100 Subject: IPv6: numbering of point-to-point-links Message-ID: <FC64B3384195884588D252343702D23F0185477C@ICABEXCCLU01B.int.sonofon.dk> Thank you all for your comments - it appears that there is no consensus on how this should be done. Thank you for the reference to this draft, Marco - and to Ron as well. Both RFC3627 and this draft appears to be stating that these issues a implementation-specific. E.g. whether an implementation will perform subnet-router-anycast on a small subnet, whether Neighbor-Discovery-messages are rate-limited etc. Does anyone have any information on how different vendors handle this - even in older software? /126 appears to be the middle path - which is reserving the subnet-router-anycast address while keeping the subnet as small as possible. This appears to address both issues - at least for Ethernet links. (one free address will hardly constitute a potential Neighbor Cache Exhaustion issue). Best regards, /Lasse -----Oprindelig meddelelse----- Fra: Marco Hogewoning [mailto:mch-nanog at xs4all.nl] Sendt: 24. januar 2011 14:11 Til: Lasse Jarlskov Cc: nanog at nanog.org Emne: Re: IPv6: numbering of point-to-point-links > While reading up on IPv6, I've seen numerous places that subnets are now > all /64. > > I have even read that subnets defined as /127 are considered harmful. RFC3627, with a lot of discussion in the IETF on this. See also https://datatracker.ietf.org/doc/draft-ietf-6man-prefixlen-p2p/ > However while implementing IPv6 in our network, I've encountered several > of our peering partners using /127 or /126 for point-to-point links. I personally don't any benefit in using /126 subnets. > What is the Best Current Practice for this - if there is any? > > Would you recommend me to use /64, /126 or /127? > > What are the pros and cons? >From an operational point of view there is a risk that be using /64 somebody can eat away a lot of memory by either scanning or even changing addresses. This is also described in the draft above... I would personally recommend to at least always assign the /64, even if you would decide to configure the /127. RFC 3627 has been around long enough that you will keep running into equipment or software that won't like the /127. In which case you can always revert back to /64. This will also allow you to use easy to remember addresses like ::1 and ::2, saving you the headache of a lot of binary counting. Grtx, Marco From lesmith at ecsis.net Tue Jan 25 08:47:09 2011 From: lesmith at ecsis.net (Larry Smith) Date: Tue, 25 Jan 2011 08:47:09 -0600 Subject: Understanding reverse DNS better In-Reply-To: <4D3EE073.3070603@p8x.net> References: <D65B039B-36B2-4936-BC2A-24E8A9938B64@gmail.com> <AE81CBB4-6CE4-484C-BE53-FA96D29A28F2@puck.nether.net> <4D3EE073.3070603@p8x.net> Message-ID: <201101250847.10034.lesmith@ecsis.net> I use Squish (www.squish.net/dnscheck) for this purpose. Reasonable web interface and gives lots of info about where things are breaking down... -- Larry Smith lesmith at ecsis.net On Tue January 25 2011 08:38, p8x wrote: > +1, also a quick check to make sure your name servers are actually set > can be done with host.. host -t ns 0.168.192.in-addr.arpa > > On 25/01/2011 10:34 PM, Jared Mauch wrote: > > I suggest doing something like: > > > > dig +trace -x 204.42.254.5 > > > > You can watch the delegation authority for the in-addr at each stage. > > > > - Jared > > > > On Jan 25, 2011, at 9:30 AM, Caleb Tennis wrote: > >> We have a /24 from one of our upstream providers that we handoff to a > >> customer. The /24 has been SWIPd to us, and we have nameservers setup > >> with ARIN against that record. > >> > >> Twice now this information has just "disappeared". That is, if do > >> reverse DNS lookups, they returns nothing, whereas they were just > >> working fine earlier. If you do an NS lookup on the block, it returns > >> nothing. The /24 blocks immediately surrounding us continue to work > >> just fine. If we do a lookup directly against our nameserver, it works > >> just fine. > >> > >> It's like the nameserver information against that reverse DNS is just > >> magically gone. > >> > >> The ARIN record looks good, nothing has changed. Last time, our upstream > >> resubmitted the info so it would repopulate, and it started working > >> again soon there after. I admit to not being the smartest one with how > >> these records work: is the problem with the upstream, or ARIN's > >> database, or is there not enough information to tell? > >> > >> Thanks, > >> Caleb From jabley at hopcount.ca Tue Jan 25 08:52:45 2011 From: jabley at hopcount.ca (Joe Abley) Date: Tue, 25 Jan 2011 09:52:45 -0500 Subject: [arin-announce] ARIN Resource Certification Update In-Reply-To: <AANLkTik99aV_wd+_Lsgczp=trOZwnJqWuMiqH5rd3haa@mail.gmail.com> References: <EE59203D-907A-4AA2-BAE6-AEE7AADAC0A2@arin.net> <0BC31466-09EA-4734-96B2-152453A62B90@arin.net> <m27hdtrg6p.wl%randy@psg.com> <FFDCC932-AFD0-428F-9A50-B3B389D4532B@tcb.net> <66D828AA-16DB-43D4-A6D1-D40C137DCDAA@hopcount.ca> <AANLkTikr+Lsh=zFNnupt4_8bW6tQqveJsseE6zXAkt3c@mail.gmail.com> <81DB557A-6336-40AE-9F1A-2E4A2718B1C9@cs.columbia.edu> <AANLkTimfEqa6U5dgqNcca4h_OX4vDBq3CQOujo_fisJ+@mail.gmail.com> <7C7F5D42-E73A-4556-BD5F-76F49838258C@arbor.net> <AANLkTik99aV_wd+_Lsgczp=trOZwnJqWuMiqH5rd3haa@mail.gmail.com> Message-ID: <715C5932-FEB4-4E28-8567-7C11A3A0A188@hopcount.ca> On 2011-01-25, at 01:25, Christopher Morrow wrote: > On Mon, Jan 24, 2011 at 11:52 PM, Roland Dobbins <rdobbins at arbor.net> wrote: > >> 2. The generally creaky, fragile, brittle, non-scalable state of the overall DNS infrastructure in general. > > this is getting better, no? I mean for the in-addr and larger folks, > anycast + lots of other things are making DNS much more reliable than > it was 10 years ago... or am I living in a fantasy world? I think "generally creaky" is right on. The DNS is a seething, living tangle of misconfigurations and protocol violations, which I think is to be expected given that it's so very distributed. ("I think we should deploy a database that is co-admined by many millions of people who don't know each other, all using different varieties of software. We'll make everything end-users do on the Internet depend on it. It'll be great.") But I think "fragile", "brittle" and "non-scaleable" are demonstrably wrong. If the DNS was as unreliable as those words suggested, nobody would use it. The reality is that everybody uses it. Joe From rdobbins at arbor.net Tue Jan 25 09:04:08 2011 From: rdobbins at arbor.net (Roland Dobbins) Date: Tue, 25 Jan 2011 22:04:08 +0700 Subject: [arin-announce] ARIN Resource Certification Update In-Reply-To: <715C5932-FEB4-4E28-8567-7C11A3A0A188@hopcount.ca> References: <EE59203D-907A-4AA2-BAE6-AEE7AADAC0A2@arin.net> <0BC31466-09EA-4734-96B2-152453A62B90@arin.net> <m27hdtrg6p.wl%randy@psg.com> <FFDCC932-AFD0-428F-9A50-B3B389D4532B@tcb.net> <66D828AA-16DB-43D4-A6D1-D40C137DCDAA@hopcount.ca> <AANLkTikr+Lsh=zFNnupt4_8bW6tQqveJsseE6zXAkt3c@mail.gmail.com> <81DB557A-6336-40AE-9F1A-2E4A2718B1C9@cs.columbia.edu> <AANLkTimfEqa6U5dgqNcca4h_OX4vDBq3CQOujo_fisJ+@mail.gmail.com> <7C7F5D42-E73A-4556-BD5F-76F49838258C@arbor.net> <AANLkTik99aV_wd+_Lsgczp=trOZwnJqWuMiqH5rd3haa@mail.gmail.com> <715C5932-FEB4-4E28-8567-7C11A3A0A188@hopcount.ca> Message-ID: <D1EAB719-83ED-4370-A84E-B10DF3277C4A@arbor.net> On Jan 25, 2011, at 9:52 PM, Joe Abley wrote: > If the DNS was as unreliable as those words suggested, nobody would use it. I see evidence of this unreliability every day, so I must respectfully disagree. ;> > The reality is that everybody uses it. The reality is that they don't really have a choice, now, do they? ;> ------------------------------------------------------------------------ Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com> Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay From tdurack at gmail.com Tue Jan 25 09:25:56 2011 From: tdurack at gmail.com (Tim Durack) Date: Tue, 25 Jan 2011 10:25:56 -0500 Subject: IPv6: numbering of point-to-point-links In-Reply-To: <FC64B3384195884588D252343702D23F0185477C@ICABEXCCLU01B.int.sonofon.dk> References: <FC64B3384195884588D252343702D23F0185477C@ICABEXCCLU01B.int.sonofon.dk> Message-ID: <AANLkTikHBx_weZf73_WsD0doSfEgRGx5-NcTLszLwN=Z@mail.gmail.com> On Tue, Jan 25, 2011 at 9:44 AM, Lasse Jarlskov <laja at telenor.dk> wrote: > Thank you all for your comments - it appears that there is no consensus > on how this should be done. The best piece of advice I received when asking similar questions in the past is to allocate a /64 for every network regardless of it's potential size. Loopbacks, point-to-point, hosting VLANs etc. Then assign whatever size you are currently comfortable with. We've used /128s for loopbacks, safe in the knowledge that we can expand them all to /64s without renumbering (in case someone comes up with a good idea why /64s on loopbacks are necessary.) We've gone unnumbered on point-to-points, as a way of deferring that particular decision. Admittedly this reduces useful diagnostics available from traceroutes, although I quite like seeing loopbacks in traceroutes anyway. Unnumbered does reduce control-plane address space surface, which might be seen as a useful benefit (I'm sure someone will tell me why that's a bad idea.) My point is, if you do your number plan right, you should have some flexibility to make changes in the future without pain. -- Tim:> From ppauly at gmail.com Tue Jan 25 09:29:30 2011 From: ppauly at gmail.com (Peter Pauly) Date: Tue, 25 Jan 2011 10:29:30 -0500 Subject: Update Spamhaus DROP list from Cisco CLI (TCL) In-Reply-To: <A1B9BAEA8FE39847BCD6C473E894B595027BF5E0@SDEXMB02.Proflowers.com> References: <Acu4RmNhcNxWLNGOQgiCPBZhn6L0gQ==> <A1B9BAEA8FE39847BCD6C473E894B595027BF5E0@SDEXMB02.Proflowers.com> Message-ID: <AANLkTimei9p8PcUDj787D_4_uLUVjyxGpekM-7+Chct7@mail.gmail.com> I made a version of Mr. Magill's script to read the dshield.org's block list and create null routes for it. He deserves all of the credit, but none of the blame in case it doesn't work for you. I'm not a TCL programmer - use at your own risk. Anyone else have any nifty TCL for Cisco scripts they can share? I'm curious to know what's possible and what people have done. ############################################################ # updatedshield.tcl ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?# # ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?# # Peter Pauly ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?# # ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?# # based on the updatedrop.tcl script by: ? ? ? ? ? ? ? ? ? # # Thomas Magill ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?# # ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?# # Reads Dshield.org block list and null routes it. ? ? ? ? # # ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?# # alias exec updatedshield tclsh updatedshield.tcl ? ? ? ? # # Untested in YOUR environment - use at your own risk ? ? ?# ############################################################ proc convertmask {args} { set mask [expr {~ 0 << ( 32 - $args )}] format "%d.%d.%d.%d" [expr {$mask >> 24 & 255}] [expr {$mask >> 16 & 255}] [expr {$mask >> 8 & 255}] [expr {$mask & 255}] } proc getfile {url} { ?? ? ? ?global http ?? ? ? ?if {![regexp -nocase {^(http://)?([^:/]+)(:([0-9])+)?(/.*)} \ ?? ? ? ? ? ? ? ? ? ? ? ?$url x protocol server y port path]} { ?? ? ? ? ? ? ? ?error "bogus URL: $url" ?? ? ? ?} ?? ? ? ?if {[string length $port] == 0} { ?? ? ? ? ? ? ? ?set port 80 ?? ? ? ?} ?? ? ? ?set sock [socket $server $port] ?? ? ? ?puts $sock "GET $path HTTP/1.0" ?? ? ? ?puts $sock "Accept: */*" ?? ? ? ?puts $sock "Accept-Language: en-us" ?? ? ? ?puts $sock "Accept-Encoding: gzip, deflate" ?? ? ? ?puts $sock "Host: www.dshield.org" ?? ? ? ?puts $sock "Connection: Keep-Alive" ?? ? ? ?puts $sock "Cache-Control: no-cache" ?? ? ? ?puts $sock "" ?? ?flush $sock ?? ? ? ?return $sock } #REMOVE OLD Null Routes set oldline [ exec "show run | inc Dshield_block" ] foreach line [split $oldline "\n"] { if {$line != ""} { ??ios_config "no $line"} {} } #UPDATE Blocklist set newline [getfile www.dshield.org/block.txt] while { [gets $newline line] >= 0 } { ??if {[regexp {(?x)(\S+)\t(\S+)\t(\S+) } $line ignore ipaddr endip cidr]} { if {$ipaddr == "Start"} continue set mask [convertmask $cidr] ios_config "ip route $ipaddr $mask null0 name Dshield_block" ??} } From joly at punkcast.com Tue Jan 25 00:38:50 2011 From: joly at punkcast.com (Joly MacFie) Date: Tue, 25 Jan 2011 01:38:50 -0500 Subject: DSL options in NYC for OOB access In-Reply-To: <6EFFEFBAC68377459A2E972105C759EC0353968C@EXVBE005-2.exch005intermedia.net> References: <4D3DF769.7060601@nexus6.co.za> <6EFFEFBAC68377459A2E972105C759EC0353968C@EXVBE005-2.exch005intermedia.net> Message-ID: <AANLkTi=gJaJ=8FzAKM8g5AfeaR8gEZavgBYb3srgyT_e@mail.gmail.com> AFAIK all DSL providers will end up going through Verizon wires, you are just shifting customer service & billing. Alternatives are the Cable Co, probably Time Warner, or, more expensively, http://www.towerstream.com/ <http://www.towerstream.com/>j > -----Original Message----- > From: Andy Ashley [mailto:lists at nexus6.co.za] > Sent: Monday, January 24, 2011 5:04 PM > To: nanog at nanog.org > Subject: DSL options in NYC for OOB access > > Hi, > > Im looking for a little advice about DSL circuits in New York, > specifically at 111 8th Ave. > Going to locate a console server there for out-of-band serial > management. > The router will need connectivity for remote telnet/ssh access from the > NOC. > > Looking for a low speed (and low cost) DSL line with a fixed IP. > I searched some obvious providers but dont really want to deal with a > huge company (Verizon, Qwest, ?) if it can be avoided. > Also $80-100+ seems a lot for something that will be used very rarely, > but maybe those prices are normal. > > Are there smaller/independent companies out there offering this sort of > thing? > I dont know much about the US DSL market, so any hints are welcome. > > Thanks. > Andy. > > -- > This message has been scanned for viruses and dangerous content by > MailScanner, and is believed to be clean. > > > > -- --------------------------------------------------------------- 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 jethro.binks at strath.ac.uk Tue Jan 25 10:21:30 2011 From: jethro.binks at strath.ac.uk (Jethro R Binks) Date: Tue, 25 Jan 2011 16:21:30 +0000 (GMT) Subject: Understanding reverse DNS better In-Reply-To: <201101250847.10034.lesmith@ecsis.net> References: <D65B039B-36B2-4936-BC2A-24E8A9938B64@gmail.com> <AE81CBB4-6CE4-484C-BE53-FA96D29A28F2@puck.nether.net> <4D3EE073.3070603@p8x.net> <201101250847.10034.lesmith@ecsis.net> Message-ID: <alpine.BSF.2.00.1101251617480.53011@qrswnz.pp.fgengu.np.hx> On Tue, 25 Jan 2011, Larry Smith wrote: > I use Squish (www.squish.net/dnscheck) for this purpose. Reasonable web > interface and gives lots of info about where things are breaking down... > > -- > Larry Smith squish.net/dnscheck is great, except when I've had problems with it, or wanted a second opinion. Does anyone know another site that offers much the same functionality? Jethro. . . . . . . . . . . . . . . . . . . . . . . . . . Jethro R Binks, Network Manager, Information Services Directorate, University Of Strathclyde, Glasgow, UK The University of Strathclyde is a charitable body, registered in Scotland, number SC015263. From jeroen at unfix.org Tue Jan 25 10:26:41 2011 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 25 Jan 2011 17:26:41 +0100 Subject: Understanding reverse DNS better In-Reply-To: <alpine.BSF.2.00.1101251617480.53011@qrswnz.pp.fgengu.np.hx> References: <D65B039B-36B2-4936-BC2A-24E8A9938B64@gmail.com> <AE81CBB4-6CE4-484C-BE53-FA96D29A28F2@puck.nether.net> <4D3EE073.3070603@p8x.net> <201101250847.10034.lesmith@ecsis.net> <alpine.BSF.2.00.1101251617480.53011@qrswnz.pp.fgengu.np.hx> Message-ID: <4D3EF9C1.9000602@unfix.org> On 2011-01-25 17:21, Jethro R Binks wrote: > On Tue, 25 Jan 2011, Larry Smith wrote: > >> I use Squish (www.squish.net/dnscheck) for this purpose. Reasonable web >> interface and gives lots of info about where things are breaking down... >> >> -- >> Larry Smith > > squish.net/dnscheck is great, except when I've had problems with it, or > wanted a second opinion. Does anyone know another site that offers much > the same functionality? google(dns doctor) google(zonecheck) (various places host that tool and you can install it locally too) Oh and this tool called 'dig' which is really amazing. Greets, Jeroen From patrick.sumby at sohonet.co.uk Tue Jan 25 10:58:44 2011 From: patrick.sumby at sohonet.co.uk (Patrick Sumby) Date: Tue, 25 Jan 2011 16:58:44 +0000 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <AANLkTikHBb+cyfPxXftb5QZh136D04fkdWFMy3NFhDdi@mail.gmail.com> References: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com> <AANLkTimcZavnJN2gqayS2-piDvOAcw_nrJAREJ0EDTjp@mail.gmail.com> <AANLkTikHBb+cyfPxXftb5QZh136D04fkdWFMy3NFhDdi@mail.gmail.com> Message-ID: <4D3F0144.70107@sohonet.co.uk> On 24/01/2011 22:41, Michael Loftis wrote: > On Mon, Jan 24, 2011 at 1:53 PM, Ray Soucy<rps at maine.edu> wrote: > >> Many cite concerns of potential DoS attacks by doing sweeps of IPv6 >> networks. I don't think this will be a common or wide-spread problem. >> The general feeling is that there is simply too much address space >> for it to be done in any reasonable amount of time, and there is >> almost nothing to be gained from it. > > The problem I see is the opening of a new, simple, DoS/DDoS scenario. > By repetitively sweeping a targets /64 you can cause EVERYTHING in > that /64 to stop working by overflowing the ND/ND cache, depending on > the specific ND cache implementation and how big it is/etc. Routers > can also act as amplifiers too, DDoSing every host within a multicast > ND directed solicitation group (and THAT is even assuming a correctly > functioning switch thats limiting the multicast travel) > > Add to it the assumption that every router gets certain things right > (like everything correctly decrementing TTLs as assumed in RFC 4861 > 11.2 in order for hosts to detect off-link RA/ND messages and guard > themselves against those), in these ways it's certainly at least > somewhat worse than ARP. > > If you're able to bring down, or severely limit, a site by sending a > couple thousand PPS towards the /64 it's on, or by varying the upper > parts of the /64 to flood all the hosts with multicast traffic while > simultaneously floodign the routers LRU ND cache well thats a cheap > and easy attack and it WILL be used, and that can be done with the > protocols working as designed, at least from my reading. Granted I > don't have an IPv6 lab to test any of this. But I'd be willing to bet > this exact scenario is readily and easily possible, it already is with > ARP tables (and it DOES happen, it's just harder to make happen with > ARP and IPv4 since the space is so small, esp when compared to a /64) > IPv6 ND LRU Caches/tables aren't going to be anywhere near big enough > to handle a single /64's worth of hosts. And if they're any > significant amt smaller then it'd be trivial to cause a DoS by > sweeping the address space. It would depend on the ND table > limits/sizes, and any implementation specific timers/etc and garbage > collection, and a some other details I don't have, but, I bet it'd be > a really small flow in the scheme of things to completely stomp out a > /64....someone I'm sure knows more about the implementations, and I'm > betting this has been brought up before about IPv6/ND... > > So I pretty strongly disagree about your statement. Repetitively > sweeping an IPv6 network to DoS/DDoS the ND protocol thereby flooding > the ND cache/LRUs could be extremely effective and if not payed > serious attention will cause serious issues. > Yes.... This is an issue for point-to-point links but using a longer prefix (/126 or similar) has been suggested as a mitigation for this sort of attack. I would assume that in the LAN scenario where you have a /64 for your internal network that you would have some sort of stateful firewall sitting infront of the network to stop any un-initiated sessions. This therefore stops any hammering of ND cache etc. The argument then is that the number of packets hitting your firewall / bandwidth starvation would be the the alternative line of attack for a DoS/DDos but that is a completely different issue. From jbates at brightok.net Tue Jan 25 11:44:49 2011 From: jbates at brightok.net (Jack Bates) Date: Tue, 25 Jan 2011 11:44:49 -0600 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <4D3F0144.70107@sohonet.co.uk> References: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com> <AANLkTimcZavnJN2gqayS2-piDvOAcw_nrJAREJ0EDTjp@mail.gmail.com> <AANLkTikHBb+cyfPxXftb5QZh136D04fkdWFMy3NFhDdi@mail.gmail.com> <4D3F0144.70107@sohonet.co.uk> Message-ID: <4D3F0C11.5070009@brightok.net> On 1/25/2011 10:58 AM, Patrick Sumby wrote: > I would assume that in the LAN scenario where you have a /64 for your > internal network that you would have some sort of stateful firewall > sitting infront of the network to stop any un-initiated sessions. This > therefore stops any hammering of ND cache etc. The argument then is that > the number of packets hitting your firewall / bandwidth starvation would > be the the alternative line of attack for a DoS/DDos but that is a > completely different issue. There are many IPv4 networks that don't implement firewall rules for subnets which contain servers. DDoS mitigation is handled differently. It would not be unexpected for these networks to do the same with IPv6. Jack From rdobbins at arbor.net Tue Jan 25 11:50:42 2011 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 26 Jan 2011 00:50:42 +0700 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <4D3F0C11.5070009@brightok.net> References: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com> <AANLkTimcZavnJN2gqayS2-piDvOAcw_nrJAREJ0EDTjp@mail.gmail.com> <AANLkTikHBb+cyfPxXftb5QZh136D04fkdWFMy3NFhDdi@mail.gmail.com> <4D3F0144.70107@sohonet.co.uk> <4D3F0C11.5070009@brightok.net> Message-ID: <AC6261B7-A2BE-4EE1-8760-8006870C9309@arbor.net> On Jan 26, 2011, at 12:44 AM, Jack Bates wrote: > DDoS mitigation is handled differently. Concur 100%. Also note that firewalls don't provide any sort of useful DDoS protection, marketing claims aside, so reaction tools such as S/RTBH, et. al. are required to protect stateful firewalls in front of client access LANs, and everything behind said stateful firewalls, from DDoS. ------------------------------------------------------------------------ Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com> Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay From owen at delong.com Tue Jan 25 12:42:29 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 25 Jan 2011 10:42:29 -0800 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <4D3F0144.70107@sohonet.co.uk> References: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com> <AANLkTimcZavnJN2gqayS2-piDvOAcw_nrJAREJ0EDTjp@mail.gmail.com> <AANLkTikHBb+cyfPxXftb5QZh136D04fkdWFMy3NFhDdi@mail.gmail.com> <4D3F0144.70107@sohonet.co.uk> Message-ID: <58166C50-0B72-43A0-8AB8-25E803EA1619@delong.com> On Jan 25, 2011, at 8:58 AM, Patrick Sumby wrote: > On 24/01/2011 22:41, Michael Loftis wrote: >> On Mon, Jan 24, 2011 at 1:53 PM, Ray Soucy<rps at maine.edu> wrote: >> >>> Many cite concerns of potential DoS attacks by doing sweeps of IPv6 >>> networks. I don't think this will be a common or wide-spread problem. >>> The general feeling is that there is simply too much address space >>> for it to be done in any reasonable amount of time, and there is >>> almost nothing to be gained from it. >> >> The problem I see is the opening of a new, simple, DoS/DDoS scenario. >> By repetitively sweeping a targets /64 you can cause EVERYTHING in >> that /64 to stop working by overflowing the ND/ND cache, depending on >> the specific ND cache implementation and how big it is/etc. Routers >> can also act as amplifiers too, DDoSing every host within a multicast >> ND directed solicitation group (and THAT is even assuming a correctly >> functioning switch thats limiting the multicast travel) I love this term... "repetitively sweeping a targets /64". Seriously? Repetitively sweeping a /64? Let's do the math... 2^64 = 18,446,744,073,709,551,616 IP addresses. Let's assume that few networks would not be DOS'd by a 1,000 PPS storm coming in so that's a reasonable cap on our scan rate. That means sweeping a /64 takes 18,446,744,073,709,551 sec. (rounded down). There are 86,400 seconds per day. 18,446,744,073,709,551 / 86,400 = 213,503,982,334 days. Rounding a year down to 365 days, that's 584,942,417 years to sweep the /64 once. If we increase our scan rate to 1,000,000 packets per second, it still takes us 584,942 years to sweep a /64. I don't know about you, but I do not expect to live long enough to sweep a /64, let alone do so repetitively. Owen From gbonser at seven.com Tue Jan 25 12:49:51 2011 From: gbonser at seven.com (George Bonser) Date: Tue, 25 Jan 2011 10:49:51 -0800 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <4D3F0144.70107@sohonet.co.uk> References: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com> <AANLkTimcZavnJN2gqayS2-piDvOAcw_nrJAREJ0EDTjp@mail.gmail.com><AANLkTikHBb+cyfPxXftb5QZh136D04fkdWFMy3NFhDdi@mail.gmail.com> <4D3F0144.70107@sohonet.co.uk> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC135D1@RWC-EX1.corp.seven.com> > > > > So I pretty strongly disagree about your statement. Repetitively > > sweeping an IPv6 network to DoS/DDoS the ND protocol thereby flooding > > the ND cache/LRUs could be extremely effective and if not payed > > serious attention will cause serious issues. > > > > > Yes.... This is an issue for point-to-point links but using a longer > prefix (/126 or similar) has been suggested as a mitigation for this > sort of attack. > > I would assume that in the LAN scenario where you have a /64 for your > internal network that you would have some sort of stateful firewall > sitting infront of the network to stop any un-initiated sessions. This > therefore stops any hammering of ND cache etc. The argument then is > that > the number of packets hitting your firewall / bandwidth starvation > would > be the the alternative line of attack for a DoS/DDos but that is a > completely different issue. > > So for /64 subnets used for point-to-points you disable ND, configure static neighbors and that's the end of it. No ND DDoS. From nmaxpierson at gmail.com Tue Jan 25 12:19:34 2011 From: nmaxpierson at gmail.com (Max Pierson) Date: Tue, 25 Jan 2011 12:19:34 -0600 Subject: Another v6 question Message-ID: <AANLkTikEZVYFz+bx7MVXeht_qNnpkUEC_Mx0qhE6J9SR@mail.gmail.com> Hi List, Sorry to bring up yet ANOTHER v6 question/topic, but this seems to be one that I cannot get a solid answer on (and probably won't and in the event that I do, it will probably change down the road anyways), but here goes. >From the provider perspective, what is the prefix-length that most are accepting to be injected into your tables?? 2 or so years ago, I read where someone stated that they were told by ATT that they weren't planning on accepting anything smaller than a /32. So what if I get my shiny new /48 from ARIN and am already multi-homed??? Does ATT not want my business (which they wouldn't get if the first place, but for argument sake, yes, I chose to pick on ATT, sorry if I offended anyone :) I already see /40's /48's ,etc in the v6 table, so some folks are allowing /48 and smaller, so what is the new /24 in v6? I only ask due to the fact that ARIN's policy for end-users is /48 minimum (which is what i've been telling folks to apply for or applying for it on behalf of them). Second, as I was crunching a few numbers to get a rough estimate of what a global table would look like in say 3 or 5 years after v4 is exhausted (I understand that it's completely unpredictable to do this, but curiosity killed the cat I guess), and in a few cases, I stopped due to the shear size of the amount of prefixes I was coming with. Where i'm getting with this is has anyone done any crunching on prefix count for v6 (as in estimates of global table usage with the various prefix lengths seen above _based_ on the initial allocation of the v6 space (not the entire v6 space itself)). I'm interested to see how long before we have 96Gb's of TCAM/Memory (take you vendor of choice) in our routers just to take a full table. (Not to mention still having all of the ipv4 de-agg crazyness going on today. Seriously, who lets /28 and /32's in their tables today? And this will only get worse as v4 fades away). Would love to hear comments from anyone that was rejected peering due to only having a /48. Would also like to hear from anyone about projected table sizes if anyone has done any research on this. Heading back to my cave now to hopefully hear some good responses. (An someone please correct me if any of the above is incorrect). TIA, Max From owen at delong.com Tue Jan 25 13:46:24 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 25 Jan 2011 11:46:24 -0800 Subject: Another v6 question In-Reply-To: <AANLkTikEZVYFz+bx7MVXeht_qNnpkUEC_Mx0qhE6J9SR@mail.gmail.com> References: <AANLkTikEZVYFz+bx7MVXeht_qNnpkUEC_Mx0qhE6J9SR@mail.gmail.com> Message-ID: <55E7EC47-C434-4DF7-B92A-8EBC24133C53@delong.com> On Jan 25, 2011, at 10:19 AM, Max Pierson wrote: > Hi List, > > Sorry to bring up yet ANOTHER v6 question/topic, but this seems to be one > that I cannot get a solid answer on (and probably won't and in the event > that I do, it will probably change down the road anyways), but here goes. > >> From the provider perspective, what is the prefix-length that most are > accepting to be injected into your tables?? 2 or so years ago, I read where > someone stated that they were told by ATT that they weren't planning on > accepting anything smaller than a /32. So what if I get my shiny new /48 > from ARIN and am already multi-homed??? Does ATT not want my business (which > they wouldn't get if the first place, but for argument sake, yes, I chose to > pick on ATT, sorry if I offended anyone :) I already see /40's /48's ,etc > in the v6 table, so some folks are allowing /48 and smaller, so what is the > new /24 in v6? > Today, the vast majority of providers are accepting /48s in IPv6. Verizon was holding the line at /32 for a while, but, they moved to /48 a few months ago. Let's be clear on terminology. I don't think anyone is allowing smaller than /48, but, most are allowing /48 and shorter. (shorter prefix = bigger network). > I only ask due to the fact that ARIN's policy for end-users is /48 minimum > (which is what i've been telling folks to apply for or applying for it on > behalf of them). > That's correct. > Second, as I was crunching a few numbers to get a rough estimate of what a > global table would look like in say 3 or 5 years after v4 is exhausted (I > understand that it's completely unpredictable to do this, but curiosity > killed the cat I guess), and in a few cases, I stopped due to the shear size > of the amount of prefixes I was coming with. Where i'm getting with this is > has anyone done any crunching on prefix count for v6 (as in estimates of > global table usage with the various prefix lengths seen above _based_ on the > initial allocation of the v6 space (not the entire v6 space itself)). I'm You really can't map prefix availability to prefix usage. There are 4 billion IPv4 /32s. There aren't 4 billion LIRs that will get /32s. There are 256 trillion IPv4 /48s (roughly). There are not 256 trillion end sites that will apply for /48s. The whole point of IPv6 is that the number of prefixes vastly exceeds the number of applicants that will use them. To measure the likely content of the IPv6 global table, then, we need to look at the number and type of users rather than looking at the maximum available number of prefixes. I haven't had trouble reaching anything I care about from my /48 advertised through Hurricane Electric and Layer 42. > interested to see how long before we have 96Gb's of TCAM/Memory (take you > vendor of choice) in our routers just to take a full table. (Not to mention > still having all of the ipv4 de-agg crazyness going on today. Seriously, who > lets /28 and /32's in their tables today? And this will only get worse as v4 > fades away). > Yeah, that's not likely to happen. TCAM doesn't scale that way. As to the IPv4 de-agg, I think that's going to be one of the primary causes for an accelerated deprecation of IPv4 once IPv6 starts to become more ubiquitous. Owen From gbonser at seven.com Tue Jan 25 13:44:01 2011 From: gbonser at seven.com (George Bonser) Date: Tue, 25 Jan 2011 11:44:01 -0800 Subject: Another v6 question In-Reply-To: <AANLkTikEZVYFz+bx7MVXeht_qNnpkUEC_Mx0qhE6J9SR@mail.gmail.com> References: <AANLkTikEZVYFz+bx7MVXeht_qNnpkUEC_Mx0qhE6J9SR@mail.gmail.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC135D5@RWC-EX1.corp.seven.com> > From: Max Pierson > Sent: Tuesday, January 25, 2011 10:20 AM > To: nanog group > Subject: Another v6 question > > > >From the provider perspective, what is the prefix-length that most are > accepting to be injected into your tables?? 2 or so years ago, I read > where > someone stated that they were told by ATT that they weren't planning on > accepting anything smaller than a /32. So what if I get my shiny new > /48 > from ARIN and am already multi-homed??? Does ATT not want my business > (which > they wouldn't get if the first place, but for argument sake, yes, I > chose to > pick on ATT, sorry if I offended anyone :) I already see /40's /48's > ,etc > in the v6 table, so some folks are allowing /48 and smaller, so what is > the > new /24 in v6? Generally, a /48 from PI space and a /32 from PA space will be accepted. If you were issued a /48 from ARIN it will generally be accepted. Some accept all the way out to a /64. I do see some de-aggregated /64 nets I am currently filtering but since the path is the same as the /32, I haven't seen need to open those filters up yet. Can't figure out why those are de-aggregated either as I don't see the more specific announced anywhere else. From streiner at cluebyfour.org Tue Jan 25 09:59:21 2011 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Tue, 25 Jan 2011 10:59:21 -0500 (EST) Subject: Another v6 question In-Reply-To: <AANLkTikEZVYFz+bx7MVXeht_qNnpkUEC_Mx0qhE6J9SR@mail.gmail.com> References: <AANLkTikEZVYFz+bx7MVXeht_qNnpkUEC_Mx0qhE6J9SR@mail.gmail.com> Message-ID: <Pine.LNX.4.64.1101251025490.14199@whammy.cluebyfour.org> On Tue, 25 Jan 2011, Max Pierson wrote: >> From the provider perspective, what is the prefix-length that most are > accepting to be injected into your tables?? 2 or so years ago, I read where > someone stated that they were told by ATT that they weren't planning on > accepting anything smaller than a /32. So what if I get my shiny new /48 > from ARIN and am already multi-homed??? Does ATT not want my business (which > they wouldn't get if the first place, but for argument sake, yes, I chose to > pick on ATT, sorry if I offended anyone :) I already see /40's /48's ,etc > in the v6 table, so some folks are allowing /48 and smaller, so what is the > new /24 in v6? >From what I've seen, both in terms of policy and practice is that most people are considering /48 to be 'the new /24'. A number of providers haven't published their v6 policies yet (at least in any place that's easy to find), but it looks like based on policy alone, NTT and Verizon will accept /48s. Also, I don't know that the number of v6 prefixes will get completely out of control for a while. Many of the bigger consumers of v4 space are getting (or have gotten) initial v6 assignments that are large enough to satisfy their space needs for some time, so the number of v6 prefixes being announced to provide connectivity to a given number of ISP customers should actually go down somewhat. For example, Comcast has several /8s of v4 space, and they are announcing a /29 into the global v6 table at the moment. That could certainly change as they ramp up their deployment of v6, but I still think the number of v6 prefixes compared to v4 will be net-negative for a long time. jms From bmanning at vacation.karoshi.com Tue Jan 25 14:03:47 2011 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 25 Jan 2011 20:03:47 +0000 Subject: Another v6 question In-Reply-To: <55E7EC47-C434-4DF7-B92A-8EBC24133C53@delong.com> References: <AANLkTikEZVYFz+bx7MVXeht_qNnpkUEC_Mx0qhE6J9SR@mail.gmail.com> <55E7EC47-C434-4DF7-B92A-8EBC24133C53@delong.com> Message-ID: <20110125200347.GA23860@vacation.karoshi.com.> > > Second, as I was crunching a few numbers to get a rough estimate of what a > > global table would look like in say 3 or 5 years after v4 is exhausted (I > > understand that it's completely unpredictable to do this, but curiosity > > killed the cat I guess), and in a few cases, I stopped due to the shear size > > of the amount of prefixes I was coming with. Where i'm getting with this is > > has anyone done any crunching on prefix count for v6 (as in estimates of > > global table usage with the various prefix lengths seen above _based_ on the > > initial allocation of the v6 space (not the entire v6 space itself)). I'm > > You really can't map prefix availability to prefix usage. this is so true. and yet you proceed, in your next few sentences to do -exactly- that. :) > There are 4 billion IPv4 /32s. There aren't 4 billion LIRs that will get /32s. presuming the LIR model holds... > There are 256 trillion IPv4 /48s (roughly). There are not 256 trillion > end sites that will apply for /48s. apply to whom? the RIR/LIR model is not the only place/venue for getting a /48. > The whole point of IPv6 is that the number of prefixes vastly exceeds > the number of applicants that will use them. not sure I buy that arguement. > To measure the likely content of the IPv6 global table, then, we need > to look at the number and type of users rather than looking at the > maximum available number of prefixes. if there is a global table that is interesting (debatable point) then I'd be more interested in curn rates and overlapping announcements. > > I haven't had trouble reaching anything I care about from my /48 > advertised through Hurricane Electric and Layer 42. > > > interested to see how long before we have 96Gb's of TCAM/Memory (take you > > vendor of choice) in our routers just to take a full table. (Not to mention > > still having all of the ipv4 de-agg crazyness going on today. Seriously, who > > lets /28 and /32's in their tables today? And this will only get worse as v4 > > fades away). > > > Yeah, that's not likely to happen. TCAM doesn't scale that way. As to the > IPv4 de-agg, I think that's going to be one of the primary causes for > an accelerated deprecation of IPv4 once IPv6 starts to become more > ubiquitous. > > Owen > > From nick at flhsi.com Tue Jan 25 14:50:35 2011 From: nick at flhsi.com (Nick Olsen) Date: Tue, 25 Jan 2011 15:50:35 -0500 Subject: Network Naming Message-ID: <7aeb7ba0$10caab2c$7a5700bb$@com> Whats the rule of thumb for naming gear these days (routers,switches...etc). Or is there one? looks like level3 does something like interface.routertype.location.level3.net Nick Olsen Network Operations (855) FLSPEED x106 From sethm at rollernet.us Tue Jan 25 15:10:04 2011 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 25 Jan 2011 13:10:04 -0800 Subject: Another v6 question In-Reply-To: <AANLkTikEZVYFz+bx7MVXeht_qNnpkUEC_Mx0qhE6J9SR@mail.gmail.com> References: <AANLkTikEZVYFz+bx7MVXeht_qNnpkUEC_Mx0qhE6J9SR@mail.gmail.com> Message-ID: <4D3F3C2C.108@rollernet.us> On 1/25/2011 10:19, Max Pierson wrote: > >>From the provider perspective, what is the prefix-length that most are > accepting to be injected into your tables?? 2 or so years ago, I read where > someone stated that they were told by ATT that they weren't planning on > accepting anything smaller than a /32. So what if I get my shiny new /48 > from ARIN and am already multi-homed??? Does ATT not want my business (which > they wouldn't get if the first place, but for argument sake, yes, I chose to > pick on ATT, sorry if I offended anyone :) I already see /40's /48's ,etc > in the v6 table, so some folks are allowing /48 and smaller, so what is the > new /24 in v6? > > I only ask due to the fact that ARIN's policy for end-users is /48 minimum > (which is what i've been telling folks to apply for or applying for it on > behalf of them). > Almost everyone of consequence accepts a /48. Verizon last year was very firm at /32, but I've heard they recently changed their mind. Verizon gave up on trying to get IPv6 to me before this and closed the account after a calendar year's worth of attempts. I replaced them with Global Crossing who got it right on the first try. These days a provider that only accepts a /32 or shorter is the exception, not the rule. ~Seth From caldcv at gmail.com Tue Jan 25 15:11:46 2011 From: caldcv at gmail.com (Christopher) Date: Tue, 25 Jan 2011 16:11:46 -0500 Subject: Network Naming In-Reply-To: <7aeb7ba0$10caab2c$7a5700bb$@com> References: <7aeb7ba0$10caab2c$7a5700bb$@com> Message-ID: <4D3F3C92.9050401@gmail.com> I usually name them after ex-girlfriends On 01/25/2011 03:50 PM, Nick Olsen wrote: > Whats the rule of thumb for naming gear these days > (routers,switches...etc). Or is there one? > > looks like level3 does something like > interface.routertype.location.level3.net > > Nick Olsen > Network Operations > (855) FLSPEED x106 > > > From jfbeam at gmail.com Tue Jan 25 15:17:59 2011 From: jfbeam at gmail.com (Ricky Beam) Date: Tue, 25 Jan 2011 16:17:59 -0500 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <8B0D83FB-38DD-4C4D-9870-5913425BA3A2@delong.com> References: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com> <AANLkTimcZavnJN2gqayS2-piDvOAcw_nrJAREJ0EDTjp@mail.gmail.com> <op.vpt734cxtfhldh@rbeam.xactional.com> <8B0D83FB-38DD-4C4D-9870-5913425BA3A2@delong.com> Message-ID: <op.vpvur91htfhldh@rbeam.xactional.com> On Mon, 24 Jan 2011 19:46:19 -0500, Owen DeLong <owen at delong.com> wrote: > Dude... In IPv6, there are 18,446,744,073,709,551,616 /64s. Those who don't learn from history are doomed to repeat it. "Dude, there are 256 /8 in IPv4." "640k ought to be enough for anyone." People can mismange anything into oblivion. IPv6 will end up the same mess IPv4 has become. (granted, it should take more than 30 years this time.) > The largest ISPs have thousands (not tens of thousands) of > point-to-point links. Having worked for small ISPs, I can count over 10k ptp links. That number goes way up when you count dialup and DSL. >>> You should think of IPv6 as a 64-bit address that happens to include a >>> 64-bit host identifier. >> >> No, you should not. That underminds the fundamental concept of IPv6 >> being *classless*. And it will lead to idiots writing broken >> applications and protocols assuming that to be true. >> > True, but, in terms of deploying networks, unless you have a really good > reason not to, it is best to use /64 for all segments. Again, the only reason for this /64 class boundry is SLAAC. The network is still 128 bits; you still have to pay attention to ALL of those bits. (Remember, SLAAC started out as a /80.) > Blindly, no. However, it's not impractical to implement fast path > switching that > handles things on /64s and push anything that requires something else > to the slow path. Any router that does CPU switching is already trash. High speed, low latency routing and switches is done in silicon (fpga's); it is not hoised to a general purpose CPU. For consumer devices, (almost) everything is done by the CPU to make it cheap. (some actually have tiny single chip switches in there.) --Ricky From owen at delong.com Tue Jan 25 15:15:35 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 25 Jan 2011 13:15:35 -0800 Subject: Another v6 question In-Reply-To: <20110125200347.GA23860@vacation.karoshi.com.> References: <AANLkTikEZVYFz+bx7MVXeht_qNnpkUEC_Mx0qhE6J9SR@mail.gmail.com> <55E7EC47-C434-4DF7-B92A-8EBC24133C53@delong.com> <20110125200347.GA23860@vacation.karoshi.com.> Message-ID: <C3CA8E6B-DC91-4A44-8343-236549A58AC2@delong.com> On Jan 25, 2011, at 12:03 PM, bmanning at vacation.karoshi.com wrote: >>> Second, as I was crunching a few numbers to get a rough estimate of what a >>> global table would look like in say 3 or 5 years after v4 is exhausted (I >>> understand that it's completely unpredictable to do this, but curiosity >>> killed the cat I guess), and in a few cases, I stopped due to the shear size >>> of the amount of prefixes I was coming with. Where i'm getting with this is >>> has anyone done any crunching on prefix count for v6 (as in estimates of >>> global table usage with the various prefix lengths seen above _based_ on the >>> initial allocation of the v6 space (not the entire v6 space itself)). I'm >> >> You really can't map prefix availability to prefix usage. > > this is so true. and yet you proceed, in your next few sentences > to do -exactly- that. :) > Not really... >> There are 4 billion IPv4 /32s. There aren't 4 billion LIRs that will get /32s. > > presuming the LIR model holds... > Whatever. >> There are 256 trillion IPv4 /48s (roughly). There are not 256 trillion >> end sites that will apply for /48s. > > apply to whom? the RIR/LIR model is not the only place/venue > for getting a /48. > To whomever they are getting their addresses from. It's irrelevant to the purposes of the discussion. The point was to show the total amount of supply vastly exceeds any rational perception of demand. >> The whole point of IPv6 is that the number of prefixes vastly exceeds >> the number of applicants that will use them. > > not sure I buy that arguement. > OK, maybe not the whole point, but, certainly the primary reason for widespread IPv6 adoption is going to be to eliminate the shortage of IP addresses present in IPv4. >> To measure the likely content of the IPv6 global table, then, we need >> to look at the number and type of users rather than looking at the >> maximum available number of prefixes. > > if there is a global table that is interesting (debatable point) > then I'd be more interested in curn rates and overlapping announcements. > Whatever. The point is that to predict the likely size of such a table, presuming it continues to exist, one must consider the size and type of prefixes that will be in it rather than considering the maximum possible size based on available prefixes. Owen From jfbeam at gmail.com Tue Jan 25 15:32:59 2011 From: jfbeam at gmail.com (Ricky Beam) Date: Tue, 25 Jan 2011 16:32:59 -0500 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <58166C50-0B72-43A0-8AB8-25E803EA1619@delong.com> References: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com> <AANLkTimcZavnJN2gqayS2-piDvOAcw_nrJAREJ0EDTjp@mail.gmail.com> <AANLkTikHBb+cyfPxXftb5QZh136D04fkdWFMy3NFhDdi@mail.gmail.com> <4D3F0144.70107@sohonet.co.uk> <58166C50-0B72-43A0-8AB8-25E803EA1619@delong.com> Message-ID: <op.vpvvg9hvtfhldh@rbeam.xactional.com> On Tue, 25 Jan 2011 13:42:29 -0500, Owen DeLong <owen at delong.com> wrote: > Seriously? Repetitively sweeping a /64? Let's do the math... ... We've had this discussion before... If the site is using SLAAC, then that 64bit target is effectively 48bits. And I can make a reasonable guess at 24 of those bits. (esp. if I've seen the address of even one of the machines.) --Ricky From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Tue Jan 25 15:42:51 2011 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Wed, 26 Jan 2011 08:12:51 +1030 Subject: Another v6 question In-Reply-To: <AANLkTikEZVYFz+bx7MVXeht_qNnpkUEC_Mx0qhE6J9SR@mail.gmail.com> References: <AANLkTikEZVYFz+bx7MVXeht_qNnpkUEC_Mx0qhE6J9SR@mail.gmail.com> Message-ID: <20110126081251.7e733f75@opy.nosense.org> On Tue, 25 Jan 2011 12:19:34 -0600 Max Pierson <nmaxpierson at gmail.com> wrote: > Hi List, > > Sorry to bring up yet ANOTHER v6 question/topic, but this seems to be one > that I cannot get a solid answer on (and probably won't and in the event > that I do, it will probably change down the road anyways), but here goes. > You could try the ipv6-ops mailing list, it is a bit more topic specific to what you're asking about. http://lists.cluenet.de/mailman/listinfo/ipv6-ops > TIA, > Max From nmaxpierson at gmail.com Tue Jan 25 15:43:01 2011 From: nmaxpierson at gmail.com (Max Pierson) Date: Tue, 25 Jan 2011 15:43:01 -0600 Subject: Another v6 question In-Reply-To: <55E7EC47-C434-4DF7-B92A-8EBC24133C53@delong.com> References: <AANLkTikEZVYFz+bx7MVXeht_qNnpkUEC_Mx0qhE6J9SR@mail.gmail.com> <55E7EC47-C434-4DF7-B92A-8EBC24133C53@delong.com> Message-ID: <AANLkTi=soS+LQoR3JYJxE8N3o9JYoxrL2dvzHZ+e5Geb@mail.gmail.com> Great reply's on and off-list so far. To hit on a few points ... Owen, thank you for catching my terminology blunder there. I understand smaller is != shorter. Complete mistake :) Glad to see most have loosened that policy, as I figured it wouldn't hold at the time I originally heard it 2 or so years ago. >You really can't map prefix availability to prefix usage. >There are 4 billion IPv4 /32s. There aren't 4 billion LIRs that will get /32s. I wasn't exactly mapping prefix availability to usage, apologies if it came across like that. My crunching did not include host bits. I understand I won't see /64's from each of my neighbors down the street. (or I shouldn't anyways). >As to the IPv4 de-agg, I think that's going to be one of the primary causes for >an accelerated deprecation of IPv4 once IPv6 starts to become more >ubiquitous. I would agree from a SP perspective, however from and end-user and enterprise perspective, most don't care about table sizes and will be slow to move to v6 until "everyone else is doing it" ... (as in they have to now because their facebook status won't be offered over v4 anymore). Alot of organizations I've spoken with still don't know what v6 even is. I think alot of end-user land and even some enterprises will drag their feet on this as long as it costs money for hardware upgrade to support v6, also having staff to support v6, legacy v4 apps that won't be ported to v6, etc. (I understand there's ways around this, my point is the customer doesn't). I think v4 will be around longer than we want it to (unfortunately), but time will tell. To Jusin's point, I agree that we will be net-negative for a while. My concerns is trying to dual-stack a v4 table and a v6 table. They both will grow over time, and until the powers that be "pull the plug" on re-issuing returned v4 space (which I completely disagree with), it'll continue that way. That's just my opinion though :) Once again, thanks for all on and off list responses! Max On Tue, Jan 25, 2011 at 1:46 PM, Owen DeLong <owen at delong.com> wrote: > > On Jan 25, 2011, at 10:19 AM, Max Pierson wrote: > > > Hi List, > > > > Sorry to bring up yet ANOTHER v6 question/topic, but this seems to be one > > that I cannot get a solid answer on (and probably won't and in the event > > that I do, it will probably change down the road anyways), but here goes. > > > >> From the provider perspective, what is the prefix-length that most are > > accepting to be injected into your tables?? 2 or so years ago, I read > where > > someone stated that they were told by ATT that they weren't planning on > > accepting anything smaller than a /32. So what if I get my shiny new /48 > > from ARIN and am already multi-homed??? Does ATT not want my business > (which > > they wouldn't get if the first place, but for argument sake, yes, I chose > to > > pick on ATT, sorry if I offended anyone :) I already see /40's /48's > ,etc > > in the v6 table, so some folks are allowing /48 and smaller, so what is > the > > new /24 in v6? > > > Today, the vast majority of providers are accepting /48s in IPv6. > > Verizon was holding the line at /32 for a while, but, they moved to /48 > a few months ago. > > Let's be clear on terminology. I don't think anyone is allowing smaller > than /48, but, most are allowing /48 and shorter. (shorter prefix = > bigger network). > > > I only ask due to the fact that ARIN's policy for end-users is /48 > minimum > > (which is what i've been telling folks to apply for or applying for it on > > behalf of them). > > > That's correct. > > > Second, as I was crunching a few numbers to get a rough estimate of what > a > > global table would look like in say 3 or 5 years after v4 is exhausted (I > > understand that it's completely unpredictable to do this, but curiosity > > killed the cat I guess), and in a few cases, I stopped due to the shear > size > > of the amount of prefixes I was coming with. Where i'm getting with this > is > > has anyone done any crunching on prefix count for v6 (as in estimates of > > global table usage with the various prefix lengths seen above _based_ on > the > > initial allocation of the v6 space (not the entire v6 space itself)). I'm > > You really can't map prefix availability to prefix usage. > > There are 4 billion IPv4 /32s. There aren't 4 billion LIRs that will get > /32s. > > There are 256 trillion IPv4 /48s (roughly). There are not 256 trillion > end sites that will apply for /48s. > > The whole point of IPv6 is that the number of prefixes vastly exceeds > the number of applicants that will use them. > > To measure the likely content of the IPv6 global table, then, we need > to look at the number and type of users rather than looking at the > maximum available number of prefixes. > > I haven't had trouble reaching anything I care about from my /48 > advertised through Hurricane Electric and Layer 42. > > > interested to see how long before we have 96Gb's of TCAM/Memory (take you > > vendor of choice) in our routers just to take a full table. (Not to > mention > > still having all of the ipv4 de-agg crazyness going on today. Seriously, > who > > lets /28 and /32's in their tables today? And this will only get worse as > v4 > > fades away). > > > Yeah, that's not likely to happen. TCAM doesn't scale that way. As to the > IPv4 de-agg, I think that's going to be one of the primary causes for > an accelerated deprecation of IPv4 once IPv6 starts to become more > ubiquitous. > > Owen > > From rcarpen at network1.net Tue Jan 25 15:43:32 2011 From: rcarpen at network1.net (Randy Carpenter) Date: Tue, 25 Jan 2011 16:43:32 -0500 (EST) Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <op.vpvvg9hvtfhldh@rbeam.xactional.com> Message-ID: <907353191.5867.1295991812314.JavaMail.root@zimbra.network1.net> ----- Original Message ----- > On Tue, 25 Jan 2011 13:42:29 -0500, Owen DeLong <owen at delong.com> > wrote: > > Seriously? Repetitively sweeping a /64? Let's do the math... > ... > > We've had this discussion before... > > If the site is using SLAAC, then that 64bit target is effectively > 48bits. > And I can make a reasonable guess at 24 of those bits. (esp. if I've > seen > the address of even one of the machines.) I wouldn't say you could assume that because one machine is a particular manufacturer, that they are all the same. I would say you could certainly limit a scan to a set list of well-known 24-bit IDs (say ~100 or so?), that would still take a couple days at least to scan. Could there not be something implemented in the firewall to prevent an incoming scan causing an issue with ND ? If you block all incoming by default, why would the router try to do a ND on an address that is not allowed? -Randy From marka at isc.org Tue Jan 25 15:57:16 2011 From: marka at isc.org (Mark Andrews) Date: Wed, 26 Jan 2011 08:57:16 +1100 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: Your message of "Tue, 25 Jan 2011 16:17:59 CDT." <op.vpvur91htfhldh@rbeam.xactional.com> References: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com> <AANLkTimcZavnJN2gqayS2-piDvOAcw_nrJAREJ0EDTjp@mail.gmail.com> <op.vpt734cxtfhldh@rbeam.xactional.com> <8B0D83FB-38DD-4C4D-9870-5913425BA3A2@delong.com><op.vpvur91htfhldh@rbeam.xactional.com> Message-ID: <20110125215716.40B519281EE@drugs.dv.isc.org> In message <op.vpvur91htfhldh at rbeam.xactional.com>, "Ricky Beam" writes: > On Mon, 24 Jan 2011 19:46:19 -0500, Owen DeLong <owen at delong.com> wrote: > > Dude... In IPv6, there are 18,446,744,073,709,551,616 /64s. > > Those who don't learn from history are doomed to repeat it. > > "Dude, there are 256 /8 in IPv4." > > "640k ought to be enough for anyone." And there was a time that IPv6 address might have been 64 bits in length and rather than having to managed 64 bits of addressing like we were managing IPv4 (smallest sized networks that would do the job) it was decided to double the address length and just manage networks and their aggregation rather than networks and their sizes. That was a deliberate decision. We are still packing networks reasonable densely especially anything /48 or shorter. > People can mismange anything into oblivion. IPv6 will end up the same > mess IPv4 has become. (granted, it should take more than 30 years this > time.) > > > The largest ISPs have thousands (not tens of thousands) of > > point-to-point links. > > Having worked for small ISPs, I can count over 10k ptp links. That number > goes way up when you count dialup and DSL. > > >>> You should think of IPv6 as a 64-bit address that happens to include a > >>> 64-bit host identifier. > >> > >> No, you should not. That underminds the fundamental concept of IPv6 > >> being *classless*. And it will lead to idiots writing broken > >> applications and protocols assuming that to be true. > >> > > True, but, in terms of deploying networks, unless you have a really good > > reason not to, it is best to use /64 for all segments. > > Again, the only reason for this /64 class boundry is SLAAC. The network > is still 128 bits; you still have to pay attention to ALL of those bits. > > (Remember, SLAAC started out as a /80.) > > > Blindly, no. However, it's not impractical to implement fast path > > switching that > > handles things on /64s and push anything that requires something else > > to the slow path. > > Any router that does CPU switching is already trash. High speed, low > latency routing and switches is done in silicon (fpga's); it is not hoised > to a general purpose CPU. > > For consumer devices, (almost) everything is done by the CPU to make it > cheap. (some actually have tiny single chip switches in there.) > > --Ricky > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From graham at g-rock.net Tue Jan 25 16:02:55 2011 From: graham at g-rock.net (=?utf-8?B?R1AgV29vZGVu?=) Date: Tue, 25 Jan 2011 16:02:55 -0600 Subject: =?utf-8?B?UmU6IE5ldHdvcmsgTmFtaW5n?= Message-ID: <20110125220343.08AEDFF806D@sociald.mobis.leasedminds.com> Punk bands here .... ----- Reply message ----- From: "Christopher" <caldcv at gmail.com> Date: Tue, Jan 25, 2011 3:11 pm Subject: Network Naming To: <nanog at nanog.org> I usually name them after ex-girlfriends On 01/25/2011 03:50 PM, Nick Olsen wrote: > Whats the rule of thumb for naming gear these days > (routers,switches...etc). Or is there one? > > looks like level3 does something like > interface.routertype.location.level3.net > > Nick Olsen > Network Operations > (855) FLSPEED x106 > > > From Valdis.Kletnieks at vt.edu Tue Jan 25 16:07:16 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 25 Jan 2011 17:07:16 -0500 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: Your message of "Tue, 25 Jan 2011 16:17:59 EST." <op.vpvur91htfhldh@rbeam.xactional.com> References: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com> <AANLkTimcZavnJN2gqayS2-piDvOAcw_nrJAREJ0EDTjp@mail.gmail.com> <op.vpt734cxtfhldh@rbeam.xactional.com> <8B0D83FB-38DD-4C4D-9870-5913425BA3A2@delong.com> <op.vpvur91htfhldh@rbeam.xactional.com> Message-ID: <63907.1295993236@localhost> On Tue, 25 Jan 2011 16:17:59 EST, Ricky Beam said: > On Mon, 24 Jan 2011 19:46:19 -0500, Owen DeLong <owen at delong.com> wrote: > > Dude... In IPv6, there are 18,446,744,073,709,551,616 /64s. > > Those who don't learn from history are doomed to repeat it. > > "Dude, there are 256 /8 in IPv4." > > "640k ought to be enough for anyone." > > People can mismange anything into oblivion. IPv6 will end up the same > mess IPv4 has become. (granted, it should take more than 30 years this > time.) To burn through all the /48s in 100 years, we'll have to use them up at the rate of 89,255 *per second*. That implies either *really* good aggregation, or your routers having enough CPU to handle the BGP churn caused by 90K new prefixes arriving on the Internet per second. Oh, and hot-pluggable memory, you'll need another terabyte of RAM every few hours. At that point, running out of prefixes is the *least* of your worries. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110125/bf49cc35/attachment.bin> From owen at delong.com Tue Jan 25 16:06:18 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 25 Jan 2011 14:06:18 -0800 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <op.vpvur91htfhldh@rbeam.xactional.com> References: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com> <AANLkTimcZavnJN2gqayS2-piDvOAcw_nrJAREJ0EDTjp@mail.gmail.com> <op.vpt734cxtfhldh@rbeam.xactional.com> <8B0D83FB-38DD-4C4D-9870-5913425BA3A2@delong.com> <op.vpvur91htfhldh@rbeam.xactional.com> Message-ID: <7E182DF5-9FBC-4C30-BDCD-AE5D88CF2368@delong.com> On Jan 25, 2011, at 1:17 PM, Ricky Beam wrote: > On Mon, 24 Jan 2011 19:46:19 -0500, Owen DeLong <owen at delong.com> wrote: >> Dude... In IPv6, there are 18,446,744,073,709,551,616 /64s. > > Those who don't learn from history are doomed to repeat it. > Correct, but... > "Dude, there are 256 /8 in IPv4." > There still are. The difference is that at the time that was said, there were 60 odd organizations that were expecting to connect to the internet and growth wasn't expected to exceed ~100. Today, there are billions of organizations, but, growth isn't expected to hit a trillion. As such, I think 281,474,976,710,656 (more than 281 trillion)/48s will cover it for longer than IPv6 will remain a viable protocol. > "640k ought to be enough for anyone." > If IPv4 is like 640k, then, IPv6 is like having 47,223,664,828,696,452,136,959 terabytes of RAM. I'd argue that while 640k was short sighted, I think it is unlikely we will see machines with much more than a terabyte of RAM in the lifetime of IPv6. > People can mismange anything into oblivion. IPv6 will end up the same mess IPv4 has become. (granted, it should take more than 30 years this time.) > IPv4 is not a mess. IPv4 was not mismanaged in my opinion. IPv4 was properly managed to the best use of the purposes intended at the time. The uses evolved. The management evolved. We have now reached the end of the ability to evolve the management enough to continue to meet the new uses. As a result, we're now deploying IPv6. IPv6 has learned from the history of IPv4 and instead of having enough addresses for all anticipated needs, it has enough addresses to build any conceivable form of network well beyond the size of what can be expected to function within the bounds of the protocol. >> The largest ISPs have thousands (not tens of thousands) of point-to-point links. > > Having worked for small ISPs, I can count over 10k ptp links. That number goes way up when you count dialup and DSL. > Most people don't implement DSL as point to point. Usually, instead, it is done as a point to multipoint addressing structure. Using a /64 per DSLAM is not an issue. Can you still count over 10k point to point links if you just look at the ones that need to be numbered? 8,192 /30s is a /15 of address space. That's not a small provider by almost anyone's definition of the term small. >>>> You should think of IPv6 as a 64-bit address that happens to include a >>>> 64-bit host identifier. >>> >>> No, you should not. That underminds the fundamental concept of IPv6 being *classless*. And it will lead to idiots writing broken applications and protocols assuming that to be true. >>> >> True, but, in terms of deploying networks, unless you have a really good >> reason not to, it is best to use /64 for all segments. > > Again, the only reason for this /64 class boundry is SLAAC. The network is still 128 bits; you still have to pay attention to ALL of those bits. > > (Remember, SLAAC started out as a /80.) > So? >> Blindly, no. However, it's not impractical to implement fast path switching that >> handles things on /64s and push anything that requires something else >> to the slow path. > > Any router that does CPU switching is already trash. High speed, low latency routing and switches is done in silicon (fpga's); it is not hoised to a general purpose CPU. > Depends on the application. If you're talking core backbone, sure. If you're talking workgroup switch/router, then, it's a different story. The number of running quagga boxes present in the internet and the number of deployed Juniper J-Series and SRX-series platforms would seem to prove your statement wrong. Owen From owen at delong.com Tue Jan 25 16:17:39 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 25 Jan 2011 14:17:39 -0800 Subject: Another v6 question In-Reply-To: <AANLkTi=soS+LQoR3JYJxE8N3o9JYoxrL2dvzHZ+e5Geb@mail.gmail.com> References: <AANLkTikEZVYFz+bx7MVXeht_qNnpkUEC_Mx0qhE6J9SR@mail.gmail.com> <55E7EC47-C434-4DF7-B92A-8EBC24133C53@delong.com> <AANLkTi=soS+LQoR3JYJxE8N3o9JYoxrL2dvzHZ+e5Geb@mail.gmail.com> Message-ID: <4F209412-3C3B-4CB6-8EB7-A25ABD1B9DBA@delong.com> On Jan 25, 2011, at 1:43 PM, Max Pierson wrote: > Great reply's on and off-list so far. > > To hit on a few points ... > > Owen, thank you for catching my terminology blunder there. I understand smaller is != shorter. Complete mistake :) > > Glad to see most have loosened that policy, as I figured it wouldn't hold at the time I originally heard it 2 or so years ago. > > >You really can't map prefix availability to prefix usage. > >There are 4 billion IPv4 /32s. There aren't 4 billion LIRs that will get /32s. > > I wasn't exactly mapping prefix availability to usage, apologies if it came across like that. My crunching did not include host bits. I understand I won't see /64's from each of my neighbors down the street. (or I shouldn't anyways). > I think you may still be missing my point... There are way more /48s available than will ever get used. There are way more /32s available than will ever get used. You need to look at the actual number of likely unaggregated sites and the number of ISPs. The sum of those numbers with some multiplier probably in the 2.5 range is probably about as close as you can get to an anticipated routing table size. That will be much smaller than then numbers you get if you crunch the number of available /48s. > >As to the IPv4 de-agg, I think that's going to be one of the primary causes for > >an accelerated deprecation of IPv4 once IPv6 starts to become more > >ubiquitous. > > I would agree from a SP perspective, however from and end-user and enterprise perspective, most don't care about table sizes and will be slow to move to v6 until "everyone else is doing it" ... (as in they have to now because their facebook status won't be offered over v4 anymore). Alot of organizations I've spoken with still don't know what v6 even is. I think alot of end-user land and even some enterprises will drag their feet on this as long as it costs money for hardware upgrade to support v6, also having staff to support v6, legacy v4 apps that won't be ported to v6, etc. (I understand there's ways around this, my point is the customer doesn't). I think v4 will be around longer than we want it to (unfortunately), but time will tell. > They will start to care when their ISP starts charging them for every prefix they inject. If you don't think that IPv4 deagg will lead to an IPv4 prefix injection charge once IPv6 is more widely deployed, think again. > To Jusin's point, > I agree that we will be net-negative for a while. My concerns is trying to dual-stack a v4 table and a v6 table. They both will grow over time, and until the powers that be "pull the plug" on re-issuing returned v4 space (which I completely disagree with), it'll continue that way. That's just my opinion though :) > I don't think IPv4 will continue to grow for all that long. I think the plug will get pulled by ISPs desperate to reduce the spiraling costs of continuing to support IPv4. When it starts becoming increasingly expensive to get ISPs to provide IPv4 services, the rest of the internet will begin to move rapidly away from IPv4. I anticipate this will take about 5-10 years after IPv4 runout at ARIN/APNIC/RIPE (which will be nearly simultaneous). Owen > Once again, thanks for all on and off list responses! > Max > > > On Tue, Jan 25, 2011 at 1:46 PM, Owen DeLong <owen at delong.com> wrote: > > On Jan 25, 2011, at 10:19 AM, Max Pierson wrote: > > > Hi List, > > > > Sorry to bring up yet ANOTHER v6 question/topic, but this seems to be one > > that I cannot get a solid answer on (and probably won't and in the event > > that I do, it will probably change down the road anyways), but here goes. > > > >> From the provider perspective, what is the prefix-length that most are > > accepting to be injected into your tables?? 2 or so years ago, I read where > > someone stated that they were told by ATT that they weren't planning on > > accepting anything smaller than a /32. So what if I get my shiny new /48 > > from ARIN and am already multi-homed??? Does ATT not want my business (which > > they wouldn't get if the first place, but for argument sake, yes, I chose to > > pick on ATT, sorry if I offended anyone :) I already see /40's /48's ,etc > > in the v6 table, so some folks are allowing /48 and smaller, so what is the > > new /24 in v6? > > > Today, the vast majority of providers are accepting /48s in IPv6. > > Verizon was holding the line at /32 for a while, but, they moved to /48 > a few months ago. > > Let's be clear on terminology. I don't think anyone is allowing smaller > than /48, but, most are allowing /48 and shorter. (shorter prefix = > bigger network). > > > I only ask due to the fact that ARIN's policy for end-users is /48 minimum > > (which is what i've been telling folks to apply for or applying for it on > > behalf of them). > > > That's correct. > > > Second, as I was crunching a few numbers to get a rough estimate of what a > > global table would look like in say 3 or 5 years after v4 is exhausted (I > > understand that it's completely unpredictable to do this, but curiosity > > killed the cat I guess), and in a few cases, I stopped due to the shear size > > of the amount of prefixes I was coming with. Where i'm getting with this is > > has anyone done any crunching on prefix count for v6 (as in estimates of > > global table usage with the various prefix lengths seen above _based_ on the > > initial allocation of the v6 space (not the entire v6 space itself)). I'm > > You really can't map prefix availability to prefix usage. > > There are 4 billion IPv4 /32s. There aren't 4 billion LIRs that will get /32s. > > There are 256 trillion IPv4 /48s (roughly). There are not 256 trillion > end sites that will apply for /48s. > > The whole point of IPv6 is that the number of prefixes vastly exceeds > the number of applicants that will use them. > > To measure the likely content of the IPv6 global table, then, we need > to look at the number and type of users rather than looking at the > maximum available number of prefixes. > > I haven't had trouble reaching anything I care about from my /48 > advertised through Hurricane Electric and Layer 42. > > > interested to see how long before we have 96Gb's of TCAM/Memory (take you > > vendor of choice) in our routers just to take a full table. (Not to mention > > still having all of the ipv4 de-agg crazyness going on today. Seriously, who > > lets /28 and /32's in their tables today? And this will only get worse as v4 > > fades away). > > > Yeah, that's not likely to happen. TCAM doesn't scale that way. As to the > IPv4 de-agg, I think that's going to be one of the primary causes for > an accelerated deprecation of IPv4 once IPv6 starts to become more > ubiquitous. > > Owen > > From bicknell at ufp.org Tue Jan 25 16:21:12 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 25 Jan 2011 14:21:12 -0800 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <63907.1295993236@localhost> References: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com> <AANLkTimcZavnJN2gqayS2-piDvOAcw_nrJAREJ0EDTjp@mail.gmail.com> <op.vpt734cxtfhldh@rbeam.xactional.com> <8B0D83FB-38DD-4C4D-9870-5913425BA3A2@delong.com> <op.vpvur91htfhldh@rbeam.xactional.com> <63907.1295993236@localhost> Message-ID: <20110125222112.GA88462@ussenterprise.ufp.org> In a message written on Tue, Jan 25, 2011 at 05:07:16PM -0500, Valdis.Kletnieks at vt.edu wrote: > To burn through all the /48s in 100 years, we'll have to use them up > at the rate of 89,255 *per second*. > > That implies either *really* good aggregation, or your routers having enough > CPU to handle the BGP churn caused by 90K new prefixes arriving on the Internet > per second. Oh, and hot-pluggable memory, you'll need another terabyte of RAM > every few hours. At that point, running out of prefixes is the *least* of your > worries. If you were allocating individual /48's, perhaps. But see, I'm a cable company, and I want a /48 per customer, and I have a couple of hundred thousand per pop, so I need a /30 per pop. Oh, and I have a few hundred pops, and I need to be able to aggreate regionally, so I need a /24. By my calculations I just used 16M /48's and I did it in about 60 seconds to write a paragraph. That's about 279,620 per second, so I'm well above your rate. To be serious for a moment, the problem isn't that we don't have enough /48's, but that humans are really bad at thinking about these big numbers. We're going from a very constrained world with limited aggregation (IPv4) to a world that seems very unconstrained, and building in a lot of aggregation. Remember the very first IPv6 addressing proposals had a fully structured address space and only 4096 ISP's at the top of the chain! If we aggregate poorly, we can absolutely blow through all the space, stranding it in all sorts of new and interesting ways. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110125/8d1ab26b/attachment.bin> From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Tue Jan 25 16:27:38 2011 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Wed, 26 Jan 2011 08:57:38 +1030 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <op.vpvvg9hvtfhldh@rbeam.xactional.com> References: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com> <AANLkTimcZavnJN2gqayS2-piDvOAcw_nrJAREJ0EDTjp@mail.gmail.com> <AANLkTikHBb+cyfPxXftb5QZh136D04fkdWFMy3NFhDdi@mail.gmail.com> <4D3F0144.70107@sohonet.co.uk> <58166C50-0B72-43A0-8AB8-25E803EA1619@delong.com> <op.vpvvg9hvtfhldh@rbeam.xactional.com> Message-ID: <20110126085738.71c58385@opy.nosense.org> On Tue, 25 Jan 2011 16:32:59 -0500 "Ricky Beam" <jfbeam at gmail.com> wrote: > On Tue, 25 Jan 2011 13:42:29 -0500, Owen DeLong <owen at delong.com> wrote: > > Seriously? Repetitively sweeping a /64? Let's do the math... > ... > > We've had this discussion before... > > If the site is using SLAAC, then that 64bit target is effectively 48bits. > And I can make a reasonable guess at 24 of those bits. (esp. if I've seen > the address of even one of the machines.) > All you're really pointing out is "security" is a relative term. A lot of these threads devolve in to a waste of time because they're discussing the pros and cons of a single, possible security mechanism without considering it in context ("possible" because if it ends up having no or very little security value it isn't really a "security mechanism" at all). The value of a security mechanism can only be judged in the context of both what threats they mitigate and whether those threats are ones that are common and likely in the context they might be used in. Security is a weakest link problem, so the first thing that needs to be done is to identify the weakest links, before worrying about how to fix them. So what threat are people trying to prevent? Address scanning is only a means to an end - so what is the "end"? Only once that is defined can it be worked out whether address scanning is a likely method attackers will use, and whether then preventing address scanning is an effective mitigation. Regards, Mark. From owen at delong.com Tue Jan 25 16:28:03 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 25 Jan 2011 14:28:03 -0800 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <20110125222112.GA88462@ussenterprise.ufp.org> References: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com> <AANLkTimcZavnJN2gqayS2-piDvOAcw_nrJAREJ0EDTjp@mail.gmail.com> <op.vpt734cxtfhldh@rbeam.xactional.com> <8B0D83FB-38DD-4C4D-9870-5913425BA3A2@delong.com> <op.vpvur91htfhldh@rbeam.xactional.com> <63907.1295993236@localhost> <20110125222112.GA88462@ussenterprise.ufp.org> Message-ID: <42DF2895-B11B-466A-9970-41534A3857A1@delong.com> On Jan 25, 2011, at 2:21 PM, Leo Bicknell wrote: > In a message written on Tue, Jan 25, 2011 at 05:07:16PM -0500, Valdis.Kletnieks at vt.edu wrote: >> To burn through all the /48s in 100 years, we'll have to use them up >> at the rate of 89,255 *per second*. >> >> That implies either *really* good aggregation, or your routers having enough >> CPU to handle the BGP churn caused by 90K new prefixes arriving on the Internet >> per second. Oh, and hot-pluggable memory, you'll need another terabyte of RAM >> every few hours. At that point, running out of prefixes is the *least* of your >> worries. > > If you were allocating individual /48's, perhaps. But see, I'm a > cable company, and I want a /48 per customer, and I have a couple > of hundred thousand per pop, so I need a /30 per pop. Oh, and I > have a few hundred pops, and I need to be able to aggreate regionally, > so I need a /24. > > By my calculations I just used 16M /48's and I did it in about 60 > seconds to write a paragraph. That's about 279,620 per second, so > I'm well above your rate. > How soon do you expect your $CABLECO to need to come back to the RIR for their next /24? That is the meaningful number. The fact that it took you 60 seconds to use a /24 to retrofit a network that was built over decades really isn't a useful measure of utilization rate. > To be serious for a moment, the problem isn't that we don't have > enough /48's, but that humans are really bad at thinking about these > big numbers. We're going from a very constrained world with limited > aggregation (IPv4) to a world that seems very unconstrained, and > building in a lot of aggregation. Remember the very first IPv6 > addressing proposals had a fully structured address space and only > 4096 ISP's at the top of the chain! > Yep... Proposal 121 is intended to help address this problem (the humans are bad at math and big numbers problem). > If we aggregate poorly, we can absolutely blow through all the space, > stranding it in all sorts of new and interesting ways. > We may or may not blow through the space, but, we certainly can easily render the space we do blow through useless. Owen From Valdis.Kletnieks at vt.edu Tue Jan 25 16:32:30 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 25 Jan 2011 17:32:30 -0500 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: Your message of "Tue, 25 Jan 2011 14:21:12 PST." <20110125222112.GA88462@ussenterprise.ufp.org> References: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com> <AANLkTimcZavnJN2gqayS2-piDvOAcw_nrJAREJ0EDTjp@mail.gmail.com> <op.vpt734cxtfhldh@rbeam.xactional.com> <8B0D83FB-38DD-4C4D-9870-5913425BA3A2@delong.com> <op.vpvur91htfhldh@rbeam.xactional.com> <63907.1295993236@localhost> <20110125222112.GA88462@ussenterprise.ufp.org> Message-ID: <65421.1295994750@localhost> On Tue, 25 Jan 2011 14:21:12 PST, Leo Bicknell said: > If you were allocating individual /48's, perhaps. But see, I'm a > cable company, and I want a /48 per customer, and I have a couple > of hundred thousand per pop, so I need a /30 per pop. Oh, and I > have a few hundred pops, and I need to be able to aggreate regionally, > so I need a /24. > > By my calculations I just used 16M /48's and I did it in about 60 > seconds to write a paragraph. That's about 279,620 per second, so > I'm well above your rate. Fine. You got ARIN or somebody to allocate your *first* /24 in under a minute. Now how long will it take you to actually *deploy* that many destinations? And where do you plan to get your customers for the next 4 or 5 /24's, and how long will *those* deploys take? Face it Leo, you can't *sustain* that growth rate. > building in a lot of aggregation. Remember the very first IPv6 > addressing proposals had a fully structured address space and only > 4096 ISP's at the top of the chain! How many Tier-1's are there now, even if you include all the wannabes? And how long would it take at current growth rates of Tier-1 status to run out the *other* 4,087 entries? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110125/7fe17849/attachment.bin> From james.cutler at consultant.com Tue Jan 25 16:41:26 2011 From: james.cutler at consultant.com (Cutler James R) Date: Tue, 25 Jan 2011 17:41:26 -0500 Subject: Network Naming In-Reply-To: <7aeb7ba0$10caab2c$7a5700bb$@com> References: <7aeb7ba0$10caab2c$7a5700bb$@com> Message-ID: <A584FE4D-62CF-4218-8D21-CF51628BDA76@consultant.com> On Jan 25, 2011, at 3:50 PM, Nick Olsen wrote: > Whats the rule of thumb for naming gear these days > (routers,switches...etc). Or is there one? Pick a scheme which: 1. Uses simple memorable names. 2. Makes business sense to you. 3. You know how to manage (database, publication, updates, etc. If I had to weight these criteria, I would weight 3 most heavily. James R. Cutler james.cutler at consultant.com From davidd at corp.nac.net Tue Jan 25 17:00:47 2011 From: davidd at corp.nac.net (David DiGiacomo) Date: Tue, 25 Jan 2011 18:00:47 -0500 Subject: Network Naming In-Reply-To: <7aeb7ba0$10caab2c$7a5700bb$@com> References: <7aeb7ba0$10caab2c$7a5700bb$@com> Message-ID: <2C357CA6-4198-45DB-B548-C98DA734C2CE@corp.nac.net> Nick, I do not believe there is a written standard for naming gear ( or at least I have never seen one) Most naming scheme's are usually something arbitrary RAS gave a pretty good tutorial on traceroutes once, specifically he covered the topic of interpreting DNS in a traceroute. I know we are not talking about traceroutes or DNS here but hopefully this can give you a little insight into naming your equipment. http://www.nanog.org/meetings/nanog45/presentations/Sunday/RAS_traceroute_N45.pdf On Jan 25, 2011, at 3:50 PM, Nick Olsen wrote: > Whats the rule of thumb for naming gear these days > (routers,switches...etc). Or is there one? > > looks like level3 does something like > interface.routertype.location.level3.net > > Nick Olsen > Network Operations > (855) FLSPEED x106 > > From owen at delong.com Tue Jan 25 17:26:29 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 25 Jan 2011 15:26:29 -0800 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <65421.1295994750@localhost> References: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com> <AANLkTimcZavnJN2gqayS2-piDvOAcw_nrJAREJ0EDTjp@mail.gmail.com> <op.vpt734cxtfhldh@rbeam.xactional.com> <8B0D83FB-38DD-4C4D-9870-5913425BA3A2@delong.com> <op.vpvur91htfhldh@rbeam.xactional.com> <63907.1295993236@localhost> <20110125222112.GA88462@ussenterprise.ufp.org> <65421.1295994750@localhost> Message-ID: <FCF6E6E9-60B8-4BFE-834A-A7D7EC3B483A@delong.com> On Jan 25, 2011, at 2:32 PM, Valdis.Kletnieks at vt.edu wrote: > On Tue, 25 Jan 2011 14:21:12 PST, Leo Bicknell said: > >> If you were allocating individual /48's, perhaps. But see, I'm a >> cable company, and I want a /48 per customer, and I have a couple >> of hundred thousand per pop, so I need a /30 per pop. Oh, and I >> have a few hundred pops, and I need to be able to aggreate regionally, >> so I need a /24. >> >> By my calculations I just used 16M /48's and I did it in about 60 >> seconds to write a paragraph. That's about 279,620 per second, so >> I'm well above your rate. > > Fine. You got ARIN or somebody to allocate your *first* /24 in under a minute. > Now how long will it take you to actually *deploy* that many destinations? And > where do you plan to get your customers for the next 4 or 5 /24's, and how long > will *those* deploys take? > > Face it Leo, you can't *sustain* that growth rate. > >> building in a lot of aggregation. Remember the very first IPv6 >> addressing proposals had a fully structured address space and only >> 4096 ISP's at the top of the chain! > > How many Tier-1's are there now, even if you include all the wannabes? > And how long would it take at current growth rates of Tier-1 status to run > out the *other* 4,087 entries? RIRs allocate to lots of non-Tier-1 organizations, so, that count is pretty meaningless no matter what definition of "tier 1" you decide to use. I suspect that there are probably somewhere between 30,000 and 120,000 ISPs world wide that are likely to end up with a /32 or shorter prefix. Owen From alh-ietf at tndh.net Tue Jan 25 18:20:27 2011 From: alh-ietf at tndh.net (Tony Hain) Date: Tue, 25 Jan 2011 16:20:27 -0800 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <FCF6E6E9-60B8-4BFE-834A-A7D7EC3B483A@delong.com> References: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com> <AANLkTimcZavnJN2gqayS2-piDvOAcw_nrJAREJ0EDTjp@mail.gmail.com> <op.vpt734cxtfhldh@rbeam.xactional.com> <8B0D83FB-38DD-4C4D-9870-5913425BA3A2@delong.com> <op.vpvur91htfhldh@rbeam.xactional.com> <63907.1295993236@localhost> <20110125222112.GA88462@ussenterprise.ufp.org> <65421.1295994750@localhost> <FCF6E6E9-60B8-4BFE-834A-A7D7EC3B483A@delong.com> Message-ID: <06ad01cbbcee$d91cc210$8b564630$@net> Owen DeLong wrote: > ...... > I suspect that there are probably somewhere between 30,000 > and 120,000 ISPs world wide that are likely to end up with a /32 > or shorter prefix. A /32 is the value that a start-up ISP would have. Assuming that there is a constant average rate of startups/failures per year, the number of /32's in the system should remain fairly constant over time. Every organization with a *real* customer base should have significantly shorter than a /32. In particular every organization that says "I can't give my customers prefix length X because I only have a /32" needs to go back to ARIN today and trade that in for a *real block*. There should be at least 10 organizations in the ARIN region that qualify for a /20 or shorter, and most would likely be /24 or shorter. As Owen said earlier, proposal 121 is intended to help people through the math. Please read the proposal, and even if you don't want to comment on the PPML list about it, take that useless /32 back to ARIN and get a *real block* today. Tony From paul at paulstewart.org Tue Jan 25 18:34:10 2011 From: paul at paulstewart.org (Paul Stewart) Date: Tue, 25 Jan 2011 19:34:10 -0500 Subject: PPPOE vs DHCP Message-ID: <051001cbbcf0$c33e8b20$49bba160$@org> Hey folks... I'm meeting with a customer tomorrow (service provider, rural telco) and we're pitching they move to a PPPOE platform most likely. But to be fair, I'm looking to draw up a comparison so they are "well informed" of the pros/cons. Has anyone done this? I came up with the following brief start: PPPOE vs DHCP PPPOE Pros ---------- Allows full authentication of customers (requires username/password) Allows control over customer connections (suspend accounts, create accounts etc) Easily assign static IP to customer (no MAC address or CPE information required) Assign public subnet to customer with ease (no manual routing required) IPv4/IPv6 fully supported on Juniper platform as required Usage tracking (GB transfer) from radius generated data PPPOE Cons ---------- Requires PPPOE termination router (Juniper ERX for example) Requires Radius server(s) to assign and track customer IP assignments/usage Customers require username/password to connect Customers require PPPOE client software or router to connect 8 bytes MTU overhead DHCP Pros --------- Simplistic - plug and play 90% of the time No MTU overhead, full 1500 MTU frame size DHCP Cons --------- No authentication occurs (anyone physically connected can use Internet generally) No user tracking without tracking customer CPE MAC addresses No usage tracking builtin to DHCP (GB transfer) There are several factors involved here. The first major thing is that we believe the customer wants to move towards caps on their customer usage (X amount of GB per month). Today, they are doing static IP assignments but the interesting thing is that the CPE they have control over today (Comtrend routers with DSL modem builtin). I know there's not always a good vs bad here but looking for opinions from folks who may have already done this comparison for a "boardroom discussion".... Thanks ;) Paul From nmaxpierson at gmail.com Tue Jan 25 17:35:02 2011 From: nmaxpierson at gmail.com (Max Pierson) Date: Tue, 25 Jan 2011 17:35:02 -0600 Subject: Another v6 question In-Reply-To: <4F209412-3C3B-4CB6-8EB7-A25ABD1B9DBA@delong.com> References: <AANLkTikEZVYFz+bx7MVXeht_qNnpkUEC_Mx0qhE6J9SR@mail.gmail.com> <55E7EC47-C434-4DF7-B92A-8EBC24133C53@delong.com> <AANLkTi=soS+LQoR3JYJxE8N3o9JYoxrL2dvzHZ+e5Geb@mail.gmail.com> <4F209412-3C3B-4CB6-8EB7-A25ABD1B9DBA@delong.com> Message-ID: <AANLkTinqipvQD-gSt1BZ5FcPT2krNhwqO5dExWrM=muG@mail.gmail.com> >I think you may still be missing my point... >There are way more /48s available than will ever get used. >There are way more /32s available than will ever get used. No, I think you're missing my point. Your statements above are of your opinion. The same opinion was said about v4 30 years ago which is why we are where we are today (again, opinions). Reality shows otherwise. In your opinion, IPv6 is it. We'll NEVER have to do this again. We'll never have to implement NAT (or some other translation protocol) again. We'll never have to worry about running out of space. If thats the case, then why are so many folks arguing over what to give to end users?? It doesn't matter by your opinion. Give em what they want!! There's no possible way we can use that many addresses. Lets get back to reality. No one, and i'll say it once more, NO ONE knows if v6 is the end all be all. (I would agree with you in regards of our lifetime we won't even use a drop in the bucket). It only took ~10 years to figure out they did it all wrong the first time around. Can you speak for the next 100 years, what about 200 years?? (Not that it matters to us anyway, we'll be long gone by then. But they way you put it is that this beast we're dealing with will never have to be revamped again. Future proof! To me, that line of thinking is a little short-sided). >They will start to care when their ISP starts charging them for every prefix they inject. If you don't think that IPv4 deagg will lead to an IPv4 prefix >injection charge once IPv6 is more widely deployed, think again. Some will care and adapt as we all hope they would, some will simply find another provider with v4 space to spare thats not charging. This won't stop until RIR/LIR's stop re-issuing v4 space. At that point, then the squeeze is on and I would imagine ALL ISP's will charge at that point because they're getting charged for having v4 space. >I don't think IPv4 will continue to grow for all that long. I think the plug will get pulled by ISPs desperate to reduce the spiraling costs of continuing to >support IPv4. When it starts becoming increasingly expensive to get ISPs to provide IPv4 services, the rest of the internet will begin to move rapidly >away from IPv4. >I anticipate this will take about 5-10 years after IPv4 runout at ARIN/APNIC/RIPE (which will be nearly simultaneous). I would agree to this as well, 5-10 years of weaning off v4 at that point is probably what we'll end up seeing, although I would say that 5-10 years in this industry is a relatively long time. Probably much longer than any of us want to see v4 stick around anyway. Max On Tue, Jan 25, 2011 at 4:17 PM, Owen DeLong <owen at delong.com> wrote: > > On Jan 25, 2011, at 1:43 PM, Max Pierson wrote: > > Great reply's on and off-list so far. > > To hit on a few points ... > > Owen, thank you for catching my terminology blunder there. I understand > smaller is != shorter. Complete mistake :) > > Glad to see most have loosened that policy, as I figured it wouldn't hold > at the time I originally heard it 2 or so years ago. > > >You really can't map prefix availability to prefix usage. > >There are 4 billion IPv4 /32s. There aren't 4 billion LIRs that will get > /32s. > > I wasn't exactly mapping prefix availability to usage, apologies if it came > across like that. My crunching did not include host bits. I understand I > won't see /64's from each of my neighbors down the street. (or I shouldn't > anyways). > > I think you may still be missing my point... > > There are way more /48s available than will ever get used. > There are way more /32s available than will ever get used. > > You need to look at the actual number of likely unaggregated sites > and the number of ISPs. The sum of those numbers with some multiplier > probably in the 2.5 range is probably about as close as you can get > to an anticipated routing table size. > > That will be much smaller than then numbers you get if you crunch > the number of available /48s. > > >As to the IPv4 de-agg, I think that's going to be one of the primary > causes for > >an accelerated deprecation of IPv4 once IPv6 starts to become more > >ubiquitous. > > I would agree from a SP perspective, however from and end-user and > enterprise perspective, most don't care about table sizes and will be slow > to move to v6 until "everyone else is doing it" ... (as in they have to now > because their facebook status won't be offered over v4 anymore). Alot > of organizations I've spoken with still don't know what v6 even is. I think > alot of end-user land and even some enterprises will drag their feet on this > as long as it costs money for hardware upgrade to support v6, also having > staff to support v6, legacy v4 apps that won't be ported to v6, etc. (I > understand there's ways around this, my point is the customer doesn't). I > think v4 will be around longer than we want it to (unfortunately), but time > will tell. > > They will start to care when their ISP starts charging them for every > prefix they inject. If you don't think that IPv4 deagg will lead to an IPv4 > prefix injection charge once IPv6 is more widely deployed, think again. > > To Jusin's point, > I agree that we will be net-negative for a while. My concerns is trying to > dual-stack a v4 table and a v6 table. They both will grow over time, and > until the powers that be "pull the plug" on re-issuing returned v4 space > (which I completely disagree with), it'll continue that way. That's just my > opinion though :) > > I don't think IPv4 will continue to grow for all that long. I think the > plug will get pulled by ISPs desperate to reduce the spiraling costs of > continuing to support IPv4. When it starts becoming increasingly expensive > to get ISPs to provide IPv4 services, the rest of the internet will begin to > move rapidly away from IPv4. > > I anticipate this will take about 5-10 years after IPv4 runout at > ARIN/APNIC/RIPE (which will be nearly simultaneous). > > Owen > > Once again, thanks for all on and off list responses! > Max > > > On Tue, Jan 25, 2011 at 1:46 PM, Owen DeLong <owen at delong.com> wrote: > >> >> On Jan 25, 2011, at 10:19 AM, Max Pierson wrote: >> >> > Hi List, >> > >> > Sorry to bring up yet ANOTHER v6 question/topic, but this seems to be >> one >> > that I cannot get a solid answer on (and probably won't and in the event >> > that I do, it will probably change down the road anyways), but here >> goes. >> > >> >> From the provider perspective, what is the prefix-length that most are >> > accepting to be injected into your tables?? 2 or so years ago, I read >> where >> > someone stated that they were told by ATT that they weren't planning on >> > accepting anything smaller than a /32. So what if I get my shiny new /48 >> > from ARIN and am already multi-homed??? Does ATT not want my business >> (which >> > they wouldn't get if the first place, but for argument sake, yes, I >> chose to >> > pick on ATT, sorry if I offended anyone :) I already see /40's /48's >> ,etc >> > in the v6 table, so some folks are allowing /48 and smaller, so what is >> the >> > new /24 in v6? >> > >> Today, the vast majority of providers are accepting /48s in IPv6. >> >> Verizon was holding the line at /32 for a while, but, they moved to /48 >> a few months ago. >> >> Let's be clear on terminology. I don't think anyone is allowing smaller >> than /48, but, most are allowing /48 and shorter. (shorter prefix = >> bigger network). >> >> > I only ask due to the fact that ARIN's policy for end-users is /48 >> minimum >> > (which is what i've been telling folks to apply for or applying for it >> on >> > behalf of them). >> > >> That's correct. >> >> > Second, as I was crunching a few numbers to get a rough estimate of what >> a >> > global table would look like in say 3 or 5 years after v4 is exhausted >> (I >> > understand that it's completely unpredictable to do this, but curiosity >> > killed the cat I guess), and in a few cases, I stopped due to the shear >> size >> > of the amount of prefixes I was coming with. Where i'm getting with this >> is >> > has anyone done any crunching on prefix count for v6 (as in estimates of >> > global table usage with the various prefix lengths seen above _based_ on >> the >> > initial allocation of the v6 space (not the entire v6 space itself)). >> I'm >> >> You really can't map prefix availability to prefix usage. >> >> There are 4 billion IPv4 /32s. There aren't 4 billion LIRs that will get >> /32s. >> >> There are 256 trillion IPv4 /48s (roughly). There are not 256 trillion >> end sites that will apply for /48s. >> >> The whole point of IPv6 is that the number of prefixes vastly exceeds >> the number of applicants that will use them. >> >> To measure the likely content of the IPv6 global table, then, we need >> to look at the number and type of users rather than looking at the >> maximum available number of prefixes. >> >> I haven't had trouble reaching anything I care about from my /48 >> advertised through Hurricane Electric and Layer 42. >> >> > interested to see how long before we have 96Gb's of TCAM/Memory (take >> you >> > vendor of choice) in our routers just to take a full table. (Not to >> mention >> > still having all of the ipv4 de-agg crazyness going on today. Seriously, >> who >> > lets /28 and /32's in their tables today? And this will only get worse >> as v4 >> > fades away). >> > >> Yeah, that's not likely to happen. TCAM doesn't scale that way. As to the >> IPv4 de-agg, I think that's going to be one of the primary causes for >> an accelerated deprecation of IPv4 once IPv6 starts to become more >> ubiquitous. >> >> Owen >> >> > > From owen at delong.com Tue Jan 25 18:57:46 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 25 Jan 2011 16:57:46 -0800 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <06ad01cbbcee$d91cc210$8b564630$@net> References: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com> <AANLkTimcZavnJN2gqayS2-piDvOAcw_nrJAREJ0EDTjp@mail.gmail.com> <op.vpt734cxtfhldh@rbeam.xactional.com> <8B0D83FB-38DD-4C4D-9870-5913425BA3A2@delong.com> <op.vpvur91htfhldh@rbeam.xactional.com> <63907.1295993236@localhost> <20110125222112.GA88462@ussenterprise.ufp.org> <65421.1295994750@localhost> <FCF6E6E9-60B8-4BFE-834A-A7D7EC3B483A@delong.com> <06ad01cbbcee$d91cc210$8b564630$@net> Message-ID: <4449218A-4864-4346-8B73-F8C75ECC1827@delong.com> On Jan 25, 2011, at 4:20 PM, Tony Hain wrote: > Owen DeLong wrote: >> ...... >> I suspect that there are probably somewhere between 30,000 >> and 120,000 ISPs world wide that are likely to end up with a /32 >> or shorter prefix. > > A /32 is the value that a start-up ISP would have. Assuming that there is a > constant average rate of startups/failures per year, the number of /32's in > the system should remain fairly constant over time. > > Every organization with a *real* customer base should have significantly > shorter than a /32. In particular every organization that says "I can't give > my customers prefix length X because I only have a /32" needs to go back to > ARIN today and trade that in for a *real block*. There should be at least 10 > organizations in the ARIN region that qualify for a /20 or shorter, and most > would likely be /24 or shorter. > > As Owen said earlier, proposal 121 is intended to help people through the > math. Please read the proposal, and even if you don't want to comment on the > PPML list about it, take that useless /32 back to ARIN and get a *real > block* today. > > Tony > > > > Unfortunately, it's hard for them to do that *today*. That's the other thing proposal 121 is intended to do is help ARIN make better allocations for ISPs. Indeed, a key part of my quoted paragraph above was the "or shorter" phrase. Even in that scenario, though, I expect a typical ISP will use a /28, a moderately large ISP will use a /24, a very large access provider might use a /20, and only a handful of extremely large providers are likely to get /16s even under the generous criteria of proposal 121. Fully deployed, the current internet would probably consume less than a /12 per RIR if every RIR adopted proposal 121. The 50 year projections of internet growth would likely have each RIR invading but not using more than half of their second /12. Even if every RIR gets to 3 /12s in 50 years, that's still only 15/512ths of the initial /3 delegated to unicast space by IETF. There are 6+ more /3s remaining in the IETF pool. Owen From fernando at gont.com.ar Tue Jan 25 19:04:25 2011 From: fernando at gont.com.ar (Fernando Gont) Date: Tue, 25 Jan 2011 22:04:25 -0300 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <8B0D83FB-38DD-4C4D-9870-5913425BA3A2@delong.com> References: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com> <AANLkTimcZavnJN2gqayS2-piDvOAcw_nrJAREJ0EDTjp@mail.gmail.com> <op.vpt734cxtfhldh@rbeam.xactional.com> <8B0D83FB-38DD-4C4D-9870-5913425BA3A2@delong.com> Message-ID: <4D3F7319.4020208@gont.com.ar> On 24/01/2011 09:46 p.m., Owen DeLong wrote: >>> Many cite concerns of potential DoS attacks by doing sweeps of >>> IPv6 networks. I don't think this will be a common or >>> wide-spread problem. >> >> Myopia doesn't make the problem go away. The point of such an >> attack is not to "find things", but to overload the router(s). >> (which can be done rather easily by a few dozen machines.) >> > Only if you don't deploy reasonable mitigation strategies. Just wondering: What would you deem as "reasonable mitigation strategies"? Thanks, -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From fernando at gont.com.ar Tue Jan 25 19:12:22 2011 From: fernando at gont.com.ar (Fernando Gont) Date: Tue, 25 Jan 2011 22:12:22 -0300 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <AANLkTikMLTkYqXSAV-ZqiVAe9sS_qxQ6z4vYPY6Q-VFj@mail.gmail.com> References: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com> <AANLkTimcZavnJN2gqayS2-piDvOAcw_nrJAREJ0EDTjp@mail.gmail.com> <op.vpt734cxtfhldh@rbeam.xactional.com> <AANLkTikMLTkYqXSAV-ZqiVAe9sS_qxQ6z4vYPY6Q-VFj@mail.gmail.com> Message-ID: <4D3F74F6.4010506@gont.com.ar> On 25/01/2011 11:44 a.m., Ray Soucy wrote: > The argument can also be made that using smaller prefixes with > sequential host numbering will lead to making network sweeps and port > scanning viable in IPv6 where it would otherwise be useless. At that > point you just need evidence of one IPv6 address being in use and you > know that a few hundred next to it have the interesting hosts > connected. Sequential host numbering is already being used, despite of the prefix lengths in use. Also, the claim that "IPv6 address scanning is impossible" is generally based on the (incorrect) assumption that host addresses are spread (randomly) over the 64-bit IID. -- But they usually aren't. Thanks, -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From gary.steers at sharedband.com Tue Jan 25 19:15:18 2011 From: gary.steers at sharedband.com (Gary Steers) Date: Wed, 26 Jan 2011 01:15:18 -0000 Subject: Network Naming In-Reply-To: <A584FE4D-62CF-4218-8D21-CF51628BDA76@consultant.com> References: <7aeb7ba0$10caab2c$7a5700bb$@com> <A584FE4D-62CF-4218-8D21-CF51628BDA76@consultant.com> Message-ID: <CF4687332659244DA0C2D1F53AFF9F83614953@sb-server-sbs.SharedComUK.local> James makes a good point... > Pick a scheme which: > 1. Uses simple memorable names. > 2. Makes business sense to you. > 3. You know how to manage (database, publication, updates, etc. > If I had to weight these criteria, I would weight 3 most heavily. The other key thing to bear in mind is consistency and scalability... (i.e. design a scope that can grow with your network and needs {interface/server}.{router/vmhost}.{city}.{country}.example.net The other thing that doesn't really have any defined list is {city}, Some people prefer 2 letter, some 3 letter, some people use airport codes etc.. Hope that helps! G --- Gary Steers Sharedband NOC/3rd Line Support Sharedband UK: +44 (0)1473 287207 US: +1 206 420 0240 E: gary.steers at sharedband.com We have a?new support system - http://support.sharedband.com -----Original Message----- From: Cutler James R [mailto:james.cutler at consultant.com] Sent: 25 January 2011 22:41 To: nanog group Subject: Re: Network Naming On Jan 25, 2011, at 3:50 PM, Nick Olsen wrote: > Whats the rule of thumb for naming gear these days > (routers,switches...etc). Or is there one? Pick a scheme which: 1. Uses simple memorable names. 2. Makes business sense to you. 3. You know how to manage (database, publication, updates, etc. If I had to weight these criteria, I would weight 3 most heavily. James R. Cutler james.cutler at consultant.com From nathan at atlasnetworks.us Tue Jan 25 19:33:05 2011 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Wed, 26 Jan 2011 01:33:05 +0000 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <4449218A-4864-4346-8B73-F8C75ECC1827@delong.com> References: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com> <AANLkTimcZavnJN2gqayS2-piDvOAcw_nrJAREJ0EDTjp@mail.gmail.com> <op.vpt734cxtfhldh@rbeam.xactional.com> <8B0D83FB-38DD-4C4D-9870-5913425BA3A2@delong.com> <op.vpvur91htfhldh@rbeam.xactional.com> <63907.1295993236@localhost> <20110125222112.GA88462@ussenterprise.ufp.org> <65421.1295994750@localhost> <FCF6E6E9-60B8-4BFE-834A-A7D7EC3B483A@delong.com> <06ad01cbbcee$d91cc210$8b564630$@net> <4449218A-4864-4346-8B73-F8C75ECC1827@delong.com> Message-ID: <8C26A4FDAE599041A13EB499117D3C286B338444@ex-mb-1.corp.atlasnetworks.us> > Even if every RIR gets to 3 /12s in 50 years, that's still only 15/512ths of the > initial /3 delegated to unicast space by IETF. There are 6+ more /3s remaining > in the IETF pool. That's good news - we need to make sure we have a /3 for both the Moon and Mars colonies. ;) Nathan From fernando at gont.com.ar Tue Jan 25 20:00:52 2011 From: fernando at gont.com.ar (Fernando Gont) Date: Tue, 25 Jan 2011 23:00:52 -0300 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <4D3E0E64.4000001@mail-abuse.org> References: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com> <20110124132825.GB10465@vacation.karoshi.com.> <735BCAC6-4C3F-4BE9-BA1D-E412B3C043ED@delong.com> <20110124190435.GB11522@vacation.karoshi.com.> <4D3E0E64.4000001@mail-abuse.org> Message-ID: <4D3F8054.8040107@gont.com.ar> On 24/01/2011 08:42 p.m., Douglas Otis wrote: > It seems efforts related to IP address specific policies are likely > doomed by the sheer size of the address space, and to be pedantic, ARP > has been replaced with multicast neighbor discovery which dramatically > reduces the overall traffic involved. This has nothing to do with the number of entries required in the Neighbor Cache. > Secondly, doesn't Secure Neighbor > Discovery implemented at layer 2 fully mitigate these issues? I too > would be interested in hearing from Radia and Fred. It need not. Also, think about actual deployment of SEND: for instance, last time I checked Windows Vista didn't support it. Thanks, -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From owen at delong.com Tue Jan 25 20:02:16 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 25 Jan 2011 18:02:16 -0800 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <8C26A4FDAE599041A13EB499117D3C286B338444@ex-mb-1.corp.atlasnetworks.us> References: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com> <AANLkTimcZavnJN2gqayS2-piDvOAcw_nrJAREJ0EDTjp@mail.gmail.com> <op.vpt734cxtfhldh@rbeam.xactional.com> <8B0D83FB-38DD-4C4D-9870-5913425BA3A2@delong.com> <op.vpvur91htfhldh@rbeam.xactional.com> <63907.1295993236@localhost> <20110125222112.GA88462@ussenterprise.ufp.org> <65421.1295994750@localhost> <FCF6E6E9-60B8-4BFE-834A-A7D7EC3B483A@delong.com> <06ad01cbbcee$d91cc210$8b564630$@net> <4449218A-4864-4346-8B73-F8C75ECC1827@delong.com> <8C26A4FDAE599041A13EB499117D3C286B338444@ex-mb-1.corp.atlasnetworks.us> Message-ID: <ADBCEF60-8FCA-4DA1-876B-BCB3D6BC6B66@delong.com> On Jan 25, 2011, at 5:33 PM, Nathan Eisenberg wrote: >> Even if every RIR gets to 3 /12s in 50 years, that's still only 15/512ths of the >> initial /3 delegated to unicast space by IETF. There are 6+ more /3s remaining >> in the IETF pool. > > That's good news - we need to make sure we have a /3 for both the Moon and Mars colonies. ;) > > Nathan > > I'll be surprised and happy to see it if we reach the point of colonizing either of those locations before we reach the point of IPv6 being an insufficient protocol for modern needs. Owen From rdobbins at arbor.net Tue Jan 25 20:29:34 2011 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 26 Jan 2011 09:29:34 +0700 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <4D3F74F6.4010506@gont.com.ar> References: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com> <AANLkTimcZavnJN2gqayS2-piDvOAcw_nrJAREJ0EDTjp@mail.gmail.com> <op.vpt734cxtfhldh@rbeam.xactional.com> <AANLkTikMLTkYqXSAV-ZqiVAe9sS_qxQ6z4vYPY6Q-VFj@mail.gmail.com> <4D3F74F6.4010506@gont.com.ar> Message-ID: <B1BD8D7F-07E4-4196-8D3A-69CBD127F0F1@arbor.net> On Jan 26, 2011, at 8:12 AM, Fernando Gont wrote: > Also, the claim that "IPv6 address scanning is impossible" is generally based on the (incorrect) assumption that host addresses are spread > (randomly) over the 64-bit IID. -- But they usually aren't. It also doesn't take into account hinted scanning via routing table lookups, whois lookups, and walking reverse DNS, not to mention making use of ND mechanisms once a single box on a given subnet has been successfully botted. ------------------------------------------------------------------------ Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com> Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay From charles at knownelement.com Tue Jan 25 21:54:09 2011 From: charles at knownelement.com (Charles N Wyble) Date: Tue, 25 Jan 2011 19:54:09 -0800 Subject: [arin-announce] ARIN Resource Certification Update In-Reply-To: <7C7F5D42-E73A-4556-BD5F-76F49838258C@arbor.net> References: <EE59203D-907A-4AA2-BAE6-AEE7AADAC0A2@arin.net> <0BC31466-09EA-4734-96B2-152453A62B90@arin.net> <m27hdtrg6p.wl%randy@psg.com> <FFDCC932-AFD0-428F-9A50-B3B389D4532B@tcb.net> <66D828AA-16DB-43D4-A6D1-D40C137DCDAA@hopcount.ca> <AANLkTikr+Lsh=zFNnupt4_8bW6tQqveJsseE6zXAkt3c@mail.gmail.com> <81DB557A-6336-40AE-9F1A-2E4A2718B1C9@cs.columbia.edu> <AANLkTimfEqa6U5dgqNcca4h_OX4vDBq3CQOujo_fisJ+@mail.gmail.com> <7C7F5D42-E73A-4556-BD5F-76F49838258C@arbor.net> Message-ID: <4D3F9AE1.9050602@knownelement.com> On 1/24/2011 8:52 PM, Roland Dobbins wrote: > On Jan 25, 2011, at 11:35 AM, Christopher Morrow wrote: > >> thinking of using DNS is tempting > > The main arguments I see against it are: > > > 2. The generally creaky, fragile, brittle, non-scalable state of the overall DNS infrastructure in general. Can you expand on this a bit? > Routing and DNS, which are the two essential elements of the Internet control plane, are e also its Achilles' heels. It can be argued that making routing validation dependent upon the DNS would make this situation worse. > > The main reasons for it are those Danny stated: > > 1. DNS exists. > > 2. DNSSEC is in the initial stages of deployment. > > 3. There's additional relevant work going on which would make DNS more suitable for this application. > > 4. Deployment inertia. > I kind of like the DNS idea. Though some challenges have been raised in this thread that warrant further discussion. In particular the in.addr delegation scenarios between RIRs. From mysidia at gmail.com Tue Jan 25 22:17:03 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Tue, 25 Jan 2011 22:17:03 -0600 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <B1BD8D7F-07E4-4196-8D3A-69CBD127F0F1@arbor.net> References: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com> <AANLkTimcZavnJN2gqayS2-piDvOAcw_nrJAREJ0EDTjp@mail.gmail.com> <op.vpt734cxtfhldh@rbeam.xactional.com> <AANLkTikMLTkYqXSAV-ZqiVAe9sS_qxQ6z4vYPY6Q-VFj@mail.gmail.com> <4D3F74F6.4010506@gont.com.ar> <B1BD8D7F-07E4-4196-8D3A-69CBD127F0F1@arbor.net> Message-ID: <AANLkTi=iBMoWEuFOH3E659DSvA4tDY39H6y09M4_fT++@mail.gmail.com> On Tue, Jan 25, 2011 at 8:29 PM, Roland Dobbins <rdobbins at arbor.net> wrote: > On Jan 26, 2011, at 8:12 AM, Fernando Gont wrote: >> Also, the claim that "IPv6 address scanning is impossible" is generally based on the (incorrect) assumption that host addresses are spread >> (randomly) over the 64-bit IID. -- But they usually aren't. > It also doesn't take into account hinted scanning via routing table lookups, whois lookups, and walking reverse DNS, not to mention making use of ND mechanisms once a single box on a given subnet has been successfully botted. It's not that discovering IPv6 hosts is impossible -- it is just that there's a very large mathematical obstacle between any brute force attempt, and the hosts attempting to be discovered, that didn't exist with IPv4. It is fair to say in the aggregate that 'scanning is impossible' with IPv6, but host discovery is not impossible. Exhaustive scanning is what is basically impossible. Hinted partial scanning might yield useful number of guessable host addresses to be attempted; that is, if most networks wind up using some guessable IP addresses for possibly vulnerable hosts; then someone/some where will find it worth while to attempt partial scanning of random announced prefixes; attempting to guess network IDs, then attempting to guess lan host IDs. The bots attempting partial scanning will have to have a lot of ideas about what addresses are most likely to be assigned, and some mechanism of making a "tradeoff" to decide when to give up on a certain network and move on to attempt 'partial scanning' against the next prefix. DNS walking and ND mechanism use are something different from scanning. They are also less effective -- would-be intruder has to compromise a host on LAN before ND can be of any use, it doesn't help so much in discovering LAN hosts on other subnets (if say compromised host is in say a very small IPv6 DMZ isolated from potentially vulnerable hosts in separated secure networks); DNS walking is no good against hosts not listed in DNS. There are other methods of discovery as well, but they are not close in scale or 'ease of use' to what brute-force address space scanning could easily accomplish with IPv4. -- -JH From joelja at bogus.com Tue Jan 25 22:21:59 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Tue, 25 Jan 2011 20:21:59 -0800 Subject: IPv6 - real vs theoretical problems In-Reply-To: <4D2CAC6E.5070108@brightok.net> References: <D338D1613B32624285BB321A5CF3DB2510A33A05EA@ginga.ai.net><AANLkTi=_dh9GDSToHJy14dqqxvJ9vexzig7BTs-4MxVm@mail.gmail.com><4D269D77.4080309@jima.tk><10FB3518-6470-4F14-963C-B3150FABE667@delong.com><D338D1613B32624285BB321A5CF3DB2510A33A0615@ginga.ai.net><70A7A45E-6685-4584-BA71-8B25F0EA09BF@delong.com> <AANLkTimC5v_XMWPuJNyahefdJvW2oscdeeqS08bW+_YN@mail.gmail.com> <5A6D953473350C4B9995546AFE9939EE0BC132DC@RWC-EX1.corp.seven.com> <4D2CAC6E.5070108@brightok.net> Message-ID: <4D3FA167.40200@bogus.com> On 1/11/11 11:15 AM, Jack Bates wrote: > > > On 1/11/2011 1:05 PM, George Bonser wrote: >> Many of us are looking at things from today's >> perspective. Maybe each room of my house will have its own subnet with >> a low power access point and I can find which room something is in by >> the IP address it has. > > Today, there are several vendors who believe the wireless part of their > cpe should be a different subnet than the ethernet. There are multiple > cases of stacked routers in homes, which requires multiple DHCPv6-PD > delegations, and the current philosophy is very wasteful (as DHCPv6 > itself doesn't support variable sized requests, chained requesting, and > other options which would make it efficient for a requesting router 3 > routers away from the initial DHCPv6 server). There are also devices (even consumer ones) that support seperate ssids for guests and other users with different security policy for each as well as layer-3 seperation. in my direct experience with the d-link it doesn't (yet) route v6 to the guest network. > > Jack > From rdobbins at arbor.net Tue Jan 25 22:30:56 2011 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 26 Jan 2011 11:30:56 +0700 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <AANLkTi=iBMoWEuFOH3E659DSvA4tDY39H6y09M4_fT++@mail.gmail.com> References: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com> <AANLkTimcZavnJN2gqayS2-piDvOAcw_nrJAREJ0EDTjp@mail.gmail.com> <op.vpt734cxtfhldh@rbeam.xactional.com> <AANLkTikMLTkYqXSAV-ZqiVAe9sS_qxQ6z4vYPY6Q-VFj@mail.gmail.com> <4D3F74F6.4010506@gont.com.ar> <B1BD8D7F-07E4-4196-8D3A-69CBD127F0F1@arbor.net> <AANLkTi=iBMoWEuFOH3E659DSvA4tDY39H6y09M4_fT++@mail.gmail.com> Message-ID: <F2B5B9F3-9D78-424F-8CED-8E3E1441953E@arbor.net> On Jan 26, 2011, at 11:17 AM, Jimmy Hess wrote: > There are other methods of discovery as well, but they are not close in scale or 'ease of use' to what brute-force address space scanning > could easily accomplish with IPv4. Most botted hosts today are compromised in the first place via layer-7 exploits, not via scanning and network-based exploits. Pushing the miscreants in the direction of hinted scanning will further strain already overloaded whois and DNS servers. And just because iterative scanning is a crapshoot in IPv6, it costs attackers nothing to do it, anyways, and so they will. So, the fact that IPv6 access networks can contain huge numbers of possible endpoint addresses as compared to IPv4 is largely irrelevant; and in fact will have negative consequences with regards to the second-order effects of hinted scanning. ------------------------------------------------------------------------ Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com> Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay From dmiller at tiggee.com Tue Jan 25 22:32:30 2011 From: dmiller at tiggee.com (David Miller) Date: Tue, 25 Jan 2011 23:32:30 -0500 Subject: Network Naming In-Reply-To: <CF4687332659244DA0C2D1F53AFF9F83614953@sb-server-sbs.SharedComUK.local> References: <7aeb7ba0$10caab2c$7a5700bb$@com> <A584FE4D-62CF-4218-8D21-CF51628BDA76@consultant.com> <CF4687332659244DA0C2D1F53AFF9F83614953@sb-server-sbs.SharedComUK.local> Message-ID: <4D3FA3DE.7040809@tiggee.com> On 1/25/2011 8:15 PM, Gary Steers wrote: > James makes a good point... > >> Pick a scheme which: >> 1. Uses simple memorable names. >> 2. Makes business sense to you. >> 3. You know how to manage (database, publication, updates, etc. >> If I had to weight these criteria, I would weight 3 most heavily. > > The other key thing to bear in mind is consistency and scalability... (i.e. design a scope that can grow with your network and needs > > {interface/server}.{router/vmhost}.{city}.{country}.example.net > > The other thing that doesn't really have any defined list is {city}, Some people prefer 2 letter, some 3 letter, some people use airport codes etc.. > The naming schemes that I have developed that needed to be upgraded in the past have almost always bumped up against scale, so build in much larger scale than you ever think that you will need from the beginning. You have X devices now in Y locations, but your naming scheme should scale to X^Z devices in Y^Z locations. I agree that for network gear, this is is a good place to start (slightly simplified here from above): {interface}.{host}.{location}.example.net - Location I personally prefer UN LOCODEs for country / city. The UN already went to the trouble of giving a unique code to every country/city. Why do I use them? LON makes perfect sense as London, England... until you have devices in London, KY and London, OH (the LOCODES for these Londons are GB LON, US LDN, US LOZ). In my opinion, airport codes (while certainly unique) work well in some locales and not so well in others (so, I don't use them, YMMV). - Host I prefer, like many do, an acronym denoting the primary function of the device. ES (edge switch), AR (access router), CR (core router), etc... whatever your internal terminology is. If you will *ever* have more than 10 of a device anywhere, then I would recommend that you number out of double digits (more than 100, then out of triple digits...). That way in a sorted list AR03 will be right between AR02 and AR04, where you expect it to be, instead of between AR29 and AR30. Standardizing on number length also limits ambiguity in pressure situations and/or over noisy or less reliable communication channels. - Interface Port names vary on gear from different vendors. {interface type} - {selector}* ... where selector repeats ordered from highest to lowest level of granularity (e.g. rack/slot/module/port) is what I use. You should use whatever makes sense to you. Are interface speeds or vlans important to your infrastructure? If so, then include them where appropriate. Unless you have exactly the same gear everywhere, you are going to have to be flexible here. I recommend documenting your naming standard and getting buy in across your organization before you put it into place. By giving names to these devices/interfaces at all, you are exposing information to the world. What makes perfect sense to engineering and support may give security, management, and/or marketing heart palpitations. Just my $0.02 (probably overvalued). > Hope that helps! > > G > > --- > Gary Steers > Sharedband NOC/3rd Line Support > Sharedband > UK: +44 (0)1473 287207 > US: +1 206 420 0240 > E: gary.steers at sharedband.com > > We have a new support system - http://support.sharedband.com > > > -----Original Message----- > From: Cutler James R [mailto:james.cutler at consultant.com] > Sent: 25 January 2011 22:41 > To: nanog group > Subject: Re: Network Naming > > On Jan 25, 2011, at 3:50 PM, Nick Olsen wrote: > >> Whats the rule of thumb for naming gear these days >> (routers,switches...etc). Or is there one? > Pick a scheme which: > 1. Uses simple memorable names. > 2. Makes business sense to you. > 3. You know how to manage (database, publication, updates, etc. > > If I had to weight these criteria, I would weight 3 most heavily. > > > James R. Cutler > james.cutler at consultant.com > > > > > > From adrian at creative.net.au Tue Jan 25 22:37:22 2011 From: adrian at creative.net.au (Adrian Chadd) Date: Wed, 26 Jan 2011 12:37:22 +0800 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <58166C50-0B72-43A0-8AB8-25E803EA1619@delong.com> References: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com> <AANLkTimcZavnJN2gqayS2-piDvOAcw_nrJAREJ0EDTjp@mail.gmail.com> <AANLkTikHBb+cyfPxXftb5QZh136D04fkdWFMy3NFhDdi@mail.gmail.com> <4D3F0144.70107@sohonet.co.uk> <58166C50-0B72-43A0-8AB8-25E803EA1619@delong.com> Message-ID: <20110126043722.GA4110@skywalker.creative.net.au> (Top-posting because the whole message is context. Oh, and I'm lazy.) I do indeed love it when people break out IPv6 addressing as "there's so many addresses, we'll never ever go through them!" Sure, if they're only used as end-point identifiers. Say you want to crack out that 64k-port space into something bigger, because say p2p becomes so wide-spread and ingrained in our society, that 64k port space per IP becomes silly. So we say, break off another 16 bits and have a host just listen on not a /128, but on a /112. Cool, 4 billion "ports". That fixes the port space. Then someone comes along with a bright idea. "Hi!" she says, "Since hosts are already listening on a /112 of space (and thus all those pesky ND cache problems have been fixed!), we can start allocating cloud identifiers on peoples' hosts, so each cloud application instance gets a separate address prefix; thus any given host can run multiple cloud instances!" Let's call that a 32 bit address space, because I bet a 16 bit "cloud ID" doesn't scale. A 16 bit cloud identifier takes it down to a /96. A 32 bit cloud identifier takes it down to /80. Cool. Now you've got all these end-hosts all happily doing p2p between each other over a 16-bit extended port space, then running p2p and other apps inside a 32-bit cloud identifier so they can both run their own distributed apps/vms (eg diaspora), or donate/sell/whatever their clock cycles to others. What did that just do to your per-site /64? That you have no hope of ever seeing a user use up? It just turned that /64 into a /112 (16 bits of port space, 32 bits of cloud identifier space.) What's the next killer app that'll chew up more of your IPv6 space? I'm all for IPv6. And I'm all for avoiding conjecture and getting to the task at hand. But simply assuming that the IPv6 address space will forever remain that - only unique host identifiers - I think is disingenious at best. :-) Adrian On Tue, Jan 25, 2011, Owen DeLong wrote: > I love this term... "repetitively sweeping a targets /64". > > Seriously? Repetitively sweeping a /64? Let's do the math... > > 2^64 = 18,446,744,073,709,551,616 IP addresses. > > Let's assume that few networks would not be DOS'd by a 1,000 PPS > storm coming in so that's a reasonable cap on our scan rate. > > That means sweeping a /64 takes 18,446,744,073,709,551 sec. > (rounded down). > > There are 86,400 seconds per day. > > 18,446,744,073,709,551 / 86,400 = 213,503,982,334 days. > > Rounding a year down to 365 days, that's 584,942,417 > years to sweep the /64 once. > > If we increase our scan rate to 1,000,000 packets > per second, it still takes us 584,942 years to sweep > a /64. > > I don't know about you, but I do not expect to live long > enough to sweep a /64, let alone do so repetitively. > > Owen -- - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support - - $24/pm+GST entry-level VPSes w/ capped bandwidth charges available in WA - From gbonser at seven.com Tue Jan 25 22:47:36 2011 From: gbonser at seven.com (George Bonser) Date: Tue, 25 Jan 2011 20:47:36 -0800 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <20110126043722.GA4110@skywalker.creative.net.au> References: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com><AANLkTimcZavnJN2gqayS2-piDvOAcw_nrJAREJ0EDTjp@mail.gmail.com><AANLkTikHBb+cyfPxXftb5QZh136D04fkdWFMy3NFhDdi@mail.gmail.com><4D3F0144.70107@sohonet.co.uk><58166C50-0B72-43A0-8AB8-25E803EA1619@delong.com> <20110126043722.GA4110@skywalker.creative.net.au> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13603@RWC-EX1.corp.seven.com> > From: Adrian Chadd > Sent: Tuesday, January 25, 2011 8:37 PM > To: Owen DeLong > Cc: nanog at nanog.org > Subject: Re: Using IPv6 with prefixes shorter than a /64 on a LAN > > (Top-posting because the whole message is context. Oh, and I'm lazy.) > > I do indeed love it when people break out IPv6 addressing as > "there's so many addresses, we'll never ever go through them!" > > Sure, if they're only used as end-point identifiers. > Yeah, at some point v6 IP addresses might be used for something completely different. For example, rather than using a cookie to balance through a load balancer to get back to a server in a "sticky session", maybe you are redirected directly to an IP address on the server that represents your session. The IP address could be provisioned dynamically on the server as required, the user hits the main URL and is "redirected" to the unique IP address representing their session. If you have a 64-bit address, each active session can easily be given its own unique IP. I can see requirements at some point for servers to be able to handle thousands of IP addresses per interface. From rdobbins at arbor.net Tue Jan 25 22:53:23 2011 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 26 Jan 2011 11:53:23 +0700 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <20110126043722.GA4110@skywalker.creative.net.au> References: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com> <AANLkTimcZavnJN2gqayS2-piDvOAcw_nrJAREJ0EDTjp@mail.gmail.com> <AANLkTikHBb+cyfPxXftb5QZh136D04fkdWFMy3NFhDdi@mail.gmail.com> <4D3F0144.70107@sohonet.co.uk> <58166C50-0B72-43A0-8AB8-25E803EA1619@delong.com> <20110126043722.GA4110@skywalker.creative.net.au> Message-ID: <AE3E144C-64D8-46AA-9EFE-9CECF2F766FA@arbor.net> On Jan 26, 2011, at 11:37 AM, Adrian Chadd wrote: > But simply assuming that the IPv6 address space will forever remain that - only unique host identifiers - I think is disingenious at best. :-) I think 'disingenuous' is too strong a word - 'overly optimistic' better reflects the position, IMHO. ;> In addition to all the extremely valid use-cases you outline, there's also the concept of one-time-use prefixes which likely will end up being used at the molecular level in manufacturing/supply-chain applications, lifetime assignments to individuals as a matter of citizenship which will be retired upon their deaths/disenfranchisement, nanite communications used to do things like clean plaque out of people's arteries in lieu of angioplasty, and a whole host of new applications we haven't even dreamed of, yet. The supreme irony of this situation is that folks who're convinced that there's no way we can even run out of addresses often accuse those of us who're plentitude-skeptics of old-fashioned thinking; whereas there's a strong case to be made that those very same vocal advocates of the plentitude position seem to be assuming that the assignment and consumption of IPv6 addresses (and networking technology and the Internet in general) will continue to be constrained by the current four-decade-old paradigm into the foreseeable future. ------------------------------------------------------------------------ Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com> Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay From franck at genius.com Tue Jan 25 23:03:50 2011 From: franck at genius.com (Franck Martin) Date: Wed, 26 Jan 2011 18:03:50 +1300 (FJST) Subject: IPv6 filtering Message-ID: <32507261.286.1296018229100.JavaMail.franck@franck-martins-macbook-pro.local> ? ipv6 41 IPv6 # IPv6 ? ipv6-route 43 IPv6-Route # Routing Header for IPv6 ? ipv6-frag 44 IPv6-Frag # Fragment Header for IPv6 ? ipv6-crypt 50 IPv6-Crypt # Encryption Header for IPv6 ? ipv6-auth 51 IPv6-Auth # Authentication Header for IPv6 ? ipv6-icmp 58 IPv6-ICMP icmpv6 icmp6 # ICMP for IPv6 ? ipv6-nonxt 59 IPv6-NoNxt # No Next Header for IPv6 ? ipv6-opts 60 IPv6-Opts # Destination Options for IPv6 Ok filtering ipv6 and ipv6-icmp is understood, it is like ipv4. But what about the others, should they be blocked, restricted? Does a ios "deny ipv6 any any" affect them? From franck at genius.com Tue Jan 25 23:08:15 2011 From: franck at genius.com (Franck Martin) Date: Wed, 26 Jan 2011 18:08:15 +1300 (FJST) Subject: Future of the IPv6 CPE survey on RIPE Labs - Your Input Needed In-Reply-To: <4D3D8DE6.2070806@ripe.net> Message-ID: <1164463.290.1296018492548.JavaMail.franck@franck-martins-macbook-pro.local> What about an Airport Extreme? It has a wan interface that does PPPOE The IPv6 feature seems working, with 6to4 or static tunnels and a basic IPv6 firewall. ----- Original Message ----- From: "Mirjam Kuehne" <mir at ripe.net> To: nanog at nanog.org Sent: Tuesday, 25 January, 2011 3:34:14 AM Subject: Future of the IPv6 CPE survey on RIPE Labs - Your Input Needed [apologies for duplicates] Hello, Based on new information we received since the last publication, we updated the IPv6 CPE matrix: http://labs.ripe.net/Members/mirjam/ipv6-cpe-survey-updated-january-2011 In order to make this information more useful for a large user base, we are preparing a detailed survey to gather more structural feedback about the range of equipment that is currently in use. Not only would we like you to participate in this survey, but we also ask for your help in identifying the right survey questions. Please find a call for input on RIPE Labs: http://labs.ripe.net/Members/marco/future-of-the-ipv6-cpe-survey-more-input-needed Kind Regards, Mirjam Kuehne & Marco Hogewoning RIPE NCC From rdobbins at arbor.net Tue Jan 25 23:13:26 2011 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 26 Jan 2011 12:13:26 +0700 Subject: IPv6 filtering In-Reply-To: <32507261.286.1296018229100.JavaMail.franck@franck-martins-macbook-pro.local> References: <32507261.286.1296018229100.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <9FC10AEC-9B96-4BFC-8261-2F6332F616AE@arbor.net> On Jan 26, 2011, at 12:03 PM, Franck Martin wrote: > Ok filtering ipv6 and ipv6-icmp is understood, it is like ipv4. Be advised, ICMPv6 is *not* like ICMP in IPv4, and knowing what can be filtered, what to filter, and where to filter it is considerably more complex than in IPv4 - which, given the prevalence of broken PMTU-D alone, is apparently not well-understood in many quarters, heh. ------------------------------------------------------------------------ Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com> Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay From owen at delong.com Tue Jan 25 23:17:18 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 25 Jan 2011 21:17:18 -0800 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13603@RWC-EX1.corp.seven.com> References: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com><AANLkTimcZavnJN2gqayS2-piDvOAcw_nrJAREJ0EDTjp@mail.gmail.com><AANLkTikHBb+cyfPxXftb5QZh136D04fkdWFMy3NFhDdi@mail.gmail.com><4D3F0144.70107@sohonet.co.uk><58166C50-0B72-43A0-8AB8-25E803EA1619@delong.com> <20110126043722.GA4110@skywalker.creative.net.au> <5A6D953473350C4B9995546AFE9939EE0BC13603@RWC-EX1.corp.seven.com> Message-ID: <FD3161F6-8DC1-45C6-B25A-02937D47F383@delong.com> On Jan 25, 2011, at 8:47 PM, George Bonser wrote: > > >> From: Adrian Chadd >> Sent: Tuesday, January 25, 2011 8:37 PM >> To: Owen DeLong >> Cc: nanog at nanog.org >> Subject: Re: Using IPv6 with prefixes shorter than a /64 on a LAN >> >> (Top-posting because the whole message is context. Oh, and I'm lazy.) >> >> I do indeed love it when people break out IPv6 addressing as >> "there's so many addresses, we'll never ever go through them!" >> >> Sure, if they're only used as end-point identifiers. >> > > Yeah, at some point v6 IP addresses might be used for something > completely different. For example, rather than using a cookie to > balance through a load balancer to get back to a server in a "sticky > session", maybe you are redirected directly to an IP address on the > server that represents your session. The IP address could be > provisioned dynamically on the server as required, the user hits the > main URL and is "redirected" to the unique IP address representing their > session. > There isn't a web farm big enough for that not to still work within a /64. Since a web farm network would be a /64 anyway, this isn't an increase in the consumption of IPv6 addresses. > If you have a 64-bit address, each active session can easily be given > its own unique IP. I can see requirements at some point for servers to > be able to handle thousands of IP addresses per interface. > Many already can. Owen From franck at genius.com Tue Jan 25 23:20:00 2011 From: franck at genius.com (Franck Martin) Date: Wed, 26 Jan 2011 18:20:00 +1300 (FJST) Subject: IPv6 filtering In-Reply-To: <9FC10AEC-9B96-4BFC-8261-2F6332F616AE@arbor.net> Message-ID: <6024623.294.1296019199315.JavaMail.franck@franck-martins-macbook-pro.local> Well we filter icmp due to exploits, if no exploits, then we can let the whole of icmpv6 through. Or is there something terribly dangerous in icmpv6 already? ----- Original Message ----- From: "Roland Dobbins" <rdobbins at arbor.net> To: "nanog group" <nanog at nanog.org> Sent: Wednesday, 26 January, 2011 6:13:26 PM Subject: Re: IPv6 filtering On Jan 26, 2011, at 12:03 PM, Franck Martin wrote: > Ok filtering ipv6 and ipv6-icmp is understood, it is like ipv4. Be advised, ICMPv6 is *not* like ICMP in IPv4, and knowing what can be filtered, what to filter, and where to filter it is considerably more complex than in IPv4 - which, given the prevalence of broken PMTU-D alone, is apparently not well-understood in many quarters, heh. ------------------------------------------------------------------------ Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com> Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay From sethm at rollernet.us Tue Jan 25 23:20:20 2011 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 25 Jan 2011 21:20:20 -0800 Subject: IPv6 filtering In-Reply-To: <9FC10AEC-9B96-4BFC-8261-2F6332F616AE@arbor.net> References: <32507261.286.1296018229100.JavaMail.franck@franck-martins-macbook-pro.local> <9FC10AEC-9B96-4BFC-8261-2F6332F616AE@arbor.net> Message-ID: <4D3FAF14.9080102@rollernet.us> On 1/25/11 9:13 PM, Roland Dobbins wrote: > > On Jan 26, 2011, at 12:03 PM, Franck Martin wrote: > >> Ok filtering ipv6 and ipv6-icmp is understood, it is like ipv4. > > Be advised, ICMPv6 is *not* like ICMP in IPv4, and knowing what can be filtered, what to filter, and where to filter it is considerably more complex than in IPv4 - which, given the prevalence of broken PMTU-D alone, is apparently not well-understood in many quarters, heh. > Also, try to resist popular opinion in outright blocking of ICMP - it's not really that evil. ~Seth From owen at delong.com Tue Jan 25 23:25:49 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 25 Jan 2011 21:25:49 -0800 Subject: IPv6 filtering In-Reply-To: <32507261.286.1296018229100.JavaMail.franck@franck-martins-macbook-pro.local> References: <32507261.286.1296018229100.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <1ECA3D3E-A5B7-49A5-8516-FCEBBB3FBE7E@delong.com> On Jan 25, 2011, at 9:03 PM, Franck Martin wrote: > > ? ipv6 41 IPv6 # IPv6 > ? ipv6-route 43 IPv6-Route # Routing Header for IPv6 > ? ipv6-frag 44 IPv6-Frag # Fragment Header for IPv6 > ? ipv6-crypt 50 IPv6-Crypt # Encryption Header for IPv6 > ? ipv6-auth 51 IPv6-Auth # Authentication Header for IPv6 > ? ipv6-icmp 58 IPv6-ICMP icmpv6 icmp6 # ICMP for IPv6 > ? ipv6-nonxt 59 IPv6-NoNxt # No Next Header for IPv6 > ? ipv6-opts 60 IPv6-Opts # Destination Options for IPv6 > > Ok filtering ipv6 and ipv6-icmp is understood, it is like ipv4. > > But what about the others, should they be blocked, restricted? > > Does a ios "deny ipv6 any any" affect them? DO NOT filter IPv6 ICMP like you filter IPv4. If you do, you will break PMTU-Discovery, Neighbor Discovery, and RA/SLAAC, all of which depend on ICMPv6. Owen From owen at delong.com Tue Jan 25 23:24:38 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 25 Jan 2011 21:24:38 -0800 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <20110126043722.GA4110@skywalker.creative.net.au> References: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com> <AANLkTimcZavnJN2gqayS2-piDvOAcw_nrJAREJ0EDTjp@mail.gmail.com> <AANLkTikHBb+cyfPxXftb5QZh136D04fkdWFMy3NFhDdi@mail.gmail.com> <4D3F0144.70107@sohonet.co.uk> <58166C50-0B72-43A0-8AB8-25E803EA1619@delong.com> <20110126043722.GA4110@skywalker.creative.net.au> Message-ID: <01A129E4-B530-48F6-8794-8451FF4649D6@delong.com> > ... > > What did that just do to your per-site /64? That you have > no hope of ever seeing a user use up? It just turned > that /64 into a /112 (16 bits of port space, 32 bits > of cloud identifier space.) What's the next killer app > that'll chew up more of your IPv6 space? > Dude... You missed... It's not supposed to be a /64 per site. The plan is a /48 per site. Yes, you managed to use one of the subnets up pretty well... ON A SINGLE SUBNET. Now, what do you do for the other 65,535 of them at the one site? > I'm all for IPv6. And I'm all for avoiding conjecture > and getting to the task at hand. But simply assuming > that the IPv6 address space will forever remain that - > only unique host identifiers - I think is disingenious > at best. :-) > Well.. There's assuming (like your assumption that a /64 per site was the original plan) and then there's doing the math. Even with the utilization you've mentioned above, my math still holds. Owen > > > Adrian > > On Tue, Jan 25, 2011, Owen DeLong wrote: > >> I love this term... "repetitively sweeping a targets /64". >> >> Seriously? Repetitively sweeping a /64? Let's do the math... >> >> 2^64 = 18,446,744,073,709,551,616 IP addresses. >> >> Let's assume that few networks would not be DOS'd by a 1,000 PPS >> storm coming in so that's a reasonable cap on our scan rate. >> >> That means sweeping a /64 takes 18,446,744,073,709,551 sec. >> (rounded down). >> >> There are 86,400 seconds per day. >> >> 18,446,744,073,709,551 / 86,400 = 213,503,982,334 days. >> >> Rounding a year down to 365 days, that's 584,942,417 >> years to sweep the /64 once. >> >> If we increase our scan rate to 1,000,000 packets >> per second, it still takes us 584,942 years to sweep >> a /64. >> >> I don't know about you, but I do not expect to live long >> enough to sweep a /64, let alone do so repetitively. >> >> Owen > > -- > - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support - > - $24/pm+GST entry-level VPSes w/ capped bandwidth charges available in WA - From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Tue Jan 25 23:33:55 2011 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Wed, 26 Jan 2011 16:03:55 +1030 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <AE3E144C-64D8-46AA-9EFE-9CECF2F766FA@arbor.net> References: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com> <AANLkTimcZavnJN2gqayS2-piDvOAcw_nrJAREJ0EDTjp@mail.gmail.com> <AANLkTikHBb+cyfPxXftb5QZh136D04fkdWFMy3NFhDdi@mail.gmail.com> <4D3F0144.70107@sohonet.co.uk> <58166C50-0B72-43A0-8AB8-25E803EA1619@delong.com> <20110126043722.GA4110@skywalker.creative.net.au> <AE3E144C-64D8-46AA-9EFE-9CECF2F766FA@arbor.net> Message-ID: <20110126160355.3847cba5@opy.nosense.org> On Wed, 26 Jan 2011 11:53:23 +0700 Roland Dobbins <rdobbins at arbor.net> wrote: > > On Jan 26, 2011, at 11:37 AM, Adrian Chadd wrote: > > > But simply assuming that the IPv6 address space will forever remain that - only unique host identifiers - I think is disingenious at best. :-) > > I think 'disingenuous' is too strong a word - 'overly optimistic' better reflects the position, IMHO. > > ;> > > In addition to all the extremely valid use-cases you outline, there's also the concept of one-time-use prefixes which likely will end up being used at the molecular level in manufacturing/supply-chain applications, lifetime assignments to individuals as a matter of citizenship which will be retired upon their deaths/disenfranchisement, nanite communications used to do things like clean plaque out of people's arteries in lieu of angioplasty, and a whole host of new applications we haven't even dreamed of, yet. > > The supreme irony of this situation is that folks who're convinced that there's no way we can even run out of addresses often accuse those of us who're plentitude-skeptics of old-fashioned thinking; whereas there's a strong case to be made that those very same vocal advocates of the plentitude position seem to be assuming that the assignment and consumption of IPv6 addresses (and networking technology and the Internet in general) will continue to be constrained by the current four-decade-old paradigm into the foreseeable future. > The correct assumption is that most people will try and usually succeed at follow the specifications, as that is what is required to successfully participate in a protocol (any protocol, not just networking ones). IPv4 history has shown that most people will. People who argue against current Ipv6 address use projections are doing so with an unstated assumption that most people won't follow the specifications. Once you make that assumption, then anything at all can be used as an example to created FUD about running out of addresses, including the equally valid example that people will close their eyes and bash the number pad when entering IPv6 prefix or address information. The only way to prevent absolutely the misconfiguration of protocol parameters is to not make them configurable. Pretty much impossible to do with networking prefixes or addresses. From hank at efes.iucc.ac.il Tue Jan 25 23:37:16 2011 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Wed, 26 Jan 2011 07:37:16 +0200 Subject: Understanding reverse DNS better In-Reply-To: <201101250847.10034.lesmith@ecsis.net> References: <4D3EE073.3070603@p8x.net> <D65B039B-36B2-4936-BC2A-24E8A9938B64@gmail.com> <AE81CBB4-6CE4-484C-BE53-FA96D29A28F2@puck.nether.net> <4D3EE073.3070603@p8x.net> Message-ID: <5.1.0.14.2.20110126073658.03764e08@efes.iucc.ac.il> At 08:47 25/01/2011 -0600, Larry Smith wrote: >I use Squish (www.squish.net/dnscheck) for this purpose. Reasonable >web interface and gives lots of info about where things are breaking >down... Seems to be having issues: Finding servers for . from A.ROOT-SERVERS.NET (198.41.0.4) Error: Resolve for NSs of . to A.ROOT-SERVERS.NET (198.41.0.4) failed: query timed out -Hank >-- >Larry Smith >lesmith at ecsis.net > >On Tue January 25 2011 08:38, p8x wrote: > > +1, also a quick check to make sure your name servers are actually set > > can be done with host.. host -t ns 0.168.192.in-addr.arpa > > > > On 25/01/2011 10:34 PM, Jared Mauch wrote: > > > I suggest doing something like: > > > > > > dig +trace -x 204.42.254.5 > > > > > > You can watch the delegation authority for the in-addr at each stage. > > > > > > - Jared > > > > > > On Jan 25, 2011, at 9:30 AM, Caleb Tennis wrote: > > >> We have a /24 from one of our upstream providers that we handoff to a > > >> customer. The /24 has been SWIPd to us, and we have nameservers setup > > >> with ARIN against that record. > > >> > > >> Twice now this information has just "disappeared". That is, if do > > >> reverse DNS lookups, they returns nothing, whereas they were just > > >> working fine earlier. If you do an NS lookup on the block, it returns > > >> nothing. The /24 blocks immediately surrounding us continue to work > > >> just fine. If we do a lookup directly against our nameserver, it works > > >> just fine. > > >> > > >> It's like the nameserver information against that reverse DNS is just > > >> magically gone. > > >> > > >> The ARIN record looks good, nothing has changed. Last time, our upstream > > >> resubmitted the info so it would repopulate, and it started working > > >> again soon there after. I admit to not being the smartest one with how > > >> these records work: is the problem with the upstream, or ARIN's > > >> database, or is there not enough information to tell? > > >> > > >> Thanks, > > >> Caleb From paul at paulgraydon.co.uk Tue Jan 25 23:42:03 2011 From: paul at paulgraydon.co.uk (Paul Graydon) Date: Tue, 25 Jan 2011 19:42:03 -1000 Subject: IPv6 filtering In-Reply-To: <6024623.294.1296019199315.JavaMail.franck@franck-martins-macbook-pro.local> References: <6024623.294.1296019199315.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <4D3FB42B.2050606@paulgraydon.co.uk> I may be dense, networking isn't my primary field (sysadmin).. but isn't ICMP there for a good reason? I.e. congestion control? I've always argued vehemently with PCI-DSS and similar auditors that I will not filter /all/ ICMP traffic on the border. Paul On 1/25/2011 7:20 PM, Franck Martin wrote: > Well we filter icmp due to exploits, if no exploits, then we can let the whole of icmpv6 through. Or is there something terribly dangerous in icmpv6 already? > > ----- Original Message ----- > From: "Roland Dobbins"<rdobbins at arbor.net> > To: "nanog group"<nanog at nanog.org> > Sent: Wednesday, 26 January, 2011 6:13:26 PM > Subject: Re: IPv6 filtering > > > On Jan 26, 2011, at 12:03 PM, Franck Martin wrote: > >> Ok filtering ipv6 and ipv6-icmp is understood, it is like ipv4. > Be advised, ICMPv6 is *not* like ICMP in IPv4, and knowing what can be filtered, what to filter, and where to filter it is considerably more complex than in IPv4 - which, given the prevalence of broken PMTU-D alone, is apparently not well-understood in many quarters, heh. > > ------------------------------------------------------------------------ > Roland Dobbins<rdobbins at arbor.net> //<http://www.arbornetworks.com> > > Most software today is very much like an Egyptian pyramid, with millions > of bricks piled on top of each other, with no structural integrity, but > just done by brute force and thousands of slaves. > > -- Alan Kay > > > > From hank at efes.iucc.ac.il Tue Jan 25 23:46:54 2011 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Wed, 26 Jan 2011 07:46:54 +0200 Subject: IPv6 filtering In-Reply-To: <6024623.294.1296019199315.JavaMail.franck@franck-martins-m acbook-pro.local> References: <9FC10AEC-9B96-4BFC-8261-2F6332F616AE@arbor.net> Message-ID: <5.1.0.14.2.20110126073427.03754da0@efes.iucc.ac.il> At 18:20 26/01/2011 +1300, Franck Martin wrote: >Content-Transfer-Encoding: 7bit > >Well we filter icmp due to exploits, if no exploits, then we can let the >whole of icmpv6 through. Or is there something terribly dangerous in >icmpv6 already? Ever since Cisco came out with "IPv6 Routing Header Vulnerability" in 2007 http://www.cisco.com/en/US/products/products_security_advisory09186a00807cb0fd.shtml I have had the following enabled: On the protected interface: ipv6 traffic-filter filter-rh in ipv6 access-list filter-rh deny ipv6 any any log routing permit ipv6 any any and have stopped many pkts that way. I still occasionally see hits in our log from all sorts of newbies who continue to try old bugs. -Hank From mnagel at willingminds.com Tue Jan 25 23:49:12 2011 From: mnagel at willingminds.com (Mark D. Nagel) Date: Tue, 25 Jan 2011 21:49:12 -0800 Subject: IPv6 filtering In-Reply-To: <1ECA3D3E-A5B7-49A5-8516-FCEBBB3FBE7E@delong.com> References: <32507261.286.1296018229100.JavaMail.franck@franck-martins-macbook-pro.local> <1ECA3D3E-A5B7-49A5-8516-FCEBBB3FBE7E@delong.com> Message-ID: <4D3FB5D8.3060408@willingminds.com> On 1/25/2011 9:25 PM, Owen DeLong wrote: > > DO NOT filter IPv6 ICMP like you filter IPv4. > > If you do, you will break PMTU-Discovery, Neighbor Discovery, > and RA/SLAAC, all of which depend on ICMPv6. > This can bite you in unexpected ways, too. For example, on a Cisco ASA, if you add a system-level 'icmpv6 permit' line and if this does not include ND, then you break ND responses to the ASA. This is much unlike ARP, which is unaffected by 'icmp permit' statements for IPv4. And, the default with no such lines is to permit all ICMP/ICMPv6 to the ASA. This seems so obvious in retrospect, but at the time was a bit of a head-scratcher. Mark -- Mark D. Nagel, CCIE #3177 <mnagel at willingminds.com> Principal Consultant, Willing Minds LLC (http://www.willingminds.com) cell: 949-279-5817, desk: 714-495-4001, fax: 949-623-9854 *** Please send support requests to support at willingminds.com! *** From rdobbins at arbor.net Tue Jan 25 23:49:13 2011 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 26 Jan 2011 12:49:13 +0700 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <20110126160355.3847cba5@opy.nosense.org> References: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com> <AANLkTimcZavnJN2gqayS2-piDvOAcw_nrJAREJ0EDTjp@mail.gmail.com> <AANLkTikHBb+cyfPxXftb5QZh136D04fkdWFMy3NFhDdi@mail.gmail.com> <4D3F0144.70107@sohonet.co.uk> <58166C50-0B72-43A0-8AB8-25E803EA1619@delong.com> <20110126043722.GA4110@skywalker.creative.net.au> <AE3E144C-64D8-46AA-9EFE-9CECF2F766FA@arbor.net> <20110126160355.3847cba5@opy.nosense.org> Message-ID: <4F45EB96-8F09-433B-8B03-6B8E430945C4@arbor.net> On Jan 26, 2011, at 12:33 PM, Mark Smith wrote: > The correct assumption is that most people will try and usually succeed at follow the specifications, as that is what is required to > successfully participate in a protocol (any protocol, not just networking ones). IPv4 history has shown that most people will. Specification <> application, as in new applications. And, no, I don't think that 'most people will' - I've seen enough foolishness with regards to IPv4 misaddressing over the last quarter-century (pre- and post-CIDR) to share your optimism in that regard. ;> ------------------------------------------------------------------------ Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com> Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay From hank at efes.iucc.ac.il Tue Jan 25 23:52:55 2011 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Wed, 26 Jan 2011 07:52:55 +0200 Subject: Understanding reverse DNS better In-Reply-To: <4D3EF9C1.9000602@unfix.org> References: <alpine.BSF.2.00.1101251617480.53011@qrswnz.pp.fgengu.np.hx> <D65B039B-36B2-4936-BC2A-24E8A9938B64@gmail.com> <AE81CBB4-6CE4-484C-BE53-FA96D29A28F2@puck.nether.net> <4D3EE073.3070603@p8x.net> <201101250847.10034.lesmith@ecsis.net> <alpine.BSF.2.00.1101251617480.53011@qrswnz.pp.fgengu.np.hx> Message-ID: <5.1.0.14.2.20110126075139.037594c8@efes.iucc.ac.il> >On 2011-01-25 17:21, Jethro R Binks wrote: > > On Tue, 25 Jan 2011, Larry Smith wrote: > > > >> I use Squish (www.squish.net/dnscheck) for this purpose. Reasonable web > >> interface and gives lots of info about where things are breaking down... > >> > >> -- > >> Larry Smith > > > > squish.net/dnscheck is great, except when I've had problems with it, or > > wanted a second opinion. Does anyone know another site that offers much > > the same functionality? If you like a nice graphic schematic try: http://www.zonecut.net/dns/index.cgi -Hank From swmike at swm.pp.se Wed Jan 26 00:30:50 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 26 Jan 2011 07:30:50 +0100 (CET) Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <06ad01cbbcee$d91cc210$8b564630$@net> References: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com> <AANLkTimcZavnJN2gqayS2-piDvOAcw_nrJAREJ0EDTjp@mail.gmail.com> <op.vpt734cxtfhldh@rbeam.xactional.com> <8B0D83FB-38DD-4C4D-9870-5913425BA3A2@delong.com> <op.vpvur91htfhldh@rbeam.xactional.com> <63907.1295993236@localhost> <20110125222112.GA88462@ussenterprise.ufp.org> <65421.1295994750@localhost> <FCF6E6E9-60B8-4BFE-834A-A7D7EC3B483A@delong.com> <06ad01cbbcee$d91cc210$8b564630$@net> Message-ID: <alpine.DEB.1.10.1101260726070.13151@uplift.swm.pp.se> On Tue, 25 Jan 2011, Tony Hain wrote: > Every organization with a *real* customer base should have significantly > shorter than a /32. In particular every organization that says "I can't > give my customers prefix length X because I only have a /32" needs to go > back to ARIN today and trade that in for a *real block*. There should be > at least 10 organizations in the ARIN region that qualify for a /20 or > shorter, and most would likely be /24 or shorter. +1 on this. We returned our /32 that we received back in 2002 or so, and after proper application received a /25 where I believe we have up to /22 reserved for us in case we need it. We hope we're not going to have to pollute the DFZ with more than a single entry in the forseeable future. To everybody who thinks we need to conserve addresses, please consider this current allocation policy (/48 and /56) as something we'll do for the first /3 in use, when we exhaust that, we need to really look at what we're doing and look if we need to change the policy for the other /3:s. We have 7 more tries to go before we exhaust the whole IPv6 space. -- Mikael Abrahamsson email: swmike at swm.pp.se From swmike at swm.pp.se Wed Jan 26 00:34:15 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 26 Jan 2011 07:34:15 +0100 (CET) Subject: PPPOE vs DHCP In-Reply-To: <051001cbbcf0$c33e8b20$49bba160$@org> References: <051001cbbcf0$c33e8b20$49bba160$@org> Message-ID: <alpine.DEB.1.10.1101260731420.13151@uplift.swm.pp.se> On Tue, 25 Jan 2011, Paul Stewart wrote: > I'm meeting with a customer tomorrow (service provider, rural telco) and > we're pitching they move to a PPPOE platform most likely. But to be > fair, I'm looking to draw up a comparison so they are "well informed" of > the pros/cons. Has anyone done this? Of course. There are plenty of ISPs doing ETTH with DHCP based solutions. and L2 and L3 switches for switching/routing. Only reason I would ever roll out PPP today is because of some regulatory demand to provide bitstream to others, and most likely not even then (there are better ways). Basically all your "con:s" on DHCP isn't true, they can all be solved and has been for 10 years by others. -- Mikael Abrahamsson email: swmike at swm.pp.se From jbates at brightok.net Wed Jan 26 00:44:46 2011 From: jbates at brightok.net (Jack Bates) Date: Wed, 26 Jan 2011 00:44:46 -0600 Subject: PPPOE vs DHCP In-Reply-To: <051001cbbcf0$c33e8b20$49bba160$@org> References: <051001cbbcf0$c33e8b20$49bba160$@org> Message-ID: <4D3FC2DE.9070704@brightok.net> On 1/25/2011 6:34 PM, Paul Stewart wrote: > PPPOE Pros > > ---------- > > > > Allows full authentication of customers (requires username/password) > Authentication isn't necessary if you have other methods of turning off a port. Authentication can actually be a Con, as the username/password can be forgotten and a truck rolled to reprogram a CPE because the user uses gmail (email often being the only other time the username/password is used). > Allows control over customer connections (suspend accounts, create accounts > etc) > Depending on telco processes, this is easily handled in the DLC (often times combined with turning off their phone service). > Easily assign static IP to customer (no MAC address or CPE information > required) > Option-82! > Assign public subnet to customer with ease (no manual routing required) > I'll give you this one. > IPv4/IPv6 fully supported on Juniper platform as required > I'm pretty sure it's supported for bridging/DHCP environments too. > Usage tracking (GB transfer) from radius generated data > It works, but there are other accounting methods. > > > PPPOE Cons > > ---------- > > > > Requires PPPOE termination router (Juniper ERX for example) > You're putting Juniper ERXs at customer houses? Really? I'd expect to see DSL/Cable drops which will utilize cheap end CPE (most of which don't support IPv6 hardly at all). > Requires Radius server(s) to assign and track customer IP assignments/usage > > Customers require username/password to connect > > Customers require PPPOE client software or router to connect > > 8 bytes MTU overhead > The 8 bytes usually isn't too bad and is counteracted in bridging environments by vlan tags (often dual tagged for proper isolation). You can usually set the MTUs 8 bytes larger to compensate and still allow 1500 byte IP packets. > DHCP Pros > > --------- > > > > Simplistic - plug and play 90% of the time > Not when it's done right. > No MTU overhead, full 1500 MTU frame size > Yes and no. When you run vlan tags, it's a bit more complex. If using ATM termination, it's less complex. > > DHCP Cons > > --------- > > > > No authentication occurs (anyone physically connected can use Internet > generally) > For consumer use, not a concern. Hijacking a phone line, for example, may get you connected, but you've also broken the customer's connection. If you are on site, plug in behind the CPE and you're golden either way. > No user tracking without tracking customer CPE MAC addresses > option-82, and when I do track, I track IP -> MAC -> Interface. The MAC is just because customers ask which MAC. I only really care about IP -> Interface. > No usage tracking builtin to DHCP (GB transfer) Granted. > There are several factors involved here. The first major thing is that we > believe the customer wants to move towards caps on their customer usage (X > amount of GB per month). Today, they are doing static IP assignments but > the interesting thing is that the CPE they have control over today (Comtrend > routers with DSL modem builtin). I know there's not always a good vs bad > here but looking for opinions from folks who may have already done this > comparison for a "boardroom discussion".... > Over the last decade, I've been building out all DSL networks as ATM, 1 pvc per interface (cisco RBE ftw) and Double tagged vlans, 1 vlan per interface (cisco unnumbered subinterfaces ftw). Juniper has similar stuff. We utilize proxy arp for customer communications. This creates a fully isolated environment with the router handling all the security and provisioning. Massive configs as I have it currently, though templating and dynamic configurations with radius backends has been getting added into newer code (hear the ASR has some nice backend options). All DSL cpes provided by the telcos are in bridging mode only (even wireless model were bridged). Why did I do this? IPv6. Telcos who did not follow my advice currently have the following issues. 1) PPPoE, must now replace every customer CPE (given out for free, customer expects telco to pay for replacement). Every DSL modem vendor I've talked to has stated that IPv6 support will not be in the older CPEs. 2) DSLAMs without q-in-q support or extremely limited vlan support requiring the DSLAM to do DHCP snooping and it's own security. IPv6 does not work... Period. Code will have to be upgraded for each of these DSLAMs to support IPv6. Vendors currently don't support it, and word is vendors are changing to support more vlans quickly. :) Ideally? You are starting a brand new network with no broadband customers. You have an inexpensive CPE which already supports IPv6 beautifully. All network equipment supports baby giants, or even better, jumbo frames. You adjust the MTU, you run PPPoE w/ v4/v6 and 1500 byte IP packets. Have a nice day. If you don't have the benefit/capability, other options tend to be more cost effective. Jack From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Wed Jan 26 00:52:29 2011 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Wed, 26 Jan 2011 17:22:29 +1030 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <4F45EB96-8F09-433B-8B03-6B8E430945C4@arbor.net> References: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com> <AANLkTimcZavnJN2gqayS2-piDvOAcw_nrJAREJ0EDTjp@mail.gmail.com> <AANLkTikHBb+cyfPxXftb5QZh136D04fkdWFMy3NFhDdi@mail.gmail.com> <4D3F0144.70107@sohonet.co.uk> <58166C50-0B72-43A0-8AB8-25E803EA1619@delong.com> <20110126043722.GA4110@skywalker.creative.net.au> <AE3E144C-64D8-46AA-9EFE-9CECF2F766FA@arbor.net> <20110126160355.3847cba5@opy.nosense.org> <4F45EB96-8F09-433B-8B03-6B8E430945C4@arbor.net> Message-ID: <20110126172229.2164fd11@opy.nosense.org> On Wed, 26 Jan 2011 12:49:13 +0700 Roland Dobbins <rdobbins at arbor.net> wrote: > > On Jan 26, 2011, at 12:33 PM, Mark Smith wrote: > > > The correct assumption is that most people will try and usually succeed at follow the specifications, as that is what is required to > > successfully participate in a protocol (any protocol, not just networking ones). IPv4 history has shown that most people will. > > Specification <> application, as in new applications. > > And, no, I don't think that 'most people will' - I've seen enough foolishness with regards to IPv4 misaddressing over the last quarter-century (pre- and post-CIDR) to share your optimism in that regard. > The Internet works most of the time doesn't it? I think that is evidence that most people get it right most of the time, and that misaddressing has minimal if any effect because it is ignored as non-complaint with the Internet's protocols (both implementation and operational ones). Usually the consequences of misaddressing are limited to those who've performed it. Mark From swmike at swm.pp.se Wed Jan 26 00:54:02 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 26 Jan 2011 07:54:02 +0100 (CET) Subject: IPv6 filtering In-Reply-To: <32507261.286.1296018229100.JavaMail.franck@franck-martins-macbook-pro.local> References: <32507261.286.1296018229100.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <alpine.DEB.1.10.1101260752530.13151@uplift.swm.pp.se> On Wed, 26 Jan 2011, Franck Martin wrote: > But what about the others, should they be blocked, restricted? "Recommendations for Filtering ICMPv6 Messages in Firewalls" <http://www.ietf.org/rfc/rfc4890.txt> -- Mikael Abrahamsson email: swmike at swm.pp.se From fernando at gont.com.ar Wed Jan 26 00:26:43 2011 From: fernando at gont.com.ar (Fernando Gont) Date: Wed, 26 Jan 2011 03:26:43 -0300 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <AANLkTikHBb+cyfPxXftb5QZh136D04fkdWFMy3NFhDdi@mail.gmail.com> References: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com> <AANLkTimcZavnJN2gqayS2-piDvOAcw_nrJAREJ0EDTjp@mail.gmail.com> <AANLkTikHBb+cyfPxXftb5QZh136D04fkdWFMy3NFhDdi@mail.gmail.com> Message-ID: <4D3FBEA3.6040404@gont.com.ar> On 24/01/2011 07:41 p.m., Michael Loftis wrote: >> Many cite concerns of potential DoS attacks by doing sweeps of IPv6 >> networks. I don't think this will be a common or wide-spread problem. >> The general feeling is that there is simply too much address space >> for it to be done in any reasonable amount of time, and there is >> almost nothing to be gained from it. > > The problem I see is the opening of a new, simple, DoS/DDoS scenario. > By repetitively sweeping a targets /64 you can cause EVERYTHING in > that /64 to stop working by overflowing the ND/ND cache, depending on > the specific ND cache implementation and how big it is/etc. That depends on the ND implementation being broken enough by not limiting the number of neighbor cache entries that are in the INCOMPLETE state. (I'm not saying those broken implementations don't exist, though). Thanks, -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From fernando at gont.com.ar Wed Jan 26 00:30:38 2011 From: fernando at gont.com.ar (Fernando Gont) Date: Wed, 26 Jan 2011 03:30:38 -0300 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <AANLkTimcZavnJN2gqayS2-piDvOAcw_nrJAREJ0EDTjp@mail.gmail.com> References: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com> <AANLkTimcZavnJN2gqayS2-piDvOAcw_nrJAREJ0EDTjp@mail.gmail.com> Message-ID: <4D3FBF8E.8070605@gont.com.ar> On 24/01/2011 05:53 p.m., Ray Soucy wrote: > Every time I see this question it' usually related to a fundamental > misunderstanding of IPv6 and the attempt to apply v4 logic to v6. > > That said. Any size prefix will likely work and is even permitted by > the RFC. You do run the risk of encountering applications that assume > a 64-bit prefix length, though. And you're often crippling the > advantages of IPv6. Just curious: What are the advantages you're referring to? Thanks, -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From fernando at gont.com.ar Wed Jan 26 01:43:52 2011 From: fernando at gont.com.ar (Fernando Gont) Date: Wed, 26 Jan 2011 04:43:52 -0300 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <B1BD8D7F-07E4-4196-8D3A-69CBD127F0F1@arbor.net> References: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com> <AANLkTimcZavnJN2gqayS2-piDvOAcw_nrJAREJ0EDTjp@mail.gmail.com> <op.vpt734cxtfhldh@rbeam.xactional.com> <AANLkTikMLTkYqXSAV-ZqiVAe9sS_qxQ6z4vYPY6Q-VFj@mail.gmail.com> <4D3F74F6.4010506@gont.com.ar> <B1BD8D7F-07E4-4196-8D3A-69CBD127F0F1@arbor.net> Message-ID: <4D3FD0B8.3040602@gont.com.ar> On 25/01/2011 11:29 p.m., Roland Dobbins wrote: > On Jan 26, 2011, at 8:12 AM, Fernando Gont wrote: > >> Also, the claim that "IPv6 address scanning is impossible" is >> generally based on the (incorrect) assumption that host addresses >> are spread (randomly) over the 64-bit IID. -- But they usually >> aren't. > > It also doesn't take into account hinted scanning via routing table > lookups, whois lookups, and walking reverse DNS, not to mention > making use of ND mechanisms once a single box on a given subnet has > been successfully botted. +1 Thanks, -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From mohacsi at niif.hu Wed Jan 26 01:55:37 2011 From: mohacsi at niif.hu (Mohacsi Janos) Date: Wed, 26 Jan 2011 08:55:37 +0100 (CET) Subject: IPv6 filtering In-Reply-To: <32507261.286.1296018229100.JavaMail.franck@franck-martins-macbook-pro.local> References: <32507261.286.1296018229100.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <alpine.BSF.2.00.1101260854230.69156@mignon.ki.iif.hu> On Wed, 26 Jan 2011, Franck Martin wrote: > > ? ipv6 41 IPv6 # IPv6 > ? ipv6-route 43 IPv6-Route # Routing Header for IPv6 > ? ipv6-frag 44 IPv6-Frag # Fragment Header for IPv6 > ? ipv6-crypt 50 IPv6-Crypt # Encryption Header for IPv6 > ? ipv6-auth 51 IPv6-Auth # Authentication Header for IPv6 > ? ipv6-icmp 58 IPv6-ICMP icmpv6 icmp6 # ICMP for IPv6 > ? ipv6-nonxt 59 IPv6-NoNxt # No Next Header for IPv6 > ? ipv6-opts 60 IPv6-Opts # Destination Options for IPv6 > > Ok filtering ipv6 and ipv6-icmp is understood, it is like ipv4. > > But what about the others, should they be blocked, restricted? > > Does a ios "deny ipv6 any any" affect them? Have a look at RFC 4890 Recommendations for Filtering ICMPv6 Messages in Firewalls. Regards, Janos Mohacsi From mohacsi at niif.hu Wed Jan 26 02:01:17 2011 From: mohacsi at niif.hu (Mohacsi Janos) Date: Wed, 26 Jan 2011 09:01:17 +0100 (CET) Subject: Future of the IPv6 CPE survey on RIPE Labs - Your Input Needed In-Reply-To: <1164463.290.1296018492548.JavaMail.franck@franck-martins-macbook-pro.local> References: <1164463.290.1296018492548.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <alpine.BSF.2.00.1101260856400.69156@mignon.ki.iif.hu> On Wed, 26 Jan 2011, Franck Martin wrote: > What about an Airport Extreme? It has a wan interface that does PPPOE > > The IPv6 feature seems working, with 6to4 or static tunnels and a basic IPv6 firewall. Yes it is. I already reported to Marco. http://labs.ripe.net/Members/marco/content-ipv6-cpe-survey It should be included somehow in a matrix But 6to4 (or other tunneling techniques) is only a substitute of real IPv6. Regards, Janos Mohacsi > > ----- Original Message ----- > From: "Mirjam Kuehne" <mir at ripe.net> > To: nanog at nanog.org > Sent: Tuesday, 25 January, 2011 3:34:14 AM > Subject: Future of the IPv6 CPE survey on RIPE Labs - Your Input Needed > > [apologies for duplicates] > > Hello, > > Based on new information we received since the last publication, we > updated the IPv6 CPE matrix: > > http://labs.ripe.net/Members/mirjam/ipv6-cpe-survey-updated-january-2011 > > In order to make this information more useful for a large user base, we > are preparing a detailed survey to gather more structural feedback about > the range of equipment that is currently in use. Not only would we like > you to participate in this survey, but we also ask for your help in > identifying the right survey questions. Please find a call for input on > RIPE Labs: > > http://labs.ripe.net/Members/marco/future-of-the-ipv6-cpe-survey-more-input-needed > > Kind Regards, > Mirjam Kuehne & Marco Hogewoning > RIPE NCC > > > From owen at delong.com Wed Jan 26 03:03:28 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 26 Jan 2011 01:03:28 -0800 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <4F45EB96-8F09-433B-8B03-6B8E430945C4@arbor.net> References: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com> <AANLkTimcZavnJN2gqayS2-piDvOAcw_nrJAREJ0EDTjp@mail.gmail.com> <AANLkTikHBb+cyfPxXftb5QZh136D04fkdWFMy3NFhDdi@mail.gmail.com> <4D3F0144.70107@sohonet.co.uk> <58166C50-0B72-43A0-8AB8-25E803EA1619@delong.com> <20110126043722.GA4110@skywalker.creative.net.au> <AE3E144C-64D8-46AA-9EFE-9CECF2F766FA@arbor.net> <20110126160355.3847cba5@opy.nosense.org> <4F45EB96-8F09-433B-8B03-6B8E430945C4@arbor.net> Message-ID: <3A804406-F13D-44FC-84BF-43F89EF0982B@delong.com> On Jan 25, 2011, at 9:49 PM, Roland Dobbins wrote: > > On Jan 26, 2011, at 12:33 PM, Mark Smith wrote: > >> The correct assumption is that most people will try and usually succeed at follow the specifications, as that is what is required to >> successfully participate in a protocol (any protocol, not just networking ones). IPv4 history has shown that most people will. > > Specification <> application, as in new applications. > > And, no, I don't think that 'most people will' - I've seen enough foolishness with regards to IPv4 misaddressing over the last quarter-century (pre- and post-CIDR) to share your optimism in that regard. > Is there IPv4 brokenness in the world? Sure. Is the majority of IPv4 deployed in the world done so in a broken manner? I think that's a stretch. Most people try and usually succeed at implementing IPv4 at least reasonably in line with the specifications. Owen From michiel at klaver.it Wed Jan 26 03:04:44 2011 From: michiel at klaver.it (Michiel Klaver) Date: Wed, 26 Jan 2011 10:04:44 +0100 Subject: Another v6 question In-Reply-To: <AANLkTikEZVYFz+bx7MVXeht_qNnpkUEC_Mx0qhE6J9SR@mail.gmail.com> References: <AANLkTikEZVYFz+bx7MVXeht_qNnpkUEC_Mx0qhE6J9SR@mail.gmail.com> Message-ID: <4D3FE3AC.8090801@klaver.it> At 22-07-28164 20:59, Max Pierson wrote: > > From the provider perspective, what is the prefix-length that most are > accepting to be injected into your tables?? 2 or so years ago, I read where > someone stated that they were told by ATT that they weren't planning on > accepting anything smaller than a /32. So what if I get my shiny new /48 > from ARIN and am already multi-homed??? Does ATT not want my business (which > they wouldn't get if the first place, but for argument sake, yes, I chose to > pick on ATT, sorry if I offended anyone :) I already see /40's /48's ,etc > in the v6 table, so some folks are allowing /48 and smaller, so what is the > new /24 in v6? > Hi Max, There is a Wikipedia article all about that: http://en.wikipedia.org/wiki/Comparison_of_IPv6_support_by_major_transit_providers And here is some more information about subnetting your IPv6 network: http://en.wikipedia.org/wiki/IPv6_subnetting_reference From mikevs at xs4all.net Wed Jan 26 03:16:01 2011 From: mikevs at xs4all.net (Miquel van Smoorenburg) Date: Wed, 26 Jan 2011 10:16:01 +0100 Subject: PPPOE vs DHCP In-Reply-To: <051001cbbcf0$c33e8b20$49bba160$@org> Message-ID: <201101260916.p0Q9G1pd029345@xs8.xs4all.nl> In article <051001cbbcf0$c33e8b20$49bba160$@org> you write: >PPPOE vs DHCP >Allows full authentication of customers (requires username/password) You probably want to authenticate on circuit id, not username/password. ATM port/vpi/vci for ATM connections, or PPPoE circuit id tag added by the DSLAM or FTTH access switch when using an ethernet transport layer. It's just a different radius attribute to authenticate on, no magic. We do that so a customer doesn't have to configure his/her router to get online. >Easily assign static IP to customer (no MAC address or CPE information >required) Don't need that with DHCP either, if you run a DHCP server that can assign IP addresses based on option82. I run a patched ISC dhcp3 server, but I understand that ISC dhcp4 makes this pretty easy >Assign public subnet to customer with ease (no manual routing required) Don't need manual routing with DHCP either, if you use a real bras such as a juniper, since you can have it authenticate off radius first before doing DHCP, and in the radius reply you can return a static route. >Usage tracking (GB transfer) from radius generated data True, at least juniper e-series BRASes don't send radius accounting for atm rfc1483/bridged connections for some reason. >DHCP Cons > >--------- One more DHCP con is that if you have an ethernet transport network from the DSLAM or FTTH access switch to your router that lumps together multiple customers in one VLAN, something along the way is probably doing DHCP sniffing to set up routing. And you can be just about sure that won't work with IPv6. VLAN-per-customer will work (and is a really a great model, for all types of encapsulation) Mike. From owen at delong.com Wed Jan 26 03:14:43 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 26 Jan 2011 01:14:43 -0800 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <4D3FBF8E.8070605@gont.com.ar> References: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com> <AANLkTimcZavnJN2gqayS2-piDvOAcw_nrJAREJ0EDTjp@mail.gmail.com> <4D3FBF8E.8070605@gont.com.ar> Message-ID: <E58532F0-F1E4-4E17-BC4D-0A96D5A7BC18@delong.com> On Jan 25, 2011, at 10:30 PM, Fernando Gont wrote: > On 24/01/2011 05:53 p.m., Ray Soucy wrote: >> Every time I see this question it' usually related to a fundamental >> misunderstanding of IPv6 and the attempt to apply v4 logic to v6. >> >> That said. Any size prefix will likely work and is even permitted by >> the RFC. You do run the risk of encountering applications that assume >> a 64-bit prefix length, though. And you're often crippling the >> advantages of IPv6. > > Just curious: What are the advantages you're referring to? > 1. Sparse addressing 2. SLAAC 3. RFC 4193 Privacy Addressing 4. Never have to worry about "growing" a subnet to hold new machines. 5. Universal subnet size, no surprises, no operator confusion, no bitmath. There are probably others. Owen From mch-nanog at xs4all.nl Wed Jan 26 03:22:50 2011 From: mch-nanog at xs4all.nl (Marco Hogewoning) Date: Wed, 26 Jan 2011 09:22:50 +0000 Subject: Future of the IPv6 CPE survey on RIPE Labs - Your Input Needed In-Reply-To: <alpine.BSF.2.00.1101260856400.69156@mignon.ki.iif.hu> References: <1164463.290.1296018492548.JavaMail.franck@franck-martins-macbook-pro.local> <alpine.BSF.2.00.1101260856400.69156@mignon.ki.iif.hu> Message-ID: <5977FCE7-62DB-40D3-A9CB-5C5CE3FE627D@xs4all.nl> Hi, Maybe a bit more to explain. Up to now I asked the vendors to provide certain information before adding a box to the matrix. Apple was send a copy but they never responded. In future we are going to build the matrix upon user supplied data. See the article on the future of this work at http://labs.ripe.net/Members/marco/future-of-the-ipv6-cpe-survey-more-input-needed. What we'll probably do is include everything for which there is a minimum number of responses like 5 or 10. Actual number to be decided upon once this is rolling and we can figure out the relevant number is. Grtx, Marco On Jan 26, 2011, at 8:01 AM, Mohacsi Janos wrote: > > > > On Wed, 26 Jan 2011, Franck Martin wrote: > >> What about an Airport Extreme? It has a wan interface that does PPPOE >> >> The IPv6 feature seems working, with 6to4 or static tunnels and a basic IPv6 firewall. > > Yes it is. I already reported to Marco. > http://labs.ripe.net/Members/marco/content-ipv6-cpe-survey > > It should be included somehow in a matrix But 6to4 (or other tunneling techniques) is only a substitute of real IPv6. > > Regards, > Janos Mohacsi > >> >> ----- Original Message ----- >> From: "Mirjam Kuehne" <mir at ripe.net> >> To: nanog at nanog.org >> Sent: Tuesday, 25 January, 2011 3:34:14 AM >> Subject: Future of the IPv6 CPE survey on RIPE Labs - Your Input Needed >> >> [apologies for duplicates] >> >> Hello, >> >> Based on new information we received since the last publication, we >> updated the IPv6 CPE matrix: >> >> http://labs.ripe.net/Members/mirjam/ipv6-cpe-survey-updated-january-2011 >> >> In order to make this information more useful for a large user base, we >> are preparing a detailed survey to gather more structural feedback about >> the range of equipment that is currently in use. Not only would we like >> you to participate in this survey, but we also ask for your help in >> identifying the right survey questions. Please find a call for input on >> RIPE Labs: >> >> http://labs.ripe.net/Members/marco/future-of-the-ipv6-cpe-survey-more-input-needed >> >> Kind Regards, >> Mirjam Kuehne & Marco Hogewoning >> RIPE NCC >> >> >> > From owen at delong.com Wed Jan 26 03:23:33 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 26 Jan 2011 01:23:33 -0800 Subject: Future of the IPv6 CPE survey on RIPE Labs - Your Input Needed In-Reply-To: <alpine.BSF.2.00.1101260856400.69156@mignon.ki.iif.hu> References: <1164463.290.1296018492548.JavaMail.franck@franck-martins-macbook-pro.local> <alpine.BSF.2.00.1101260856400.69156@mignon.ki.iif.hu> Message-ID: <31362582-C2A9-45CC-A3E9-13EB5743C957@delong.com> It works for routing native IPv6 under some circumstances as well. Owen On Jan 26, 2011, at 12:01 AM, Mohacsi Janos wrote: > > > > On Wed, 26 Jan 2011, Franck Martin wrote: > >> What about an Airport Extreme? It has a wan interface that does PPPOE >> >> The IPv6 feature seems working, with 6to4 or static tunnels and a basic IPv6 firewall. > > Yes it is. I already reported to Marco. > http://labs.ripe.net/Members/marco/content-ipv6-cpe-survey > > It should be included somehow in a matrix But 6to4 (or other tunneling techniques) is only a substitute of real IPv6. > > Regards, > Janos Mohacsi > >> >> ----- Original Message ----- >> From: "Mirjam Kuehne" <mir at ripe.net> >> To: nanog at nanog.org >> Sent: Tuesday, 25 January, 2011 3:34:14 AM >> Subject: Future of the IPv6 CPE survey on RIPE Labs - Your Input Needed >> >> [apologies for duplicates] >> >> Hello, >> >> Based on new information we received since the last publication, we >> updated the IPv6 CPE matrix: >> >> http://labs.ripe.net/Members/mirjam/ipv6-cpe-survey-updated-january-2011 >> >> In order to make this information more useful for a large user base, we >> are preparing a detailed survey to gather more structural feedback about >> the range of equipment that is currently in use. Not only would we like >> you to participate in this survey, but we also ask for your help in >> identifying the right survey questions. Please find a call for input on >> RIPE Labs: >> >> http://labs.ripe.net/Members/marco/future-of-the-ipv6-cpe-survey-more-input-needed >> >> Kind Regards, >> Mirjam Kuehne & Marco Hogewoning >> RIPE NCC >> >> >> From paul at paulstewart.org Wed Jan 26 05:01:14 2011 From: paul at paulstewart.org (Paul Stewart) Date: Wed, 26 Jan 2011 06:01:14 -0500 Subject: PPPOE vs DHCP In-Reply-To: <201101260916.p0Q9G1pd029345@xs8.xs4all.nl> References: <051001cbbcf0$c33e8b20$49bba160$@org> <201101260916.p0Q9G1pd029345@xs8.xs4all.nl> Message-ID: <06a101cbbd48$5c3281e0$149785a0$@org> I just wanted to say thank you for a TONNE of feedback I received on this topic. This has been of great help in filling in some items I missed in my quick list. Will try to respond offlist to several of you that responded - got over 100 replies offline with some interesting ideas. I definitely learned I should have made my original post a bit clearer though and specifically the usage tracking component ;) Normally I would post a summary on these kinds of topics but quite honestly there is such a huge varience in opinions and options around this that I'll probably just invite anyone to hit me offlist if they are interested in the feedback received so far... Thanks folks, Paul From eugen at leitl.org Wed Jan 26 05:29:47 2011 From: eugen at leitl.org (Eugen Leitl) Date: Wed, 26 Jan 2011 12:29:47 +0100 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <8C26A4FDAE599041A13EB499117D3C286B338444@ex-mb-1.corp.atlasnetworks.us> References: <op.vpt734cxtfhldh@rbeam.xactional.com> <8B0D83FB-38DD-4C4D-9870-5913425BA3A2@delong.com> <op.vpvur91htfhldh@rbeam.xactional.com> <63907.1295993236@localhost> <20110125222112.GA88462@ussenterprise.ufp.org> <65421.1295994750@localhost> <FCF6E6E9-60B8-4BFE-834A-A7D7EC3B483A@delong.com> <06ad01cbbcee$d91cc210$8b564630$@net> <4449218A-4864-4346-8B73-F8C75ECC1827@delong.com> <8C26A4FDAE599041A13EB499117D3C286B338444@ex-mb-1.corp.atlasnetworks.us> Message-ID: <20110126112947.GM23560@leitl.org> On Wed, Jan 26, 2011 at 01:33:05AM +0000, Nathan Eisenberg wrote: > > Even if every RIR gets to 3 /12s in 50 years, that's still only 15/512ths of the > > initial /3 delegated to unicast space by IETF. There are 6+ more /3s remaining > > in the IETF pool. > > That's good news - we need to make sure we have a /3 for both the Moon and Mars colonies. ;) A /64 is barely enough bits for a ~2 m resolution on Earth surface, and barely to the Karman line. In practice you'd aim for ~um resolution for all major gravity wells in this system (DTN is already flying, there's a Cisco box in Earth orbit, Moon and Mars are next). (And of course if you're you're going to multiply above by 10^11, or so. Eventually). From rdobbins at arbor.net Wed Jan 26 06:22:16 2011 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 26 Jan 2011 19:22:16 +0700 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <20110126112947.GM23560@leitl.org> References: <op.vpt734cxtfhldh@rbeam.xactional.com> <8B0D83FB-38DD-4C4D-9870-5913425BA3A2@delong.com> <op.vpvur91htfhldh@rbeam.xactional.com> <63907.1295993236@localhost> <20110125222112.GA88462@ussenterprise.ufp.org> <65421.1295994750@localhost> <FCF6E6E9-60B8-4BFE-834A-A7D7EC3B483A@delong.com> <06ad01cbbcee$d91cc210$8b564630$@net> <4449218A-4864-4346-8B73-F8C75ECC1827@delong.com> <8C26A4FDAE599041A13EB499117D3C286B338444@ex-mb-1.corp.atlasnetworks.us> <20110126112947.GM23560@leitl.org> Message-ID: <2192DBD8-CC10-4299-8603-2C4EEFABABF3@arbor.net> On Jan 26, 2011, at 6:29 PM, Eugen Leitl wrote: > In practice you'd aim for ~um resolution for all major gravity wells in this system (DTN is already flying, there's a Cisco box in Earth orbit, Moon and Mars are next). Don't forget the asteroid belt, that's where the real money is. ------------------------------------------------------------------------ Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com> Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay From richard.barnes at gmail.com Wed Jan 26 06:41:50 2011 From: richard.barnes at gmail.com (Richard Barnes) Date: Wed, 26 Jan 2011 07:41:50 -0500 Subject: Future of the IPv6 CPE survey on RIPE Labs - Your Input Needed In-Reply-To: <31362582-C2A9-45CC-A3E9-13EB5743C957@delong.com> References: <1164463.290.1296018492548.JavaMail.franck@franck-martins-macbook-pro.local> <alpine.BSF.2.00.1101260856400.69156@mignon.ki.iif.hu> <31362582-C2A9-45CC-A3E9-13EB5743C957@delong.com> Message-ID: <AANLkTinkMg+n6z8nZbxBD+9uRe5BBc2c+ceExbNQgqFp@mail.gmail.com> Could you elaborate? Which circumstances? On Wed, Jan 26, 2011 at 4:23 AM, Owen DeLong <owen at delong.com> wrote: > It works for routing native IPv6 under some circumstances as well. > > Owen > > On Jan 26, 2011, at 12:01 AM, Mohacsi Janos wrote: > >> >> >> >> On Wed, 26 Jan 2011, Franck Martin wrote: >> >>> What about an Airport Extreme? It has a wan interface that does PPPOE >>> >>> The IPv6 feature seems working, with 6to4 or static tunnels and a basic IPv6 firewall. >> >> Yes it is. I already reported to Marco. >> http://labs.ripe.net/Members/marco/content-ipv6-cpe-survey >> >> It should be included somehow in a matrix But 6to4 (or other tunneling techniques) is only a substitute of real IPv6. >> >> Regards, >> ? ? ? Janos Mohacsi >> >>> >>> ----- Original Message ----- >>> From: "Mirjam Kuehne" <mir at ripe.net> >>> To: nanog at nanog.org >>> Sent: Tuesday, 25 January, 2011 3:34:14 AM >>> Subject: Future of the IPv6 CPE survey on RIPE Labs - Your Input Needed >>> >>> [apologies for duplicates] >>> >>> Hello, >>> >>> Based on new information we received since the last publication, we >>> updated the IPv6 CPE matrix: >>> >>> http://labs.ripe.net/Members/mirjam/ipv6-cpe-survey-updated-january-2011 >>> >>> In order to make this information more useful for a large user base, we >>> are preparing a detailed survey to gather more structural feedback about >>> the range of equipment that is currently in use. Not only would we like >>> you to participate in this survey, but we also ask for your help in >>> identifying the right survey questions. Please find a call for input on >>> RIPE Labs: >>> >>> http://labs.ripe.net/Members/marco/future-of-the-ipv6-cpe-survey-more-input-needed >>> >>> Kind Regards, >>> Mirjam Kuehne & Marco Hogewoning >>> RIPE NCC >>> >>> >>> > > > From paul at paulstewart.org Wed Jan 26 07:40:49 2011 From: paul at paulstewart.org (Paul Stewart) Date: Wed, 26 Jan 2011 08:40:49 -0500 Subject: PPPOE vs DHCP In-Reply-To: <201101260916.p0Q9G1pd029345@xs8.xs4all.nl> References: <051001cbbcf0$c33e8b20$49bba160$@org> <201101260916.p0Q9G1pd029345@xs8.xs4all.nl> Message-ID: <07df01cbbd5e$a53fabe0$efbf03a0$@org> Thank you for the response... I should have made this a bit clearer - option 82 is an option on their DSLAM's today and is supposed to work "not bad". But this customer may also be looking at other services such as wireless in the future which does not support option 82 - they want a unified delivery of their product. I left out this detail as you can see ;) Also, the comment " so a customer doesn't have to configure his/her router to get online" is also interesting - we WANT our customers to configure their routers and understand them to a basic degree... this coming from a security perspective where we are seeing a magnitude to customer routers getting hacked or their wireless left open etc. Usage based billing is a very hot topic in this area (Ontario, Canada) and we will confirm with the customer today that they do indeed want to track all GB usage per customer... Today, they have no interest nor can they get IPv6 which is a shame.... having said that, we want to provide a solution to them than can do IPv6 in the future... Thanks, Paul -----Original Message----- From: Miquel van Smoorenburg [mailto:mikevs at xs4all.net] Sent: Wednesday, January 26, 2011 4:16 AM To: paul at paulstewart.org Cc: nanog at nanog.org Subject: Re: PPPOE vs DHCP In article <051001cbbcf0$c33e8b20$49bba160$@org> you write: >PPPOE vs DHCP >Allows full authentication of customers (requires username/password) You probably want to authenticate on circuit id, not username/password. ATM port/vpi/vci for ATM connections, or PPPoE circuit id tag added by the DSLAM or FTTH access switch when using an ethernet transport layer. It's just a different radius attribute to authenticate on, no magic. We do that so a customer doesn't have to configure his/her router to get online. >Easily assign static IP to customer (no MAC address or CPE information >required) Don't need that with DHCP either, if you run a DHCP server that can assign IP addresses based on option82. I run a patched ISC dhcp3 server, but I understand that ISC dhcp4 makes this pretty easy >Assign public subnet to customer with ease (no manual routing required) Don't need manual routing with DHCP either, if you use a real bras such as a juniper, since you can have it authenticate off radius first before doing DHCP, and in the radius reply you can return a static route. >Usage tracking (GB transfer) from radius generated data True, at least juniper e-series BRASes don't send radius accounting for atm rfc1483/bridged connections for some reason. >DHCP Cons > >--------- One more DHCP con is that if you have an ethernet transport network from the DSLAM or FTTH access switch to your router that lumps together multiple customers in one VLAN, something along the way is probably doing DHCP sniffing to set up routing. And you can be just about sure that won't work with IPv6. VLAN-per-customer will work (and is a really a great model, for all types of encapsulation) Mike. From ml at kenweb.org Wed Jan 26 08:07:05 2011 From: ml at kenweb.org (ML) Date: Wed, 26 Jan 2011 09:07:05 -0500 Subject: IPv6: numbering of point-to-point-links In-Reply-To: <AANLkTinxHFz83ykca7VpVo=XRJts7WGFP6G6+i2OB7R2@mail.gmail.com> References: <FC64B3384195884588D252343702D23F01854588@ICABEXCCLU01B.int.sonofon.dk> <AANLkTinxHFz83ykca7VpVo=XRJts7WGFP6G6+i2OB7R2@mail.gmail.com> Message-ID: <4D402A89.3040407@kenweb.org> On 1/24/2011 4:20 PM, Ray Soucy wrote: > That said. By not using the 64-bit boundary you may be sacrificing > performance optimizations with today's processors that lack operations > for values larger than 64-bits. Is this an issue for any known vendors today? From paul at paulstewart.org Wed Jan 26 08:12:00 2011 From: paul at paulstewart.org (Paul Stewart) Date: Wed, 26 Jan 2011 09:12:00 -0500 Subject: PPPOE vs DHCP In-Reply-To: <4D3FC2DE.9070704@brightok.net> References: <051001cbbcf0$c33e8b20$49bba160$@org> <4D3FC2DE.9070704@brightok.net> Message-ID: <07e201cbbd63$005c44d0$0114ce70$@org> > PPPOE Cons > > ---------- > > > > Requires PPPOE termination router (Juniper ERX for example) > You're putting Juniper ERXs at customer houses? Really? I'd expect to see DSL/Cable drops which will utilize cheap end CPE (most of which don't support IPv6 hardly at all). No, we're not putting ERX's at people's homes ... not sure where you got that from? What I was saying is that if you're running PPPOE then you have have somewhere in the service provider network to "terminate" the sessions.... Paul From jbates at brightok.net Wed Jan 26 08:30:48 2011 From: jbates at brightok.net (Jack Bates) Date: Wed, 26 Jan 2011 08:30:48 -0600 Subject: PPPOE vs DHCP In-Reply-To: <07e201cbbd63$005c44d0$0114ce70$@org> References: <051001cbbcf0$c33e8b20$49bba160$@org> <4D3FC2DE.9070704@brightok.net> <07e201cbbd63$005c44d0$0114ce70$@org> Message-ID: <4D403018.6070103@brightok.net> On 1/26/2011 8:12 AM, Paul Stewart wrote: > No, we're not putting ERX's at people's homes ... not sure where you got > that from? What I was saying is that if you're running PPPOE then you have > have somewhere in the service provider network to "terminate" the > sessions.... > Hey. It was the middle of the night. I completely misread which side of the termination you were referring to. Terminating PPPoE generally isn't much different than terminating VLANs. In Juniper world, it requires the right equipment. Cisco world, it's not generally a big deal. Jack From isabeldias1 at yahoo.com Wed Jan 26 08:39:36 2011 From: isabeldias1 at yahoo.com (isabel dias) Date: Wed, 26 Jan 2011 06:39:36 -0800 (PST) Subject: PPPOE vs DHCP In-Reply-To: <07df01cbbd5e$a53fabe0$efbf03a0$@org> References: <051001cbbcf0$c33e8b20$49bba160$@org> <201101260916.p0Q9G1pd029345@xs8.xs4all.nl> <07df01cbbd5e$a53fabe0$efbf03a0$@org> Message-ID: <52879.41791.qm@web121607.mail.ne1.yahoo.com> http://www.cisco.com/en/US/products/hw/routers/ps295/products_configuration_example09186a0080093e3b.shtml http://s-tools1.juniper.net/solutions/literature/white_papers/200187.pdf 3rd party vendors might want to have me onboard :-) otherwise you can come up w/ your own piece of kit, rfc' it and a few white papers bla and boom, start your own business like the others have done in the past .......... ? ________________________________ From: Paul Stewart <paul at paulstewart.org> To: Miquel van Smoorenburg <mikevs at xs4all.net> Cc: nanog at nanog.org Sent: Wed, January 26, 2011 1:40:49 PM Subject: RE: PPPOE vs DHCP Thank you for the response... I should have made this a bit clearer - option 82 is an option on their DSLAM's today and is supposed to work "not bad".? But this customer may also be looking at other services such as wireless in the future which does not support option 82 - they want a unified delivery of their product.? I left out this detail as you can see ;) Also, the comment " so a customer doesn't have to configure his/her router to get online" is also interesting - we WANT our customers to configure their routers and understand them to a basic degree... this coming from a security perspective where we are seeing a magnitude to customer routers getting hacked or their wireless left open etc. Usage based billing is a very hot topic in this area (Ontario, Canada) and we will confirm with the customer today that they do indeed want to track all GB usage per customer... Today, they have no interest nor can they get IPv6 which is a shame.... having said that, we want to provide a solution to them than can do IPv6 in the future... Thanks, Paul -----Original Message----- From: Miquel van Smoorenburg [mailto:mikevs at xs4all.net] Sent: Wednesday, January 26, 2011 4:16 AM To: paul at paulstewart.org Cc: nanog at nanog.org Subject: Re: PPPOE vs DHCP In article <051001cbbcf0$c33e8b20$49bba160$@org> you write: >PPPOE vs DHCP >Allows full authentication of customers (requires username/password) You probably want to authenticate on circuit id, not username/password. ATM port/vpi/vci for ATM connections, or PPPoE circuit id tag added by the DSLAM or FTTH access switch when using an ethernet transport layer. It's just a different radius attribute to authenticate on, no magic. We do that so a customer doesn't have to configure his/her router to get online. >Easily assign static IP to customer (no MAC address or CPE information >required) Don't need that with DHCP either, if you run a DHCP server that can assign IP addresses based on option82. I run a patched ISC dhcp3 server, but I understand that ISC dhcp4 makes this pretty easy >Assign public subnet to customer with ease (no manual routing required) Don't need manual routing with DHCP either, if you use a real bras such as a juniper, since you can have it authenticate off radius first before doing DHCP, and in the radius reply you can return a static route. >Usage tracking (GB transfer) from radius generated data True, at least juniper e-series BRASes don't send radius accounting for atm rfc1483/bridged connections for some reason. >DHCP Cons > >--------- One more DHCP con is that if you have an ethernet transport network from the DSLAM or FTTH access switch to your router that lumps together multiple customers in one VLAN, something along the way is probably doing DHCP sniffing to set up routing. And you can be just about sure that won't work with IPv6. VLAN-per-customer will work (and is a really a great model, for all types of encapsulation) Mike. From james.cutler at consultant.com Wed Jan 26 09:06:05 2011 From: james.cutler at consultant.com (Cutler James R) Date: Wed, 26 Jan 2011 10:06:05 -0500 Subject: Network Naming In-Reply-To: <4D3FA3DE.7040809@tiggee.com> References: <7aeb7ba0$10caab2c$7a5700bb$@com> <A584FE4D-62CF-4218-8D21-CF51628BDA76@consultant.com> <CF4687332659244DA0C2D1F53AFF9F83614953@sb-server-sbs.SharedComUK.local> <4D3FA3DE.7040809@tiggee.com> Message-ID: <1D839416-DDE9-4B82-8C88-63D642A85F5F@consultant.com> > I recommend documenting your naming standard and getting buy in across your organization before you put it into place. This is a necessary condition for successful deployment, but not part of the schema. On Jan 25, 2011, at 11:32 PM, David Miller wrote: > On 1/25/2011 8:15 PM, Gary Steers wrote: >> James makes a good point... >> >>> Pick a scheme which: >>> 1. Uses simple memorable names. >>> 2. Makes business sense to you. >>> 3. You know how to manage (database, publication, updates, etc. >>> If I had to weight these criteria, I would weight 3 most heavily. >> >> The other key thing to bear in mind is consistency and scalability... (i.e. design a scope that can grow with your network and needs >> >> {interface/server}.{router/vmhost}.{city}.{country}.example.net >> >> The other thing that doesn't really have any defined list is {city}, Some people prefer 2 letter, some 3 letter, some people use airport codes etc.. >> > > The naming schemes that I have developed that needed to be upgraded in the past have almost always bumped up against scale, so build in much larger scale than you ever think that you will need from the beginning. You have X devices now in Y locations, but your naming scheme should scale to X^Z devices in Y^Z locations. > > I agree that for network gear, this is is a good place to start (slightly simplified here from above): > > {interface}.{host}.{location}.example.net > > > - Location > I personally prefer UN LOCODEs for country / city. The UN already went to the trouble of giving a unique code to every country/city. Why do I use them? LON makes perfect sense as London, England... until you have devices in London, KY and London, OH (the LOCODES for these Londons are GB LON, US LDN, US LOZ). In my opinion, airport codes (while certainly unique) work well in some locales and not so well in others (so, I don't use them, YMMV). > > - Host > I prefer, like many do, an acronym denoting the primary function of the device. ES (edge switch), AR (access router), CR (core router), etc... whatever your internal terminology is. If you will *ever* have more than 10 of a device anywhere, then I would recommend that you number out of double digits (more than 100, then out of triple digits...). That way in a sorted list AR03 will be right between AR02 and AR04, where you expect it to be, instead of between AR29 and AR30. Standardizing on number length also limits ambiguity in pressure situations and/or over noisy or less reliable communication channels. > > - Interface > Port names vary on gear from different vendors. {interface type} - {selector}* ... where selector repeats ordered from highest to lowest level of granularity (e.g. rack/slot/module/port) is what I use. You should use whatever makes sense to you. Are interface speeds or vlans important to your infrastructure? If so, then include them where appropriate. Unless you have exactly the same gear everywhere, you are going to have to be flexible here. > > I recommend documenting your naming standard and getting buy in across your organization before you put it into place. By giving names to these devices/interfaces at all, you are exposing information to the world. What makes perfect sense to engineering and support may give security, management, and/or marketing heart palpitations. > > Just my $0.02 (probably overvalued). > >> Hope that helps! >> >> G >> >> --- >> Gary Steers >> Sharedband NOC/3rd Line Support >> Sharedband >> UK: +44 (0)1473 287207 >> US: +1 206 420 0240 >> E: gary.steers at sharedband.com >> >> We have a new support system - http://support.sharedband.com >> >> >> -----Original Message----- >> From: Cutler James R [mailto:james.cutler at consultant.com] >> Sent: 25 January 2011 22:41 >> To: nanog group >> Subject: Re: Network Naming >> >> On Jan 25, 2011, at 3:50 PM, Nick Olsen wrote: >> >>> Whats the rule of thumb for naming gear these days >>> (routers,switches...etc). Or is there one? >> Pick a scheme which: >> 1. Uses simple memorable names. >> 2. Makes business sense to you. >> 3. You know how to manage (database, publication, updates, etc. >> >> If I had to weight these criteria, I would weight 3 most heavily. >> >> >> James R. Cutler >> james.cutler at consultant.com >> >> >> >> >> >> > > James R. Cutler james.cutler at consultant.com From bblackford at gmail.com Wed Jan 26 09:33:56 2011 From: bblackford at gmail.com (Bill Blackford) Date: Wed, 26 Jan 2011 07:33:56 -0800 Subject: Network Naming In-Reply-To: <4D3FA3DE.7040809@tiggee.com> References: <7aeb7ba0$10caab2c$7a5700bb$@com> <A584FE4D-62CF-4218-8D21-CF51628BDA76@consultant.com> <CF4687332659244DA0C2D1F53AFF9F83614953@sb-server-sbs.SharedComUK.local> <4D3FA3DE.7040809@tiggee.com> Message-ID: <AANLkTimDqzmz_wg8x0-sqJ+5iCotPwguOx0K2qoFuSi5@mail.gmail.com> What I found when visiting this in my own organization that being an Enterprise and "pseudo" service provider, is that naming fits into several categories. 1. Hostnames/Prompts 2. Rack Switches in Data centers 3. Path. Meaning routed interfaces that the world sees in the form of PTR records. Prompts: {Organization}-{Site}-{Dist_Frame}-{Device_Type}{Number} MYCORP-HQ-2B-S1 (My_Corp., headquarters, 2nd Fl idfb, switch1. Another way I've named prompts is with relative DNS suffix. This tends to work best with routers, not so much for rack or access gear. ex, CAR1.INAP.STTL# full DNS name: car1.inap.sttl.my-corp.net Racks: Same as above just replacing frame with rack# Path: {Interface_Type}{number}.{Device_Type}{number}.{Geo_Location}.{org_fqdn} For interface type I've been sticking to the Juniper convention as I find it more consistent than that of Ciscos. I have a document that describes the convention of every field of every type in order to maintain consistency. What I struggle with is trying to find a consistent naming convention for gear behind the firewall vs. on the outside that is publicly visible. -b -- Bill Blackford Network Engineer Logged into reality and abusing my sudo privileges..... From tim at pelican.org Wed Jan 26 09:36:02 2011 From: tim at pelican.org (Tim Franklin) Date: Wed, 26 Jan 2011 15:36:02 +0000 (GMT) Subject: PPPOE vs DHCP In-Reply-To: <4D403018.6070103@brightok.net> Message-ID: <23842845.31296056161980.JavaMail.root@jennyfur.pelican.org> > Terminating PPPoE generally isn't much different than terminating > VLANs. In Juniper world, it requires the right equipment. Cisco > world, it's not generally a big deal. Unless, for example, you already sunk a chunk of change into Cisco 10Ks, and now want IPv6 on your PPPoE. Not that I'm becomming increasingly bitter about that platform or anything... Regards, Tim. From psirt at cisco.com Wed Jan 26 09:39:07 2011 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 26 Jan 2011 10:39:07 -0500 Subject: Cisco Security Advisory: Cisco Content Services Gateway Vulnerabilities Message-ID: <201101261039.csg2@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Cisco Security Advisory: Cisco Content Services Gateway Vulnerabilities Advisory ID: cisco-sa-20110126-csg2 http://www.cisco.com/warp/public/707/cisco-sa-20110126-csg2.shtml Revision 1.0 For Public Release 2011 January 26 1600 UTC (GMT) +--------------------------------------------------------------------- Summary ======= A service policy bypass vulnerability exists in the Cisco Content Services Gateway - Second Generation (CSG2), which runs on the Cisco Service and Application Module for IP (SAMI). Under certain configurations this vulnerability could allow: * Customers to access sites that would normally match a billing policy to be accessed without being charged to the end customer * Customers to access sites that would normally be denied based on configured restriction policies Additionally, Cisco IOS Software Release 12.4(24)MD1 on the Cisco CSG2 contains two vulnerabilities that can be exploited by a remote, unauthenticated attacker to create a denial of service condition that prevents traffic from passing through the CSG2. These vulnerabilities require only a single content service to be active on the Cisco CSG2 and can be exploited via crafted TCP packets. A three-way handshake is not required to exploit either of these vulnerabilities. Workarounds that mitigate these vulnerabilities are not available. This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20110126-csg2.shtml. Affected Products ================= The service policy bypass vulnerability affects all versions of the Cisco IOS Software for the CSG2 prior to the first fixed release, as indicated in the "Software Versions and Fixes" section of this advisory. The two denial of service vulnerabilities only affect Cisco IOS Software Release 12.4(24)MD1 on the Cisco CSG2. No other Cisco IOS Software releases are affected. Vulnerable Products +------------------ To determine the version of Cisco IOS Software that is running on the Cisco CSG2, issue the "show module" command from Cisco IOS Software on the switch on which the Cisco CSG2 module is installed to identify what modules and sub-modules are installed on the system. Cisco CSG2 runs on the Cisco Service and Application Module for IP (SAMI) card, and is identified in the following example in slot 2 via the WS-SVC-SAMI-BB-K9 identification: C7600#show module Mod Ports Card Type Model Serial No. --- ----- -------------------------------------- ------------------ ----------- 1 2 Supervisor Engine 720 (Active) WS-SUP720-3BXL JAF1226ARQS 2 1 SAMI Module (csgk9) WS-SVC-SAMI-BB-K9 SAD113906P1 4 48 CEF720 48 port 10/100/1000mb Ethernet WS-X6748-GE-TX SAL1127T6XY Mod MAC addresses Hw Fw Sw Status --- ---------------------------------- ------ ------------ ------------ ------- 1 001e.be6e.a018 to 001e.be6e.a01b 5.6 8.5(2) 12.2(33)SRC5 Ok 2 001d.45f8.f3dc to 001d.45f8.f3e3 2.1 8.7(0.22)FW1 12.4(2010040 Ok 4 001c.587a.ef20 to 001c.587a.ef4f 2.6 12.2(14r)S5 12.2(33)SRC5 Ok Mod Sub-Module Model Serial Hw Status ---- --------------------------- ------------------ ----------- ------- ------- 1 Policy Feature Card 3 WS-F6K-PFC3BXL JAF1226BNQM 1.8 Ok 1 MSFC3 Daughterboard WS-SUP720 JAF1226BNMC 3.1 Ok 2 SAMI Daughterboard 1 SAMI-DC-BB SAD114400L9 1.1 Other 2 SAMI Daughterboard 2 SAMI-DC-BB SAD114207FU 1.1 Other 4 Centralized Forwarding Card WS-F6700-CFC SAL1029VGFK 2.0 Ok Mod Online Diag Status ---- ------------------- 1 Pass 2 Pass 4 Pass C7600# After locating the correct slot, issue the "session slot <module number> processor <3-9>" command to open a console connection to the respective Cisco CSG2. Once connected to the Cisco CSG2, perform the "show version" command: The following example shows that the Cisco CSG2 is running software Release 12.4(24)MD1: CSG2#show version Cisco IOS Software, SAMI Software (SAMI-CSGK9-M), Version 12.4(24)MD1, RELEASE SOFTWARE (fc2) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2010 by Cisco Systems, Inc. Compiled Wed 07-Apr-10 09:50 by prod_rel_team --- output truncated --- Products Confirmed Not Vulnerable +-------------------------------- The Cisco Content Services Gateway - 1st Generation (CSG) is not affected by these vulnerabilities. No other Cisco products are currently known to be affected by these vulnerabilities. Details ======= The Cisco Content Services Gateway - Second Generation (CSG2) provides intelligent network capabilities such as flexible policy management and billing based on deep-packet inspection, as well as subscriber and application awareness capabilities that enable mobile operators to quickly and easily offer value-added, differentiated services over their mobile data networks. The service policy bypass vulnerability affects configurations that allow end users to first access non-accounted or billed sites. After a user accesses a non-accounted site, it is possible to access other sites that are defined by a billing service policy or to access sites that may be blocked by other policies by sending specially crafted HTTP packets. This vulnerability only affects HTTP content traffic. HTTPS and other traffic types are not affected. Both denial of service vulnerabilities require only a single content service to be active on the Cisco CSG2 and can be exploited via crafted TCP packets. A three-way handshake is not required to exploit either of these vulnerabilities. The vulnerabilities are triggered by TCP traffic that transits the Cisco CSG2. The service policy bypass vulnerability is documented in Cisco Bug ID CSCtk35917 and has been assigned CVE ID CVE-2011-0348. The denial of service bugs are documented in Cisco Bug ID CSCth17178 and Cisco Bug ID CSCth41891 and have been assigned CVE IDs CVE-2011-0349 and CVE-2011-0350 respectively. Vulnerability Scoring Details ============================= Cisco has provided scores for the vulnerabilities in this advisory based on the Common Vulnerability Scoring System (CVSS). The CVSS scoring in this Security Advisory is done in accordance with CVSS version 2.0. CVSS is a standards-based scoring method that conveys vulnerability severity and helps determine urgency and priority of response. Cisco has provided a base and temporal score. Customers can then compute environmental scores to assist in determining the impact of the vulnerability in individual networks. Cisco has provided an FAQ to answer additional questions regarding CVSS at: http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html Cisco has also provided a CVSS calculator to help compute the environmental impact for individual networks at: http://intellishield.cisco.com/security/alertmanager/cvss * CSCtk35917 ("Service Policy Bypass Vulnerability") CVSS Base Score - 6.4 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - Partial Integrity Impact - Partial Availability Impact - None CVSS Temporal Score - 5.3 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed * CSCth41891/CSCth17178 ("Crafted TCP packet causes CSG2 to restart") CVSS Base Score - 7.8 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - None Integrity Impact - None Availability Impact - Complete CVSS Temporal Score - 6.4 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed Impact ====== Successful exploitation of the service policy bypass can allow customers to obtain access to sites that would normally be accounted and billed according to the billing policy without the billing policy being engaged. Additionally, customers could gain access to URLs that are configured in the Cisco CSG2 to be explicitly denied. Successful exploitation of either denial of service vulnerability could result in the Cisco CSG2 reloading or potentially hanging. Due to Cisco Bug ID CSCtg50821, the Cisco CSG2 may not automatically recover and may require a manual reload of the SAMI card by issuing the "hw-module module <x> reset" CLI command from the switch. Software Versions and Fixes =========================== When considering software upgrades, also consult http://www.cisco.com/go/psirt and any subsequent advisories to determine exposure and a complete upgrade solution. In all cases, customers should exercise caution to be certain the devices to be upgraded contain sufficient memory and that current hardware and software configurations will continue to be supported properly by the new release. If the information is not clear, contact the Cisco Technical Assistance Center (TAC) or your contracted maintenance provider for assistance. Each row of the Cisco IOS Software table (below) names a Cisco IOS release train. If a release train is vulnerable, then the earliest possible releases that contain the fix (along with the anticipated date of availability for each, if applicable) are listed in the "First Fixed Release" column of the table. The "Recommended Release" column indicates the releases which have fixes for all the published vulnerabilities at the time of this Advisory. A device running a release in the given train that is earlier than the release in a specific column (less than the First Fixed Release) is known to be vulnerable. Cisco recommends upgrading to a release equal to or later than the release in the "Recommended Releases" column of the table. +---------------------------------------------------------------+ | Major | Availability of Repaired Releases | | Release | | |------------+--------------------------------------------------| | Affected | | | 12.x-Based | First Fixed Release | | Releases | | |------------+--------------------------------------------------| | 12.0 - | 12.0 through 12.3 based releases are not | | 12.3 | affected | |------------+--------------------------------------------------| | Affected | First Fixed Release | | 12.4-Based |--------------------------------------------------| | Releases | DoS | Service Policy Bypass | | | Vulnerabilities | Vulnerability | |------------+------------------+-------------------------------| | | All 12.4(11)MD | | | | releases are not | All 12.4(11)MD releases are | | | affected. | affected. Migrate to a fixed | | | | release. | | | All 12.4(15)MD | | | | releases are not | All 12.4(15)MD releases are | | | affected. | affected. Migrate to a fixed | | | | release. | | | All 12.4(22)MD | | | 12.4MD | releases are not | All 12.4(22)MD releases are | | | affected. | affected. Migrate to a fixed | | | | release. | | | Releases prior | | | | to 12.4(24)MD1 | All 12.4(24)MD releases prior | | | are not | to 12.4(24)MD3 are affected. | | | affected. | | | | | First fixed in 12.4(24)MD3 | | | First fixed in | | | | 12.4(24)MD2 | | |------------+------------------+-------------------------------| | | | All 12.4(22)MDA releases | | | | prior to 12.4(22)MDA5 are | | | | affected. First fixed in 12.4 | | | No releases | (22)MDA5 | | 12.4MDA | affected. | | | | | All 12.4(24)MDA releases | | | | prior to 12.4(24)MDA3 are | | | | affected. First fixed in 12.4 | | | | (24)MDA3 | |------------+--------------------------------------------------| | Affected | | | 15.X-Based | First Fixed Release | | Releases | | |------------+--------------------------------------------------| | 15.0 - | 15.0 through 15.1 based releases are not | | 15.1 | affected | +---------------------------------------------------------------+ Cisco IOS Software for the CSG2 is located on Cisco Software Download center at the following location: Cisco Interfaces and Modules --> Cisco Services Modules --> Cisco Service Application Module for IP. Workarounds =========== There are no workarounds for these vulnerabilities. Obtaining Fixed Software ======================== Cisco has released free software updates that address these vulnerabilities. Prior to deploying software, customers should consult their maintenance provider or check the software for feature set compatibility and known issues specific to their environment. Customers may only install and expect support for the feature sets they have purchased. By installing, downloading, accessing or otherwise using such software upgrades, customers agree to be bound by the terms of Cisco's software license terms found at http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html, or as otherwise set forth at Cisco.com Downloads at http://www.cisco.com/public/sw-center/sw-usingswc.shtml. Do not contact psirt at cisco.com or security-alert at cisco.com for software upgrades. Customers with Service Contracts +------------------------------- Customers with contracts should obtain upgraded software through their regular update channels. For most customers, this means that upgrades should be obtained through the Software Center on Cisco's worldwide website at http://www.cisco.com. Customers using Third Party Support Organizations +------------------------------------------------ Customers whose Cisco products are provided or maintained through prior or existing agreements with third-party support organizations, such as Cisco Partners, authorized resellers, or service providers should contact that support organization for guidance and assistance with the appropriate course of action in regards to this advisory. The effectiveness of any workaround or fix is dependent on specific customer situations, such as product mix, network topology, traffic behavior, and organizational mission. Due to the variety of affected products and releases, customers should consult with their service provider or support organization to ensure any applied workaround or fix is the most appropriate for use in the intended network before it is deployed. Customers without Service Contracts +---------------------------------- Customers who purchase direct from Cisco but do not hold a Cisco service contract, and customers who purchase through third-party vendors but are unsuccessful in obtaining fixed software through their point of sale should acquire upgrades by contacting the Cisco Technical Assistance Center (TAC). TAC contacts are as follows. * +1 800 553 2447 (toll free from within North America) * +1 408 526 7209 (toll call from anywhere in the world) * e-mail: tac at cisco.com Customers should have their product serial number available and be prepared to give the URL of this notice as evidence of entitlement to a free upgrade. Free upgrades for non-contract customers must be requested through the TAC. Refer to http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html for additional TAC contact information, including localized telephone numbers, and instructions and e-mail addresses for use in various languages. Exploitation and Public Announcements ===================================== The Cisco PSIRT is aware of public announcements of the service billing bypass vulnerability on some external blog sites. However the Cisco PSIRT is not aware of any malicious use of the vulnerabilities described in this advisory. These vulnerabilities were found by both internal testing and when handling customer support calls. Status of this Notice: FINAL ============================ THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS DOCUMENT AT ANY TIME. A stand-alone copy or Paraphrase of the text of this document that omits the distribution URL in the following section is an uncontrolled copy, and may lack important information or contain factual errors. Distribution ============ This advisory is posted on Cisco's worldwide website at: http://www.cisco.com/warp/public/707/cisco-sa-20110126-csg2.shtml In addition to worldwide web posting, a text version of this notice is clear-signed with the Cisco PSIRT PGP key and is posted to the following e-mail and Usenet news recipients. * cust-security-announce at cisco.com * first-bulletins at lists.first.org * bugtraq at securityfocus.com * vulnwatch at vulnwatch.org * cisco at spot.colorado.edu * cisco-nsp at puck.nether.net * full-disclosure at lists.grok.org.uk * comp.dcom.sys.cisco at newsgate.cisco.com Future updates of this advisory, if any, will be placed on Cisco's worldwide website, but may or may not be actively announced on mailing lists or newsgroups. Users concerned about this problem are encouraged to check the above URL for any updates. Revision History ================ +------------------------------------------------------------+ | Revision 1.0 | 2011-January-26 | Initial public release. | +------------------------------------------------------------+ Cisco Security Procedures ========================= Complete information on reporting security vulnerabilities in Cisco products, obtaining assistance with security incidents, and registering to receive security information from Cisco, is available on Cisco's worldwide website at http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html. This includes instructions for press inquiries regarding Cisco security notices. All Cisco security advisories are available at http://www.cisco.com/go/psirt. +-------------------------------------------------------------------- Copyright 2010-2011 Cisco Systems, Inc. All rights reserved. +-------------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iF4EAREIAAYFAk1APx0ACgkQQXnnBKKRMNBE4QD/WfH2GXgAJub+4ech0JhHizBO 98PLNKENutVsJpa0eCUA/2hKwfofNSloEh7i5JZXrwKFcjgBYJcPnDa1W2JRHSfZ =EZt9 -----END PGP SIGNATURE----- From rps at maine.edu Wed Jan 26 09:55:56 2011 From: rps at maine.edu (Ray Soucy) Date: Wed, 26 Jan 2011 10:55:56 -0500 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <58166C50-0B72-43A0-8AB8-25E803EA1619@delong.com> References: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com> <AANLkTimcZavnJN2gqayS2-piDvOAcw_nrJAREJ0EDTjp@mail.gmail.com> <AANLkTikHBb+cyfPxXftb5QZh136D04fkdWFMy3NFhDdi@mail.gmail.com> <4D3F0144.70107@sohonet.co.uk> <58166C50-0B72-43A0-8AB8-25E803EA1619@delong.com> Message-ID: <AANLkTikYUBOznThu5915+2-y0DoKGLc6OWnToT+QeaZj@mail.gmail.com> I think we're losing focus on the discussion here. The core issue here is that ND tables have a finite size, just like ARP tables. Making an unsolicited request to a subnet will cause ND on the router to try and reach find the host. This can be a problem with subnets as small as 1024 (I constantly find people using Linux-based routers, for example, running with the kernel default ARP table of 127 instead of bumping it up to a sane and network appropriate level). I don't believe that using smaller IPv6 prefixes is an appropriate response to the problem. In time, we will likely see protection mechanisms come from vendors. Perhaps disabling the ability for routers to solicit ND and just depend on connected hosts to announce their presence would be sufficient. Perhaps not. It is something that needs to be looked into, just like DAD DoS attacks, and rogue RA on the LAN. But it has little to do with prefix length. When it comes down to it. I find it hard to justify attempting to mitigate this DoS vector by using longer prefixes. There are many many more useful and effective DoS vectors that are lower-hanging fruit. And the lowest hanging fruit always wins. On Tue, Jan 25, 2011 at 1:42 PM, Owen DeLong <owen at delong.com> wrote: > > On Jan 25, 2011, at 8:58 AM, Patrick Sumby wrote: > >> On 24/01/2011 22:41, Michael Loftis wrote: >>> On Mon, Jan 24, 2011 at 1:53 PM, Ray Soucy<rps at maine.edu> ?wrote: >>> >>>> Many cite concerns of potential DoS attacks by doing sweeps of IPv6 >>>> networks. ?I don't think this will be a common or wide-spread problem. >>>> ?The general feeling is that there is simply too much address space >>>> for it to be done in any reasonable amount of time, and there is >>>> almost nothing to be gained from it. >>> >>> The problem I see is the opening of a new, simple, DoS/DDoS scenario. >>> By repetitively sweeping a targets /64 you can cause EVERYTHING in >>> that /64 to stop working by overflowing the ND/ND cache, depending on >>> the specific ND cache implementation and how big it is/etc. ?Routers >>> can also act as amplifiers too, DDoSing every host within a multicast >>> ND directed solicitation group (and THAT is even assuming a correctly >>> functioning switch thats limiting the multicast travel) > > I love this term... "repetitively sweeping a targets /64". > > Seriously? Repetitively sweeping a /64? Let's do the math... > > 2^64 = 18,446,744,073,709,551,616 IP addresses. > > Let's assume that few networks would not be DOS'd by a 1,000 PPS > storm coming in so that's a reasonable cap on our scan rate. > > That means sweeping a /64 takes 18,446,744,073,709,551 sec. > (rounded down). > > There are 86,400 seconds per day. > > 18,446,744,073,709,551 / 86,400 = 213,503,982,334 days. > > Rounding a year down to 365 days, that's 584,942,417 > years to sweep the /64 once. > > If we increase our scan rate to 1,000,000 packets > per second, it still takes us 584,942 years to sweep > a /64. > > I don't know about you, but I do not expect to live long > enough to sweep a /64, let alone do so repetitively. > > Owen > > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From jbates at brightok.net Wed Jan 26 10:33:58 2011 From: jbates at brightok.net (Jack Bates) Date: Wed, 26 Jan 2011 10:33:58 -0600 Subject: PPPOE vs DHCP In-Reply-To: <23842845.31296056161980.JavaMail.root@jennyfur.pelican.org> References: <23842845.31296056161980.JavaMail.root@jennyfur.pelican.org> Message-ID: <4D404CF6.1000104@brightok.net> On 1/26/2011 9:36 AM, Tim Franklin wrote: >> Terminating PPPoE generally isn't much different than terminating >> VLANs. In Juniper world, it requires the right equipment. Cisco >> world, it's not generally a big deal. > > Unless, for example, you already sunk a chunk of change into Cisco 10Ks, and now want IPv6 on your PPPoE. Not that I'm becomming increasingly bitter about that platform or anything... > 10K isn't supporting IPv6 on PPPoE? I thought the 10K specialized in utilizing the IOS SR line. I've played with PPPoE and bridging on the 7200s mostly. I need to kick up an ASR, as I hear it's specialized code line has much better IPv6 support than IOS SR. both XR/XE codes seem to be much more richly featured, especially for radius backending DHCP. Jack From tim at pelican.org Wed Jan 26 11:03:19 2011 From: tim at pelican.org (Tim Franklin) Date: Wed, 26 Jan 2011 17:03:19 +0000 (GMT) Subject: PPPOE vs DHCP In-Reply-To: <4D404CF6.1000104@brightok.net> Message-ID: <31322983.91296061399385.JavaMail.root@jennyfur.pelican.org> > 10K isn't supporting IPv6 on PPPoE? I thought the 10K specialized in > utilizing the IOS SR line. I've played with PPPoE and bridging on the > 7200s mostly. I need to kick up an ASR, as I hear it's specialized > code line has much better IPv6 support than IOS SR. both XR/XE codes > seem to be much more richly featured, especially for radius backending > DHCP. So they're telling us, at least for PPPoE specifically. Cisco solution is "buy ASR". Regards, Tim. From owen at delong.com Wed Jan 26 11:01:40 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 26 Jan 2011 09:01:40 -0800 Subject: Future of the IPv6 CPE survey on RIPE Labs - Your Input Needed In-Reply-To: <AANLkTinkMg+n6z8nZbxBD+9uRe5BBc2c+ceExbNQgqFp@mail.gmail.com> References: <1164463.290.1296018492548.JavaMail.franck@franck-martins-macbook-pro.local> <alpine.BSF.2.00.1101260856400.69156@mignon.ki.iif.hu> <31362582-C2A9-45CC-A3E9-13EB5743C957@delong.com> <AANLkTinkMg+n6z8nZbxBD+9uRe5BBc2c+ceExbNQgqFp@mail.gmail.com> Message-ID: <CB7A959F-1A6F-4F3E-B937-F7F3C09C85F5@delong.com> I haven't done exhaustive testing, but, it has to do with certain combinations of IPv4 configurations and IPv6 routing do work and other combinations don't. Owen On Jan 26, 2011, at 4:41 AM, Richard Barnes wrote: > Could you elaborate? Which circumstances? > > On Wed, Jan 26, 2011 at 4:23 AM, Owen DeLong <owen at delong.com> wrote: >> It works for routing native IPv6 under some circumstances as well. >> >> Owen >> >> On Jan 26, 2011, at 12:01 AM, Mohacsi Janos wrote: >> >>> >>> >>> >>> On Wed, 26 Jan 2011, Franck Martin wrote: >>> >>>> What about an Airport Extreme? It has a wan interface that does PPPOE >>>> >>>> The IPv6 feature seems working, with 6to4 or static tunnels and a basic IPv6 firewall. >>> >>> Yes it is. I already reported to Marco. >>> http://labs.ripe.net/Members/marco/content-ipv6-cpe-survey >>> >>> It should be included somehow in a matrix But 6to4 (or other tunneling techniques) is only a substitute of real IPv6. >>> >>> Regards, >>> Janos Mohacsi >>> >>>> >>>> ----- Original Message ----- >>>> From: "Mirjam Kuehne" <mir at ripe.net> >>>> To: nanog at nanog.org >>>> Sent: Tuesday, 25 January, 2011 3:34:14 AM >>>> Subject: Future of the IPv6 CPE survey on RIPE Labs - Your Input Needed >>>> >>>> [apologies for duplicates] >>>> >>>> Hello, >>>> >>>> Based on new information we received since the last publication, we >>>> updated the IPv6 CPE matrix: >>>> >>>> http://labs.ripe.net/Members/mirjam/ipv6-cpe-survey-updated-january-2011 >>>> >>>> In order to make this information more useful for a large user base, we >>>> are preparing a detailed survey to gather more structural feedback about >>>> the range of equipment that is currently in use. Not only would we like >>>> you to participate in this survey, but we also ask for your help in >>>> identifying the right survey questions. Please find a call for input on >>>> RIPE Labs: >>>> >>>> http://labs.ripe.net/Members/marco/future-of-the-ipv6-cpe-survey-more-input-needed >>>> >>>> Kind Regards, >>>> Mirjam Kuehne & Marco Hogewoning >>>> RIPE NCC >>>> >>>> >>>> >> >> >> From owen at delong.com Wed Jan 26 11:05:48 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 26 Jan 2011 09:05:48 -0800 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <63907.1295993236@localhost> References: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com> <AANLkTimcZavnJN2gqayS2-piDvOAcw_nrJAREJ0EDTjp@mail.gmail.com> <op.vpt734cxtfhldh@rbeam.xactional.com> <8B0D83FB-38DD-4C4D-9870-5913425BA3A2@delong.com> <op.vpvur91htfhldh@rbeam.xactional.com> <63907.1295993236@localhost> Message-ID: <43F4D716-FA9A-4771-9A65-9888D14AC221@delong.com> On Jan 25, 2011, at 2:07 PM, Valdis.Kletnieks at vt.edu wrote: > On Tue, 25 Jan 2011 16:17:59 EST, Ricky Beam said: >> On Mon, 24 Jan 2011 19:46:19 -0500, Owen DeLong <owen at delong.com> wrote: >>> Dude... In IPv6, there are 18,446,744,073,709,551,616 /64s. >> >> Those who don't learn from history are doomed to repeat it. >> >> "Dude, there are 256 /8 in IPv4." >> >> "640k ought to be enough for anyone." >> >> People can mismange anything into oblivion. IPv6 will end up the same >> mess IPv4 has become. (granted, it should take more than 30 years this >> time.) > > To burn through all the /48s in 100 years, we'll have to use them up > at the rate of 89,255 *per second*. > > That implies either *really* good aggregation, or your routers having enough > CPU to handle the BGP churn caused by 90K new prefixes arriving on the Internet > per second. Oh, and hot-pluggable memory, you'll need another terabyte of RAM > every few hours. At that point, running out of prefixes is the *least* of your > worries. > This presumes that we don't run out of /48s by installing them in routers a /20 at a time. Owen From jbates at brightok.net Wed Jan 26 11:59:26 2011 From: jbates at brightok.net (Jack Bates) Date: Wed, 26 Jan 2011 11:59:26 -0600 Subject: Future of the IPv6 CPE survey on RIPE Labs - Your Input Needed In-Reply-To: <CB7A959F-1A6F-4F3E-B937-F7F3C09C85F5@delong.com> References: <1164463.290.1296018492548.JavaMail.franck@franck-martins-macbook-pro.local> <alpine.BSF.2.00.1101260856400.69156@mignon.ki.iif.hu> <31362582-C2A9-45CC-A3E9-13EB5743C957@delong.com> <AANLkTinkMg+n6z8nZbxBD+9uRe5BBc2c+ceExbNQgqFp@mail.gmail.com> <CB7A959F-1A6F-4F3E-B937-F7F3C09C85F5@delong.com> Message-ID: <4D4060FE.1000504@brightok.net> I believe it has to do with IPv6 mechanisms for handling native addressing. I haven't had the opportunity to test it myself, but from dealing with other vendors, I find that they all support subsets of possible configurations. For example, we test the following with each CPE device which supports IPv6 and is up for consideration. 1) 6to4 support 2) SLAAC + DHCPv6-PD on bridging wan (haven't found one yet, and I believe still the only setup for IOS) 3) DHCPv6 IA_TA requests + DHCPv6-PD (too bad IOS SR doesn't support this yet?) 4) Support of RA to determine default route (seen many require manual gateway configurations since DHCPv6 won't send a default router option) 5) PPPoE/A with above combinations 6) PPPoE/A unnumbered ptp + DHCPv6-PD 7) /60 and /48 DHCPv6-PD and how they are assigned by the CPE 8) DHCPv6 IA_TA, SLAAC, and DHCPv6-PD support on the device's LAN and determining the mechanism it uses 9) Default stateful firewall rules for IPv6. 10) Support for static assignments and routing for IPv6 (many devices are still working on dynamic support and have no manual support) I've yet to find a consumer grade product which meets all of these different configurations; especially in the $50 range. Jack On 1/26/2011 11:01 AM, Owen DeLong wrote: > I haven't done exhaustive testing, but, it has to do with certain combinations > of IPv4 configurations and IPv6 routing do work and other combinations > don't. > > Owen > > On Jan 26, 2011, at 4:41 AM, Richard Barnes wrote: > >> Could you elaborate? Which circumstances? >> >> On Wed, Jan 26, 2011 at 4:23 AM, Owen DeLong<owen at delong.com> wrote: >>> It works for routing native IPv6 under some circumstances as well. >>> >>> Owen >>> >>> On Jan 26, 2011, at 12:01 AM, Mohacsi Janos wrote: >>> >>>> >>>> >>>> >>>> On Wed, 26 Jan 2011, Franck Martin wrote: >>>> >>>>> What about an Airport Extreme? It has a wan interface that does PPPOE >>>>> >>>>> The IPv6 feature seems working, with 6to4 or static tunnels and a basic IPv6 firewall. >>>> >>>> Yes it is. I already reported to Marco. >>>> http://labs.ripe.net/Members/marco/content-ipv6-cpe-survey >>>> >>>> It should be included somehow in a matrix But 6to4 (or other tunneling techniques) is only a substitute of real IPv6. >>>> >>>> Regards, >>>> Janos Mohacsi >>>> >>>>> >>>>> ----- Original Message ----- >>>>> From: "Mirjam Kuehne"<mir at ripe.net> >>>>> To: nanog at nanog.org >>>>> Sent: Tuesday, 25 January, 2011 3:34:14 AM >>>>> Subject: Future of the IPv6 CPE survey on RIPE Labs - Your Input Needed >>>>> >>>>> [apologies for duplicates] >>>>> >>>>> Hello, >>>>> >>>>> Based on new information we received since the last publication, we >>>>> updated the IPv6 CPE matrix: >>>>> >>>>> http://labs.ripe.net/Members/mirjam/ipv6-cpe-survey-updated-january-2011 >>>>> >>>>> In order to make this information more useful for a large user base, we >>>>> are preparing a detailed survey to gather more structural feedback about >>>>> the range of equipment that is currently in use. Not only would we like >>>>> you to participate in this survey, but we also ask for your help in >>>>> identifying the right survey questions. Please find a call for input on >>>>> RIPE Labs: >>>>> >>>>> http://labs.ripe.net/Members/marco/future-of-the-ipv6-cpe-survey-more-input-needed >>>>> >>>>> Kind Regards, >>>>> Mirjam Kuehne& Marco Hogewoning >>>>> RIPE NCC >>>>> >>>>> >>>>> >>> >>> >>> > > From jbates at brightok.net Wed Jan 26 12:04:19 2011 From: jbates at brightok.net (Jack Bates) Date: Wed, 26 Jan 2011 12:04:19 -0600 Subject: PPPOE vs DHCP In-Reply-To: <31322983.91296061399385.JavaMail.root@jennyfur.pelican.org> References: <31322983.91296061399385.JavaMail.root@jennyfur.pelican.org> Message-ID: <4D406223.4010104@brightok.net> On 1/26/2011 11:03 AM, Tim Franklin wrote: > So they're telling us, at least for PPPoE specifically. Cisco solution is "buy ASR". > This is same solution they've given for the 7206 and other traditional IOS platforms. I haven't checked, but all the RBE/unnumbered vlan support for IPv6 with proxy-ND, better radius backend for DHCPv6, and supposedly IA_TA support for DHCPv6 will be in the ASR only. The features in IOS SR train are somewhat functional but extremely limited. If I find myself having to spend money on ASRs, I may just spend the money replacing them with Juniper. Only reason I haven't is that I haven't needed to spend the money at all. Jack From charles at knownelement.com Wed Jan 26 12:22:40 2011 From: charles at knownelement.com (Charles N Wyble) Date: Wed, 26 Jan 2011 10:22:40 -0800 Subject: Ipv6 for the content provider Message-ID: <4D406670.8040202@knownelement.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, All the recurring threads about prefix length, security posture, ddos, consumer CPE support have been somewhat interesting to my service provider alter ego. Ipv6 is definitely on folks minds this year. The threads seem a lot less trollish as well. It appears some significant progress is being made, and peoples opinions are firming up. Hopefully this will help move ipv6 adoption forward. I have recently turned up an ipv6 tunnel with he.net and have end to end connectivity. I'm using pfsense as my routing platform. It was pretty easy (about 10 minutes of total work I think). So I can connect to various ipv6 enabled sites on the interwebz. This seems to be the first step in deployment. For the most part, I'm a data center/application administrator/content provider kind of guy. As such, I want to provide all my web content over ipv6, and support ipv6 SMTP. What are folks doing in this regard? Do I just need to assign ip addresses to my servers, add AAAA records to my DNS server and that's it? I'm running PowerDNS for DNS, Apache for WWW. Postfix for SMTP. Feel free to point me at any good manuals and say RTFM :) - -- Charles N Wyble (charles at knownelement.com) Systems craftsman for the stars http://www.knownelement.com Mobile: 626 539 4344 Office: 310 929 8793 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNQGZvAAoJEMvvG/TyLEAt9ykP/ROLSWz3LmAF78OMBEhWEMvX MjOVR2QK6kQ3byV8WLro95tCOuyo8L8fUC60KyFh4XRsedb7xk6S8cTER80zmGzG rOAFVpNyJ1QzCcf4MYpj8xHn9zM6Fywft4VzKQEgDvlV8yD0VZKJi+fNj4noZ5oK tmM1s9Is5db3d5ldrC6M54TQJsbaZiuz+FrFtpkENraJIWlOeU3laM6kvwzvYpok BKtnaY6zBq42QovpJ+MU+lmanCB6Z0r3e2cSB+N7XJL0Va/Y2IW/eZn35S+dE3xk y7RPSZu2jDxJ6atQJVIBpjfL6oqUUr+0RHc+gX4VJyOrwpEuJQ/GvTiRDTUZkA0A twhvQnS6yc5G8L+iwID4YqkVKNCFcJUtAHUntqmy1FqTe9iQSlZdUPPhKrkRE7zW B2S2T0Lv6a/neHU5yfsGjiYbIAy7keXoiMPbR4ZJxC/KkogfWNgMZBVpjGVn0NI4 COOymyFYgvQFiXIpvmpQn0iLFcWmmGdwV2DPvxMArdmfw2SeyipJiBSeeEbb4ZG4 kw1LOrI7+OGnoDEByAtkZPh42wAbXbrSw9WeWvphAsQ2dAmASqXUKuHTDXd1laCC yi37NTRmWACNHKcVEhpk3saJDCsPPVx6ECYfhSsSALZDn6696BvFXZnN2423Fmk7 dtMKM38+rxz9r4IL5O+n =Mi6R -----END PGP SIGNATURE----- From jack at crepinc.com Wed Jan 26 12:38:48 2011 From: jack at crepinc.com (Jack Carrozzo) Date: Wed, 26 Jan 2011 13:38:48 -0500 Subject: Ipv6 for the content provider In-Reply-To: <4D406670.8040202@knownelement.com> References: <4D406670.8040202@knownelement.com> Message-ID: <AANLkTinj7NQE5BbWcV92PYyZOU2+xeu5OXz=yYUUK1ot@mail.gmail.com> Bind and apache work with v6 out of the box, and have for years. As I understand it, when a client requests a particular domain of yours and gets an A and an AAAA, the client will default to the AAAA (assuming it's on a v6 network) and attempt to communicate as such. Failing that, it will fall back to the v4 A record. So in short, yes, it's as simple as telling the daemons to listen on your v6 addresses and adding the AAAA records. Just think how happy your 1 client/customer using IPv6 will be ;-) -Jack Carrozzo On Wed, Jan 26, 2011 at 1:22 PM, Charles N Wyble <charles at knownelement.com>wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello, > > > All the recurring threads about prefix length, security posture, ddos, > consumer CPE support have been somewhat interesting to my service > provider alter ego. Ipv6 is definitely on folks minds this year. The > threads seem a lot less trollish as well. It appears some significant > progress is being made, and peoples opinions are firming up. Hopefully > this will help move ipv6 adoption forward. > > I have recently turned up an ipv6 tunnel with he.net and have end to end > connectivity. I'm using pfsense as my routing platform. It was pretty > easy (about 10 minutes of total work I think). So I can connect to > various ipv6 enabled sites on the interwebz. This seems to be the first > step in deployment. > > > For the most part, I'm a data center/application administrator/content > provider kind of guy. As such, I want to provide all my web content over > ipv6, and support ipv6 SMTP. What are folks doing in this regard? > > Do I just need to assign ip addresses to my servers, add AAAA records to > my DNS server and that's it? I'm running PowerDNS for DNS, Apache for > WWW. Postfix for SMTP. > > Feel free to point me at any good manuals and say RTFM :) > > > > - -- > Charles N Wyble (charles at knownelement.com) > Systems craftsman for the stars > http://www.knownelement.com > Mobile: 626 539 4344 > Office: 310 929 8793 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQIcBAEBAgAGBQJNQGZvAAoJEMvvG/TyLEAt9ykP/ROLSWz3LmAF78OMBEhWEMvX > MjOVR2QK6kQ3byV8WLro95tCOuyo8L8fUC60KyFh4XRsedb7xk6S8cTER80zmGzG > rOAFVpNyJ1QzCcf4MYpj8xHn9zM6Fywft4VzKQEgDvlV8yD0VZKJi+fNj4noZ5oK > tmM1s9Is5db3d5ldrC6M54TQJsbaZiuz+FrFtpkENraJIWlOeU3laM6kvwzvYpok > BKtnaY6zBq42QovpJ+MU+lmanCB6Z0r3e2cSB+N7XJL0Va/Y2IW/eZn35S+dE3xk > y7RPSZu2jDxJ6atQJVIBpjfL6oqUUr+0RHc+gX4VJyOrwpEuJQ/GvTiRDTUZkA0A > twhvQnS6yc5G8L+iwID4YqkVKNCFcJUtAHUntqmy1FqTe9iQSlZdUPPhKrkRE7zW > B2S2T0Lv6a/neHU5yfsGjiYbIAy7keXoiMPbR4ZJxC/KkogfWNgMZBVpjGVn0NI4 > COOymyFYgvQFiXIpvmpQn0iLFcWmmGdwV2DPvxMArdmfw2SeyipJiBSeeEbb4ZG4 > kw1LOrI7+OGnoDEByAtkZPh42wAbXbrSw9WeWvphAsQ2dAmASqXUKuHTDXd1laCC > yi37NTRmWACNHKcVEhpk3saJDCsPPVx6ECYfhSsSALZDn6696BvFXZnN2423Fmk7 > dtMKM38+rxz9r4IL5O+n > =Mi6R > -----END PGP SIGNATURE----- > > From gbonser at seven.com Wed Jan 26 12:39:46 2011 From: gbonser at seven.com (George Bonser) Date: Wed, 26 Jan 2011 10:39:46 -0800 Subject: Ipv6 for the content provider In-Reply-To: <4D406670.8040202@knownelement.com> References: <4D406670.8040202@knownelement.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC1361D@RWC-EX1.corp.seven.com> > From: Charles N Wyble > Sent: Wednesday, January 26, 2011 10:23 AM > To: nanog at nanog.org > Subject: Ipv6 for the content provider > > For the most part, I'm a data center/application administrator/content > provider kind of guy. As such, I want to provide all my web content > over > ipv6, and support ipv6 SMTP. What are folks doing in this regard? > > Do I just need to assign ip addresses to my servers, add AAAA records > to > my DNS server and that's it? I'm running PowerDNS for DNS, Apache for > WWW. Postfix for SMTP. > > Feel free to point me at any good manuals and say RTFM :) Most load balancers these days will allow you to provision an IPv6 virtual IP that balances to v4 servers. So you can provide services over v6 without a lot of changes inside your network. You will need a DNS server that hands out AAAA records though. From owen at delong.com Wed Jan 26 12:46:31 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 26 Jan 2011 10:46:31 -0800 Subject: Ipv6 for the content provider In-Reply-To: <4D406670.8040202@knownelement.com> References: <4D406670.8040202@knownelement.com> Message-ID: <F53714F3-6199-44B8-9519-79467D961544@delong.com> > > Do I just need to assign ip addresses to my servers, add AAAA records to > my DNS server and that's it? I'm running PowerDNS for DNS, Apache for > WWW. Postfix for SMTP. > It might be that simple, it might not. Depends on your application. For the DNS and Mail, it should be pretty much that simple. I don't know about the state of Postfix (don't use it), but, sendmail has been IPv6 ready for years and I'm running with it no problem. As to the web, Apache is fully IPv6 ready and that's easy. It will take IPv6 addresses in all the same places you would configure IPv4 addresses. You do need to enclose the address portion in brackets with the port number outside the brackets. e.g.: 2620:0:930::400:7 on port 80 = [2620:0:930::400:7]:80 Other considerations that may be important: 1. Load balancers 2. Log parsers 3. UI stuff that accepts or reports IP addresses Application Site Administration CMS 4. Databases that contain IP address(es) 5. Other tools, files, etc. that may interact with IP addresses All of those things will need additional attention as you add IPv6 capabilities to your site. Some sites have to worry about all 5. Some sites don't have to worry about any of these things. I was able to do all the web sites I host at home just by adding the appropriate Apache configs and putting in the AAAA records next to the A records. Took me about an hour for a couple dozen sites. I've received exactly zero user complaints since the IPv6 implementation. More complex environments may take considerably more effort. Owen From owen at delong.com Wed Jan 26 12:47:41 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 26 Jan 2011 10:47:41 -0800 Subject: Ipv6 for the content provider In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC1361D@RWC-EX1.corp.seven.com> References: <4D406670.8040202@knownelement.com> <5A6D953473350C4B9995546AFE9939EE0BC1361D@RWC-EX1.corp.seven.com> Message-ID: <024EC9AD-2FD3-406A-A3DA-868152F33187@delong.com> On Jan 26, 2011, at 10:39 AM, George Bonser wrote: > > >> From: Charles N Wyble >> Sent: Wednesday, January 26, 2011 10:23 AM >> To: nanog at nanog.org >> Subject: Ipv6 for the content provider >> >> For the most part, I'm a data center/application administrator/content >> provider kind of guy. As such, I want to provide all my web content >> over >> ipv6, and support ipv6 SMTP. What are folks doing in this regard? >> >> Do I just need to assign ip addresses to my servers, add AAAA records >> to >> my DNS server and that's it? I'm running PowerDNS for DNS, Apache for >> WWW. Postfix for SMTP. >> >> Feel free to point me at any good manuals and say RTFM :) > > > Most load balancers these days will allow you to provision an IPv6 > virtual IP that balances to v4 servers. So you can provide services > over v6 without a lot of changes inside your network. You will need a > DNS server that hands out AAAA records though. > > And if your servers behind the LB aren't prepared for it, you lose a LOT of logging data, geolocation capabilities, and some other things if you go that route. Owen From graham at apolix.co.za Wed Jan 26 12:50:27 2011 From: graham at apolix.co.za (Graham Beneke) Date: Wed, 26 Jan 2011 20:50:27 +0200 Subject: Ipv6 for the content provider In-Reply-To: <4D406670.8040202@knownelement.com> References: <4D406670.8040202@knownelement.com> Message-ID: <4D406CF3.4030401@apolix.co.za> On 26/01/2011 20:22, Charles N Wyble wrote: > For the most part, I'm a data center/application administrator/content > provider kind of guy. As such, I want to provide all my web content over > ipv6, and support ipv6 SMTP. What are folks doing in this regard? > > Do I just need to assign ip addresses to my servers, add AAAA records to > my DNS server and that's it? I'm running PowerDNS for DNS, Apache for > WWW. Postfix for SMTP. I haven't worked with Postfix recently but Exim on a default config will start talking IPv6 as soon as it has connectivity. Just be careful of this since you need to make sure that all your rDNS, SPF, etc ducks are in a row before you give it IPv6 since it can start delivering mail via IPv6 with very little encouragement. With Apache I've had some funnies with how it binds (or fails) to IPv4 and IPv6 sockets at startup. Once you're over that hurdle I've found that the majority of open source web apps either support IPv6 or are designed correctly to not be impacted by other layers in the network stack. Its important to keep a close eye on logs and also don't roll out to all your servers in one go. The gradual migration to dual stack has been fairly painless for me. -- Graham Beneke From bicknell at ufp.org Wed Jan 26 12:55:26 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 26 Jan 2011 10:55:26 -0800 Subject: Ipv6 for the content provider In-Reply-To: <4D406670.8040202@knownelement.com> References: <4D406670.8040202@knownelement.com> Message-ID: <20110126185526.GA79278@ussenterprise.ufp.org> In a message written on Wed, Jan 26, 2011 at 10:22:40AM -0800, Charles N Wyble wrote: > For the most part, I'm a data center/application administrator/content > provider kind of guy. As such, I want to provide all my web content over > ipv6, and support ipv6 SMTP. What are folks doing in this regard? > > Do I just need to assign ip addresses to my servers, add AAAA records to > my DNS server and that's it? I'm running PowerDNS for DNS, Apache for > WWW. Postfix for SMTP. The layer 3 part for you is really simple. Here's a deployment model we use a number of places. I'm going to assume you have a /48, from ARIN or your upstream. Lay out your networks as: AAAA:BBBB:CCCC:<vlan>::/64 The AAAA:BBBB:CCCC::/48 was given to you by ARIN/your upstream. For VLAN I recommend being human friendly and making vlan 10 be AAAA:BBBB:CCCC:0010::/64, even though that's technically 16 in Hex. The vlan's consume 4096 of your 65536 subnets, so you still have many more to play with. Want to know what address to configure, well, you can guess if you know the vlan number. We then also do the same thing with the address, if it's a static server. Say the server was 10.2.50.210. We re-use the 210 part, and get AAAA:BBBB:CCCC:0010::210, assuming it is on VLAN 10. So you assign addresses to your boxes, decide if you want static default routes or want to allow them to learn a default via RA, and well, you're basically done for Layer 3. Application level support on Linux/FreeBSD/NetBSD is 98% and rising every day. Apache, BIND, Postfix, they all work great. The "problem" is you may need config adjustment. Your Apache ListenOn's will need IPv6 added, your Postfix "local nets" ACL will need your IPv6 addresses added, and so on. And that is the crux of the migration issue. Updating all the configuration in all the apps to both do the right thing and be secure in IPv6. That is where all of your work will be, particualrly if you have custom systems to manage IP's or configs. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110126/e7217531/attachment.bin> From david.freedman at uk.clara.net Wed Jan 26 13:10:58 2011 From: david.freedman at uk.clara.net (David Freedman) Date: Wed, 26 Jan 2011 19:10:58 +0000 Subject: Ipv6 for the content provider In-Reply-To: <024EC9AD-2FD3-406A-A3DA-868152F33187@delong.com> References: <4D406670.8040202@knownelement.com> <5A6D953473350C4B9995546AFE9939EE0BC1361D@RWC-EX1.corp.seven.com> <024EC9AD-2FD3-406A-A3DA-868152F33187@delong.com> Message-ID: <ihprk2$g39$1@dough.gmane.org> >> >> > And if your servers behind the LB aren't prepared for it, you lose a LOT > of logging data, geolocation capabilities, and some other things if you > go that route. > > Owen > > > I can't imagine an LB vendor who would sell a v6 to v4 vip solution who wouldn't provide a way to inject the v6 addr in to the request as an additional header? I suggest a naming-and-shaming is in order -- David Freedman Group Network Engineering Claranet Group From ljakab at ac.upc.edu Wed Jan 26 13:13:48 2011 From: ljakab at ac.upc.edu (=?ISO-8859-1?Q?Lor=E1nd_Jakab?=) Date: Wed, 26 Jan 2011 20:13:48 +0100 Subject: Ipv6 for the content provider In-Reply-To: <F53714F3-6199-44B8-9519-79467D961544@delong.com> References: <4D406670.8040202@knownelement.com> <F53714F3-6199-44B8-9519-79467D961544@delong.com> Message-ID: <4D40726C.5080604@ac.upc.edu> On 01/26/2011 07:46 PM, Owen DeLong wrote: >> Do I just need to assign ip addresses to my servers, add AAAA records to >> my DNS server and that's it? I'm running PowerDNS for DNS, Apache for >> WWW. Postfix for SMTP. >> > It might be that simple, it might not. Depends on your application. > > For the DNS and Mail, it should be pretty much that simple. I don't know > about the state of Postfix (don't use it), but, sendmail has been IPv6 > ready for years and I'm running with it no problem. I run a low traffic mail server with Postfix, and setting up IPv6 was as easy as adding AAAA records for the MX-es and enabling 'inet_protocols = all' in main.cf -Lorand Jakab From tony at lava.net Wed Jan 26 13:17:08 2011 From: tony at lava.net (Antonio Querubin) Date: Wed, 26 Jan 2011 09:17:08 -1000 (HST) Subject: Ipv6 for the content provider In-Reply-To: <4D406670.8040202@knownelement.com> References: <4D406670.8040202@knownelement.com> Message-ID: <alpine.OSX.2.00.1101260905210.211@cust11794.lava.net> On Wed, 26 Jan 2011, Charles N Wyble wrote: > Do I just need to assign ip addresses to my servers, add AAAA records to > my DNS server and that's it? I'm running PowerDNS for DNS, Apache for > WWW. Postfix for SMTP. Best to remove IP version dependencies in your configs. If you are using name-based virtual hosting in Apache, convert: Listen a.b.c.d:80 -> Listen 80 <Virtualhost a.b.c.d:80> -> <Virtualhost *:80> Use hard-coded IP addresses only where required for stuff like SSL-enabled webhosts. In postfix just add to main.cf: inet_interfaces = all inet_protocols = all And make sure your MX hostnames have AAAA RRs. Antonio Querubin e-mail/xmpp: tony at lava.net From ftigeot at wolfpond.org Wed Jan 26 13:17:10 2011 From: ftigeot at wolfpond.org (Francois Tigeot) Date: Wed, 26 Jan 2011 20:17:10 +0100 Subject: Ipv6 for the content provider In-Reply-To: <4D406670.8040202@knownelement.com> References: <4D406670.8040202@knownelement.com> Message-ID: <20110126191710.GB1495@sekishi.zefyris.com> On Wed, Jan 26, 2011 at 10:22:40AM -0800, Charles N Wyble wrote: > For the most part, I'm a data center/application administrator/content > provider kind of guy. As such, I want to provide all my web content over > ipv6, and support ipv6 SMTP. What are folks doing in this regard? > > Do I just need to assign ip addresses to my servers, add AAAA records to > my DNS server and that's it? I'm running PowerDNS for DNS, Apache for > WWW. Postfix for SMTP. Depending on your local configuration, you may have to change some minor options (e.g add a IPv6 Listen line for Apache), but yeah, in general it's as simple as adding an AAAA record in the DNS. The only troublesome applications I still encounter these days are Munin (monitoring stuff: http://www.munin-monitoring.org/) and anything that's Java based. If its running on a IPv6-enabled host, Java wants to use IPv6 sockets for everything - including IPv4 connections. Most modern operating systems do not allow this; you have to force the use of either IPv4 or IPv6 and disable the other protocol. I had to put these options in a Tomcat startup script: -Djava.net.preferIPv4Stack=false -Djava.net.preferIPv6Addresses=true -- Francois Tigeot From gbonser at seven.com Wed Jan 26 13:18:50 2011 From: gbonser at seven.com (George Bonser) Date: Wed, 26 Jan 2011 11:18:50 -0800 Subject: Ipv6 for the content provider In-Reply-To: <20110126185526.GA79278@ussenterprise.ufp.org> References: <4D406670.8040202@knownelement.com> <20110126185526.GA79278@ussenterprise.ufp.org> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13622@RWC-EX1.corp.seven.com> > > Application level support on Linux/FreeBSD/NetBSD is 98% and rising > every day. Apache, BIND, Postfix, they all work great. The "problem" > is you may need config adjustment. Your Apache ListenOn's will need > IPv6 added, your Postfix "local nets" ACL will need your IPv6 addresses > added, and so on. > > And that is the crux of the migration issue. Updating all the > configuration in all the apps to both do the right thing and be secure > in IPv6. That is where all of your work will be, particualrly if you > have custom systems to manage IP's or configs. > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ We're still having some problems with linux and java. For example, a v6 socket is supposed to support either protocol. But for some reason, and I don't know if this is just one particular kernel, if communications is attempted under some circumstances with a v4 address on a dual-stacked host, the packets go out on the wire with v6 mapped v4 addresses (::ffff:x.x.x.x) which isn't supposed to happen. So everything isn't quite there yet for dual-stacking all applications. The "safest" approach on paper is v6 native using NAT64/DNS64 but getting the NAT64 piece in place at production quality and scale is a problem at this point. From gbonser at seven.com Wed Jan 26 13:22:06 2011 From: gbonser at seven.com (George Bonser) Date: Wed, 26 Jan 2011 11:22:06 -0800 Subject: Ipv6 for the content provider In-Reply-To: <024EC9AD-2FD3-406A-A3DA-868152F33187@delong.com> References: <4D406670.8040202@knownelement.com> <5A6D953473350C4B9995546AFE9939EE0BC1361D@RWC-EX1.corp.seven.com> <024EC9AD-2FD3-406A-A3DA-868152F33187@delong.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13624@RWC-EX1.corp.seven.com> > And if your servers behind the LB aren't prepared for it, you lose a > LOT > of logging data, geolocation capabilities, and some other things if you > go that route. > > Owen Relying on IP address for geolocation is actually quite ridiculous though I do realize that many people seem to believe that you can map an IP address to the physical location of the originator of the data, at least to the country level, but I suppose some people will sell you anything. We haven't seen any problem with logging data so far in our testing. From tony at lava.net Wed Jan 26 13:23:20 2011 From: tony at lava.net (Antonio Querubin) Date: Wed, 26 Jan 2011 09:23:20 -1000 (HST) Subject: Ipv6 for the content provider In-Reply-To: <alpine.OSX.2.00.1101260905210.211@cust11794.lava.net> References: <4D406670.8040202@knownelement.com> <alpine.OSX.2.00.1101260905210.211@cust11794.lava.net> Message-ID: <alpine.OSX.2.00.1101260919580.211@cust11794.lava.net> On Wed, 26 Jan 2011, Antonio Querubin wrote: > Best to remove IP version dependencies in your configs. > > If you are using name-based virtual hosting in Apache, convert: > > Listen a.b.c.d:80 -> Listen 80 > <Virtualhost a.b.c.d:80> -> <Virtualhost *:80> > > Use hard-coded IP addresses only where required for stuff like SSL-enabled > webhosts. > > In postfix just add to main.cf: > > inet_interfaces = all > inet_protocols = all > > And make sure your MX hostnames have AAAA RRs. One additional note. Add your IPv6 prefixes to mynetworks. The IPv6 prefix should be enclosed in brackets before the prefix length. Ie. the IPv6 loopback would be added as [::1]/128. Antonio Querubin e-mail/xmpp: tony at lava.net From dwcarder at wisc.edu Wed Jan 26 13:41:37 2011 From: dwcarder at wisc.edu (Dale W. Carder) Date: Wed, 26 Jan 2011 13:41:37 -0600 Subject: Ipv6 for the content provider In-Reply-To: <AANLkTinj7NQE5BbWcV92PYyZOU2+xeu5OXz=yYUUK1ot@mail.gmail.com> References: <4D406670.8040202@knownelement.com> <AANLkTinj7NQE5BbWcV92PYyZOU2+xeu5OXz=yYUUK1ot@mail.gmail.com> Message-ID: <20110126194136.GI71684@ricotta.doit.wisc.edu> Thus spake Jack Carrozzo (jack at crepinc.com) on Wed, Jan 26, 2011 at 01:38:48PM -0500: > As I understand it, when a client requests a particular domain of yours and gets > an A and an AAAA, the client will default to the AAAA (assuming it's on a v6 > network) and attempt to communicate as such. Failing that, it will fall back > to the v4 A record. This is true for now. See http://tools.ietf.org/html/draft-wing-v6ops-happy-eyeballs-ipv6 for a proposal on how this could change. Dale From dwcarder at wisc.edu Wed Jan 26 13:45:12 2011 From: dwcarder at wisc.edu (Dale W. Carder) Date: Wed, 26 Jan 2011 13:45:12 -0600 Subject: Ipv6 for the content provider In-Reply-To: <20110126185526.GA79278@ussenterprise.ufp.org> References: <4D406670.8040202@knownelement.com> <20110126185526.GA79278@ussenterprise.ufp.org> Message-ID: <20110126194512.GJ71684@ricotta.doit.wisc.edu> Thus spake Leo Bicknell (bicknell at ufp.org) on Wed, Jan 26, 2011 at 10:55:26AM -0800: > > The layer 3 part for you is really simple. Here's a deployment model we > use a number of places. I'm going to assume you have a /48, from ARIN > or your upstream. > > Lay out your networks as: > AAAA:BBBB:CCCC:<vlan>::/64 > > The AAAA:BBBB:CCCC::/48 was given to you by ARIN/your upstream. > For VLAN I recommend being human friendly and making vlan 10 be > AAAA:BBBB:CCCC:0010::/64, even though that's technically 16 in Hex. At our site, we very strongly discourage mapping like this. Your addressing plan will outlive your infrastructure, and you will be stuck with it until renumbering is no longer hard. Dale From mloftis at wgops.com Wed Jan 26 14:24:27 2011 From: mloftis at wgops.com (Michael Loftis) Date: Wed, 26 Jan 2011 13:24:27 -0700 Subject: IPv6 filtering In-Reply-To: <4D3FB5D8.3060408@willingminds.com> References: <32507261.286.1296018229100.JavaMail.franck@franck-martins-macbook-pro.local> <1ECA3D3E-A5B7-49A5-8516-FCEBBB3FBE7E@delong.com> <4D3FB5D8.3060408@willingminds.com> Message-ID: <AANLkTimPSwxaY7tDz9cgvhL-pxxkgNA4A0TjpxA_C=+R@mail.gmail.com> On Tue, Jan 25, 2011 at 10:49 PM, Mark D. Nagel <mnagel at willingminds.com> wrote: > This can bite you in unexpected ways, too. ?For example, on a Cisco ASA, > if you add a system-level 'icmpv6 permit' line and if this does not > include ND, then you break ND responses to the ASA. ?This is much unlike > ARP, which is unaffected by 'icmp permit' statements for IPv4. ?And, the > default with no such lines is to permit all ICMP/ICMPv6 to the ASA. This > seems so obvious in retrospect, but at the time was a bit of a > head-scratcher. > ARP is a seperate protocol supporting IPv4 ... For IPv6 ND is done using ICMPv6 messages. A bit confusing transitioning from IPv4/ARP for sure. > Mark From owen at delong.com Wed Jan 26 14:33:48 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 26 Jan 2011 12:33:48 -0800 Subject: Ipv6 for the content provider In-Reply-To: <ihprk2$g39$1@dough.gmane.org> References: <4D406670.8040202@knownelement.com> <5A6D953473350C4B9995546AFE9939EE0BC1361D@RWC-EX1.corp.seven.com> <024EC9AD-2FD3-406A-A3DA-868152F33187@delong.com> <ihprk2$g39$1@dough.gmane.org> Message-ID: <DFC8C53F-9D03-4A68-B652-6BAFF8ED93C4@delong.com> On Jan 26, 2011, at 11:10 AM, David Freedman wrote: >>> >>> >> And if your servers behind the LB aren't prepared for it, you lose a LOT >> of logging data, geolocation capabilities, and some other things if you >> go that route. >> >> Owen >> >> >> > > I can't imagine an LB vendor who would sell a v6 to v4 vip solution who > wouldn't provide a way to inject the v6 addr in to the request as an > additional header? I suggest a naming-and-shaming is in order > Sure, but, if you're not prepared to parse, log, and deal with that header, then, you lose, right? Note I said "IF your servers behind the LB aren't prepared for it..." Owen From owen at delong.com Wed Jan 26 14:40:49 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 26 Jan 2011 12:40:49 -0800 Subject: Ipv6 for the content provider In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13624@RWC-EX1.corp.seven.com> References: <4D406670.8040202@knownelement.com> <5A6D953473350C4B9995546AFE9939EE0BC1361D@RWC-EX1.corp.seven.com> <024EC9AD-2FD3-406A-A3DA-868152F33187@delong.com> <5A6D953473350C4B9995546AFE9939EE0BC13624@RWC-EX1.corp.seven.com> Message-ID: <9863522D-BE25-48EA-A07A-BEA7495FCF1B@delong.com> On Jan 26, 2011, at 11:22 AM, George Bonser wrote: >> And if your servers behind the LB aren't prepared for it, you lose a >> LOT >> of logging data, geolocation capabilities, and some other things if > you >> go that route. >> >> Owen > > Relying on IP address for geolocation is actually quite ridiculous > though I do realize that many people seem to believe that you can map an > IP address to the physical location of the originator of the data, at > least to the country level, but I suppose some people will sell you > anything. > > We haven't seen any problem with logging data so far in our testing. > I don't disagree, but, since people like Wells Fargo are using it as a security check (ask me about my experiences trying to log in from Rwanda to check on a mortgage payment some time), things that potentially make it even more broken than it is are worth pointing out to administrators that may be stuck implementing IPv6 on sites that may have such dependencies. Owen From owen at delong.com Wed Jan 26 14:39:16 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 26 Jan 2011 12:39:16 -0800 Subject: Ipv6 for the content provider In-Reply-To: <alpine.OSX.2.00.1101260905210.211@cust11794.lava.net> References: <4D406670.8040202@knownelement.com> <alpine.OSX.2.00.1101260905210.211@cust11794.lava.net> Message-ID: <DF3C7AD3-2065-4228-9525-70022E768C7C@delong.com> On Jan 26, 2011, at 11:17 AM, Antonio Querubin wrote: > On Wed, 26 Jan 2011, Charles N Wyble wrote: > >> Do I just need to assign ip addresses to my servers, add AAAA records to >> my DNS server and that's it? I'm running PowerDNS for DNS, Apache for >> WWW. Postfix for SMTP. > > Best to remove IP version dependencies in your configs. > > If you are using name-based virtual hosting in Apache, convert: > > Listen a.b.c.d:80 -> Listen 80 > <Virtualhost a.b.c.d:80> -> <Virtualhost *:80> > That only works if you have only one address on the machine and. If you have addresses that aren't intended for name-based-site-A but do terminate SSL connections to sites B, C, and D, then you probably don't want to use * for site A. > Use hard-coded IP addresses only where required for stuff like SSL-enabled webhosts. > Depends on the complexity of your environment. In a more complex configuration you can actually save yourself a lot of trouble and confusion later by using a construct like this: Listen 192.159.10.7:80 Listen [2620:0:930::dead:beef:cafe]:80 Listen [2620:0:930::400:7]:80 <VirtualHost 192.159.10.7:80 [2620:0:930::400:7]:80 [2620:0:930::dead:beef:cafe] :80> ServerName www.delong.com ... YMMV, but, that's working reliably in my environment for: [root at owen conf]# host www.delong.com www.delong.com has address 192.159.10.7 www.delong.com has IPv6 address 2620:0:930::400:7 (The dead:beef:cafe address isn't currently in the AAAAs that are publicly visible because it's used for testing specialized testing from different DNS views.) The machine in question has a number of IPv4 and IPv6 addresses many of which terminate HTTP/HTTPs connections, some of which do not. Owen From owen at delong.com Wed Jan 26 14:44:24 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 26 Jan 2011 12:44:24 -0800 Subject: Ipv6 for the content provider In-Reply-To: <20110126191710.GB1495@sekishi.zefyris.com> References: <4D406670.8040202@knownelement.com> <20110126191710.GB1495@sekishi.zefyris.com> Message-ID: <E3870C8B-6D62-46F9-87D6-CCC04E31BCEA@delong.com> On Jan 26, 2011, at 11:17 AM, Francois Tigeot wrote: > On Wed, Jan 26, 2011 at 10:22:40AM -0800, Charles N Wyble wrote: >> For the most part, I'm a data center/application administrator/content >> provider kind of guy. As such, I want to provide all my web content over >> ipv6, and support ipv6 SMTP. What are folks doing in this regard? >> >> Do I just need to assign ip addresses to my servers, add AAAA records to >> my DNS server and that's it? I'm running PowerDNS for DNS, Apache for >> WWW. Postfix for SMTP. > > Depending on your local configuration, you may have to change some minor > options (e.g add a IPv6 Listen line for Apache), but yeah, in general it's > as simple as adding an AAAA record in the DNS. > > The only troublesome applications I still encounter these days are > Munin (monitoring stuff: http://www.munin-monitoring.org/) and anything > that's Java based. > > If its running on a IPv6-enabled host, Java wants to use IPv6 sockets for > everything - including IPv4 connections. If you're not on a broken BSD or Windows implementation, that shouldn't be a problem. It would be nice if BSD would correct their IPV6_V6ONLY behavior instead of putting up an alleged security red herring. I'm not sure why Micr0$0ft suffers from this braindeath. > Most modern operating systems do not allow this; you have to force the use > of either IPv4 or IPv6 and disable the other protocol. > Not true. Other than BSD/Windows, most modern operating systems actually follow the RFCs in this regard. Even most of the BSD derivatives will allow you to correctly set IPV6_V6ONLY=False to correct the errant default behavior. Owen From owen at delong.com Wed Jan 26 14:47:03 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 26 Jan 2011 12:47:03 -0800 Subject: Ipv6 for the content provider In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13622@RWC-EX1.corp.seven.com> References: <4D406670.8040202@knownelement.com> <20110126185526.GA79278@ussenterprise.ufp.org> <5A6D953473350C4B9995546AFE9939EE0BC13622@RWC-EX1.corp.seven.com> Message-ID: <1C50EC26-1D17-4DE8-9762-A4F5AE5A35B4@delong.com> On Jan 26, 2011, at 11:18 AM, George Bonser wrote: >> >> Application level support on Linux/FreeBSD/NetBSD is 98% and rising >> every day. Apache, BIND, Postfix, they all work great. The "problem" >> is you may need config adjustment. Your Apache ListenOn's will need >> IPv6 added, your Postfix "local nets" ACL will need your IPv6 > addresses >> added, and so on. >> >> And that is the crux of the migration issue. Updating all the >> configuration in all the apps to both do the right thing and be secure >> in IPv6. That is where all of your work will be, particualrly if you >> have custom systems to manage IP's or configs. >> >> -- >> Leo Bicknell - bicknell at ufp.org - CCIE 3440 >> PGP keys at http://www.ufp.org/~bicknell/ > > We're still having some problems with linux and java. For example, a v6 > socket is supposed to support either protocol. But for some reason, and > I don't know if this is just one particular kernel, if communications is > attempted under some circumstances with a v4 address on a dual-stacked > host, the packets go out on the wire with v6 mapped v4 addresses > (::ffff:x.x.x.x) which isn't supposed to happen. So everything isn't > quite there yet for dual-stacking all applications. The "safest" > approach on paper is v6 native using NAT64/DNS64 but getting the NAT64 > piece in place at production quality and scale is a problem at this > point. > > That's definitely a bug. Mapped addresses should never hit the wire. Dual stack is quite a bit safer than NAT64/DNS64. The bug you describe should be fairly trivial to get fixed if someone can isolate which product actually has the bug. Have you tried the current kernel under the existing other components? If swapping the kernel doesn't fix it (I think the mapped address on the wire bugs in the Linux kernel were removed fairly early in the 2.6 chain IIRC), then it's probably Java. Owen From tesparza at covad.com Wed Jan 26 15:05:38 2011 From: tesparza at covad.com (Tony Esparza) Date: Wed, 26 Jan 2011 13:05:38 -0800 Subject: Multiple WAN setup for Bridge customers on Ericsson SmartEdge Platform In-Reply-To: <1C50EC26-1D17-4DE8-9762-A4F5AE5A35B4@delong.com> References: <4D406670.8040202@knownelement.com> <20110126185526.GA79278@ussenterprise.ufp.org> <5A6D953473350C4B9995546AFE9939EE0BC13622@RWC-EX1.corp.seven.com> <1C50EC26-1D17-4DE8-9762-A4F5AE5A35B4@delong.com> Message-ID: <4EF4BF1E8F43894386584BE36354494A05B85F579E@ZANEMS01.cc-ntd1.covad.com> Hello, I was wondering if anyone has successfully deployed a multi WAN product using encapsulation bridge1483 on the Ericsson SmartEdge platform. Please hit me offline, I can forward you my configs. Tony From gbonser at seven.com Wed Jan 26 15:18:16 2011 From: gbonser at seven.com (George Bonser) Date: Wed, 26 Jan 2011 13:18:16 -0800 Subject: Ipv6 for the content provider In-Reply-To: <1C50EC26-1D17-4DE8-9762-A4F5AE5A35B4@delong.com> References: <4D406670.8040202@knownelement.com> <20110126185526.GA79278@ussenterprise.ufp.org> <5A6D953473350C4B9995546AFE9939EE0BC13622@RWC-EX1.corp.seven.com> <1C50EC26-1D17-4DE8-9762-A4F5AE5A35B4@delong.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC1362C@RWC-EX1.corp.seven.com> > That's definitely a bug. Mapped addresses should never hit the wire. > > Dual stack is quite a bit safer than NAT64/DNS64. The bug you describe > should be fairly trivial to get fixed if someone can isolate which > product > actually has the bug. Have you tried the current kernel under the > existing > other components? If swapping the kernel doesn't fix it (I think the > mapped address on the wire bugs in the Linux kernel were removed > fairly early in the 2.6 chain IIRC), then it's probably Java. > > Owen It was a fairly recent kernel (2.6.31-19 #56 Ubuntu) and uptime on the machine I was testing on is a bit less than a year so it hasn't been updated in a while. I will try it again once that machine gets updated. I have seen a few bugs in various Ubuntu kernel builds, too. Such as in one build ND is broken (machine responds to its own DAD probes so it thinks any address it tries to use is in use) but the previous build and subsequent build (all of the same kernel version, just different patch tinkering by Ubuntu) work ok. From rsm at fast-serv.com Wed Jan 26 15:50:22 2011 From: rsm at fast-serv.com (Randy McAnally) Date: Wed, 26 Jan 2011 16:50:22 -0500 Subject: Ipv6 for the content provider In-Reply-To: <4D406670.8040202@knownelement.com> References: <4D406670.8040202@knownelement.com> Message-ID: <20110126214802.M82382@fast-serv.com> On Wed, 26 Jan 2011 10:22:40 -0800, Charles N Wyble wrote > For the most part, I'm a data center/application > administrator/content provider kind of guy. As such, I want to > provide all my web content over ipv6, and support ipv6 SMTP. What > are folks doing in this regard? The only issue I've faced is RHEL/CentOS doesn't have stateful connection tracking for IPv6 - so ip6tables is practically worthless. ~Randy From charles at knownelement.com Wed Jan 26 15:52:07 2011 From: charles at knownelement.com (Charles N Wyble) Date: Wed, 26 Jan 2011 13:52:07 -0800 Subject: What's the current state of major access networks in North America ipv6 delivery status? Message-ID: <4D409787.8050104@knownelement.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Is anyone tracking the major consumer/business class access networks delivery of ipv6 in North America? I'm on ATT DSL. It looks like they want to use 6rd? I've only briefly looked into 6rd. Is this a dead end path/giant hack? https://sites.google.com/site/ipv6implementors/2010/agenda/05_Chase_Googleconf-BroadbandtransitiontoIPv6using6rd.pdf?attredirects=0 I spoke with impulse.net last year, which appears to serve large portions of the AT&T cable plant in Southern California. They were willing to offer native ipv6. Not sure how (one /64, a /48) etc. I see that FiOS did a trial in April 2010 http://newscenter.verizon.com/press-releases/verizon/2010/verizon-begins-testing-ipv6.html (it mentions special CPE). What about verizon DSL? Comcast is currently conducting trials: http://comcast6.net/ (anyone participated in this?) How about TimeWarnerCable? They don't seem to have any sort of v6 offering, on wholesale or retail services. Am I missing anyone in the DSL/Cable/FTTH market? As for wireless broadband providers, there is satellite and 3g/4g/LTE. I haven't looked at the satellite providers. I know Verizon is offering dual stack on their LTE service, according to a thread a couple weeks ago. T-mobile is offering it on the small subset of phones that have v6 capable baseband. For grins and giggles, how does North America stack up against other regions, when it comes to access network ipv6 delivery. Thanks. - -- Charles N Wyble (charles at knownelement.com) Systems craftsman for the stars http://www.knownelement.com Mobile: 626 539 4344 Office: 310 929 8793 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNQJd/AAoJEMvvG/TyLEAtIx4P/1ehNtwotF30HZf4BqeWlJ7C gGmp33VkvwPdh8qUT4scHT/Wcql2V/ijhEJk7t0Tu9F98ig51c3euLuJ9iUhgP8v RdX9Ty8uAThs2EL/sT3aEVlrbiEOtkjW5zFQzWv3So7aPFeO9u5uBa9XO2eeOFG4 nI1ztpPzq3obGGLZWixIJ3ukOvKnb1ilKk74h9kjvnRA89wE1nS8ZvulWdWovAZ6 CaiU54SARQFlqtZ5PsrPrAi1LEz5lXP3Pp3kvphjp019XmyPvtgFwqwX6WoMbBgQ hHulUEnTX9A/3S/Llzz/eQRcWDX+KtqfF/khNBglsr6Y8tBgvJ360YI7dmn9J2hS 1QmnkiwTKlSkvbBM9HVbC/no7nB/J4ybOTVV004ciY6WWTRnCNGtgnoUWO4+qJVK E0996B2egOmhkUJs8AR+VYsguEVbSc12wbxZYrfjTjh7yE87q92okw/mUVi5OOVL t+ysZpV6yifR6/0T26VTJnJ/Ha6tjOE8SmA6lSKdKac5GTPkFBRqzkqsgGmF3lQq NAYMaVKmmq58j5e3eA8btGNf/u4wzJv9JJFXx3aij7pCE29yAfSrMfNV8r6ayAvL lDXQH3AP6LpV6EPb2vAUPq95iw+Fvl5PN80PYdyxVwpphQRutYQYvPZBh9/RfFOi LL5HLupKb900MQX/ZMjY =tE8q -----END PGP SIGNATURE----- From dwcarder at wisc.edu Wed Jan 26 15:53:52 2011 From: dwcarder at wisc.edu (Dale W. Carder) Date: Wed, 26 Jan 2011 15:53:52 -0600 Subject: Ipv6 for the content provider In-Reply-To: <20110126214802.M82382@fast-serv.com> References: <4D406670.8040202@knownelement.com> <20110126214802.M82382@fast-serv.com> Message-ID: <20110126215351.GH80033@ricotta.doit.wisc.edu> Thus spake Randy McAnally (rsm at fast-serv.com) on Wed, Jan 26, 2011 at 04:50:22PM -0500: > On Wed, 26 Jan 2011 10:22:40 -0800, Charles N Wyble wrote > > > For the most part, I'm a data center/application > > administrator/content provider kind of guy. As such, I want to > > provide all my web content over ipv6, and support ipv6 SMTP. What > > are folks doing in this regard? > > The only issue I've faced is RHEL/CentOS doesn't have stateful connection > tracking for IPv6 - so ip6tables is practically worthless. Yep, we ran into this too early on with rhel [4,5]. Have you looked at rhel 6? Dale From charles at knownelement.com Wed Jan 26 15:56:05 2011 From: charles at knownelement.com (Charles N Wyble) Date: Wed, 26 Jan 2011 13:56:05 -0800 Subject: Ipv6 for the content provider In-Reply-To: <20110126214802.M82382@fast-serv.com> References: <4D406670.8040202@knownelement.com> <20110126214802.M82382@fast-serv.com> Message-ID: <4D409875.2060207@knownelement.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/26/2011 01:50 PM, Randy McAnally wrote: > On Wed, 26 Jan 2011 10:22:40 -0800, Charles N Wyble wrote > >> For the most part, I'm a data center/application >> administrator/content provider kind of guy. As such, I want to >> provide all my web content over ipv6, and support ipv6 SMTP. What >> are folks doing in this regard? > > The only issue I've faced is RHEL/CentOS doesn't have stateful connection > tracking for IPv6 - so ip6tables is practically worthless. Hmmmm. Interesting. I wonder if this is specific to the RedHat kernel? Or a problem with v6 support on Linux in general? Perhaps it could be solved with tweaking which iptables modules get loaded. Ugh. This is why I don't care for iptables as a firewall. Lost lots of time tracking down bizarre corner cases due to module issues. Don't get me started on the number of issues due to distro patching of the kernel. I haven't used Linux for any serious networking duty for some time. Just Cisco and pfsense. However the majority of my servers are Linux (Ubuntu 10.10/8.04) (with a couple of windows 2008 servers). - -- Charles N Wyble (charles at knownelement.com) Systems craftsman for the stars http://www.knownelement.com Mobile: 626 539 4344 Office: 310 929 8793 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNQJh0AAoJEMvvG/TyLEAt5pQP/iSi5x43vW5oGGsatcMXCFnz nd4vXZrMlujHazd9DAYwkbwHUXkdXq26sQk+k3Ah90rBecpRJPm6y0O5Gyoktdex oxEP1CRLsgWk1kJFa2aSqS/Lh3loJgXHRaY17sNiqbqWoNXz9meh8oLNATFM5iu0 2uFgxJKQhEGv0iwWUFXtzXkUlQxdFNP71+AcCKY6mhaLYdVUUasmFWrwsumN0KNo WsVhTqI8LLow0HcfOjhxI7QD2m84Hl46oUyIzZ05I2g4iI0BD6UyvrGW2FKEsuml 9Fwb9kULuNBO9vJRPu0PyzgFL6qYtjTC3EigUP8/wpsSDC6TxLLXuZI5cSZnnd8M DOpjhL2854eTNq2IKicaxwb5U+Hq6E4rbpKFZxutvo9z3nFKGOwQx8qUnMiFgNu9 i4oASTus3ZLOkMncacXFxI8CJlvOGlktAeWdDfJ+z1ebCutgtCC1Qkgz7EFGq2oe zejLgMZsKVkr3Ezmiij7CTlrHCiWFeNrl9OLkGs7uB8Kx7SJmJlWRxsU3mfm72np 4Q1MQrk8NSI687S/XI3yf/q0+E73eI7ldYdivstubN5VcPpQDMFOQ/7yYm7AeM7V IbnPwkICxTQqJNALTB3QUFBq5UM26MRONFhi58TAOSkkwgQzyuLarLI4eBft43sx NQ6IrlMG0nFYl1h12SGy =gbrP -----END PGP SIGNATURE----- From rsm at fast-serv.com Wed Jan 26 16:01:31 2011 From: rsm at fast-serv.com (Randy McAnally) Date: Wed, 26 Jan 2011 17:01:31 -0500 Subject: Ipv6 for the content provider In-Reply-To: <4D409875.2060207@knownelement.com> References: <4D406670.8040202@knownelement.com> <20110126214802.M82382@fast-serv.com> <4D409875.2060207@knownelement.com> Message-ID: <20110126220009.M50392@fast-serv.com> On Wed, 26 Jan 2011 13:56:05 -0800, Charles N Wyble wrote > > The only issue I've faced is RHEL/CentOS doesn't have stateful connection > > tracking for IPv6 - so ip6tables is practically worthless. > > Hmmmm. Interesting. I wonder if this is specific to the RedHat > kernel? I've worked around it by compiling custom (newer) Kernels on systems that need it. Apparently support was added some time around 2.6.20, but of course RHEL5 is still in the dark ages of 2.6.18. ~Randy From Valdis.Kletnieks at vt.edu Wed Jan 26 16:09:07 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 26 Jan 2011 17:09:07 -0500 Subject: Ipv6 for the content provider In-Reply-To: Your message of "Wed, 26 Jan 2011 13:56:05 PST." <4D409875.2060207@knownelement.com> References: <4D406670.8040202@knownelement.com> <20110126214802.M82382@fast-serv.com> <4D409875.2060207@knownelement.com> Message-ID: <79330.1296079747@localhost> On Wed, 26 Jan 2011 13:56:05 PST, Charles N Wyble said: > > The only issue I've faced is RHEL/CentOS doesn't have stateful connection > > tracking for IPv6 - so ip6tables is practically worthless. > > > Hmmmm. Interesting. I wonder if this is specific to the RedHat kernel? > Or a problem with v6 support on Linux in general? (Linux kernels are trying to stick to a release-every-3-months schedule). RHEL/CentOS 5 is using a 2.6.18 kernel. The needed support for stateful IPv6 landed in 2.6.21 or so (so almost a year after RHEL 5 did its feature freeze). RHEL 6 is apparently a 2.6.32 kernel so it should be there. Cutting edge kernel is currently 2.6.38-rc2. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110126/897ef83a/attachment.bin> From trejrco at gmail.com Wed Jan 26 16:20:03 2011 From: trejrco at gmail.com (TJ) Date: Wed, 26 Jan 2011 17:20:03 -0500 Subject: What's the current state of major access networks in North America ipv6 delivery status? In-Reply-To: <4D409787.8050104@knownelement.com> References: <4D409787.8050104@knownelement.com> Message-ID: <AANLkTinDtMXETy5gARnB1r+VG9RurKyNKEPdff3Kj6M9@mail.gmail.com> On Wed, Jan 26, 2011 at 16:52, Charles N Wyble <charles at knownelement.com>wrote: (SNIP) Comcast is currently conducting trials: > http://comcast6.net/ (anyone participated in this?) > Yes, I am in one of their trials now. For the trial I am in (Residential cable, 6RD) they shipped me a Cisco/Linksys running OpenWRT/LuCI. Mostly been working great ... /TJ From charles at knownelement.com Wed Jan 26 16:33:27 2011 From: charles at knownelement.com (Charles N Wyble) Date: Wed, 26 Jan 2011 14:33:27 -0800 Subject: What's the current state of major access networks in North America ipv6 delivery status? In-Reply-To: <4D409787.8050104@knownelement.com> References: <4D409787.8050104@knownelement.com> Message-ID: <4D40A137.3060503@knownelement.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/26/2011 01:52 PM, Charles N Wyble wrote: > > Is anyone tracking the major consumer/business class access networks > delivery of ipv6 in North America? > > I'm on ATT DSL. It looks like they want to use 6rd? I've only briefly > looked into 6rd. Is this a dead end path/giant hack? > > https://sites.google.com/site/ipv6implementors/2010/agenda/05_Chase_Googleconf-BroadbandtransitiontoIPv6using6rd.pdf?attredirects=0 > Found an article talking about at&t v6 support http://www.networkworld.com/news/2010/102710-att-ipv6.html?page=3 Also found http://www.corp.att.com/gov/solution/network_services/data_nw/ipv6/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNQKEzAAoJEMvvG/TyLEAt45cP/0g+8lNUb1z6Ew/tWgGPEYWu u7wemSTjs27yxKXIbdfWzcWizvX3THHFNW6oRlRIdaH3z+Ttkzb/ne5wEDw9lcgV vnW0n/QjKQOWFaZ+chgEpplEVPth5jww/B/o9taeS7MXonbhQipTeTo3/U7am0GB MCZXngLllOhPZmmjhqsssiLX94wjc5uvqSdAExTt7aXQ7+SaVzpFghXTZgWAG9eE X9JpFeLhJMNPed1MOzxOn7WTsqDu2sHyszoyrZwGyjyQ/JZFDFfdhE3qQPRe97tv ZOmlfPYFjJRjQ4MlY7iX+BI/CTRAeM+59oslpX8h7VeGY4zmlNGw8dhR1yvB400h w+/GubudSnL50XppUslKWbl03v+4dTQYMy3dotwH2OM8ovcJMn596rLW8j+3zV7t zcOuLSLFlqY6QZYy8tp705qzYesLWvHJJlpbXryyOGoz/5SJyTvfkDywOgyNeXz4 siU2a+JaAxlJsrBc9YsabCY8C60zFQxKBwANXWhvP7TZiFtt+SaNLp/Eahh9NoAO Zygs4FekumT9TFeNsAnPlHFFCl9v6fU0Yxc8u0ffYa2+hW6f/2My4tY0n07PNd8l DUUO7h9GtLpfEgTk2eLavY8HZcb1RtA4cvMe8n1J2GOVCwpGfOD0xl1Y3AX6v+rk JuGqPIfyQ8GiNtj7KzRV =LASk -----END PGP SIGNATURE----- From tony at lava.net Wed Jan 26 16:56:01 2011 From: tony at lava.net (Antonio Querubin) Date: Wed, 26 Jan 2011 12:56:01 -1000 (HST) Subject: Ipv6 for the content provider In-Reply-To: <DF3C7AD3-2065-4228-9525-70022E768C7C@delong.com> References: <4D406670.8040202@knownelement.com> <alpine.OSX.2.00.1101260905210.211@cust11794.lava.net> <DF3C7AD3-2065-4228-9525-70022E768C7C@delong.com> Message-ID: <alpine.OSX.2.00.1101261242070.211@cust11794.lava.net> On Wed, 26 Jan 2011, Owen DeLong wrote: >> Listen a.b.c.d:80 -> Listen 80 >> <Virtualhost a.b.c.d:80> -> <Virtualhost *:80> >> > That only works if you have only one address on the machine and. Actually it works fine on machines with multiple IP addresses for both FreeBSD and CentOS. And IPv6 enabled servers can easily have multiple IPv6 addresses. > If you have addresses that aren't intended for name-based-site-A but > do terminate SSL connections to sites B, C, and D, then you probably > don't want to use * for site A. Generally, I've found this doesn't really matter too much since the view from the outside world to the server will be funneled via DNS records. Site A can still be referenced by a * in the Apache config since the A and AAAA records will probably reference only the name-based IP addresses for the server while sites B, C, and D DNS records reference site-specific addresses also residing on the same server. The bottom line is that the Apache config can be kept simple and free of hard-coded addresses except where absolutely necessary. >> Use hard-coded IP addresses only where required for stuff like SSL-enabled webhosts. >> > Depends on the complexity of your environment. In a more complex configuration > you can actually save yourself a lot of trouble and confusion later by using a > construct like this: > > Listen 192.159.10.7:80 > Listen [2620:0:930::dead:beef:cafe]:80 > Listen [2620:0:930::400:7]:80 > <VirtualHost 192.159.10.7:80 [2620:0:930::400:7]:80 [2620:0:930::dead:beef:cafe] > :80> > ServerName www.delong.com I'd do that only for the SSL-enabled sites. Otherwise the generic name-based Apache config should work fine for just about everything else. Antonio Querubin e-mail/xmpp: tony at lava.net From lowen at pari.edu Wed Jan 26 16:58:24 2011 From: lowen at pari.edu (Lamar Owen) Date: Wed, 26 Jan 2011 17:58:24 -0500 Subject: Ipv6 for the content provider In-Reply-To: <20110126220009.M50392@fast-serv.com> References: <4D406670.8040202@knownelement.com> Message-ID: <201101261758.25188.lowen@pari.edu> On Wednesday, January 26, 2011 05:01:31 pm Randy McAnally wrote: > I've worked around it by compiling custom (newer) Kernels on systems that need > it. Apparently support was added some time around 2.6.20, but of course RHEL5 > is still in the dark ages of 2.6.18. RHEL has the eMRG kernel available that is post-2.6.18, for RHEL5. However, RHEL's 2.6.18 kernel has many many things backported from much more recent kernels, including features like ext4. Saying that it's an old kernel isn't completely true; it's kind of like saying a '67 C2 Vette with a 327 has an old engine (after all, why not the 427?), but what you don't see is the sixty-thousandths overbore, 18 degree BowTie heads, forged crank, a 1300CFM Holley Dominator 4500 on an Edelbrock Victor Glidden single-plane port-matched 18 degree intake, along with Flowmaster long tube headers, long lobe COMP cam, and high stall torque converter that makes it more than just an old 327... Sorry, dream car there.... and, yes, I'd rather have the tricked-out 327 small block than the 427 big-block....although that carb on that intake isn't the most street-friendly combination ever imagined.... Don't judge a kernel by the superficial version number; look for the performance parts under the hood, and maybe even under the valve covers.... From tony at lava.net Wed Jan 26 16:59:36 2011 From: tony at lava.net (Antonio Querubin) Date: Wed, 26 Jan 2011 12:59:36 -1000 (HST) Subject: Ipv6 for the content provider In-Reply-To: <E3870C8B-6D62-46F9-87D6-CCC04E31BCEA@delong.com> References: <4D406670.8040202@knownelement.com> <20110126191710.GB1495@sekishi.zefyris.com> <E3870C8B-6D62-46F9-87D6-CCC04E31BCEA@delong.com> Message-ID: <alpine.OSX.2.00.1101261257290.211@cust11794.lava.net> On Wed, 26 Jan 2011, Owen DeLong wrote: > It would be nice if BSD would correct their IPV6_V6ONLY behavior instead > of putting up an alleged security red herring. I'm not sure why Micr0$0ft suffers > from this braindeath. Or at the very least document this in plain site in the IPv6 section of the docs. Their non-RFC-compliant behaviour is a hidden land mine. Antonio Querubin e-mail/xmpp: tony at lava.net From tony at lava.net Wed Jan 26 17:05:50 2011 From: tony at lava.net (Antonio Querubin) Date: Wed, 26 Jan 2011 13:05:50 -1000 (HST) Subject: Ipv6 for the content provider In-Reply-To: <20110126214802.M82382@fast-serv.com> References: <4D406670.8040202@knownelement.com> <20110126214802.M82382@fast-serv.com> Message-ID: <alpine.OSX.2.00.1101261301230.211@cust11794.lava.net> On Wed, 26 Jan 2011, Randy McAnally wrote: > The only issue I've faced is RHEL/CentOS doesn't have stateful connection > tracking for IPv6 - so ip6tables is practically worthless. As long as you're willing to run your iptables through a modification filter to generate the corresponding ip6tables you should be ok. The following sed script might come in handy. s/-p icmp --icmp-type any/-p icmpv6/ /-m state --state ESTABLISHED,RELATED/ { s/-m state --state ESTABLISHED,RELATED/-p udp -m udp --dport 32768:61000/p s/udp/tcp/g s/61000/61000 ! --syn/ } s/-m state --state NEW // s/224.0.0.251/ff02::fb/ s/icmp-host-prohibited/icmp6-adm-prohibited/ Modify as needed. YMMV. Antonio Querubin e-mail/xmpp: tony at lava.net From tony at lava.net Wed Jan 26 17:09:02 2011 From: tony at lava.net (Antonio Querubin) Date: Wed, 26 Jan 2011 13:09:02 -1000 (HST) Subject: What's the current state of major access networks in North America ipv6 delivery status? In-Reply-To: <4D409787.8050104@knownelement.com> References: <4D409787.8050104@knownelement.com> Message-ID: <alpine.OSX.2.00.1101261306130.211@cust11794.lava.net> On Wed, 26 Jan 2011, Charles N Wyble wrote: > How about TimeWarnerCable? They don't seem to have any sort of v6 > offering, on wholesale or retail services. TW Cable has no IPv6 offering. However, TW Telecom provides IPv6 connectivity upon request. By default they only provide a /56 if you need multiple subnets and you have to provide further justification to get a /48. Antonio Querubin e-mail/xmpp: tony at lava.net From Valdis.Kletnieks at vt.edu Wed Jan 26 17:13:04 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 26 Jan 2011 18:13:04 -0500 Subject: Ipv6 for the content provider In-Reply-To: Your message of "Wed, 26 Jan 2011 12:56:01 -1000." <alpine.OSX.2.00.1101261242070.211@cust11794.lava.net> References: <4D406670.8040202@knownelement.com> <alpine.OSX.2.00.1101260905210.211@cust11794.lava.net> <DF3C7AD3-2065-4228-9525-70022E768C7C@delong.com> <alpine.OSX.2.00.1101261242070.211@cust11794.lava.net> Message-ID: <82273.1296083584@localhost> On Wed, 26 Jan 2011 12:56:01 -1000, Antonio Querubin said: > On Wed, 26 Jan 2011, Owen DeLong wrote: > > >> Listen a.b.c.d:80 -> Listen 80 > >> <Virtualhost a.b.c.d:80> -> <Virtualhost *:80> > >> > > That only works if you have only one address on the machine and. > > Actually it works fine on machines with multiple IP addresses for both > FreeBSD and CentOS. And IPv6 enabled servers can easily have multiple > IPv6 addresses. What Owen meant was that if you expect it to answer *only* for a.b.c.d:80, and *not* to answer for other addresses/interfaces, you may be in for a surprise (consider a DMZ host where you have: outside world - 128.257.12.2 inside facing - 192.168.149.149 VirtualHost 198.168.149.149:80 # super-sekrit corporate internal site Changing that VirtualHost to *:80 will probably cause some grief. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110126/ec7381a6/attachment.bin> From florin at futurefreedom.ro Mon Jan 24 07:39:33 2011 From: florin at futurefreedom.ro (Florin Veres) Date: Mon, 24 Jan 2011 15:39:33 +0200 Subject: Upload config to juniper Message-ID: <AANLkTinEpsHaVcro9io3gCpHeCKwpNHg9zBSAY+7oZKJ@mail.gmail.com> Hey guys, Do any of you have any idea if it's possible to upload configuration from a script (prefix-list updates in this case) to a JunOS device (MX)? For Cisco devices I'm doing it using rcp. Thanks, Florin From jna at retina.net Wed Jan 26 17:22:56 2011 From: jna at retina.net (John Adams) Date: Wed, 26 Jan 2011 15:22:56 -0800 Subject: Upload config to juniper In-Reply-To: <AANLkTinEpsHaVcro9io3gCpHeCKwpNHg9zBSAY+7oZKJ@mail.gmail.com> References: <AANLkTinEpsHaVcro9io3gCpHeCKwpNHg9zBSAY+7oZKJ@mail.gmail.com> Message-ID: <AANLkTiny3vmQzbyC2rD17E8HV9LHm+tjK4DZQytMFB-d@mail.gmail.com> I do this with pyexpect for blacklist updating. It works amazingly well. One thing to remember when communicating with the JunOS device is that if you fail to disable the CLI controls, communicating with the device is very difficult. I do something like: import pexpect child = pexpect.spawn ('ssh', ['-p','22','-o','StrictHostKeyChecking=no',"router ip address goes here"], 2) child.sendline("set cli screen-length 0") child.sendline("set cli screen-width 0") < put your commands here to talk to the router > -j On Mon, Jan 24, 2011 at 5:39 AM, Florin Veres <florin at futurefreedom.ro> wrote: > Hey guys, > > Do any of you have any idea if it's possible to upload configuration from a > script (prefix-list updates in this case) to a JunOS device (MX)? > For Cisco devices I'm doing it using rcp. > > Thanks, > Florin > From marka at isc.org Wed Jan 26 17:38:38 2011 From: marka at isc.org (Mark Andrews) Date: Thu, 27 Jan 2011 10:38:38 +1100 Subject: Ipv6 for the content provider In-Reply-To: Your message of "Wed, 26 Jan 2011 10:22:40 -0800." <4D406670.8040202@knownelement.com> References: <4D406670.8040202@knownelement.com> Message-ID: <20110126233838.5959092E47B@drugs.dv.isc.org> Additionally for DNS don't forget to add IPv6 glue for the nameservers for your zones to the parent zones. For named in particular listen-on-v6 needs to be specified as it is not on by default e.g. "listen-on-v6 { any; };". Named will ask questions over IPv6 by default even if it isn't listening on IPv6. -- 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 Jan 26 16:02:38 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 26 Jan 2011 14:02:38 -0800 Subject: What's the current state of major access networks in North America ipv6 delivery status? In-Reply-To: <4D409787.8050104@knownelement.com> References: <4D409787.8050104@knownelement.com> Message-ID: <BACEA722-744B-4773-89EF-03FBB933E1E4@delong.com> On Jan 26, 2011, at 1:52 PM, Charles N Wyble wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Is anyone tracking the major consumer/business class access networks > delivery of ipv6 in North America? > > I'm on ATT DSL. It looks like they want to use 6rd? I've only briefly > looked into 6rd. Is this a dead end path/giant hack? > > https://sites.google.com/site/ipv6implementors/2010/agenda/05_Chase_Googleconf-BroadbandtransitiontoIPv6using6rd.pdf?attredirects=0 > It's a fairly ugly way to deliver IPv6, but, as transition technologies go, it's the least dead-end of the options. It at least provides essentially native dual stack environment. The only difference is that your IPv6 access is via a tunnel. You'll probably be limited to a /56 or less over 6rd, unfortunately, but, because of the awful way 6rd consumes addresses, handing out /48s would be utterly impractical. Free.fr stuck their customers with /60s, which is hopefully a very temporary situation. > > I spoke with impulse.net last year, which appears to serve large > portions of the AT&T cable plant in Southern California. They were > willing to offer native ipv6. Not sure how (one /64, a /48) etc. > You should definitely push your providers to give you a /48 if possible. If /56 or worse /60 or worst of all, /64 become widespread trends, it may significantly impact, delay, or even prevent innovations in the end-user networking/consumer electronics markets. Owen From kauer at biplane.com.au Wed Jan 26 18:44:38 2011 From: kauer at biplane.com.au (Karl Auer) Date: Thu, 27 Jan 2011 11:44:38 +1100 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <AE3E144C-64D8-46AA-9EFE-9CECF2F766FA@arbor.net> References: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com> <AANLkTimcZavnJN2gqayS2-piDvOAcw_nrJAREJ0EDTjp@mail.gmail.com> <AANLkTikHBb+cyfPxXftb5QZh136D04fkdWFMy3NFhDdi@mail.gmail.com> <4D3F0144.70107@sohonet.co.uk> <58166C50-0B72-43A0-8AB8-25E803EA1619@delong.com> <20110126043722.GA4110@skywalker.creative.net.au> <AE3E144C-64D8-46AA-9EFE-9CECF2F766FA@arbor.net> Message-ID: <1296089078.6522.194.camel@karl> On Wed, 2011-01-26 at 11:53 +0700, Roland Dobbins wrote: > On Jan 26, 2011, at 11:37 AM, Adrian Chadd wrote: > The supreme irony of this situation is that folks who're convinced > that there's no way we can even run out of addresses often accuse > those of us who're plentitude-skeptics of old-fashioned thinking; > whereas there's a strong case to be made that those very same vocal > advocates of the plentitude position seem to be assuming that the > assignment and consumption of IPv6 addresses (and networking > technology and the Internet in general) will continue to be > constrained by the current four-decade-old paradigm into the > foreseeable future. Both positions are wrong, but the plenitudinists are more right :-) As long as we allow ourselves to be limited in our thinking by numbers (which are infinite by their very nature), we will be - well, limited in our thinking. So let's get rid of the limitation in our minds. IPv6 provides *effectively* unlimited address space, even if it's only "for now". So let's USE it that way. Let's unlearn our limited thinking patterns. Let's go colonise infinity. And if we need to fix it in a few decades, so what? Nothing is forever. As Mark Twain suggested, let's "live like it's heaven on earth". Regards, K. PS: I saw a great t-shirt recently, ideal for your next IPv6 conference: "The time for action is past - now is the time for senseless bickering". -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110127/90e35b57/attachment.bin> From marka at isc.org Wed Jan 26 18:43:31 2011 From: marka at isc.org (Mark Andrews) Date: Thu, 27 Jan 2011 11:43:31 +1100 Subject: What's the current state of major access networks in North America ipv6 delivery status? In-Reply-To: Your message of "Wed, 26 Jan 2011 14:02:38 -0800." <BACEA722-744B-4773-89EF-03FBB933E1E4@delong.com> References: <4D409787.8050104@knownelement.com><BACEA722-744B-4773-89EF-03FBB933E1E4@delong.com> Message-ID: <20110127004331.F2DC092EF85@drugs.dv.isc.org> In message <BACEA722-744B-4773-89EF-03FBB933E1E4 at delong.com>, Owen DeLong write s: > > On Jan 26, 2011, at 1:52 PM, Charles N Wyble wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > >=20 > >=20 > > Is anyone tracking the major consumer/business class access networks > > delivery of ipv6 in North America? > >=20 > > I'm on ATT DSL. It looks like they want to use 6rd? I've only briefly > > looked into 6rd. Is this a dead end path/giant hack? > >=20 > > = > https://sites.google.com/site/ipv6implementors/2010/agenda/05_Chase_Google= > conf-BroadbandtransitiontoIPv6using6rd.pdf?attredirects=3D0 > >=20 > It's a fairly ugly way to deliver IPv6, but, as transition technologies > go, it's the least dead-end of the options. > > It at least provides essentially native dual stack environment. The > only difference is that your IPv6 access is via a tunnel. You'll = > probably > be limited to a /56 or less over 6rd, unfortunately, but, because of the > awful way 6rd consumes addresses, handing out /48s would be > utterly impractical. Free.fr stuck their customers with /60s, which is > hopefully a very temporary situation. This comes from using a single 6rd prefix for all the clients. Those saying this is the way to do this really havn't thought about what they are going to have to do once they can't get enough IPv4 addresses to give a public one to each customer that needs a IPv4 addresses and also needs 6rd. The "simple" solution of a signgle prefix doesn't work. 6rd doesn't have to consume space badly and it shouldn't consume space badly if done right. DHCP servers don't hand out the same router to each client. They hand out the same router to all clients on the same subnet. ISP's are capable of configuring their DHCP servers to do that. Configuring them to hand out a 6rd prefix on a per subnet basis is no harder. Just ask for a /48 for each IPv4 address you intend to support 6rd on. For each block IPv4 block you get from RIR you specify a matching 6rd prefix. This prefix is stable for the life of the IPv4 block's allocation. When you get a new IPv4 block you add the 6rd prefix to the configuration system. If you are using RFC 1918 addresses to connect to your customers and NATing that you request enough /48's to cover the amout of RFC 1918 space you are using. If you are re-using space in multiple places then 6rd becomes a little more complicated as the prefixes need to differ for each re-uses. Note the naive single 6rd prefix doesn't work in this situation so ISPs doing this will need do something more complicated. Also give that address space will almost certainly need to be re-used while 6rd is also in use I fail to see the objection to doing it sensibly from the get go. Down the track I can see 6rd prefixes being allocated on request being just one more thing that the consumer can request via a web form. This will allow the ISP to recover the space being used by 6rd. > >=20 > > I spoke with impulse.net last year, which appears to serve large > > portions of the AT&T cable plant in Southern California. They were > > willing to offer native ipv6. Not sure how (one /64, a /48) etc. > >=20 > You should definitely push your providers to give you a /48 if > possible. If /56 or worse /60 or worst of all, /64 become widespread > trends, it may significantly impact, delay, or even prevent innovations > in the end-user networking/consumer electronics markets. > > Owen > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From remy.sanchez at hyperthese.net Wed Jan 26 19:25:51 2011 From: remy.sanchez at hyperthese.net (=?ISO-8859-1?Q?R=E9my_Sanchez?=) Date: Thu, 27 Jan 2011 02:25:51 +0100 Subject: What's the current state of major access networks in North America ipv6 delivery status? In-Reply-To: <BACEA722-744B-4773-89EF-03FBB933E1E4@delong.com> References: <4D409787.8050104@knownelement.com> <BACEA722-744B-4773-89EF-03FBB933E1E4@delong.com> Message-ID: <4D40C99F.3020204@hyperthese.net> On 01/26/2011 11:02 PM, Owen DeLong wrote: > Free.fr stuck their customers with /60s, which is > hopefully a very temporary situation. Stuck with /64 in practice, which will evolve into /60 when the IPv6 support in their Freebox will be better. I don't think that we'll get anything more than /60 before the next decade... At least, they have been able to provide pseudo-native IPv6 for years. If anyone asks, performances of IPv6 over Free's 6rd are almost the same than IPv4's. -- R?my Sanchez -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110127/cbd6cb50/attachment.bin> From warren at kumari.net Wed Jan 26 19:33:10 2011 From: warren at kumari.net (Warren Kumari) Date: Wed, 26 Jan 2011 20:33:10 -0500 Subject: DSL options in NYC for OOB access In-Reply-To: <8C26A4FDAE599041A13EB499117D3C286B334371@ex-mb-1.corp.atlasnetworks.us> References: <4D3DF769.7060601@nexus6.co.za> <20110124225422.GA86715@latency.net> <8C26A4FDAE599041A13EB499117D3C286B334371@ex-mb-1.corp.atlasnetworks.us> Message-ID: <67524F4A-821F-439C-9AA2-E31D8886DD3F@kumari.net> On Jan 24, 2011, at 6:22 PM, Nathan Eisenberg wrote: >> You can get a CLEAR WiMAX fixed modem with static IP address for $50 >> (USD) monthly, or less if you opt for the low-bandwidth plan. > > I wouldn't dare rely on something of that nature for a lifeline connection. I'd spring for the extra $30/mo. It's expensive, but there ain't nothin' like a physical cable when it's 3AM on a Sunday. > > Nathan > > From owen at delong.com Wed Jan 26 19:33:25 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 26 Jan 2011 17:33:25 -0800 Subject: Another v6 question In-Reply-To: <AANLkTinqipvQD-gSt1BZ5FcPT2krNhwqO5dExWrM=muG@mail.gmail.com> References: <AANLkTikEZVYFz+bx7MVXeht_qNnpkUEC_Mx0qhE6J9SR@mail.gmail.com> <55E7EC47-C434-4DF7-B92A-8EBC24133C53@delong.com> <AANLkTi=soS+LQoR3JYJxE8N3o9JYoxrL2dvzHZ+e5Geb@mail.gmail.com> <4F209412-3C3B-4CB6-8EB7-A25ABD1B9DBA@delong.com> <AANLkTinqipvQD-gSt1BZ5FcPT2krNhwqO5dExWrM=muG@mail.gmail.com> Message-ID: <67827BB1-BF59-45AF-842F-B9E1AD7A1F87@delong.com> On Jan 25, 2011, at 3:35 PM, Max Pierson wrote: > >I think you may still be missing my point... > >There are way more /48s available than will ever get used. > >There are way more /32s available than will ever get used. > > No, I think you're missing my point. Your statements above are of your opinion. The same opinion was said about v4 30 years ago which is why we are where we are today (again, opinions). Reality shows otherwise. > V4 30 years ago -- expected consumption: ~60 /8s of 256. IPv6 today -- expected consumption: Maybe 15 /12s of 4096. The scales in question are vastly different. > In your opinion, IPv6 is it. We'll NEVER have to do this again. We'll never have to implement NAT (or some other translation protocol) again. We'll never have to worry about running out of space. If thats the case, then why are so many folks arguing over what to give to end users?? It doesn't matter by your opinion. Give em what they want!! There's no possible way we can use that many addresses. > Not at all... In my opinion, IPv6 will probably last about 30-50 years. In my opinion, IPv6 addressing will outlast IPv6 usability on other fronts. I absolutely think we'll have to do this all again. I just don't think that addresses are going to be the thing we run out of next time. I think people are arguing over what to give end users because people are generally bad at large-number arithmetic. The human brain can visualize things up to as much as a few hundred. Some people can even visualize a couple of thousand. Beyond that, our neurons just think of things as randomly larger magnitudes of "a really big number". It all gets lumped into "a whole lot" and we lose site of the numeric realities. > Lets get back to reality. No one, and i'll say it once more, NO ONE knows if v6 is the end all be all. (I would agree with you in regards of our lifetime we won't even use a drop in the bucket). It only took ~10 years to figure out they did it all wrong the first time around. Can you speak for the next 100 years, what about 200 years?? (Not that it matters to us anyway, we'll be long gone by then. But they way you put it is that this beast we're dealing with will never have to be revamped again. Future proof! To me, that line of thinking is a little short-sided). > No, that's not what I said at all. What I said was that addressing isn't going to be the constraint that causes us to have to revamp it next time. Let's put it in perspective... If we give a /48 to every end site, then, we have enough addresses for 281,474,976,710,656 end sites. There are currently <7,000,000,000 people on the planet, so, let's assume we give each of them 10 buildings (home, work, a summer cottage, and 7 spares for whatever). That consumes 70,000,000,000 /48s. Now we're down to 281,404,976,710,656 /48s remaining. If we build 1,000 new end sites every second, we will need 281,404,976,710 seconds to use them all up. At 86,400 seconds per day, that's 3,257,002 days or 8,923 years. I'm pretty sure that we will not be able to sustain building 1,000 new structures per second for 8,923 years. To do it in 200 years, we would have to build almost 50,000 new structures every second. I realize there have been some amazing periods of growth on the internet, but, even at the peak of the .COM boom, even Cisco wasn't building at anywhere near that rate. However, all of this is a bit out of context from what I was saying. The point was that if you're trying to figure out how big routers are going to have to be for near-term IPv6 or even medium-term IPv6 deployment, counting the total possible number of prefixes isn't a useful metric because the actual utilization will be nowhere near that large and the numbers are impossible to use as an engineering spec. for any technology yet known. > > Some will care and adapt as we all hope they would, some will simply find another provider with v4 space to spare thats not charging. This won't stop until RIR/LIR's stop re-issuing v4 space. At that point, then the squeeze is on and I would imagine ALL ISP's will charge at that point because they're getting charged for having v4 space. > There will come a time (likely this year) when there isn't another provider with v4 space to spare that you can find. One that doesn't charge for it? That'll probably happen even earlier. I think that the RIR/LIRs won't have to stop reissuing space. I think we'll rapidly reach a point where space isn't coming back to them to be reissued. At least not in meaningful quantities. > >I don't think IPv4 will continue to grow for all that long. I think the plug will get pulled by ISPs desperate to reduce the spiraling costs of continuing to >support IPv4. When it starts becoming increasingly expensive to get ISPs to provide IPv4 services, the rest of the internet will begin to move rapidly >away from IPv4. > > >I anticipate this will take about 5-10 years after IPv4 runout at ARIN/APNIC/RIPE (which will be nearly simultaneous). > > I would agree to this as well, 5-10 years of weaning off v4 at that point is probably what we'll end up seeing, although I would say that 5-10 years in this industry is a relatively long time. Probably much longer than any of us want to see v4 stick around anyway. > Well, that's <6-11 years from today. I'd like to see IPv4 go away in ~3 years. Any faster would be too traumatic. I think 6 years is a perfectly reasonable time frame. I think if it takes 11 years it will be because of significant foot-dragging by some key organizations. I'm not convinced that foot-dragging is as likely as some people are, but, there's enough probability to provide some wiggle room in the numbers. Owen From owen at delong.com Wed Jan 26 18:45:41 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 26 Jan 2011 16:45:41 -0800 Subject: Ipv6 for the content provider In-Reply-To: <alpine.OSX.2.00.1101261257290.211@cust11794.lava.net> References: <4D406670.8040202@knownelement.com> <20110126191710.GB1495@sekishi.zefyris.com> <E3870C8B-6D62-46F9-87D6-CCC04E31BCEA@delong.com> <alpine.OSX.2.00.1101261257290.211@cust11794.lava.net> Message-ID: <5B7007C4-2F56-4193-8A5F-EFDDCCB49830@delong.com> On Jan 26, 2011, at 2:59 PM, Antonio Querubin wrote: > On Wed, 26 Jan 2011, Owen DeLong wrote: > >> It would be nice if BSD would correct their IPV6_V6ONLY behavior instead >> of putting up an alleged security red herring. I'm not sure why Micr0$0ft suffers >> from this braindeath. > > Or at the very least document this in plain site in the IPv6 section of the docs. Their non-RFC-compliant behaviour is a hidden land mine. > > Antonio Querubin > e-mail/xmpp: tony at lava.net It's actually pretty well known and it is documented in several places in plain sight. They're quite proud of their brokenness and they extol the virtues of the allegedly improved security profile it provides. I think Rolland Dobbins has coined a good term for it... "Security Theater". (Though this strikes me as being more like "Security Circus") Owen From owen at delong.com Wed Jan 26 18:49:33 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 26 Jan 2011 16:49:33 -0800 Subject: Ipv6 for the content provider In-Reply-To: <82273.1296083584@localhost> References: <4D406670.8040202@knownelement.com> <alpine.OSX.2.00.1101260905210.211@cust11794.lava.net> <DF3C7AD3-2065-4228-9525-70022E768C7C@delong.com> <alpine.OSX.2.00.1101261242070.211@cust11794.lava.net> <82273.1296083584@localhost> Message-ID: <A4243CA2-C4D5-4ADF-98A4-96AB9A47ABC5@delong.com> On Jan 26, 2011, at 3:13 PM, Valdis.Kletnieks at vt.edu wrote: > On Wed, 26 Jan 2011 12:56:01 -1000, Antonio Querubin said: >> On Wed, 26 Jan 2011, Owen DeLong wrote: >> >>>> Listen a.b.c.d:80 -> Listen 80 >>>> <Virtualhost a.b.c.d:80> -> <Virtualhost *:80> >>>> >>> That only works if you have only one address on the machine and. >> >> Actually it works fine on machines with multiple IP addresses for both >> FreeBSD and CentOS. And IPv6 enabled servers can easily have multiple >> IPv6 addresses. > > What Owen meant was that if you expect it to answer *only* for a.b.c.d:80, > and *not* to answer for other addresses/interfaces, you may be in for a > surprise (consider a DMZ host where you have: > > outside world - 128.257.12.2 > inside facing - 192.168.149.149 > > VirtualHost 198.168.149.149:80 # super-sekrit corporate internal site > > Changing that VirtualHost to *:80 will probably cause some grief. ;) Exactly... That is one of MANY examples of the kind of potential for abuse I was attempting to describe. Admittedly, if you put your Super-sekrit corporate internal site on a DMZ host, you arguably deserve what happens, but... Owen From mysidia at gmail.com Wed Jan 26 20:31:26 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 26 Jan 2011 20:31:26 -0600 Subject: Upload config to juniper In-Reply-To: <AANLkTinEpsHaVcro9io3gCpHeCKwpNHg9zBSAY+7oZKJ@mail.gmail.com> References: <AANLkTinEpsHaVcro9io3gCpHeCKwpNHg9zBSAY+7oZKJ@mail.gmail.com> Message-ID: <AANLkTi=R6bTmpBtj=oUbyDuCG8xC-cMgEJodRhSxbTFh@mail.gmail.com> On Mon, Jan 24, 2011 at 7:39 AM, Florin Veres <florin at futurefreedom.ro> wrote: > Hey guys, > Do any of you have any idea if it's possible to upload configuration from a > script (prefix-list updates in this case) to a JunOS device (MX)? > For Cisco devices I'm doing it using rcp. >From config mode use a "load merge" command that specifies a SCP or FTP URL. You'll need to setup SSH keys in advance to do so without an additional password for the device to download the script. Alternatively... SCP the file to a temporary file on the device then "load merge" the uploaded file, to merge config from the script. Net::SSH::Expect from CPAN to connect via ssh from perl. Something like use Net::SSH::Perl; use Net::SSH::Expect; my $ssh = Net::SSH::Expect->new( host => 'myfavoritehostname.example.com', user => 'blahblahblah', password => '1234', raw_pty => 1); $ssh->login(q[blahblah at myfavoritehostname.example.com's password]); $output1 = $ssh->exec("configure private"); # $blah = $ssh->exec("load merge username at scriptserver.example.com:/path/to/scriptfile_to_load.txt"); print scalar $ssh->exec("show | compare"); # commit -- -JH From dotis at mail-abuse.org Wed Jan 26 20:36:28 2011 From: dotis at mail-abuse.org (Douglas Otis) Date: Wed, 26 Jan 2011 18:36:28 -0800 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <4D3F8054.8040107@gont.com.ar> References: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com> <20110124132825.GB10465@vacation.karoshi.com.> <735BCAC6-4C3F-4BE9-BA1D-E412B3C043ED@delong.com> <20110124190435.GB11522@vacation.karoshi.com.> <4D3E0E64.4000001@mail-abuse.org> <4D3F8054.8040107@gont.com.ar> Message-ID: <4D40DA2C.4010809@mail-abuse.org> On 1/25/11 6:00 PM, Fernando Gont wrote: > On 24/01/2011 08:42 p.m., Douglas Otis wrote: >> It seems efforts related to IP address specific policies are likely >> doomed by the sheer size of the address space, and to be pedantic, ARP >> has been replaced with multicast neighbor discovery which dramatically >> reduces the overall traffic involved. > This has nothing to do with the number of entries required in the > Neighbor Cache. >> Secondly, doesn't Secure Neighbor >> Discovery implemented at layer 2 fully mitigate these issues? I too >> would be interested in hearing from Radia and Fred. > It need not. Also, think about actual deployment of SEND: for instance, > last time I checked Windows Vista didn't support it. First, it should be noted ND over ARP offers ~16M to 2 reduction in traffic. Secondly, services offered within a facility can implement Secure Neighbor Discovery, since a local network's data link layer, by definition, is isolated from the rest of the Internet. While ICMPv6 supports ND and SeND using standard IPv6 headers, only stateful ICMPv6 Packets Too Big messages should be permitted. Nor is Vista, ISATAP, or Teredo wise choices for offering Internet services. At least there are Java implementations of Secure Neighbor Discovery. When one considers what is needed to defend a facility's resources, Secure Neighbor Discovery seems desirable since it offers hardware supported defenses from a wide range of threats. While it is easy to understand a desire to keep specific IP addresses organized into small segments, such an approach seems at greater risk and more fragile in the face of frequent renumbering. In other words, it seems best to use IPv6 secure automation whenever possible. The make before break feature of IPv6 should also remove most impediments related to renumbering. In other words, fears expressed about poorly considered address block assignments also seem misplaced. -Doug From fernando at gont.com.ar Wed Jan 26 21:08:56 2011 From: fernando at gont.com.ar (Fernando Gont) Date: Thu, 27 Jan 2011 00:08:56 -0300 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <4D40DA2C.4010809@mail-abuse.org> References: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com> <20110124132825.GB10465@vacation.karoshi.com.> <735BCAC6-4C3F-4BE9-BA1D-E412B3C043ED@delong.com> <20110124190435.GB11522@vacation.karoshi.com.> <4D3E0E64.4000001@mail-abuse.org> <4D3F8054.8040107@gont.com.ar> <4D40DA2C.4010809@mail-abuse.org> Message-ID: <4D40E1C8.2020802@gont.com.ar> On 26/01/2011 11:36 p.m., Douglas Otis wrote: >>> Discovery implemented at layer 2 fully mitigate these issues? I too >>> would be interested in hearing from Radia and Fred. >> It need not. Also, think about actual deployment of SEND: for instance, >> last time I checked Windows Vista didn't support it. > First, it should be noted ND over ARP offers ~16M to 2 reduction in > traffic. Does this really make a difference in a typical LAN? > Secondly, services offered within a facility can implement > Secure Neighbor Discovery, since a local network's data link layer, by > definition, is isolated from the rest of the Internet. How many implementations are there of SEND? e.g., Is there SEND support for Windows? > While ICMPv6 > supports ND and SeND using standard IPv6 headers, only stateful ICMPv6 > Packets Too Big messages should be permitted. Not sure what you mean. > Nor is Vista, ISATAP, or > Teredo wise choices for offering Internet services. At least there are > Java implementations of Secure Neighbor Discovery. C'mon. That's great for "proof of concept". But would you raun a real network with that? Would you deploy e.g., 200+ Windows boxes with Java-based SEND support? What about all the PKI burden? > When one considers what is needed to defend a facility's resources, > Secure Neighbor Discovery seems desirable since it offers hardware > supported defenses from a wide range of threats. Without DNSsec fully deployed, is it worth the effort? > While it is easy to > understand a desire to keep specific IP addresses organized into small > segments, such an approach seems at greater risk and more fragile in the > face of frequent renumbering. In other words, it seems best to use IPv6 > secure automation whenever possible. ?? > The make before break feature of IPv6 should also remove most > impediments related to renumbering. One of the most important impediments on renumbering is the IP addresses hardcoded in configuration files, ACLs, etc. And IPv6 does nothing (and cannot do anything) to help with that. Thanks, -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From fernando at gont.com.ar Wed Jan 26 22:09:43 2011 From: fernando at gont.com.ar (Fernando Gont) Date: Thu, 27 Jan 2011 01:09:43 -0300 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <E58532F0-F1E4-4E17-BC4D-0A96D5A7BC18@delong.com> References: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com> <AANLkTimcZavnJN2gqayS2-piDvOAcw_nrJAREJ0EDTjp@mail.gmail.com> <4D3FBF8E.8070605@gont.com.ar> <E58532F0-F1E4-4E17-BC4D-0A96D5A7BC18@delong.com> Message-ID: <4D40F007.70809@gont.com.ar> On 26/01/2011 06:14 a.m., Owen DeLong wrote: >>> That said. Any size prefix will likely work and is even permitted by >>> the RFC. You do run the risk of encountering applications that assume >>> a 64-bit prefix length, though. And you're often crippling the >>> advantages of IPv6. >> >> Just curious: What are the advantages you're referring to? >> > 1. Sparse addressing This comes at a cost, though. > 2. SLAAC > 3. RFC 4193 Privacy Addressing Privacy Extensions "solve" (*) a privacy issue *introduced* by SLAAC embedding the MAC addresses in the IID. -- So, if anything, I deem this as a patch, rather than a feature. (*) there is some bibliography about the effectiveness of privacy addresses. Some have even argued that they are harmful. > 4. Never have to worry about "growing" a subnet to hold new machines. As in #1, this comes at a price. > 5. Universal subnet size, no surprises, no operator confusion, no bitmath. With quite a bit of experience with subnetting (from IPv4), I doubt this can be flagged as a benefit. Thanks, -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From bmanning at vacation.karoshi.com Wed Jan 26 23:00:47 2011 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 27 Jan 2011 05:00:47 +0000 Subject: DSL options in NYC for OOB access In-Reply-To: <67524F4A-821F-439C-9AA2-E31D8886DD3F@kumari.net> References: <4D3DF769.7060601@nexus6.co.za> <20110124225422.GA86715@latency.net> <8C26A4FDAE599041A13EB499117D3C286B334371@ex-mb-1.corp.atlasnetworks.us> <67524F4A-821F-439C-9AA2-E31D8886DD3F@kumari.net> Message-ID: <20110127050047.GA9940@vacation.karoshi.com.> On Wed, Jan 26, 2011 at 08:33:10PM -0500, Warren Kumari wrote: > > On Jan 24, 2011, at 6:22 PM, Nathan Eisenberg wrote: > > >> You can get a CLEAR WiMAX fixed modem with static IP address for $50 > >> (USD) monthly, or less if you opt for the low-bandwidth plan. > > > > I wouldn't dare rely on something of that nature for a lifeline connection. I'd spring for the extra $30/mo. It's expensive, but there ain't nothin' like a physical cable when it's 3AM on a Sunday. > > > > Nathan phys plant is good, nesscy but not sufficant for lifeline. for lifeline - your only option is regulated wireline service w/o any dependance on external power. regulated telco voice service has a requirement for self-power - usually in the range of 12+hours. Not the 90min batteries in most cell towers. ymmv of course and you get what you pay for. --bill From owen at delong.com Thu Jan 27 00:29:30 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 26 Jan 2011 22:29:30 -0800 Subject: Another v6 question In-Reply-To: <AANLkTi=fJbDuv1X_cDSWMzAF7sBkF+2K7+eso97NiQBc@mail.gmail.com> References: <AANLkTikEZVYFz+bx7MVXeht_qNnpkUEC_Mx0qhE6J9SR@mail.gmail.com> <55E7EC47-C434-4DF7-B92A-8EBC24133C53@delong.com> <AANLkTi=soS+LQoR3JYJxE8N3o9JYoxrL2dvzHZ+e5Geb@mail.gmail.com> <4F209412-3C3B-4CB6-8EB7-A25ABD1B9DBA@delong.com> <AANLkTinqipvQD-gSt1BZ5FcPT2krNhwqO5dExWrM=muG@mail.gmail.com> <67827BB1-BF59-45AF-842F-B9E1AD7A1F87@delong.com> <AANLkTi=fJbDuv1X_cDSWMzAF7sBkF+2K7+eso97NiQBc@mail.gmail.com> Message-ID: <5CE30429-3FD2-4554-8D57-670DA6F15FBB@delong.com> On Jan 26, 2011, at 9:31 PM, Max Pierson wrote: > >V4 30 years ago -- expected consumption: ~60 /8s of 256. > >IPv6 today -- expected consumption: Maybe 15 /12s of 4096. > >The scales in question are vastly different. > > I made no such comparison between the two. The scales are vastly different, but I think you're still missing my point. 30 years ago, no one "expected" cells phones to consume IP's. 30 years ago, no one "expected" xbox's and playstations to consume IP's. Point being is the "unexpected". > I'm not missing your point. I'm saying that in IPv6, we've put enough addresses in to allow for things nobody has thought of in 30, 60, 90, even 100 years and then some. > >Not at all... In my opinion, IPv6 will probably last about 30-50 years. In my opinion, IPv6 addressing will outlast IPv6 usability on other fronts. I >absolutely think we'll have to do this all again. I just don't think that addresses are going to be the thing we run out of next time. > > Ok then, what is it exactly you think we'll run out of in 30-50 years?? Please elaborate. > If I knew, then, I'd be well on my way to much greater wealth. Whatever it is, I am only certain of the following things about it: 1. We have no idea what the requirements will be at this time. 2. We have no idea which particular scaling limit in IPv6 will actually drive us to the next protocol. 3. Our needs in 30-50 years will be different than our needs today. 4. This all assumes that we have a human race to care about having an internet in 50 years. Such is not necessarily a safe assumption. > >No, that's not what I said at all. What I said was that addressing isn't going to be the constraint that causes us to have to revamp it next time. > > Once again, please elaborate. > See below... I pretty much did elaborate in another message about the number of /48s and the construction rate required to consume them.. I don't know what will cause us to revamp it next time. I'm just sure there are enough numbers to make it to that point. > >The point was that if you're trying to figure out how big routers are > >going to have to be for near-term IPv6 or even medium-term IPv6 > >deployment, counting the total possible number of prefixes isn't > >a useful metric because the actual utilization will be nowhere > >near that large and the numbers are impossible to use as an > >engineering spec. for any technology yet known. > > Actually, my original post may have been somewhat misleading due to "what a global table would look like in say 3 or 5 years after v4 is exhausted" and "in our routers just to take a full table". I wasn't referring to just v6 deployment moving forward. I didn't mean after v4 goes away completely. I was adding v4 table + v6 table (assuming we dual-stack, if you separate the two, ~4000 prefixes fit quite nicely on just about anything still running today, and that also makes the second question of my original post irrelevant). We won't need that amount of memory after v4 goes away (probably for quite some time). The prefix count at that point will be significantly lower. I understand that. Apologies for not being clearer. > Well, once IPv6 is more fully deployed, you'll be seeing at least 30,000 and more like 75,000 prefixes in IPv6. That's because there are about 30,000 active ASNs today and given tendencies towards traffic engineering, greater multihoming, easier address acquisition and some other factors, a 2+ growth factor over ASNs wouldn't surprise me in the short term. > >I'd like to see IPv4 go away in ~3 years. Any faster would be too traumatic. > >I think 6 years is a perfectly reasonable time frame. I think if it takes 11 years > >it will be because of significant foot-dragging by some key organizations. > >I'm not convinced that foot-dragging is as likely as some people are, but, > >there's enough probability to provide some wiggle room in the numbers. > > I agree, although I do think there will be some foot-dragging, I just don't think it will take 11 years. If anyone at that point is still speaking only v4, IMO they'll only be speaking to "127.0.0.1". > I think there will be quite a bit of foot dragging. I think you misunderstand me. I'm expecting everyone to be pretty much dual-stacked in the next 3-4 years, even with foot dragging. I'm expecting us to start seeing IPv4 actually deprecated as in some providers won't route it any more (or if they do, they'll charge a lot to do so) in 6-11 years. That's what I mean when I say I'd like to see IPv4 go away in that time frame. Owen From frnkblk at iname.com Thu Jan 27 00:44:37 2011 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 27 Jan 2011 00:44:37 -0600 Subject: What's the current state of major access networks in North America ipv6 delivery status? In-Reply-To: <4D40A137.3060503@knownelement.com> References: <4D409787.8050104@knownelement.com> <4D40A137.3060503@knownelement.com> Message-ID: <006701cbbded$aa5d6f60$ff184e20$@iname.com> This is all hearsay, but I learned from a shared vendor that AT&T is putting pressure on them to complete their IPv6 support, so that the vendor is moving up completion from Q4 to Q2. This was a sales person talking, so who knows. Frank -----Original Message----- From: Charles N Wyble [mailto:charles at knownelement.com] Sent: Wednesday, January 26, 2011 4:33 PM To: nanog at nanog.org Subject: Re: What's the current state of major access networks in North America ipv6 delivery status? -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/26/2011 01:52 PM, Charles N Wyble wrote: > > Is anyone tracking the major consumer/business class access networks > delivery of ipv6 in North America? > > I'm on ATT DSL. It looks like they want to use 6rd? I've only briefly > looked into 6rd. Is this a dead end path/giant hack? > > https://sites.google.com/site/ipv6implementors/2010/agenda/05_Chase_Googleco nf-BroadbandtransitiontoIPv6using6rd.pdf?attredirects=0 > Found an article talking about at&t v6 support http://www.networkworld.com/news/2010/102710-att-ipv6.html?page=3 Also found http://www.corp.att.com/gov/solution/network_services/data_nw/ipv6/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNQKEzAAoJEMvvG/TyLEAt45cP/0g+8lNUb1z6Ew/tWgGPEYWu u7wemSTjs27yxKXIbdfWzcWizvX3THHFNW6oRlRIdaH3z+Ttkzb/ne5wEDw9lcgV vnW0n/QjKQOWFaZ+chgEpplEVPth5jww/B/o9taeS7MXonbhQipTeTo3/U7am0GB MCZXngLllOhPZmmjhqsssiLX94wjc5uvqSdAExTt7aXQ7+SaVzpFghXTZgWAG9eE X9JpFeLhJMNPed1MOzxOn7WTsqDu2sHyszoyrZwGyjyQ/JZFDFfdhE3qQPRe97tv ZOmlfPYFjJRjQ4MlY7iX+BI/CTRAeM+59oslpX8h7VeGY4zmlNGw8dhR1yvB400h w+/GubudSnL50XppUslKWbl03v+4dTQYMy3dotwH2OM8ovcJMn596rLW8j+3zV7t zcOuLSLFlqY6QZYy8tp705qzYesLWvHJJlpbXryyOGoz/5SJyTvfkDywOgyNeXz4 siU2a+JaAxlJsrBc9YsabCY8C60zFQxKBwANXWhvP7TZiFtt+SaNLp/Eahh9NoAO Zygs4FekumT9TFeNsAnPlHFFCl9v6fU0Yxc8u0ffYa2+hW6f/2My4tY0n07PNd8l DUUO7h9GtLpfEgTk2eLavY8HZcb1RtA4cvMe8n1J2GOVCwpGfOD0xl1Y3AX6v+rk JuGqPIfyQ8GiNtj7KzRV =LASk -----END PGP SIGNATURE----- From frnkblk at iname.com Thu Jan 27 00:51:50 2011 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 27 Jan 2011 00:51:50 -0600 Subject: What's the current state of major access networks in North America ipv6 delivery status? In-Reply-To: <4D409787.8050104@knownelement.com> References: <4D409787.8050104@knownelement.com> Message-ID: <006b01cbbdee$ac792e00$056b8a00$@iname.com> Two good lists are here: http://www.sixxs.net/faq/connectivity/?faq=native http://www.sixxs.net/wiki/IPv6_Enabled_Service_Providers Frank -----Original Message----- From: Charles N Wyble [mailto:charles at knownelement.com] Sent: Wednesday, January 26, 2011 3:52 PM To: nanog at nanog.org Subject: What's the current state of major access networks in North America ipv6 delivery status? -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Is anyone tracking the major consumer/business class access networks delivery of ipv6 in North America? I'm on ATT DSL. It looks like they want to use 6rd? I've only briefly looked into 6rd. Is this a dead end path/giant hack? https://sites.google.com/site/ipv6implementors/2010/agenda/05_Chase_Googleco nf-BroadbandtransitiontoIPv6using6rd.pdf?attredirects=0 I spoke with impulse.net last year, which appears to serve large portions of the AT&T cable plant in Southern California. They were willing to offer native ipv6. Not sure how (one /64, a /48) etc. I see that FiOS did a trial in April 2010 http://newscenter.verizon.com/press-releases/verizon/2010/verizon-begins-tes ting-ipv6.html (it mentions special CPE). What about verizon DSL? Comcast is currently conducting trials: http://comcast6.net/ (anyone participated in this?) How about TimeWarnerCable? They don't seem to have any sort of v6 offering, on wholesale or retail services. Am I missing anyone in the DSL/Cable/FTTH market? As for wireless broadband providers, there is satellite and 3g/4g/LTE. I haven't looked at the satellite providers. I know Verizon is offering dual stack on their LTE service, according to a thread a couple weeks ago. T-mobile is offering it on the small subset of phones that have v6 capable baseband. For grins and giggles, how does North America stack up against other regions, when it comes to access network ipv6 delivery. Thanks. - -- Charles N Wyble (charles at knownelement.com) Systems craftsman for the stars http://www.knownelement.com Mobile: 626 539 4344 Office: 310 929 8793 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNQJd/AAoJEMvvG/TyLEAtIx4P/1ehNtwotF30HZf4BqeWlJ7C gGmp33VkvwPdh8qUT4scHT/Wcql2V/ijhEJk7t0Tu9F98ig51c3euLuJ9iUhgP8v RdX9Ty8uAThs2EL/sT3aEVlrbiEOtkjW5zFQzWv3So7aPFeO9u5uBa9XO2eeOFG4 nI1ztpPzq3obGGLZWixIJ3ukOvKnb1ilKk74h9kjvnRA89wE1nS8ZvulWdWovAZ6 CaiU54SARQFlqtZ5PsrPrAi1LEz5lXP3Pp3kvphjp019XmyPvtgFwqwX6WoMbBgQ hHulUEnTX9A/3S/Llzz/eQRcWDX+KtqfF/khNBglsr6Y8tBgvJ360YI7dmn9J2hS 1QmnkiwTKlSkvbBM9HVbC/no7nB/J4ybOTVV004ciY6WWTRnCNGtgnoUWO4+qJVK E0996B2egOmhkUJs8AR+VYsguEVbSc12wbxZYrfjTjh7yE87q92okw/mUVi5OOVL t+ysZpV6yifR6/0T26VTJnJ/Ha6tjOE8SmA6lSKdKac5GTPkFBRqzkqsgGmF3lQq NAYMaVKmmq58j5e3eA8btGNf/u4wzJv9JJFXx3aij7pCE29yAfSrMfNV8r6ayAvL lDXQH3AP6LpV6EPb2vAUPq95iw+Fvl5PN80PYdyxVwpphQRutYQYvPZBh9/RfFOi LL5HLupKb900MQX/ZMjY =tE8q -----END PGP SIGNATURE----- From rdobbins at arbor.net Thu Jan 27 00:49:35 2011 From: rdobbins at arbor.net (Roland Dobbins) Date: Thu, 27 Jan 2011 13:49:35 +0700 Subject: Another v6 question In-Reply-To: <5CE30429-3FD2-4554-8D57-670DA6F15FBB@delong.com> References: <AANLkTikEZVYFz+bx7MVXeht_qNnpkUEC_Mx0qhE6J9SR@mail.gmail.com> <55E7EC47-C434-4DF7-B92A-8EBC24133C53@delong.com> <AANLkTi=soS+LQoR3JYJxE8N3o9JYoxrL2dvzHZ+e5Geb@mail.gmail.com> <4F209412-3C3B-4CB6-8EB7-A25ABD1B9DBA@delong.com> <AANLkTinqipvQD-gSt1BZ5FcPT2krNhwqO5dExWrM=muG@mail.gmail.com> <67827BB1-BF59-45AF-842F-B9E1AD7A1F87@delong.com> <AANLkTi=fJbDuv1X_cDSWMzAF7sBkF+2K7+eso97NiQBc@mail.gmail.com> <5CE30429-3FD2-4554-8D57-670DA6F15FBB@delong.com> Message-ID: <A38EB72F-D9AA-4A40-A9B2-8F7125B6525F@arbor.net> On Jan 27, 2011, at 1:29 PM, Owen DeLong wrote: > I'm saying that in IPv6, we've put enough addresses in to allow for things nobody has thought of in 30, 60, 90, even 100 years and then some. Possibly, as long as we don't blow through them via exercises in profligacy nobody has heretofore thought of, heh. ;> ------------------------------------------------------------------------ Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com> Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay From frnkblk at iname.com Thu Jan 27 00:53:13 2011 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 27 Jan 2011 00:53:13 -0600 Subject: What's the current state of major access networks in North America ipv6 delivery status? In-Reply-To: <alpine.OSX.2.00.1101261306130.211@cust11794.lava.net> References: <4D409787.8050104@knownelement.com> <alpine.OSX.2.00.1101261306130.211@cust11794.lava.net> Message-ID: <006c01cbbdee$de6d4400$9b47cc00$@iname.com> All the leading MSOs are actively working towards IPv6 trials and deployments, they're just at different stages. Comcast, as we all can see, is publicly leading, but there are others who are not too far behind. Frank -----Original Message----- From: Antonio Querubin [mailto:tony at lava.net] Sent: Wednesday, January 26, 2011 5:09 PM To: Charles N Wyble Cc: nanog at nanog.org Subject: Re: What's the current state of major access networks in North America ipv6 delivery status? On Wed, 26 Jan 2011, Charles N Wyble wrote: > How about TimeWarnerCable? They don't seem to have any sort of v6 > offering, on wholesale or retail services. TW Cable has no IPv6 offering. However, TW Telecom provides IPv6 connectivity upon request. By default they only provide a /56 if you need multiple subnets and you have to provide further justification to get a /48. Antonio Querubin e-mail/xmpp: tony at lava.net From frnkblk at iname.com Thu Jan 27 00:57:43 2011 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 27 Jan 2011 00:57:43 -0600 Subject: Future of the IPv6 CPE survey on RIPE Labs - Your Input Needed In-Reply-To: <4D4060FE.1000504@brightok.net> References: <1164463.290.1296018492548.JavaMail.franck@franck-martins-macbook-pro.local> <alpine.BSF.2.00.1101260856400.69156@mignon.ki.iif.hu> <31362582-C2A9-45CC-A3E9-13EB5743C957@delong.com> <AANLkTinkMg+n6z8nZbxBD+9uRe5BBc2c+ceExbNQgqFp@mail.gmail.com> <CB7A959F-1A6F-4F3E-B937-F7F3C09C85F5@delong.com> <4D4060FE.1000504@brightok.net> Message-ID: <006d01cbbdef$7f425c80$7dc71580$@iname.com> Have you looked at D-Link's DIR-825? It has most of the things you're looking for. The DIR-655 is a more affordable option. In regards to (2), is it even possible to do DHCPv6-PD on with a SLAAC WAN? In regards to (3), I have that working on SRE, but with an external DHCP server. Frank -----Original Message----- From: Jack Bates [mailto:jbates at brightok.net] Sent: Wednesday, January 26, 2011 11:59 AM To: Owen DeLong Cc: nanog at nanog.org Subject: Re: Future of the IPv6 CPE survey on RIPE Labs - Your Input Needed I believe it has to do with IPv6 mechanisms for handling native addressing. I haven't had the opportunity to test it myself, but from dealing with other vendors, I find that they all support subsets of possible configurations. For example, we test the following with each CPE device which supports IPv6 and is up for consideration. 1) 6to4 support 2) SLAAC + DHCPv6-PD on bridging wan (haven't found one yet, and I believe still the only setup for IOS) 3) DHCPv6 IA_TA requests + DHCPv6-PD (too bad IOS SR doesn't support this yet?) 4) Support of RA to determine default route (seen many require manual gateway configurations since DHCPv6 won't send a default router option) 5) PPPoE/A with above combinations 6) PPPoE/A unnumbered ptp + DHCPv6-PD 7) /60 and /48 DHCPv6-PD and how they are assigned by the CPE 8) DHCPv6 IA_TA, SLAAC, and DHCPv6-PD support on the device's LAN and determining the mechanism it uses 9) Default stateful firewall rules for IPv6. 10) Support for static assignments and routing for IPv6 (many devices are still working on dynamic support and have no manual support) I've yet to find a consumer grade product which meets all of these different configurations; especially in the $50 range. Jack On 1/26/2011 11:01 AM, Owen DeLong wrote: > I haven't done exhaustive testing, but, it has to do with certain combinations > of IPv4 configurations and IPv6 routing do work and other combinations > don't. > > Owen > > On Jan 26, 2011, at 4:41 AM, Richard Barnes wrote: > >> Could you elaborate? Which circumstances? >> >> On Wed, Jan 26, 2011 at 4:23 AM, Owen DeLong<owen at delong.com> wrote: >>> It works for routing native IPv6 under some circumstances as well. >>> >>> Owen >>> >>> On Jan 26, 2011, at 12:01 AM, Mohacsi Janos wrote: >>> >>>> >>>> >>>> >>>> On Wed, 26 Jan 2011, Franck Martin wrote: >>>> >>>>> What about an Airport Extreme? It has a wan interface that does PPPOE >>>>> >>>>> The IPv6 feature seems working, with 6to4 or static tunnels and a basic IPv6 firewall. >>>> >>>> Yes it is. I already reported to Marco. >>>> http://labs.ripe.net/Members/marco/content-ipv6-cpe-survey >>>> >>>> It should be included somehow in a matrix But 6to4 (or other tunneling techniques) is only a substitute of real IPv6. >>>> >>>> Regards, >>>> Janos Mohacsi >>>> >>>>> >>>>> ----- Original Message ----- >>>>> From: "Mirjam Kuehne"<mir at ripe.net> >>>>> To: nanog at nanog.org >>>>> Sent: Tuesday, 25 January, 2011 3:34:14 AM >>>>> Subject: Future of the IPv6 CPE survey on RIPE Labs - Your Input Needed >>>>> >>>>> [apologies for duplicates] >>>>> >>>>> Hello, >>>>> >>>>> Based on new information we received since the last publication, we >>>>> updated the IPv6 CPE matrix: >>>>> >>>>> http://labs.ripe.net/Members/mirjam/ipv6-cpe-survey-updated-january-2011 >>>>> >>>>> In order to make this information more useful for a large user base, we >>>>> are preparing a detailed survey to gather more structural feedback about >>>>> the range of equipment that is currently in use. Not only would we like >>>>> you to participate in this survey, but we also ask for your help in >>>>> identifying the right survey questions. Please find a call for input on >>>>> RIPE Labs: >>>>> >>>>> http://labs.ripe.net/Members/marco/future-of-the-ipv6-cpe-survey-more-input- needed >>>>> >>>>> Kind Regards, >>>>> Mirjam Kuehne& Marco Hogewoning >>>>> RIPE NCC >>>>> >>>>> >>>>> >>> >>> >>> > > From frnkblk at iname.com Thu Jan 27 01:04:29 2011 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 27 Jan 2011 01:04:29 -0600 Subject: PPPOE vs DHCP In-Reply-To: <4D406223.4010104@brightok.net> References: <31322983.91296061399385.JavaMail.root@jennyfur.pelican.org> <4D406223.4010104@brightok.net> Message-ID: <006e01cbbdf0$7111e530$5335af90$@iname.com> If Cisco won't do a good job of RBE on the 7206VXR, I may just need to stick with PPPoEv6 on the SR train. I have that successfully working in a test bed. Frank -----Original Message----- From: Jack Bates [mailto:jbates at brightok.net] Sent: Wednesday, January 26, 2011 12:04 PM To: nanog at nanog.org Subject: Re: PPPOE vs DHCP On 1/26/2011 11:03 AM, Tim Franklin wrote: > So they're telling us, at least for PPPoE specifically. Cisco solution is "buy ASR". > This is same solution they've given for the 7206 and other traditional IOS platforms. I haven't checked, but all the RBE/unnumbered vlan support for IPv6 with proxy-ND, better radius backend for DHCPv6, and supposedly IA_TA support for DHCPv6 will be in the ASR only. The features in IOS SR train are somewhat functional but extremely limited. If I find myself having to spend money on ASRs, I may just spend the money replacing them with Juniper. Only reason I haven't is that I haven't needed to spend the money at all. Jack From frnkblk at iname.com Thu Jan 27 01:05:43 2011 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 27 Jan 2011 01:05:43 -0600 Subject: PPPOE vs DHCP In-Reply-To: <4D406223.4010104@brightok.net> References: <31322983.91296061399385.JavaMail.root@jennyfur.pelican.org> <4D406223.4010104@brightok.net> Message-ID: <006f01cbbdf0$9d5ed670$d81c8350$@iname.com> By IA_TA support, do you mean the ability for the 7206VXR to act as the DHCPv6 server? If I understand you correctly, I have it working well with DHCPv6 relay. Frank -----Original Message----- From: Jack Bates [mailto:jbates at brightok.net] Sent: Wednesday, January 26, 2011 12:04 PM To: nanog at nanog.org Subject: Re: PPPOE vs DHCP On 1/26/2011 11:03 AM, Tim Franklin wrote: > So they're telling us, at least for PPPoE specifically. Cisco solution is "buy ASR". > This is same solution they've given for the 7206 and other traditional IOS platforms. I haven't checked, but all the RBE/unnumbered vlan support for IPv6 with proxy-ND, better radius backend for DHCPv6, and supposedly IA_TA support for DHCPv6 will be in the ASR only. The features in IOS SR train are somewhat functional but extremely limited. If I find myself having to spend money on ASRs, I may just spend the money replacing them with Juniper. Only reason I haven't is that I haven't needed to spend the money at all. Jack From frnkblk at iname.com Thu Jan 27 01:09:34 2011 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 27 Jan 2011 01:09:34 -0600 Subject: PPPOE vs DHCP In-Reply-To: <051001cbbcf0$c33e8b20$49bba160$@org> References: <051001cbbcf0$c33e8b20$49bba160$@org> Message-ID: <007001cbbdf1$26b03040$741090c0$@iname.com> We were a mostly PPPoA shop, and were doing PPPoE on our FTTH but moved to DHCP because of our desire to move to v6 without waiting for the access vendor and to get rid of supporting that username/password combo. And DSL modems that we're replacing in the field we're moving from PPPoA to PPPoE because of Ethernet transport because I'm not as sold on RBE in a 7206VXR, even though I really could use the same Option 82 in the same way as we do for FTTH. VLAN-per-user seems like a lot of router config overhead, though I could be proved wrong if I misunderstand. Frank -----Original Message----- From: Paul Stewart [mailto:paul at paulstewart.org] Sent: Tuesday, January 25, 2011 6:34 PM To: nanog at nanog.org Subject: PPPOE vs DHCP Hey folks... I'm meeting with a customer tomorrow (service provider, rural telco) and we're pitching they move to a PPPOE platform most likely. But to be fair, I'm looking to draw up a comparison so they are "well informed" of the pros/cons. Has anyone done this? <snip> From tony at lava.net Thu Jan 27 01:53:17 2011 From: tony at lava.net (Antonio Querubin) Date: Wed, 26 Jan 2011 21:53:17 -1000 (HST) Subject: Ipv6 for the content provider In-Reply-To: <5B7007C4-2F56-4193-8A5F-EFDDCCB49830@delong.com> References: <4D406670.8040202@knownelement.com> <20110126191710.GB1495@sekishi.zefyris.com> <E3870C8B-6D62-46F9-87D6-CCC04E31BCEA@delong.com> <alpine.OSX.2.00.1101261257290.211@cust11794.lava.net> <5B7007C4-2F56-4193-8A5F-EFDDCCB49830@delong.com> Message-ID: <alpine.OSX.2.00.1101262142150.144@cust11794.lava.net> On Wed, 26 Jan 2011, Owen DeLong wrote: > It's actually pretty well known and it is documented in several places in plain > sight. Where? A search for IPV6_V6ONLY in the FreeBSD Handbook yields nothing. You'd think the brokenness would at least be mentioned in the handbook. A similar search of the FreeBSD FAQ yields a bunch of hits but none that really mention the RFC brokenness. The only place where I've seen this behaviour mentioned in the past is in bug reports. And the responses to those were that the non-compliant behaviour was preferred but would/should be more clearly documented. Years later, the documentation is still lacking. Antonio Querubin e-mail/xmpp: tony at lava.net From mohacsi at niif.hu Thu Jan 27 03:19:18 2011 From: mohacsi at niif.hu (Mohacsi Janos) Date: Thu, 27 Jan 2011 10:19:18 +0100 (CET) Subject: Future of the IPv6 CPE survey on RIPE Labs - Your Input Needed In-Reply-To: <AANLkTinkMg+n6z8nZbxBD+9uRe5BBc2c+ceExbNQgqFp@mail.gmail.com> References: <1164463.290.1296018492548.JavaMail.franck@franck-martins-macbook-pro.local> <alpine.BSF.2.00.1101260856400.69156@mignon.ki.iif.hu> <31362582-C2A9-45CC-A3E9-13EB5743C957@delong.com> <AANLkTinkMg+n6z8nZbxBD+9uRe5BBc2c+ceExbNQgqFp@mail.gmail.com> Message-ID: <alpine.BSF.2.00.1101271015490.69156@mignon.ki.iif.hu> On Wed, 26 Jan 2011, Richard Barnes wrote: > Could you elaborate? Which circumstances? > > On Wed, Jan 26, 2011 at 4:23 AM, Owen DeLong <owen at delong.com> wrote: >> It works for routing native IPv6 under some circumstances as well. If the broadband service is provided with bridged mode (i.e. If your router gets IPv4 via DHCP). As written PPPoE with IPv6 is not supported. Regards, Janos Mohacsi >> >> Owen >> >> On Jan 26, 2011, at 12:01 AM, Mohacsi Janos wrote: >> >>> >>> >>> >>> On Wed, 26 Jan 2011, Franck Martin wrote: >>> >>>> What about an Airport Extreme? It has a wan interface that does PPPOE >>>> >>>> The IPv6 feature seems working, with 6to4 or static tunnels and a basic IPv6 firewall. >>> >>> Yes it is. I already reported to Marco. >>> http://labs.ripe.net/Members/marco/content-ipv6-cpe-survey >>> >>> It should be included somehow in a matrix But 6to4 (or other tunneling techniques) is only a substitute of real IPv6. >>> >>> Regards, >>> ? ? ? Janos Mohacsi >>> >>>> >>>> ----- Original Message ----- >>>> From: "Mirjam Kuehne" <mir at ripe.net> >>>> To: nanog at nanog.org >>>> Sent: Tuesday, 25 January, 2011 3:34:14 AM >>>> Subject: Future of the IPv6 CPE survey on RIPE Labs - Your Input Needed >>>> >>>> [apologies for duplicates] >>>> >>>> Hello, >>>> >>>> Based on new information we received since the last publication, we >>>> updated the IPv6 CPE matrix: >>>> >>>> http://labs.ripe.net/Members/mirjam/ipv6-cpe-survey-updated-january-2011 >>>> >>>> In order to make this information more useful for a large user base, we >>>> are preparing a detailed survey to gather more structural feedback about >>>> the range of equipment that is currently in use. Not only would we like >>>> you to participate in this survey, but we also ask for your help in >>>> identifying the right survey questions. Please find a call for input on >>>> RIPE Labs: >>>> >>>> http://labs.ripe.net/Members/marco/future-of-the-ipv6-cpe-survey-more-input-needed >>>> >>>> Kind Regards, >>>> Mirjam Kuehne & Marco Hogewoning >>>> RIPE NCC >>>> >>>> >>>> >> >> >> > From ivan.brunello at gmail.com Thu Jan 27 04:30:41 2011 From: ivan.brunello at gmail.com (Ivan Brunello) Date: Thu, 27 Jan 2011 11:30:41 +0100 Subject: NANOG Digest, Vol 36, Issue 141 In-Reply-To: <mailman.2605.1295989968.21807.nanog@nanog.org> References: <mailman.2605.1295989968.21807.nanog@nanog.org> Message-ID: <AANLkTikrtJmMWbg+6bFZMFbtXjXkc0_SAzhC_c8rnvkr@mail.gmail.com> > > Message: 10 > Date: Tue, 25 Jan 2011 16:11:46 -0500 > From: Christopher <caldcv at gmail.com> > Subject: Re: Network Naming > To: nanog at nanog.org > Message-ID: <4D3F3C92.9050401 at gmail.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > I usually name them after ex-girlfriends > > > On 01/25/2011 03:50 PM, Nick Olsen wrote: > > Whats the rule of thumb for naming gear these days > > (routers,switches...etc). Or is there one? > > > > looks like level3 does something like > > interface.routertype.location.level3.net > > > > Nick Olsen > > Network Operations > > (855) FLSPEED x106 > > > > > > > I would then get short of names VERY FAST :-) Ivan Brunello Net Ops .... From hank at efes.iucc.ac.il Thu Jan 27 05:21:20 2011 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Thu, 27 Jan 2011 13:21:20 +0200 (IST) Subject: Found: Who is responsible for no more IP addresses Message-ID: <alpine.LRH.2.00.1101271319090.15061@efes.iucc.ac.il> "World to run out of IP addresses soon, Internet expert says" http://news.xinhuanet.com/english2010/sci/2011-01/26/c_13708282.htm "Vint Cerf, who helped create IPv4 in 1977 and one of the founding fathers of the Web, told Australia's Sydney Morning Herald that IP addresses will be used up soon, perhaps within weeks. "I thought it was an experiment and I thought that 4.3 billion IPv4 addresses would be enough to do an experiment," Cerf was quoted as saying, adding it is his "fault" that "we were running out of the addresses."" Glad we cleared that up! :-) -Hank From John_Brzozowski at Cable.Comcast.com Thu Jan 27 05:57:04 2011 From: John_Brzozowski at Cable.Comcast.com (Brzozowski, John) Date: Thu, 27 Jan 2011 11:57:04 +0000 Subject: What's the current state of major access networks in North America ipv6 delivery status? In-Reply-To: <BACEA722-744B-4773-89EF-03FBB933E1E4@delong.com> Message-ID: <C966C429.7FD46%john_brzozowski@cable.comcast.com> In order to deploy /56 to end users would require an IPv6 /24 be dedicated to 6rd, /48s would require a dedicated IPv6 /16. This assumes an operator wants/needs to provide IPv6 via 6rd to end users where their IPv4 address is fully unique. There is quite a bit of IPv6 address space that does not gets utilized in this model. The routers we are using as part of the trials only support /64 as such we are using an IPv6 /32. It is also important that operators plan for the ability to delegate prefixes that are shorter than a /64. There are several cases that we have seen where the router can only make use of a /64. This is better than nothing when referring to legacy devices that have been able to introduce some support for IPv6 and would have otherwise been IPv4 only devices. John ========================================= John Jason Brzozowski Comcast Cable e) mailto:john_brzozowski at cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net ========================================= On 1/26/11 5:02 PM, "Owen DeLong" <owen at delong.com> wrote: > >On Jan 26, 2011, at 1:52 PM, Charles N Wyble wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> >> Is anyone tracking the major consumer/business class access networks >> delivery of ipv6 in North America? >> >> I'm on ATT DSL. It looks like they want to use 6rd? I've only briefly >> looked into 6rd. Is this a dead end path/giant hack? >> >> >>https://sites.google.com/site/ipv6implementors/2010/agenda/05_Chase_Googl >>econf-BroadbandtransitiontoIPv6using6rd.pdf?attredirects=0 >> >It's a fairly ugly way to deliver IPv6, but, as transition technologies >go, it's the least dead-end of the options. > >It at least provides essentially native dual stack environment. The >only difference is that your IPv6 access is via a tunnel. You'll probably >be limited to a /56 or less over 6rd, unfortunately, but, because of the >awful way 6rd consumes addresses, handing out /48s would be >utterly impractical. Free.fr stuck their customers with /60s, which is >hopefully a very temporary situation. > >> >> I spoke with impulse.net last year, which appears to serve large >> portions of the AT&T cable plant in Southern California. They were >> willing to offer native ipv6. Not sure how (one /64, a /48) etc. >> >You should definitely push your providers to give you a /48 if >possible. If /56 or worse /60 or worst of all, /64 become widespread >trends, it may significantly impact, delay, or even prevent innovations >in the end-user networking/consumer electronics markets. > >Owen > > From Skeeve at eintellego.net Thu Jan 27 06:20:48 2011 From: Skeeve at eintellego.net (Skeeve Stevens) Date: Thu, 27 Jan 2011 23:20:48 +1100 Subject: Found: Who is responsible for no more IP addresses In-Reply-To: <alpine.LRH.2.00.1101271319090.15061@efes.iucc.ac.il> Message-ID: <C967AE47.1FEBF%skeeve@eintellego.net> Class Action? ;-) ...Skeeve -- Skeeve Stevens, CEO eintellego Pty Ltd - The Networking Specialists skeeve at eintellego.net / www.eintellego.net Phone: 1300 753 383, Fax: (+612) 8572 9954 Cell +61 (0)414 753 383 / skype://skeeve www.linkedin.com/in/skeeve ; facebook.com/eintellego -- eintellego - The Experts that the Experts call - Juniper - HP Networking - Cisco - Brocade - Arista - Allied Telesis Disclaimer: Limits of Liability and Disclaimer: This message is for the named person's use only. It may contain sensitive and private proprietary or legally privileged information. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. eintellego Pty Ltd and each legal entity in the Tefilah Pty Ltd group of companies reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of any such entity. Any reference to costs, fee quotations, contractual transactions and variations to contract terms is subject to separate confirmation in writing signed by an authorised representative of eintellego. Whilst all efforts are made to safeguard inbound and outbound e-mails, we cannot guarantee that attachments are virus-free or compatible with your systems and do not accept any liability in respect of viruses or computer problems experienced. -----Original Message----- From: Hank Nussbacher <hank at efes.iucc.ac.il> Date: Thu, 27 Jan 2011 22:21:20 +1100 To: "nanog at nanog.org" <nanog at nanog.org> Subject: Found: Who is responsible for no more IP addresses >"World to run out of IP addresses soon, Internet expert says" > >http://news.xinhuanet.com/english2010/sci/2011-01/26/c_13708282.htm > >"Vint Cerf, who helped create IPv4 in 1977 and one of the founding >fathers >of the Web, told Australia's Sydney Morning Herald that IP addresses will >be used up soon, perhaps within weeks. > >"I thought it was an experiment and I thought that 4.3 billion IPv4 >addresses would be enough to do an experiment," Cerf was quoted as >saying, >adding it is his "fault" that "we were running out of the addresses."" > >Glad we cleared that up! :-) > >-Hank > From nick at foobar.org Thu Jan 27 06:24:13 2011 From: nick at foobar.org (Nick Hilliard) Date: Thu, 27 Jan 2011 12:24:13 +0000 Subject: Found: Who is responsible for no more IP addresses In-Reply-To: <alpine.LRH.2.00.1101271319090.15061@efes.iucc.ac.il> References: <alpine.LRH.2.00.1101271319090.15061@efes.iucc.ac.il> Message-ID: <4D4163ED.1060201@foobar.org> On 27/01/2011 11:21, Hank Nussbacher wrote: > "I thought it was an experiment and I thought that 4.3 billion IPv4 > addresses would be enough to do an experiment," Cerf was quoted as saying, > adding it is his "fault" that "we were running out of the addresses."" Fortunately, web developers have fixed the problem according to Fox news: http://www.foxnews.com/scitech/2011/01/26/internet-run-ip-addresses-happens-anyones-guess/ "Web developers have tried to compensate for this problem by creating IPv6 -- a system that recognizes six-digit IP addresses rather than four-digit ones." It will be difficult initially, though: "But IPv6 isn't backwards-compatible with IPv4, meaning that it's not able to read most content that operates on an IPv4 system. At best, the user experience will be clunky and slow. At worst, instead of a webpage, all users will be able to view is a blank page." I'm glad Fox has cleared all this up for us. Nick From gary.steers at sharedband.com Thu Jan 27 06:45:29 2011 From: gary.steers at sharedband.com (Gary Steers) Date: Thu, 27 Jan 2011 12:45:29 -0000 Subject: Found: Who is responsible for no more IP addresses In-Reply-To: <alpine.LRH.2.00.1101271319090.15061@efes.iucc.ac.il> References: <alpine.LRH.2.00.1101271319090.15061@efes.iucc.ac.il> Message-ID: <CF4687332659244DA0C2D1F53AFF9F836149D1@sb-server-sbs.SharedComUK.local> Him, admitting fault, well then, why should we spend money on IPv6, if it's his fault does that mean he will come to our business to roll out v6? Let's get a list together of who he will visit first :) G Gary Steers Sharedband NOC/3rd Line Support E: gary.steers at sharedband.com -----Original Message----- From: Hank Nussbacher [mailto:hank at efes.iucc.ac.il] Sent: 27 January 2011 11:21 To: nanog at nanog.org Subject: Found: Who is responsible for no more IP addresses "World to run out of IP addresses soon, Internet expert says" http://news.xinhuanet.com/english2010/sci/2011-01/26/c_13708282.htm "Vint Cerf, who helped create IPv4 in 1977 and one of the founding fathers of the Web, told Australia's Sydney Morning Herald that IP addresses will be used up soon, perhaps within weeks. "I thought it was an experiment and I thought that 4.3 billion IPv4 addresses would be enough to do an experiment," Cerf was quoted as saying, adding it is his "fault" that "we were running out of the addresses."" Glad we cleared that up! :-) -Hank From hank at efes.iucc.ac.il Thu Jan 27 06:50:24 2011 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Thu, 27 Jan 2011 14:50:24 +0200 Subject: Found: Who is responsible for no more IP addresses In-Reply-To: <4D4163ED.1060201@foobar.org> References: <alpine.LRH.2.00.1101271319090.15061@efes.iucc.ac.il> <alpine.LRH.2.00.1101271319090.15061@efes.iucc.ac.il> Message-ID: <5.1.0.14.2.20110127144943.00c2fbb8@efes.iucc.ac.il> At 12:24 27/01/2011 +0000, Nick Hilliard wrote: >On 27/01/2011 11:21, Hank Nussbacher wrote: >>"I thought it was an experiment and I thought that 4.3 billion IPv4 >>addresses would be enough to do an experiment," Cerf was quoted as saying, >>adding it is his "fault" that "we were running out of the addresses."" > >Fortunately, web developers have fixed the problem according to Fox news: > >http://www.foxnews.com/scitech/2011/01/26/internet-run-ip-addresses-happens-anyones-guess/ > > >"Web developers have tried to compensate for this problem by creating IPv6 >-- a system that recognizes six-digit IP addresses rather than four-digit >ones." > >It will be difficult initially, though: > >"But IPv6 isn't backwards-compatible with IPv4, meaning that it's not able >to read most content that operates on an IPv4 system. At best, the user >experience will be clunky and slow. At worst, instead of a webpage, all >users will be able to view is a blank page." > >I'm glad Fox has cleared all this up for us. I guess they are hiring TSA rejects. No other way to explain the cluelessness :-) -Hank >Nick From carlosm3011 at gmail.com Thu Jan 27 06:56:26 2011 From: carlosm3011 at gmail.com (Carlos Martinez-Cagnazzo) Date: Thu, 27 Jan 2011 10:56:26 -0200 Subject: What's the current state of major access networks in North America ipv6 delivery status? In-Reply-To: <C966C429.7FD46%john_brzozowski@cable.comcast.com> References: <BACEA722-744B-4773-89EF-03FBB933E1E4@delong.com> <C966C429.7FD46%john_brzozowski@cable.comcast.com> Message-ID: <AANLkTi=mjhRtHQYO1LD=9Ai2Tin+QCtdnNYkdYrf95z0@mail.gmail.com> Reading this thread, and building on many comments to a previous one, I definitely see the need for subnetting a /64 arising sooner than later. It might not be perfect, It might be ugly, but it will happen. And, if you ask me, I would rather subnet a /64 than end up with a ipv6 version of NAT, a much worse alternative. cheers, Carlos On Thu, Jan 27, 2011 at 9:57 AM, Brzozowski, John <John_Brzozowski at cable.comcast.com> wrote: > In order to deploy /56 to end users would require an IPv6 /24 be dedicated > to 6rd, /48s would require a dedicated IPv6 /16. ?This assumes an operator > wants/needs to provide IPv6 via 6rd to end users where their IPv4 address > is fully unique. ?There is quite a bit of IPv6 address space that does not > gets utilized in this model. > > The routers we are using as part of the trials only support /64 as such we > are using an IPv6 /32. > > It is also important that operators plan for the ability to delegate > prefixes that are shorter than a /64. ?There are several cases that we > have seen where the router can only make use of a /64. ?This is better > than nothing when referring to legacy devices that have been able to > introduce some support for IPv6 and would have otherwise been IPv4 only > devices. > > John > ========================================= > John Jason Brzozowski > Comcast Cable > e) mailto:john_brzozowski at cable.comcast.com > o) 609-377-6594 > m) 484-962-0060 > w) http://www.comcast6.net > ========================================= > > > > > On 1/26/11 5:02 PM, "Owen DeLong" <owen at delong.com> wrote: > >> >>On Jan 26, 2011, at 1:52 PM, Charles N Wyble wrote: >> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> >>> Is anyone tracking the major consumer/business class access networks >>> delivery of ipv6 in North America? >>> >>> I'm on ATT DSL. It looks like they want to use 6rd? I've only briefly >>> looked into 6rd. Is this a dead end path/giant hack? >>> >>> >>>https://sites.google.com/site/ipv6implementors/2010/agenda/05_Chase_Googl >>>econf-BroadbandtransitiontoIPv6using6rd.pdf?attredirects=0 >>> >>It's a fairly ugly way to deliver IPv6, but, as transition technologies >>go, it's the least dead-end of the options. >> >>It at least provides essentially native dual stack environment. The >>only difference is that your IPv6 access is via a tunnel. You'll probably >>be limited to a /56 or less over 6rd, unfortunately, but, because of the >>awful way 6rd consumes addresses, handing out /48s would be >>utterly impractical. Free.fr stuck their customers with /60s, which is >>hopefully a very temporary situation. >> >>> >>> I spoke with impulse.net last year, which appears to serve large >>> portions of the AT&T cable plant in Southern California. They were >>> willing to offer native ipv6. Not sure how (one /64, a /48) etc. >>> >>You should definitely push your providers to give you a /48 if >>possible. If /56 or worse /60 or worst of all, /64 become widespread >>trends, it may significantly impact, delay, or even prevent innovations >>in the end-user networking/consumer electronics markets. >> >>Owen >> >> > > > -- -- ========================= Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net ========================= From swm at emanon.com Thu Jan 27 06:59:20 2011 From: swm at emanon.com (Scott Morris) Date: Thu, 27 Jan 2011 07:59:20 -0500 Subject: NANOG Digest, Vol 36, Issue 141 In-Reply-To: <AANLkTikrtJmMWbg+6bFZMFbtXjXkc0_SAzhC_c8rnvkr@mail.gmail.com> References: <mailman.2605.1295989968.21807.nanog@nanog.org> <AANLkTikrtJmMWbg+6bFZMFbtXjXkc0_SAzhC_c8rnvkr@mail.gmail.com> Message-ID: <4D416C28.8020206@emanon.com> So.... Do you run a small network? Or are there LOTS of EX-girlfriends? ;) Scott On 1/27/11 5:30 AM, Ivan Brunello wrote: >> Message: 10 >> Date: Tue, 25 Jan 2011 16:11:46 -0500 >> From: Christopher <caldcv at gmail.com> >> Subject: Re: Network Naming >> To: nanog at nanog.org >> Message-ID: <4D3F3C92.9050401 at gmail.com> >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> >> I usually name them after ex-girlfriends >> >> >> On 01/25/2011 03:50 PM, Nick Olsen wrote: >>> Whats the rule of thumb for naming gear these days >>> (routers,switches...etc). Or is there one? >>> >>> looks like level3 does something like >>> interface.routertype.location.level3.net >>> >>> Nick Olsen >>> Network Operations >>> (855) FLSPEED x106 >>> >>> >>> > I would then get short of names VERY FAST :-) > > Ivan Brunello > Net Ops > .... > > From tony at lava.net Thu Jan 27 07:11:21 2011 From: tony at lava.net (Antonio Querubin) Date: Thu, 27 Jan 2011 03:11:21 -1000 (HST) Subject: What's the current state of major access networks in North America ipv6 delivery status? In-Reply-To: <AANLkTi=mjhRtHQYO1LD=9Ai2Tin+QCtdnNYkdYrf95z0@mail.gmail.com> References: <BACEA722-744B-4773-89EF-03FBB933E1E4@delong.com> <C966C429.7FD46%john_brzozowski@cable.comcast.com> <AANLkTi=mjhRtHQYO1LD=9Ai2Tin+QCtdnNYkdYrf95z0@mail.gmail.com> Message-ID: <alpine.OSX.2.00.1101270306550.528@cust11794.lava.net> On Thu, 27 Jan 2011, Carlos Martinez-Cagnazzo wrote: > Reading this thread, and building on many comments to a previous one, > I definitely see the need for subnetting a /64 arising sooner than > later. > > It might not be perfect, It might be ugly, but it will happen. And, if > you ask me, I would rather subnet a /64 than end up with a ipv6 > version of NAT, a much worse alternative. Maybe not NAT but some kind of proxy ND and/or a migration from routing firewalls to bridging firewalls. If the broadband provider is only providing a single /64, it's not likely they're gonna be willing to add routes to your gateway. Antonio Querubin e-mail/xmpp: tony at lava.net From narten at us.ibm.com Thu Jan 27 07:43:10 2011 From: narten at us.ibm.com (Thomas Narten) Date: Thu, 27 Jan 2011 08:43:10 -0500 Subject: What's the current state of major access networks in North America ipv6 delivery status? In-Reply-To: <006c01cbbdee$de6d4400$9b47cc00$@iname.com> References: <4D409787.8050104@knownelement.com> <alpine.OSX.2.00.1101261306130.211@cust11794.lava.net> <006c01cbbdee$de6d4400$9b47cc00$@iname.com> Message-ID: <201101271343.p0RDhAov017652@cichlid.raleigh.ibm.com> > All the leading MSOs are actively working towards IPv6 trials and > deployments, they're just at different stages. Comcast, as we all can see, > is publicly leading, but there are others who are not too far behind. See "U.S. cable companies embrace IPv6" http://www.networkworld.com/news/2010/102810-cable-ipv6.html Thomas From jared at puck.nether.net Thu Jan 27 07:43:53 2011 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 27 Jan 2011 08:43:53 -0500 Subject: Ipv6 for the content provider In-Reply-To: <alpine.OSX.2.00.1101262142150.144@cust11794.lava.net> References: <4D406670.8040202@knownelement.com> <20110126191710.GB1495@sekishi.zefyris.com> <E3870C8B-6D62-46F9-87D6-CCC04E31BCEA@delong.com> <alpine.OSX.2.00.1101261257290.211@cust11794.lava.net> <5B7007C4-2F56-4193-8A5F-EFDDCCB49830@delong.com> <alpine.OSX.2.00.1101262142150.144@cust11794.lava.net> Message-ID: <D98E475C-BAD8-453C-B9F3-D5F6F2EDF411@puck.nether.net> On Jan 27, 2011, at 2:53 AM, Antonio Querubin wrote: > On Wed, 26 Jan 2011, Owen DeLong wrote: > >> It's actually pretty well known and it is documented in several places in plain >> sight. > > Where? > > A search for IPV6_V6ONLY in the FreeBSD Handbook yields nothing. You'd think the brokenness would at least be mentioned in the handbook. > > A similar search of the FreeBSD FAQ yields a bunch of hits but none that really mention the RFC brokenness. > > The only place where I've seen this behaviour mentioned in the past is in bug reports. And the responses to those were that the non-compliant behaviour was preferred but would/should be more clearly documented. Years later, the documentation is still lacking. The FreeBSD releng/core community has consistently done odd things that have caused them to lose favor in my mind, ranging from: a) Lack of support of serial console other than com1 without rebuilding the kernel, boot blocks, etc. b) soliciting feedback in -RC releases and not fixing defects in the -RELEASE, nor updating errata documents regarding defects they have refused to fix c) Generally being arrogant and rude to the user community that may not want to manage a large set of systems by "make buildworld" These are just a few of my unfavorite things regarding that community. I have the things I like, but the things that I don't continue to outweigh and feed into regret of using their systems. At least when I freebsd-update now, I don't need to edit german ISDN rate files anymore, but the fact that I had to in the first place is problematic to say the least. - Jared REFERENCES: a: [26.6.5.2] http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/serialconsole-setup.html b: http://www.freebsd.org/cgi/query-pr.cgi?pr=140712 From owen at delong.com Thu Jan 27 07:49:19 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 27 Jan 2011 05:49:19 -0800 Subject: Found: Who is responsible for no more IP addresses In-Reply-To: <4D4163ED.1060201@foobar.org> References: <alpine.LRH.2.00.1101271319090.15061@efes.iucc.ac.il> <4D4163ED.1060201@foobar.org> Message-ID: <22FB1A8D-90B3-49F1-BFD8-E581AAE1C808@delong.com> On Jan 27, 2011, at 4:24 AM, Nick Hilliard wrote: > On 27/01/2011 11:21, Hank Nussbacher wrote: >> "I thought it was an experiment and I thought that 4.3 billion IPv4 >> addresses would be enough to do an experiment," Cerf was quoted as saying, >> adding it is his "fault" that "we were running out of the addresses."" > > Fortunately, web developers have fixed the problem according to Fox news: > > http://www.foxnews.com/scitech/2011/01/26/internet-run-ip-addresses-happens-anyones-guess/ > > "Web developers have tried to compensate for this problem by creating IPv6 -- a system that recognizes six-digit IP addresses rather than four-digit ones." > Consider the source... Fox -- All the news that's fit to misquote. (or something like that). Those guys never get anything technical or political right.* > It will be difficult initially, though: > > "But IPv6 isn't backwards-compatible with IPv4, meaning that it's not able to read most content that operates on an IPv4 system. At best, the user experience will be clunky and slow. At worst, instead of a webpage, all users will be able to view is a blank page." > > I'm glad Fox has cleared all this up for us. > ROFLMAO Owen *In order for Fox to sue me for libel, they first have to prove my statement is false. From carlos at lacnic.net Thu Jan 27 07:56:15 2011 From: carlos at lacnic.net (Carlos Martinez-Cagnazzo) Date: Thu, 27 Jan 2011 11:56:15 -0200 Subject: What's the current state of major access networks in North America ipv6 delivery status? In-Reply-To: <alpine.OSX.2.00.1101270306550.528@cust11794.lava.net> References: <BACEA722-744B-4773-89EF-03FBB933E1E4@delong.com> <C966C429.7FD46%john_brzozowski@cable.comcast.com> <AANLkTi=mjhRtHQYO1LD=9Ai2Tin+QCtdnNYkdYrf95z0@mail.gmail.com> <alpine.OSX.2.00.1101270306550.528@cust11794.lava.net> Message-ID: <AANLkTinMbE1Lm4KvB-X3uK+DF4YKB49Ycu3shbrBMj4U@mail.gmail.com> I guess I won't need to add routes to my gateway, only subnetting on the inside will probably do for the time being (a hub/spoke topology, routing only between directly-connected subnets). And many ISPs allow you to buy your own CPE. Using an AirPort Extreme (or other home router with similar features) in bridged mode would do the trick, i guess. :-) cheers, Carlos On Thu, Jan 27, 2011 at 11:11 AM, Antonio Querubin <tony at lava.net> wrote: > On Thu, 27 Jan 2011, Carlos Martinez-Cagnazzo wrote: > >> Reading this thread, and building on many comments to a previous one, >> I definitely see the need for subnetting a /64 arising sooner than >> later. >> >> It might not be perfect, It might be ugly, but it will happen. And, if >> you ask me, I would rather subnet a /64 than end up with a ipv6 >> version of NAT, a much worse alternative. > > Maybe not NAT but some kind of proxy ND and/or a migration from routing > firewalls to bridging firewalls. ?If the broadband provider is only > providing a single /64, it's not likely they're gonna be willing to add > routes to your gateway. > > Antonio Querubin > e-mail/xmpp: ?tony at lava.net > > From John_Brzozowski at Cable.Comcast.com Thu Jan 27 07:58:55 2011 From: John_Brzozowski at Cable.Comcast.com (Brzozowski, John) Date: Thu, 27 Jan 2011 13:58:55 +0000 Subject: What's the current state of major access networks in North America ipv6 delivery status? In-Reply-To: <AANLkTi=mjhRtHQYO1LD=9Ai2Tin+QCtdnNYkdYrf95z0@mail.gmail.com> Message-ID: <C966E3A9.7FF0C%john_brzozowski@cable.comcast.com> I am definitely *NOT* an advocate of NAT66 nor am I an advocate of further subneting a /64 into longer prefixes. Where additional IPv6 prefixes are required a prefix shorter than a /64 should be delegated. John ========================================= John Jason Brzozowski Comcast Cable e) mailto:john_brzozowski at cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net ========================================= On 1/27/11 7:56 AM, "Carlos Martinez-Cagnazzo" <carlosm3011 at gmail.com> wrote: >Reading this thread, and building on many comments to a previous one, >I definitely see the need for subnetting a /64 arising sooner than >later. > >It might not be perfect, It might be ugly, but it will happen. And, if >you ask me, I would rather subnet a /64 than end up with a ipv6 >version of NAT, a much worse alternative. > >cheers, > >Carlos > >On Thu, Jan 27, 2011 at 9:57 AM, Brzozowski, John ><John_Brzozowski at cable.comcast.com> wrote: >> In order to deploy /56 to end users would require an IPv6 /24 be >>dedicated >> to 6rd, /48s would require a dedicated IPv6 /16. This assumes an >>operator >> wants/needs to provide IPv6 via 6rd to end users where their IPv4 >>address >> is fully unique. There is quite a bit of IPv6 address space that does >>not >> gets utilized in this model. >> >> The routers we are using as part of the trials only support /64 as such >>we >> are using an IPv6 /32. >> >> It is also important that operators plan for the ability to delegate >> prefixes that are shorter than a /64. There are several cases that we >> have seen where the router can only make use of a /64. This is better >> than nothing when referring to legacy devices that have been able to >> introduce some support for IPv6 and would have otherwise been IPv4 only >> devices. >> >> John >> ========================================= >> John Jason Brzozowski >> Comcast Cable >> e) mailto:john_brzozowski at cable.comcast.com >> o) 609-377-6594 >> m) 484-962-0060 >> w) http://www.comcast6.net >> ========================================= >> >> >> >> >> On 1/26/11 5:02 PM, "Owen DeLong" <owen at delong.com> wrote: >> >>> >>>On Jan 26, 2011, at 1:52 PM, Charles N Wyble wrote: >>> >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>>> >>>> >>>> Is anyone tracking the major consumer/business class access networks >>>> delivery of ipv6 in North America? >>>> >>>> I'm on ATT DSL. It looks like they want to use 6rd? I've only briefly >>>> looked into 6rd. Is this a dead end path/giant hack? >>>> >>>> >>>>https://sites.google.com/site/ipv6implementors/2010/agenda/05_Chase_Goo >>>>gl >>>>econf-BroadbandtransitiontoIPv6using6rd.pdf?attredirects=0 >>>> >>>It's a fairly ugly way to deliver IPv6, but, as transition technologies >>>go, it's the least dead-end of the options. >>> >>>It at least provides essentially native dual stack environment. The >>>only difference is that your IPv6 access is via a tunnel. You'll >>>probably >>>be limited to a /56 or less over 6rd, unfortunately, but, because of the >>>awful way 6rd consumes addresses, handing out /48s would be >>>utterly impractical. Free.fr stuck their customers with /60s, which is >>>hopefully a very temporary situation. >>> >>>> >>>> I spoke with impulse.net last year, which appears to serve large >>>> portions of the AT&T cable plant in Southern California. They were >>>> willing to offer native ipv6. Not sure how (one /64, a /48) etc. >>>> >>>You should definitely push your providers to give you a /48 if >>>possible. If /56 or worse /60 or worst of all, /64 become widespread >>>trends, it may significantly impact, delay, or even prevent innovations >>>in the end-user networking/consumer electronics markets. >>> >>>Owen >>> >>> >> >> >> > > > >-- >-- >========================= >Carlos M. Martinez-Cagnazzo >http://www.labs.lacnic.net >========================= From marka at isc.org Thu Jan 27 08:03:19 2011 From: marka at isc.org (Mark Andrews) Date: Fri, 28 Jan 2011 01:03:19 +1100 Subject: What's the current state of major access networks in North America ipv6 delivery status? In-Reply-To: Your message of "Thu, 27 Jan 2011 11:57:04 -0000." <C966C429.7FD46%john_brzozowski@cable.comcast.com> References: <C966C429.7FD46%john_brzozowski@cable.comcast.com> Message-ID: <20110127140319.281E993486C@drugs.dv.isc.org> In message <C966C429.7FD46%john_brzozowski at cable.comcast.com>, "Brzozowski, John" wri tes: > In order to deploy /56 to end users would require an IPv6 /24 be dedicated > to 6rd, /48s would require a dedicated IPv6 /16. This assumes an operator > wants/needs to provide IPv6 via 6rd to end users where their IPv4 address > is fully unique. There is quite a bit of IPv6 address space that does not > gets utilized in this model. No it doesn't require /16 to deploy 6rd with /48's. It does however require the ISP to do more than say "this is our 6rd prefix" and shove all 32 bits of IPv4 address into the delegated prefix. The moment the ISP needs to re-use IPv4 addresses for customers the simple "this is our 6rd prefix" fails to work. If an ISP has 34/8 and 35.0/9 then it needs two blocks of IPv6 addresses on a /24 and one a /25, which would be used like this: [P1 24 bits][low 24 bits][subnet 16 bits][host 64 bits] [P2 25 bits][low 23 bits][subnet 16 bits][host 64 bits] The 6rd routers for P1 know that P1 means the top 8 bits are 34. The 6rd routers for P2 know that P2 means the top 9 bits are 35.0. The DHCP server for subnets in 34/8 are configured to hand out 6rd prefix info for P1 (6rdPrefixLen=24, IPv4MaskLen=8). Similarly 35.0/9 and P2 (6rdPrefixLen=25, IPv4Masklen=9). This really shouldn't be to hard for the provisioning systems to handle. If the ISP was using 10/8 twice to connect to its customers then it would need two /24's (P1 and P2). P1 and P2 would both have 6rdPrefixLen=24, IPv4MaskLen=8. See RFC 5969 (RFC 5569 describes what Free originally did). > The routers we are using as part of the trials only support /64 as such we > are using an IPv6 /32. > > It is also important that operators plan for the ability to delegate > prefixes that are shorter than a /64. There are several cases that we > have seen where the router can only make use of a /64. This is better > than nothing when referring to legacy devices that have been able to > introduce some support for IPv6 and would have otherwise been IPv4 only > devices. > > John > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > John Jason Brzozowski > Comcast Cable > e) mailto:john_brzozowski at cable.comcast.com > o) 609-377-6594 > m) 484-962-0060 > w) http://www.comcast6.net > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > On 1/26/11 5:02 PM, "Owen DeLong" <owen at delong.com> wrote: > > > > >On Jan 26, 2011, at 1:52 PM, Charles N Wyble wrote: > > > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA1 > >>=20 > >>=20 > >> Is anyone tracking the major consumer/business class access networks > >> delivery of ipv6 in North America? > >>=20 > >> I'm on ATT DSL. It looks like they want to use 6rd? I've only briefly > >> looked into 6rd. Is this a dead end path/giant hack? > >>=20 > >>=20 > >>https://sites.google.com/site/ipv6implementors/2010/agenda/05_Chase_Googl > >>econf-BroadbandtransitiontoIPv6using6rd.pdf?attredirects=3D0 > >>=20 > >It's a fairly ugly way to deliver IPv6, but, as transition technologies > >go, it's the least dead-end of the options. > > > >It at least provides essentially native dual stack environment. The > >only difference is that your IPv6 access is via a tunnel. You'll probably > >be limited to a /56 or less over 6rd, unfortunately, but, because of the > >awful way 6rd consumes addresses, handing out /48s would be > >utterly impractical. Free.fr stuck their customers with /60s, which is > >hopefully a very temporary situation. > > > >>=20 > >> I spoke with impulse.net last year, which appears to serve large > >> portions of the AT&T cable plant in Southern California. They were > >> willing to offer native ipv6. Not sure how (one /64, a /48) etc. > >>=20 > >You should definitely push your providers to give you a /48 if > >possible. If /56 or worse /60 or worst of all, /64 become widespread > >trends, it may significantly impact, delay, or even prevent innovations > >in the end-user networking/consumer electronics markets. > > > >Owen > > > > > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From carlosm3011 at gmail.com Thu Jan 27 08:08:48 2011 From: carlosm3011 at gmail.com (Carlos Martinez-Cagnazzo) Date: Thu, 27 Jan 2011 12:08:48 -0200 Subject: What's the current state of major access networks in North America ipv6 delivery status? In-Reply-To: <C966E3A9.7FF0C%john_brzozowski@cable.comcast.com> References: <AANLkTi=mjhRtHQYO1LD=9Ai2Tin+QCtdnNYkdYrf95z0@mail.gmail.com> <C966E3A9.7FF0C%john_brzozowski@cable.comcast.com> Message-ID: <AANLkTinBn4OKVf1dBk=sWOdOpBh-BsWBakVR-LhQq-kj@mail.gmail.com> I agree with you, but, will it happen? The same fixed boundary behaviour that makes the /64 so convenient for LAN addressing ends up making the same /64 very convenient for ISPs as well. They associate the /64 with the "single public IP" they issue to customers nowadays. Again, I would *love* to be wrong on this one. Seriously. This is an argument I sincerely hope to lose, but after being in the ISP business for more than 10 years, I wouldn't expect my local ISPs at least to issue anything shorter than a /64 to customers. And... the argument for this will have a commercial background as well. They will perceive customers who want multiple subnets as customers who can pay more. They will make customers who want multiple subnets go through hops to get a shorter prefix. Justifications and such. Very few people will do it. warm regards Carlos On Thu, Jan 27, 2011 at 11:58 AM, Brzozowski, John <John_Brzozowski at cable.comcast.com> wrote: > I am definitely *NOT* an advocate of NAT66 nor am I an advocate of further > subneting a /64 into longer prefixes. > > Where additional IPv6 prefixes are required a prefix shorter than a /64 > should be delegated. > > John > ========================================= > John Jason Brzozowski > Comcast Cable > e) mailto:john_brzozowski at cable.comcast.com > o) 609-377-6594 > m) 484-962-0060 > w) http://www.comcast6.net > ========================================= > > > > > On 1/27/11 7:56 AM, "Carlos Martinez-Cagnazzo" <carlosm3011 at gmail.com> > wrote: > >>Reading this thread, and building on many comments to a previous one, >>I definitely see the need for subnetting a /64 arising sooner than >>later. >> >>It might not be perfect, It might be ugly, but it will happen. And, if >>you ask me, I would rather subnet a /64 than end up with a ipv6 >>version of NAT, a much worse alternative. >> >>cheers, >> >>Carlos >> >>On Thu, Jan 27, 2011 at 9:57 AM, Brzozowski, John >><John_Brzozowski at cable.comcast.com> wrote: >>> In order to deploy /56 to end users would require an IPv6 /24 be >>>dedicated >>> to 6rd, /48s would require a dedicated IPv6 /16. ?This assumes an >>>operator >>> wants/needs to provide IPv6 via 6rd to end users where their IPv4 >>>address >>> is fully unique. ?There is quite a bit of IPv6 address space that does >>>not >>> gets utilized in this model. >>> >>> The routers we are using as part of the trials only support /64 as such >>>we >>> are using an IPv6 /32. >>> >>> It is also important that operators plan for the ability to delegate >>> prefixes that are shorter than a /64. ?There are several cases that we >>> have seen where the router can only make use of a /64. ?This is better >>> than nothing when referring to legacy devices that have been able to >>> introduce some support for IPv6 and would have otherwise been IPv4 only >>> devices. >>> >>> John >>> ========================================= >>> John Jason Brzozowski >>> Comcast Cable >>> e) mailto:john_brzozowski at cable.comcast.com >>> o) 609-377-6594 >>> m) 484-962-0060 >>> w) http://www.comcast6.net >>> ========================================= >>> >>> >>> >>> >>> On 1/26/11 5:02 PM, "Owen DeLong" <owen at delong.com> wrote: >>> >>>> >>>>On Jan 26, 2011, at 1:52 PM, Charles N Wyble wrote: >>>> >>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>> Hash: SHA1 >>>>> >>>>> >>>>> Is anyone tracking the major consumer/business class access networks >>>>> delivery of ipv6 in North America? >>>>> >>>>> I'm on ATT DSL. It looks like they want to use 6rd? I've only briefly >>>>> looked into 6rd. Is this a dead end path/giant hack? >>>>> >>>>> >>>>>https://sites.google.com/site/ipv6implementors/2010/agenda/05_Chase_Goo >>>>>gl >>>>>econf-BroadbandtransitiontoIPv6using6rd.pdf?attredirects=0 >>>>> >>>>It's a fairly ugly way to deliver IPv6, but, as transition technologies >>>>go, it's the least dead-end of the options. >>>> >>>>It at least provides essentially native dual stack environment. The >>>>only difference is that your IPv6 access is via a tunnel. You'll >>>>probably >>>>be limited to a /56 or less over 6rd, unfortunately, but, because of the >>>>awful way 6rd consumes addresses, handing out /48s would be >>>>utterly impractical. Free.fr stuck their customers with /60s, which is >>>>hopefully a very temporary situation. >>>> >>>>> >>>>> I spoke with impulse.net last year, which appears to serve large >>>>> portions of the AT&T cable plant in Southern California. They were >>>>> willing to offer native ipv6. Not sure how (one /64, a /48) etc. >>>>> >>>>You should definitely push your providers to give you a /48 if >>>>possible. If /56 or worse /60 or worst of all, /64 become widespread >>>>trends, it may significantly impact, delay, or even prevent innovations >>>>in the end-user networking/consumer electronics markets. >>>> >>>>Owen >>>> >>>> >>> >>> >>> >> >> >> >>-- >>-- >>========================= >>Carlos M. Martinez-Cagnazzo >>http://www.labs.lacnic.net >>========================= > > -- -- ========================= Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net ========================= From owen at delong.com Thu Jan 27 08:08:05 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 27 Jan 2011 06:08:05 -0800 Subject: What's the current state of major access networks in North America ipv6 delivery status? In-Reply-To: <alpine.OSX.2.00.1101270306550.528@cust11794.lava.net> References: <BACEA722-744B-4773-89EF-03FBB933E1E4@delong.com> <C966C429.7FD46%john_brzozowski@cable.comcast.com> <AANLkTi=mjhRtHQYO1LD=9Ai2Tin+QCtdnNYkdYrf95z0@mail.gmail.com> <alpine.OSX.2.00.1101270306550.528@cust11794.lava.net> Message-ID: <D6F4DCE7-4021-41E7-9E89-42A8FAEEBB5F@delong.com> On Jan 27, 2011, at 5:11 AM, Antonio Querubin wrote: > On Thu, 27 Jan 2011, Carlos Martinez-Cagnazzo wrote: > >> Reading this thread, and building on many comments to a previous one, >> I definitely see the need for subnetting a /64 arising sooner than >> later. Why? >> >> It might not be perfect, It might be ugly, but it will happen. And, if >> you ask me, I would rather subnet a /64 than end up with a ipv6 >> version of NAT, a much worse alternative. > You should be able to do that today if you're so inclined, but, you lose some features. > Maybe not NAT but some kind of proxy ND and/or a migration from routing firewalls to bridging firewalls. If the broadband provider is only providing a single /64, it's not likely they're gonna be willing to add routes to your gateway. > If they're routing a /64 to your gateway, you're all set. If they're not, then, how are you getting the /64 in the first place? None of the providers I've talked to are using single /64s for any other reason that CPE limitations. The worst case I'm aware of today is Free.FR who is limiting their customers to a /64 today due to CPE problems, but, has allocated /60 per customer and plans to make /60s available as soon as the CPE can support it. Owen From jbates at brightok.net Thu Jan 27 08:17:31 2011 From: jbates at brightok.net (Jack Bates) Date: Thu, 27 Jan 2011 08:17:31 -0600 Subject: Future of the IPv6 CPE survey on RIPE Labs - Your Input Needed In-Reply-To: <006d01cbbdef$7f425c80$7dc71580$@iname.com> References: <1164463.290.1296018492548.JavaMail.franck@franck-martins-macbook-pro.local> <alpine.BSF.2.00.1101260856400.69156@mignon.ki.iif.hu> <31362582-C2A9-45CC-A3E9-13EB5743C957@delong.com> <AANLkTinkMg+n6z8nZbxBD+9uRe5BBc2c+ceExbNQgqFp@mail.gmail.com> <CB7A959F-1A6F-4F3E-B937-F7F3C09C85F5@delong.com> <4D4060FE.1000504@brightok.net> <006d01cbbdef$7f425c80$7dc71580$@iname.com> Message-ID: <4D417E7B.8000906@brightok.net> On 1/27/2011 12:57 AM, Frank Bulk wrote: > Have you looked at D-Link's DIR-825? It has most of the things you're > looking for. The DIR-655 is a more affordable option. > Haven't had the chance to look at that one. Will check it out. > In regards to (2), is it even possible to do DHCPv6-PD on with a SLAAC WAN? > It had better be, as IOS 12.2 SRE only supports SLAAC + DHCPv6-PD. Most of the Cisco documentation I've seen, says that is their beautiful layout. No more proxyarp/nd. Instead, assign a /64 to each subinterface, perform SLAAC, then hand out prefixes via DHCPv6-PD if someone needs a prefix. > In regards to (3), I have that working on SRE, but with an external DHCP > server. > Yeah, I could see the forwarding code supporting it. Cisco documentation stated proxynd with rbe/unnumbered vlans isn't what they support. How did your tests go mirroring the v4 method using dhcp forwarding with the v6 method? Jack From jbates at brightok.net Thu Jan 27 08:24:13 2011 From: jbates at brightok.net (Jack Bates) Date: Thu, 27 Jan 2011 08:24:13 -0600 Subject: PPPOE vs DHCP In-Reply-To: <006f01cbbdf0$9d5ed670$d81c8350$@iname.com> References: <31322983.91296061399385.JavaMail.root@jennyfur.pelican.org> <4D406223.4010104@brightok.net> <006f01cbbdf0$9d5ed670$d81c8350$@iname.com> Message-ID: <4D41800D.7050704@brightok.net> On 1/27/2011 1:05 AM, Frank Bulk wrote: > By IA_TA support, do you mean the ability for the 7206VXR to act as the DHCPv6 server? If I understand you correctly, I have it working well with DHCPv6 relay. > Yeah, IA_TA is the temporary addresses (compared to prefix delegation). I haven't tested it with relay, as I've hoped to avoid that (hate depending on remote servers). I'm interested, though, if RBE and unnumbered vlans can be made to work with IPv6 even with the relay as they do in IPv4. Documentation leads me to believe they won't (given cisco docs state that they figured one prefix per subinterface and no proxynd as they did in IPv4). I guess you could possibly manually activate proxynd on each subinterface? I know the routing mechanisms themselves work, verified with prefix delegations. Jack From nmaxpierson at gmail.com Wed Jan 26 23:31:59 2011 From: nmaxpierson at gmail.com (Max Pierson) Date: Wed, 26 Jan 2011 23:31:59 -0600 Subject: Another v6 question In-Reply-To: <67827BB1-BF59-45AF-842F-B9E1AD7A1F87@delong.com> References: <AANLkTikEZVYFz+bx7MVXeht_qNnpkUEC_Mx0qhE6J9SR@mail.gmail.com> <55E7EC47-C434-4DF7-B92A-8EBC24133C53@delong.com> <AANLkTi=soS+LQoR3JYJxE8N3o9JYoxrL2dvzHZ+e5Geb@mail.gmail.com> <4F209412-3C3B-4CB6-8EB7-A25ABD1B9DBA@delong.com> <AANLkTinqipvQD-gSt1BZ5FcPT2krNhwqO5dExWrM=muG@mail.gmail.com> <67827BB1-BF59-45AF-842F-B9E1AD7A1F87@delong.com> Message-ID: <AANLkTi=fJbDuv1X_cDSWMzAF7sBkF+2K7+eso97NiQBc@mail.gmail.com> >V4 30 years ago -- expected consumption: ~60 /8s of 256. >IPv6 today -- expected consumption: Maybe 15 /12s of 4096. >The scales in question are vastly different. I made no such comparison between the two. The scales are vastly different, but I think you're still missing my point. 30 years ago, no one "expected" cells phones to consume IP's. 30 years ago, no one "expected" xbox's and playstations to consume IP's. Point being is the "unexpected". >Not at all... In my opinion, IPv6 will probably last about 30-50 years. In my opinion, IPv6 addressing will outlast IPv6 usability on other fronts. I >absolutely think we'll have to do this all again. I just don't think that addresses are going to be the thing we run out of next time. Ok then, what is it exactly you think we'll run out of in 30-50 years?? Please elaborate. >No, that's not what I said at all. What I said was that addressing isn't going to be the constraint that causes us to have to revamp it next time. Once again, please elaborate. >The point was that if you're trying to figure out how big routers are >going to have to be for near-term IPv6 or even medium-term IPv6 >deployment, counting the total possible number of prefixes isn't >a useful metric because the actual utilization will be nowhere >near that large and the numbers are impossible to use as an >engineering spec. for any technology yet known. Actually, my original post may have been somewhat misleading due to "what a global table would look like in say 3 or 5 years after v4 is exhausted" and "in our routers just to take a full table". I wasn't referring to just v6 deployment moving forward. I didn't mean after v4 goes away completely. I was adding v4 table + v6 table (assuming we dual-stack, if you separate the two, ~4000 prefixes fit quite nicely on just about anything still running today, and that also makes the second question of my original post irrelevant). We won't need that amount of memory after v4 goes away (probably for quite some time). The prefix count at that point will be significantly lower. I understand that. Apologies for not being clearer. >I'd like to see IPv4 go away in ~3 years. Any faster would be too traumatic. >I think 6 years is a perfectly reasonable time frame. I think if it takes 11 years >it will be because of significant foot-dragging by some key organizations. >I'm not convinced that foot-dragging is as likely as some people are, but, >there's enough probability to provide some wiggle room in the numbers. I agree, although I do think there will be some foot-dragging, I just don't think it will take 11 years. If anyone at that point is still speaking only v4, IMO they'll only be speaking to "127.0.0.1". M On Wed, Jan 26, 2011 at 7:33 PM, Owen DeLong <owen at delong.com> wrote: > > On Jan 25, 2011, at 3:35 PM, Max Pierson wrote: > > >I think you may still be missing my point... > >There are way more /48s available than will ever get used. > >There are way more /32s available than will ever get used. > > No, I think you're missing my point. Your statements above are of your > opinion. The same opinion was said about v4 30 years ago which is why we are > where we are today (again, opinions). Reality shows otherwise. > > V4 30 years ago -- expected consumption: ~60 /8s of 256. > > IPv6 today -- expected consumption: Maybe 15 /12s of 4096. > > The scales in question are vastly different. > > In your opinion, IPv6 is it. We'll NEVER have to do this again. We'll never > have to implement NAT (or some other translation protocol) again. We'll > never have to worry about running out of space. If thats the case, then why > are so many folks arguing over what to give to end users?? It doesn't matter > by your opinion. Give em what they want!! There's no possible way we can use > that many addresses. > > Not at all... In my opinion, IPv6 will probably last about 30-50 years. In > my opinion, IPv6 addressing will outlast IPv6 usability on other fronts. I > absolutely think we'll have to do this all again. I just don't think that > addresses are going to be the thing we run out of next time. > > I think people are arguing over what to give end users because people are > generally bad at large-number arithmetic. The human brain can visualize > things up to as much as a few hundred. Some people can even visualize a > couple of thousand. Beyond that, our neurons just think of things as > randomly larger magnitudes of "a really big number". It all gets lumped into > "a whole lot" and we lose site of the numeric realities. > > Lets get back to reality. No one, and i'll say it once more, NO ONE knows > if v6 is the end all be all. (I would agree with you in regards of our > lifetime we won't even use a drop in the bucket). It only took ~10 years to > figure out they did it all wrong the first time around. Can you speak for > the next 100 years, what about 200 years?? (Not that it matters to us > anyway, we'll be long gone by then. But they way you put it is that this > beast we're dealing with will never have to be revamped again. Future proof! > To me, that line of thinking is a little short-sided). > > No, that's not what I said at all. What I said was that addressing isn't > going to be the constraint that causes us to have to revamp it next time. > > Let's put it in perspective... If we give a /48 to every end site, then, we > have > enough addresses for 281,474,976,710,656 end sites. There are currently > <7,000,000,000 people on the planet, so, let's assume we give each of them > 10 buildings (home, work, a summer cottage, and 7 spares for whatever). > That consumes 70,000,000,000 /48s. Now we're down to 281,404,976,710,656 > /48s remaining. If we build 1,000 new end sites every second, we will > need 281,404,976,710 seconds to use them all up. At 86,400 seconds > per day, that's 3,257,002 days or 8,923 years. > > I'm pretty sure that we will not be able to sustain building 1,000 new > structures per second for 8,923 years. To do it in 200 years, we > would have to build almost 50,000 new structures every second. > > I realize there have been some amazing periods of growth on the > internet, but, even at the peak of the .COM boom, even Cisco wasn't > building at anywhere near that rate. > > However, all of this is a bit out of context from what I was saying. > The point was that if you're trying to figure out how big routers are > going to have to be for near-term IPv6 or even medium-term IPv6 > deployment, counting the total possible number of prefixes isn't > a useful metric because the actual utilization will be nowhere > near that large and the numbers are impossible to use as an > engineering spec. for any technology yet known. > > > Some will care and adapt as we all hope they would, some will simply find > another provider with v4 space to spare thats not charging. This won't stop > until RIR/LIR's stop re-issuing v4 space. At that point, then the squeeze is > on and I would imagine ALL ISP's will charge at that point because they're > getting charged for having v4 space. > > There will come a time (likely this year) when there isn't another provider > with v4 space to spare that you can find. One that doesn't charge for it? > That'll probably happen even earlier. > > I think that the RIR/LIRs won't have to stop reissuing space. I think we'll > rapidly reach a point where space isn't coming back to them to be reissued. > At least not in meaningful quantities. > > >I don't think IPv4 will continue to grow for all that long. I think the > plug will get pulled by ISPs desperate to reduce the spiraling costs of > continuing to >support IPv4. When it starts becoming increasingly expensive > to get ISPs to provide IPv4 services, the rest of the internet will begin to > move rapidly >away from IPv4. > > >I anticipate this will take about 5-10 years after IPv4 runout at > ARIN/APNIC/RIPE (which will be nearly simultaneous). > > I would agree to this as well, 5-10 years of weaning off v4 at that point > is probably what we'll end up seeing, although I would say that 5-10 years > in this industry is a relatively long time. Probably much longer than any of > us want to see v4 stick around anyway. > > Well, that's <6-11 years from today. > > I'd like to see IPv4 go away in ~3 years. Any faster would be too > traumatic. > I think 6 years is a perfectly reasonable time frame. I think if it takes > 11 years > it will be because of significant foot-dragging by some key organizations. > I'm not convinced that foot-dragging is as likely as some people are, but, > there's enough probability to provide some wiggle room in the numbers. > > Owen > > From jared at puck.nether.net Thu Jan 27 08:49:58 2011 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 27 Jan 2011 09:49:58 -0500 Subject: Another v6 question In-Reply-To: <67827BB1-BF59-45AF-842F-B9E1AD7A1F87@delong.com> References: <AANLkTikEZVYFz+bx7MVXeht_qNnpkUEC_Mx0qhE6J9SR@mail.gmail.com> <55E7EC47-C434-4DF7-B92A-8EBC24133C53@delong.com> <AANLkTi=soS+LQoR3JYJxE8N3o9JYoxrL2dvzHZ+e5Geb@mail.gmail.com> <4F209412-3C3B-4CB6-8EB7-A25ABD1B9DBA@delong.com> <AANLkTinqipvQD-gSt1BZ5FcPT2krNhwqO5dExWrM=muG@mail.gmail.com> <67827BB1-BF59-45AF-842F-B9E1AD7A1F87@delong.com> Message-ID: <A5E4AFBB-92C6-464E-AAAB-07B69ECD5214@puck.nether.net> On Jan 26, 2011, at 8:33 PM, Owen DeLong wrote: > I'd like to see IPv4 go away in ~3 years. Any faster would be too traumatic. > I think 6 years is a perfectly reasonable time frame. I think if it takes 11 years > it will be because of significant foot-dragging by some key organizations. > I'm not convinced that foot-dragging is as likely as some people are, but, > there's enough probability to provide some wiggle room in the numbers. I expect that in ~3 years, we will see dual-stack and /64's handed out in conjunction with an IPv4 address as "common". The ipv6 zealots talking about anything but a /64 for end-site are talking about a "business class" service. Even with my static IPs at home, I have no need for more than a single /64 to be used in my wildest dreams. I could live with ~256 ips for the future. I consider my tech density "above-average". - Jared From owen at delong.com Thu Jan 27 08:53:29 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 27 Jan 2011 06:53:29 -0800 Subject: What's the current state of major access networks in North America ipv6 delivery status? In-Reply-To: <AANLkTinBn4OKVf1dBk=sWOdOpBh-BsWBakVR-LhQq-kj@mail.gmail.com> References: <AANLkTi=mjhRtHQYO1LD=9Ai2Tin+QCtdnNYkdYrf95z0@mail.gmail.com> <C966E3A9.7FF0C%john_brzozowski@cable.comcast.com> <AANLkTinBn4OKVf1dBk=sWOdOpBh-BsWBakVR-LhQq-kj@mail.gmail.com> Message-ID: <355AD96A-8B9D-4D3F-B329-0D197DFB064B@delong.com> On Jan 27, 2011, at 6:08 AM, Carlos Martinez-Cagnazzo wrote: > I agree with you, but, will it happen? The same fixed boundary > behaviour that makes the /64 so convenient for LAN addressing ends up > making the same /64 very convenient for ISPs as well. They associate > the /64 with the "single public IP" they issue to customers nowadays. > Most are not. I don't know where you are getting your information. > Again, I would *love* to be wrong on this one. Seriously. This is an > argument I sincerely hope to lose, but after being in the ISP business > for more than 10 years, I wouldn't expect my local ISPs at least to > issue anything shorter than a /64 to customers. > Then embrace victory. You are wrong. One of the largest residential broadband providers in the world just told you that you are wrong. (John is running IPv6 for Comcast. He speaks with a pretty authoritative voice on the topic.) I talk to a lot of these providers on a pretty regular basis. I talked to groups of them about IPv6 in 30 countries on 6 continents last year. I have yet to encounter a single provider that thinks a single /64 is the be-all-end-all for residential services in IPv6. > And... the argument for this will have a commercial background as > well. They will perceive customers who want multiple subnets as > customers who can pay more. They will make customers who want multiple > subnets go through hops to get a shorter prefix. Justifications and > such. Very few people will do it. > If they do, that will be a radical change from the current state of the environment, possibly brought about by people telling them that is what they expect. Owen > warm regards > > Carlos > > On Thu, Jan 27, 2011 at 11:58 AM, Brzozowski, John > <John_Brzozowski at cable.comcast.com> wrote: >> I am definitely *NOT* an advocate of NAT66 nor am I an advocate of further >> subneting a /64 into longer prefixes. >> >> Where additional IPv6 prefixes are required a prefix shorter than a /64 >> should be delegated. >> >> John >> ========================================= >> John Jason Brzozowski >> Comcast Cable >> e) mailto:john_brzozowski at cable.comcast.com >> o) 609-377-6594 >> m) 484-962-0060 >> w) http://www.comcast6.net >> ========================================= >> >> >> >> >> On 1/27/11 7:56 AM, "Carlos Martinez-Cagnazzo" <carlosm3011 at gmail.com> >> wrote: >> >>> Reading this thread, and building on many comments to a previous one, >>> I definitely see the need for subnetting a /64 arising sooner than >>> later. >>> >>> It might not be perfect, It might be ugly, but it will happen. And, if >>> you ask me, I would rather subnet a /64 than end up with a ipv6 >>> version of NAT, a much worse alternative. >>> >>> cheers, >>> >>> Carlos >>> >>> On Thu, Jan 27, 2011 at 9:57 AM, Brzozowski, John >>> <John_Brzozowski at cable.comcast.com> wrote: >>>> In order to deploy /56 to end users would require an IPv6 /24 be >>>> dedicated >>>> to 6rd, /48s would require a dedicated IPv6 /16. This assumes an >>>> operator >>>> wants/needs to provide IPv6 via 6rd to end users where their IPv4 >>>> address >>>> is fully unique. There is quite a bit of IPv6 address space that does >>>> not >>>> gets utilized in this model. >>>> >>>> The routers we are using as part of the trials only support /64 as such >>>> we >>>> are using an IPv6 /32. >>>> >>>> It is also important that operators plan for the ability to delegate >>>> prefixes that are shorter than a /64. There are several cases that we >>>> have seen where the router can only make use of a /64. This is better >>>> than nothing when referring to legacy devices that have been able to >>>> introduce some support for IPv6 and would have otherwise been IPv4 only >>>> devices. >>>> >>>> John >>>> ========================================= >>>> John Jason Brzozowski >>>> Comcast Cable >>>> e) mailto:john_brzozowski at cable.comcast.com >>>> o) 609-377-6594 >>>> m) 484-962-0060 >>>> w) http://www.comcast6.net >>>> ========================================= >>>> >>>> >>>> >>>> >>>> On 1/26/11 5:02 PM, "Owen DeLong" <owen at delong.com> wrote: >>>> >>>>> >>>>> On Jan 26, 2011, at 1:52 PM, Charles N Wyble wrote: >>>>> >>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>> Hash: SHA1 >>>>>> >>>>>> >>>>>> Is anyone tracking the major consumer/business class access networks >>>>>> delivery of ipv6 in North America? >>>>>> >>>>>> I'm on ATT DSL. It looks like they want to use 6rd? I've only briefly >>>>>> looked into 6rd. Is this a dead end path/giant hack? >>>>>> >>>>>> >>>>>> https://sites.google.com/site/ipv6implementors/2010/agenda/05_Chase_Goo >>>>>> gl >>>>>> econf-BroadbandtransitiontoIPv6using6rd.pdf?attredirects=0 >>>>>> >>>>> It's a fairly ugly way to deliver IPv6, but, as transition technologies >>>>> go, it's the least dead-end of the options. >>>>> >>>>> It at least provides essentially native dual stack environment. The >>>>> only difference is that your IPv6 access is via a tunnel. You'll >>>>> probably >>>>> be limited to a /56 or less over 6rd, unfortunately, but, because of the >>>>> awful way 6rd consumes addresses, handing out /48s would be >>>>> utterly impractical. Free.fr stuck their customers with /60s, which is >>>>> hopefully a very temporary situation. >>>>> >>>>>> >>>>>> I spoke with impulse.net last year, which appears to serve large >>>>>> portions of the AT&T cable plant in Southern California. They were >>>>>> willing to offer native ipv6. Not sure how (one /64, a /48) etc. >>>>>> >>>>> You should definitely push your providers to give you a /48 if >>>>> possible. If /56 or worse /60 or worst of all, /64 become widespread >>>>> trends, it may significantly impact, delay, or even prevent innovations >>>>> in the end-user networking/consumer electronics markets. >>>>> >>>>> Owen >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> >>> -- >>> -- >>> ========================= >>> Carlos M. Martinez-Cagnazzo >>> http://www.labs.lacnic.net >>> ========================= >> >> > > > > -- > -- > ========================= > Carlos M. Martinez-Cagnazzo > http://www.labs.lacnic.net > ========================= From jbates at brightok.net Thu Jan 27 09:00:55 2011 From: jbates at brightok.net (Jack Bates) Date: Thu, 27 Jan 2011 09:00:55 -0600 Subject: PPPOE vs DHCP In-Reply-To: <007001cbbdf1$26b03040$741090c0$@iname.com> References: <051001cbbcf0$c33e8b20$49bba160$@org> <007001cbbdf1$26b03040$741090c0$@iname.com> Message-ID: <4D4188A7.2010507@brightok.net> On 1/27/2011 1:09 AM, Frank Bulk wrote: > I'm not as sold on RBE in a 7206VXR, > even though I really could use the same Option 82 in the same way as we do > for FTTH. What was your problem with RBE? I've loved it (except for the 3000 interface configs that take 3-5minutes to write). Jack From owen at delong.com Thu Jan 27 09:04:31 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 27 Jan 2011 07:04:31 -0800 Subject: Another v6 question In-Reply-To: <A5E4AFBB-92C6-464E-AAAB-07B69ECD5214@puck.nether.net> References: <AANLkTikEZVYFz+bx7MVXeht_qNnpkUEC_Mx0qhE6J9SR@mail.gmail.com> <55E7EC47-C434-4DF7-B92A-8EBC24133C53@delong.com> <AANLkTi=soS+LQoR3JYJxE8N3o9JYoxrL2dvzHZ+e5Geb@mail.gmail.com> <4F209412-3C3B-4CB6-8EB7-A25ABD1B9DBA@delong.com> <AANLkTinqipvQD-gSt1BZ5FcPT2krNhwqO5dExWrM=muG@mail.gmail.com> <67827BB1-BF59-45AF-842F-B9E1AD7A1F87@delong.com> <A5E4AFBB-92C6-464E-AAAB-07B69ECD5214@puck.nether.net> Message-ID: <C52BD26B-2E5B-4B8B-8CAE-8CD60E6C6DF7@delong.com> On Jan 27, 2011, at 6:49 AM, Jared Mauch wrote: > > On Jan 26, 2011, at 8:33 PM, Owen DeLong wrote: > >> I'd like to see IPv4 go away in ~3 years. Any faster would be too traumatic. >> I think 6 years is a perfectly reasonable time frame. I think if it takes 11 years >> it will be because of significant foot-dragging by some key organizations. >> I'm not convinced that foot-dragging is as likely as some people are, but, >> there's enough probability to provide some wiggle room in the numbers. > > I expect that in ~3 years, we will see dual-stack and /64's handed out in conjunction with an IPv4 address as "common". > > The ipv6 zealots talking about anything but a /64 for end-site are talking about a "business class" service. Even with my static IPs at home, I have no need for more than a single /64 to be used in my wildest dreams. I could live with ~256 ips for the future. I consider my tech density "above-average". > > - Jared As one of the IPv6 zealots talking about anything but a /64 for end sites, I can assure you that I am talking about it for residential class service not business class. Your tech density may be above average for today, but, you lack vision for the future. Imagine a future where devices form autonomous network segments and negotiate prefixes and routing for those segments in a semi- or fully- autonomous fashion. The appliance net in the kitchen will be managed by a router. The RFID tags on the products in your fridge and your pantries will form autnonous subnets with routers embedded in the fridge and pantries. Each of your home entertainment clusters will likely form its own subnet. Even today, it is not uncommon for a residential gateway to support at least five segments: 1. External WAN segment shared with ISP 2. Internal wired network 3. Internal wireless network 4. "DMZ" segment 5. Guest wireless network Seriously, it's important that we do not limit our IPv6 thinking by our IPv4 mindset. The future is not the present and we will see much more advanced capabilities in the residential world going forward if we allow it to happen. Owen From nmaxpierson at gmail.com Thu Jan 27 09:20:01 2011 From: nmaxpierson at gmail.com (Max Pierson) Date: Thu, 27 Jan 2011 09:20:01 -0600 Subject: Another v6 question In-Reply-To: <5CE30429-3FD2-4554-8D57-670DA6F15FBB@delong.com> References: <AANLkTikEZVYFz+bx7MVXeht_qNnpkUEC_Mx0qhE6J9SR@mail.gmail.com> <55E7EC47-C434-4DF7-B92A-8EBC24133C53@delong.com> <AANLkTi=soS+LQoR3JYJxE8N3o9JYoxrL2dvzHZ+e5Geb@mail.gmail.com> <4F209412-3C3B-4CB6-8EB7-A25ABD1B9DBA@delong.com> <AANLkTinqipvQD-gSt1BZ5FcPT2krNhwqO5dExWrM=muG@mail.gmail.com> <67827BB1-BF59-45AF-842F-B9E1AD7A1F87@delong.com> <AANLkTi=fJbDuv1X_cDSWMzAF7sBkF+2K7+eso97NiQBc@mail.gmail.com> <5CE30429-3FD2-4554-8D57-670DA6F15FBB@delong.com> Message-ID: <AANLkTinwAEp1+HAk6jZ_u-8krHgC5nAJA305+Cvh3ypo@mail.gmail.com> >I'm not missing your point. I'm saying that in IPv6, we've put enough addresses >in to allow for things nobody has thought of in 30, 60, 90, even 100 years and >then some. As Roland said, "Possibly, as long as we don't blow through them via exercises in profligacy nobody has heretofore thought of, heh." >If I knew, then, I'd be well on my way to much greater wealth. Whatever it is, I am only >certain of the following things about it: > 1. We have no idea what the requirements will be at this time. I believe it was Donald Rumsfeld that said... "But there are also unknown unknowns ? the ones we don't know we don't know." What if that unknown comes in the form of "mass address consumption"? But from your view, that's not possible, so i'll just move on. > 2. We have no idea which particular scaling limit in IPv6 will actually drive us to the next protocol. I am aware that v6 still has some of the same issues that v4 has. Those have been talked about for years. I'm sure you're aware of this as well... http://www.apricot.net/apricot2007/presentation/apia-future-routing/apia-future-routing-vince-fuller.pdf The v6 train has already left the station. Scale at some point will be an issue, I'm just not entirely convinced it's v6 that will need revamping. >I think you misunderstand me. I understand you .... and all that you've stated. I just don't happen to agree with some of it. M >Let's put it in perspective... If we give a /48 to every end site, then, we have >enough addresses for 281,474,976,710,656 end sites. I get your point about sustainable growth. I even agree with it. What you're referring to then is not On Thu, Jan 27, 2011 at 12:29 AM, Owen DeLong <owen at delong.com> wrote: > > On Jan 26, 2011, at 9:31 PM, Max Pierson wrote: > > > >V4 30 years ago -- expected consumption: ~60 /8s of 256. > > >IPv6 today -- expected consumption: Maybe 15 /12s of 4096. > > >The scales in question are vastly different. > > > > I made no such comparison between the two. The scales are vastly > different, but I think you're still missing my point. 30 years ago, no one > "expected" cells phones to consume IP's. 30 years ago, no one "expected" > xbox's and playstations to consume IP's. Point being is the "unexpected". > > > I'm not missing your point. I'm saying that in IPv6, we've put enough > addresses > in to allow for things nobody has thought of in 30, 60, 90, even 100 years > and > then some. > > > >Not at all... In my opinion, IPv6 will probably last about 30-50 years. > In my opinion, IPv6 addressing will outlast IPv6 usability on other fronts. > I >absolutely think we'll have to do this all again. I just don't think that > addresses are going to be the thing we run out of next time. > > > > Ok then, what is it exactly you think we'll run out of in 30-50 years?? > Please elaborate. > > > If I knew, then, I'd be well on my way to much greater wealth. Whatever it > is, I am only > certain of the following things about it: > > 1. We have no idea what the requirements will be at this time. > 2. We have no idea which particular scaling limit in IPv6 will > actually drive > us to the next protocol. > 3. Our needs in 30-50 years will be different than our needs > today. > 4. This all assumes that we have a human race to care about > having an > internet in 50 years. Such is not necessarily a safe > assumption. > > > >No, that's not what I said at all. What I said was that addressing isn't > going to be the constraint that causes us to have to revamp it next time. > > > > Once again, please elaborate. > > > See below... I pretty much did elaborate in another message about > the number of /48s and the construction rate required to consume > them.. I don't know what will cause us to > revamp it next time. I'm just sure there are enough numbers to make > it to that point. > > > >The point was that if you're trying to figure out how big routers are > > >going to have to be for near-term IPv6 or even medium-term IPv6 > > >deployment, counting the total possible number of prefixes isn't > > >a useful metric because the actual utilization will be nowhere > > >near that large and the numbers are impossible to use as an > > >engineering spec. for any technology yet known. > > > > Actually, my original post may have been somewhat misleading due to "what > a global table would look like in say 3 or 5 years after v4 is exhausted" > and "in our routers just to take a full table". I wasn't referring to just > v6 deployment moving forward. I didn't mean after v4 goes away completely. I > was adding v4 table + v6 table (assuming we dual-stack, if you separate the > two, ~4000 prefixes fit quite nicely on just about anything still running > today, and that also makes the second question of my original post > irrelevant). We won't need that amount of memory after v4 goes away > (probably for quite some time). The prefix count at that point will be > significantly lower. I understand that. Apologies for not being clearer. > > > Well, once IPv6 is more fully deployed, you'll be seeing at least 30,000 > and more like 75,000 prefixes in IPv6. That's because there are about 30,000 > active ASNs today and given tendencies towards traffic engineering, greater > multihoming, easier address acquisition and some other factors, a 2+ growth > factor over ASNs wouldn't surprise me in the short term. > > > >I'd like to see IPv4 go away in ~3 years. Any faster would be too > traumatic. > > >I think 6 years is a perfectly reasonable time frame. I think if it > takes 11 years > > >it will be because of significant foot-dragging by some key > organizations. > > >I'm not convinced that foot-dragging is as likely as some people are, > but, > > >there's enough probability to provide some wiggle room in the numbers. > > > > I agree, although I do think there will be some foot-dragging, I just > don't think it will take 11 years. If anyone at that point is still speaking > only v4, IMO they'll only be speaking to "127.0.0.1". > > > I think there will be quite a bit of foot dragging. I think you > misunderstand me. > I'm expecting everyone to be pretty much dual-stacked in the next 3-4 > years, > even with foot dragging. I'm expecting us to start seeing IPv4 actually > deprecated > as in some providers won't route it any more (or if they do, they'll charge > a lot > to do so) in 6-11 years. That's what I mean when I say I'd like to see IPv4 > go away in that time frame. > > Owen > > From dwhite at olp.net Thu Jan 27 09:25:03 2011 From: dwhite at olp.net (Dan White) Date: Thu, 27 Jan 2011 09:25:03 -0600 Subject: Future of the IPv6 CPE survey on RIPE Labs - Your Input Needed In-Reply-To: <4D417E7B.8000906@brightok.net> References: <1164463.290.1296018492548.JavaMail.franck@franck-martins-macbook-pro.local> <alpine.BSF.2.00.1101260856400.69156@mignon.ki.iif.hu> <31362582-C2A9-45CC-A3E9-13EB5743C957@delong.com> <AANLkTinkMg+n6z8nZbxBD+9uRe5BBc2c+ceExbNQgqFp@mail.gmail.com> <CB7A959F-1A6F-4F3E-B937-F7F3C09C85F5@delong.com> <4D4060FE.1000504@brightok.net> <006d01cbbdef$7f425c80$7dc71580$@iname.com> <4D417E7B.8000906@brightok.net> Message-ID: <20110127152503.GC5424@dan.olp.net> On 27/01/11?08:17?-0600, Jack Bates wrote: >On 1/27/2011 12:57 AM, Frank Bulk wrote: >>Have you looked at D-Link's DIR-825? It has most of the things you're >>looking for. The DIR-655 is a more affordable option. >> >Haven't had the chance to look at that one. Will check it out. > >>In regards to (2), is it even possible to do DHCPv6-PD on with a SLAAC WAN? >> >It had better be, as IOS 12.2 SRE only supports SLAAC + DHCPv6-PD. >Most of the Cisco documentation I've seen, says that is their >beautiful layout. No more proxyarp/nd. Instead, assign a /64 to each >subinterface, perform SLAAC, then hand out prefixes via DHCPv6-PD if >someone needs a prefix. The DIR-825(Rev B) running firmware 2.05NA does. From the status screen: IPv6 Connection Type : Autoconfiguration (SLAAC/DHCPv6) Network Status : Connected WAN IPv6 Address : 2610:b8:0:234:218:e7ff:fef8:66dc/64 IPv6 Default Gateway : fe80::c67d:4fff:fed6:5401 LAN IPv6 Address : 2610:b8:100f:1:218:e7ff:fef8:66db/64 LAN IPv6 Link-Local Address : fe80::218:e7ff:fef8:66db/64 Primary IPv6 DNS Server : 2610:b8:0:3:215:c5ff:fef3:f9c8 Secondary IPv6 DNS Server : 2610:b8:0:3:215:c5ff:feee:9448 DHCP-PD : Enabled IPv6 network assigned by DHCP-PD : 2610:b8:100f::/48 The latest firmware has fairly good support, but is lacking configurable v6 firewall settings. I haven't done any firewall testing yet, but I'd imagine all incoming v6 connections are blocked. The Emulator hasn't been updated yet to reflect the options in the new firmware, but this should give you an idea of what the configuration looks like: http://www.support.dlink.com/emulators/dir825_revB/203NA/adv_link_local.html The DIR-615 should have similar support, but I haven't upgraded it yet. We're also evaluating a Netgear NWR3500U, which also has v6 support. However, it has the problem that whatever subnet mask is assigned via DHCP-PD is assign on the LAN (so the LAN gets a /48 instead of a /64). Anybody found a work around for that, or have a contact at Netgear? -- Dan White From jbates at brightok.net Thu Jan 27 09:33:57 2011 From: jbates at brightok.net (Jack Bates) Date: Thu, 27 Jan 2011 09:33:57 -0600 Subject: Future of the IPv6 CPE survey on RIPE Labs - Your Input Needed In-Reply-To: <20110127152503.GC5424@dan.olp.net> References: <1164463.290.1296018492548.JavaMail.franck@franck-martins-macbook-pro.local> <alpine.BSF.2.00.1101260856400.69156@mignon.ki.iif.hu> <31362582-C2A9-45CC-A3E9-13EB5743C957@delong.com> <AANLkTinkMg+n6z8nZbxBD+9uRe5BBc2c+ceExbNQgqFp@mail.gmail.com> <CB7A959F-1A6F-4F3E-B937-F7F3C09C85F5@delong.com> <4D4060FE.1000504@brightok.net> <006d01cbbdef$7f425c80$7dc71580$@iname.com> <4D417E7B.8000906@brightok.net> <20110127152503.GC5424@dan.olp.net> Message-ID: <4D419065.8030903@brightok.net> On 1/27/2011 9:25 AM, Dan White wrote: > > The DIR-825(Rev B) running firmware 2.05NA does. From the status screen: > > IPv6 Connection Type : Autoconfiguration (SLAAC/DHCPv6) Nice. New love for D-Link then. I've had DSL modem vendors sending me their IPv6 stuff. It's been horrid. Luckily, most of my network is bridged and it's only what the customer buys that is a problem. A bit pricey, but any good router usually is. Jack From frnkblk at iname.com Thu Jan 27 09:58:07 2011 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 27 Jan 2011 09:58:07 -0600 Subject: Future of the IPv6 CPE survey on RIPE Labs - Your Input Needed In-Reply-To: <4D417E7B.8000906@brightok.net> References: <1164463.290.1296018492548.JavaMail.franck@franck-martins-macbook-pro.local> <alpine.BSF.2.00.1101260856400.69156@mignon.ki.iif.hu> <31362582-C2A9-45CC-A3E9-13EB5743C957@delong.com> <AANLkTinkMg+n6z8nZbxBD+9uRe5BBc2c+ceExbNQgqFp@mail.gmail.com> <CB7A959F-1A6F-4F3E-B937-F7F3C09C85F5@delong.com> <4D4060FE.1000504@brightok.net> <006d01cbbdef$7f425c80$7dc71580$@iname.com> <4D417E7B.8000906@brightok.net> Message-ID: <005901cbbe3a$fd195eb0$f74c1c10$@iname.com> I don't know what I was thinking last night, but I believe I had SLAAC + DHCPv6-PD working myself, but wasn't satisfied. =) I'm not comfortable using SLAAC for WAN addresses in a service provider environment. I do DHCPv4 relay today. DHCPv6 relay worked perfectly on an PVI, but with a SVI with it was very much hit and miss, such that now CSCtl77398 has been created. Enabling "ipv6 multicast-routing" has dramatically improved the success of DHCPv6 relay. So while the bug is not fixed, it's good enough that I can continue with preparing for a trial. Frank -----Original Message----- From: Jack Bates [mailto:jbates at brightok.net] Sent: Thursday, January 27, 2011 8:18 AM To: frnkblk at iname.com Cc: Owen DeLong; nanog at nanog.org Subject: Re: Future of the IPv6 CPE survey on RIPE Labs - Your Input Needed On 1/27/2011 12:57 AM, Frank Bulk wrote: > Have you looked at D-Link's DIR-825? It has most of the things you're > looking for. The DIR-655 is a more affordable option. > Haven't had the chance to look at that one. Will check it out. > In regards to (2), is it even possible to do DHCPv6-PD on with a SLAAC WAN? > It had better be, as IOS 12.2 SRE only supports SLAAC + DHCPv6-PD. Most of the Cisco documentation I've seen, says that is their beautiful layout. No more proxyarp/nd. Instead, assign a /64 to each subinterface, perform SLAAC, then hand out prefixes via DHCPv6-PD if someone needs a prefix. > In regards to (3), I have that working on SRE, but with an external DHCP > server. > Yeah, I could see the forwarding code supporting it. Cisco documentation stated proxynd with rbe/unnumbered vlans isn't what they support. How did your tests go mirroring the v4 method using dhcp forwarding with the v6 method? Jack From jared at puck.nether.net Thu Jan 27 10:03:41 2011 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 27 Jan 2011 11:03:41 -0500 Subject: /64 is "enough" until 2021 for 90% of users (was Re: Another v6 question) In-Reply-To: <C52BD26B-2E5B-4B8B-8CAE-8CD60E6C6DF7@delong.com> References: <AANLkTikEZVYFz+bx7MVXeht_qNnpkUEC_Mx0qhE6J9SR@mail.gmail.com> <55E7EC47-C434-4DF7-B92A-8EBC24133C53@delong.com> <AANLkTi=soS+LQoR3JYJxE8N3o9JYoxrL2dvzHZ+e5Geb@mail.gmail.com> <4F209412-3C3B-4CB6-8EB7-A25ABD1B9DBA@delong.com> <AANLkTinqipvQD-gSt1BZ5FcPT2krNhwqO5dExWrM=muG@mail.gmail.com> <67827BB1-BF59-45AF-842F-B9E1AD7A1F87@delong.com> <A5E4AFBB-92C6-464E-AAAB-07B69ECD5214@puck.nether.net> <C52BD26B-2E5B-4B8B-8CAE-8CD60E6C6DF7@delong.com> Message-ID: <E628DA61-DF9B-46D6-9E0E-C813B06A48B6@puck.nether.net> On Jan 27, 2011, at 10:04 AM, Owen DeLong wrote: > > On Jan 27, 2011, at 6:49 AM, Jared Mauch wrote: > >> >> On Jan 26, 2011, at 8:33 PM, Owen DeLong wrote: >> >>> I'd like to see IPv4 go away in ~3 years. Any faster would be too traumatic. >>> I think 6 years is a perfectly reasonable time frame. I think if it takes 11 years >>> it will be because of significant foot-dragging by some key organizations. >>> I'm not convinced that foot-dragging is as likely as some people are, but, >>> there's enough probability to provide some wiggle room in the numbers. >> >> I expect that in ~3 years, we will see dual-stack and /64's handed out in conjunction with an IPv4 address as "common". >> >> The ipv6 zealots talking about anything but a /64 for end-site are talking about a "business class" service. Even with my static IPs at home, I have no need for more than a single /64 to be used in my wildest dreams. I could live with ~256 ips for the future. I consider my tech density "above-average". >> >> - Jared > > As one of the IPv6 zealots talking about anything but a /64 for end sites, I > can assure you that I am talking about it for residential class service > not business class. > > Your tech density may be above average for today, but, you lack vision > for the future. > > Imagine a future where devices form autonomous network segments > and negotiate prefixes and routing for those segments in a semi- > or fully- autonomous fashion. > > The appliance net in the kitchen will be managed by a router. > The RFID tags on the products in your fridge and your pantries > will form autnonous subnets with routers embedded in the > fridge and pantries. Each of your home entertainment clusters > will likely form its own subnet. > > Even today, it is not uncommon for a residential gateway to support > at least five segments: > > 1. External WAN segment shared with ISP > 2. Internal wired network > 3. Internal wireless network > 4. "DMZ" segment > 5. Guest wireless network > > Seriously, it's important that we do not limit our IPv6 thinking by > our IPv4 mindset. The future is not the present and we will see > much more advanced capabilities in the residential world > going forward if we allow it to happen. I'm not. There's certainly interesting use cases of this "IP" header type, independent of being v4 or v6. You're talking about the various segments, and I'm thinking about the folks from Toyota doing their ipv6 local networks integrated into vehicles. But many people are also stuck in thinking that these people need to be segmented in the first place. This "security by obscurity" mentality that being behind a VPN, being air-gapped, wired, wireless, that you are deserving of a variable class of service is part of the discussion. I could call out vendors that have highly sensitive data that is available "if only" you brought a cat5 cable to the office vs using their "guest" wireless. that segmentation ignores the authentication of end-stations, or person behind the keyboard. If you actually did that, you don't need to have a different 'guest' wireless vs the 'internal' wireless network. Now, I don't think that by reading this that an enterprise is going to clean up their act, (wired vs wireless), or stop any other silly practices using these "packet eating" firewall/nat/vpn devices. But tying those practices in to the equation can serve to validate the premise that these people actually need to be segmented vs solving the real security (trust) problem that exists on the end devices. You don't necessarily need to see my AppleTV on my home network, but as a guest at my home, (after authenticating to my local wireless network) you gain access to play music and control various elements of my network. I don't need to make these "public", but if they are on a public-IP, the devices should be able to be properly secured (and can be). I don't think I need a public and private FridgeNet to determine the quantity and quality of the beverages and offer different SLAs based on if they are on the 'guestFridgeNet' vs 'privateFridgeNet'. This is taking it a step or three too far. Most people don't know or care what their IP subnet is. Even if every time I connected a device to my network (or re-connected after power saving, etc) I incremented the usable part of my /64, it would take me some time to consume that space fully. I do think we're closer together than apart, but for 90% of home users, (and you can quote me on this in 10 years) a /64 will be sufficient for their uses. Anyone needing more than a /64 for their home is either going to some impractical extreme or better defined as a "prosumer" that will want a higher SLA in the first place, and therefore should pay a modest amount more. - Jared From frnkblk at iname.com Thu Jan 27 10:14:17 2011 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 27 Jan 2011 10:14:17 -0600 Subject: Future of the IPv6 CPE survey on RIPE Labs - Your Input Needed In-Reply-To: <4D419065.8030903@brightok.net> References: <1164463.290.1296018492548.JavaMail.franck@franck-martins-macbook-pro.local> <alpine.BSF.2.00.1101260856400.69156@mignon.ki.iif.hu> <31362582-C2A9-45CC-A3E9-13EB5743C957@delong.com> <AANLkTinkMg+n6z8nZbxBD+9uRe5BBc2c+ceExbNQgqFp@mail.gmail.com> <CB7A959F-1A6F-4F3E-B937-F7F3C09C85F5@delong.com> <4D4060FE.1000504@brightok.net> <006d01cbbdef$7f425c80$7dc71580$@iname.com> <4D417E7B.8000906@brightok.net> <20110127152503.GC5424@dan.olp.net> <4D419065.8030903@brightok.net> Message-ID: <005b01cbbe3d$3f387c20$bda97460$@iname.com> Agreed, the DSL stuff is horrid. When using PPPoE it asks me to enter the default IPv6 gateway. You got to be kidding me. Frank -----Original Message----- From: Jack Bates [mailto:jbates at brightok.net] Sent: Thursday, January 27, 2011 9:34 AM To: Dan White Cc: frnkblk at iname.com; nanog at nanog.org Subject: Re: Future of the IPv6 CPE survey on RIPE Labs - Your Input Needed On 1/27/2011 9:25 AM, Dan White wrote: > > The DIR-825(Rev B) running firmware 2.05NA does. From the status screen: > > IPv6 Connection Type : Autoconfiguration (SLAAC/DHCPv6) Nice. New love for D-Link then. I've had DSL modem vendors sending me their IPv6 stuff. It's been horrid. Luckily, most of my network is bridged and it's only what the customer buys that is a problem. A bit pricey, but any good router usually is. Jack From pscanlon at arbor.net Thu Jan 27 10:27:04 2011 From: pscanlon at arbor.net (Paul Scanlon) Date: Thu, 27 Jan 2011 09:27:04 -0700 Subject: NANOG 51 (Miami): ISP Security BOF In-Reply-To: <96287424-DF08-4C20-B7C7-96B909915900@arbor.net> References: <96287424-DF08-4C20-B7C7-96B909915900@arbor.net> Message-ID: <24E6A68E-40DE-49A1-80AD-D2D49B1275ED@arbor.net> All, Thanks for the feedback on the topics for the NANOG ISP Security Track BoF Scheduled on Monday 4:30 - 6 pm in the Grand conference room. Brief Snapshot of the current agenda: - RPKI Deployment Overview and Example - Operation Payback, Anonymous Tool Set Taxonomy - Briefing on SPAM Botnets Activity Trends and Observations We'll open the session with a brief agenda bashing to allow any hot items to be worked in, but it would also be very beneficial if anyone has anything they would like to have worked into the agenda prior to the meeting to send their topics / thoughts to the chairs cc'd. Looking forward to seeing you in Miami. Best, Paul On Jan 6, 2011, at 6:01 PM, Scanlon, Paul wrote: > Hi All, > > Happy New Year. > > NANOG 51 in Miami is rapidly approaching, January 30 - February 2, and we are looking for topics for the ISP Security BOF. Eric Osterweil and I are going to be moderating this year with the assistance of Danny McPherson. We would very much like to hear your feedback regarding topics of interest for the session. > > If you have any security related topics that you would like to hear about, not hear about, or be willing to speak about, please let one of us know as soon as possible, feedback to the list obviously welcome. > > Slides are welcome but not required. > > Much thanks, > > Eric & Paul > > > ------------------------------------ > > Paul Scanlon > Arbor Networks > +1.303.477.0919 office > +1.303.810.7260 mobile > > ------------------------------------ > ------------------------------------ Paul Scanlon Arbor Networks +1.303.477.0919 office +1.303.810.7260 mobile www.arbornetworks.com How networks grow? ------------------------------------ From bjohnson at drtel.com Thu Jan 27 10:29:37 2011 From: bjohnson at drtel.com (Brian Johnson) Date: Thu, 27 Jan 2011 16:29:37 +0000 Subject: Found: Who is responsible for no more IP addresses In-Reply-To: <22FB1A8D-90B3-49F1-BFD8-E581AAE1C808@delong.com> References: <alpine.LRH.2.00.1101271319090.15061@efes.iucc.ac.il> <4D4163ED.1060201@foobar.org> <22FB1A8D-90B3-49F1-BFD8-E581AAE1C808@delong.com> Message-ID: <F05D77A9631CAE4097F7B69095F1B06F02E201@EX02.drtel.lan> I'm a bit torn on this issue. I haven't even heard any other "main-stream" sources say anything on this topic. But Incorrect info is bad too. I hope the viewers who watched this are getting the gist that "Something wicked this way comes". :) LOL - Brian J. >-----Original Message----- >From: Owen DeLong [mailto:owen at delong.com] >Sent: Thursday, January 27, 2011 7:49 AM >To: Nick Hilliard >Cc: nanog at nanog.org >Subject: Re: Found: Who is responsible for no more IP addresses > > >On Jan 27, 2011, at 4:24 AM, Nick Hilliard wrote: > >> On 27/01/2011 11:21, Hank Nussbacher wrote: >>> "I thought it was an experiment and I thought that 4.3 billion IPv4 >>> addresses would be enough to do an experiment," Cerf was quoted as >saying, >>> adding it is his "fault" that "we were running out of the addresses."" >> >> Fortunately, web developers have fixed the problem according to Fox news: >> >> http://www.foxnews.com/scitech/2011/01/26/internet-run-ip-addresses- >happens-anyones-guess/ >> >> "Web developers have tried to compensate for this problem by creating >IPv6 -- a system that recognizes six-digit IP addresses rather than four-digit >ones." >> >Consider the source... Fox -- All the news that's fit to misquote. (or something >like that). > >Those guys never get anything technical or political right.* > >> It will be difficult initially, though: >> >> "But IPv6 isn't backwards-compatible with IPv4, meaning that it's not able to >read most content that operates on an IPv4 system. At best, the user >experience will be clunky and slow. At worst, instead of a webpage, all users >will be able to view is a blank page." >> >> I'm glad Fox has cleared all this up for us. >> >ROFLMAO > >Owen > >*In order for Fox to sue me for libel, they first have to prove my statement is >false. > From caldcv at gmail.com Thu Jan 27 10:58:01 2011 From: caldcv at gmail.com (Christopher) Date: Thu, 27 Jan 2011 11:58:01 -0500 Subject: Contact at Dynadot Message-ID: <4D41A419.1010109@gmail.com> I have been knocking down this Romanian IRC botnet since Thanksgiving and Dynadot has been dragging their feet. I even called and talked to someone in tech support, which was an Asian guy with a small grasp of English but that's another discussion, and still they say they are "investigating it" Does anyone have a personal contact at Dynadot to get this escalated? It's painfully obvious and needs no investigation because they can look at the past DNS records for this subdomains to see the constant changes and updates with totally random IP addresses - customer DSL IP addresses, Russia, China, EDU institutions worldwide, etc. Please contact me off list. Thank you From morrowc.lists at gmail.com Thu Jan 27 11:04:39 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 27 Jan 2011 12:04:39 -0500 Subject: Found: Who is responsible for no more IP addresses In-Reply-To: <F05D77A9631CAE4097F7B69095F1B06F02E201@EX02.drtel.lan> References: <alpine.LRH.2.00.1101271319090.15061@efes.iucc.ac.il> <4D4163ED.1060201@foobar.org> <22FB1A8D-90B3-49F1-BFD8-E581AAE1C808@delong.com> <F05D77A9631CAE4097F7B69095F1B06F02E201@EX02.drtel.lan> Message-ID: <AANLkTinc56Le67N=2Z0nfBC627CE06mgqmma36ntJEAx@mail.gmail.com> On Thu, Jan 27, 2011 at 11:29 AM, Brian Johnson <bjohnson at drtel.com> wrote: > I'm a bit torn on this issue. I haven't even heard any other "main-stream" sources say anything on this topic. But Incorrect info is bad too. > > I hope the viewers who watched this are getting the gist that "Something wicked this way comes". :) I believe that's the only message foxnews puts out, if their viewing audience is missing that... then we all have very much larger issues :( From joelja at bogus.com Thu Jan 27 11:46:58 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Thu, 27 Jan 2011 09:46:58 -0800 Subject: Future of the IPv6 CPE survey on RIPE Labs - Your Input Needed In-Reply-To: <4D419065.8030903@brightok.net> References: <1164463.290.1296018492548.JavaMail.franck@franck-martins-macbook-pro.local> <alpine.BSF.2.00.1101260856400.69156@mignon.ki.iif.hu> <31362582-C2A9-45CC-A3E9-13EB5743C957@delong.com> <AANLkTinkMg+n6z8nZbxBD+9uRe5BBc2c+ceExbNQgqFp@mail.gmail.com> <CB7A959F-1A6F-4F3E-B937-F7F3C09C85F5@delong.com> <4D4060FE.1000504@brightok.net> <006d01cbbdef$7f425c80$7dc71580$@iname.com> <4D417E7B.8000906@brightok.net> <20110127152503.GC5424@dan.olp.net> <4D419065.8030903@brightok.net> Message-ID: <4D41AF92.5060307@bogus.com> On 1/27/11 7:33 AM, Jack Bates wrote: > > > On 1/27/2011 9:25 AM, Dan White wrote: >> >> The DIR-825(Rev B) running firmware 2.05NA does. From the status screen: >> >> IPv6 Connection Type : Autoconfiguration (SLAAC/DHCPv6) > > Nice. New love for D-Link then. I've had DSL modem vendors sending me > their IPv6 stuff. It's been horrid. Luckily, most of my network is > bridged and it's only what the customer buys that is a problem. > > A bit pricey, but any good router usually is. For $129 it's epic. And the scary part is it was released in 2009. > Jack > From jmamodio at gmail.com Thu Jan 27 11:59:06 2011 From: jmamodio at gmail.com (Jorge Amodio) Date: Thu, 27 Jan 2011 11:59:06 -0600 Subject: Found: Who is responsible for no more IP addresses In-Reply-To: <4D4163ED.1060201@foobar.org> References: <alpine.LRH.2.00.1101271319090.15061@efes.iucc.ac.il> <4D4163ED.1060201@foobar.org> Message-ID: <AANLkTi=gOqysF28+mMK0wYmd_Y-sDebvOKit=GoDxDs9@mail.gmail.com> > http://www.foxnews.com/scitech/2011/01/26/internet-run-ip-addresses-happens-anyones-guess/ "It's the end of the web as we know it. " We are doomed !! Glad to know that, since a large percentage of it suxs. Can we go back to the ftp.funet.fi (still up !! ) and gopher ? Cheers Jorge From jg at freedesktop.org Thu Jan 27 12:01:41 2011 From: jg at freedesktop.org (Jim Gettys) Date: Thu, 27 Jan 2011 13:01:41 -0500 Subject: Future of the IPv6 CPE survey on RIPE Labs - Your Input Needed In-Reply-To: <4D41AF92.5060307@bogus.com> References: <1164463.290.1296018492548.JavaMail.franck@franck-martins-macbook-pro.local> <alpine.BSF.2.00.1101260856400.69156@mignon.ki.iif.hu> <31362582-C2A9-45CC-A3E9-13EB5743C957@delong.com> <AANLkTinkMg+n6z8nZbxBD+9uRe5BBc2c+ceExbNQgqFp@mail.gmail.com> <CB7A959F-1A6F-4F3E-B937-F7F3C09C85F5@delong.com> <4D4060FE.1000504@brightok.net> <006d01cbbdef$7f425c80$7dc71580$@iname.com> <4D417E7B.8000906@brightok.net> <20110127152503.GC5424@dan.olp.net> <4D419065.8030903@brightok.net> <4D41AF92.5060307@bogus.com> Message-ID: <4D41B305.8020800@freedesktop.org> On 01/27/2011 12:46 PM, Joel Jaeggli wrote: > On 1/27/11 7:33 AM, Jack Bates wrote: >> >> >> On 1/27/2011 9:25 AM, Dan White wrote: >>> >>> The DIR-825(Rev B) running firmware 2.05NA does. From the status screen: >>> >>> IPv6 Connection Type : Autoconfiguration (SLAAC/DHCPv6) >> >> Nice. New love for D-Link then. I've had DSL modem vendors sending me >> their IPv6 stuff. It's been horrid. Luckily, most of my network is >> bridged and it's only what the customer buys that is a problem. >> >> A bit pricey, but any good router usually is. > > For $129 it's epic. And the scary part is it was released in 2009. > For god's sake, stay away from the DIR-825(Rev A), which has been effectively abandoned by DLINK support and has no IPv6 support at all. This has left a bad taste in my mouth. It has an entirely different processor in it. The RevB replaced the RevA over a year ago, but it's worth checking. Unfortunately, my Rev B was blown up by lightning. Dunno if it is being supported by DLINK any better. - Jim From bjohnson at drtel.com Thu Jan 27 12:34:37 2011 From: bjohnson at drtel.com (Brian Johnson) Date: Thu, 27 Jan 2011 18:34:37 +0000 Subject: Found: Who is responsible for no more IP addresses In-Reply-To: <AANLkTinc56Le67N=2Z0nfBC627CE06mgqmma36ntJEAx@mail.gmail.com> References: <alpine.LRH.2.00.1101271319090.15061@efes.iucc.ac.il> <4D4163ED.1060201@foobar.org> <22FB1A8D-90B3-49F1-BFD8-E581AAE1C808@delong.com> <F05D77A9631CAE4097F7B69095F1B06F02E201@EX02.drtel.lan> <AANLkTinc56Le67N=2Z0nfBC627CE06mgqmma36ntJEAx@mail.gmail.com> Message-ID: <F05D77A9631CAE4097F7B69095F1B06F02E2C2@EX02.drtel.lan> I really wish people would keep their personal/political bias outside the list unless it is specific and relevant. What other "main-stream" news organization has made any reports on this issue? To be clear, FOX screwed this up big time, but that doesn't mean we all need to get out our personal/political pitchforks and run them out of town. Take your Ritalin. :) - Brian J. >-----Original Message----- >From: christopher.morrow at gmail.com >[mailto:christopher.morrow at gmail.com] On Behalf Of Christopher Morrow >Sent: Thursday, January 27, 2011 11:05 AM >To: Brian Johnson >Cc: nanog at nanog.org >Subject: Re: Found: Who is responsible for no more IP addresses > >On Thu, Jan 27, 2011 at 11:29 AM, Brian Johnson <bjohnson at drtel.com> >wrote: >> I'm a bit torn on this issue. I haven't even heard any other "main-stream" >sources say anything on this topic. But Incorrect info is bad too. >> >> I hope the viewers who watched this are getting the gist that "Something >wicked this way comes". :) > >I believe that's the only message foxnews puts out, if their viewing >audience is missing that... then we all have very much larger issues >:( From surfer at mauigateway.com Thu Jan 27 12:40:03 2011 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 27 Jan 2011 10:40:03 -0800 Subject: Future of the IPv6 CPE survey on RIPE Labs - Your Input Needed Message-ID: <20110127104003.C5C2818C@resin18.mta.everyone.net> --- frnkblk at iname.com wrote: From: "Frank Bulk" <frnkblk at iname.com> Have you looked at D-Link's DIR-825? It has most of the things you're ------------------------------------------- Ewww, yuck! "...this router utilizes dual active firewalls (SPI and NAT) to prevent potential attacks from across the Internet." ftp://ftp.dlink.com/Gateway/dir825/Manual/dir825_manual_110.zip scott From jared at puck.nether.net Thu Jan 27 12:43:54 2011 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 27 Jan 2011 13:43:54 -0500 Subject: Found: Who is responsible for no more IP addresses In-Reply-To: <AANLkTi=gOqysF28+mMK0wYmd_Y-sDebvOKit=GoDxDs9@mail.gmail.com> References: <alpine.LRH.2.00.1101271319090.15061@efes.iucc.ac.il> <4D4163ED.1060201@foobar.org> <AANLkTi=gOqysF28+mMK0wYmd_Y-sDebvOKit=GoDxDs9@mail.gmail.com> Message-ID: <7AE2246A-8067-4AE9-93EF-A0CE9487A8E5@puck.nether.net> On Jan 27, 2011, at 12:59 PM, Jorge Amodio wrote: >> http://www.foxnews.com/scitech/2011/01/26/internet-run-ip-addresses-happens-anyones-guess/ > > "It's the end of the web as we know it. " We are doomed !! > > Glad to know that, since a large percentage of it suxs. > > Can we go back to the ftp.funet.fi (still up !! ) and gopher ? Which host? archie.sura.net - Jared From nazgul at somewhere.com Thu Jan 27 12:46:41 2011 From: nazgul at somewhere.com (Kee Hinckley) Date: Thu, 27 Jan 2011 13:46:41 -0500 Subject: Found: Who is responsible for no more IP addresses In-Reply-To: <F05D77A9631CAE4097F7B69095F1B06F02E2C2@EX02.drtel.lan> References: <alpine.LRH.2.00.1101271319090.15061@efes.iucc.ac.il> <4D4163ED.1060201@foobar.org> <22FB1A8D-90B3-49F1-BFD8-E581AAE1C808@delong.com> <F05D77A9631CAE4097F7B69095F1B06F02E201@EX02.drtel.lan> <AANLkTinc56Le67N=2Z0nfBC627CE06mgqmma36ntJEAx@mail.gmail.com> <F05D77A9631CAE4097F7B69095F1B06F02E2C2@EX02.drtel.lan> Message-ID: <8A4EDD42-D3FE-43CF-9D1A-01CE7BE0A583@somewhere.com> On Jan 27, 2011, at 1:34 PM, Brian Johnson wrote: > I really wish people would keep their personal/political bias outside the list unless it is specific and relevant. What other "main-stream" news organization has made any reports on this issue? As much as I agree with the comments people have made, you're right, they aren't appropriate for this forum. However, it *is* possible to cover properly: IP Address Shortage Has ISPs Scrambling For Space http://www.npr.org/templates/story/story.php?storyId=128907099 > Bear with us while we go a little deeper into the digital landscape. We're going to talk about IPv4 exhaustion next. Don't be scared - we'll break it down. Here it goes. > > Everything that can be connected directly to the Internet - computers, cell phones, game systems, TVs, even cars - has an Internet Protocol, or IP address. IP version 4, or IPv4, has just over 4 billion unique addresses. But with so many Internet-ready devices on the market, the current supply of IP addresses will run out sometime next year. > > John Curran is going to explain what that means for Internet users. He's the president and CEO of the American Registry for Internet Numbers, and he's in the studio at member station KPBS in San Diego. Welcome to the program. From peter at peter-dambier.de Thu Jan 27 13:03:20 2011 From: peter at peter-dambier.de (Peter Dambier) Date: Thu, 27 Jan 2011 20:03:20 +0100 Subject: PPPOE vs DHCP - RIPE Database In-Reply-To: <051001cbbcf0$c33e8b20$49bba160$@org> References: <051001cbbcf0$c33e8b20$49bba160$@org> Message-ID: <4D41C178.5020302@peter-dambier.de> Hi, I have not seen this in the discussion yet. http://labs.ripe.net/Members/mirjam/ipv6-cpe-survey-updated-january-2011 CPE support does not seem to be very broad yet. As far as I can see there is almost PPPoE only for IPv6 in Europe. In Germany cable is a mess by regulation. So no cable/dhcp. There used to be a DTAG monopoly with aDSL only and PPPoE only. Most ISPs still rely on the DTAG infrastructure. That is why very PPPoE biased. There is a high concentration of AVM in the CPE with Infineon chipsets in both DSLAM and DSL-Modem / Router --- OT --- Living in the outback with DSL-1000 max I made some tests with CIS-modem, Broadcom Cipset (Hitachi) and Infineon/AVM. The CIS-modem is no longer sold but far superior to the others. I had trouble to get some of the Broadcoms working. Replacing the power supply unit (wallwart, not regulated) with a regulated and filtered 13.5 volts power supply unit for my hamradio both the bradcoms and the AVW worked almost a good as the CIS-modem. Some of you might remember tuneable hum noise in ancient am-radios. That noise could be cured by shunting the rectifiers with 4.7 nano farad capacitors. The spectrum of the modem shows a lattice that goes away with a reulated and filtered power source. Of coarse you cannot spend a week experimenting at any client site. So excuse the noise. --- /OT --- -- Peter and Karin Dambier Cesidian Root - Radice Cesidiana Rimbacher Strasse 16 D-69509 Moerlenbach-Bonsweiher +49(6209)795-816 (Telekom) +49(6252)750-308 (VoIP: sipgate.de) mail: peter at peter-dambier.de http://www.peter-dambier.de/ http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ ULA= fd80:4ce1:c66a::/48 From jra at baylink.com Thu Jan 27 13:06:21 2011 From: jra at baylink.com (Jay Ashworth) Date: Thu, 27 Jan 2011 14:06:21 -0500 (EST) Subject: Found: Who is responsible for no more IP addresses In-Reply-To: <F05D77A9631CAE4097F7B69095F1B06F02E2C2@EX02.drtel.lan> Message-ID: <2966867.2746.1296155181722.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Brian Johnson" <bjohnson at drtel.com> > I really wish people would keep their personal/political bias outside > the list unless it is specific and relevant. What other "main-stream" > news organization has made any reports on this issue? > > To be clear, FOX screwed this up big time, but that doesn't mean we > all need to get out our personal/political pitchforks and run them out > of town. Take your Ritalin. :-) Fox didn't screw up, for a change, and Vint's quote appears in many other news sources. Apparently, I'm the only one on Nanog who knows about this new thing called The Google. :-) Thinking that Fox "News" is not a reputable news source is not, indeed, an opinion attributable *solely* to non-Republicans, and indeed, it's easy to prove in a documentary, non-partisan fashion. Cheers, -- jra From jra at baylink.com Thu Jan 27 13:15:46 2011 From: jra at baylink.com (Jay Ashworth) Date: Thu, 27 Jan 2011 14:15:46 -0500 (EST) Subject: Found: Who is responsible for no more IP addresses In-Reply-To: <15529016.2734.1296152726503.JavaMail.root@benjamin.baylink.com> Message-ID: <218938.2790.1296155746757.JavaMail.root@benjamin.baylink.com> [ Sorry; forgot to address this to the list, earlier. ] ----- Original Message ----- > From: "Brian Johnson" <bjohnson at drtel.com> > I'm a bit torn on this issue. I haven't even heard any other > "main-stream" sources say anything on this topic. But Incorrect info > is bad too. > > I hope the viewers who watched this are getting the gist that > "Something wicked this way comes". :) Vint was quoted as saying this some months ago, I believe in a story linked from Slashdot on a reputable news outlet. Sure enough: https://encrypted.google.com/search?q=vint+cerf+IP+address Cheers, -- jra From Valdis.Kletnieks at vt.edu Thu Jan 27 13:14:44 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 27 Jan 2011 14:14:44 -0500 Subject: Another v6 question In-Reply-To: Your message of "Thu, 27 Jan 2011 07:04:31 PST." <C52BD26B-2E5B-4B8B-8CAE-8CD60E6C6DF7@delong.com> References: <AANLkTikEZVYFz+bx7MVXeht_qNnpkUEC_Mx0qhE6J9SR@mail.gmail.com> <55E7EC47-C434-4DF7-B92A-8EBC24133C53@delong.com> <AANLkTi=soS+LQoR3JYJxE8N3o9JYoxrL2dvzHZ+e5Geb@mail.gmail.com> <4F209412-3C3B-4CB6-8EB7-A25ABD1B9DBA@delong.com> <AANLkTinqipvQD-gSt1BZ5FcPT2krNhwqO5dExWrM=muG@mail.gmail.com> <67827BB1-BF59-45AF-842F-B9E1AD7A1F87@delong.com> <A5E4AFBB-92C6-464E-AAAB-07B69ECD5214@puck.nether.net> <C52BD26B-2E5B-4B8B-8CAE-8CD60E6C6DF7@delong.com> Message-ID: <17648.1296155684@localhost> On Thu, 27 Jan 2011 07:04:31 PST, Owen DeLong said: > > On Jan 27, 2011, at 6:49 AM, Jared Mauch wrote: > > The ipv6 zealots talking about anything but a /64 for end-site are > > talking about a "business class" service. Even with my static IPs at > > home, I have no need for more than a single /64 to be used in my wildest > > dreams. I could live with ~256 ips for the future. I consider my tech > > density "above-average". > Even today, it is not uncommon for a residential gateway to support > at least five segments: > > 1. External WAN segment shared with ISP > 2. Internal wired network > 3. Internal wireless network > 4. "DMZ" segment > 5. Guest wireless network Even at the low end - a Belkin Play wireless router with that basic config can be had for $45 now: http://www.google.com/products/catalog?oe=utf-8&q=belkin+play+router+wireless&um=1&ie=UTF-8&cid=8536738187275945735&ei=B5JBTaPwJYjVgAfPh7ngAQ&sa=X&oi=product_catalog_result&ct=result&resnum=3&ved=0CDcQ8wIwAg# Nice unit, works reasonably well for me. Too bad I'll probably have to replace both that and the Linksys cablemodem in front of it when Comcast gets me IPv6 (I'm not holding my breath waiting for firmware upgrades for either to enable IPv6, at that price level the flash memory must be fairly tiny and IPv6 will cause the image to grow a bunch). On Thu, 27 Jan 2011 11:03:41 EST, Jared Mauch said: > I could call out vendors that have highly sensitive data that is > available "if only" you brought a cat5 cable to the office vs using > their "guest" wireless. that segmentation ignores the authentication of > end-stations, or person behind the keyboard. If you actually did that, > you don't need to have a different 'guest' wireless vs the 'internal' > wireless network. Enterprises don't use $45 Belkin wireless routers. The segmentation security model works just fine for a home network - I give my kids the SSID and key for the one wireless net, and if they have friends along when they visit, they get the SSID and key for the *other* network off the post-it note stuck to the side of the Belkin. (That security model works too - if you can read the post-it, my wireless is the least of my security problems). Feel free to suggest a significantly better security model that involves less management work for me. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110127/b62c64bb/attachment.bin> From swmike at swm.pp.se Thu Jan 27 13:32:12 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 27 Jan 2011 20:32:12 +0100 (CET) Subject: Another v6 question In-Reply-To: <A5E4AFBB-92C6-464E-AAAB-07B69ECD5214@puck.nether.net> References: <AANLkTikEZVYFz+bx7MVXeht_qNnpkUEC_Mx0qhE6J9SR@mail.gmail.com> <55E7EC47-C434-4DF7-B92A-8EBC24133C53@delong.com> <AANLkTi=soS+LQoR3JYJxE8N3o9JYoxrL2dvzHZ+e5Geb@mail.gmail.com> <4F209412-3C3B-4CB6-8EB7-A25ABD1B9DBA@delong.com> <AANLkTinqipvQD-gSt1BZ5FcPT2krNhwqO5dExWrM=muG@mail.gmail.com> <67827BB1-BF59-45AF-842F-B9E1AD7A1F87@delong.com> <A5E4AFBB-92C6-464E-AAAB-07B69ECD5214@puck.nether.net> Message-ID: <alpine.DEB.1.10.1101272030321.13151@uplift.swm.pp.se> On Thu, 27 Jan 2011, Jared Mauch wrote: > The ipv6 zealots talking about anything but a /64 for end-site are > talking about a "business class" service. Even with my static IPs at > home, I have no need for more than a single /64 to be used in my wildest > dreams. I could live with ~256 ips for the future. I consider my tech > density "above-average". I don't agree at all. I have 3 /64s in use in my home already. I could fairly easily go down to 2, but I definitely need at least 2. I don't want to handle people like me differently, thus /56 for all residential customers makes a lot of sense. I see no downside. -- Mikael Abrahamsson email: swmike at swm.pp.se From drais at icantclick.org Thu Jan 27 13:42:09 2011 From: drais at icantclick.org (david raistrick) Date: Thu, 27 Jan 2011 14:42:09 -0500 (EST) Subject: Found: Who is responsible for no more IP addresses In-Reply-To: <2966867.2746.1296155181722.JavaMail.root@benjamin.baylink.com> References: <2966867.2746.1296155181722.JavaMail.root@benjamin.baylink.com> Message-ID: <alpine.BSF.2.00.1101271434580.54349@murf.icantclick.org> On Thu, 27 Jan 2011, Jay Ashworth wrote: > Fox didn't screw up, for a change, and Vint's quote appears in many > other news sources. Apparently, I'm the only one on Nanog who knows > about this new thing called The Google. :-) Fox (in the linked article) didn't quote Vint. They said useful things like this: source: http://www.foxnews.com/scitech/2011/01/26/internet-run-ip-addresses-happens-anyones-guess/ "It's the end of the web as we know it." And this is -not- what the article said before: "Web developers have compensated for this problem by creating IPv6 -- a system which recognizes 128-bit addresses as opposed to IPv4's 32-bit addresses." Originally (an hour ago) it read something like "Web developers have compensated for this problem by creating IPv6 -- a system which uses 6 digit addresses instead of 4 digit addresses" "But IPv6 isn't backwards-compatible with IPv4, meaning that it's not able to read most content that operates on an IPv4 system. At best, the user experience will be clunky and slow. At worst, instead of a webpage, all users will be able to view is a blank page." -- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html From drais at icantclick.org Thu Jan 27 13:43:37 2011 From: drais at icantclick.org (david raistrick) Date: Thu, 27 Jan 2011 14:43:37 -0500 (EST) Subject: Found: Who is responsible for no more IP addresses In-Reply-To: <alpine.BSF.2.00.1101271434580.54349@murf.icantclick.org> References: <2966867.2746.1296155181722.JavaMail.root@benjamin.baylink.com> <alpine.BSF.2.00.1101271434580.54349@murf.icantclick.org> Message-ID: <alpine.BSF.2.00.1101271442510.54349@murf.icantclick.org> here's the original quote (which a friend had pasted to me): "Web developers have tried to compensate for this problem by creating IPv6 -- a system that recognizes six-digit IP addresses rather than four-digit ones." On Thu, 27 Jan 2011, david raistrick wrote: > On Thu, 27 Jan 2011, Jay Ashworth wrote: > >> Fox didn't screw up, for a change, and Vint's quote appears in many >> other news sources. Apparently, I'm the only one on Nanog who knows >> about this new thing called The Google. :-) > > Fox (in the linked article) didn't quote Vint. > > > They said useful things like this: > > source: > http://www.foxnews.com/scitech/2011/01/26/internet-run-ip-addresses-happens-anyones-guess/ > > "It's the end of the web as we know it." > > And this is -not- what the article said before: > "Web developers have compensated for this problem by creating IPv6 -- a > system which recognizes 128-bit addresses as opposed to IPv4's 32-bit > addresses." > > Originally (an hour ago) it read something like > "Web developers have compensated for this problem by creating IPv6 -- a > system which uses 6 digit addresses instead of 4 digit addresses" > > > "But IPv6 isn't backwards-compatible with IPv4, meaning that it's not able to > read most content that operates on an IPv4 system. At best, the user > experience will be clunky and slow. At worst, instead of a webpage, all users > will be able to view is a blank page." > > > > -- > david raistrick http://www.netmeister.org/news/learn2quote.html > drais at icantclick.org http://www.expita.com/nomime.html > > -- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html From jeff-kell at utc.edu Thu Jan 27 13:49:05 2011 From: jeff-kell at utc.edu (Jeff Kell) Date: Thu, 27 Jan 2011 14:49:05 -0500 Subject: Found: Who is responsible for no more IP addresses In-Reply-To: <alpine.BSF.2.00.1101271442510.54349@murf.icantclick.org> References: <2966867.2746.1296155181722.JavaMail.root@benjamin.baylink.com> <alpine.BSF.2.00.1101271434580.54349@murf.icantclick.org> <alpine.BSF.2.00.1101271442510.54349@murf.icantclick.org> Message-ID: <4D41CC31.20101@utc.edu> On 1/27/2011 2:43 PM, david raistrick wrote: > > > here's the original quote (which a friend had pasted to me): > > "Web developers have tried to compensate for this problem by creating IPv6 -- a system > that recognizes six-digit IP addresses rather than four-digit ones." And as replied privately to someone else earlier, that was quoted from Fox news IPv6 website, http://wwwwww.foxnews.com :-) Jeff From Wesley.E.George at sprint.com Thu Jan 27 13:51:54 2011 From: Wesley.E.George at sprint.com (George, Wes E [NTK]) Date: Thu, 27 Jan 2011 19:51:54 +0000 Subject: Found: Who is responsible for no more IP addresses In-Reply-To: <2966867.2746.1296155181722.JavaMail.root@benjamin.baylink.com> References: <F05D77A9631CAE4097F7B69095F1B06F02E2C2@EX02.drtel.lan> <2966867.2746.1296155181722.JavaMail.root@benjamin.baylink.com> Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E0695B4@PLSWM12A.ad.sprint.com> > -----Original Message----- > From: Jay Ashworth [mailto:jra at baylink.com] > Sent: Thursday, January 27, 2011 2:06 PM > To: NANOG > Subject: Re: Found: Who is responsible for no more IP addresses > > ----- Original Message ----- > > From: "Brian Johnson" <bjohnson at drtel.com> > > > > > To be clear, FOX screwed this up big time, but that doesn't mean we > > all need to get out our personal/political pitchforks and run them > out > > of town. Take your Ritalin. :-) > > Fox didn't screw up, for a change, and Vint's quote appears in many > other news sources. Apparently, I'm the only one on Nanog who knows > about this new thing called The Google. :-) > > Thinking that Fox "News" is not a reputable news source is not, indeed, > an opinion attributable *solely* to non-Republicans, and indeed, it's > easy > to prove in a documentary, non-partisan fashion. > [WES] Don't kid yourself, defending a "reputable news organization" for not properly checking their facts on a technical story before publishing is politically motivated too, especially when you try to imply that being willing to call out inaccurate (technical) info in the news is somehow related to one's political party. The article that everyone is causing everyone to make fun of Fox news for says nothing about Vint. Fox news has posted two separate articles, both of which have been factually incorrect. http://www.foxnews.com/scitech/2011/01/26/internet-run-ip-addresses-happens-anyones-guess/ and http://www.foxnews.com/scitech/2010/07/26/world-run-internet-addresses-year-experts-predict/ They at least corrected the first one - "Editors' Note: An earlier version of this story erroneously described an IP address as consisting of four digits, rather than four sets of digits, and inaccurately described the IP address. This story has been updated to reflect the correction." But this gem still exists in the first article: "Web developers have compensated for this problem by creating IPv6". At least there's *probably* some web developers at IETF that might have had a hand in creating IPv6, so that one's not technically incorrect... The second one from several months ago is still borked: "IPv4, ... the unique 32-digit number used to identify each computer, website or internet-connected device. ... The solution to the problem is IPv6, which uses a 128-digit address." So, first it was 32 digits, then it was 4 digits... FWIW, Marketplace (on NPR) did a story the other night too. It wasn't necessarily incorrect, but it was so dumbed down that they managed to talk about IPv4 exhaustion without mentioning the words "IPv4" or "IPv6" http://marketplace.publicradio.org/display/web/2011/01/25/pm-internet-running-out-of-digital-addresses/ Wes George -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6793 bytes Desc: not available URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110127/235441a1/attachment.bin> From jra at baylink.com Thu Jan 27 14:03:09 2011 From: jra at baylink.com (Jay Ashworth) Date: Thu, 27 Jan 2011 15:03:09 -0500 (EST) Subject: Found: Who is responsible for no more IP addresses In-Reply-To: <32372610.2816.1296158568386.JavaMail.root@benjamin.baylink.com> Message-ID: <15379786.2818.1296158589318.JavaMail.root@benjamin.baylink.com> Let me clarify: The original question was (so far as I could see): "Was Fox making up the quote where Vint took the blame for IPv4 exhaustion?" The answer, of course, was "no, they didn't; lots of people have the quote". I wasn't speaking to the technical details of the actual piece, which, clearly, I didn't read. :-) Cheers -- jra From mathews at hawaii.edu Thu Jan 27 14:22:13 2011 From: mathews at hawaii.edu (Robert Mathews (OSIA)) Date: Thu, 27 Jan 2011 15:22:13 -0500 Subject: Found: Who is responsible for no more IP addresses In-Reply-To: <54E900DC635DAB4DB7A6D799B3C4CD8E0695B4@PLSWM12A.ad.sprint.com> References: <F05D77A9631CAE4097F7B69095F1B06F02E2C2@EX02.drtel.lan> <2966867.2746.1296155181722.JavaMail.root@benjamin.baylink.com> <54E900DC635DAB4DB7A6D799B3C4CD8E0695B4@PLSWM12A.ad.sprint.com> Message-ID: <4D41D3F5.3010800@hawaii.edu> George, Wes E [NTK] wrote: > The second one from several months ago is still borked: > "IPv4, ... the unique 32-digit number used to identify each computer, website > or internet-connected device. ... The solution to the problem is IPv6, which > uses a 128-digit address." So, first it was 32 digits, then it was 4 digits... > > ..... > > Wes George Confusion can be purposeful. See http://www.justicequest.net/forums/showpost.php?p=457015&postcount=4 Perhaps, it would be possible to effect some - *to switch-off* their netted computers/devices for a period no less than 6 months - such that their computers/devices are able to properly adjust to changes. O:-) Best. From mark at viviotech.net Thu Jan 27 14:26:58 2011 From: mark at viviotech.net (Mark Keymer) Date: Thu, 27 Jan 2011 12:26:58 -0800 Subject: Found: Who is responsible for no more IP addresses In-Reply-To: <54E900DC635DAB4DB7A6D799B3C4CD8E0695B4@PLSWM12A.ad.sprint.com> References: <F05D77A9631CAE4097F7B69095F1B06F02E2C2@EX02.drtel.lan> <2966867.2746.1296155181722.JavaMail.root@benjamin.baylink.com> <54E900DC635DAB4DB7A6D799B3C4CD8E0695B4@PLSWM12A.ad.sprint.com> Message-ID: <4D41D512.30109@viviotech.net> What I don't understand is I can only guess they must have a IT team. And Maybe even 1 or more people that view this list. Why don't they just talk to there own staff about the issues? Maybe one of the IT guess saw the issues talked about the articles and contacted the news team about the bad info. I donno. I agree they kind of did a poor job on this. If you work at FOX maybe you should help get the news guys on the right page. :) Sincerely, Mark On 1/27/2011 11:51 AM, George, Wes E [NTK] wrote: >> -----Original Message----- >> From: Jay Ashworth [mailto:jra at baylink.com] >> Sent: Thursday, January 27, 2011 2:06 PM >> To: NANOG >> Subject: Re: Found: Who is responsible for no more IP addresses >> >> ----- Original Message ----- >>> From: "Brian Johnson" <bjohnson at drtel.com> >>> To be clear, FOX screwed this up big time, but that doesn't mean we >>> all need to get out our personal/political pitchforks and run them >> out >>> of town. Take your Ritalin. :-) >> Fox didn't screw up, for a change, and Vint's quote appears in many >> other news sources. Apparently, I'm the only one on Nanog who knows >> about this new thing called The Google. :-) >> >> Thinking that Fox "News" is not a reputable news source is not, indeed, >> an opinion attributable *solely* to non-Republicans, and indeed, it's >> easy >> to prove in a documentary, non-partisan fashion. >> > [WES] Don't kid yourself, defending a "reputable news organization" for not > properly checking their facts on a technical story before publishing is > politically motivated too, especially when you try to imply that being willing > to call out inaccurate (technical) info in the news is somehow related to > one's political party. > > The article that everyone is causing everyone to make fun of Fox news for says > nothing about Vint. > Fox news has posted two separate articles, both of which have been factually > incorrect. > http://www.foxnews.com/scitech/2011/01/26/internet-run-ip-addresses-happens-anyones-guess/ > and > http://www.foxnews.com/scitech/2010/07/26/world-run-internet-addresses-year-experts-predict/ > > They at least corrected the first one - "Editors' Note: An earlier version of > this story erroneously described an IP address as consisting of four digits, > rather than four sets of digits, and inaccurately described the IP address. > This story has been updated to reflect the correction." > But this gem still exists in the first article: "Web developers have > compensated for this problem by creating IPv6". At least there's *probably* > some web developers at IETF that might have had a hand in creating IPv6, so > that one's not technically incorrect... > > The second one from several months ago is still borked: > "IPv4, ... the unique 32-digit number used to identify each computer, website > or internet-connected device. ... The solution to the problem is IPv6, which > uses a 128-digit address." So, first it was 32 digits, then it was 4 digits... > > FWIW, Marketplace (on NPR) did a story the other night too. It wasn't > necessarily incorrect, but it was so dumbed down that they managed to talk > about IPv4 exhaustion without mentioning the words "IPv4" or "IPv6" > http://marketplace.publicradio.org/display/web/2011/01/25/pm-internet-running-out-of-digital-addresses/ > > Wes George From jra at baylink.com Thu Jan 27 15:20:44 2011 From: jra at baylink.com (Jay Ashworth) Date: Thu, 27 Jan 2011 16:20:44 -0500 (EST) Subject: [dnsext] Historical root keys: The Large Router Vendor Speaks In-Reply-To: <4D41D3E2.6060107@cisco.com> Message-ID: <230107.2836.1296163244902.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "John Bashinski" <jbash at cisco.com> > Well, this has generated some interesting messages, and apparently > some people think that the "large router vendor" in question should > speak for itself. Yay! > Realities > ========= > 5. Some of the people installing these products (frankly including some > of the professional network gear) will have no clue what DNSSEC is > or what cryptography is. > > 6. In the case of the consumer gear, the cost to us of helping the > customer deal with any DNSSEC failure will be greater than the entire profit > we make on the device. > > 7. Even for professional gear, customers don't want to pay their staff > to mess with this, and we don't want to pay our staff to support > them. > > 8. Lots of our products get drop-shipped to people's field offices, > get plugged in by a wire-plugger-inner who basically just checks > that the lights are on and goes on to the next task, and then > have to fend for themselves, at least enough to be able to talk > to the NOC and await further instructions. > > Implication B: As much as it possibly can, anything we do must work > without human intervention, and especially without very skilled > intervention. We know there will be problems, but we MUST minimize > them and minimize the amount of "touch" required to fix them. > > Implication C: Social engineering is almost always a bigger risk than > cryptographic failure, especially at the device end of the > communication chain. That block of (correct) observations, coupled with later ones which I've elided for space, suggests to me the following observation: There is a limit to the maximum practical security and trust which can be engineered into the Internet at Large, absent some investment by specific users/network operators who require more. That observation shouldn't apply to the people who actually have a reason to be on this list -- backbone operators and professional DNS zone server operators *should* make that investment, as a contribution to the Public Good... but you can't necessarily expect it at the edge. My experience, and the integration of all the things I've learned in doing this for 25 years, is that complexity reaches a tipping point; there's only so much of it you can allow and still have a stable system -- and the complexity "attack surface" is at least proportional to the size of the system itself; something the size of The Entire Internet has even more stringent limits in that regard than, say, an enterprise LAN/WAN. So while I applaud Cisco's (or, more properly, John's) evaluation of the situation, and statement of goals -- and I agree with nearly everything he says -- my personal opinion is that there's a practical limit as to how close to the edge you can push the event horizon without the whole thing falling over... and I don't think that number's 100%. Cheers, -- jra From joelja at bogus.com Thu Jan 27 15:31:04 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Thu, 27 Jan 2011 13:31:04 -0800 Subject: Future of the IPv6 CPE survey on RIPE Labs - Your Input Needed In-Reply-To: <4D41B305.8020800@freedesktop.org> References: <1164463.290.1296018492548.JavaMail.franck@franck-martins-macbook-pro.local> <alpine.BSF.2.00.1101260856400.69156@mignon.ki.iif.hu> <31362582-C2A9-45CC-A3E9-13EB5743C957@delong.com> <AANLkTinkMg+n6z8nZbxBD+9uRe5BBc2c+ceExbNQgqFp@mail.gmail.com> <CB7A959F-1A6F-4F3E-B937-F7F3C09C85F5@delong.com> <4D4060FE.1000504@brightok.net> <006d01cbbdef$7f425c80$7dc71580$@iname.com> <4D417E7B.8000906@brightok.net> <20110127152503.GC5424@dan.olp.net> <4D419065.8030903@brightok.net> <4D41AF92.5060307@bogus.com> <4D41B305.8020800@freedesktop.org> Message-ID: <4D41E418.9050503@bogus.com> On 1/27/11 10:01 AM, Jim Gettys wrote: > > For god's sake, stay away from the DIR-825(Rev A), which has been > effectively abandoned by DLINK support and has no IPv6 support at all. pretty sure you can't find those on the shelf... The current model I bought on a lark for someone for christmas 2009 and have subsequently purchased several more, and not just becasue of the ipv6 support. > This has left a bad taste in my mouth. It has an entirely different > processor in it. The RevB replaced the RevA over a year ago, but it's > worth checking. > > Unfortunately, my Rev B was blown up by lightning. Dunno if it is being > supported by DLINK any better. > - Jim > From joelja at bogus.com Thu Jan 27 15:33:05 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Thu, 27 Jan 2011 13:33:05 -0800 Subject: Future of the IPv6 CPE survey on RIPE Labs - Your Input Needed In-Reply-To: <20110127104003.C5C2818C@resin18.mta.everyone.net> References: <20110127104003.C5C2818C@resin18.mta.everyone.net> Message-ID: <4D41E491.5000500@bogus.com> unlike a simpler device you can actually turn that off. in fact it has more knobs than you've likely seen in a consumer cpe... joel On 1/27/11 10:40 AM, Scott Weeks wrote: > > > --- frnkblk at iname.com wrote: > From: "Frank Bulk" <frnkblk at iname.com> > > Have you looked at D-Link's DIR-825? It has most of the things you're > ------------------------------------------- > > > > Ewww, yuck! "...this router utilizes dual active firewalls (SPI and NAT) to prevent potential attacks from across the Internet." > > ftp://ftp.dlink.com/Gateway/dir825/Manual/dir825_manual_110.zip > > > scott > From bruns at 2mbit.com Thu Jan 27 15:50:39 2011 From: bruns at 2mbit.com (Brielle) Date: Thu, 27 Jan 2011 14:50:39 -0700 Subject: Future of the IPv6 CPE survey on RIPE Labs - Your Input Needed Message-ID: <b6d1f487890f35832d8a036116e8d864.squirrel@webmail.sosdg.org> On Thu, January 27, 2011 2:31 pm, Joel Jaeggli wrote: > On 1/27/11 10:01 AM, Jim Gettys wrote: >> For god's sake, stay away from the DIR-825(Rev A), which has been effectively abandoned by DLINK support and has no IPv6 support at all. > pretty sure you can't find those on the shelf... > The current model I bought on a lark for someone for christmas 2009 and have subsequently purchased several more, and not just becasue of the ipv6 support. The DIR-615 Rev C1 and higher are fairly decent, and both OpenWRT and DD-WRT capable. The TrendNet TEW623BRP and friends of that era are basically rebranded DIR-615 C1s. Both are fairly inexpensive and quite capable once you get rid of the stock software. -- Brielle Bruns http://www.sosdg.org / http://www.ahbl.org From mikea at mikea.ath.cx Thu Jan 27 15:53:22 2011 From: mikea at mikea.ath.cx (mikea) Date: Thu, 27 Jan 2011 15:53:22 -0600 Subject: Found: Who is responsible for no more IP addresses In-Reply-To: <4D41D512.30109@viviotech.net> References: <F05D77A9631CAE4097F7B69095F1B06F02E2C2@EX02.drtel.lan> <2966867.2746.1296155181722.JavaMail.root@benjamin.baylink.com> <54E900DC635DAB4DB7A6D799B3C4CD8E0695B4@PLSWM12A.ad.sprint.com> <4D41D512.30109@viviotech.net> Message-ID: <20110127215322.GA58148@mikea.ath.cx> On Thu, Jan 27, 2011 at 12:26:58PM -0800, Mark Keymer wrote: > What I don't understand is I can only guess they must have a IT team. > And Maybe even 1 or more people that view this list. Why don't they just > talk to there own staff about the issues? Maybe one of the IT guess saw > the issues talked about the articles and contacted the news team about > the bad info. I donno. I agree they kind of did a poor job on this. > > If you work at FOX maybe you should help get the news guys on the right > page. :) My experience working with newspaper and TV reporters leads me to believe that they can't recognize when they're on the wrong page, and will sacrifice accuracy to catchy titles and text "simplified" to the point of being ludicrously wrong -- at least when it comes to topics such as computers, networking, and spam. I certainly don't expect any better of Fox. Remember that study on people so incompetent that they can't recognize their own incompetence? That's it, in spades. -- Mike Andrews, W5EGO mikea at mikea.ath.cx Tired old sysadmin From lowen at pari.edu Thu Jan 27 14:56:25 2011 From: lowen at pari.edu (Lamar Owen) Date: Thu, 27 Jan 2011 15:56:25 -0500 Subject: Found: Who is responsible for no more IP addresses In-Reply-To: <4D41D512.30109@viviotech.net> References: <F05D77A9631CAE4097F7B69095F1B06F02E2C2@EX02.drtel.lan> Message-ID: <201101271556.25585.lowen@pari.edu> On Thursday, January 27, 2011 03:26:58 pm Mark Keymer wrote: > If you work at FOX maybe you should help get the news guys on the right > page. :) Coming from broadcast engineering prior to my current IT gig, let me tell you that in most larger broadcast organizations the tech folk are rather fortunate if the talent knows who they are at all, and even more fortunate if the talent takes instruction from them; the right people to get to are the producers. Most of the time, large broadcaster talent and producers (and managers) aren't terribly receptive to corrections from technical staff. I was in a very good situation in the stations for which I worked; but they were smaller organizations. I always felt like a valuable part of the team, and I and the talent were great friends, as they knew I cared about making them look and sound good. In the age of conglomeration, central IT/engineering, and outsourcing, it may be that the actual production outfit for whom the talent directly works is not the same organization for whom the IT folk work, and the broadcast tech folk may work for someone entirely different. Additionally, the IT and tech staff are many of the times terribly understaffed, and may not even pay attention to the actual product going over the air, concentrating on the transmission, computer, automation, or studio operations/production systems technical operation rather than the content transmitted. Or they're fixing yet another virus infection; perhaps they might even get docked for correcting such an error with 'shouldn't you have been working instead of watching our news?' Now, if that tech happens to be the operator on duty in master control, he or she can sometimes have QA feedback capability, but not always, and almost never directly to the talent. So, a good case of the right hand not knowing what the left hand does. And once it is on the air, it's very difficult to get it changed; egg in the face, you know. The fact that it was changed at all should speak volumes, IMO. Someone did catch at least part of the error, and had sufficient feedback capability to get it corrected. From paul at paulgraydon.co.uk Thu Jan 27 16:26:27 2011 From: paul at paulgraydon.co.uk (Paul Graydon) Date: Thu, 27 Jan 2011 12:26:27 -1000 Subject: Found: Who is responsible for no more IP addresses In-Reply-To: <4D41D512.30109@viviotech.net> References: <F05D77A9631CAE4097F7B69095F1B06F02E2C2@EX02.drtel.lan> <2966867.2746.1296155181722.JavaMail.root@benjamin.baylink.com> <54E900DC635DAB4DB7A6D799B3C4CD8E0695B4@PLSWM12A.ad.sprint.com> <4D41D512.30109@viviotech.net> Message-ID: <4D41F113.9030302@paulgraydon.co.uk> I consider it to be very much part of the general attitude of news organisations towards the online content. It seems in general that very little editorial oversight takes place with online content, compared to what might appear in print. Often seems rather much like the content comes direct from the journalists, which any editor will tell you is generally a bad idea! Part of the problem has been perfectly demonstrated by this article. Having published something inaccurate and had lots of people jump on them in the comments, they've since updated and fixed the faults. Never mind that there are who knows how many people who have read it already and now have the wrong idea, as long as it's correct now, right? Paul On 01/27/2011 10:26 AM, Mark Keymer wrote: > What I don't understand is I can only guess they must have a IT team. > And Maybe even 1 or more people that view this list. Why don't they just > talk to there own staff about the issues? Maybe one of the IT guess saw > the issues talked about the articles and contacted the news team about > the bad info. I donno. I agree they kind of did a poor job on this. > > If you work at FOX maybe you should help get the news guys on the right > page. :) > > Sincerely, > > Mark > > > On 1/27/2011 11:51 AM, George, Wes E [NTK] wrote: >>> -----Original Message----- >>> From: Jay Ashworth [mailto:jra at baylink.com] >>> Sent: Thursday, January 27, 2011 2:06 PM >>> To: NANOG >>> Subject: Re: Found: Who is responsible for no more IP addresses >>> >>> ----- Original Message ----- >>>> From: "Brian Johnson"<bjohnson at drtel.com> >>>> To be clear, FOX screwed this up big time, but that doesn't mean we >>>> all need to get out our personal/political pitchforks and run them >>> out >>>> of town. Take your Ritalin. :-) >>> Fox didn't screw up, for a change, and Vint's quote appears in many >>> other news sources. Apparently, I'm the only one on Nanog who knows >>> about this new thing called The Google. :-) >>> >>> Thinking that Fox "News" is not a reputable news source is not, indeed, >>> an opinion attributable *solely* to non-Republicans, and indeed, it's >>> easy >>> to prove in a documentary, non-partisan fashion. >>> >> [WES] Don't kid yourself, defending a "reputable news organization" for not >> properly checking their facts on a technical story before publishing is >> politically motivated too, especially when you try to imply that being willing >> to call out inaccurate (technical) info in the news is somehow related to >> one's political party. >> >> The article that everyone is causing everyone to make fun of Fox news for says >> nothing about Vint. >> Fox news has posted two separate articles, both of which have been factually >> incorrect. >> http://www.foxnews.com/scitech/2011/01/26/internet-run-ip-addresses-happens-anyones-guess/ >> and >> http://www.foxnews.com/scitech/2010/07/26/world-run-internet-addresses-year-experts-predict/ >> >> They at least corrected the first one - "Editors' Note: An earlier version of >> this story erroneously described an IP address as consisting of four digits, >> rather than four sets of digits, and inaccurately described the IP address. >> This story has been updated to reflect the correction." >> But this gem still exists in the first article: "Web developers have >> compensated for this problem by creating IPv6". At least there's *probably* >> some web developers at IETF that might have had a hand in creating IPv6, so >> that one's not technically incorrect... >> >> The second one from several months ago is still borked: >> "IPv4, ... the unique 32-digit number used to identify each computer, website >> or internet-connected device. ... The solution to the problem is IPv6, which >> uses a 128-digit address." So, first it was 32 digits, then it was 4 digits... >> >> FWIW, Marketplace (on NPR) did a story the other night too. It wasn't >> necessarily incorrect, but it was so dumbed down that they managed to talk >> about IPv4 exhaustion without mentioning the words "IPv4" or "IPv6" >> http://marketplace.publicradio.org/display/web/2011/01/25/pm-internet-running-out-of-digital-addresses/ >> >> Wes George > From jfesler at gigo.com Thu Jan 27 17:08:43 2011 From: jfesler at gigo.com (Jason Fesler) Date: Thu, 27 Jan 2011 15:08:43 -0800 (PST) Subject: test-ipv6.com Message-ID: <alpine.BSF.2.00.1101271448000.15852@goat.gigo.com> Several people have suggested I (re)post information about test-ipv6.com here. http://test-ipv6.com .. tests ipv4 and ipv6 by dns name tests dual stack (will the client break on World IPv6 Day?) tests ipv6 by IP literal (teredo can pass this) gives advice to end user about current status and (depending on circumstances) more information "broken" users (can't connect to dual stack) are solicited for info Caution: does depend on javascript. http://test-ipv6.com/simple_test.html Eyeball test only for user, with instructions; no javascript required. Please direct any comments, flames, etc directly to me instead of the list. I've added enough noise already :-) From tmagill at providecommerce.com Thu Jan 27 17:33:57 2011 From: tmagill at providecommerce.com (Thomas Magill) Date: Thu, 27 Jan 2011 23:33:57 +0000 Subject: SP Sizing math? Message-ID: <A1B9BAEA8FE39847BCD6C473E894B595027D2AB5@SDEXMB02.Proflowers.com> So keep in mind I don't have an SP background. I have a client who has this idea of getting into the SP business and I'm trying to help them realize, realistically, what kind of undertaking this will be. For a residential SP, what is a good reference for general guidelines on sizing. Such as, for 6,000 residential users, how bandwidth upstream would be required to be fairly assured your phone will not be blowing up with complaints? What amount of oversubscription is acceptable at what amount of bandwidth? Are customers just sold if you tell them 5 meg down, even though you have a 20:1 oversubscription? I have read in NANOG archives 100Mbps/1,000 users for a school campus environment; would residential be equivalent? Any input would be greatly appreciated. Thomas Magill Network Engineer Office: (858) 909-3777 Cell: (858) 869-9685 tmagill at providecommerce.com<mailto:tmagill at providecommerce.com> provide-commerce 4840 Eastgate Mall San Diego, CA 92121 ProFlowers<http://www.proflowers.com/> | redENVELOPE<http://www.redenvelope.com/> | Cherry Moon Farms<http://www.cherrymoonfarms.com/> | Shari's Berries<http://www.berries.com/> From surfer at mauigateway.com Thu Jan 27 17:38:27 2011 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 27 Jan 2011 15:38:27 -0800 Subject: Future of the IPv6 CPE survey on RIPE Labs - Your Input Needed Message-ID: <20110127153827.C5C0412B@resin14.mta.everyone.net> On 1/27/11 10:40 AM, Scott Weeks wrote: > --- frnkblk at iname.com wrote: > From: "Frank Bulk" <frnkblk at iname.com> > > Have you looked at D-Link's DIR-825? It has most of the things you're > ------------------------------------------- > > > > Ewww, yuck! "...this router utilizes dual active firewalls (SPI and NAT) to prevent potential attacks from across the Internet." > > ftp://ftp.dlink.com/Gateway/dir825/Manual/dir825_manual_110.zip --- joelja at bogus.com wrote: From: Joel Jaeggli <joelja at bogus.com> unlike a simpler device you can actually turn that off. in fact it has more knobs than you've likely seen in a consumer cpe... ----------------------------------- I just meant they were calling NAT an "active firewall" in the manual. I need a bath. I feel dirty now... >:-) scott From danny at spesh.com Thu Jan 27 17:47:33 2011 From: danny at spesh.com (Danny O'Brien) Date: Thu, 27 Jan 2011 15:47:33 -0800 Subject: Connectivity status for Egypt Message-ID: <AANLkTimUaNCRFhQqBTPM6Z=W7WUfU8fZUFHGjbqXGJsq@mail.gmail.com> Around 2236 UCT, we lost all Internet connectivity with our contacts in Egypt, and I'm hearing reports of (in declining order of confirmability): 1) Internet connectivity loss on major (broadband) ISPs 2) No SMS 4) Intermittent connectivity with smaller (dialup?) ISPs 5) No mobile service in major cities -- Cairo, Alexandria The working assumption here is that the Egyptian government has made the decision to shut down all external, and perhaps internal electronic communication as a reaction to the ongoing protests in that country. If anyone can provide more details as to what they're seeing, the extent, plus times and dates, it would be very useful. In moments like this there are often many unconfirmed rumors: I'm seeking concrete reliable confirmation which I can pass onto the press and those working to bring some communications back up (if you have a ham radio license, there is some very early work to provide emergency connectivity. Info at: http://pastebin.com/fHHBqZ7Q ) Thank you, -- dobrien at cpj.org Danny O'Brien, Committee to Protect Journalists gpg key: http://www.spesh.com/danny/crypto/dannyobrien-key20091106.txt From nanog.20110127 at jason.roysdon.net Thu Jan 27 18:03:40 2011 From: nanog.20110127 at jason.roysdon.net (Jason Roysdon - NANOG) Date: Thu, 27 Jan 2011 16:03:40 -0800 Subject: Clearwire/Clear for branch office connectivity? Message-ID: <20110128000149.M54753@jason.roysdon.net> As a Clear customer, some things that I would inform you of: Using RFC1918 in their backbone: Traceroute from my internal network out: $ traceroute 8.8.8.8 traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 40 byte packets 1 10.12.250.49 (10.12.250.49) 1.671 ms 1.467 ms 3.214 ms - my network 2 10.12.249.1 (10.12.249.1) 15.594 ms 15.530 ms 17.015 ms - my network 3 192.168.15.1 (192.168.15.1) 17.957 ms 17.882 ms 18.978 ms - Clear CPE router device 4 * * * 5 10.41.229.197 (10.41.229.197) 82.081 ms 83.805 ms 52.455 ms 6 (71.22.8.161) 72.237 ms 72.105 ms 73.546 ms 7 (71.22.8.253) 75.988 ms 75.915 ms 76.095 ms 8 xe-10-3-0.bar1.SanFrancisco1.Level3.net (4.53.132.13) 73.130 ms 75.894 ms 75.801 ms 9 ae-0-11.bar2.SanFrancisco1.Level3.net (4.69.140.146) 79.860 ms 79.785 ms 76.723 ms 10 ae-6-6.ebr2.SanJose1.Level3.net (4.69.140.154) 79.558 ms 86.145 ms 86.056 ms 11 ae-92-92.csw4.SanJose1.Level3.net (4.69.134.222) 88.848 ms ae-72-72.csw2.SanJose1.Level3.net (4.69.134.214) 79.919 ms ae-92-92.csw4.SanJose1.Level3.net (4.69.134.222) 87.548 ms 12 ae-2-79.edge2.SanJose1.Level3.net (4.68.18.79) 77.322 ms ae-1-69.edge2.SanJose1.Level3.net (4.68.18.15) 78.785 ms ae-4-99.edge2.SanJose1.Level3.net (4.68.18.207) 77.568 ms 13 YOU-TUBE-IN.edge2.SanJose1.Level3.net (4.79.40.178) 80.985 ms 79.992 ms 81.634 ms 14 72.14.232.138 (72.14.232.138) 77.333 ms 72.14.232.136 (72.14.232.136) 81.425 ms 72.14.232.138 (72.14.232.138) 81.579 ms 15 216.239.47.186 (216.239.47.186) 102.799 ms 216.239.49.198 (216.239.49.198) 98.672 ms 107.898 ms 16 216.239.43.228 (216.239.43.228) 99.203 ms 99.134 ms 101.426 ms 17 216.239.48.165 (216.239.48.165) 101.391 ms 216.239.48.137 (216.239.48.137) 101.234 ms 216.239.48.165 (216.239.48.165) 110.738 ms 18 209.85.254.150 (209.85.254.150) 103.835 ms 104.921 ms 209.85.254.146 (209.85.254.146) 110.847 ms 19 google-public-dns-a.google.com (8.8.8.8) 90.106 ms 97.549 ms 93.919 ms Hops 1-3 are mine. Hops 4-7 is Clear's backbone. Clear doesn't use PTR records all the time, see hops 6 & 7. Traceroute back to my Clear IP on my CPE router device: $ traceroute (address removed) traceroute to (address removed), 30 hops max, 60 byte packets 1 removed 1.812 ms 2.173 ms 2.087 ms 2 public IP, removed 2.731 ms 2.635 ms 2.591 ms 3 public IP, removed 2.549 ms 2.520 ms 2.467 ms 4 0.ge-2-0-1.xt1.sac1.alter.net (152.63.51.81) 5.194 ms 5.170 ms 5.384 ms 5 0.so-5-2-0.xl3.sjc7.alter.net (152.63.48.6) 50.991 ms 49.159 ms 49.088 ms 6 0.ae3.br1.sjc7.alter.net (152.63.51.38) 9.644 ms 0.ae3.br3.sjc7.alter.net (152.63.50.5) 9.394 ms 9.352 ms 7 xe-9-2-0.edge1.sanjose3.level3.net (4.68.62.109) 10.201 ms 10.146 ms 10.107 ms 8 vlan69.csw1.sanjose1.level3.net (4.68.18.62) 18.609 ms vlan99.csw4.SanJose1.Level3.net (4.68.18.254) 13.095 ms vlan89.csw3.SanJose1.Level3.net (4.68.18.190) 12.120 ms 9 ae-82-82.ebr2.sanjose1.level3.net (4.69.134.217) 10.507 ms ae-62-62.ebr2.sanjose1.level3.net (4.69.134.209) 9.397 ms 9.344 ms 10 ae-1-6.bar2.sanfrancisco1.level3.net (4.69.140.153) 10.429 ms 9.605 ms 9.767 ms 11 ae-0-11.bar1.sanfrancisco1.level3.net (4.69.140.145) 9.741 ms 10.291 ms 10.172 ms 12 clearwire-c.bar1.sanfrancisco1.level3.net (4.53.132.14) 11.604 ms 11.598 ms 11.523 ms 13 71.22.8.254 (71.22.8.254) 10.122 ms 10.046 ms 10.038 ms 14 71.22.8.162 (71.22.8.162) 12.713 ms 10.839 ms 11.142 ms 15 * * * 16 * * * 17 * * * Traceroute back to my Clear CPE router's default gateway: $ traceroute 50.8.128.1 traceroute to 50.8.128.1 (50.8.128.1), 30 hops max, 60 byte packets 1 removed 1.812 ms 2.173 ms 2.087 ms 2 public IP, removed 2.731 ms 2.635 ms 2.591 ms 3 public IP, removed 2.549 ms 2.520 ms 2.467 ms 4 0.ge-2-0-1.xt1.sac1.alter.net (152.63.51.81) 21.532 ms 21.529 ms 21.510 ms 5 0.so-5-2-0.xl3.sjc7.alter.net (152.63.48.6) 30.556 ms 32.337 ms 32.309 ms 6 0.ae3.br1.sjc7.alter.net (152.63.51.38) 32.298 ms 0.ae3.br3.sjc7.alter.net (152.63.50.5) 38.977 ms 0.ae3.br1.sjc7.alter.net (152.63.51.38) 40.915 ms 7 xe-8-1-0.edge1.sanjose3.level3.net (4.68.110.249) 27.102 ms 13.003 ms 21.180 ms 8 vlan79.csw2.SanJose1.Level3.net (4.68.18.126) 21.157 ms 18.735 ms vlan89.csw3.sanjose1.level3.net (4.68.18.190) 29.614 ms 9 ae-62-62.ebr2.sanjose1.level3.net (4.69.134.209) 29.598 ms 22.253 ms ae-72-72.ebr2.SanJose1.Level3.net (4.69.134.213) 34.313 ms 10 ae-1-6.bar2.sanfrancisco1.level3.net (4.69.140.153) 22.176 ms 22.859 ms 27.192 ms 11 ae-0-11.bar1.sanfrancisco1.level3.net (4.69.140.145) 27.140 ms 25.919 ms 25.114 ms 12 clearwire-c.bar1.sanfrancisco1.level3.net (4.53.132.14) 26.566 ms 26.525 ms 26.465 ms 13 71.22.8.254 (71.22.8.254) 24.857 ms 26.655 ms 26.201 ms 14 71.22.8.162 (71.22.8.162) 15.488 ms 17.219 ms 17.212 ms 15 50-8-128-1.sfo.clearwire-wmx.net (50.8.128.1) 17.194 ms 11.126 ms 11.075 ms Clear's new WiMax routers do not allow you to bridge or use your public IP address directly. They force the router to NAT. However, you can turn off all firewalling and do a one-to-one NAT to a single device (as I've done to my Linux router). It does pass protocols such as 41 (for IPv6 tunneling over IPv4). You can get a "static" IP on the CPE router by paying more (something in the range of $5 or $10/month). I've not had my non-static IP change yet (Using dynamic dns to remote back in). Think of Clear's tech support as lower than your home DSL provider's support levels. About all they can do is have you reboot your computer and reset your CPE router. Examples of less-than-helpful tech support: "If you log into your router - we don't support that and you cannot make any changes" (this is requires for the above disabling of their firewall and one-to-one NAT setup which is totally unsupported - or just to see the exact signal strength or get the MAC address to report to them so you don't have to move the device). "Our router is not grounded, so you must plug it directly into the [mains] otherwise it builds up static" (in response that it is never a power loss that has caused me problems, as I have it on a surge-protecting UPS with my home Linux router which never has a problem). Having to manually aim your CPE router means you'd want to have a professional do it and make sure it is not going to move. There are a number of places that sell outside mounting/housing equipment so you can aim and get the best signal. This is a low-end solution for low-end costs (think MetroPCS/Cricket from the pay-as-you-go cell phone market - except with a 2 year contract). I think it's a good backup solution for the SOHO because sometimes DSL/Cable does have issues, but I would not use it for a business primary solution. I'd been a relatively happy customer of Clear for the last year for the price ($29/mo) I pay. My experience of the last week is not so happy. I have a direct line of sight to their tower from my two story house (once you get through one sheet of drywall and the roof). Their tower is less than a mile away and I have 4-5 bars of service. Suddenly my service was horrible this last week, with constant loss of Internet access. Ping monitoring to their default gateway will continue to work, but not beyond. Ping monitoring to their default gateway from co-located hosts doesn't have problems at this time. Resetting CPE router device fixes it, but problems can resume within as little as 20 minutes. Current solution which has worked for the last 24 hours was to use their online map to find the next best tower: I have repositioned the CPE router to point at a different tower and now that tower is the only one my CPE router detects (previously my CPE router could see 3-4 towers as there are a few a few more miles away to the left and right of the tower I was using). Again I get a consistent 4-5 bars with this other tower, but now no more problems. My guess is that there is some sort of malfunction at the other tower. Originally I thought my CPE router was having a problem (which is leased from Clear and they were sending a new one, not to arrive for another 3-4 days), as the problem would not fix itself without resetting the CPE router and was instantly fixed after resetting it. However, as of now I've had 24+ hours without problems so I believe the problem is with the tower or was with Clear's network and not the CPE router (the CPE router had been getting reset 10+ times per day as the household has been having issues the last 7 days, and the only change yesterday was pointing to a new tower and not a power cycle). Check their online maps, service is very spotting with many holes. My residence shows as not getting service (showing signal is blocked 2-3 blocks away by other buildings), but as I have a two story and have it mounted at the top of my house it has a clear line of sight. Look at their support pages on how they say to move it all around your house to find the best room to install it in for signal. According to their support site, don't install it too close to anything (Wifi, or any other electrical device) as that will block service as well (this is not true as far as I have observed while monitoring signal strength with numbers from the CPE device). I'd never consider using their mobile service as it would be so unreliable as to where you could get service. They tried to get my local PD to switch from AT&T's wireless data service in the cars to Clear a few years back and the trails were so bad and spotty. I'd never consider using their VoIP service (even if it was free) as their latency jitter just doesn't cut it. Jason Roysdon > Since I'm not with Clearwire anymore (end of contract) I can say that > there are people in the core networking that do follow and respond the > this list. > > I can say that their backbone is solid and the people there really do > care about the network. > > If you have serious a backbone issue with Clearwire a message on this > list will result in a response.. > > -- > Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 From caldcv at gmail.com Thu Jan 27 18:10:33 2011 From: caldcv at gmail.com (Christopher) Date: Thu, 27 Jan 2011 19:10:33 -0500 Subject: Connectivity status for Egypt In-Reply-To: <AANLkTimUaNCRFhQqBTPM6Z=W7WUfU8fZUFHGjbqXGJsq@mail.gmail.com> References: <AANLkTimUaNCRFhQqBTPM6Z=W7WUfU8fZUFHGjbqXGJsq@mail.gmail.com> Message-ID: <4D420979.2000004@gmail.com> I have a server with CityNet Host in Cairo. The server and ISP are completely offline From tglassey at earthlink.net Thu Jan 27 18:10:39 2011 From: tglassey at earthlink.net (todd glassey) Date: Thu, 27 Jan 2011 16:10:39 -0800 Subject: Found: Who is responsible for no more IP addresses In-Reply-To: <201101271556.25585.lowen@pari.edu> References: <F05D77A9631CAE4097F7B69095F1B06F02E2C2@EX02.drtel.lan> <201101271556.25585.lowen@pari.edu> Message-ID: <4D42097F.5020609@earthlink.net> On 1/27/2011 12:56 PM, Lamar Owen wrote: > On Thursday, January 27, 2011 03:26:58 pm Mark Keymer wrote: >> If you work at FOX maybe you should help get the news guys on the right >> page. :) > Coming from broadcast engineering prior to my current IT gig, let me tell you that in most larger broadcast organizations the tech folk are rather fortunate if the talent knows who they are at all, and even more fortunate if the talent takes instruction from them; the right people to get to are the producers. Most of the time, large broadcaster talent and producers (and managers) aren't terribly receptive to corrections from technical staff. Actually I would say they resist those corrections since they make the impetus of their fear-raising "the earth is flat commentary" what it is - something specifically to sell advertising content and to ensure they can from their perspective properly value their ad space. > I was in a very good situation in the stations for which I worked; but they were smaller organizations. I always felt like a valuable part of the team, and I and the talent were great friends, as they knew I cared about making them look and sound good. > > In the age of conglomeration, central IT/engineering, and outsourcing, it may be that the actual production outfit for whom the talent directly works is not the same organization for whom the IT folk work, and the broadcast tech folk may work for someone entirely different. Additionally, the IT and tech staff are many of the times terribly understaffed, and may not even pay attention to the actual product going over the air, concentrating on the transmission, computer, automation, or studio operations/production systems technical operation rather than the content transmitted. Or they're fixing yet another virus infection; perhaps they might even get docked for correcting such an error with 'shouldn't you have been working instead of watching our news?' > > Now, if that tech happens to be the operator on duty in master control, he or she can sometimes have QA feedback capability, but not always, and almost never directly to the talent. > > So, a good case of the right hand not knowing what the left hand does. The real problem is when the mind controlling the hands cannot keep the right hand and left hand synchronized on which ones responsibility rezipping the pants is... > And once it is on the air, it's very difficult to get it changed; egg in the face, you know. The fact that it was changed at all should speak volumes, IMO. Someone did catch at least part of the error, and had sufficient feedback capability to get it corrected. > > > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 10.0.1204 / Virus Database: 1435/3406 - Release Date: 01/27/11 > > From marka at isc.org Thu Jan 27 18:16:32 2011 From: marka at isc.org (Mark Andrews) Date: Fri, 28 Jan 2011 11:16:32 +1100 Subject: test-ipv6.com In-Reply-To: Your message of "Thu, 27 Jan 2011 15:08:43 -0800." <alpine.BSF.2.00.1101271448000.15852@goat.gigo.com> References: <alpine.BSF.2.00.1101271448000.15852@goat.gigo.com> Message-ID: <20110128001632.CF4E1938AFA@drugs.dv.isc.org> In message <alpine.BSF.2.00.1101271448000.15852 at goat.gigo.com>, Jason Fesler wr ites: > Several people have suggested I (re)post information about test-ipv6.com > here. > > http://test-ipv6.com .. > tests ipv4 and ipv6 by dns name > tests dual stack (will the client break on World IPv6 Day?) > tests ipv6 by IP literal (teredo can pass this) > gives advice to end user about current status and (depending on > circumstances) more information > "broken" users (can't connect to dual stack) are solicited for info > Caution: does depend on javascript. > > http://test-ipv6.com/simple_test.html > Eyeball test only for user, with instructions; no javascript required. > > Please direct any comments, flames, etc directly to me instead of the > list. I've added enough noise already :-) Note you can have totally broken IPv6 connectivity and still be fine on World IPv6 day. You just need applications with good multi-homing support. No web site can check this for you. If you are a application developer and want TCP example code that will work well with a broken IPv6 connection have a look at my blog. http://www.isc.org/community/blog/201101/how-to-connect-to-a-multi-homed-server-over-tcp Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From mmc at internode.com.au Thu Jan 27 18:25:52 2011 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Fri, 28 Jan 2011 10:55:52 +1030 Subject: test-ipv6.com In-Reply-To: <20110128001632.CF4E1938AFA@drugs.dv.isc.org> References: <alpine.BSF.2.00.1101271448000.15852@goat.gigo.com> <20110128001632.CF4E1938AFA@drugs.dv.isc.org> Message-ID: <FD0585DC-3869-4A90-8BFA-75D130C6EDE7@internode.com.au> On 28/01/2011, at 10:46 AM, Mark Andrews wrote: >> d. >> >> Please direct any comments, flames, etc directly to me instead of the >> list. I've added enough noise already :-) > > Note you can have totally broken IPv6 connectivity and still be > fine on World IPv6 day. You just need applications with good > multi-homing support. No web site can check this for you. > Anyone for peering cake? MMC From jfesler at gigo.com Thu Jan 27 18:52:51 2011 From: jfesler at gigo.com (Jason Fesler) Date: Thu, 27 Jan 2011 16:52:51 -0800 (PST) Subject: test-ipv6.com In-Reply-To: <20110128001632.CF4E1938AFA@drugs.dv.isc.org> References: <alpine.BSF.2.00.1101271448000.15852@goat.gigo.com> <20110128001632.CF4E1938AFA@drugs.dv.isc.org> Message-ID: <alpine.BSF.2.00.1101271623320.15852@goat.gigo.com> > Note you can have totally broken IPv6 connectivity and still be > fine on World IPv6 day. You just need applications with good > multi-homing support. Agreed so far. > No web site can check this for you. Hmm. What's wrong with asking the browser to try a dual-stack url today, as a proxy for what will happen to said web browser on June 8? The concern with World IPv6 day is with the users who have IPv6 enable, and have a default route - yet have broken IPv6 connectivity. This specific population will see timeouts on June 8. > If you are a application developer and want TCP example code that > will work well with a broken IPv6 connection have a look at my blog. Hopefully browsers will adopt your idea (or Happy Eyeballs). It may be the only remedy available, short of content providers collectively moving forward with dual stack, 0.05% broken users be damned. http://tools.ietf.org/html/draft-wing-v6ops-happy-eyeballs-ipv6-01 I'm personally not a big fan of either method, as that's going to increase the amount of tcp sessions to my web servers. It is merely less bad than the alternative. From cvuljanic at gmail.com Thu Jan 27 18:53:13 2011 From: cvuljanic at gmail.com (Craig V) Date: Thu, 27 Jan 2011 19:53:13 -0500 Subject: Connectivity status for Egypt In-Reply-To: <4D420979.2000004@gmail.com> References: <AANLkTimUaNCRFhQqBTPM6Z=W7WUfU8fZUFHGjbqXGJsq@mail.gmail.com> <4D420979.2000004@gmail.com> Message-ID: <AANLkTi=oNf5uEwbYUYWdxYpes6seC8GZgimpH=2s_1yX@mail.gmail.com> Some interesting financial news... Unsure if this is related the outages, but interesting..... http://www.marketwatch.com/story/egypt-market-slumps-as-mideast-turmoil-spreads-2011-01-27 EGYPT: Stock market stumbles amid nationwide turbulence<http://latimesblogs.latimes.com/babylonbeyond/2011/01/egypt-stock-market-stumbles-amidst-nationwide-turbulence.html> <http://www.marketwatch.com/story/egypt-market-slumps-as-mideast-turmoil-spreads-2011-01-27> http://latimesblogs.latimes.com/babylonbeyond/2011/01/egypt-stock-market-stumbles-amidst-nationwide-turbulence.html <http://latimesblogs.latimes.com/babylonbeyond/2011/01/egypt-stock-market-stumbles-amidst-nationwide-turbulence.html> On Thu, Jan 27, 2011 at 7:10 PM, Christopher <caldcv at gmail.com> wrote: > I have a server with CityNet Host in Cairo. The server and ISP are > completely offline > > From jbates at brightok.net Thu Jan 27 18:59:15 2011 From: jbates at brightok.net (Jack Bates) Date: Thu, 27 Jan 2011 18:59:15 -0600 Subject: test-ipv6.com In-Reply-To: <FD0585DC-3869-4A90-8BFA-75D130C6EDE7@internode.com.au> References: <alpine.BSF.2.00.1101271448000.15852@goat.gigo.com> <20110128001632.CF4E1938AFA@drugs.dv.isc.org> <FD0585DC-3869-4A90-8BFA-75D130C6EDE7@internode.com.au> Message-ID: <4D4214E3.7040407@brightok.net> On 1/27/2011 6:25 PM, Matthew Moyle-Croft wrote: > > Anyone for peering cake? > Yeah, Google, HE, Cogent, Sprint, Qwest, and Level3 all need peering cakes (as I'm pretty sure there is no participant in that list which is connected to every other participant in that list). If you could bake Qwest a Juniper IPv6 cake and Sprint an OKC gig-e termination w/ dual stack cake, that would be swell too. :) Jack (why did I decide to live in Oklahoma again?) From paul at paulgraydon.co.uk Thu Jan 27 19:01:04 2011 From: paul at paulgraydon.co.uk (Paul Graydon) Date: Thu, 27 Jan 2011 15:01:04 -1000 Subject: Connectivity status for Egypt In-Reply-To: <AANLkTi=oNf5uEwbYUYWdxYpes6seC8GZgimpH=2s_1yX@mail.gmail.com> References: <AANLkTimUaNCRFhQqBTPM6Z=W7WUfU8fZUFHGjbqXGJsq@mail.gmail.com> <4D420979.2000004@gmail.com> <AANLkTi=oNf5uEwbYUYWdxYpes6seC8GZgimpH=2s_1yX@mail.gmail.com> Message-ID: <4D421550.4050505@paulgraydon.co.uk> I'd suspect it's got a lot more to do with the open rioting on the streets, government shooting people, the numbers involved in protests, what happened in Tunisia next door etc. etc. Loss of Internet connectivity is relatively minor in comparison. Any investor with even half a brain is going to twig that's just not a good market to have money in right now. On 01/27/2011 02:53 PM, Craig V wrote: > Some interesting financial news... Unsure if this is related the outages, > but interesting..... > > http://www.marketwatch.com/story/egypt-market-slumps-as-mideast-turmoil-spreads-2011-01-27 > > EGYPT: Stock market stumbles amid nationwide > turbulence<http://latimesblogs.latimes.com/babylonbeyond/2011/01/egypt-stock-market-stumbles-amidst-nationwide-turbulence.html> > <http://www.marketwatch.com/story/egypt-market-slumps-as-mideast-turmoil-spreads-2011-01-27> > http://latimesblogs.latimes.com/babylonbeyond/2011/01/egypt-stock-market-stumbles-amidst-nationwide-turbulence.html > <http://latimesblogs.latimes.com/babylonbeyond/2011/01/egypt-stock-market-stumbles-amidst-nationwide-turbulence.html> > > On Thu, Jan 27, 2011 at 7:10 PM, Christopher<caldcv at gmail.com> wrote: > >> I have a server with CityNet Host in Cairo. The server and ISP are >> completely offline >> >> From mysidia at gmail.com Thu Jan 27 19:03:54 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 27 Jan 2011 19:03:54 -0600 Subject: Another v6 question In-Reply-To: <A5E4AFBB-92C6-464E-AAAB-07B69ECD5214@puck.nether.net> References: <AANLkTikEZVYFz+bx7MVXeht_qNnpkUEC_Mx0qhE6J9SR@mail.gmail.com> <55E7EC47-C434-4DF7-B92A-8EBC24133C53@delong.com> <AANLkTi=soS+LQoR3JYJxE8N3o9JYoxrL2dvzHZ+e5Geb@mail.gmail.com> <4F209412-3C3B-4CB6-8EB7-A25ABD1B9DBA@delong.com> <AANLkTinqipvQD-gSt1BZ5FcPT2krNhwqO5dExWrM=muG@mail.gmail.com> <67827BB1-BF59-45AF-842F-B9E1AD7A1F87@delong.com> <A5E4AFBB-92C6-464E-AAAB-07B69ECD5214@puck.nether.net> Message-ID: <AANLkTinwjARSJJQpMO-jkw3BxAuYcDuyJ4PjCgqQwEQo@mail.gmail.com> On Thu, Jan 27, 2011 at 8:49 AM, Jared Mauch <jared at puck.nether.net> wrote: > On Jan 26, 2011, at 8:33 PM, Owen DeLong wrote: > I expect that in ~3 years, we will see dual-stack and /64's handed out in conjunction with an IPv4 address as "common". > The ipv6 zealots talking about anything but a /64 for >end-site are talking about a "business class" service. No... they are not.. the /56 assignments are for all types of end sites, whether business or not. What makes a service "business class" or not has nothing directly to do with the number of IP addresses used. The only reason more IP addresses available was associated with higher classes of service in IPv4, and different end sites had different sizes of assignments, was because IP addresses were so scarce, and costly. Business class connections provide data rates suitable for larger networks, or generally come with SLAs; committed data rates, or assurances of reliability. The IP addressing needed for hosts is independent of the class of service. Under IPv6; it should be possible to upgrade service levels, or add networks, with no renumbering, or extra work required by the ISP to allocate more subnets. The /48 end-site assignments help future proof the LAN and help avoid the need to ever renumber to add subnets or to add discontinuous ones (aside from changing ISPs). > ?Even with my static IPs at home, I have no need for >more than a single /64 to be used in my wildest dreams. >I could live with ~256 ips for the future. ?I consider my >tech density "above-average". 98% of home users could probably live with _one_ IP address behind a NAT router; heck, most of them are doing just that with IPv4. Heck... most could probably live with 8 TCP port numbers and 8 UDP port numbers. What a waste of bits to give residential users 16-bit port numbers. Transition to IPv6 is not about what users can "live with" using current technology. The /48 end site assignments is supposed to provide opportunity for new technologies to be developed and provide useful innovations. Your wildest dreams are pretty limited, if you can't think of any way the additional subnets can be useful. Security and logical division are a few ideas. You might not care to do that now... but in 20 years, when you have 100000 smart chip / IP-based home automation enabled devices on your LAN. Subnetting starts to look more attractive; especially if common routers get the ability to do it automatically, and implement some passive isolation-based security mechanisms. > - Jared -JH From jbates at brightok.net Thu Jan 27 19:08:55 2011 From: jbates at brightok.net (Jack Bates) Date: Thu, 27 Jan 2011 19:08:55 -0600 Subject: Another v6 question In-Reply-To: <AANLkTinwjARSJJQpMO-jkw3BxAuYcDuyJ4PjCgqQwEQo@mail.gmail.com> References: <AANLkTikEZVYFz+bx7MVXeht_qNnpkUEC_Mx0qhE6J9SR@mail.gmail.com> <55E7EC47-C434-4DF7-B92A-8EBC24133C53@delong.com> <AANLkTi=soS+LQoR3JYJxE8N3o9JYoxrL2dvzHZ+e5Geb@mail.gmail.com> <4F209412-3C3B-4CB6-8EB7-A25ABD1B9DBA@delong.com> <AANLkTinqipvQD-gSt1BZ5FcPT2krNhwqO5dExWrM=muG@mail.gmail.com> <67827BB1-BF59-45AF-842F-B9E1AD7A1F87@delong.com> <A5E4AFBB-92C6-464E-AAAB-07B69ECD5214@puck.nether.net> <AANLkTinwjARSJJQpMO-jkw3BxAuYcDuyJ4PjCgqQwEQo@mail.gmail.com> Message-ID: <4D421727.7050602@brightok.net> On 1/27/2011 7:03 PM, Jimmy Hess wrote: > Security and logical division are a few ideas. > You might not care to do that now... but in 20 years, when you have > 100000 smart chip / IP-based home automation enabled devices on your > LAN. My helpdesk decided to counter with "We'll run out because of the nanobots we'll be injected with to cure cancer and other diseases." They just don't understand the fact that a single /64 network is plenty to handle all the nanobots in the human body (supposing we're still going to be human). Of course, the nanobots really do need their own isolated subnet. They do a lot of multicast, I'm guessing. Jack From tme at americafree.tv Thu Jan 27 19:10:56 2011 From: tme at americafree.tv (Marshall Eubanks) Date: Thu, 27 Jan 2011 20:10:56 -0500 Subject: Connectivity status for Egypt In-Reply-To: <AANLkTimUaNCRFhQqBTPM6Z=W7WUfU8fZUFHGjbqXGJsq@mail.gmail.com> References: <AANLkTimUaNCRFhQqBTPM6Z=W7WUfU8fZUFHGjbqXGJsq@mail.gmail.com> Message-ID: <513C97F8-55F0-45C1-92D5-B62AE60D1688@americafree.tv> On Jan 27, 2011, at 6:47 PM, Danny O'Brien wrote: > Around 2236 UCT, we lost all Internet connectivity with our contacts in > Egypt, and I'm hearing reports of (in declining order of confirmability): > > 1) Internet connectivity loss on major (broadband) ISPs > 2) No SMS > 4) Intermittent connectivity with smaller (dialup?) ISPs > 5) No mobile service in major cities -- Cairo, Alexandria > > The working assumption here is that the Egyptian government has made the > decision to shut down all external, and perhaps internal electronic > communication as a reaction to the ongoing protests in that country. > > If anyone can provide more details as to what they're seeing, the extent, > plus times and dates, it would be very useful. In moments like this there > are often many unconfirmed rumors: I'm seeking concrete reliable > confirmation which I can pass onto the press and those working to bring some > communications back up (if you have a ham radio license, there is some very > early work to provide emergency connectivity. Info at: > http://pastebin.com/fHHBqZ7Q ) On twitter (follow the #jan25 and #jan28 hash tags), there are many reports of loss of internet connectivity in Egypt. Apparently cell phones and land lines are still working. Of course, the assumption there is that this is connected to the large protests expected tomorrow in Egypt. Regards Marshall > > Thank you, > > -- > dobrien at cpj.org > Danny O'Brien, Committee to Protect Journalists > gpg key: http://www.spesh.com/danny/crypto/dannyobrien-key20091106.txt > From mysidia at gmail.com Thu Jan 27 19:19:12 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 27 Jan 2011 19:19:12 -0600 Subject: Found: Who is responsible for no more IP addresses In-Reply-To: <AANLkTi=gOqysF28+mMK0wYmd_Y-sDebvOKit=GoDxDs9@mail.gmail.com> References: <alpine.LRH.2.00.1101271319090.15061@efes.iucc.ac.il> <4D4163ED.1060201@foobar.org> <AANLkTi=gOqysF28+mMK0wYmd_Y-sDebvOKit=GoDxDs9@mail.gmail.com> Message-ID: <AANLkTikZsxZO7d0VmB2DQoLb_rY0KeeOPnYSaapQTvu7@mail.gmail.com> On Thu, Jan 27, 2011 at 11:59 AM, Jorge Amodio <jmamodio at gmail.com> wrote: >> http://www.foxnews.com/scitech/2011/01/26/internet-run-ip-addresses-happens-anyones-guess/ > "It's the end of the web as we know it. " We are doomed !! > Glad to know that, since a large percentage of it suxs. > Can we go back to the ftp.funet.fi ?(still up !! ) and gopher ? We can always weather out the IPv4 exhaustion by going back to UUCP for e-mail delivery, file transfer; better be sure to grab the source code in advance just in case. If the worst happens... get a few /24 microallocations for UUCP relays as critical infrastructure on whatever's left of the net, so we can perform modem dialin from wherever, and uploads our proposals to Usenet, for restoring sanity to the tarred remains of the internets.... <EG> > Jorge -- -JH From smb at cs.columbia.edu Thu Jan 27 19:20:54 2011 From: smb at cs.columbia.edu (Steven Bellovin) Date: Thu, 27 Jan 2011 20:20:54 -0500 Subject: Found: Who is responsible for no more IP addresses In-Reply-To: <20110127215322.GA58148@mikea.ath.cx> References: <F05D77A9631CAE4097F7B69095F1B06F02E2C2@EX02.drtel.lan> <2966867.2746.1296155181722.JavaMail.root@benjamin.baylink.com> <54E900DC635DAB4DB7A6D799B3C4CD8E0695B4@PLSWM12A.ad.sprint.com> <4D41D512.30109@viviotech.net> <20110127215322.GA58148@mikea.ath.cx> Message-ID: <49C877B1-0DCB-44F2-9F9D-90A310CD6B82@cs.columbia.edu> On Jan 27, 2011, at 4:53 22PM, mikea wrote: > On Thu, Jan 27, 2011 at 12:26:58PM -0800, Mark Keymer wrote: >> What I don't understand is I can only guess they must have a IT team. >> And Maybe even 1 or more people that view this list. Why don't they just >> talk to there own staff about the issues? Maybe one of the IT guess saw >> the issues talked about the articles and contacted the news team about >> the bad info. I donno. I agree they kind of did a poor job on this. >> >> If you work at FOX maybe you should help get the news guys on the right >> page. :) > > My experience working with newspaper and TV reporters leads me to believe > that they can't recognize when they're on the wrong page, and will > sacrifice accuracy to catchy titles and text "simplified" to the point > of being ludicrously wrong -- at least when it comes to topics such as > computers, networking, and spam. I certainly don't expect any better of > Fox. > Mmm... I've dealt with the press a lot. In general, the reporters from well-respected news organizations really are a lot better. One can argue cause and effect; the fact remains that when I've talked to the NY Times, the Wall Street Journal, NPR, and the Washington Post, I've been a lot happier with what appeared than when, say, I've spoken with (quite literally) Entertainment Weekly. No, the major outlets haven't been perfect, and I've occasionally spoken with reporters who, shall we say, didn't know which end the high-order bit was on; in general, though, my comments hold. Fox? Since I don't see that the Tea Party has any particular axe to grind here (the administration is neither pushing IPv6 on a reluctant private sector nor is it responsible for the forthcoming debacle), they're probably in the middle of the pack. --Steve Bellovin, http://www.cs.columbia.edu/~smb From fergdawgster at gmail.com Thu Jan 27 19:23:03 2011 From: fergdawgster at gmail.com (Paul Ferguson) Date: Thu, 27 Jan 2011 17:23:03 -0800 Subject: Connectivity status for Egypt In-Reply-To: <513C97F8-55F0-45C1-92D5-B62AE60D1688@americafree.tv> References: <AANLkTimUaNCRFhQqBTPM6Z=W7WUfU8fZUFHGjbqXGJsq@mail.gmail.com> <513C97F8-55F0-45C1-92D5-B62AE60D1688@americafree.tv> Message-ID: <AANLkTinVxeeH47=E-L472YjPo9kdozptsXanFx+qF6-r@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, Jan 27, 2011 at 5:10 PM, Marshall Eubanks <tme at americafree.tv> wrote: > > On twitter (follow the #jan25 and #jan28 hash tags), there are many > reports of loss of internet connectivity in Egypt. Apparently cell phones > and land lines are still working. > > Of course, the assumption there is that this is connected to the large > protests expected tomorrow in Egypt. > The U.S Embassy in Cairo website is also unreachable, as well as the main Egyptian Governmental portal: %ping www.egypt.gov.eg Pinging www.egypt.gov.eg [81.21.104.81] with 32 bytes of data: Request timed out. Request timed out. Request timed out. Request timed out. Ping statistics for 81.21.104.81: Packets: Sent = 4, Received = 0, Lost = 4 (100% loss), %tracert cairo.usembassy.gov Tracing route to cairo.usembassy.gov [62.140.73.207] over a maximum of 30 hops: 1 4 ms 2 ms 1 ms 62.140.73.207 [snip] 7 37 ms 27 ms 28 ms ix-1-1-0-0.tcore1.LVW-LosAngeles.as6453.net [216.6.12.25] 8 247 ms 204 ms 205 ms if-2-2.tcore2.LVW-LosAngeles.as6453.net [66.110.59.2] 9 226 ms 199 ms 204 ms if-8-1508.tcore2.AEQ-Ashburn.as6453.net [64.86.252.74] 10 289 ms 301 ms 219 ms if-2-2.tcore1.AEQ-Ashburn.as6453.net [216.6.87.2] 11 190 ms 252 ms 204 ms if-6-871.tcore1.PVU-Paris.as6453.net [216.6.51.58] 12 197 ms 204 ms 203 ms if-11-1-0-1411.core1.PV1-Paris.as6453.net [80.231.153.13] 13 229 ms 229 ms 236 ms ix-9-0-0.core1.PV1-Paris.as6453.net [195.219.215.38] 14 * * * Request timed out. 15 * * * Request timed out. 16 * * * Request timed out. 17 * * * Request timed out. 18 * ^C %ping cairo.usembassy.gov Pinging cairo.usembassy.gov [62.140.73.207] with 32 bytes of data: Request timed out. Request timed out. Request timed out. Request timed out. Ping statistics for 62.140.73.207: Packets: Sent = 4, Received = 0, Lost = 4 (100% loss), % Information related to '62.140.73.0 - 62.140.73.255' inetnum: 62.140.73.0 - 62.140.73.255 netname: EG-NMC descr: AW-NMC descr: For any abuse complain contact abuse at nile-online.com country: EG admin-c: IM217-AFRINIC tech-c: IA119-AFRINIC tech-c: IM217-AFRINIC tech-c: OM2093-AFRINIC status: ASSIGNED PA mnt-by: O-MAHMOUD remarks: data has been transferred from RIPE Whois Database 20050221 source: AFRINIC # Filtered parent: 62.140.64.0 - 62.140.127.255 role: IP Address Manager address: top of address: pyramid address: sand address: sahara phone: +202 37611153 phone: +202 37611123 fax-no: +202 37607656 e-mail: ipadmin at nile-online.com e-mail: ashwadfy at nile-online.com e-mail: mhalim at nile-online.com admin-c: MS22-Afrinic admin-c: MMK1-AFRINIC tech-c: AS38-Afrinic nic-hdl: IM217-AFRINIC source: AFRINIC # Filtered role: IP Address Admin address: 15 Mohamed Hafez St., address: Mohandessin address: Giza address: Egypt phone: +202 37611153 phone: +202 37611123 fax-no: +202 37607656 e-mail: ipadmin at nile-online.com e-mail: ashwadfy at nile-online.com e-mail: mhalim at nile-online.com admin-c: MS22-Afrinic tech-c: AS38-Afrinic nic-hdl: IA119-AFRINIC remarks: data has been transferred from RIPE Whois Database 20050221 source: AFRINIC # Filtered person: Omar Mahmoud nic-hdl: OM2093-AFRINIC address: 15 Mohamed Hafez St., address: Mohandessin address: Giza address: Egypt address: Cairo address: Egypt e-mail: mispeng-core at etisalatdata.net phone: +202 7606677 fax-no: +202 7607656 remarks: For any abuse complain contact abuse at nile-online.com remarks: data has been transferred from RIPE Whois Database 20050221 mnt-by: O-MAHMOUD source: AFRINIC # Filtered - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFNQhpoq1pz9mNUZTMRAkPsAKDQ4y08/I45IS/0XfNZ7kMbciQ61wCfQDJ9 Gm/f4cSJ9lY5BI4fBjdr+vU= =SRH3 -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson ?Engineering Architecture for the Internet ?fergdawgster(at)gmail.com ?ferg's tech blog: http://fergdawg.blogspot.com/ From marka at isc.org Thu Jan 27 19:25:49 2011 From: marka at isc.org (Mark Andrews) Date: Fri, 28 Jan 2011 12:25:49 +1100 Subject: test-ipv6.com In-Reply-To: Your message of "Thu, 27 Jan 2011 16:52:51 -0800." <alpine.BSF.2.00.1101271623320.15852@goat.gigo.com> References: <alpine.BSF.2.00.1101271448000.15852@goat.gigo.com> <20110128001632.CF4E1938AFA@drugs.dv.isc.org><alpine.BSF.2.00.1101271623320.15852@goat.gigo.com> Message-ID: <20110128012549.124DF939361@drugs.dv.isc.org> In message <alpine.BSF.2.00.1101271623320.15852 at goat.gigo.com>, Jason Fesler wr ites: > > Note you can have totally broken IPv6 connectivity and still be > > fine on World IPv6 day. You just need applications with good > > multi-homing support. > > Agreed so far. > > > No web site can check this for you. > > Hmm. What's wrong with asking the browser to try a dual-stack url today, > as a proxy for what will happen to said web browser on June 8? There is nothing wrong with that. Just remember you are only testing a single application. > The concern with World IPv6 day is with the users who have IPv6 enable, > and have a default route - yet have broken IPv6 connectivity. This > specific population will see timeouts on June 8. Yes. Their *applications* are broken. Application should continue to work well even in the presence of network breakage to one of the address to the site it is connecting to. Nameservers have been doing this for decades with sub second timeouts. > > If you are a application developer and want TCP example code that > > will work well with a broken IPv6 connection have a look at my blog. > > Hopefully browsers will adopt your idea (or Happy Eyeballs). > It may be the only remedy available, short of content providers > collectively moving forward with dual stack, 0.05% broken users be damned. Moving forward and be damned is a good idea provide you have enough content providers take the step at the same time. Your breakage will initially be 0.05 but when BING, Yahoo and Google etc. are all slow you will start to ask yourself why is the network slow. I would expext a measurable improvement over 24 hours especially if the websites also put up hints for how to fix the problems. > http://tools.ietf.org/html/draft-wing-v6ops-happy-eyeballs-ipv6-01 > > I'm personally not a big fan of either method, as that's going to increase > the amount of tcp sessions to my web servers. It is merely less bad than > the alternative. Unless the client is coming in over a congested link or a very long rtt path you are unlikely to see any additional tcp sessions. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From mikea at mikea.ath.cx Thu Jan 27 19:26:09 2011 From: mikea at mikea.ath.cx (mikea) Date: Thu, 27 Jan 2011 19:26:09 -0600 Subject: Found: Who is responsible for no more IP addresses In-Reply-To: <49C877B1-0DCB-44F2-9F9D-90A310CD6B82@cs.columbia.edu> References: <F05D77A9631CAE4097F7B69095F1B06F02E2C2@EX02.drtel.lan> <2966867.2746.1296155181722.JavaMail.root@benjamin.baylink.com> <54E900DC635DAB4DB7A6D799B3C4CD8E0695B4@PLSWM12A.ad.sprint.com> <4D41D512.30109@viviotech.net> <20110127215322.GA58148@mikea.ath.cx> <49C877B1-0DCB-44F2-9F9D-90A310CD6B82@cs.columbia.edu> Message-ID: <20110128012609.GA62410@mikea.ath.cx> On Thu, Jan 27, 2011 at 08:20:54PM -0500, Steven Bellovin wrote: > > On Jan 27, 2011, at 4:53 22PM, mikea wrote: > > > On Thu, Jan 27, 2011 at 12:26:58PM -0800, Mark Keymer wrote: > >> What I don't understand is I can only guess they must have a IT team. > >> And Maybe even 1 or more people that view this list. Why don't they just > >> talk to there own staff about the issues? Maybe one of the IT guess saw > >> the issues talked about the articles and contacted the news team about > >> the bad info. I donno. I agree they kind of did a poor job on this. > >> > >> If you work at FOX maybe you should help get the news guys on the right > >> page. :) > > > > My experience working with newspaper and TV reporters leads me to believe > > that they can't recognize when they're on the wrong page, and will > > sacrifice accuracy to catchy titles and text "simplified" to the point > > of being ludicrously wrong -- at least when it comes to topics such as > > computers, networking, and spam. I certainly don't expect any better of > > Fox. > > > > Mmm... I've dealt with the press a lot. In general, the reporters from > well-respected news organizations really are a lot better. One can > argue cause and effect; the fact remains that when I've talked to the > NY Times, the Wall Street Journal, NPR, and the Washington Post, I've > been a lot happier with what appeared than when, say, I've spoken with > (quite literally) Entertainment Weekly. No, the major outlets haven't > been perfect, and I've occasionally spoken with reporters who, shall > we say, didn't know which end the high-order bit was on; in general, > though, my comments hold. > > Fox? Since I don't see that the Tea Party has any particular axe to > grind here (the administration is neither pushing IPv6 on a reluctant > private sector nor is it responsible for the forthcoming debacle), > they're probably in the middle of the pack. Mine was considerably less exalted: network TV stations and the local poor excuse for a newspaper. The newspaper reporter tried, but just got it *so* wrong. The TV folks didn't even try, and got it even wronger. I was being interviewed on spam and botnets, which is a fairly arcane topic, and wasn't surprised. -- Mike Andrews, W5EGO mikea at mikea.ath.cx Tired old sysadmin From mikea at mikea.ath.cx Thu Jan 27 19:28:05 2011 From: mikea at mikea.ath.cx (mikea) Date: Thu, 27 Jan 2011 19:28:05 -0600 Subject: test-ipv6.com In-Reply-To: <4D4214E3.7040407@brightok.net> References: <alpine.BSF.2.00.1101271448000.15852@goat.gigo.com> <20110128001632.CF4E1938AFA@drugs.dv.isc.org> <FD0585DC-3869-4A90-8BFA-75D130C6EDE7@internode.com.au> <4D4214E3.7040407@brightok.net> Message-ID: <20110128012805.GB62410@mikea.ath.cx> On Thu, Jan 27, 2011 at 06:59:15PM -0600, Jack Bates wrote: > On 1/27/2011 6:25 PM, Matthew Moyle-Croft wrote: > > > >Anyone for peering cake? > > > > Yeah, Google, HE, Cogent, Sprint, Qwest, and Level3 all need peering > cakes (as I'm pretty sure there is no participant in that list which is > connected to every other participant in that list). If you could bake > Qwest a Juniper IPv6 cake and Sprint an OKC gig-e termination w/ dual > stack cake, that would be swell too. :) > > > Jack (why did I decide to live in Oklahoma again?) Because the weather is so exciting. -- Mike Andrews, W5EGO mikea at mikea.ath.cx Tired old sysadmin From andree+nanog at toonk.nl Thu Jan 27 19:28:20 2011 From: andree+nanog at toonk.nl (Andree Toonk) Date: Thu, 27 Jan 2011 17:28:20 -0800 Subject: Connectivity status for Egypt In-Reply-To: <AANLkTimUaNCRFhQqBTPM6Z=W7WUfU8fZUFHGjbqXGJsq@mail.gmail.com> References: <AANLkTimUaNCRFhQqBTPM6Z=W7WUfU8fZUFHGjbqXGJsq@mail.gmail.com> Message-ID: <4D421BB4.1000909@toonk.nl> Hi, Looking at the BGP announcements it seems that the problem started at around 22:28 UTC. Most of the Autonomous systems operating in Egypt are currently not announcing any or at least significantly less prefixes. The one exception seems to be AS20928 (Noor Data Networks). For more details also see: http://bgpmon.net/blog/?p=450 Cheers, Andree .-- My secret spy satellite informs me that at 11-01-27 3:47 PM Danny O'Brien wrote: > Around 2236 UCT, we lost all Internet connectivity with our contacts in > Egypt, and I'm hearing reports of (in declining order of confirmability): > > 1) Internet connectivity loss on major (broadband) ISPs > 2) No SMS > 4) Intermittent connectivity with smaller (dialup?) ISPs > 5) No mobile service in major cities -- Cairo, Alexandria > > The working assumption here is that the Egyptian government has made the > decision to shut down all external, and perhaps internal electronic > communication as a reaction to the ongoing protests in that country. > > If anyone can provide more details as to what they're seeing, the extent, > plus times and dates, it would be very useful. In moments like this there > are often many unconfirmed rumors: I'm seeking concrete reliable > confirmation which I can pass onto the press and those working to bring some > communications back up (if you have a ham radio license, there is some very > early work to provide emergency connectivity. Info at: > http://pastebin.com/fHHBqZ7Q ) > > Thank you, > From ljakab at ac.upc.edu Thu Jan 27 19:29:13 2011 From: ljakab at ac.upc.edu (=?UTF-8?B?TG9yw6FuZCBKYWthYg==?=) Date: Fri, 28 Jan 2011 02:29:13 +0100 Subject: Connectivity status for Egypt In-Reply-To: <AANLkTimUaNCRFhQqBTPM6Z=W7WUfU8fZUFHGjbqXGJsq@mail.gmail.com> References: <AANLkTimUaNCRFhQqBTPM6Z=W7WUfU8fZUFHGjbqXGJsq@mail.gmail.com> Message-ID: <4D421BE9.4050307@ac.upc.edu> On 01/28/2011 12:47 AM, Danny O'Brien wrote: > If anyone can provide more details as to what they're seeing, the extent, > plus times and dates, it would be very useful. In moments like this there > are often many unconfirmed rumors: I'm seeking concrete reliable > confirmation which I can pass onto the press and those working to bring some > communications back up (if you have a ham radio license, there is some very > early work to provide emergency connectivity. Info at: > http://pastebin.com/fHHBqZ7Q ) BGPmon has a quick analysis on the reachability of prefixes usually announced by the top 10 operators from Egypt: http://bgpmon.net/blog/?p=450 -Lorand Jakab From eosterweil at verisign.com Thu Jan 27 19:51:11 2011 From: eosterweil at verisign.com (Osterweil, Eric) Date: Thu, 27 Jan 2011 18:51:11 -0700 Subject: [arin-announce] ARIN Resource Certification Update In-Reply-To: <C96766D5.4C70%eosterweil@verisign.com> Message-ID: <C9676F1F.4D27%eosterweil@verisign.com> Sorry to be Johnny-come-lately to this... On 1/24/11 6:31 PM, "Randy Bush" <randy at psg.com> wrote: >> Right, I've heard the circular dependency arguments. So, are you >> suggesting the RPKI isn't going to rely on DNS at all? > > correct. it need not. Maybe I am misunderstand something here... Are (for example) the rsync processes going to use hard coded IPs? Are the SIAs and AIAs referenced by IP? > >> I'm of the belief RPKI should NOT be on the critical path, but instead >> focus on Internet number resource certification - are you suggesting >> otherwise? > > <channeling steve kent> > see the word 'certification'? guess where that leads. pki. add > resources and stir. Sounds like a loose definition of pki. Does DNSSEC count as such a loosely defined pki? :-P > >>> if the latter, then you have the problem that the dns trust model is >>> not congruent with the routing and address trust model. >> That could be easily fixed with trivial tweaks and transitive trust/ >> delegation graphs that are, I suspect. > > not bloody likely. the folk who sign dns zones are not even in the same > building as the folk who deal with address space. in large isps, not > even in the same town. Why does this stop the whole thing short? I think the people who run any as-yet-to-be-developed-and-deployed system don't sit in any building at all... Yet, right? :) Tbqh, I think I might be missing something important (so, please forgive my ignorance), but I don't see how (for example) admins of the SMTP infrastructure have trouble getting their MX records right in DNS zones... How are getting certs in there so much worse? Eric From eosterweil at verisign.com Thu Jan 27 19:51:38 2011 From: eosterweil at verisign.com (Osterweil, Eric) Date: Thu, 27 Jan 2011 18:51:38 -0700 Subject: [arin-announce] ARIN Resource Certification Update In-Reply-To: <C967670A.4C7E%eosterweil@verisign.com> Message-ID: <C9676F3A.4D28%eosterweil@verisign.com> On 1/25/11 7:04 AM, "Roland Dobbins" <rdobbins at arbor.net> wrote: > > > On Jan 25, 2011, at 9:52 PM, Joe Abley wrote: > >> If the DNS was as unreliable as those words suggested, nobody would use it. > > I see evidence of this unreliability every day, so I must respectfully > disagree. > > ;> > >> The reality is that everybody uses it. > > The reality is that they don't really have a choice, now, do they? > > ;> I think it's actually correct, and backs up Danny's point: it is very useful to be able to use a system that is: deployed, understood, operationally viable, etc. The risk of designing from scratch is best described by the lead time many other architectural changes have/are facing in being deployed. I think the bottom line is that this infrastructure will allow a security solution to reach deployment _much_ sooner than a green-field design. Eric From tony at lava.net Thu Jan 27 19:56:07 2011 From: tony at lava.net (Antonio Querubin) Date: Thu, 27 Jan 2011 15:56:07 -1000 (HST) Subject: What's the current state of major access networks in North America ipv6 delivery status? In-Reply-To: <D6F4DCE7-4021-41E7-9E89-42A8FAEEBB5F@delong.com> References: <BACEA722-744B-4773-89EF-03FBB933E1E4@delong.com> <C966C429.7FD46%john_brzozowski@cable.comcast.com> <AANLkTi=mjhRtHQYO1LD=9Ai2Tin+QCtdnNYkdYrf95z0@mail.gmail.com> <alpine.OSX.2.00.1101270306550.528@cust11794.lava.net> <D6F4DCE7-4021-41E7-9E89-42A8FAEEBB5F@delong.com> Message-ID: <alpine.OSX.2.00.1101271550001.152@cust11794.lava.net> On Thu, 27 Jan 2011, Owen DeLong wrote: > If they're routing a /64 to your gateway, you're all set. If they're not, > then, how are you getting the /64 in the first place? Bridged ethernet across the broadband provider network to the ISP router. Each customer gets a single /64 vlan to their residence. If the customer now wants more than one subnet, the ISP must now route additional prefixes to a customer's gateway. The customer can't just setup a router to break up the single /64 without the ISP carrying a route entry or the customer doing some kind of IPv6 NAT or proxy ND. If the ISP wont route additional prefixes, then the customer is forced to do the latter. From jbates at brightok.net Thu Jan 27 19:58:03 2011 From: jbates at brightok.net (Jack Bates) Date: Thu, 27 Jan 2011 19:58:03 -0600 Subject: [arin-announce] ARIN Resource Certification Update In-Reply-To: <C9676F3A.4D28%eosterweil@verisign.com> References: <C9676F3A.4D28%eosterweil@verisign.com> Message-ID: <4D4222AB.7060809@brightok.net> On 1/27/2011 7:51 PM, Osterweil, Eric wrote: > I think the bottom line is that this infrastructure will allow a security > solution to reach deployment_much_ sooner than a green-field design. Errr, yeah. See IPv6 deployment. Jack From randy at psg.com Thu Jan 27 19:59:51 2011 From: randy at psg.com (Randy Bush) Date: Fri, 28 Jan 2011 10:59:51 +0900 Subject: [arin-announce] ARIN Resource Certification Update In-Reply-To: <C96766D5.4C70%eosterweil@verisign.com> References: <m2d3nlpvcs.wl%randy@psg.com> <C96766D5.4C70%eosterweil@verisign.com> Message-ID: <m239odn5yg.wl%randy@psg.com> > Why does this stop the whole thing short? the devil is in the details and the trust. i am desperately open to other approaches. but work it out at the detailed level, not just a troll on nanog. i anxiously await your and danny's draft. randy From jbates at brightok.net Thu Jan 27 20:00:19 2011 From: jbates at brightok.net (Jack Bates) Date: Thu, 27 Jan 2011 20:00:19 -0600 Subject: What's the current state of major access networks in North America ipv6 delivery status? In-Reply-To: <alpine.OSX.2.00.1101271550001.152@cust11794.lava.net> References: <BACEA722-744B-4773-89EF-03FBB933E1E4@delong.com> <C966C429.7FD46%john_brzozowski@cable.comcast.com> <AANLkTi=mjhRtHQYO1LD=9Ai2Tin+QCtdnNYkdYrf95z0@mail.gmail.com> <alpine.OSX.2.00.1101270306550.528@cust11794.lava.net> <D6F4DCE7-4021-41E7-9E89-42A8FAEEBB5F@delong.com> <alpine.OSX.2.00.1101271550001.152@cust11794.lava.net> Message-ID: <4D422333.3030206@brightok.net> On 1/27/2011 7:56 PM, Antonio Querubin wrote: > If the ISP wont route additional prefixes, then the customer is forced > to do the latter. If the ISP wont route additional prefixes, they don't support IPv6. Jack From r.engehausen at gmail.com Thu Jan 27 20:07:40 2011 From: r.engehausen at gmail.com (Roy) Date: Thu, 27 Jan 2011 18:07:40 -0800 Subject: Connectivity status for Egypt In-Reply-To: <AANLkTimUaNCRFhQqBTPM6Z=W7WUfU8fZUFHGjbqXGJsq@mail.gmail.com> References: <AANLkTimUaNCRFhQqBTPM6Z=W7WUfU8fZUFHGjbqXGJsq@mail.gmail.com> Message-ID: <4D4224EC.1060604@gmail.com> On 1/27/2011 3:47 PM, Danny O'Brien wrote: > Around 2236 UCT, we lost all Internet connectivity with our contacts in > Egypt, and I'm hearing reports of (in declining order of confirmability): > > 1) Internet connectivity loss on major (broadband) ISPs > 2) No SMS > 4) Intermittent connectivity with smaller (dialup?) ISPs > 5) No mobile service in major cities -- Cairo, Alexandria > > The working assumption here is that the Egyptian government has made the > decision to shut down all external, and perhaps internal electronic > communication as a reaction to the ongoing protests in that country. > > If anyone can provide more details as to what they're seeing, the extent, > plus times and dates, it would be very useful. In moments like this there > are often many unconfirmed rumors: I'm seeking concrete reliable > confirmation which I can pass onto the press and those working to bring some > communications back up (if you have a ham radio license, there is some very > early work to provide emergency connectivity. Info at: > http://pastebin.com/fHHBqZ7Q ) > > Thank you, > I suggest that you confine your information to the press on what you know rather than speculation on the cause. "Never attribute to malice that which can be adequately explained by stupidity, but don't rule out malice" https://secure.wikimedia.org/wikipedia/en/wiki/Hanlon%27s_razor From fergdawgster at gmail.com Thu Jan 27 20:12:07 2011 From: fergdawgster at gmail.com (Paul Ferguson) Date: Thu, 27 Jan 2011 18:12:07 -0800 Subject: Connectivity status for Egypt In-Reply-To: <4D4224EC.1060604@gmail.com> References: <AANLkTimUaNCRFhQqBTPM6Z=W7WUfU8fZUFHGjbqXGJsq@mail.gmail.com> <4D4224EC.1060604@gmail.com> Message-ID: <AANLkTin+kr+KhguBxJKPNGJw+9oe6dq7S=dS2vonPMPF@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, Jan 27, 2011 at 6:07 PM, Roy <r.engehausen at gmail.com> wrote: > I suggest that you confine your information to the press on what you know > rather than speculation on the cause. > I think the earlier references to the BGPmon blog article is sufficient to illustrate a coordinated effort in "blacking out" connectivity - again: http://bgpmon.net/blog/?p=450 - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFNQiXuq1pz9mNUZTMRAkMWAJ4g+Jw0f0VqZyoybvbovskchvGo3ACdE0Ef N/FTQBDz4C1hnuwD/o6Ej+M= =Z4fv -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson ?Engineering Architecture for the Internet ?fergdawgster(at)gmail.com ?ferg's tech blog: http://fergdawg.blogspot.com/ From danny at spesh.com Thu Jan 27 20:47:53 2011 From: danny at spesh.com (Danny O'Brien) Date: Thu, 27 Jan 2011 18:47:53 -0800 Subject: Connectivity status for Egypt In-Reply-To: <4D4224EC.1060604@gmail.com> References: <AANLkTimUaNCRFhQqBTPM6Z=W7WUfU8fZUFHGjbqXGJsq@mail.gmail.com> <4D4224EC.1060604@gmail.com> Message-ID: <AANLkTimPmL0aKSFZL1Z6vat=o8zkPejEn6o9FmiDdWSj@mail.gmail.com> On Thu, Jan 27, 2011 at 6:07 PM, Roy <r.engehausen at gmail.com> wrote: > On 1/27/2011 3:47 PM, Danny O'Brien wrote: > >> Around 2236 UCT, we lost all Internet connectivity with our contacts in >> Egypt, and I'm hearing reports of (in declining order of confirmability): >> >> 1) Internet connectivity loss on major (broadband) ISPs >> 2) No SMS >> 4) Intermittent connectivity with smaller (dialup?) ISPs >> 5) No mobile service in major cities -- Cairo, Alexandria >> >> The working assumption here is that the Egyptian government has made the >> decision to shut down all external, and perhaps internal electronic >> communication as a reaction to the ongoing protests in that country. >> >> If anyone can provide more details as to what they're seeing, the extent, >> plus times and dates, it would be very useful. In moments like this there >> are often many unconfirmed rumors: I'm seeking concrete reliable >> confirmation which I can pass onto the press and those working to bring >> some >> communications back up (if you have a ham radio license, there is some >> very >> early work to provide emergency connectivity. Info at: >> http://pastebin.com/fHHBqZ7Q ) >> >> Thank you, >> >> I suggest that you confine your information to the press on what you know > rather than speculation on the cause. > > "Never attribute to malice that which can be adequately explained by > stupidity, but don't rule out malice" > > https://secure.wikimedia.org/wikipedia/en/wiki/Hanlon%27s_razor > > That is indeed one of the reasons why I'm seeking corroboration of the pattern of behaviour; at least to isolate and eliminate any alternative explanations. It would certainly be of operational interest (and certainly not unknown in the annals of historical "stupidity") if, say, a single fiber-cut or network upgrade was disrupting all of these different forms of communication simultaneously. On the other hand, there's only a finite number of imaginary backhoes you can conjure up before other explanations begin to trump Hanlon's razor. Right now, I think that http://bgpmon.net/blog/?p=450 explains (or at least illustrates) why we were getting reports of widespread but not universal Internet interruption. See also http://www.renesys.com/blog/2011/01/egypt-leaves-the-internet.shtml . I don't have a good explanation for the SMS problems, but lots of independent reports; I've yet to have any real confirmation of no mobile service, and lots of denials, so right now I'm going to assume that's untrue. If anyone can get explanations from their peers in the region, please pass them on (however incomplete or informal -- mail me directly if you'd rather not contribute to rumors or non-operational NANOG discussions). It's late at night in Egypt, and the biggest protests are planned for tomorrow. A great deal of life-critical systems will be under a great deal of stress during that time, and the interruptions in network connectivity would be extremely worrying. Thanks for checking this out, d. From jcurran at arin.net Thu Jan 27 21:00:59 2011 From: jcurran at arin.net (John Curran) Date: Fri, 28 Jan 2011 03:00:59 +0000 Subject: ARIN IRR Authentication (was: Re: AltDB?) In-Reply-To: <C6D38F6D-74D0-4E41-8A25-DE1816C860C4@arin.net> References: <59051.1294464800@nsa.vix.com> <00041A16-473F-4F96-93E8-E3CD3F83E1B2@virtualized.org> <70374.1294475040@nsa.vix.com> <m2aajb4vb7.wl%randy@psg.com> <m28vyv4uv0.wl%randy@psg.com> <5336.1294506839@nsa.vix.com> <Pine.LNX.4.61.1101081243291.5148@soloth.lewis.org> <AANLkTi=TDwNgT5WCx-sQ8NgAZ=NZWQDEWzd6+3CEW4st@mail.gmail.com> <AANLkTikCaadeah6Gub1EG43E0j_4N14Yipm+bjsyNzkw@mail.gmail.com> <m2fwt23glz.wl%randy@psg.com> <AANLkTim+_RqZLLG8BWQOnqgJ_EYDDz6tmKROq=ZGOqF=@mail.gmail.com> <1AAAEF13-B1AC-41CA-8B16-9985FD9E0EB2@arin.net> <4D2BAAE3.8080009@dougbarton.us> <BE650600-AD67-4A51-8FDF-ED3F368A6F06@arin.net> <4D2BFC80.2040305@dougbarton.us> <C6D38F6D-74D0-4E41-8A25-DE1816C860C4@arin.net> Message-ID: <EB7C0B14-A399-4572-85C9-8557F2C1BD2D@corp.arin.net> On Jan 11, 2011, at 9:14 AM, John Curran wrote: > As noted, we're now looking into how to fix the IRR authentication > situation and will report back asap. Based on the ARIN's IRR authentication thread a couple of weeks ago, there were suggestions placed into ARIN's ACSP process for changes to ARIN's IRR system. ARIN has looked at the integration issues involved and has scheduled an upgrade to the IRR system that will accept PGP and CRYPT-PW authentication as well as implementing notification support for both the mnt-nfy and notify fields by the end of August 2011. For further details, please look at: https://www.arin.net/participate/acsp/suggestions/2011-1.html https://www.arin.net/participate/acsp/suggestions/2011-2.html I'd like to thank everyone for bringing this situation to our attention, and will report back once this functionality is in place. Thanks! /John John Curran President and CEO ARIN From graham at g-rock.net Thu Jan 27 21:08:50 2011 From: graham at g-rock.net (Graham Wooden) Date: Thu, 27 Jan 2011 21:08:50 -0600 Subject: Collos in Memphis, TN and Louisville, KY? Message-ID: <C9678F62.2B0E0%graham@g-rock.net> Hi folks, Can anyone recommend any collo's in both Memphis TN and Louisville, KY? Preferably in their respective downtown areas? Thanks mucho, -graham From scubacuda at gmail.com Thu Jan 27 22:03:42 2011 From: scubacuda at gmail.com (Rogelio) Date: Thu, 27 Jan 2011 23:03:42 -0500 Subject: best PCRF for pre-paid mobile solutions? Message-ID: <AANLkTi=96u-4a-RRxDU5fWJm+BJ+QAg8ESFD8GtWYEw_@mail.gmail.com> I am researching some PCRF solutions for some work I am doing with non-US operators, and I am looking for features that work well in pre-paid mobile environments, particularly ones that want to cap or charge 3G and WiFi at different rates / levels. Any suggestions or contacts? -- Also on LinkedIn?? Feel free to connect if you too are an open networker: scubacuda at gmail.com From scubacuda at gmail.com Thu Jan 27 22:18:19 2011 From: scubacuda at gmail.com (Rogelio) Date: Thu, 27 Jan 2011 23:18:19 -0500 Subject: overview of RAN solutions? Message-ID: <AANLkTi=u+c005piSXH4nHnudKixK7hCDhGB-SGNFFVMF@mail.gmail.com> I am wrapping my mind around the myriad of RAN solutions out there, and I would appreciate it if someone had a good overview of the subject or could direct me to new vendors worth investigating. So far, I see ones that are designed to (a) increase coverage, (b) increase capacity, or (c) do some combo of (a) and (b). Some solutions suck in the donor signal (antennas on top of roof) and then blow it back indoors on various frequencies. A good example of this is something like Axell, which doesn't appear to add much capacity, just stretch the existing uplink's capacity by amplifying the signal indoors. Other solutions (IP-RAN, E-RAN, etc) have an Internet / IP component and allow for all sorts of cool things (synchronization between units for soft handoff, etc). SpiderCloud seems to be a good play here. Then there are other niche plays that don't do everything, but seem to be good enough for various applications, like SMS texting. If I remember right, IPAccess did this sort of thing for schools (which is perfect for emergencies). Any others I should look into? I'm primarily interested in carrier-grade ones... -- Also on LinkedIn?? Feel free to connect if you too are an open networker: scubacuda at gmail.com From morrowc.lists at gmail.com Thu Jan 27 22:35:35 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 27 Jan 2011 23:35:35 -0500 Subject: Found: Who is responsible for no more IP addresses In-Reply-To: <F05D77A9631CAE4097F7B69095F1B06F02E2C2@EX02.drtel.lan> References: <alpine.LRH.2.00.1101271319090.15061@efes.iucc.ac.il> <4D4163ED.1060201@foobar.org> <22FB1A8D-90B3-49F1-BFD8-E581AAE1C808@delong.com> <F05D77A9631CAE4097F7B69095F1B06F02E201@EX02.drtel.lan> <AANLkTinc56Le67N=2Z0nfBC627CE06mgqmma36ntJEAx@mail.gmail.com> <F05D77A9631CAE4097F7B69095F1B06F02E2C2@EX02.drtel.lan> Message-ID: <AANLkTikRnPcsoq14-EtWVxVPiijVHxwEgZdMYtSjgNms@mail.gmail.com> On Thu, Jan 27, 2011 at 1:34 PM, Brian Johnson <bjohnson at drtel.com> wrote: > I really wish people would keep their personal/political bias outside the list unless it is specific and relevant. What other "main-stream" news organization has made any reports on this issue? > > To be clear, FOX screwed this up big time, but that doesn't mean we all need to get out our personal/political pitchforks and run them out of town. Take your Ritalin. :) not to beat a dead horse, but... I hadn't realized i said anything political in my statement. thanks, and as another frequent poster says: "Drive slow!" -chris From nanog at jima.tk Thu Jan 27 23:27:52 2011 From: nanog at jima.tk (Jima) Date: Thu, 27 Jan 2011 23:27:52 -0600 Subject: Found: Who is responsible for no more IP addresses In-Reply-To: <4D4163ED.1060201@foobar.org> References: <alpine.LRH.2.00.1101271319090.15061@efes.iucc.ac.il> <4D4163ED.1060201@foobar.org> Message-ID: <4D4253D8.5060608@jima.tk> On 1/27/2011 6:24 AM, Nick Hilliard wrote: > On 27/01/2011 11:21, Hank Nussbacher wrote: >> "I thought it was an experiment and I thought that 4.3 billion IPv4 >> addresses would be enough to do an experiment," Cerf was quoted as >> saying, >> adding it is his "fault" that "we were running out of the addresses."" > > Fortunately, web developers have fixed the problem according to Fox news: > > http://www.foxnews.com/scitech/2011/01/26/internet-run-ip-addresses-happens-anyones-guess/ > > > "Web developers have tried to compensate for this problem by creating > IPv6 -- a system that recognizes six-digit IP addresses rather than > four-digit ones." > > It will be difficult initially, though: > > "But IPv6 isn't backwards-compatible with IPv4, meaning that it's not > able to read most content that operates on an IPv4 system. At best, the > user experience will be clunky and slow. At worst, instead of a webpage, > all users will be able to view is a blank page." > > I'm glad Fox has cleared all this up for us. Actually, Fox News got the article -- glaring technical inaccuracies and all -- from www.news.com.au: http://www.news.com.au/technology/the-internet-has-run-out-of-ip-addresses-and-what-happens-after-that-is-anyones-guess/story-e6frfro0-1225995086627 Of course, you won't find (most of) the inaccuracies there now; they edited the article after the fact (and after Fox copied them). The only proof I had for myself reading it later were my logged peanut-gallery comments in #ipv6: 14:03 < jima> "Web developers have tried to compensate for this problem by creating IPv6 - a system which recognises six-digit IP addresses." 14:04 < jima> web developers? *wince* six-digit IP addresses? *cringe* 14:05 < jima> i'm gonna give mr. hutson a piece of my mind! ...if i could figure out who he is. :-\ After the edit, I did snark via Twitter, "Media Trolling 101: 1. Write #IPv6 story w/ glaring tech. inaccuracies. 2. Get story picked up by FoxNews. 3. Fix inaccuracies. 4. Laugh." ( http://twitter.com/neojima/status/30644080144818176 ) So, yes, while this was an example of news coverage gone terribly wrong, we can't blame Fox alone. (There is, however, such a thing as "fact-checking," but that's a secondary point.) Jima From labovit at gmail.com Thu Jan 27 23:36:41 2011 From: labovit at gmail.com (Craig Labovitz) Date: Fri, 28 Jan 2011 00:36:41 -0500 Subject: Connectivity status for Egypt In-Reply-To: <4D421BB4.1000909@toonk.nl> References: <AANLkTimUaNCRFhQqBTPM6Z=W7WUfU8fZUFHGjbqXGJsq@mail.gmail.com> <4D421BB4.1000909@toonk.nl> Message-ID: <9CCC7D46-D578-4BA0-893C-BAE0D170253B@gmail.com> And to add to this thread, an graph of Egyptian Internet traffic across a large number of geographically / topologically diverse providers yesterday (Jan 27): http://farm6.static.flickr.com/5291/5395027368_7d97b74c0b_b.jpg Traffic drops to a handful of megabits following the withdrawal of most Egyptian ISP BGP routes. - Craig On Jan 27, 2011, at 8:28 PM, Andree Toonk wrote: > Hi, > > Looking at the BGP announcements it seems that the problem started at around 22:28 UTC. > > Most of the Autonomous systems operating in Egypt are currently not announcing any or at least significantly less prefixes. > The one exception seems to be AS20928 (Noor Data Networks). > > For more details also see: http://bgpmon.net/blog/?p=450 > > Cheers, > Andree ------------------------ Craig Labovitz | Chief Scientist, Arbor Networks http://www.monkey.org/~labovit From owen at delong.com Thu Jan 27 23:48:26 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 27 Jan 2011 21:48:26 -0800 Subject: Found: Who is responsible for no more IP addresses In-Reply-To: <2966867.2746.1296155181722.JavaMail.root@benjamin.baylink.com> References: <2966867.2746.1296155181722.JavaMail.root@benjamin.baylink.com> Message-ID: <9203B885-646B-43D6-94B9-69C648FCF5A8@delong.com> On Jan 27, 2011, at 11:06 AM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Brian Johnson" <bjohnson at drtel.com> > >> I really wish people would keep their personal/political bias outside >> the list unless it is specific and relevant. What other "main-stream" >> news organization has made any reports on this issue? >> >> To be clear, FOX screwed this up big time, but that doesn't mean we >> all need to get out our personal/political pitchforks and run them out >> of town. Take your Ritalin. :-) > > Fox didn't screw up, for a change, and Vint's quote appears in many > other news sources. Apparently, I'm the only one on Nanog who knows > about this new thing called The Google. :-) > I don't think Vint's quote was the part where we thought Fox screwed up. "Web developers have it fixed" (or something to that effect) on the other hand... > Thinking that Fox "News" is not a reputable news source is not, indeed, > an opinion attributable *solely* to non-Republicans, and indeed, it's easy > to prove in a documentary, non-partisan fashion. > Yep. Owen From jra at baylink.com Thu Jan 27 23:50:41 2011 From: jra at baylink.com (Jay Ashworth) Date: Fri, 28 Jan 2011 00:50:41 -0500 (EST) Subject: Found: Who is responsible for no more IP addresses In-Reply-To: <9203B885-646B-43D6-94B9-69C648FCF5A8@delong.com> Message-ID: <8221039.3009.1296193840975.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Owen DeLong" <owen at delong.com> > > Fox didn't screw up, for a change, and Vint's quote appears in many > > other news sources. Apparently, I'm the only one on Nanog who knows > > about this new thing called The Google. :-) > > > I don't think Vint's quote was the part where we thought Fox screwed > up. Yes; that was cleared up for me. :-) -- jra From owen at delong.com Thu Jan 27 23:45:55 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 27 Jan 2011 21:45:55 -0800 Subject: Found: Who is responsible for no more IP addresses In-Reply-To: <F05D77A9631CAE4097F7B69095F1B06F02E2C2@EX02.drtel.lan> References: <alpine.LRH.2.00.1101271319090.15061@efes.iucc.ac.il> <4D4163ED.1060201@foobar.org> <22FB1A8D-90B3-49F1-BFD8-E581AAE1C808@delong.com> <F05D77A9631CAE4097F7B69095F1B06F02E201@EX02.drtel.lan> <AANLkTinc56Le67N=2Z0nfBC627CE06mgqmma36ntJEAx@mail.gmail.com> <F05D77A9631CAE4097F7B69095F1B06F02E2C2@EX02.drtel.lan> Message-ID: <73D55B3B-1E9C-4C20-AC1A-4283CD229D0E@delong.com> On Jan 27, 2011, at 10:34 AM, Brian Johnson wrote: > I really wish people would keep their personal/political bias outside the list unless it is specific and relevant. What other "main-stream" news organization has made any reports on this issue? > CNN, which actually got it right several months ago. >> >> Owen From owen at delong.com Thu Jan 27 23:51:03 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 27 Jan 2011 21:51:03 -0800 Subject: Another v6 question In-Reply-To: <alpine.DEB.1.10.1101272030321.13151@uplift.swm.pp.se> References: <AANLkTikEZVYFz+bx7MVXeht_qNnpkUEC_Mx0qhE6J9SR@mail.gmail.com> <55E7EC47-C434-4DF7-B92A-8EBC24133C53@delong.com> <AANLkTi=soS+LQoR3JYJxE8N3o9JYoxrL2dvzHZ+e5Geb@mail.gmail.com> <4F209412-3C3B-4CB6-8EB7-A25ABD1B9DBA@delong.com> <AANLkTinqipvQD-gSt1BZ5FcPT2krNhwqO5dExWrM=muG@mail.gmail.com> <67827BB1-BF59-45AF-842F-B9E1AD7A1F87@delong.com> <A5E4AFBB-92C6-464E-AAAB-07B69ECD5214@puck.nether.net> <alpine.DEB.1.10.1101272030321.13151@uplift.swm.pp.se> Message-ID: <A942C766-5018-451E-B136-6CBA67EEC03F@delong.com> On Jan 27, 2011, at 11:32 AM, Mikael Abrahamsson wrote: > On Thu, 27 Jan 2011, Jared Mauch wrote: > >> The ipv6 zealots talking about anything but a /64 for end-site are talking about a "business class" service. Even with my static IPs at home, I have no need for more than a single /64 to be used in my wildest dreams. I could live with ~256 ips for the future. I consider my tech density "above-average". > > I don't agree at all. I have 3 /64s in use in my home already. I could fairly easily go down to 2, but I definitely need at least 2. > > I don't want to handle people like me differently, thus /56 for all residential customers makes a lot of sense. I see no downside. > > -- > Mikael Abrahamsson email: swmike at swm.pp.se The downside is that it doesn't provide enough bits for certain kinds of auto-topology management that are being considered by CE vendors. I highly recommend /48 instead. Owen From John_Brzozowski at Cable.Comcast.com Fri Jan 28 00:07:00 2011 From: John_Brzozowski at Cable.Comcast.com (Brzozowski, John) Date: Fri, 28 Jan 2011 06:07:00 +0000 Subject: What's the current state of major access networks in North America ipv6 delivery status? In-Reply-To: <20110127140319.281E993486C@drugs.dv.isc.org> Message-ID: <C96781BF.804FB%john_brzozowski@cable.comcast.com> Mark, Thanks for the insight, however, from an operators point of view one of the benefits of 6rd is the simplified deployment model. The statement below regarding how to explicitly provision 6rd CEs is some what inaccurate. This provisioning for some deployments of 6rd could carry some complexities which should not be trivialized. "This really shouldn't be to hard for the provisioning systems to handle." There is an assumption being made that the entire DHCP infrastructure can support the transmission of 6rd DHCP options and can make those decisions per CE or subscriber. John ========================================= John Jason Brzozowski Comcast Cable e) mailto:john_brzozowski at cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net ========================================= On 1/27/11 9:03 AM, "Mark Andrews" <marka at isc.org> wrote: > >In message <C966C429.7FD46%john_brzozowski at cable.comcast.com>, >"Brzozowski, John" wri >tes: >> In order to deploy /56 to end users would require an IPv6 /24 be >>dedicated >> to 6rd, /48s would require a dedicated IPv6 /16. This assumes an >>operator >> wants/needs to provide IPv6 via 6rd to end users where their IPv4 >>address >> is fully unique. There is quite a bit of IPv6 address space that does >>not >> gets utilized in this model. > >No it doesn't require /16 to deploy 6rd with /48's. It does however >require the ISP to do more than say "this is our 6rd prefix" and >shove all 32 bits of IPv4 address into the delegated prefix. The >moment the ISP needs to re-use IPv4 addresses for customers the >simple "this is our 6rd prefix" fails to work. > >If an ISP has 34/8 and 35.0/9 then it needs two blocks of IPv6 >addresses on a /24 and one a /25, which would be used like this: > > [P1 24 bits][low 24 bits][subnet 16 bits][host 64 bits] > [P2 25 bits][low 23 bits][subnet 16 bits][host 64 bits] > >The 6rd routers for P1 know that P1 means the top 8 bits are 34. >The 6rd routers for P2 know that P2 means the top 9 bits are 35.0. > >The DHCP server for subnets in 34/8 are configured to hand out 6rd >prefix info for P1 (6rdPrefixLen=24, IPv4MaskLen=8). Similarly >35.0/9 and P2 (6rdPrefixLen=25, IPv4Masklen=9). This really shouldn't >be to hard for the provisioning systems to handle. > >If the ISP was using 10/8 twice to connect to its customers then >it would need two /24's (P1 and P2). P1 and P2 would both have >6rdPrefixLen=24, IPv4MaskLen=8. > >See RFC 5969 (RFC 5569 describes what Free originally did). > >> The routers we are using as part of the trials only support /64 as such >>we >> are using an IPv6 /32. >> >> It is also important that operators plan for the ability to delegate >> prefixes that are shorter than a /64. There are several cases that we >> have seen where the router can only make use of a /64. This is better >> than nothing when referring to legacy devices that have been able to >> introduce some support for IPv6 and would have otherwise been IPv4 only >> devices. >> >> John >> >>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >>3D= >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> John Jason Brzozowski >> Comcast Cable >> e) mailto:john_brzozowski at cable.comcast.com >> o) 609-377-6594 >> m) 484-962-0060 >> w) http://www.comcast6.net >> >>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >>3D= >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> >> >> >> On 1/26/11 5:02 PM, "Owen DeLong" <owen at delong.com> wrote: >> >> > >> >On Jan 26, 2011, at 1:52 PM, Charles N Wyble wrote: >> > >> >> -----BEGIN PGP SIGNED MESSAGE----- >> >> Hash: SHA1 >> >>=20 >> >>=20 >> >> Is anyone tracking the major consumer/business class access networks >> >> delivery of ipv6 in North America? >> >>=20 >> >> I'm on ATT DSL. It looks like they want to use 6rd? I've only briefly >> >> looked into 6rd. Is this a dead end path/giant hack? >> >>=20 >> >>=20 >> >>>>https://sites.google.com/site/ipv6implementors/2010/agenda/05_Chase_Goo >>>>gl >> >>econf-BroadbandtransitiontoIPv6using6rd.pdf?attredirects=3D0 >> >>=20 >> >It's a fairly ugly way to deliver IPv6, but, as transition technologies >> >go, it's the least dead-end of the options. >> > >> >It at least provides essentially native dual stack environment. The >> >only difference is that your IPv6 access is via a tunnel. You'll >>probably >> >be limited to a /56 or less over 6rd, unfortunately, but, because of >>the >> >awful way 6rd consumes addresses, handing out /48s would be >> >utterly impractical. Free.fr stuck their customers with /60s, which is >> >hopefully a very temporary situation. >> > >> >>=20 >> >> I spoke with impulse.net last year, which appears to serve large >> >> portions of the AT&T cable plant in Southern California. They were >> >> willing to offer native ipv6. Not sure how (one /64, a /48) etc. >> >>=20 >> >You should definitely push your providers to give you a /48 if >> >possible. If /56 or worse /60 or worst of all, /64 become widespread >> >trends, it may significantly impact, delay, or even prevent innovations >> >in the end-user networking/consumer electronics markets. >> > >> >Owen >> > >> > >> >> >-- >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 Fri Jan 28 00:26:35 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 27 Jan 2011 22:26:35 -0800 Subject: What's the current state of major access networks in North America ipv6 delivery status? In-Reply-To: <alpine.OSX.2.00.1101271550001.152@cust11794.lava.net> References: <BACEA722-744B-4773-89EF-03FBB933E1E4@delong.com> <C966C429.7FD46%john_brzozowski@cable.comcast.com> <AANLkTi=mjhRtHQYO1LD=9Ai2Tin+QCtdnNYkdYrf95z0@mail.gmail.com> <alpine.OSX.2.00.1101270306550.528@cust11794.lava.net> <D6F4DCE7-4021-41E7-9E89-42A8FAEEBB5F@delong.com> <alpine.OSX.2.00.1101271550001.152@cust11794.lava.net> Message-ID: <60DF6149-7C9C-434C-9481-C1BC57F1F7B7@delong.com> On Jan 27, 2011, at 5:56 PM, Antonio Querubin wrote: > On Thu, 27 Jan 2011, Owen DeLong wrote: > >> If they're routing a /64 to your gateway, you're all set. If they're not, >> then, how are you getting the /64 in the first place? > > Bridged ethernet across the broadband provider network to the ISP router. Each customer gets a single /64 vlan to their residence. If the customer now wants more than one subnet, the ISP must now route additional prefixes to a customer's gateway. The customer can't just setup a router to break up the single /64 without the ISP carrying a route entry or the customer doing some kind of IPv6 NAT or proxy ND. If the ISP wont route additional prefixes, then the customer is forced to do the latter. If you need more than one prefix, then, they should route you a /48 instead of a /64. If they won't, I strongly encourage you to switch providers, or, get a free tunnel from http://tunnelbroker.net and use that. Owen From owen at delong.com Fri Jan 28 00:32:15 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 27 Jan 2011 22:32:15 -0800 Subject: test-ipv6.com In-Reply-To: <4D4214E3.7040407@brightok.net> References: <alpine.BSF.2.00.1101271448000.15852@goat.gigo.com> <20110128001632.CF4E1938AFA@drugs.dv.isc.org> <FD0585DC-3869-4A90-8BFA-75D130C6EDE7@internode.com.au> <4D4214E3.7040407@brightok.net> Message-ID: <9FA6BF6F-4D8D-434C-935C-600201997530@delong.com> On Jan 27, 2011, at 4:59 PM, Jack Bates wrote: > On 1/27/2011 6:25 PM, Matthew Moyle-Croft wrote: >> >> Anyone for peering cake? >> > > Yeah, Google, HE, Cogent, Sprint, Qwest, and Level3 all need peering cakes (as I'm pretty sure there is no participant in that list which is connected to every other participant in that list). If you could bake Qwest a Juniper IPv6 cake and Sprint an OKC gig-e termination w/ dual stack cake, that would be swell too. :) > > > Jack (why did I decide to live in Oklahoma again?) HE would be glad to peer with each and every member of that list and has made every attempt to do so, including baking a cake for Cogent. We do peer with some members of that list and appreciate their more enlightened approach to a better internet for everyone. We hope others will follow suit. If you are interested in peering IPv6 with Hurricane Electric, please contact me or peering at he.net. Owen From swmike at swm.pp.se Fri Jan 28 00:41:04 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 28 Jan 2011 07:41:04 +0100 (CET) Subject: What's the current state of major access networks in North America ipv6 delivery status? In-Reply-To: <alpine.OSX.2.00.1101271550001.152@cust11794.lava.net> References: <BACEA722-744B-4773-89EF-03FBB933E1E4@delong.com> <C966C429.7FD46%john_brzozowski@cable.comcast.com> <AANLkTi=mjhRtHQYO1LD=9Ai2Tin+QCtdnNYkdYrf95z0@mail.gmail.com> <alpine.OSX.2.00.1101270306550.528@cust11794.lava.net> <D6F4DCE7-4021-41E7-9E89-42A8FAEEBB5F@delong.com> <alpine.OSX.2.00.1101271550001.152@cust11794.lava.net> Message-ID: <alpine.DEB.1.10.1101280737090.13151@uplift.swm.pp.se> On Thu, 27 Jan 2011, Antonio Querubin wrote: > Bridged ethernet across the broadband provider network to the ISP > router. Each customer gets a single /64 vlan to their residence. If the > customer now wants more than one subnet, the ISP must now route > additional prefixes to a customer's gateway. The customer can't just > setup a router to break up the single /64 without the ISP carrying a > route entry or the customer doing some kind of IPv6 NAT or proxy ND. > If the ISP wont route additional prefixes, then the customer is forced > to do the latter. You do NOT want to keep state for all the devices in the customer residence. Your ND table will be enormous. We already have problems with ARP on our larger residential aggregation routers, I don't even want to think about what it'd look like with 10+ devices in peoples homes in those /64:s, each perhaps using multiple IPs. Your ND traffic will be enormous. It's much cleaner to require a CPE at he customer prem, run LL only between CPE and PE, DHCPv6-PD a /56 or larger, and now you're done with it. No need to keep state for customer home devices, you just have to handle the CPE. Minimal TCAM usage, minimal state handling. -- Mikael Abrahamsson email: swmike at swm.pp.se From r.engehausen at gmail.com Fri Jan 28 00:49:01 2011 From: r.engehausen at gmail.com (Roy) Date: Thu, 27 Jan 2011 22:49:01 -0800 Subject: Connectivity status for Egypt In-Reply-To: <9CCC7D46-D578-4BA0-893C-BAE0D170253B@gmail.com> References: <AANLkTimUaNCRFhQqBTPM6Z=W7WUfU8fZUFHGjbqXGJsq@mail.gmail.com> <4D421BB4.1000909@toonk.nl> <9CCC7D46-D578-4BA0-893C-BAE0D170253B@gmail.com> Message-ID: <4D4266DD.7000906@gmail.com> On 1/27/2011 9:36 PM, Craig Labovitz wrote: > > And to add to this thread, an graph of Egyptian Internet traffic across a large number of geographically / topologically diverse providers yesterday (Jan 27): > > http://farm6.static.flickr.com/5291/5395027368_7d97b74c0b_b.jpg > > Traffic drops to a handful of megabits following the withdrawal of most Egyptian ISP BGP routes. > > - Craig > I don't think there is any doubt in anyone's mind on the fact that the service is being interrupted somehow. The question is why. Being an old fart, I tend to dig up stories that explain my point. Almost two years ago, I woke up one morning and got on my trusty computer to read email, etc. I couldn't reach the Internet. My microwave to my ISP was up but their uplinks were either down or just went a few hops and died. I tried to dial in but that just got a fast busy signal. Calls to the ISP help desks involved via my land line also got fast busy or "your call could not be completed". Now getting a bit worried, I dug out my cellphone and had no bars. Usually I got all of them here. I immediately thought of 9/11 and was speculating that some terrorist attack had struck. I quickly went to the family room and powered up the satellite TV. Everything seemed normal. No attacks. You probably know the rest. 30 miles away in San Jose, someone went down a manhole and severed some fiber cables. It turns out that all the services involved (AT&T, Verizon, Qwest, Cogent, etc) all were in that manhole. Almost 200,000 people had no communications for most of the day. Moral of the story: Separate facts from assumptions and guesses. I did some Google searches and that region has had large scale disruptions in the past. Several cables follow the same path to the Suez canal and were hit. https://secure.wikimedia.org/wikipedia/en/wiki/2008_submarine_cable_disruption From gbonser at seven.com Fri Jan 28 00:58:38 2011 From: gbonser at seven.com (George Bonser) Date: Thu, 27 Jan 2011 22:58:38 -0800 Subject: Found: Who is responsible for no more IP addresses In-Reply-To: <8221039.3009.1296193840975.JavaMail.root@benjamin.baylink.com> References: <9203B885-646B-43D6-94B9-69C648FCF5A8@delong.com> <8221039.3009.1296193840975.JavaMail.root@benjamin.baylink.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC136B8@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Jay Ashworth [mailto:jra at baylink.com] > Sent: Thursday, January 27, 2011 9:51 PM > To: NANOG > Subject: Re: Found: Who is responsible for no more IP addresses > > ----- Original Message ----- > > From: "Owen DeLong" <owen at delong.com> > > > > Fox didn't screw up, for a change, and Vint's quote appears in many > > > other news sources. Apparently, I'm the only one on Nanog who knows > > > about this new thing called The Google. :-) > > > > > I don't think Vint's quote was the part where we thought Fox screwed > > up. > > Yes; that was cleared up for me. :-) > -- jra It isn't even a Fox News story, it comes from a News Corp affiliate by Claire Connelly in Australia. The original is here: http://www.news.com.au/technology/the-internet-has-run-out-of-ip-addresses-and-what-happens-after-that-is-anyones-guess/story-e6frfro0-1225995086627 Take a look at the stories, they run AP content just like everyone else along with articles from affiliates around the world. From joelja at bogus.com Fri Jan 28 01:39:53 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Thu, 27 Jan 2011 23:39:53 -0800 Subject: Connectivity status for Egypt In-Reply-To: <4D4266DD.7000906@gmail.com> References: <AANLkTimUaNCRFhQqBTPM6Z=W7WUfU8fZUFHGjbqXGJsq@mail.gmail.com> <4D421BB4.1000909@toonk.nl> <9CCC7D46-D578-4BA0-893C-BAE0D170253B@gmail.com> <4D4266DD.7000906@gmail.com> Message-ID: <4D4272C9.2080406@bogus.com> On 1/27/11 10:49 PM, Roy wrote: > On 1/27/2011 9:36 PM, Craig Labovitz wrote: >> >> And to add to this thread, an graph of Egyptian Internet traffic >> across a large number of geographically / topologically diverse >> providers yesterday (Jan 27): >> >> http://farm6.static.flickr.com/5291/5395027368_7d97b74c0b_b.jpg >> >> Traffic drops to a handful of megabits following the withdrawal of >> most Egyptian ISP BGP routes. >> >> - Craig >> > > I don't think there is any doubt in anyone's mind on the fact that the > service is being interrupted somehow. The question is why. The BBC doesn't seem to have too much trouble coming to a conclusion as to why. http://www.bbc.co.uk/news/world-middle-east-12303564 internal communications are disrupted as are external commucations. from renesys http://www.renesys.com/blog/2011/01/egypt-leaves-the-internet.shtml At 22:34 UTC (00:34am local time), Renesys observed the virtually simultaneous withdrawal of all routes to Egyptian networks in the Internet's global routing table. Approximately 3,500 individual BGP routes were withdrawn, leaving no valid paths by which the rest of the world could continue to exchange Internet traffic with Egypt's service providers. <snip> > Moral of the story: Separate facts from assumptions and guesses. I did > some Google searches and that region has had large scale disruptions in > the past. Several cables follow the same path to the Suez canal and > were hit. my links through the region are all fine, but they don't jump off the cable in egypt just pass through. > https://secure.wikimedia.org/wikipedia/en/wiki/2008_submarine_cable_disruption > > > From marka at isc.org Fri Jan 28 01:42:36 2011 From: marka at isc.org (Mark Andrews) Date: Fri, 28 Jan 2011 18:42:36 +1100 Subject: What's the current state of major access networks in North America ipv6 delivery status? In-Reply-To: Your message of "Fri, 28 Jan 2011 06:07:00 -0000." <C96781BF.804FB%john_brzozowski@cable.comcast.com> References: <C96781BF.804FB%john_brzozowski@cable.comcast.com> Message-ID: <20110128074236.554B59422FB@drugs.dv.isc.org> In message <C96781BF.804FB%john_brzozowski at cable.comcast.com>, "Brzozowski, Joh n" writes: > Mark, > > Thanks for the insight, however, from an operators point of view one of > the benefits of 6rd is the simplified deployment model. The statement > below regarding how to explicitly provision 6rd CEs is some what > inaccurate. This provisioning for some deployments of 6rd could carry > some complexities which should not be trivialized. I'm not trying to trivialize the issue. I think that being able to have the same prefix layout for ULA and PA addresses is useful. I also think homes having /48 are useful. There was also the claim that 6rd *required* a /16 to deliver to deliver /48's to the customers. That claim is demonstrable false. It is not a protocol requirement. It is the result of a choice being made to deploy a single 6rd domain covering all of IPv4 space. There are alternatives and they should be presented. * 6rd domain covering the whole of IPv4 space. * 6rd domain per /8 or similar block the ISP has addresses in. * 6rd domain per block allocated from the RIR's rounded up to the closest power of 2. * 6rd domain per pop. * 6rd enabled at client request (may require putting the client in a appropriate address pool). Each of these has tradeoffs in complexity, delegated prefix size and address wastage. I was aiming for a relatively low level of complexity with the 6rd per RIR allocation and a /48 delegated prefixes. That the 6rd domains would just be a table that is referred to when generating the final configurations for the DHCP servers as it is a property of the IPv4 address to be returned and not the customer. > "This really shouldn't be to hard for the provisioning systems to handle." > > There is an assumption being made that the entire DHCP infrastructure can > support the transmission of 6rd DHCP options and can make those decisions > per CE or subscriber. > > John > ========================== > ================ > John Jason Brzozowski > Comcast Cable > e) mailto:john_brzozowski at cable.comcast.com > o) 609-377-6594 > m) 484-962-0060 > w) http://www.comcast6.net > ========================== > ================ > > > > > On 1/27/11 9:03 AM, "Mark Andrews" <marka at isc.org> wrote: > > > > >In message <C966C429.7FD46%john_brzozowski at cable.comcast.com>, > >"Brzozowski, John" wri > >tes: > >> In order to deploy /56 to end users would require an IPv6 /24 be > >>dedicated > >> to 6rd, /48s would require a dedicated IPv6 /16. This assumes an > >>operator > >> wants/needs to provide IPv6 via 6rd to end users where their IPv4 > >>address > >> is fully unique. There is quite a bit of IPv6 address space that does > >>not > >> gets utilized in this model. > > > >No it doesn't require /16 to deploy 6rd with /48's. It does however > >require the ISP to do more than say "this is our 6rd prefix" and > >shove all 32 bits of IPv4 address into the delegated prefix. The > >moment the ISP needs to re-use IPv4 addresses for customers the > >simple "this is our 6rd prefix" fails to work. > > > >If an ISP has 34/8 and 35.0/9 then it needs two blocks of IPv6 > >addresses on a /24 and one a /25, which would be used like this: > > > > [P1 24 bits][low 24 bits][subnet 16 bits][host 64 bits] > > [P2 25 bits][low 23 bits][subnet 16 bits][host 64 bits] > > > >The 6rd routers for P1 know that P1 means the top 8 bits are 34. > >The 6rd routers for P2 know that P2 means the top 9 bits are 35.0. > > > >The DHCP server for subnets in 34/8 are configured to hand out 6rd > >prefix info for P1 (6rdPrefixLen=24, IPv4MaskLen=8). Similarly > >35.0/9 and P2 (6rdPrefixLen=25, IPv4Masklen=9). This really shouldn't > >be to hard for the provisioning systems to handle. > > > >If the ISP was using 10/8 twice to connect to its customers then > >it would need two /24's (P1 and P2). P1 and P2 would both have > >6rdPrefixLen=24, IPv4MaskLen=8. > > > >See RFC 5969 (RFC 5569 describes what Free originally did). > > > >> The routers we are using as part of the trials only support /64 as such > >>we > >> are using an IPv6 /32. > >>=20 > >> It is also important that operators plan for the ability to delegate > >> prefixes that are shorter than a /64. There are several cases that we > >> have seen where the router can only make use of a /64. This is better > >> than nothing when referring to legacy devices that have been able to > >> introduce some support for IPv6 and would have otherwise been IPv4 only > >> devices. > >>=20 > >> John > >>=20 > >>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D== > 3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > >>3D= > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > =3D=3D > >> John Jason Brzozowski > >> Comcast Cable > >> e) mailto:john_brzozowski at cable.comcast.com > >> o) 609-377-6594 > >> m) 484-962-0060 > >> w) http://www.comcast6.net > >>=20 > >>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D== > 3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > >>3D= > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > =3D=3D > >>=20 > >>=20 > >>=20 > >>=20 > >> On 1/26/11 5:02 PM, "Owen DeLong" <owen at delong.com> wrote: > >>=20 > >> > > >> >On Jan 26, 2011, at 1:52 PM, Charles N Wyble wrote: > >> > > >> >> -----BEGIN PGP SIGNED MESSAGE----- > >> >> Hash: SHA1 > >> >>=20 > >> >>=20 > >> >> Is anyone tracking the major consumer/business class access networks > >> >> delivery of ipv6 in North America? > >> >>=20 > >> >> I'm on ATT DSL. It looks like they want to use 6rd? I've only briefly > >> >> looked into 6rd. Is this a dead end path/giant hack? > >> >>=20 > >> >>=20 > >>=20 > >>>>https://sites.google.com/site/ipv6implementors/2010/agenda/05_Chase_Goo > >>>>gl > >> >>econf-BroadbandtransitiontoIPv6using6rd.pdf?attredirects=3D0 > >> >>=20 > >> >It's a fairly ugly way to deliver IPv6, but, as transition technologies > >> >go, it's the least dead-end of the options. > >> > > >> >It at least provides essentially native dual stack environment. The > >> >only difference is that your IPv6 access is via a tunnel. You'll > >>probably > >> >be limited to a /56 or less over 6rd, unfortunately, but, because of > >>the > >> >awful way 6rd consumes addresses, handing out /48s would be > >> >utterly impractical. Free.fr stuck their customers with /60s, which is > >> >hopefully a very temporary situation. > >> > > >> >>=20 > >> >> I spoke with impulse.net last year, which appears to serve large > >> >> portions of the AT&T cable plant in Southern California. They were > >> >> willing to offer native ipv6. Not sure how (one /64, a /48) etc. > >> >>=20 > >> >You should definitely push your providers to give you a /48 if > >> >possible. If /56 or worse /60 or worst of all, /64 become widespread > >> >trends, it may significantly impact, delay, or even prevent innovations > >> >in the end-user networking/consumer electronics markets. > >> > > >> >Owen > >> > > >> > > >>=20 > >>=20 > >--=20 > >Mark Andrews, ISC > >1 Seymour St., Dundas Valley, NSW 2117, Australia > >PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From khuon at neebu.net Fri Jan 28 01:44:00 2011 From: khuon at neebu.net (Jake Khuon) Date: Thu, 27 Jan 2011 23:44:00 -0800 Subject: Connectivity status for Egypt In-Reply-To: <4D4266DD.7000906@gmail.com> References: <AANLkTimUaNCRFhQqBTPM6Z=W7WUfU8fZUFHGjbqXGJsq@mail.gmail.com> <4D421BB4.1000909@toonk.nl> <9CCC7D46-D578-4BA0-893C-BAE0D170253B@gmail.com> <4D4266DD.7000906@gmail.com> Message-ID: <1296200640.3123.3.camel@Decaf.NEEBU.Net> On Thu, 2011-01-27 at 22:49 -0800, Roy wrote: > On 1/27/2011 9:36 PM, Craig Labovitz wrote: > > > > And to add to this thread, an graph of Egyptian Internet traffic across a large number of geographically / topologically diverse providers yesterday (Jan 27): > > > > http://farm6.static.flickr.com/5291/5395027368_7d97b74c0b_b.jpg > > > > Traffic drops to a handful of megabits following the withdrawal of most Egyptian ISP BGP routes. > > > Moral of the story: Separate facts from assumptions and guesses. I did > some Google searches and that region has had large scale disruptions in > the past. Several cables follow the same path to the Suez canal and > were hit. I guess this begs the question of whether or not we're seeing actual layer1 going down or just the effects of mass BGP withdrawals. Are we seeing lights out on fibre links or just peering sessions going down? Both could still point to a coordinated intentional blackout by the Egyptian gov't though. -- /*=================[ Jake Khuon <khuon at NEEBU.Net> ]=================+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | -------- | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| NETWORKS | +==================================================================*/ From fergdawgster at gmail.com Fri Jan 28 01:46:06 2011 From: fergdawgster at gmail.com (Paul Ferguson) Date: Thu, 27 Jan 2011 23:46:06 -0800 Subject: Connectivity status for Egypt In-Reply-To: <4D4272C9.2080406@bogus.com> References: <AANLkTimUaNCRFhQqBTPM6Z=W7WUfU8fZUFHGjbqXGJsq@mail.gmail.com> <4D421BB4.1000909@toonk.nl> <9CCC7D46-D578-4BA0-893C-BAE0D170253B@gmail.com> <4D4266DD.7000906@gmail.com> <4D4272C9.2080406@bogus.com> Message-ID: <AANLkTin94dPMn_tOPUmqD+wr9oZyqJODvTTCfRxDL8rM@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, Jan 27, 2011 at 11:39 PM, Joel Jaeggli <joelja at bogus.com> wrote: > On 1/27/11 10:49 PM, Roy wrote: >> Moral of the story: Separate facts from assumptions and guesses. I did >> some Google searches and that region has had large scale disruptions in >> the past. Several cables follow the same path to the Suez canal and >> were hit. > > my links through the region are all fine, but they don't jump off the > cable in egypt just pass through. > >> https://secure.wikimedia.org/wikipedia/en/wiki/2008_submarine_cable_disr >> uption >> To my knowledge, no one has reported any cable problems in Norther Africa - -- and news of those problems generally travels very fast. :-) Also, if there *was* a cable problem on one of the paths through the vicinity, it affect more than just Egypt: https://secure.wikimedia.org/wikipedia/en/wiki/File:Cable_map18.svg I don't think it takes a leap of imagination to understand what has happened here. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFNQnQ0q1pz9mNUZTMRAoFQAKCE8P0wINouFWUvW9GFn7FR6XVmOwCdGV/i VzTaxnJQOPVqyY2bP8ZraDA= =daOC -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson ?Engineering Architecture for the Internet ?fergdawgster(at)gmail.com ?ferg's tech blog: http://fergdawg.blogspot.com/ From carlos at race.com Fri Jan 28 02:29:19 2011 From: carlos at race.com (Carlos Alcantar) Date: Fri, 28 Jan 2011 00:29:19 -0800 Subject: Connectivity status for Egypt References: <AANLkTimUaNCRFhQqBTPM6Z=W7WUfU8fZUFHGjbqXGJsq@mail.gmail.com><4D421BB4.1000909@toonk.nl><9CCC7D46-D578-4BA0-893C-BAE0D170253B@gmail.com><4D4266DD.7000906@gmail.com> <4D4272C9.2080406@bogus.com> <AANLkTin94dPMn_tOPUmqD+wr9oZyqJODvTTCfRxDL8rM@mail.gmail.com> Message-ID: <859604546CD1FF488BDB6EA94C896AFB012807E8@racexchange.race.local> Looks like you can still make phone calls into Egypt. So it's not totally lights out... Carlos Alcantar Race Communications / Race Team Member 101 Haskins Way, So. San Francisco, CA. 94080 Phone: +1 415 376 3314 ?Fax: ?+1 650 246 8901 / carlos *at* race.com / www.race.com -----Original Message----- From: Paul Ferguson [mailto:fergdawgster at gmail.com] Sent: Thursday, January 27, 2011 11:46 PM To: Joel Jaeggli Cc: nanog at nanog.org Subject: Re: Connectivity status for Egypt -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, Jan 27, 2011 at 11:39 PM, Joel Jaeggli <joelja at bogus.com> wrote: > On 1/27/11 10:49 PM, Roy wrote: >> Moral of the story: Separate facts from assumptions and guesses. I >> did some Google searches and that region has had large scale >> disruptions in the past. Several cables follow the same path to the >> Suez canal and were hit. > > my links through the region are all fine, but they don't jump off the > cable in egypt just pass through. > >> https://secure.wikimedia.org/wikipedia/en/wiki/2008_submarine_cable_d >> isr >> uption >> To my knowledge, no one has reported any cable problems in Norther Africa - -- and news of those problems generally travels very fast. :-) Also, if there *was* a cable problem on one of the paths through the vicinity, it affect more than just Egypt: https://secure.wikimedia.org/wikipedia/en/wiki/File:Cable_map18.svg I don't think it takes a leap of imagination to understand what has happened here. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFNQnQ0q1pz9mNUZTMRAoFQAKCE8P0wINouFWUvW9GFn7FR6XVmOwCdGV/i VzTaxnJQOPVqyY2bP8ZraDA= =daOC -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson ?Engineering Architecture for the Internet ?fergdawgster(at)gmail.com ?ferg's tech blog: http://fergdawg.blogspot.com/ From kevin at steadfast.net Fri Jan 28 02:39:54 2011 From: kevin at steadfast.net (Kevin Stange) Date: Fri, 28 Jan 2011 02:39:54 -0600 Subject: test-ipv6.com In-Reply-To: <20110128001632.CF4E1938AFA@drugs.dv.isc.org> References: <alpine.BSF.2.00.1101271448000.15852@goat.gigo.com> <20110128001632.CF4E1938AFA@drugs.dv.isc.org> Message-ID: <4D4280DA.8090900@steadfast.net> On 01/27/2011 06:16 PM, Mark Andrews wrote: > In message <alpine.BSF.2.00.1101271448000.15852 at goat.gigo.com>, Jason Fesler wr > ites: >> Several people have suggested I (re)post information about test-ipv6.com >> here. >> >> http://test-ipv6.com .. >> tests ipv4 and ipv6 by dns name >> tests dual stack (will the client break on World IPv6 Day?) >> tests ipv6 by IP literal (teredo can pass this) >> gives advice to end user about current status and (depending on >> circumstances) more information >> "broken" users (can't connect to dual stack) are solicited for info >> Caution: does depend on javascript. >> >> http://test-ipv6.com/simple_test.html >> Eyeball test only for user, with instructions; no javascript required. >> >> Please direct any comments, flames, etc directly to me instead of the >> list. I've added enough noise already :-) > > Note you can have totally broken IPv6 connectivity and still be > fine on World IPv6 day. You just need applications with good > multi-homing support. No web site can check this for you. However, by coincidence, this week I happened to be playing with the site and it revealed to me a particular use case of my DNS resolvers that was broken and gave me a chance to fix it. I don't think there's any harm in some baseline sanity checking. -- Kevin Stange Chief Technology Officer Steadfast Networks http://steadfast.net Phone: 312-602-2689 x203 Fax: 312-602-2688 Cell: 312-320-5867 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110128/e5e6251f/attachment.bin> From marka at isc.org Fri Jan 28 02:56:27 2011 From: marka at isc.org (Mark Andrews) Date: Fri, 28 Jan 2011 19:56:27 +1100 Subject: test-ipv6.com In-Reply-To: Your message of "Fri, 28 Jan 2011 02:39:54 MDT." <4D4280DA.8090900@steadfast.net> References: <alpine.BSF.2.00.1101271448000.15852@goat.gigo.com> <20110128001632.CF4E1938AFA@drugs.dv.isc.org><4D4280DA.8090900@steadfast.net> Message-ID: <20110128085627.8FF1394338A@drugs.dv.isc.org> In message <4D4280DA.8090900 at steadfast.net>, Kevin Stange writes: > On 01/27/2011 06:16 PM, Mark Andrews wrote: > > In message <alpine.BSF.2.00.1101271448000.15852 at goat.gigo.com>, Jason F= > esler wr > > ites: > >> Several people have suggested I (re)post information about test-ipv6.c= > om=20 > >> here. > >> > >> http://test-ipv6.com .. > >> tests ipv4 and ipv6 by dns name > >> tests dual stack (will the client break on World IPv6 Day?) > >> tests ipv6 by IP literal (teredo can pass this) > >> gives advice to end user about current status and (depending on > >> circumstances) more information > >> "broken" users (can't connect to dual stack) are solicited for info= > > >> Caution: does depend on javascript. > >> > >> http://test-ipv6.com/simple_test.html > >> Eyeball test only for user, with instructions; no javascript requir= > ed. > >> > >> Please direct any comments, flames, etc directly to me instead of the = > > >> list. I've added enough noise already :-) > >=20 > > Note you can have totally broken IPv6 connectivity and still be > > fine on World IPv6 day. You just need applications with good > > multi-homing support. No web site can check this for you. > > However, by coincidence, this week I happened to be playing with the > site and it revealed to me a particular use case of my DNS resolvers > that was broken and gave me a chance to fix it. > > I don't think there's any harm in some baseline sanity checking. No harm at all. > --=20 > Kevin Stange > Chief Technology Officer > Steadfast Networks > http://steadfast.net > > Phone: 312-602-2689 x203 > Fax: 312-602-2688 > Cell: 312-320-5867 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From tony at lava.net Fri Jan 28 03:01:37 2011 From: tony at lava.net (Antonio Querubin) Date: Thu, 27 Jan 2011 23:01:37 -1000 (HST) Subject: What's the current state of major access networks in North America ipv6 delivery status? In-Reply-To: <alpine.DEB.1.10.1101280737090.13151@uplift.swm.pp.se> References: <BACEA722-744B-4773-89EF-03FBB933E1E4@delong.com> <C966C429.7FD46%john_brzozowski@cable.comcast.com> <AANLkTi=mjhRtHQYO1LD=9Ai2Tin+QCtdnNYkdYrf95z0@mail.gmail.com> <alpine.OSX.2.00.1101270306550.528@cust11794.lava.net> <D6F4DCE7-4021-41E7-9E89-42A8FAEEBB5F@delong.com> <alpine.OSX.2.00.1101271550001.152@cust11794.lava.net> <alpine.DEB.1.10.1101280737090.13151@uplift.swm.pp.se> Message-ID: <alpine.OSX.2.00.1101272257240.201@cust11794.lava.net> On Fri, 28 Jan 2011, Mikael Abrahamsson wrote: > You do NOT want to keep state for all the devices in the customer residence. > Your ND table will be enormous. > > We already have problems with ARP on our larger residential aggregation > routers, I don't even want to think about what it'd look like with 10+ > devices in peoples homes in those /64:s, each perhaps using multiple IPs. > Your ND traffic will be enormous. I wonder how many ISPs actually have so many IPv6 customers that they actually have these problems. Or is this mainly a limitation with a particular vendor's equipment? Antonio Querubin e-mail/xmpp: tony at lava.net From randy at psg.com Fri Jan 28 03:09:52 2011 From: randy at psg.com (Randy Bush) Date: Fri, 28 Jan 2011 18:09:52 +0900 Subject: ARIN IRR Authentication (was: Re: AltDB?) In-Reply-To: <EB7C0B14-A399-4572-85C9-8557F2C1BD2D@corp.arin.net> References: <59051.1294464800@nsa.vix.com> <00041A16-473F-4F96-93E8-E3CD3F83E1B2@virtualized.org> <70374.1294475040@nsa.vix.com> <m2aajb4vb7.wl%randy@psg.com> <m28vyv4uv0.wl%randy@psg.com> <5336.1294506839@nsa.vix.com> <Pine.LNX.4.61.1101081243291.5148@soloth.lewis.org> <AANLkTi=TDwNgT5WCx-sQ8NgAZ=NZWQDEWzd6+3CEW4st@mail.gmail.com> <AANLkTikCaadeah6Gub1EG43E0j_4N14Yipm+bjsyNzkw@mail.gmail.com> <m2fwt23glz.wl%randy@psg.com> <AANLkTim+_RqZLLG8BWQOnqgJ_EYDDz6tmKROq=ZGOqF=@mail.gmail.com> <1AAAEF13-B1AC-41CA-8B16-9985FD9E0EB2@arin.net> <4D2BAAE3.8080009@dougbarton.us> <BE650600-AD67-4A51-8FDF-ED3F368A6F06@arin.net> <4D2BFC80.2040305@dougbarton.us> <C6D38F6D-74D0-4E41-8A25-DE1816C860C4@arin.net> <EB7C0B14-A399-4572-85C9-8557F2C1BD2D@corp.arin.net> Message-ID: <m2zkql8kdb.wl%randy@psg.com> > Based on the ARIN's IRR authentication thread a couple of weeks ago, there > were suggestions placed into ARIN's ACSP process for changes to ARIN's IRR > system. ARIN has looked at the integration issues involved and has scheduled > an upgrade to the IRR system that will accept PGP and CRYPT-PW authentication > as well as implementing notification support for both the mnt-nfy and notify > fields by the end of August 2011. way cool! thank you. randy From pelle at hemmop.com Fri Jan 28 03:10:00 2011 From: pelle at hemmop.com (Per Carlson) Date: Fri, 28 Jan 2011 10:10:00 +0100 Subject: Another v6 question In-Reply-To: <A942C766-5018-451E-B136-6CBA67EEC03F@delong.com> References: <AANLkTikEZVYFz+bx7MVXeht_qNnpkUEC_Mx0qhE6J9SR@mail.gmail.com> <55E7EC47-C434-4DF7-B92A-8EBC24133C53@delong.com> <AANLkTi=soS+LQoR3JYJxE8N3o9JYoxrL2dvzHZ+e5Geb@mail.gmail.com> <4F209412-3C3B-4CB6-8EB7-A25ABD1B9DBA@delong.com> <AANLkTinqipvQD-gSt1BZ5FcPT2krNhwqO5dExWrM=muG@mail.gmail.com> <67827BB1-BF59-45AF-842F-B9E1AD7A1F87@delong.com> <A5E4AFBB-92C6-464E-AAAB-07B69ECD5214@puck.nether.net> <alpine.DEB.1.10.1101272030321.13151@uplift.swm.pp.se> <A942C766-5018-451E-B136-6CBA67EEC03F@delong.com> Message-ID: <AANLkTinDQdH5Z==mbYvm-OstA2m-WVkxo7vKyLc8x7vf@mail.gmail.com> Hi Owen. > The downside is that it doesn't provide enough bits for certain kinds of auto-topology > management that are being considered by CE vendors. I highly recommend /48 instead. I've seen this claim (you need a /48) from your side several times, but never seen any explanation why a /56 won't work. Is there any requirement that sub-delegations must happen on 8-bit boundaries? AFAICS there is at least nothing in the RFC. Wouldn't for example a nibble boundary work equally well (splitting a /56 into 16 /60s, each containing 16 /64s)? I don't challenge the claim, I'm just trying to understand the rationale behind it. -- Pelle RFC1925, truth 11: ?Every old idea will be proposed again with a different name and ?a different presentation, regardless of whether it works. From jcurran at arin.net Fri Jan 28 03:13:38 2011 From: jcurran at arin.net (John Curran) Date: Fri, 28 Jan 2011 09:13:38 +0000 Subject: ARIN IRR Authentication (was: Re: AltDB?) In-Reply-To: <m2zkql8kdb.wl%randy@psg.com> References: <59051.1294464800@nsa.vix.com> <00041A16-473F-4F96-93E8-E3CD3F83E1B2@virtualized.org> <70374.1294475040@nsa.vix.com> <m2aajb4vb7.wl%randy@psg.com> <m28vyv4uv0.wl%randy@psg.com> <5336.1294506839@nsa.vix.com> <Pine.LNX.4.61.1101081243291.5148@soloth.lewis.org> <AANLkTi=TDwNgT5WCx-sQ8NgAZ=NZWQDEWzd6+3CEW4st@mail.gmail.com> <AANLkTikCaadeah6Gub1EG43E0j_4N14Yipm+bjsyNzkw@mail.gmail.com> <m2fwt23glz.wl%randy@psg.com> <AANLkTim+_RqZLLG8BWQOnqgJ_EYDDz6tmKROq=ZGOqF=@mail.gmail.com> <1AAAEF13-B1AC-41CA-8B16-9985FD9E0EB2@arin.net> <4D2BAAE3.8080009@dougbarton.us> <BE650600-AD67-4A51-8FDF-ED3F368A6F06@arin.net> <4D2BFC80.2040305@dougbarton.us> <C6D38F6D-74D0-4E41-8A25-DE1816C860C4@arin.net> <EB7C0B14-A399-4572-85C9-8557F2C1BD2D@corp.arin.net> <m2zkql8kdb.wl%randy@psg.com> Message-ID: <35C4B2E4-5D20-4DF7-9479-ED15F7B5B39A@arin.net> On Jan 28, 2011, at 4:09 AM, Randy Bush wrote: >> Based on the ARIN's IRR authentication thread a couple of weeks ago, there >> were suggestions placed into ARIN's ACSP process for changes to ARIN's IRR >> system. ARIN has looked at the integration issues involved and has scheduled >> an upgrade to the IRR system that will accept PGP and CRYPT-PW authentication >> as well as implementing notification support for both the mnt-nfy and notify >> fields by the end of August 2011. > > way cool! thank you. No problem at all (and my apologies for not noticing this state of affairs sooner) /John From marka at isc.org Fri Jan 28 03:25:28 2011 From: marka at isc.org (Mark Andrews) Date: Fri, 28 Jan 2011 20:25:28 +1100 Subject: Another v6 question In-Reply-To: Your message of "Fri, 28 Jan 2011 10:10:00 BST." <AANLkTinDQdH5Z==mbYvm-OstA2m-WVkxo7vKyLc8x7vf@mail.gmail.com> References: <AANLkTikEZVYFz+bx7MVXeht_qNnpkUEC_Mx0qhE6J9SR@mail.gmail.com> <55E7EC47-C434-4DF7-B92A-8EBC24133C53@delong.com> <AANLkTi=soS+LQoR3JYJxE8N3o9JYoxrL2dvzHZ+e5Geb@mail.gmail.com> <4F209412-3C3B-4CB6-8EB7-A25ABD1B9DBA@delong.com> <AANLkTinqipvQD-gSt1BZ5FcPT2krNhwqO5dExWrM=muG@mail.gmail.com> <67827BB1-BF59-45AF-842F-B9E1AD7A1F87@delong.com> <A5E4AFBB-92C6-464E-AAAB-07B69ECD5214@puck.nether.net> <alpine.DEB.1.10.1101272030321.13151@uplift.swm.pp.se> <A942C766-5018-451E-B136-6CBA67EEC03F@delong.com> <AANLkTinDQdH5Z==mbYvm-OstA2m-WVkxo7vKyLc8x7vf@mail.gmail.com> Message-ID: <20110128092528.5FB98943F01@drugs.dv.isc.org> In message <AANLkTinDQdH5Z==mbYvm-OstA2m-WVkxo7vKyLc8x7vf at mail.gmail.com>, Per Carlson writes: > Hi Owen. > > > The downside is that it doesn't provide enough bits for certain kinds of = > auto-topology > > management that are being considered by CE vendors. I highly recommend /4= > 8 instead. > > I've seen this claim (you need a /48) from your side several times, > but never seen any explanation why a /56 won't work. > > Is there any requirement that sub-delegations must happen on 8-bit > boundaries? AFAICS there is at least nothing in the RFC. Wouldn't for > example a nibble boundary work equally well (splitting a /56 into 16 > /60s, each containing 16 /64s)? > > I don't challenge the claim, I'm just trying to understand the > rationale behind it. There is a model where the down stream CPE devices always request powers of two prefixes. It doesn't take many CPE devices daisy chained to exhaust 8 bits. The other model is to just request as many /64 as needed using multiple requests with different identifiers. You can daisy chain out past the limits of IPv6 to route packets with that model. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From mch-nanog at xs4all.nl Fri Jan 28 05:01:01 2011 From: mch-nanog at xs4all.nl (Marco Hogewoning) Date: Fri, 28 Jan 2011 12:01:01 +0100 Subject: PPPOE vs DHCP - RIPE Database In-Reply-To: <4D41C178.5020302@peter-dambier.de> References: <051001cbbcf0$c33e8b20$49bba160$@org> <4D41C178.5020302@peter-dambier.de> Message-ID: <CF557A4B-557B-4B8D-A60A-B674E665453D@xs4all.nl> On Jan 27, 2011, at 8:03 PM, Peter Dambier wrote: > Hi, > > I have not seen this in the discussion yet. > > http://labs.ripe.net/Members/mirjam/ipv6-cpe-survey-updated-january-2011 > > CPE support does not seem to be very broad yet. > As far as I can see there is almost PPPoE only for IPv6 in Europe. As long as there is an ADSL interface they usually support both, goes for major vendors as well as some smaller ones. > In Germany cable is a mess by regulation. So no cable/dhcp. > > There used to be a DTAG monopoly with aDSL only and PPPoE only. > Most ISPs still rely on the DTAG infrastructure. That is why > very PPPoE biased. > > There is a high concentration of AVM in the CPE with Infineon > chipsets in both DSLAM and DSL-Modem / Router Part of the DTAG modems seem to be 7570 based and for what I have been told by German friends these can be flashed to the standard production releases. Not of much use for native, but you will get tunnel support in the box. Marco From swmike at swm.pp.se Fri Jan 28 05:34:34 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 28 Jan 2011 12:34:34 +0100 (CET) Subject: What's the current state of major access networks in North America ipv6 delivery status? In-Reply-To: <alpine.OSX.2.00.1101272257240.201@cust11794.lava.net> References: <BACEA722-744B-4773-89EF-03FBB933E1E4@delong.com> <C966C429.7FD46%john_brzozowski@cable.comcast.com> <AANLkTi=mjhRtHQYO1LD=9Ai2Tin+QCtdnNYkdYrf95z0@mail.gmail.com> <alpine.OSX.2.00.1101270306550.528@cust11794.lava.net> <D6F4DCE7-4021-41E7-9E89-42A8FAEEBB5F@delong.com> <alpine.OSX.2.00.1101271550001.152@cust11794.lava.net> <alpine.DEB.1.10.1101280737090.13151@uplift.swm.pp.se> <alpine.OSX.2.00.1101272257240.201@cust11794.lava.net> Message-ID: <alpine.DEB.1.10.1101281230010.13151@uplift.swm.pp.se> On Thu, 27 Jan 2011, Antonio Querubin wrote: > I wonder how many ISPs actually have so many IPv6 customers that they > actually have these problems. Or is this mainly a limitation with a > particular vendor's equipment? If you want to buy some equipment that can handle hundreds of thousands of ND:s instead of one that might handle thousands, you're free to do so. Also your L2 transport need to scale as well, including needing to handle tens of MAC addresses per customer (I live in a household of 2 adults, we have approximately 10-15 devices that talk IP, and this is not becoming fewer over time). It's your money (or your employers). -- Mikael Abrahamsson email: swmike at swm.pp.se From mir at ripe.net Fri Jan 28 07:32:02 2011 From: mir at ripe.net (Mirjam Kuehne) Date: Fri, 28 Jan 2011 14:32:02 +0100 Subject: Connectivity status for Egypt In-Reply-To: <859604546CD1FF488BDB6EA94C896AFB012807E8@racexchange.race.local> References: <AANLkTimUaNCRFhQqBTPM6Z=W7WUfU8fZUFHGjbqXGJsq@mail.gmail.com><4D421BB4.1000909@toonk.nl><9CCC7D46-D578-4BA0-893C-BAE0D170253B@gmail.com><4D4266DD.7000906@gmail.com> <4D4272C9.2080406@bogus.com> <AANLkTin94dPMn_tOPUmqD+wr9oZyqJODvTTCfRxDL8rM@mail.gmail.com> <859604546CD1FF488BDB6EA94C896AFB012807E8@racexchange.race.local> Message-ID: <4D42C552.30902@ripe.net> Hi, We did some analysis of the situation in Egypt using the RIPEstat toolbox (please note, this is a prototype and we're not sure how it will handle a big load): http://labs.ripe.net/Members/akvadrako/live_eqyptian_internet_incident_analysis Mirjam Kuehne RIPE NCC Carlos Alcantar wrote: > Looks like you can still make phone calls into Egypt. So it's not totally lights out... > > > Carlos Alcantar > Race Communications / Race Team Member > 101 Haskins Way, So. San Francisco, CA. 94080 > Phone: +1 415 376 3314 Fax: +1 650 246 8901 / carlos *at* race.com / www.race.com > > > > -----Original Message----- > From: Paul Ferguson [mailto:fergdawgster at gmail.com] > Sent: Thursday, January 27, 2011 11:46 PM > To: Joel Jaeggli > Cc: nanog at nanog.org > Subject: Re: Connectivity status for Egypt > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Thu, Jan 27, 2011 at 11:39 PM, Joel Jaeggli <joelja at bogus.com> wrote: > >> On 1/27/11 10:49 PM, Roy wrote: >>> Moral of the story: Separate facts from assumptions and guesses. I >>> did some Google searches and that region has had large scale >>> disruptions in the past. Several cables follow the same path to the >>> Suez canal and were hit. >> my links through the region are all fine, but they don't jump off the >> cable in egypt just pass through. >> >>> https://secure.wikimedia.org/wikipedia/en/wiki/2008_submarine_cable_d >>> isr >>> uption >>> > > To my knowledge, no one has reported any cable problems in Norther Africa > - -- and news of those problems generally travels very fast. :-) > > Also, if there *was* a cable problem on one of the paths through the vicinity, it affect more than just Egypt: > > https://secure.wikimedia.org/wikipedia/en/wiki/File:Cable_map18.svg > > I don't think it takes a leap of imagination to understand what has happened here. > > - - ferg > > -----BEGIN PGP SIGNATURE----- > Version: PGP Desktop 9.5.3 (Build 5003) > > wj8DBQFNQnQ0q1pz9mNUZTMRAoFQAKCE8P0wINouFWUvW9GFn7FR6XVmOwCdGV/i > VzTaxnJQOPVqyY2bP8ZraDA= > =daOC > -----END PGP SIGNATURE----- > > > > -- > "Fergie", a.k.a. Paul Ferguson > Engineering Architecture for the Internet > fergdawgster(at)gmail.com > ferg's tech blog: http://fergdawg.blogspot.com/ > > > From tme at americafree.tv Fri Jan 28 07:33:29 2011 From: tme at americafree.tv (Marshall Eubanks) Date: Fri, 28 Jan 2011 08:33:29 -0500 Subject: Connectivity status for Egypt In-Reply-To: <859604546CD1FF488BDB6EA94C896AFB012807E8@racexchange.race.local> References: <AANLkTimUaNCRFhQqBTPM6Z=W7WUfU8fZUFHGjbqXGJsq@mail.gmail.com><4D421BB4.1000909@toonk.nl><9CCC7D46-D578-4BA0-893C-BAE0D170253B@gmail.com><4D4266DD.7000906@gmail.com> <4D4272C9.2080406@bogus.com> <AANLkTin94dPMn_tOPUmqD+wr9oZyqJODvTTCfRxDL8rM@mail.gmail.com> <859604546CD1FF488BDB6EA94C896AFB012807E8@racexchange.race.local> Message-ID: <3231D76B-55AB-40CA-BAD2-C0708782BA8E@americafree.tv> On Jan 28, 2011, at 3:29 AM, Carlos Alcantar wrote: > Looks like you can still make phone calls into Egypt. So it's not totally lights out... > Mobile is apparently being shut down now : http://www.vodafone.com/content/index/press.html Statement - Vodafone Egypt All mobile operators in Egypt have been instructed to suspend services in selected areas. Under Egyptian legislation the authorities have the right to issue such an order and we are obliged to comply with it. The Egyptian authorities will be clarifying the situation in due course . ----- I think that clarifications are unnecessary in this case. Regards Marshall > > Carlos Alcantar > Race Communications / Race Team Member > 101 Haskins Way, So. San Francisco, CA. 94080 > Phone: +1 415 376 3314 Fax: +1 650 246 8901 / carlos *at* race.com / www.race.com > > > > -----Original Message----- > From: Paul Ferguson [mailto:fergdawgster at gmail.com] > Sent: Thursday, January 27, 2011 11:46 PM > To: Joel Jaeggli > Cc: nanog at nanog.org > Subject: Re: Connectivity status for Egypt > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Thu, Jan 27, 2011 at 11:39 PM, Joel Jaeggli <joelja at bogus.com> wrote: > >> On 1/27/11 10:49 PM, Roy wrote: >>> Moral of the story: Separate facts from assumptions and guesses. I >>> did some Google searches and that region has had large scale >>> disruptions in the past. Several cables follow the same path to the >>> Suez canal and were hit. >> >> my links through the region are all fine, but they don't jump off the >> cable in egypt just pass through. >> >>> https://secure.wikimedia.org/wikipedia/en/wiki/2008_submarine_cable_d >>> isr >>> uption >>> > > To my knowledge, no one has reported any cable problems in Norther Africa > - -- and news of those problems generally travels very fast. :-) > > Also, if there *was* a cable problem on one of the paths through the vicinity, it affect more than just Egypt: > > https://secure.wikimedia.org/wikipedia/en/wiki/File:Cable_map18.svg > > I don't think it takes a leap of imagination to understand what has happened here. > > - - ferg > > -----BEGIN PGP SIGNATURE----- > Version: PGP Desktop 9.5.3 (Build 5003) > > wj8DBQFNQnQ0q1pz9mNUZTMRAoFQAKCE8P0wINouFWUvW9GFn7FR6XVmOwCdGV/i > VzTaxnJQOPVqyY2bP8ZraDA= > =daOC > -----END PGP SIGNATURE----- > > > > -- > "Fergie", a.k.a. Paul Ferguson > Engineering Architecture for the Internet > fergdawgster(at)gmail.com > ferg's tech blog: http://fergdawg.blogspot.com/ > > > > From mlarson at verisign.com Fri Jan 28 07:58:56 2011 From: mlarson at verisign.com (Matt Larson) Date: Fri, 28 Jan 2011 08:58:56 -0500 Subject: .com DNSSEC operational message Message-ID: <20110128135856.GC65553@DUL1MLARSON-M1.vcorp.ad.vrsn.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Over the next several weeks, Verisign will deploy DNSSEC in the .com zone. This message contains operational information related to the deployment that might be of interest to the Internet operational community. The .com DNSSEC deployment consists of the following major milestones: February 26, 2011: The .com registry system will allow ICANN-accredited registrars to submit DS records for domains under .com. These DS records will not be published in the .com zone until the .com zone is actually signed. February 28, 2011: A deliberately unvalidatable .com zone will be published. Any DS records for .com that have been submitted by registrars will be published in the deliberately unvalidatable zone. March 31, 2011: The .com key material will have been unobscured over the course of the preceding several days and the .com zone will now be usable for DNSSEC validation. DS records for .com should appear in the root zone on this day. If you have any questions or comments, please send email to info at verisign-grs.com or reply to this message. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iQEVAwUBTULLoNdGiUJktOYBAQLgewgAkGWNabyhkidMp5Y/58yDl90td1PFd7X7 Q3rQNAeWOrbJFrMuLoBbmKpfk68c4MjIYzCTKwdER84Jj4MRxbNiDgsMpk3+Br5R qM3NdskB9AwZ90foPU4MPDw8IvBK7SsOHltsf5eyLGbKkoNPBzcDiK3woSTX2XbR xTwOlAHTMdF1IP5o3ytca3a4BwqeRmrErAJGDVlWvbK3KPeV9iDWa+jCkoFTcDD8 6p3syOjimnaJnagRPnm5HodeNb9gH2SVZqKHczKBsapxL5wga2MIAowdmBwzL1Wi DuUzTg5eWx7tG0F112lAyHDCFhil7KLHllree/dqXyyic7paV0e1uA== =bGtT -----END PGP SIGNATURE----- From extraexploit at gmail.com Fri Jan 28 08:37:43 2011 From: extraexploit at gmail.com (exploit dev) Date: Fri, 28 Jan 2011 15:37:43 +0100 Subject: Egypt Telecom AS isolation Message-ID: <AANLkTiksKa6aKH5v_z3mBdzM=idnWfkUiwBoZ1-Oyhi2@mail.gmail.com> Hi to all, I try with BGPlay to show something related to BGP Traffic for some prefix of as8452. If you are interested check: http://extraexploit.blogspot.com/2011/01/egypt-telecom-as-isolation-bgplay-show.html -- http://extraexploit.blogspot.com From weiler+lists.nanog at watson.org Fri Jan 28 09:03:27 2011 From: weiler+lists.nanog at watson.org (Samuel Weiler) Date: Fri, 28 Jan 2011 10:03:27 -0500 (EST) Subject: [arin-announce] ARIN Resource Certification Update Message-ID: <alpine.BSF.2.00.1101281002200.24245@fledge.watson.org> [moderation seems slow; resending from subscribed address instead] On Mon, 24 Jan 2011, Danny McPherson wrote: > I suspect I've sufficiently chummed the waters, I'll kick back and absorb > all the reasons this is a whack idea :) Short summary: it's not entirely whack, but no one has yet put forward a working data model. The scheme in Bill Manning's INET'98 paper might have worked for classFUL addresses, but not CIDR. I think there may have been similar problems with Lutz Donnerhacke and Wouter Wijngaards' scheme(s) from 2008. Joe Abley's problem statement on this list gets to one of the issues. Your answer to him of "New prefix-based RRs? And perhaps even a new .arpa or in-addr.arpa subdomain" is a bit short on details. I challenge you to work out the details. Once we have something concrete, then we can pick apart why it won't work, tweak, and repeat. -- Sam From jbates at brightok.net Fri Jan 28 09:14:04 2011 From: jbates at brightok.net (Jack Bates) Date: Fri, 28 Jan 2011 09:14:04 -0600 Subject: What's the current state of major access networks in North America ipv6 delivery status? In-Reply-To: <alpine.DEB.1.10.1101280737090.13151@uplift.swm.pp.se> References: <BACEA722-744B-4773-89EF-03FBB933E1E4@delong.com> <C966C429.7FD46%john_brzozowski@cable.comcast.com> <AANLkTi=mjhRtHQYO1LD=9Ai2Tin+QCtdnNYkdYrf95z0@mail.gmail.com> <alpine.OSX.2.00.1101270306550.528@cust11794.lava.net> <D6F4DCE7-4021-41E7-9E89-42A8FAEEBB5F@delong.com> <alpine.OSX.2.00.1101271550001.152@cust11794.lava.net> <alpine.DEB.1.10.1101280737090.13151@uplift.swm.pp.se> Message-ID: <4D42DD3C.90003@brightok.net> On 1/28/2011 12:41 AM, Mikael Abrahamsson wrote: > It's much cleaner to require a CPE at he customer prem, run LL only > between CPE and PE, DHCPv6-PD a /56 or larger, and now you're done with > it. No need to keep state for customer home devices, you just have to > handle the CPE. Except now you require a user to have a routed CPE. I'm up for classic stateful DHCPv6 IA_TA addressing + DHCPv6-PD. Best of both worlds, and in a proper setup, any address not assigned is null routed. Jack From tme at americafree.tv Fri Jan 28 09:15:19 2011 From: tme at americafree.tv (Marshall Eubanks) Date: Fri, 28 Jan 2011 10:15:19 -0500 Subject: Connectivity status for Egypt In-Reply-To: <AANLkTimPmL0aKSFZL1Z6vat=o8zkPejEn6o9FmiDdWSj@mail.gmail.com> References: <AANLkTimUaNCRFhQqBTPM6Z=W7WUfU8fZUFHGjbqXGJsq@mail.gmail.com> <4D4224EC.1060604@gmail.com> <AANLkTimPmL0aKSFZL1Z6vat=o8zkPejEn6o9FmiDdWSj@mail.gmail.com> Message-ID: <0986C0EF-B467-48EB-8835-72B0FF417EF4@americafree.tv> Al Arabiya is reporting (via twitter) that the Internet has been shut of in Syria (where I have not heard of reports of protests). I have no confirmation of this as yet. Regards Marshall On Jan 27, 2011, at 9:47 PM, Danny O'Brien wrote: > On Thu, Jan 27, 2011 at 6:07 PM, Roy <r.engehausen at gmail.com> wrote: > >> On 1/27/2011 3:47 PM, Danny O'Brien wrote: >> >>> Around 2236 UCT, we lost all Internet connectivity with our contacts in >>> Egypt, and I'm hearing reports of (in declining order of confirmability): >>> >>> 1) Internet connectivity loss on major (broadband) ISPs >>> 2) No SMS >>> 4) Intermittent connectivity with smaller (dialup?) ISPs >>> 5) No mobile service in major cities -- Cairo, Alexandria >>> >>> The working assumption here is that the Egyptian government has made the >>> decision to shut down all external, and perhaps internal electronic >>> communication as a reaction to the ongoing protests in that country. >>> >>> If anyone can provide more details as to what they're seeing, the extent, >>> plus times and dates, it would be very useful. In moments like this there >>> are often many unconfirmed rumors: I'm seeking concrete reliable >>> confirmation which I can pass onto the press and those working to bring >>> some >>> communications back up (if you have a ham radio license, there is some >>> very >>> early work to provide emergency connectivity. Info at: >>> http://pastebin.com/fHHBqZ7Q ) >>> >>> Thank you, >>> >>> I suggest that you confine your information to the press on what you know >> rather than speculation on the cause. >> >> "Never attribute to malice that which can be adequately explained by >> stupidity, but don't rule out malice" >> >> https://secure.wikimedia.org/wikipedia/en/wiki/Hanlon%27s_razor >> >> > That is indeed one of the reasons why I'm seeking corroboration of the > pattern of behaviour; at least to isolate and eliminate any alternative > explanations. It would certainly be of operational interest (and certainly > not unknown in the annals of historical "stupidity") if, say, a single > fiber-cut or network upgrade was disrupting all of these different forms of > communication simultaneously. On the other hand, there's only a finite > number of imaginary backhoes you can conjure up before other explanations > begin to trump Hanlon's razor. > > Right now, I think that http://bgpmon.net/blog/?p=450 explains (or at least > illustrates) why we were getting reports of widespread but not universal > Internet interruption. See also > http://www.renesys.com/blog/2011/01/egypt-leaves-the-internet.shtml . > > I don't have a good explanation for the SMS problems, but lots of > independent reports; I've yet to have any real confirmation of no mobile > service, and lots of denials, so right now I'm going to assume that's > untrue. > > If anyone can get explanations from their peers in the region, please pass > them on (however incomplete or informal -- mail me directly if you'd rather > not contribute to rumors or non-operational NANOG discussions). > > It's late at night in Egypt, and the biggest protests are planned for > tomorrow. A great deal of life-critical systems will be under a great deal > of stress during that time, and the interruptions in network connectivity > would be extremely worrying. > > Thanks for checking this out, > > d. > From pawal at blipp.com Fri Jan 28 09:23:43 2011 From: pawal at blipp.com (=?iso-8859-1?Q?Patrik_Wallstr=F6m?=) Date: Fri, 28 Jan 2011 16:23:43 +0100 Subject: Connectivity status for Egypt In-Reply-To: <0986C0EF-B467-48EB-8835-72B0FF417EF4@americafree.tv> References: <AANLkTimUaNCRFhQqBTPM6Z=W7WUfU8fZUFHGjbqXGJsq@mail.gmail.com> <4D4224EC.1060604@gmail.com> <AANLkTimPmL0aKSFZL1Z6vat=o8zkPejEn6o9FmiDdWSj@mail.gmail.com> <0986C0EF-B467-48EB-8835-72B0FF417EF4@americafree.tv> Message-ID: <01F070A7-9D86-4E9C-A672-ACBF7A1E1E4C@blipp.com> On Jan 28, 2011, at 4:15 PM, Marshall Eubanks wrote: > Al Arabiya is reporting (via twitter) that the Internet has been shut of in Syria (where I have not heard of reports of protests). > > I have no confirmation of this as yet. I have seen no evidence if this. Can still reach services within the country. From nick at foobar.org Fri Jan 28 09:24:28 2011 From: nick at foobar.org (Nick Hilliard) Date: Fri, 28 Jan 2011 15:24:28 +0000 Subject: Connectivity status for Egypt In-Reply-To: <0986C0EF-B467-48EB-8835-72B0FF417EF4@americafree.tv> References: <AANLkTimUaNCRFhQqBTPM6Z=W7WUfU8fZUFHGjbqXGJsq@mail.gmail.com> <4D4224EC.1060604@gmail.com> <AANLkTimPmL0aKSFZL1Z6vat=o8zkPejEn6o9FmiDdWSj@mail.gmail.com> <0986C0EF-B467-48EB-8835-72B0FF417EF4@americafree.tv> Message-ID: <4D42DFAC.8000204@foobar.org> On 28/01/2011 15:15, Marshall Eubanks wrote: > Al Arabiya is reporting (via twitter) that the Internet has been shut of > in Syria (where I have not heard of reports of protests). > > I have no confirmation of this as yet. AS29386 (Syrian Telecommunication Establishment) appears to be up at this time, as are all nameservers for the .sy TLD. Nick From patrick at ianai.net Fri Jan 28 09:25:59 2011 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 28 Jan 2011 10:25:59 -0500 Subject: Connectivity status for Egypt In-Reply-To: <01F070A7-9D86-4E9C-A672-ACBF7A1E1E4C@blipp.com> References: <AANLkTimUaNCRFhQqBTPM6Z=W7WUfU8fZUFHGjbqXGJsq@mail.gmail.com> <4D4224EC.1060604@gmail.com> <AANLkTimPmL0aKSFZL1Z6vat=o8zkPejEn6o9FmiDdWSj@mail.gmail.com> <0986C0EF-B467-48EB-8835-72B0FF417EF4@americafree.tv> <01F070A7-9D86-4E9C-A672-ACBF7A1E1E4C@blipp.com> Message-ID: <4E5F13EF-FE58-44D1-AB10-246B22E25B3E@ianai.net> On Jan 28, 2011, at 10:23 AM, Patrik Wallstr?m wrote: > On Jan 28, 2011, at 4:15 PM, Marshall Eubanks wrote: > >> Al Arabiya is reporting (via twitter) that the Internet has been shut of in Syria (where I have not heard of reports of protests). >> >> I have no confirmation of this as yet. > > I have seen no evidence if this. Can still reach services within the country. Definitely not shut down. -- TTFN, patrick From tme at americafree.tv Fri Jan 28 09:39:04 2011 From: tme at americafree.tv (Marshall Eubanks) Date: Fri, 28 Jan 2011 10:39:04 -0500 Subject: Connectivity status for Egypt In-Reply-To: <4E5F13EF-FE58-44D1-AB10-246B22E25B3E@ianai.net> References: <AANLkTimUaNCRFhQqBTPM6Z=W7WUfU8fZUFHGjbqXGJsq@mail.gmail.com> <4D4224EC.1060604@gmail.com> <AANLkTimPmL0aKSFZL1Z6vat=o8zkPejEn6o9FmiDdWSj@mail.gmail.com> <0986C0EF-B467-48EB-8835-72B0FF417EF4@americafree.tv> <01F070A7-9D86-4E9C-A672-ACBF7A1E1E4C@blipp.com> <4E5F13EF-FE58-44D1-AB10-246B22E25B3E@ianai.net> Message-ID: <87F3DAF7-12E4-4316-996F-C594E857B383@americafree.tv> On Jan 28, 2011, at 10:25 AM, Patrick W. Gilmore wrote: > On Jan 28, 2011, at 10:23 AM, Patrik Wallstr?m wrote: >> On Jan 28, 2011, at 4:15 PM, Marshall Eubanks wrote: >> >>> Al Arabiya is reporting (via twitter) that the Internet has been shut of in Syria (where I have not heard of reports of protests). >>> >>> I have no confirmation of this as yet. >> >> I have seen no evidence if this. Can still reach services within the country. > > Definitely not shut down. Thanks Marshall > > -- > TTFN, > patrick > > > From jbates at brightok.net Fri Jan 28 09:40:25 2011 From: jbates at brightok.net (Jack Bates) Date: Fri, 28 Jan 2011 09:40:25 -0600 Subject: What's the current state of major access networks in North America ipv6 delivery status? In-Reply-To: <alpine.DEB.1.10.1101281230010.13151@uplift.swm.pp.se> References: <BACEA722-744B-4773-89EF-03FBB933E1E4@delong.com> <C966C429.7FD46%john_brzozowski@cable.comcast.com> <AANLkTi=mjhRtHQYO1LD=9Ai2Tin+QCtdnNYkdYrf95z0@mail.gmail.com> <alpine.OSX.2.00.1101270306550.528@cust11794.lava.net> <D6F4DCE7-4021-41E7-9E89-42A8FAEEBB5F@delong.com> <alpine.OSX.2.00.1101271550001.152@cust11794.lava.net> <alpine.DEB.1.10.1101280737090.13151@uplift.swm.pp.se> <alpine.OSX.2.00.1101272257240.201@cust11794.lava.net> <alpine.DEB.1.10.1101281230010.13151@uplift.swm.pp.se> Message-ID: <4D42E369.4040200@brightok.net> On 1/28/2011 5:34 AM, Mikael Abrahamsson wrote: > > If you want to buy some equipment that can handle hundreds of thousands > of ND:s instead of one that might handle thousands, you're free to do > so. Also your L2 transport need to scale as well, including needing to > handle tens of MAC addresses per customer (I live in a household of 2 > adults, we have approximately 10-15 devices that talk IP, and this is > not becoming fewer over time). > > It's your money (or your employers). > IPv4, standard termination routers (7206VXR), DHCP, no router CPE required, no request limitations. We'll have equivalent in IPv6 with DHCPv6, except we route prefixes for routers, but that won't effect the mac tables. Router 1: 1233 Router 2: 1012 Router 3: 2198 and so on (just random routers). I don't see these numbers as being an issue. The router choice of the ISP is often a factor of number of customers, throughput, and desired feature sets/flexibility; which is why we run multiple processor based routers. I can handle more customers on a hardware based platform, but I also get much better support for the 100s of thousands of ND/ARP tables and run the risk of hardware not supporting a feature I need. Customers are often likely to get a router for their location, especially if you aren't providing wireless in the stock CPE; though I do have a few regions which issue stock CPE with wireless, fully bridged (no routing). Customer's choice. Jack From fasterfourier at gmail.com Fri Jan 28 10:10:05 2011 From: fasterfourier at gmail.com (Robert Johnson) Date: Fri, 28 Jan 2011 11:10:05 -0500 Subject: Need provider suggestions - BGP transit over GRE tunnel Message-ID: <AANLkTikCHuobbeWyyk1Nng_+FE1DcDZwFFupfmUsBDs_@mail.gmail.com> My organization is planning to become multihomed in the near future. Currently we have redundant (router and physical path) links to a single AS where we get our transit, and speak BGP to them using a private ASN. This configuration has not been meeting our reliability requirements, so we will be getting our own ASN from ARIN, and moving from PA to PI IP space. Our new provider will be used for backup purposes only. We would like to minimize the monthly cost of this connection; to do this, we are planning to use a VZ business FIOS connection with symmetrical bandwidth to establish a GRE tunnel to a datacenter somewhere, and bring up a BGP session over that tunnel. I'd like to know if there are providers that offer such a service on a regular basis, and if so, if anyone is doing this and has words of wisdom. Thanks in advance. From morrowc.lists at gmail.com Fri Jan 28 10:17:58 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 28 Jan 2011 11:17:58 -0500 Subject: Connectivity status for Egypt In-Reply-To: <1296200640.3123.3.camel@Decaf.NEEBU.Net> References: <AANLkTimUaNCRFhQqBTPM6Z=W7WUfU8fZUFHGjbqXGJsq@mail.gmail.com> <4D421BB4.1000909@toonk.nl> <9CCC7D46-D578-4BA0-893C-BAE0D170253B@gmail.com> <4D4266DD.7000906@gmail.com> <1296200640.3123.3.camel@Decaf.NEEBU.Net> Message-ID: <AANLkTi=BrQ_m1ypzObszR8_Ta9hPuz_gw-x7ZJYqknJh@mail.gmail.com> On Fri, Jan 28, 2011 at 2:44 AM, Jake Khuon <khuon at neebu.net> wrote: > I guess this begs the question of whether or not we're seeing actual > layer1 going down or just the effects of mass BGP withdrawals. ?Are we > seeing lights out on fibre links or just peering sessions going down? > Both could still point to a coordinated intentional blackout by the > Egyptian gov't though. out of curiousity, what's the difference though between loss of light and peer shutdown? If the local gov't comes in and says: "Make the internets go down", you as the op choose how to do that... NOT getting calls from your peer for interface alarms is probably sane. You can simply drop your routes, leave BGP running even and roll ... If it's clear (and it seems to be) that the issue is a nation-state-decision... implementation (how it's done, no IF it's done) isn't really important, is it? -chris From jared at puck.nether.net Fri Jan 28 10:24:58 2011 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 28 Jan 2011 11:24:58 -0500 Subject: Connectivity status for Egypt In-Reply-To: <AANLkTi=BrQ_m1ypzObszR8_Ta9hPuz_gw-x7ZJYqknJh@mail.gmail.com> References: <AANLkTimUaNCRFhQqBTPM6Z=W7WUfU8fZUFHGjbqXGJsq@mail.gmail.com> <4D421BB4.1000909@toonk.nl> <9CCC7D46-D578-4BA0-893C-BAE0D170253B@gmail.com> <4D4266DD.7000906@gmail.com> <1296200640.3123.3.camel@Decaf.NEEBU.Net> <AANLkTi=BrQ_m1ypzObszR8_Ta9hPuz_gw-x7ZJYqknJh@mail.gmail.com> Message-ID: <4DFB34E6-C056-480C-8406-D0D5285441F6@puck.nether.net> I have seen nation state disconnects where light is lost. Jared Mauch On Jan 28, 2011, at 11:17 AM, Christopher Morrow <morrowc.lists at gmail.com> wrote: > On Fri, Jan 28, 2011 at 2:44 AM, Jake Khuon <khuon at neebu.net> wrote: > >> I guess this begs the question of whether or not we're seeing actual >> layer1 going down or just the effects of mass BGP withdrawals. Are we >> seeing lights out on fibre links or just peering sessions going down? >> Both could still point to a coordinated intentional blackout by the >> Egyptian gov't though. > > out of curiousity, what's the difference though between loss of light > and peer shutdown? If the local gov't comes in and says: "Make the > internets go down", you as the op choose how to do that... NOT getting > calls from your peer for interface alarms is probably sane. You can > simply drop your routes, leave BGP running even and roll ... > > If it's clear (and it seems to be) that the issue is a > nation-state-decision... implementation (how it's done, no IF it's > done) isn't really important, is it? > > -chris > From patrick at ianai.net Fri Jan 28 10:27:02 2011 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 28 Jan 2011 11:27:02 -0500 Subject: Connectivity status for Egypt In-Reply-To: <4DFB34E6-C056-480C-8406-D0D5285441F6@puck.nether.net> References: <AANLkTimUaNCRFhQqBTPM6Z=W7WUfU8fZUFHGjbqXGJsq@mail.gmail.com> <4D421BB4.1000909@toonk.nl> <9CCC7D46-D578-4BA0-893C-BAE0D170253B@gmail.com> <4D4266DD.7000906@gmail.com> <1296200640.3123.3.camel@Decaf.NEEBU.Net> <AANLkTi=BrQ_m1ypzObszR8_Ta9hPuz_gw-x7ZJYqknJh@mail.gmail.com> <4DFB34E6-C056-480C-8406-D0D5285441F6@puck.nether.net> Message-ID: <7ACB6668-5DDC-4782-B775-F24A555EF45A@ianai.net> On Jan 28, 2011, at 11:24 AM, Jared Mauch wrote: > I have seen nation state disconnects where light is lost. The question is not whether that would it (it obviously would). The question is whether it is important if the laser stops blinking or just blinks in ways that end users can't see all the YouTube, web pages, twitter posts, etc. that the gov't doesn't want them to see. I think it does not matter. Censorship is censorship. (So much for "routing around it".) -- TTFN, patrick > On Jan 28, 2011, at 11:17 AM, Christopher Morrow <morrowc.lists at gmail.com> wrote: > >> On Fri, Jan 28, 2011 at 2:44 AM, Jake Khuon <khuon at neebu.net> wrote: >> >>> I guess this begs the question of whether or not we're seeing actual >>> layer1 going down or just the effects of mass BGP withdrawals. Are we >>> seeing lights out on fibre links or just peering sessions going down? >>> Both could still point to a coordinated intentional blackout by the >>> Egyptian gov't though. >> >> out of curiousity, what's the difference though between loss of light >> and peer shutdown? If the local gov't comes in and says: "Make the >> internets go down", you as the op choose how to do that... NOT getting >> calls from your peer for interface alarms is probably sane. You can >> simply drop your routes, leave BGP running even and roll ... >> >> If it's clear (and it seems to be) that the issue is a >> nation-state-decision... implementation (how it's done, no IF it's >> done) isn't really important, is it? >> >> -chris >> > From lee at asgard.org Fri Jan 28 10:29:36 2011 From: lee at asgard.org (Lee Howard) Date: Fri, 28 Jan 2011 11:29:36 -0500 Subject: What's the current state of major access networks in North America ipv6 delivery status? In-Reply-To: <alpine.OSX.2.00.1101261306130.211@cust11794.lava.net> References: <4D409787.8050104@knownelement.com> <alpine.OSX.2.00.1101261306130.211@cust11794.lava.net> Message-ID: <000401cbbf08$8ef0f230$acd2d690$@org> > -----Original Message----- > From: Antonio Querubin [mailto:tony at lava.net] > Sent: Wednesday, January 26, 2011 6:09 PM > To: Charles N Wyble > Cc: nanog at nanog.org > Subject: Re: What's the current state of major access networks in North America ipv6 > delivery status? > > On Wed, 26 Jan 2011, Charles N Wyble wrote: > > > How about TimeWarnerCable? They don't seem to have any sort of v6 > > offering, on wholesale or retail services. > > TW Cable has no IPv6 offering. Time Warner Cable turned up its first commercial customer using native IPv6 over our fiber access product last year, and we expect to begin residential IPv6 trials this spring. We, along with other MSOs, have been working with CableLabs, NCTA and the SCTE in a multi-industry effort to adopt IPv6, and are hopeful that companies in the CE and vendor communities begin to offer new equipment and provide firmware upgrades that ensure the devices in our customers' homes support IPv6. Lee Howard From tme at americafree.tv Fri Jan 28 10:33:41 2011 From: tme at americafree.tv (Marshall Eubanks) Date: Fri, 28 Jan 2011 11:33:41 -0500 Subject: Connectivity status for Egypt In-Reply-To: <4DFB34E6-C056-480C-8406-D0D5285441F6@puck.nether.net> References: <AANLkTimUaNCRFhQqBTPM6Z=W7WUfU8fZUFHGjbqXGJsq@mail.gmail.com> <4D421BB4.1000909@toonk.nl> <9CCC7D46-D578-4BA0-893C-BAE0D170253B@gmail.com> <4D4266DD.7000906@gmail.com> <1296200640.3123.3.camel@Decaf.NEEBU.Net> <AANLkTi=BrQ_m1ypzObszR8_Ta9hPuz_gw-x7ZJYqknJh@mail.gmail.com> <4DFB34E6-C056-480C-8406-D0D5285441F6@puck.nether.net> Message-ID: <B77D3533-6C1B-4A67-B651-3346E8D29833@americafree.tv> On Jan 28, 2011, at 11:24 AM, Jared Mauch wrote: > I have seen nation state disconnects where light is lost. I believe that was the case for Burma, for example. Marshall > > > Jared Mauch > > On Jan 28, 2011, at 11:17 AM, Christopher Morrow <morrowc.lists at gmail.com> wrote: > >> On Fri, Jan 28, 2011 at 2:44 AM, Jake Khuon <khuon at neebu.net> wrote: >> >>> I guess this begs the question of whether or not we're seeing actual >>> layer1 going down or just the effects of mass BGP withdrawals. Are we >>> seeing lights out on fibre links or just peering sessions going down? >>> Both could still point to a coordinated intentional blackout by the >>> Egyptian gov't though. >> >> out of curiousity, what's the difference though between loss of light >> and peer shutdown? If the local gov't comes in and says: "Make the >> internets go down", you as the op choose how to do that... NOT getting >> calls from your peer for interface alarms is probably sane. You can >> simply drop your routes, leave BGP running even and roll ... >> >> If it's clear (and it seems to be) that the issue is a >> nation-state-decision... implementation (how it's done, no IF it's >> done) isn't really important, is it? >> >> -chris >> > > From pkranz at unwiredltd.com Fri Jan 28 10:36:42 2011 From: pkranz at unwiredltd.com (Peter Kranz) Date: Fri, 28 Jan 2011 08:36:42 -0800 Subject: Best current looking glass software builds Message-ID: <002701cbbf09$8b658c10$a230a430$@unwiredltd.com> Anyone done a recent scan of newer looking glass software implementations for apache? We've used cougar's for several years, but have been problems with its SSH implementation lately. Peter Kranz www.UnwiredLtd.com <http://www.unwiredltd.com/> Desk: 510-868-1614 x100 Mobile: 510-207-0000 pkranz at unwiredltd.com From jack at crepinc.com Fri Jan 28 10:48:59 2011 From: jack at crepinc.com (Jack Carrozzo) Date: Fri, 28 Jan 2011 10:48:59 -0600 Subject: Need provider suggestions - BGP transit over GRE tunnel In-Reply-To: <AANLkTikCHuobbeWyyk1Nng_+FE1DcDZwFFupfmUsBDs_@mail.gmail.com> References: <AANLkTikCHuobbeWyyk1Nng_+FE1DcDZwFFupfmUsBDs_@mail.gmail.com> Message-ID: <AANLkTikDohDcYipK5dv1=ifMM_MwnT+PH+FvQHT1zjX8@mail.gmail.com> The general way this works for a small shop is two transits - one cheap provider who you move most of your bits over, and one more expensive but reliable link. Prepend / localpref / whathaveyou to your hearts content until pleased with your bandwidth bill, and when your cheap link toasts you're all set. What you're suggesting with the GRE over commodity links would *work*, but: (a) By the time you convince a network that they should do this for you, you're likely going to be out as much money as just brining up directly connected transit and not pushing much traffic at them. (b) You're using the GRE setup as your backup... over a setup thats about 100x less reliable than your primary link. -Jack Carrozzo From mehmet at akcin.net Fri Jan 28 10:49:07 2011 From: mehmet at akcin.net (Mehmet Akcin) Date: Fri, 28 Jan 2011 11:49:07 -0500 Subject: Best current looking glass software builds In-Reply-To: <002701cbbf09$8b658c10$a230a430$@unwiredltd.com> References: <002701cbbf09$8b658c10$a230a430$@unwiredltd.com> Message-ID: <F4420A32-7691-4F70-9735-3123D4267180@akcin.net> rancid's looking glass seems to be working just fine. mehmet On Jan 28, 2011, at 11:36 AM, Peter Kranz wrote: > Anyone done a recent scan of newer looking glass software implementations > for apache? We've used cougar's for several years, but have been problems > with its SSH implementation lately. > > > > Peter Kranz > www.UnwiredLtd.com <http://www.unwiredltd.com/> > Desk: 510-868-1614 x100 > Mobile: 510-207-0000 > pkranz at unwiredltd.com > > > From jmamodio at gmail.com Fri Jan 28 10:49:21 2011 From: jmamodio at gmail.com (Jorge Amodio) Date: Fri, 28 Jan 2011 10:49:21 -0600 Subject: Connectivity status for Egypt In-Reply-To: <B77D3533-6C1B-4A67-B651-3346E8D29833@americafree.tv> References: <AANLkTimUaNCRFhQqBTPM6Z=W7WUfU8fZUFHGjbqXGJsq@mail.gmail.com> <4D421BB4.1000909@toonk.nl> <9CCC7D46-D578-4BA0-893C-BAE0D170253B@gmail.com> <4D4266DD.7000906@gmail.com> <1296200640.3123.3.camel@Decaf.NEEBU.Net> <AANLkTi=BrQ_m1ypzObszR8_Ta9hPuz_gw-x7ZJYqknJh@mail.gmail.com> <4DFB34E6-C056-480C-8406-D0D5285441F6@puck.nether.net> <B77D3533-6C1B-4A67-B651-3346E8D29833@americafree.tv> Message-ID: <AANLkTikgrkMB_Us35R9cyn6vDG3qUA-vKHVZeyZWOx=Z@mail.gmail.com> Does anybody knows what is the situation with local traffic, are people able to communicate within the country, are there any local servers/services that are being blocked/etc. ? -J From jack at crepinc.com Fri Jan 28 10:51:01 2011 From: jack at crepinc.com (Jack Carrozzo) Date: Fri, 28 Jan 2011 10:51:01 -0600 Subject: Best current looking glass software builds In-Reply-To: <002701cbbf09$8b658c10$a230a430$@unwiredltd.com> References: <002701cbbf09$8b658c10$a230a430$@unwiredltd.com> Message-ID: <AANLkTimo8sNBE8d=G__0U3asDx1yJUbQz8TPKw4miN9x@mail.gmail.com> If you don't mind mod_perl, the looking glass included with Rancid works OK with SSH. Don't know what you mean by "newer looking", since there's not much to the interface - you can just drop your logos and such in there. -Jack Carrozzo On Fri, Jan 28, 2011 at 10:36 AM, Peter Kranz <pkranz at unwiredltd.com> wrote: > Anyone done a recent scan of newer looking glass software implementations > for apache? We've used cougar's for several years, but have been problems > with its SSH implementation lately. > > > > Peter Kranz > www.UnwiredLtd.com <http://www.unwiredltd.com/> > Desk: 510-868-1614 x100 > Mobile: 510-207-0000 > pkranz at unwiredltd.com > > > > From nick at foobar.org Fri Jan 28 10:54:19 2011 From: nick at foobar.org (Nick Hilliard) Date: Fri, 28 Jan 2011 16:54:19 +0000 Subject: Best current looking glass software builds In-Reply-To: <F4420A32-7691-4F70-9735-3123D4267180@akcin.net> References: <002701cbbf09$8b658c10$a230a430$@unwiredltd.com> <F4420A32-7691-4F70-9735-3123D4267180@akcin.net> Message-ID: <4D42F4BB.90004@foobar.org> On 28/01/2011 16:49, Mehmet Akcin wrote: >> Anyone done a recent scan of newer looking glass software implementations >> for apache? We've used cougar's for several years, but have been problems >> with its SSH implementation lately. It works fine with SSHv1, if you have that enabled. Not so good with sshv2. Nick From Valdis.Kletnieks at vt.edu Fri Jan 28 10:55:07 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 28 Jan 2011 11:55:07 -0500 Subject: Connectivity status for Egypt In-Reply-To: Your message of "Fri, 28 Jan 2011 11:17:58 EST." <AANLkTi=BrQ_m1ypzObszR8_Ta9hPuz_gw-x7ZJYqknJh@mail.gmail.com> References: <AANLkTimUaNCRFhQqBTPM6Z=W7WUfU8fZUFHGjbqXGJsq@mail.gmail.com> <4D421BB4.1000909@toonk.nl> <9CCC7D46-D578-4BA0-893C-BAE0D170253B@gmail.com> <4D4266DD.7000906@gmail.com> <1296200640.3123.3.camel@Decaf.NEEBU.Net> <AANLkTi=BrQ_m1ypzObszR8_Ta9hPuz_gw-x7ZJYqknJh@mail.gmail.com> Message-ID: <13761.1296233707@localhost> On Fri, 28 Jan 2011 11:17:58 EST, Christopher Morrow said: > On Fri, Jan 28, 2011 at 2:44 AM, Jake Khuon <khuon at neebu.net> wrote: > > > I guess this begs the question of whether or not we're seeing actual > > layer1 going down or just the effects of mass BGP withdrawals. Are we > > seeing lights out on fibre links or just peering sessions going down? > out of curiousity, what's the difference though between loss of light > and peer shutdown? When Jake wrote that at 2:44AM, it was still unclear if it was government mandate or accidental. The difference is that if it was government action, bringing up a peer may get you a bullet, while relighting a cable that suffered a shark attack is probably safe unless it was a shark with frickin' lasers mounted on its head - which is plausible, as covert-action sharks have been alleged in that region before: http://www.bbc.co.uk/news/world-middle-east-11937285 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110128/4f83e194/attachment.bin> From jj at diamondtech.ca Fri Jan 28 10:59:17 2011 From: jj at diamondtech.ca (Jeff Johnstone) Date: Fri, 28 Jan 2011 08:59:17 -0800 Subject: Connectivity status for Egypt In-Reply-To: <AANLkTikgrkMB_Us35R9cyn6vDG3qUA-vKHVZeyZWOx=Z@mail.gmail.com> References: <AANLkTimUaNCRFhQqBTPM6Z=W7WUfU8fZUFHGjbqXGJsq@mail.gmail.com> <4D421BB4.1000909@toonk.nl> <9CCC7D46-D578-4BA0-893C-BAE0D170253B@gmail.com> <4D4266DD.7000906@gmail.com> <1296200640.3123.3.camel@Decaf.NEEBU.Net> <AANLkTi=BrQ_m1ypzObszR8_Ta9hPuz_gw-x7ZJYqknJh@mail.gmail.com> <4DFB34E6-C056-480C-8406-D0D5285441F6@puck.nether.net> <B77D3533-6C1B-4A67-B651-3346E8D29833@americafree.tv> <AANLkTikgrkMB_Us35R9cyn6vDG3qUA-vKHVZeyZWOx=Z@mail.gmail.com> Message-ID: <AANLkTi=cT0meoNwOwtodiXLELx-AWmT3aZ1+Mg48n--V@mail.gmail.com> On Fri, Jan 28, 2011 at 8:49 AM, Jorge Amodio <jmamodio at gmail.com> wrote: > Does anybody knows what is the situation with local traffic, are > people able to communicate within the country, are there any local > servers/services that are being blocked/etc. ? > > -J > > According to CBC in Canada this morning... http://www.cbc.ca/world/story/2011/01/28/egypt-protests.html Internet, data services cut Internet and cellphone data service was unavailable throughout the country, making it impossible for news of the protests to be broadcast via social networking sites like Facebook and Twitter. The lack of service made it virtually impossible for Egyptians, who use mobile phones almost exclusively, to communicate with one another. Protest organizers had also been using social networking sites like Facebook and Twitter to spread information about the protests. In the United States, Mubarak's closest Western ally, the State Department, said the "events unfolding in Egypt are of deep concern." "Fundamental rights must be respected, violence avoided and open communications allowed," State Department spokesman P.J. Crowley said on Twitter. According to reports, the government ordered internet service providers to cut service early Friday morning. Egypt's four primary internet providers ? Link Egypt, Vodafone/Raya, Telecom Egypt, Etisalat Misr ? all stopped moving data in and out of the country at 12:34 a.m., according to a network security firm monitoring the traffic. (The service provider Noor, which is used by the Egyptian stock exchange, remained active.) An estimated one million people were expected to take part in the demonstrations Friday afternoon, which began following prayers at mosques in Cairo and elsewhere. Read more: http://www.cbc.ca/world/story/2011/01/28/egypt-protests.html#ixzz1CLlbJhdl cheers Jeff From bill at herrin.us Fri Jan 28 11:05:09 2011 From: bill at herrin.us (William Herrin) Date: Fri, 28 Jan 2011 12:05:09 -0500 Subject: Need provider suggestions - BGP transit over GRE tunnel In-Reply-To: <AANLkTikCHuobbeWyyk1Nng_+FE1DcDZwFFupfmUsBDs_@mail.gmail.com> References: <AANLkTikCHuobbeWyyk1Nng_+FE1DcDZwFFupfmUsBDs_@mail.gmail.com> Message-ID: <AANLkTimsf11HavuvVMQ57O6rAGGzrQ=Qwq=MzxFAktjd@mail.gmail.com> On Fri, Jan 28, 2011 at 11:10 AM, Robert Johnson <fasterfourier at gmail.com> wrote: > My organization is planning to become multihomed in the near future. > Currently we have redundant (router and physical path) links to a > single AS where we get our transit, and speak BGP to them using a > private ASN. This configuration has not been meeting our reliability > requirements, so we will be getting our own ASN from ARIN, and moving > from PA to PI IP space. > > Our new provider will be used for backup purposes only. We would like > to minimize the monthly cost of this connection; to do this, we are > planning to use a VZ business FIOS connection with symmetrical > bandwidth to establish a GRE tunnel to a datacenter somewhere, and > bring up a BGP session over that tunnel. I'd like to know if there are > providers that offer such a service on a regular basis, and if so, if > anyone is doing this and has words of wisdom. Hi Robert, I use a similar technique myself and it works reasonably well. Servint.net was willing to do it for me and he.net gave me a quote as well. Three pitfalls to watch out for: 1. A small portion of your traffic is going to wander in via the data center link and down the GRE tunnel during normal operations. You can tweak the announcement so that it isn't much, but it won't be zero either. 2. Make sure you originate the network announcement from your physical location, not from the data center. In other words, no "network 10.2.3.0 mask 255.255.255.0" in the "router bgp" section at the data center. If the data center becomes disconnected from you, it should drop the announcement. 3. You'll need a small block (/29) of PA addresses at the data center to anchor the tunnel. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004 From tony at lava.net Fri Jan 28 11:09:46 2011 From: tony at lava.net (Antonio Querubin) Date: Fri, 28 Jan 2011 07:09:46 -1000 (HST) Subject: What's the current state of major access networks in North America ipv6 delivery status? In-Reply-To: <000401cbbf08$8ef0f230$acd2d690$@org> References: <4D409787.8050104@knownelement.com> <alpine.OSX.2.00.1101261306130.211@cust11794.lava.net> <000401cbbf08$8ef0f230$acd2d690$@org> Message-ID: <alpine.OSX.2.00.1101280706100.147@cust11794.lava.net> On Fri, 28 Jan 2011, Lee Howard wrote: > Time Warner Cable turned up its first commercial customer using native IPv6 > over our > fiber access product last year, and we expect to begin residential IPv6 > trials this spring. > We, along with other MSOs, have been working with CableLabs, NCTA and the > SCTE > in a multi-industry effort to adopt IPv6, and are hopeful that companies in > the CE and > vendor communities begin to offer new equipment and provide firmware > upgrades that > ensure the devices in our customers' homes support IPv6. When I queried the local TWC reps on behalf of a business client who has TWC Business Class service about 2 weeks ago, the response I received was "it's not available yet... you need to convert to IPv4..." Are Business Class customers considered residential or commercial? Antonio Querubin e-mail/xmpp: tony at lava.net From tony at lava.net Fri Jan 28 11:26:17 2011 From: tony at lava.net (Antonio Querubin) Date: Fri, 28 Jan 2011 07:26:17 -1000 (HST) Subject: What's the current state of major access networks in North America ipv6 delivery status? In-Reply-To: <4D42E369.4040200@brightok.net> References: <BACEA722-744B-4773-89EF-03FBB933E1E4@delong.com> <C966C429.7FD46%john_brzozowski@cable.comcast.com> <AANLkTi=mjhRtHQYO1LD=9Ai2Tin+QCtdnNYkdYrf95z0@mail.gmail.com> <alpine.OSX.2.00.1101270306550.528@cust11794.lava.net> <D6F4DCE7-4021-41E7-9E89-42A8FAEEBB5F@delong.com> <alpine.OSX.2.00.1101271550001.152@cust11794.lava.net> <alpine.DEB.1.10.1101280737090.13151@uplift.swm.pp.se> <alpine.OSX.2.00.1101272257240.201@cust11794.lava.net> <alpine.DEB.1.10.1101281230010.13151@uplift.swm.pp.se> <4D42E369.4040200@brightok.net> Message-ID: <alpine.OSX.2.00.1101280719010.147@cust11794.lava.net> On Fri, 28 Jan 2011, Jack Bates wrote: > IPv4, standard termination routers (7206VXR), DHCP, no router CPE required, > no request limitations. We'll have equivalent in IPv6 with DHCPv6, except we > route prefixes for routers, but that won't effect the mac tables. > > Router 1: 1233 > Router 2: 1012 > Router 3: 2198 > > and so on (just random routers). I don't see these numbers as being an issue. It simply isn't an issue for us here either. It's not like we're immediately trading an ARP table for a ND table that's hundreds of times larger than the ARP table. Customers just don't change things that quickly. And I would think aggregation equipment vendors who have been eating their own dog food understand that too. Antonio Querubin e-mail/xmpp: tony at lava.net From JDuffy at nww.com Fri Jan 28 11:43:52 2011 From: JDuffy at nww.com (JDuffy at nww.com) Date: Fri, 28 Jan 2011 12:43:52 -0500 Subject: Connectivity status for Egypt Message-ID: <2DB499DF412E434C9F2E2917BA540171239466077D@USMACCR01.idgone.int> I'm a reporter for Network World, and we're working on a series of stories re the Egyptian Internet blackout. I hope I can glean some information from the operators on this list for my story. It would be much appreciated. My question for NANOG operators is... Is the blackout disrupting your operations in Egypt, Northern Africa and/or the Middle East? Have you noticed any resumption of service since the outage went into effect on Thursday, Jan. 27? Also, a bill was introduced recently in Congress proposing an Internet "kill switch" to be used, apparently, in response to cyberattacks on the U.S.: http://edge.networkworld.com/news/2009/040209-obama-cybersecurity-bill.html?page=1 Do you have any opinions on whether this "kill switch" could indeed be employed here to thwart attacks... or to suppress communications during time of political unrest? As a network operator, would you support such a bill? And would you comply with it if it indeed became law? Thank you, and best regards, Jim Duffy Managing Editor Network World From jared at puck.nether.net Fri Jan 28 11:50:39 2011 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 28 Jan 2011 12:50:39 -0500 Subject: Connectivity status for Egypt In-Reply-To: <2DB499DF412E434C9F2E2917BA540171239466077D@USMACCR01.idgone.int> References: <2DB499DF412E434C9F2E2917BA540171239466077D@USMACCR01.idgone.int> Message-ID: <0A58FD6C-FA07-4CD9-833E-86F56A089777@puck.nether.net> Jim, On Jan 28, 2011, at 12:43 PM, <JDuffy at nww.com> wrote: > And would you comply with it if it indeed became law? For better or worse, companies will comply with lawful requests. In the event of US Civil Unrest, I think it would be much harder than in other regimes to exert this type of control, and would cause a much broader global impact to economic activity. The same would happen with any pan-european "blackout". For the economic reasons alone, I rate the chances of "kill-switch" a zero. It makes for great reporting about power, but the practicality is zero. (this does not preclude the US Government from disconnecting *its* enterprise networks, as has happened with Bureau of Indian Affairs in the past, etc...) - Jared Mauch From cscora at apnic.net Fri Jan 28 12:28:38 2011 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 29 Jan 2011 04:28:38 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201101281828.p0SIScQV023991@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith <pfs at cisco.com>. Routing Table Report 04:00 +10GMT Sat 29 Jan, 2011 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 340429 Prefixes after maximum aggregation: 154694 Deaggregation factor: 2.20 Unique aggregates announced to Internet: 169224 Total ASes present in the Internet Routing Table: 35707 Prefixes per ASN: 9.53 Origin-only ASes present in the Internet Routing Table: 30778 Origin ASes announcing only one prefix: 14951 Transit ASes present in the Internet Routing Table: 4929 Transit-only ASes present in the Internet Routing Table: 118 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 31 Max AS path prepend of ASN (36992) 29 Prefixes from unregistered ASNs in the Routing Table: 321 Unregistered ASNs in the Routing Table: 126 Number of 32-bit ASNs allocated by the RIRs: 1051 Prefixes from 32-bit ASNs in the Routing Table: 6 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 215 Number of addresses announced to Internet: 2348554048 Equivalent to 139 /8s, 252 /16s and 23 /24s Percentage of available address space announced: 63.4 Percentage of allocated address space announced: 65.4 Percentage of available address space allocated: 96.8 Percentage of address space in use by end-sites: 88.0 Total number of prefixes smaller than registry allocations: 139482 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 84978 Total APNIC prefixes after maximum aggregation: 28832 APNIC Deaggregation factor: 2.95 Prefixes being announced from the APNIC address blocks: 81750 Unique aggregates announced from the APNIC address blocks: 35514 APNIC Region origin ASes present in the Internet Routing Table: 4313 APNIC Prefixes per ASN: 18.95 APNIC Region origin ASes announcing only one prefix: 1219 APNIC Region transit ASes present in the Internet Routing Table: 690 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 20 Number of APNIC addresses announced to Internet: 586409504 Equivalent to 34 /8s, 243 /16s and 230 /24s Percentage of available APNIC address space announced: 79.4 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 138008 Total ARIN prefixes after maximum aggregation: 70693 ARIN Deaggregation factor: 1.95 Prefixes being announced from the ARIN address blocks: 108934 Unique aggregates announced from the ARIN address blocks: 44467 ARIN Region origin ASes present in the Internet Routing Table: 14154 ARIN Prefixes per ASN: 7.70 ARIN Region origin ASes announcing only one prefix: 5405 ARIN Region transit ASes present in the Internet Routing Table: 1470 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 23 Number of ARIN addresses announced to Internet: 751502720 Equivalent to 44 /8s, 203 /16s and 5 /24s Percentage of available ARIN address space announced: 63.1 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 47/8, 48/8, 50/8, 52/8, 54/8, 55/8, 56/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, 107/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 80950 Total RIPE prefixes after maximum aggregation: 46146 RIPE Deaggregation factor: 1.75 Prefixes being announced from the RIPE address blocks: 74326 Unique aggregates announced from the RIPE address blocks: 48334 RIPE Region origin ASes present in the Internet Routing Table: 15230 RIPE Prefixes per ASN: 4.88 RIPE Region origin ASes announcing only one prefix: 7770 RIPE Region transit ASes present in the Internet Routing Table: 2370 Average RIPE Region AS path length visible: 4.6 Max RIPE Region AS path length visible: 25 Number of RIPE addresses announced to Internet: 456913728 Equivalent to 27 /8s, 59 /16s and 243 /24s Percentage of available RIPE address space announced: 75.7 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 196608-198655 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 176/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 31587 Total LACNIC prefixes after maximum aggregation: 7249 LACNIC Deaggregation factor: 4.36 Prefixes being announced from the LACNIC address blocks: 30348 Unique aggregates announced from the LACNIC address blocks: 15794 LACNIC Region origin ASes present in the Internet Routing Table: 1424 LACNIC Prefixes per ASN: 21.31 LACNIC Region origin ASes announcing only one prefix: 431 LACNIC Region transit ASes present in the Internet Routing Table: 250 Average LACNIC Region AS path length visible: 4.4 Max LACNIC Region AS path length visible: 19 Number of LACNIC addresses announced to Internet: 80151168 Equivalent to 4 /8s, 199 /16s and 2 /24s Percentage of available LACNIC address space announced: 59.7 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 181/8, 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 4684 Total AfriNIC prefixes after maximum aggregation: 1653 AfriNIC Deaggregation factor: 2.83 Prefixes being announced from the AfriNIC address blocks: 3503 Unique aggregates announced from the AfriNIC address blocks: 1581 AfriNIC Region origin ASes present in the Internet Routing Table: 407 AfriNIC Prefixes per ASN: 8.61 AfriNIC Region origin ASes announcing only one prefix: 126 AfriNIC Region transit ASes present in the Internet Routing Table: 92 Average AfriNIC Region AS path length visible: 5.1 Max AfriNIC Region AS path length visible: 31 Number of AfriNIC addresses announced to Internet: 18336512 Equivalent to 1 /8s, 23 /16s and 203 /24s Percentage of available AfriNIC address space announced: 36.4 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 105/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1915 9485 526 Korea Telecom (KIX) 7545 1594 301 82 TPG Internet Pty Ltd 4755 1401 636 159 TATA Communications formerly 17974 1395 467 27 PT TELEKOMUNIKASI INDONESIA 24560 1094 317 180 Bharti Airtel Ltd., Telemedia 9583 1044 76 487 Sify Limited 4808 1028 2108 287 CNCGROUP IP network: China169 17488 950 162 103 Hathway IP Over Cable Interne 18101 924 117 142 Reliance Infocom Ltd Internet 9829 847 739 75 BSNL National Internet Backbo 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 3710 3855 265 bellsouth.net, inc. 4323 2629 1109 404 Time Warner Telecom 19262 1841 4943 285 Verizon Global Networks 1785 1787 697 133 PaeTec Communications, Inc. 20115 1519 1529 643 Charter Communications 6478 1476 291 56 AT&T Worldnet Services 7018 1360 6674 875 AT&T WorldNet Services 2386 1297 553 933 AT&T Data Communications Serv 22773 1274 2864 77 Cox Communications, Inc. 11492 1266 235 81 Cable One Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6830 514 1764 319 UPC Distribution Services 9198 465 266 14 Kazakhtelecom Data Network Ad 34984 458 97 137 BILISIM TELEKOM 3292 447 2011 390 TDC Tele Danmark 8866 438 133 23 Bulgarian Telecommunication C 12479 412 577 6 Uni2 Autonomous System 3320 403 7619 352 Deutsche Telekom AG 8551 402 353 46 Bezeq International 702 396 1816 309 UUNET - Commercial IP service 20940 393 91 303 Akamai Technologies European 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 1358 252 165 TVCABLE BOGOTA 8151 1329 2627 355 UniNet S.A. de C.V. 28573 1245 959 82 NET Servicos de Comunicao S.A 6503 1149 355 78 AVANTEL, S.A. 7303 885 461 114 Telecom Argentina Stet-France 14420 614 55 90 CORPORACION NACIONAL DE TELEC 22047 566 310 15 VTR PUNTO NET S.A. 3816 526 222 99 Empresa Nacional de Telecomun 7738 478 922 30 Telecomunicacoes da Bahia S.A 14117 456 34 31 Telefonica del Sur 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 3741 264 987 226 The Internet Solution 6713 203 199 12 Itissalat Al-MAGHRIB 33776 194 12 15 Starcomms Nigeria Limited 29571 193 17 11 Ci Telecom Autonomous system 16637 161 440 90 MTN Network Solutions 36874 139 24 6 Cybersmart 29975 131 475 17 Vodacom 37061 108 9 2 One Communications Ltd 15706 106 16 5 Sudatel Internet Exchange Aut 37054 85 5 21 Data Telecom Service 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 3710 3855 265 bellsouth.net, inc. 4323 2629 1109 404 Time Warner Telecom 4766 1915 9485 526 Korea Telecom (KIX) 19262 1841 4943 285 Verizon Global Networks 1785 1787 697 133 PaeTec Communications, Inc. 7545 1594 301 82 TPG Internet Pty Ltd 20115 1519 1529 643 Charter Communications 6478 1476 291 56 AT&T Worldnet Services 4755 1401 636 159 TATA Communications formerly 17974 1395 467 27 PT TELEKOMUNIKASI INDONESIA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4323 2629 2225 Time Warner Telecom 1785 1787 1654 PaeTec Communications, Inc. 19262 1841 1556 Verizon Global Networks 7545 1594 1512 TPG Internet Pty Ltd 6478 1476 1420 AT&T Worldnet Services 4766 1915 1389 Korea Telecom (KIX) 17974 1395 1368 PT TELEKOMUNIKASI INDONESIA 4755 1401 1242 TATA Communications formerly 22773 1274 1197 Cox Communications, Inc. 10620 1358 1193 TVCABLE BOGOTA Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 4323 Time Warner Telecom 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 4323 Time Warner Telecom 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.155.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 5.0.0.0/16 12654 RIPE NCC RIS Project 5.1.0.0/21 12654 RIPE NCC RIS Project 5.1.24.0/24 12654 RIPE NCC RIS Project 24.129.192.0/19 7922 Continental Cablevision 37.0.0.0/16 12654 RIPE NCC RIS Project 37.1.0.0/21 12654 RIPE NCC RIS Project 37.1.24.0/24 12654 RIPE NCC RIS Project 41.57.192.0/18 22750 BCSNET 41.78.192.0/22 30999 Emtel is GSM, 3G and ISP in M 41.222.79.0/24 36938 >>UNKNOWN<< Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:19 /9:10 /10:26 /11:71 /12:214 /13:440 /14:765 /15:1358 /16:11463 /17:5579 /18:9215 /19:18750 /20:24139 /21:24535 /22:32307 /23:30984 /24:177748 /25:979 /26:1061 /27:578 /28:162 /29:16 /30:2 /31:0 /32:8 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2289 3710 bellsouth.net, inc. 6478 1430 1476 AT&T Worldnet Services 4323 1417 2629 Time Warner Telecom 10620 1249 1358 TVCABLE BOGOTA 11492 1222 1266 Cable One 18566 1092 1111 Covad Communications 7011 1065 1168 Citizens Utilities 1785 1059 1787 PaeTec Communications, Inc. 19262 954 1841 Verizon Global Networks 6503 933 1149 AVANTEL, S.A. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:167 2:30 4:13 5:1 8:331 12:2029 13:1 14:381 15:15 16:3 17:8 20:9 23:1 24:1466 27:548 32:61 33:5 34:2 36:1 37:1 38:693 40:101 41:1617 42:1 44:3 46:514 47:5 49:143 50:74 52:12 55:6 56:2 57:30 58:870 59:483 60:391 61:1119 62:783 63:1924 64:3761 65:2331 66:4068 67:1754 68:998 69:2866 70:717 71:392 72:1987 73:1 74:2302 75:293 76:329 77:851 78:692 79:436 80:1022 81:767 82:508 83:470 84:458 85:1044 86:512 87:727 88:359 89:1579 90:159 91:3424 92:492 93:1041 94:1154 95:779 96:413 97:249 98:756 99:33 101:24 107:3 108:81 109:856 110:471 111:695 112:313 113:346 114:495 115:635 116:879 117:673 118:646 119:1031 120:234 121:702 122:1610 123:1050 124:1269 125:1213 128:247 129:158 130:174 131:570 132:110 133:20 134:218 135:49 136:216 137:147 138:293 139:120 140:491 141:198 142:360 143:377 144:488 145:51 146:426 147:194 148:625 149:273 150:151 151:230 152:303 153:175 154:3 155:346 156:174 157:341 158:128 159:377 160:313 161:203 162:277 163:117 164:484 165:336 166:481 167:422 168:739 169:150 170:746 171:66 172:1 173:1264 174:511 175:308 176:1 177:4 178:760 180:754 182:399 183:251 184:207 186:957 187:799 188:906 189:1015 190:4438 192:5782 193:4796 194:3466 195:2930 196:1024 197:3 198:3551 199:3749 200:5585 201:1583 202:8274 203:8431 204:4092 205:2347 206:2533 207:2967 208:3884 209:3493 210:2629 211:1330 212:1852 213:1622 214:751 215:62 216:4824 217:1489 218:526 219:375 220:1202 221:448 222:319 223:93 End of report From jabley at hopcount.ca Fri Jan 28 12:32:07 2011 From: jabley at hopcount.ca (Joe Abley) Date: Fri, 28 Jan 2011 13:32:07 -0500 Subject: Connectivity status for Egypt In-Reply-To: <B77D3533-6C1B-4A67-B651-3346E8D29833@americafree.tv> References: <AANLkTimUaNCRFhQqBTPM6Z=W7WUfU8fZUFHGjbqXGJsq@mail.gmail.com> <4D421BB4.1000909@toonk.nl> <9CCC7D46-D578-4BA0-893C-BAE0D170253B@gmail.com> <4D4266DD.7000906@gmail.com> <1296200640.3123.3.camel@Decaf.NEEBU.Net> <AANLkTi=BrQ_m1ypzObszR8_Ta9hPuz_gw-x7ZJYqknJh@mail.gmail.com> <4DFB34E6-C056-480C-8406-D0D5285441F6@puck.nether.net> <B77D3533-6C1B-4A67-B651-3346E8D29833@americafree.tv> Message-ID: <EDFD4E4A-C01A-46A4-891E-8FCF90CED2CB@hopcount.ca> On 2011-01-28, at 11:33, Marshall Eubanks wrote: > On Jan 28, 2011, at 11:24 AM, Jared Mauch wrote: > >> I have seen nation state disconnects where light is lost. > > I believe that was the case for Burma, for example. It was not the case in Nepal in 2005 though, if I remember correctly. In that case connectivity to the outside was maintained, but access to that connectivity by people inside the country was curtailed. Joe From iljitsch at muada.com Fri Jan 28 13:01:12 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Fri, 28 Jan 2011 20:01:12 +0100 Subject: 3500 Egyptian prefixes? Message-ID: <BCFF7510-17CC-4CD3-A3B7-2D9C20584551@muada.com> On the Renesys blog http://www.renesys.com/blog/2011/01/egypt-leaves-the-internet.shtml it says that 3500 prefixes disappeared. 1% of the global table seems a lot, especially considering that according to AfriNIC Egypt only has 122 IPv4 and 7 IPv6 prefixes. What gives? From morrowc.lists at gmail.com Fri Jan 28 13:07:16 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 28 Jan 2011 14:07:16 -0500 Subject: 3500 Egyptian prefixes? In-Reply-To: <BCFF7510-17CC-4CD3-A3B7-2D9C20584551@muada.com> References: <BCFF7510-17CC-4CD3-A3B7-2D9C20584551@muada.com> Message-ID: <AANLkTimJOYpOa2rjCZPyogqUvr6x6O3mc=-pF1ovawhJ@mail.gmail.com> On Fri, Jan 28, 2011 at 2:01 PM, Iljitsch van Beijnum <iljitsch at muada.com> wrote: > On the Renesys blog http://www.renesys.com/blog/2011/01/egypt-leaves-the-internet.shtml > it says that 3500 prefixes disappeared. 1% of the global table seems a lot, especially considering that according to AfriNIC Egypt only has 122 IPv4 and 7 IPv6 prefixes. > > What gives? de-aggregates not-afrinic-region blocks geo-located blocks (potentially mis-located?) customer blocks of the 7 isp's in region lots of slosh there... From ren.provo at gmail.com Fri Jan 28 13:11:12 2011 From: ren.provo at gmail.com (Ren Provo) Date: Fri, 28 Jan 2011 14:11:12 -0500 Subject: 3500 Egyptian prefixes? In-Reply-To: <BCFF7510-17CC-4CD3-A3B7-2D9C20584551@muada.com> References: <BCFF7510-17CC-4CD3-A3B7-2D9C20584551@muada.com> Message-ID: <AANLkTimicch+4LrFx-AJVEiF9EKLCtFHThsGbbgf1XQS@mail.gmail.com> ~25 million people live in Cairo alone, many under the age of 30 given another 'arrival' is said to occur every 10 minutes. When we were there earlier this month most had cell phones and wi-fi spots were available all around the area that is being streamed on CNN right now. As a society they are very social and a fair amount of their marketing materials have shifted to email addresses vs. phone/fax contacts. Internet access is a big part of their society. On Fri, Jan 28, 2011 at 2:01 PM, Iljitsch van Beijnum <iljitsch at muada.com>wrote: > On the Renesys blog > http://www.renesys.com/blog/2011/01/egypt-leaves-the-internet.shtml > it says that 3500 prefixes disappeared. 1% of the global table seems a lot, > especially considering that according to AfriNIC Egypt only has 122 IPv4 and > 7 IPv6 prefixes. > > What gives? > From john at sackheads.org Fri Jan 28 14:07:20 2011 From: john at sackheads.org (John Payne) Date: Fri, 28 Jan 2011 15:07:20 -0500 Subject: Bogons In-Reply-To: <F6427296-2D81-40A2-B578-95BD27B8CE35@sackheads.org> References: <F6427296-2D81-40A2-B578-95BD27B8CE35@sackheads.org> Message-ID: <A28DCA86-6934-4ABE-B2E9-B951B013D44F@sackheads.org> On Dec 17, 2010, at 4:06 PM, John Payne wrote: > With the holiday freezes approaching, it might be worth making sure that the recently allocated /8s are not in your bogon list.... > > 23/8 > 100/8 > 5/8 > 37/8 > > Just sayin' 105/8, 2/8, etc etc Now that the holidays are over and IANA v4 depletion is likely days away, perhaps its time to consider stripping your bogon lists down to the bare minimum, and as someone else said, declare bogons dead and move to martians? Just sayin' From khuon at neebu.net Fri Jan 28 14:07:11 2011 From: khuon at neebu.net (Jake Khuon) Date: Fri, 28 Jan 2011 12:07:11 -0800 Subject: Connectivity status for Egypt In-Reply-To: <7ACB6668-5DDC-4782-B775-F24A555EF45A@ianai.net> References: <AANLkTimUaNCRFhQqBTPM6Z=W7WUfU8fZUFHGjbqXGJsq@mail.gmail.com> <4D421BB4.1000909@toonk.nl> <9CCC7D46-D578-4BA0-893C-BAE0D170253B@gmail.com> <4D4266DD.7000906@gmail.com> <1296200640.3123.3.camel@Decaf.NEEBU.Net> <AANLkTi=BrQ_m1ypzObszR8_Ta9hPuz_gw-x7ZJYqknJh@mail.gmail.com> <4DFB34E6-C056-480C-8406-D0D5285441F6@puck.nether.net> <7ACB6668-5DDC-4782-B775-F24A555EF45A@ianai.net> Message-ID: <1296245232.5676.8.camel@Decaf.NEEBU.Net> On Fri, 2011-01-28 at 11:27 -0500, Patrick W. Gilmore wrote: > I think it does not matter. Censorship is censorship. (So much for "routing around it".) Obviously for the effected, the effects are the same. |8^) However, I'm interested in knowing about the level of fine control that the Egyptian government may have exercised. I think the subtle implications on the relationships between operators and governments bear some fine distinction in such a case. Also I think there will eventually be different consequences between an indiscriminate mass disconnect of all telecom and network services and a selective one where some of the infrastructure is left intact but under tighter control... especially if internal reach is still selectively available while external reach has been disabled. -- /*=================[ Jake Khuon <khuon at NEEBU.Net> ]=================+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | -------- | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| NETWORKS | +==================================================================*/ From gbonser at seven.com Fri Jan 28 14:14:07 2011 From: gbonser at seven.com (George Bonser) Date: Fri, 28 Jan 2011 12:14:07 -0800 Subject: Bogons In-Reply-To: <A28DCA86-6934-4ABE-B2E9-B951B013D44F@sackheads.org> References: <F6427296-2D81-40A2-B578-95BD27B8CE35@sackheads.org> <A28DCA86-6934-4ABE-B2E9-B951B013D44F@sackheads.org> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC136D4@RWC-EX1.corp.seven.com> > Now that the holidays are over and IANA v4 depletion is likely days > away, perhaps its time to consider stripping your bogon lists down to > the bare minimum, and as someone else said, declare bogons dead and > move to martians? > > > Just sayin' > There are still some 7,000 prefixes in the v4 "full bogons" list. These are such things as allocations to RIR's but have not yet been allocated. It's updated every four hours: http://www.team-cymru.org/Services/Bogons/fullbogons-ipv4.txt " The traditional bogon prefixes, plus prefixes that have been allocated to RIRs but not yet assigned by those RIRs to ISPs, end-users, etc. Updated every four hours." That is one probably best taken by BGP feed and not done manually. From john at sackheads.org Fri Jan 28 14:22:24 2011 From: john at sackheads.org (John Payne) Date: Fri, 28 Jan 2011 15:22:24 -0500 Subject: Bogons In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC136D4@RWC-EX1.corp.seven.com> References: <F6427296-2D81-40A2-B578-95BD27B8CE35@sackheads.org> <A28DCA86-6934-4ABE-B2E9-B951B013D44F@sackheads.org> <5A6D953473350C4B9995546AFE9939EE0BC136D4@RWC-EX1.corp.seven.com> Message-ID: <03AF91C1-A63E-47B2-9C15-BFDC1965EA95@sackheads.org> On Jan 28, 2011, at 3:14 PM, George Bonser wrote: > > >> Now that the holidays are over and IANA v4 depletion is likely days >> away, perhaps its time to consider stripping your bogon lists down to >> the bare minimum, and as someone else said, declare bogons dead and >> move to martians? >> >> >> Just sayin' >> > > There are still some 7,000 prefixes in the v4 "full bogons" list. These > are such things as allocations to RIR's but have not yet been allocated. > It's updated every four hours: > > > > http://www.team-cymru.org/Services/Bogons/fullbogons-ipv4.txt > > " The traditional bogon prefixes, plus prefixes that have been > allocated to RIRs but not yet assigned by those RIRs to ISPs, end-users, > etc. Updated every four hours." > > That is one probably best taken by BGP feed and not done manually. Yes, I was referring to static/manual bogon list. The Cymru BGP feed rocks. From gbonser at seven.com Fri Jan 28 14:36:30 2011 From: gbonser at seven.com (George Bonser) Date: Fri, 28 Jan 2011 12:36:30 -0800 Subject: Connectivity status for Egypt In-Reply-To: <1296245232.5676.8.camel@Decaf.NEEBU.Net> References: <AANLkTimUaNCRFhQqBTPM6Z=W7WUfU8fZUFHGjbqXGJsq@mail.gmail.com><4D421BB4.1000909@toonk.nl><9CCC7D46-D578-4BA0-893C-BAE0D170253B@gmail.com><4D4266DD.7000906@gmail.com> <1296200640.3123.3.camel@Decaf.NEEBU.Net><AANLkTi=BrQ_m1ypzObszR8_Ta9hPuz_gw-x7ZJYqknJh@mail.gmail.com><4DFB34E6-C056-480C-8406-D0D5285441F6@puck.nether.net><7ACB6668-5DDC-4782-B775-F24A555EF45A@ianai.net> <1296245232.5676.8.camel@Decaf.NEEBU.Net> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC136D6@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Jake Khuon [mailto:khuon at neebu.net] > Sent: Friday, January 28, 2011 12:07 PM > To: Patrick W. Gilmore > Cc: NANOG list > Subject: Re: Connectivity status for Egypt > > On Fri, 2011-01-28 at 11:27 -0500, Patrick W. Gilmore wrote: > > > I think it does not matter. Censorship is censorship. (So much for > "routing around it".) > I think it would be pretty hard to actually cut off communications when the telephone system is still working. You can move a lot of email by dialup UUCP if you wanted to. I am guessing that satellite internet still works and landline dialup to a modem outside the country still works. And there's always static routes :) From aj at sneep.net Fri Jan 28 14:51:02 2011 From: aj at sneep.net (Alastair Johnson) Date: Fri, 28 Jan 2011 12:51:02 -0800 Subject: Connectivity status for Egypt In-Reply-To: <AANLkTi=BrQ_m1ypzObszR8_Ta9hPuz_gw-x7ZJYqknJh@mail.gmail.com> References: <AANLkTimUaNCRFhQqBTPM6Z=W7WUfU8fZUFHGjbqXGJsq@mail.gmail.com> <4D421BB4.1000909@toonk.nl> <9CCC7D46-D578-4BA0-893C-BAE0D170253B@gmail.com> <4D4266DD.7000906@gmail.com> <1296200640.3123.3.camel@Decaf.NEEBU.Net> <AANLkTi=BrQ_m1ypzObszR8_Ta9hPuz_gw-x7ZJYqknJh@mail.gmail.com> Message-ID: <4D432C36.5070404@sneep.net> On 1/28/2011 8:17 AM, Christopher Morrow wrote: > out of curiousity, what's the difference though between loss of light > and peer shutdown? If the local gov't comes in and says: "Make the > internets go down", you as the op choose how to do that... NOT getting > calls from your peer for interface alarms is probably sane. You can > simply drop your routes, leave BGP running even and roll ... > > If it's clear (and it seems to be) that the issue is a > nation-state-decision... implementation (how it's done, no IF it's > done) isn't really important, is it? I guess it depends on what goes down as an effect of the mandate. If it's full Layer 1 severing, then leased line and other circuits will go down too. If it's just "shut down your Internet peering sessions", then there's alternative opportunities for connectivity. For instance, our corporate WAN links into Cairo are still up (UUNET PIP). aj From charles at knownelement.com Fri Jan 28 14:52:37 2011 From: charles at knownelement.com (Charles N Wyble) Date: Fri, 28 Jan 2011 12:52:37 -0800 Subject: Connectivity status for Egypt In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC136D6@RWC-EX1.corp.seven.com> References: <AANLkTimUaNCRFhQqBTPM6Z=W7WUfU8fZUFHGjbqXGJsq@mail.gmail.com><4D421BB4.1000909@toonk.nl><9CCC7D46-D578-4BA0-893C-BAE0D170253B@gmail.com><4D4266DD.7000906@gmail.com> <1296200640.3123.3.camel@Decaf.NEEBU.Net><AANLkTi=BrQ_m1ypzObszR8_Ta9hPuz_gw-x7ZJYqknJh@mail.gmail.com><4DFB34E6-C056-480C-8406-D0D5285441F6@puck.nether.net><7ACB6668-5DDC-4782-B775-F24A555EF45A@ianai.net> <1296245232.5676.8.camel@Decaf.NEEBU.Net> <5A6D953473350C4B9995546AFE9939EE0BC136D6@RWC-EX1.corp.seven.com> Message-ID: <4D432C95.1050400@knownelement.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/28/2011 12:36 PM, George Bonser wrote: > > >> -----Original Message----- >> From: Jake Khuon [mailto:khuon at neebu.net] >> Sent: Friday, January 28, 2011 12:07 PM >> To: Patrick W. Gilmore >> Cc: NANOG list >> Subject: Re: Connectivity status for Egypt >> >> On Fri, 2011-01-28 at 11:27 -0500, Patrick W. Gilmore wrote: >> >>> I think it does not matter. Censorship is censorship. (So much for >> "routing around it".) >> > > > I think it would be pretty hard to actually cut off communications when the telephone system is still working. You can move a lot of email by dialup UUCP if you wanted to. Right. In a government regulated monopoly telcom carrier. > > I am guessing that satellite internet still works If people can't afford to eat, I doubt they can afford satellite internet. and landline dialup to a modem outside the country still works. This presumes people have long distance plans. And there's always static routes :) To what? If everyone has dropped BGP sessions how are you as an end user going to setup static routes? Unless there are no firewalls and everything is wide open how would you reach gateways? - -- Charles N Wyble (charles at knownelement.com) Systems craftsman for the stars http://www.knownelement.com Mobile: 626 539 4344 Office: 310 929 8793 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNQyyUAAoJEMvvG/TyLEAt2ZoQALt3Arteje09ssqAkrbsretj BuH1UyzK6VNpyk9q72p9C10XowqNE9BGTni+B1lZxh4VNY/cSdRaQFQO9DsMt+ww dWl4HAu/PswRkWGrdQ2DIncRuXd8D6IOQ+ggv2I3cA6Pxi9Ep3rg5GF63+x1fTff 6SCU+FWjTe4ghkeDkR7d2L/6DESJiZCR1DojBMIPf1/W8TTllqmCXflPW6cLgIlC gBqiCVM24FhMBmNzGGjfcnfoQnCcwFD5qAVPBcMh0Y9Hz5olEN2F0tsgYSbG2szH 3UD4ocZ07xLMAG1LdkjoEJmORdAQOv5GL2nkFFCi+/K6sMTyhRhBkO03DA0tOkRN M/wJIrRMeSS5ur6NBy0PDgHcHYo138w5wUAoZi3B8JrfiP+cxJ+oEMm6LDDLTNV7 NbKgpkUOeAvi+qhXo2BUbXpZv8Oh/OAedwIu7/5xHx8YPm2Bq9OTkZrPECslig/G p2NCWpohbKfUn0EeN/NdutxWX/O6YY3y5mB/wfFasnr0kvi413QOMnRViOSgfNY/ DTtpzTc7aahY0L2uAU21qTZIMDRuB/aYaHfbfsKpL2LGdxq/JFm6sQQ/IeN5Q7ii 0QvMDM04Eqi4cCgut7p3DKTjkxFnU9Wilo/A8jeY4CRVH1I/Afft6aDh7GZNPKgr QaEcUTQLrfCF284d1XSl =QICt -----END PGP SIGNATURE----- From joseph.prasad at gmail.com Fri Jan 28 14:58:04 2011 From: joseph.prasad at gmail.com (Joseph Prasad) Date: Fri, 28 Jan 2011 12:58:04 -0800 Subject: Connectivity status for Egypt In-Reply-To: <AANLkTimUaNCRFhQqBTPM6Z=W7WUfU8fZUFHGjbqXGJsq@mail.gmail.com> References: <AANLkTimUaNCRFhQqBTPM6Z=W7WUfU8fZUFHGjbqXGJsq@mail.gmail.com> Message-ID: <AANLkTi=XKThTWUASZVrBuWkK+egBRr-1vrYDjOnCk23N@mail.gmail.com> Here is a blog by Al Jazeera on what is happening in Egypt. Look at the time stamp of 7:46. Kill-Switch is alive and well. Coming to America soon? http://blogs.aljazeera.net/middle-east/2011/01/28/liveblog-egypts-protests-erupt . *--------------------------------* *The only power people exert over us, is the power we allow them to exert.* * * *http://www.projectcensored.org/* * * *http://www.thenewamerican.com/* *--------------------------------* On Thu, Jan 27, 2011 at 3:47 PM, Danny O'Brien <danny at spesh.com> wrote: > Around 2236 UCT, we lost all Internet connectivity with our contacts in > Egypt, and I'm hearing reports of (in declining order of confirmability): > > 1) Internet connectivity loss on major (broadband) ISPs > 2) No SMS > 4) Intermittent connectivity with smaller (dialup?) ISPs > 5) No mobile service in major cities -- Cairo, Alexandria > > The working assumption here is that the Egyptian government has made the > decision to shut down all external, and perhaps internal electronic > communication as a reaction to the ongoing protests in that country. > > If anyone can provide more details as to what they're seeing, the extent, > plus times and dates, it would be very useful. In moments like this there > are often many unconfirmed rumors: I'm seeking concrete reliable > confirmation which I can pass onto the press and those working to bring > some > communications back up (if you have a ham radio license, there is some very > early work to provide emergency connectivity. Info at: > http://pastebin.com/fHHBqZ7Q ) > > Thank you, > > -- > dobrien at cpj.org > Danny O'Brien, Committee to Protect Journalists > gpg key: http://www.spesh.com/danny/crypto/dannyobrien-key20091106.txt > -- * * From a.harrowell at gmail.com Fri Jan 28 15:02:34 2011 From: a.harrowell at gmail.com (Alexander Harrowell) Date: Fri, 28 Jan 2011 21:02:34 +0000 Subject: Connectivity status for Egypt In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC136D6@RWC-EX1.corp.seven.com> References: <AANLkTimUaNCRFhQqBTPM6Z=W7WUfU8fZUFHGjbqXGJsq@mail.gmail.com> <1296245232.5676.8.camel@Decaf.NEEBU.Net> <5A6D953473350C4B9995546AFE9939EE0BC136D6@RWC-EX1.corp.seven.com> Message-ID: <201101282102.51666.a.harrowell@gmail.com> On Friday 28 January 2011 20:36:30 George Bonser wrote: > > -----Original Message----- > > From: Jake Khuon [mailto:khuon at neebu.net] > > Sent: Friday, January 28, 2011 12:07 PM > > To: Patrick W. Gilmore > > Cc: NANOG list > > Subject: Re: Connectivity status for Egypt > > > > On Fri, 2011-01-28 at 11:27 -0500, Patrick W. Gilmore wrote: > > > I think it does not matter. Censorship is censorship. (So much for > > > > "routing around it".) > > I think it would be pretty hard to actually cut off communications when the > telephone system is still working. You can move a lot of email by dialup > UUCP if you wanted to. > > I am guessing that satellite internet still works and landline dialup to a > modem outside the country still works. And there's always static routes > :) International dial-out is a good point, especially these days when international voice isn't wildly expensive any more. Does anyone have a source for dialup pools like that? Personally, I suspect that it's probably more important to cut off internal comms. Especially as the TV and media people are pretty good at bringing their own satellite connectivity. Which is more worrying, someone updating their wordpress.com blog, or the same person texting everyone they know to show up outside State TV at 1700 hours and bring a bag of bricks? A lot of the fbk/twt/whatever activity, and all the really politically important fraction of it, is just that - but going through either externally located servers or externally-owned ones. I wonder if anyone's working on a mesh or p-t-p radio app that runs on a smartphone? -- The only thing worse than e-mail disclaimers...is people who send e-mail to lists complaining about them -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110128/2bacd1ae/attachment.bin> From aj at sneep.net Fri Jan 28 15:07:58 2011 From: aj at sneep.net (Alastair Johnson) Date: Fri, 28 Jan 2011 13:07:58 -0800 Subject: Connectivity status for Egypt In-Reply-To: <201101282102.51666.a.harrowell@gmail.com> References: <AANLkTimUaNCRFhQqBTPM6Z=W7WUfU8fZUFHGjbqXGJsq@mail.gmail.com> <1296245232.5676.8.camel@Decaf.NEEBU.Net> <5A6D953473350C4B9995546AFE9939EE0BC136D6@RWC-EX1.corp.seven.com> <201101282102.51666.a.harrowell@gmail.com> Message-ID: <4D43302E.3020308@sneep.net> On 1/28/2011 1:02 PM, Alexander Harrowell wrote: > I wonder if anyone's working on a mesh or p-t-p radio app that runs on a > smartphone? Yes - came across http://www.servalproject.org/ from the linux.conf.au program. From charles at knownelement.com Fri Jan 28 15:15:35 2011 From: charles at knownelement.com (Charles N Wyble) Date: Fri, 28 Jan 2011 13:15:35 -0800 Subject: Connectivity status for Egypt In-Reply-To: <201101282102.51666.a.harrowell@gmail.com> References: <AANLkTimUaNCRFhQqBTPM6Z=W7WUfU8fZUFHGjbqXGJsq@mail.gmail.com> <1296245232.5676.8.camel@Decaf.NEEBU.Net> <5A6D953473350C4B9995546AFE9939EE0BC136D6@RWC-EX1.corp.seven.com> <201101282102.51666.a.harrowell@gmail.com> Message-ID: <4D4331F7.5080507@knownelement.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/28/2011 01:02 PM, Alexander Harrowell wrote: > On Friday 28 January 2011 20:36:30 George Bonser wrote: >>> -----Original Message----- >>> From: Jake Khuon [mailto:khuon at neebu.net] >>> Sent: Friday, January 28, 2011 12:07 PM >>> To: Patrick W. Gilmore >>> Cc: NANOG list >>> Subject: Re: Connectivity status for Egypt >>> >>> On Fri, 2011-01-28 at 11:27 -0500, Patrick W. Gilmore wrote: >>>> I think it does not matter. Censorship is censorship. (So much for >>> >>> "routing around it".) >> >> I think it would be pretty hard to actually cut off communications when the >> telephone system is still working. You can move a lot of email by dialup >> UUCP if you wanted to. >> >> > > I wonder if anyone's working on a mesh or p-t-p radio app that runs on a > smartphone? > > Yes. http://www.servalproject.org/ - -- Charles N Wyble (charles at knownelement.com) Systems craftsman for the stars http://www.knownelement.com Mobile: 626 539 4344 Office: 310 929 8793 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNQzHxAAoJEMvvG/TyLEAtV60P+wUsrIDsZJrS7L2reSL0GhF7 LOZlTAWG4LeuJQnt6GfpKVJlZgoR1/ucm1NLZDnJeJ6+14sB0CqMipd2XDse5shB zWzvdHn0yGF/RQEnEpZPhQv83crbLVBN2k56KoPkgxbuBwLRdmIZkvSSTXbeAqXy ovQWTGMQWxjT0IUYFylljFo1Djsx/aFeMm+MW5R+9bSL4DASg802ozi2oxVeSpzP lbYsp2ZOtPq3XkWRE3g2JeA/BEJiVJ0BRGUSuoSKUVRsvW4qwlGK1ZUFmNeQ+7xn 0tCucyAhpe/ir3eLm0fMpXk0haXzbpns6oxfudUdMXPLO6PwtYNC/DgBIxlnxDxQ 7G9YD6O63xsRLf3VclDVYgvgwpm6YEIVcjZ4pg/fk1IpKazEB1UlQl10UaFItRvC V7Vo6sK9wzs4GddNwXVJFa919IP3bRsFY7wnWDNES/Nb71vmzvZlk1eEMITn/F1S zxDr1MQdAnsiWYqG7CFjrWjVNCOK/1x7msmIdRpUB31TyMRnzFWxb4JxXEweVbRo VulT+c1fNVyag+YnIkI1nj/8U5zfPygZXMx4FQhMCtA4dqcBeN2W01P0vDJnUuVH zGASBV18/4F1MGduC9zKU1yW4pTxTt0/t/o/o4/SkAMz8BCDvo7vct+3+3Y9+v4p aovANFV1Q3cNt+0GMqQS =UYCf -----END PGP SIGNATURE----- From morrowc.lists at gmail.com Fri Jan 28 15:18:28 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 28 Jan 2011 16:18:28 -0500 Subject: Connectivity status for Egypt In-Reply-To: <4D432C36.5070404@sneep.net> References: <AANLkTimUaNCRFhQqBTPM6Z=W7WUfU8fZUFHGjbqXGJsq@mail.gmail.com> <4D421BB4.1000909@toonk.nl> <9CCC7D46-D578-4BA0-893C-BAE0D170253B@gmail.com> <4D4266DD.7000906@gmail.com> <1296200640.3123.3.camel@Decaf.NEEBU.Net> <AANLkTi=BrQ_m1ypzObszR8_Ta9hPuz_gw-x7ZJYqknJh@mail.gmail.com> <4D432C36.5070404@sneep.net> Message-ID: <AANLkTimH-Ng6dpZbLVMFnAO8pf24w_DaQNjyoLyTUCq2@mail.gmail.com> On Fri, Jan 28, 2011 at 3:51 PM, Alastair Johnson <aj at sneep.net> wrote: > For instance, our corporate WAN links into Cairo are still up (UUNET PIP). <cough> that's the MCI PIP</cough>... From Valdis.Kletnieks at vt.edu Fri Jan 28 15:16:41 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 28 Jan 2011 16:16:41 -0500 Subject: Connectivity status for Egypt In-Reply-To: Your message of "Fri, 28 Jan 2011 12:36:30 PST." <5A6D953473350C4B9995546AFE9939EE0BC136D6@RWC-EX1.corp.seven.com> References: <AANLkTimUaNCRFhQqBTPM6Z=W7WUfU8fZUFHGjbqXGJsq@mail.gmail.com> <4D421BB4.1000909@toonk.nl> <9CCC7D46-D578-4BA0-893C-BAE0D170253B@gmail.com> <4D4266DD.7000906@gmail.com> <1296200640.3123.3.camel@Decaf.NEEBU.Net> <AANLkTi=BrQ_m1ypzObszR8_Ta9hPuz_gw-x7ZJYqknJh@mail.gmail.com> <4DFB34E6-C056-480C-8406-D0D5285441F6@puck.nether.net> <7ACB6668-5DDC-4782-B775-F24A555EF45A@ianai.net> <1296245232.5676.8.camel@Decaf.NEEBU.Net> <5A6D953473350C4B9995546AFE9939EE0BC136D6@RWC-EX1.corp.seven.com> Message-ID: <31157.1296249401@localhost> On Fri, 28 Jan 2011 12:36:30 PST, George Bonser said: > I think it would be pretty hard to actually cut off communications when the > telephone system is still working. You can move a lot of email by dialup UUCP > if you wanted to. Sure, just pop onto amazon.com and order a modem... oh, wait. (It's certainly doable, but decidedly nontrivial, and will require much sneakernet to bootstrap) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110128/1d17a146/attachment.bin> From gbonser at seven.com Fri Jan 28 15:20:34 2011 From: gbonser at seven.com (George Bonser) Date: Fri, 28 Jan 2011 13:20:34 -0800 Subject: Connectivity status for Egypt In-Reply-To: <4D4331F7.5080507@knownelement.com> References: <AANLkTimUaNCRFhQqBTPM6Z=W7WUfU8fZUFHGjbqXGJsq@mail.gmail.com> <1296245232.5676.8.camel@Decaf.NEEBU.Net> <5A6D953473350C4B9995546AFE9939EE0BC136D6@RWC-EX1.corp.seven.com><201101282102.51666.a.harrowell@gmail.com> <4D4331F7.5080507@knownelement.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC136DD@RWC-EX1.corp.seven.com> I have also seen reports that Syria has severed their Internet access, as well: http://af.reuters.com/article/tunisiaNews/idAFLDE70P18Y20110126 http://twitter.com/AlArabiya_Eng/status/31002490816167936 Can anyone confirm that? From morrowc.lists at gmail.com Fri Jan 28 15:22:55 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 28 Jan 2011 16:22:55 -0500 Subject: Connectivity status for Egypt In-Reply-To: <AANLkTimH-Ng6dpZbLVMFnAO8pf24w_DaQNjyoLyTUCq2@mail.gmail.com> References: <AANLkTimUaNCRFhQqBTPM6Z=W7WUfU8fZUFHGjbqXGJsq@mail.gmail.com> <4D421BB4.1000909@toonk.nl> <9CCC7D46-D578-4BA0-893C-BAE0D170253B@gmail.com> <4D4266DD.7000906@gmail.com> <1296200640.3123.3.camel@Decaf.NEEBU.Net> <AANLkTi=BrQ_m1ypzObszR8_Ta9hPuz_gw-x7ZJYqknJh@mail.gmail.com> <4D432C36.5070404@sneep.net> <AANLkTimH-Ng6dpZbLVMFnAO8pf24w_DaQNjyoLyTUCq2@mail.gmail.com> Message-ID: <AANLkTinNYMnW0pNHt52xRAxb8NFr9yK7Srn0FL1N=GSz@mail.gmail.com> On Fri, Jan 28, 2011 at 4:18 PM, Christopher Morrow <morrowc.lists at gmail.com> wrote: > On Fri, Jan 28, 2011 at 3:51 PM, Alastair Johnson <aj at sneep.net> wrote: > >> For instance, our corporate WAN links into Cairo are still up (UUNET PIP). > > <cough> that's the MCI PIP</cough>... probably the .EG parts of that PIP are provided on a partner network still ... I don't think they have build of their own gear into the country, and there's a high likelihood that if state-security sees 'forbidden' traffic on those links they'll request traffic shutdown on that network as well. If you operate a network in the affected country I'm sure you'll have to comply with LEA demands... -chris From ncnet at sbcglobal.net Fri Jan 28 15:29:04 2011 From: ncnet at sbcglobal.net (Larry Stites) Date: Fri, 28 Jan 2011 13:29:04 -0800 Subject: Connectivity status for Egypt In-Reply-To: <4D432C95.1050400@knownelement.com> Message-ID: <C9687520.1B4119%ncnet@sbcglobal.net> Thank you Charles on 1/28/11 12:52 PM, Charles N Wyble wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 01/28/2011 12:36 PM, George Bonser wrote: >> >> >>> -----Original Message----- >>> From: Jake Khuon [mailto:khuon at neebu.net] >>> Sent: Friday, January 28, 2011 12:07 PM >>> To: Patrick W. Gilmore >>> Cc: NANOG list >>> Subject: Re: Connectivity status for Egypt >>> >>> On Fri, 2011-01-28 at 11:27 -0500, Patrick W. Gilmore wrote: >>> >>>> I think it does not matter. Censorship is censorship. (So much for >>> "routing around it".) >>> >> >> >> I think it would be pretty hard to actually cut off communications when the >> telephone system is still working. You can move a lot of email by dialup >> UUCP if you wanted to. > > Right. In a government regulated monopoly telcom carrier. > >> >> I am guessing that satellite internet still works > > If people can't afford to eat, I doubt they can afford satellite internet. > > and landline dialup to a modem outside the country still works. > > This presumes people have long distance plans. > > And there's always static routes :) > > To what? If everyone has dropped BGP sessions how are you as an end user > going to setup static routes? Unless there are no firewalls and > everything is wide open how would you reach gateways? > > > > > - -- > Charles N Wyble (charles at knownelement.com) > Systems craftsman for the stars > http://www.knownelement.com > Mobile: 626 539 4344 > Office: 310 929 8793 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQIcBAEBAgAGBQJNQyyUAAoJEMvvG/TyLEAt2ZoQALt3Arteje09ssqAkrbsretj > BuH1UyzK6VNpyk9q72p9C10XowqNE9BGTni+B1lZxh4VNY/cSdRaQFQO9DsMt+ww > dWl4HAu/PswRkWGrdQ2DIncRuXd8D6IOQ+ggv2I3cA6Pxi9Ep3rg5GF63+x1fTff > 6SCU+FWjTe4ghkeDkR7d2L/6DESJiZCR1DojBMIPf1/W8TTllqmCXflPW6cLgIlC > gBqiCVM24FhMBmNzGGjfcnfoQnCcwFD5qAVPBcMh0Y9Hz5olEN2F0tsgYSbG2szH > 3UD4ocZ07xLMAG1LdkjoEJmORdAQOv5GL2nkFFCi+/K6sMTyhRhBkO03DA0tOkRN > M/wJIrRMeSS5ur6NBy0PDgHcHYo138w5wUAoZi3B8JrfiP+cxJ+oEMm6LDDLTNV7 > NbKgpkUOeAvi+qhXo2BUbXpZv8Oh/OAedwIu7/5xHx8YPm2Bq9OTkZrPECslig/G > p2NCWpohbKfUn0EeN/NdutxWX/O6YY3y5mB/wfFasnr0kvi413QOMnRViOSgfNY/ > DTtpzTc7aahY0L2uAU21qTZIMDRuB/aYaHfbfsKpL2LGdxq/JFm6sQQ/IeN5Q7ii > 0QvMDM04Eqi4cCgut7p3DKTjkxFnU9Wilo/A8jeY4CRVH1I/Afft6aDh7GZNPKgr > QaEcUTQLrfCF284d1XSl > =QICt > -----END PGP SIGNATURE----- > ~.~ From franck at genius.com Fri Jan 28 15:37:23 2011 From: franck at genius.com (Franck Martin) Date: Sat, 29 Jan 2011 10:37:23 +1300 (FJST) Subject: Connectivity status for Egypt In-Reply-To: <EDFD4E4A-C01A-46A4-891E-8FCF90CED2CB@hopcount.ca> Message-ID: <33496563.960.1296250642067.JavaMail.franck@franck-martins-macbook-pro.local> If I'm correct, in 2000 in Fiji, the main fiber optic cable from the national provider to the international provider was sabotaged, cutting all communications. Fortunately an Alcatel team was on the island (SCC commissioning) with the right tools and could splice it back in a few hours, otherwise Fiji would have gone dark for days... ----- Original Message ----- From: "Joe Abley" <jabley at hopcount.ca> To: "Marshall Eubanks" <tme at americafree.tv> Cc: nanog at nanog.org Sent: Saturday, 29 January, 2011 7:32:07 AM Subject: Re: Connectivity status for Egypt On 2011-01-28, at 11:33, Marshall Eubanks wrote: > On Jan 28, 2011, at 11:24 AM, Jared Mauch wrote: > >> I have seen nation state disconnects where light is lost. > > I believe that was the case for Burma, for example. It was not the case in Nepal in 2005 though, if I remember correctly. In that case connectivity to the outside was maintained, but access to that connectivity by people inside the country was curtailed. Joe From a.harrowell at gmail.com Fri Jan 28 15:40:42 2011 From: a.harrowell at gmail.com (Alexander Harrowell) Date: Fri, 28 Jan 2011 21:40:42 +0000 Subject: Connectivity status for Egypt In-Reply-To: <AANLkTinNYMnW0pNHt52xRAxb8NFr9yK7Srn0FL1N=GSz@mail.gmail.com> References: <AANLkTimUaNCRFhQqBTPM6Z=W7WUfU8fZUFHGjbqXGJsq@mail.gmail.com> <AANLkTimH-Ng6dpZbLVMFnAO8pf24w_DaQNjyoLyTUCq2@mail.gmail.com> <AANLkTinNYMnW0pNHt52xRAxb8NFr9yK7Srn0FL1N=GSz@mail.gmail.com> Message-ID: <201101282140.53090.a.harrowell@gmail.com> On Friday 28 January 2011 21:22:55 Christopher Morrow wrote: > On Fri, Jan 28, 2011 at 4:18 PM, Christopher Morrow > > <morrowc.lists at gmail.com> wrote: > > On Fri, Jan 28, 2011 at 3:51 PM, Alastair Johnson <aj at sneep.net> wrote: > >> For instance, our corporate WAN links into Cairo are still up (UUNET > >> PIP). > > > > <cough> that's the MCI PIP</cough>... > > probably the .EG parts of that PIP are provided on a partner network > still ... I don't think they have build of their own gear into the > country, and there's a high likelihood that if state-security sees > 'forbidden' traffic on those links they'll request traffic shutdown on > that network as well. > > If you operate a network in the affected country I'm sure you'll have > to comply with LEA demands... > > -chris It's ironic that in 1991, the Soviet coup leaders had the international voice gateway shut down but left the Internet link up (who cares about some weird thing eggheads chat over?), but now, dictators in trouble pull all the BGP announcements but leave the PSTN up. Who cares about some old thing your mother uses? Not impressed by US journalists asking why the WH press secretary can't order Vodafone to turn their GSM net back on, though. 1) it's not them who would have to say no to the nice man from Central State Security with his electric shock baton, 2) VF.eg is half-owned by the Egyptian government... -- The only thing worse than e-mail disclaimers...is people who send e-mail to lists complaining about them -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110128/04527c77/attachment.bin> From andrew.wallace at rocketmail.com Fri Jan 28 15:44:17 2011 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Fri, 28 Jan 2011 13:44:17 -0800 (PST) Subject: Connectivity status for Egypt Message-ID: <535636.53395.qm@web59603.mail.ac4.yahoo.com> We should be asking the Egyptians to stagger the return of services so that infrastructure isn't affected, when connectivity is deemed to be allowed to come back online. Andrew Wallace --- British IT Security Consultant From cidr-report at potaroo.net Fri Jan 28 16:00:02 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 28 Jan 2011 22:00:02 GMT Subject: BGP Update Report Message-ID: <201101282200.p0SM02QR068968@wattle.apnic.net> BGP Update Report Interval: 20-Jan-11 -to- 27-Jan-11 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS32528 18632 1.3% 6210.7 -- ABBOTT Abbot Labs 2 - AS1785 18374 1.3% 10.4 -- AS-PAETEC-NET - PaeTec Communications, Inc. 3 - AS18025 16571 1.2% 460.3 -- ACE-1-WIFI-AS-AP Ace-1 Wifi Network 4 - AS35931 15587 1.1% 5195.7 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 5 - AS8452 15525 1.1% 9.4 -- TE-AS TE-AS 6 - AS33475 12203 0.9% 56.8 -- RSN-1 - RockSolid Network, Inc. 7 - AS23700 12199 0.9% 27.4 -- BM-AS-ID PT. Broadband Multimedia, Tbk 8 - AS9498 12187 0.9% 17.8 -- BBIL-AP BHARTI Airtel Ltd. 9 - AS24923 11360 0.8% 2840.0 -- SETTC South-East Transtelecom Joint Stock Co. 10 - AS24863 11133 0.8% 11.6 -- LINKdotNET-AS 11 - AS9829 10876 0.8% 28.2 -- BSNL-NIB National Internet Backbone 12 - AS15105 10194 0.7% 37.9 -- NETWORKTELEPHONE - Network Telephone Corporation 13 - AS25019 9838 0.7% 44.1 -- SAUDINETSTC-AS Autonomus System Number for SaudiNet 14 - AS17974 8548 0.6% 11.5 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 15 - AS6316 8282 0.6% 77.4 -- AS-PAETEC-NET - PaeTec Communications, Inc. 16 - AS36992 7722 0.5% 11.5 -- ETISALAT-MISR 17 - AS28573 7694 0.5% 12.1 -- NET Servicos de Comunicao S.A. 18 - AS30969 7082 0.5% 120.0 -- 19 - AS14420 6938 0.5% 11.3 -- CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP 20 - AS9198 6384 0.5% 14.0 -- KAZTELECOM-AS JSC Kazakhtelecom TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS32528 18632 1.3% 6210.7 -- ABBOTT Abbot Labs 2 - AS6401 5855 0.4% 5855.0 -- ALLST-6401 - Allstream Corp. 3 - AS35931 15587 1.1% 5195.7 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 4 - AS24923 11360 0.8% 2840.0 -- SETTC South-East Transtelecom Joint Stock Co. 5 - AS49776 2103 0.1% 2103.0 -- GORSET-AS Gorodskaya Set Ltd. 6 - AS49600 1504 0.1% 1504.0 -- LASEDA La Seda de Barcelona, S.A 7 - AS28175 1494 0.1% 1494.0 -- 8 - AS34239 1422 0.1% 1422.0 -- INTERAMERICAN General Insurance Company 9 - AS27771 2682 0.2% 1341.0 -- Instituto Venezolano de Investigaciones Cientificas 10 - AS40772 2648 0.2% 1324.0 -- VELOCITER-WIRELESS-INC - Velociter Wireless, Inc. 11 - AS36383 1764 0.1% 882.0 -- TRABERTECHNOLOGIES-NETWORK - Traber Technologies Inc. 12 - AS35914 1763 0.1% 881.5 -- FIREHOST-INC - FireHost, Inc. 13 - AS43605 659 0.1% 659.0 -- STRK-NET JSC STRK 14 - AS17408 3268 0.2% 653.6 -- ABOVE-AS-AP AboveNet Communications Taiwan 15 - AS9929 4377 0.3% 625.3 -- CNCNET-CN China Netcom Corp. 16 - AS4454 582 0.0% 582.0 -- TNET-AS - State of Tennessee 17 - AS45550 516 0.0% 516.0 -- NGT-AS-VN New Generations Telecommunications Corporation 18 - AS40168 488 0.0% 488.0 -- TOYOTA-PR - Toyota de Puerto Rico Corp. 19 - AS3 957 0.1% 333.0 -- VP-NET-SE Videoplaza AB 20 - AS18025 16571 1.2% 460.3 -- ACE-1-WIFI-AS-AP Ace-1 Wifi Network TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 213.129.96.0/19 11343 0.8% AS24923 -- SETTC South-East Transtelecom Joint Stock Co. 2 - 63.211.68.0/22 10105 0.7% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 3 - 130.36.34.0/24 9317 0.6% AS32528 -- ABBOTT Abbot Labs 4 - 130.36.35.0/24 9314 0.6% AS32528 -- ABBOTT Abbot Labs 5 - 216.126.136.0/22 7442 0.5% AS6316 -- AS-PAETEC-NET - PaeTec Communications, Inc. 6 - 159.18.255.0/24 5855 0.4% AS6401 -- ALLST-6401 - Allstream Corp. 7 - 198.140.43.0/24 5436 0.4% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 8 - 68.65.152.0/22 3700 0.2% AS11915 -- TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 9 - 67.210.226.0/24 3495 0.2% AS35914 -- FIREHOST-INC - FireHost, Inc. AS7819 -- GLOBAL-IP-NETWORKS - Global IP Networks INC 10 - 202.153.174.0/24 3254 0.2% AS17408 -- ABOVE-AS-AP AboveNet Communications Taiwan 11 - 27.123.248.0/22 3215 0.2% AS18025 -- ACE-1-WIFI-AS-AP Ace-1 Wifi Network 12 - 182.54.140.0/22 3210 0.2% AS18025 -- ACE-1-WIFI-AS-AP Ace-1 Wifi Network 13 - 182.54.148.0/22 3210 0.2% AS18025 -- ACE-1-WIFI-AS-AP Ace-1 Wifi Network 14 - 101.78.20.0/22 3199 0.2% AS18025 -- ACE-1-WIFI-AS-AP Ace-1 Wifi Network 15 - 101.78.24.0/22 3198 0.2% AS18025 -- ACE-1-WIFI-AS-AP Ace-1 Wifi Network 16 - 206.184.16.0/24 3190 0.2% AS174 -- COGENT Cogent/PSI 17 - 76.74.88.0/23 2430 0.2% AS6517 -- RELIANCEGLOBALCOM - Reliance Globalcom Services, Inc 18 - 187.86.13.0/24 2246 0.1% AS28135 -- 19 - 213.108.216.0/21 2103 0.1% AS49776 -- GORSET-AS Gorodskaya Set Ltd. 20 - 183.88.0.0/16 2072 0.1% AS45629 -- JASTEL-NETWORK-TH-AP Jasmine International Tower AS45758 -- TRIPLETNET-AS-AP TripleT Internet Internet service provider Bangkok Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu 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 Jan 28 16:00:00 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 28 Jan 2011 22:00:00 GMT Subject: The Cidr Report Message-ID: <201101282200.p0SM00aS068962@wattle.apnic.net> This report has been generated at Fri Jan 28 21:11:57 2011 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 21-01-11 344825 201651 22-01-11 344975 201806 23-01-11 344876 201935 24-01-11 345075 201872 25-01-11 345142 201967 26-01-11 345293 201663 27-01-11 344858 200621 28-01-11 342381 201194 AS Summary 36544 Number of ASes in routing system 15508 Number of ASes announcing only one prefix 3710 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 106681344 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'). --- 28Jan11 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 342245 201128 141117 41.2% All ASes AS6389 3710 270 3440 92.7% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 2625 409 2216 84.4% TWTC - tw telecom holdings, inc. AS19262 1841 285 1556 84.5% VZGNI-TRANSIT - Verizon Online LLC AS4766 1915 544 1371 71.6% KIXS-AS-KR Korea Telecom AS6478 1476 245 1231 83.4% ATT-INTERNET3 - AT&T Services, Inc. AS22773 1274 86 1188 93.2% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS4755 1402 341 1061 75.7% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS1785 1790 768 1022 57.1% AS-PAETEC-NET - PaeTec Communications, Inc. AS28573 1246 304 942 75.6% NET Servicos de Comunicao S.A. AS10620 1357 443 914 67.4% Telmex Colombia S.A. AS7545 1596 727 869 54.4% TPG-INTERNET-AP TPG Internet Pty Ltd AS6503 1150 376 774 67.3% Axtel, S.A.B. de C.V. AS18101 922 152 770 83.5% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS24560 1094 333 761 69.6% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS7303 886 126 760 85.8% Telecom Argentina S.A. AS4808 1032 316 716 69.4% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS3356 1186 489 697 58.8% LEVEL3 Level 3 Communications AS17488 950 281 669 70.4% HATHWAY-NET-AP Hathway IP Over Cable Internet AS18566 1125 482 643 57.2% COVAD - Covad Communications Co. AS9498 745 110 635 85.2% BBIL-AP BHARTI Airtel Ltd. AS11492 1269 648 621 48.9% CABLEONE - CABLE ONE, INC. AS17676 647 69 578 89.3% GIGAINFRA Softbank BB Corp. AS855 633 57 576 91.0% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS8151 1185 616 569 48.0% Uninet S.A. de C.V. AS7552 649 102 547 84.3% VIETEL-AS-AP Vietel Corporation AS22047 566 31 535 94.5% VTR BANDA ANCHA S.A. AS14420 614 97 517 84.2% CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP AS3549 860 352 508 59.1% GBLX Global Crossing Ltd. AS9443 570 75 495 86.8% INTERNETPRIMUS-AS-AP Primus Telecommunications AS4804 571 77 494 86.5% MPX-AS Microplex PTY LTD Total 36886 9211 27675 75.0% Top 30 total Possible Bogus Routes 5.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 5.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 5.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 24.129.192.0/19 AS7922 COMCAST-7922 - Comcast Cable Communications, Inc. 37.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 37.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 37.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 46.227.80.0/21 AS8304 AS8304 ECRITEL Company 46.227.96.0/21 AS12611 RKOM R-KOM Regensburger Telekommunikations GmbH & Co. KG 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.18.224.0/20 AS12129 123NET - 123.Net, Inc. 64.21.192.0/20 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.212.0/22 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.216.0/21 AS11610 INETNEBR-1 - Internet Nebraska Corporation 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 69.6.81.0/24 AS13442 71.19.134.0/23 AS3313 INET-AS I.NET S.p.A. 72.22.32.0/19 AS33150 72.22.61.0/24 AS33150 72.22.62.0/24 AS33150 76.77.32.0/19 AS2828 XO-AS15 - XO Communications 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 96.45.161.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.162.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.163.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.164.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.165.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.166.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.167.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.168.0/21 AS3257 TINET-BACKBONE Tinet SpA 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas 110.173.64.0/19 AS37963 CNNIC-ALIBABA-CN-NET-AP Alibaba (China) Technology Co., Ltd. 113.29.0.0/17 AS3549 GBLX Global Crossing Ltd. 113.29.0.0/20 AS3549 GBLX Global Crossing Ltd. 113.29.16.0/20 AS3549 GBLX Global Crossing Ltd. 113.29.32.0/20 AS3549 GBLX Global Crossing Ltd. 113.29.64.0/20 AS3549 GBLX Global Crossing Ltd. 115.42.28.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.30.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.40.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.42.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.44.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.47.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.48.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.49.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.50.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.51.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.52.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.53.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.54.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.55.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.56.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.57.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.58.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.59.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.61.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.62.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.63.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 116.68.136.0/21 AS28045 Pantel Communications 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 121.54.160.0/24 AS38890 121.54.161.0/24 AS38890 121.54.162.0/24 AS38890 121.54.163.0/24 AS38890 121.54.164.0/24 AS38890 121.54.166.0/24 AS38890 121.54.167.0/24 AS38890 121.200.192.0/24 AS17767 122.200.32.0/20 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 122.200.40.0/21 AS38272 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services Inc. 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 172.12.0.0/18 AS28665 PredialNet Provedor de Internet Ltda. 176.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 176.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 176.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 181.82.176.224/27 AS45976 CNYGE-AS-KR chungcheongnamdo yeongi office of education 181.82.177.0/26 AS45976 CNYGE-AS-KR chungcheongnamdo yeongi office of education 190.102.32.0/20 AS30058 FDCSERVERS - FDCservers.net 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.101.46.0/24 AS6503 Axtel, S.A.B. de C.V. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 196.6.108.0/24 AS5713 SAIX-NET 196.13.201.0/24 AS2018 TENET-1 196.13.202.0/24 AS2018 TENET-1 196.13.203.0/24 AS2018 TENET-1 196.13.204.0/24 AS2018 TENET-1 196.110.105.0/24 AS8513 SKYVISION SkyVision Network Services 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.15.4.0/24 AS4323 TWTC - tw telecom holdings, inc. 198.15.5.0/24 AS4323 TWTC - tw telecom holdings, inc. 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.99.241.0/24 AS11797 AC-NIELSEN-AS AC NIELSEN 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.175.231.0/24 AS19262 VZGNI-TRANSIT - Verizon Online LLC 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 198.182.235.0/24 AS3356 LEVEL3 Level 3 Communications 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 199.185.130.0/23 AS19662 UNISERVE-ONLINE - Uniserve On Line 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.233.92.0/24 AS26896 D102-ITC - Data 102, LLC 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.24.73.0/24 AS26061 Equant Colombia 200.24.78.0/26 AS3549 GBLX Global Crossing Ltd. 200.24.78.64/26 AS3549 GBLX Global Crossing Ltd. 202.1.224.0/24 AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000 202.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.20.108.0/23 AS17885 JKTXLNET-AS-AP PT Excelcomindo Pratama 202.58.113.0/24 AS19161 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.66.128.0/18 AS9584 GENESIS-AP Diyixian.com Limited 202.66.160.0/19 AS9584 GENESIS-AP Diyixian.com Limited 202.66.160.0/20 AS9584 GENESIS-AP Diyixian.com Limited 202.66.176.0/20 AS9584 GENESIS-AP Diyixian.com Limited 202.66.184.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.186.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.188.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.189.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.190.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.133.37.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.146.186.0/24 AS23655 SNAP-NZ-AS Snap Internet Limited 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 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.130.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.131.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.133.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 202.179.144.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.149.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.150.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.18.156.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.22.78.0/24 AS18117 HARBOURMSP-AU-AP Harbour MSP Pty. Ltd 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.27.123.0/24 AS4739 CIX-ADELAIDE-AS Internode Systems Pty Ltd 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.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.142.219.0/24 AS45149 203.175.107.0/24 AS45595 PKTELECOM-AS-PK Pakistan Telecom Company Limited 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.10.232.0/21 AS33150 204.19.14.0/23 AS577 BACOM - Bell Canada 204.209.114.0/24 AS13768 PEER1 - Peer 1 Network Inc. 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.207.148.0/23 AS812 ROGERS-CABLE - Rogers Cable Communications Inc. 205.210.145.0/24 AS11814 DISTRIBUTEL-AS11814 - DISTRIBUTEL COMMUNICATIONS LTD. 206.72.192.0/23 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 206.72.194.0/23 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 206.123.129.0/24 AS10790 INREACH-AS - InReach Internet 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.188.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.189.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.190.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.191.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.64.200.0/22 AS11730 CIL-ASN - Circle Internet LTD 208.64.240.0/21 AS13871 TELEBYTE-NW - Telebyte NW 208.73.160.0/24 AS32767 208.78.165.0/24 AS16565 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.83.54.0/24 AS23485 SEI-LLC-AS-NUM - SEI LLC 208.89.60.0/22 AS40626 208.92.196.0/22 AS10929 NETELLIGENT - Netelligent Hosting Services Inc. 208.92.199.0/24 AS26198 3MENATWORK - 3Men at Work Integrated Networks, Inc. 208.94.48.0/21 AS19406 TWRS-MA - Towerstream I, Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.141.32.0/19 AS53667 PONYNET - FranTech Solutions 209.165.239.0/24 AS209 ASN-QWEST - Qwest Communications Company, LLC 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.213.1.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 209.213.4.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 216.10.235.0/24 AS13780 NTNCOMMUNICATIONS - NTN 216.10.236.0/24 AS13780 NTNCOMMUNICATIONS - NTN 216.21.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 216.21.196.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.201.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.202.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.206.0/23 AS12251 INVISION - Invision.com, Inc. 216.58.192.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.197.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.200.0/24 AS18530 ISOMEDIA-1 - Isomedia Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.194.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 216.250.112.0/20 AS7296 ALCHEMYNET - Alchemy Communications, Inc. Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From netfortius at gmail.com Fri Jan 28 16:01:24 2011 From: netfortius at gmail.com (Stefan) Date: Fri, 28 Jan 2011 16:01:24 -0600 Subject: Connectivity status for Egypt In-Reply-To: <535636.53395.qm@web59603.mail.ac4.yahoo.com> References: <535636.53395.qm@web59603.mail.ac4.yahoo.com> Message-ID: <AANLkTimxo-GCj4Wv_naJ3Ck8ab+EK2dwwh7fVg6FrEjG@mail.gmail.com> On Fri, Jan 28, 2011 at 3:44 PM, andrew.wallace <andrew.wallace at rocketmail.com> wrote: > We should be asking the Egyptians to stagger the return of services so that infrastructure isn't affected, when connectivity is deemed to be allowed to come back online. > > Andrew Wallace > > --- > > British IT Security Consultant http://lifehacker.com/5746046/how-to-foil-a-nationwide-internet-shutdown ***Stefan Mititelu http://twitter.com/netfortius http://www.linkedin.com/in/netfortius From nonobvious at gmail.com Fri Jan 28 16:07:51 2011 From: nonobvious at gmail.com (Bill Stewart) Date: Fri, 28 Jan 2011 14:07:51 -0800 Subject: Connectivity status for Egypt In-Reply-To: <535636.53395.qm@web59603.mail.ac4.yahoo.com> References: <535636.53395.qm@web59603.mail.ac4.yahoo.com> Message-ID: <AANLkTi=xVx8-Sz=ww4AmumX9grsQPHOkPTa_AWph00VP@mail.gmail.com> On 1/28/11, andrew.wallace <andrew.wallace at rocketmail.com> wrote: > We should be asking the Egyptians to stagger the return of services so that > infrastructure isn't affected, when connectivity is deemed to be allowed to > come back online. Well, yeah, it has to be done carefully, otherwise the first guy to turn on an E1 line that announces routes for the entire country is going to have his router overheat and the blue smoke get out.... If we're lucky, the Army won't damage too much as they either win or lose. -- ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it. From michiel at klaver.it Fri Jan 28 16:12:17 2011 From: michiel at klaver.it (Michiel Klaver) Date: Fri, 28 Jan 2011 23:12:17 +0100 Subject: Best current looking glass software builds In-Reply-To: <002701cbbf09$8b658c10$a230a430$@unwiredltd.com> References: <002701cbbf09$8b658c10$a230a430$@unwiredltd.com> Message-ID: <4D433F41.2050709@klaver.it> At 22-07-2011 20:59, Peter Kranz wrote: > Anyone done a recent scan of newer looking glass software implementations > for apache? We've used cougar's for several years, but have been problems > with its SSH implementation lately. > Development of the Version6 LookingGlass can be found here, the latest version also supports proper SSH-v2: https://github.com/Cougar/lg From web at typo.org Fri Jan 28 16:15:24 2011 From: web at typo.org (Wayne E. Bouchard) Date: Fri, 28 Jan 2011 15:15:24 -0700 Subject: Connectivity status for Egypt In-Reply-To: <AANLkTi=xVx8-Sz=ww4AmumX9grsQPHOkPTa_AWph00VP@mail.gmail.com> References: <535636.53395.qm@web59603.mail.ac4.yahoo.com> <AANLkTi=xVx8-Sz=ww4AmumX9grsQPHOkPTa_AWph00VP@mail.gmail.com> Message-ID: <20110128221524.GA47761@typo.org> On Fri, Jan 28, 2011 at 02:07:51PM -0800, Bill Stewart wrote: > On 1/28/11, andrew.wallace <andrew.wallace at rocketmail.com> wrote: > > We should be asking the Egyptians to stagger the return of services so that > > infrastructure isn't affected, when connectivity is deemed to be allowed to > > come back online. > > Well, yeah, it has to be done carefully, otherwise the first guy to > turn on an E1 line that announces routes for the entire country is > going to have his router overheat and the blue smoke get out.... If > we're lucky, the Army won't damage too much as they either win or > lose. It depends on what remains functional after the fact. If there is no demand for traffic, then routes will be stable and the session will stay active. If the link fills, the session bounces as packets get dropped. It also depends on whether the person turning up that first E1 actually has much behind them and whether those people have much connectivity that doesn't require shrapnel removal. --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From deleskie at gmail.com Fri Jan 28 16:32:39 2011 From: deleskie at gmail.com (jim deleskie) Date: Fri, 28 Jan 2011 18:32:39 -0400 Subject: Connectivity status for Egypt In-Reply-To: <AANLkTimH-Ng6dpZbLVMFnAO8pf24w_DaQNjyoLyTUCq2@mail.gmail.com> References: <AANLkTimUaNCRFhQqBTPM6Z=W7WUfU8fZUFHGjbqXGJsq@mail.gmail.com> <4D421BB4.1000909@toonk.nl> <9CCC7D46-D578-4BA0-893C-BAE0D170253B@gmail.com> <4D4266DD.7000906@gmail.com> <1296200640.3123.3.camel@Decaf.NEEBU.Net> <AANLkTi=BrQ_m1ypzObszR8_Ta9hPuz_gw-x7ZJYqknJh@mail.gmail.com> <4D432C36.5070404@sneep.net> <AANLkTimH-Ng6dpZbLVMFnAO8pf24w_DaQNjyoLyTUCq2@mail.gmail.com> Message-ID: <AANLkTik=k_qQ22=2yzO-ZYMgyTaO4_t7C8OhXC4ucfX1@mail.gmail.com> iMCI or WCOM? :) On Fri, Jan 28, 2011 at 5:18 PM, Christopher Morrow <morrowc.lists at gmail.com > wrote: > On Fri, Jan 28, 2011 at 3:51 PM, Alastair Johnson <aj at sneep.net> wrote: > > > For instance, our corporate WAN links into Cairo are still up (UUNET > PIP). > > <cough> that's the MCI PIP</cough>... > > From morrowc.lists at gmail.com Fri Jan 28 17:06:03 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 28 Jan 2011 18:06:03 -0500 Subject: Connectivity status for Egypt In-Reply-To: <AANLkTik=k_qQ22=2yzO-ZYMgyTaO4_t7C8OhXC4ucfX1@mail.gmail.com> References: <AANLkTimUaNCRFhQqBTPM6Z=W7WUfU8fZUFHGjbqXGJsq@mail.gmail.com> <4D421BB4.1000909@toonk.nl> <9CCC7D46-D578-4BA0-893C-BAE0D170253B@gmail.com> <4D4266DD.7000906@gmail.com> <1296200640.3123.3.camel@Decaf.NEEBU.Net> <AANLkTi=BrQ_m1ypzObszR8_Ta9hPuz_gw-x7ZJYqknJh@mail.gmail.com> <4D432C36.5070404@sneep.net> <AANLkTimH-Ng6dpZbLVMFnAO8pf24w_DaQNjyoLyTUCq2@mail.gmail.com> <AANLkTik=k_qQ22=2yzO-ZYMgyTaO4_t7C8OhXC4ucfX1@mail.gmail.com> Message-ID: <AANLkTinGvhL9AUjP1HnU-+zLGmVmMyBCmYFZ+5-kkQpO@mail.gmail.com> On Fri, Jan 28, 2011 at 5:32 PM, jim deleskie <deleskie at gmail.com> wrote: > iMCI or WCOM? :) w (technically the folks that engineered it were mci folk... from texas. > On Fri, Jan 28, 2011 at 5:18 PM, Christopher Morrow > <morrowc.lists at gmail.com> wrote: >> >> On Fri, Jan 28, 2011 at 3:51 PM, Alastair Johnson <aj at sneep.net> wrote: >> >> > For instance, our corporate WAN links into Cairo are still up (UUNET >> > PIP). >> >> <cough> that's the MCI PIP</cough>... >> > > From blake at ispn.net Fri Jan 28 17:29:04 2011 From: blake at ispn.net (Blake Hudson) Date: Fri, 28 Jan 2011 17:29:04 -0600 Subject: test-ipv6.com In-Reply-To: <alpine.BSF.2.00.1101271448000.15852@goat.gigo.com> References: <alpine.BSF.2.00.1101271448000.15852@goat.gigo.com> Message-ID: <4D435140.7020207@ispn.net> Does this site have an AAAA record? If so, my DNS does not pick it up. > [root at ns1 ~]# dig AAAA test-ipv6.com > > ; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 <<>> AAAA test-ipv6.com > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12875 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;test-ipv6.com. IN AAAA > > ;; AUTHORITY SECTION: > test-ipv6.com. 360 IN SOA ns1.gigo.com. > root.ns1.gigo.com. 2011010101 86400 7200 3600000 172800 > > ;; Query time: 216 msec > ;; SERVER: 64.35.208.1#53(64.35.208.1) > ;; WHEN: Fri Jan 28 17:27:20 2011 > ;; MSG SIZE rcvd: 81 > > [root at ns1 ~]# dig AAAA www.test-ipv6.com > > ; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 <<>> AAAA www.test-ipv6.com > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12788 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;www.test-ipv6.com. IN AAAA > > ;; ANSWER SECTION: > www.test-ipv6.com. 360 IN CNAME test-ipv6.com. > > ;; AUTHORITY SECTION: > test-ipv6.com. 355 IN SOA ns1.gigo.com. > root.ns1.gigo.com. 2011010101 86400 7200 3600000 172800 > > ;; Query time: 59 msec > ;; SERVER: 64.35.208.1#53(64.35.208.1) > ;; WHEN: Fri Jan 28 17:27:25 2011 > ;; MSG SIZE rcvd: 99 -------- Original Message -------- Subject: test-ipv6.com From: Jason Fesler <jfesler at gigo.com> To: nanog at nanog.org Date: Thursday, January 27, 2011 5:08:43 PM > Several people have suggested I (re)post information about > test-ipv6.com here. > > http://test-ipv6.com .. > tests ipv4 and ipv6 by dns name > tests dual stack (will the client break on World IPv6 Day?) > tests ipv6 by IP literal (teredo can pass this) > gives advice to end user about current status and (depending on > circumstances) more information > "broken" users (can't connect to dual stack) are solicited for info > Caution: does depend on javascript. > > http://test-ipv6.com/simple_test.html > Eyeball test only for user, with instructions; no javascript required. > > Please direct any comments, flames, etc directly to me instead of the > list. I've added enough noise already :-) > > From kevin at steadfast.net Fri Jan 28 17:45:55 2011 From: kevin at steadfast.net (Kevin Stange) Date: Fri, 28 Jan 2011 17:45:55 -0600 Subject: test-ipv6.com In-Reply-To: <4D435140.7020207@ispn.net> References: <alpine.BSF.2.00.1101271448000.15852@goat.gigo.com> <4D435140.7020207@ispn.net> Message-ID: <4D435533.6090704@steadfast.net> On 01/28/2011 05:29 PM, Blake Hudson wrote: > Does this site have an AAAA record? If so, my DNS does not pick it up. It does not and explains why on its FAQ: http://test-ipv6.com/faq.html -- Kevin Stange Chief Technology Officer Steadfast Networks http://steadfast.net Phone: 312-602-2689 ext. 203 | Fax: 312-602-2688 | Cell: 312-320-5867 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 261 bytes Desc: OpenPGP digital signature URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110128/e8ceb5c9/attachment.bin> From nonobvious at gmail.com Fri Jan 28 18:02:58 2011 From: nonobvious at gmail.com (Bill Stewart) Date: Fri, 28 Jan 2011 16:02:58 -0800 Subject: Ipv6 for the content provider In-Reply-To: <024EC9AD-2FD3-406A-A3DA-868152F33187@delong.com> References: <4D406670.8040202@knownelement.com> <5A6D953473350C4B9995546AFE9939EE0BC1361D@RWC-EX1.corp.seven.com> <024EC9AD-2FD3-406A-A3DA-868152F33187@delong.com> Message-ID: <AANLkTin+atGQ+2JDJhzU0m2QZbTzQkSU_KcDwfTcbBaK@mail.gmail.com> On 1/26/11, Owen DeLong <owen at delong.com> wrote: > And if your servers behind the LB aren't prepared for it, > you lose a LOT of logging data, geolocation capabilities, > and some other things if you go that route. Of course, anybody expecting a current IPv4 geolocation service to provide accurate information over IPv6 over the next couple of years is wildly optimistic (with all due respect to people in that business, but just sayin' good luck with that...) Maybe you'll get some consistency about which continent they're on based on the RIR the addresses came from, but even that's probably dodgy if the address belongs to Hurricane Electric or Sixxs or some other popular tunnel broker, and maybe you'll get some consistency on "is it the same /56 as last time?", and maybe some of them will start doing tricks like putting web bugs for "ipv4tracker.geolocator-example.com" and "ipv6tracker.geolocator-example.com" on the same web pages to try to start building correlation information, and if course you need your application that uses the information to speak IPv6 and handle 128-bit records and not just 32-bit. -- ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it. From john at sackheads.org Fri Jan 28 18:07:09 2011 From: john at sackheads.org (John Payne) Date: Fri, 28 Jan 2011 19:07:09 -0500 Subject: What's the current state of major access networks in North America ipv6 delivery status? In-Reply-To: <4D409787.8050104@knownelement.com> References: <4D409787.8050104@knownelement.com> Message-ID: <815DAAE1-6FE7-4207-A1DE-36780533F197@sackheads.org> On Jan 26, 2011, at 4:52 PM, Charles N Wyble <charles at knownelement.com> wrote: > Comcast is currently conducting trials: > http://comcast6.net/ (anyone participated in this?) Yes, and other than the fact that their 6rd implementation only gives me a /64, I've been really happy with it. My wife doesn't even know that her iOS devices and win7 box are dual stacked :) From brunner at nic-naa.net Fri Jan 28 18:12:36 2011 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Fri, 28 Jan 2011 19:12:36 -0500 Subject: in case of prefix withdrawal, dial-out In-Reply-To: <AANLkTinGvhL9AUjP1HnU-+zLGmVmMyBCmYFZ+5-kkQpO@mail.gmail.com> References: <AANLkTimUaNCRFhQqBTPM6Z=W7WUfU8fZUFHGjbqXGJsq@mail.gmail.com> <4D421BB4.1000909@toonk.nl> <9CCC7D46-D578-4BA0-893C-BAE0D170253B@gmail.com> <4D4266DD.7000906@gmail.com> <1296200640.3123.3.camel@Decaf.NEEBU.Net> <AANLkTi=BrQ_m1ypzObszR8_Ta9hPuz_gw-x7ZJYqknJh@mail.gmail.com> <4D432C36.5070404@sneep.net> <AANLkTimH-Ng6dpZbLVMFnAO8pf24w_DaQNjyoLyTUCq2@mail.gmail.com> <AANLkTik=k_qQ22=2yzO-ZYMgyTaO4_t7C8OhXC4ucfX1@mail.gmail.com> <AANLkTinGvhL9AUjP1HnU-+zLGmVmMyBCmYFZ+5-kkQpO@mail.gmail.com> Message-ID: <4D435B74.3000307@nic-naa.net> It is my son's turn to have the laptop so I won't bother to translate. The non-francophones can use Google's auto-xlate bot. http://www.lemonde.fr/technologies/article/2011/01/28/pour-contourner-le-blocage-du-web-les-modems-56k_1471819_651865.html From nonobvious at gmail.com Fri Jan 28 18:16:08 2011 From: nonobvious at gmail.com (Bill Stewart) Date: Fri, 28 Jan 2011 16:16:08 -0800 Subject: DSL options in NYC for OOB access In-Reply-To: <4D3DF769.7060601@nexus6.co.za> References: <4D3DF769.7060601@nexus6.co.za> Message-ID: <AANLkTinBEjrL6iwm1xYujA0OZiqGzfRwgXRM_b9D6Y0=@mail.gmail.com> On 1/24/11, Andy Ashley <lists at nexus6.co.za> wrote: > Im looking for a little advice about DSL circuits in New York, > specifically at 111 8th Ave. > Going to locate a console server there for out-of-band serial management. > The router will need connectivity for remote telnet/ssh access from the NOC. How much bandwidth do you need? Is a dialup modem fast enough? Traditional phone lines often give you a much different set of reliability issues and common-mode failures than Internet connectivity, which is good. I've been very happy with Pushkablue's dialup out-of-band boxes, which give you a serial console and power supply relays. Similarly, if wireless works in the part of the building you're in, and if the building allows you to have equipment that transmits radio signals (some colos don't), that's another option, again, because it's going to have different failures than the equipment you're controlling. > I searched some obvious providers but dont really want to deal with a > huge company (Verizon, Qwest, ?) if it can be avoided. .... > Are there smaller/independent companies out there offering > this sort of thing? > I dont know much about the US DSL market, so any hints are welcome. If you don't know the market, then there's a whole lot of value in dealing with the two or three dominant players for that city, or the two dozen huge companies for the country, as opposed to the hundreds or thousands of small players. (Admittedly, having dealt with ZA's dominant player in a previous job, I'd rather use anybody else also...) -- ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it. From shadowedstranger at gmail.com Fri Jan 28 14:35:43 2011 From: shadowedstranger at gmail.com (Jacob Broussard) Date: Fri, 28 Jan 2011 12:35:43 -0800 Subject: Bogons In-Reply-To: <03AF91C1-A63E-47B2-9C15-BFDC1965EA95@sackheads.org> References: <F6427296-2D81-40A2-B578-95BD27B8CE35@sackheads.org> <A28DCA86-6934-4ABE-B2E9-B951B013D44F@sackheads.org> <5A6D953473350C4B9995546AFE9939EE0BC136D4@RWC-EX1.corp.seven.com> <03AF91C1-A63E-47B2-9C15-BFDC1965EA95@sackheads.org> Message-ID: <AANLkTimzEvNKw9CSOeS+RHPxXPuNFWKV8fF1rM7aoCN8@mail.gmail.com> Static bogons are the bane of my existence... The pain of trying to explain to someone for MONTHS that they haven't updated their reference, with traceroutes to back it up, and they continue to say that it has something to do with my network. On Jan 28, 2011 12:24 PM, "John Payne" <john at sackheads.org> wrote: > > On Jan 28, 2011, at 3:14 PM, George Bonser wrote: > >> >> >>> Now that the holidays are over and IANA v4 depletion is likely days >>> away, perhaps its time to consider stripping your bogon lists down to >>> the bare minimum, and as someone else said, declare bogons dead and >>> move to martians? >>> >>> >>> Just sayin' >>> >> >> There are still some 7,000 prefixes in the v4 "full bogons" list. These >> are such things as allocations to RIR's but have not yet been allocated. >> It's updated every four hours: >> >> >> >> http://www.team-cymru.org/Services/Bogons/fullbogons-ipv4.txt >> >> " The traditional bogon prefixes, plus prefixes that have been >> allocated to RIRs but not yet assigned by those RIRs to ISPs, end-users, >> etc. Updated every four hours." >> >> That is one probably best taken by BGP feed and not done manually. > > Yes, I was referring to static/manual bogon list. The Cymru BGP feed rocks. > > From mbassett at intelius.com Fri Jan 28 19:39:26 2011 From: mbassett at intelius.com (Mark Bassett) Date: Fri, 28 Jan 2011 17:39:26 -0800 Subject: Upload config to juniper In-Reply-To: <AANLkTi=R6bTmpBtj=oUbyDuCG8xC-cMgEJodRhSxbTFh@mail.gmail.com> References: <AANLkTinEpsHaVcro9io3gCpHeCKwpNHg9zBSAY+7oZKJ@mail.gmail.com> <AANLkTi=R6bTmpBtj=oUbyDuCG8xC-cMgEJodRhSxbTFh@mail.gmail.com> Message-ID: <8E80582D6651CB47BE5B9CE81D63D0480D09D5F8@exchange2.intelius1.intelius.com> Actually if you use the JUNOS api and the reference scripts there are examples to do just this. -----Original Message----- From: Jimmy Hess [mailto:mysidia at gmail.com] Sent: Wednesday, January 26, 2011 6:31 PM To: Florin Veres Cc: nanog at nanog.org Subject: Re: Upload config to juniper On Mon, Jan 24, 2011 at 7:39 AM, Florin Veres <florin at futurefreedom.ro> wrote: > Hey guys, > Do any of you have any idea if it's possible to upload configuration from a > script (prefix-list updates in this case) to a JunOS device (MX)? > For Cisco devices I'm doing it using rcp. >From config mode use a "load merge" command that specifies a SCP or FTP URL. You'll need to setup SSH keys in advance to do so without an additional password for the device to download the script. Alternatively... SCP the file to a temporary file on the device then "load merge" the uploaded file, to merge config from the script. Net::SSH::Expect from CPAN to connect via ssh from perl. Something like use Net::SSH::Perl; use Net::SSH::Expect; my $ssh = Net::SSH::Expect->new( host => 'myfavoritehostname.example.com', user => 'blahblahblah', password => '1234', raw_pty => 1); $ssh->login(q[blahblah at myfavoritehostname.example.com's password]); $output1 = $ssh->exec("configure private"); # $blah = $ssh->exec("load merge username at scriptserver.example.com:/path/to/scriptfile_to_load.txt"); print scalar $ssh->exec("show | compare"); # commit -- -JH From mpalmer at hezmatt.org Fri Jan 28 19:41:39 2011 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Sat, 29 Jan 2011 12:41:39 +1100 Subject: Bogons In-Reply-To: <AANLkTimzEvNKw9CSOeS+RHPxXPuNFWKV8fF1rM7aoCN8@mail.gmail.com> References: <F6427296-2D81-40A2-B578-95BD27B8CE35@sackheads.org> <A28DCA86-6934-4ABE-B2E9-B951B013D44F@sackheads.org> <5A6D953473350C4B9995546AFE9939EE0BC136D4@RWC-EX1.corp.seven.com> <03AF91C1-A63E-47B2-9C15-BFDC1965EA95@sackheads.org> <AANLkTimzEvNKw9CSOeS+RHPxXPuNFWKV8fF1rM7aoCN8@mail.gmail.com> Message-ID: <20110129014139.GJ3684@hezmatt.org> On Fri, Jan 28, 2011 at 12:35:43PM -0800, Jacob Broussard wrote: > Static bogons are the bane of my existence... The pain of trying to explain > to someone for MONTHS that they haven't updated their reference, with > traceroutes to back it up, and they continue to say that it has something to > do with my network. THey're right -- your network is using an address range they've chosen to configure their equipment not to accept... <grin> - Matt From mbassett at intelius.com Fri Jan 28 19:44:30 2011 From: mbassett at intelius.com (Mark Bassett) Date: Fri, 28 Jan 2011 17:44:30 -0800 Subject: Upload config to juniper In-Reply-To: <8E80582D6651CB47BE5B9CE81D63D0480D09D5F8@exchange2.intelius1.intelius.com> References: <AANLkTinEpsHaVcro9io3gCpHeCKwpNHg9zBSAY+7oZKJ@mail.gmail.com><AANLkTi=R6bTmpBtj=oUbyDuCG8xC-cMgEJodRhSxbTFh@mail.gmail.com> <8E80582D6651CB47BE5B9CE81D63D0480D09D5F8@exchange2.intelius1.intelius.com> Message-ID: <8E80582D6651CB47BE5B9CE81D63D0480D09D5FC@exchange2.intelius1.intelius.com> I use the Netconf API and send xml config snippets like so: <configuration> <security> <zones> <security-zone> <name>Untrust</name> <address-book> <address operation="delete"> <name>auto_ip-7</name> <ip-prefix>67.23.7.115/32</ip-prefix> </address> <address-set> <name>demo_inbound_permit</name> <address operation="delete"> <name>auto_ip-7</name> </address> </address-set> </address-book> </security-zone> </zones> </security> </configuration> -----Original Message----- From: Mark Bassett [mailto:mbassett at intelius.com] Sent: Friday, January 28, 2011 5:39 PM To: Jimmy Hess; Florin Veres Cc: nanog at nanog.org Subject: RE: Upload config to juniper Actually if you use the JUNOS api and the reference scripts there are examples to do just this. -----Original Message----- From: Jimmy Hess [mailto:mysidia at gmail.com] Sent: Wednesday, January 26, 2011 6:31 PM To: Florin Veres Cc: nanog at nanog.org Subject: Re: Upload config to juniper On Mon, Jan 24, 2011 at 7:39 AM, Florin Veres <florin at futurefreedom.ro> wrote: > Hey guys, > Do any of you have any idea if it's possible to upload configuration from a > script (prefix-list updates in this case) to a JunOS device (MX)? > For Cisco devices I'm doing it using rcp. >From config mode use a "load merge" command that specifies a SCP or FTP URL. You'll need to setup SSH keys in advance to do so without an additional password for the device to download the script. Alternatively... SCP the file to a temporary file on the device then "load merge" the uploaded file, to merge config from the script. Net::SSH::Expect from CPAN to connect via ssh from perl. Something like use Net::SSH::Perl; use Net::SSH::Expect; my $ssh = Net::SSH::Expect->new( host => 'myfavoritehostname.example.com', user => 'blahblahblah', password => '1234', raw_pty => 1); $ssh->login(q[blahblah at myfavoritehostname.example.com's password]); $output1 = $ssh->exec("configure private"); # $blah = $ssh->exec("load merge username at scriptserver.example.com:/path/to/scriptfile_to_load.txt"); print scalar $ssh->exec("show | compare"); # commit -- -JH From bensons at queuefull.net Fri Jan 28 19:47:42 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Fri, 28 Jan 2011 17:47:42 -0800 Subject: Connectivity status for Egypt In-Reply-To: <535636.53395.qm@web59603.mail.ac4.yahoo.com> References: <535636.53395.qm@web59603.mail.ac4.yahoo.com> Message-ID: <B15A9CCC-CDC1-4A69-9FE5-D2084D646CBA@queuefull.net> On Jan 28, 2011, at 1:44 PM, andrew.wallace wrote: > We should be asking the Egyptians to stagger the return of services so that infrastructure isn't affected, when connectivity is deemed to be allowed to come back online. > > Andrew Wallace > > --- > > British IT Security Consultant You should send them an email about that. From owen at delong.com Fri Jan 28 22:04:12 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 28 Jan 2011 20:04:12 -0800 Subject: Ipv6 for the content provider In-Reply-To: <AANLkTin+atGQ+2JDJhzU0m2QZbTzQkSU_KcDwfTcbBaK@mail.gmail.com> References: <4D406670.8040202@knownelement.com> <5A6D953473350C4B9995546AFE9939EE0BC1361D@RWC-EX1.corp.seven.com> <024EC9AD-2FD3-406A-A3DA-868152F33187@delong.com> <AANLkTin+atGQ+2JDJhzU0m2QZbTzQkSU_KcDwfTcbBaK@mail.gmail.com> Message-ID: <8BC2C7B1-2BB8-4710-B0EC-5C9532560890@delong.com> The IPv6 geo databases actually tend to be about on par with the IPv4 ones from what I have seen so far (which is admittedly limited as I don't really use geolocation services). However, I still think it is important for people considering deploying something as you described to be aware of the additional things that may break and factor that into their decision about how and what to deploy. Owen On Jan 28, 2011, at 4:02 PM, Bill Stewart wrote: > On 1/26/11, Owen DeLong <owen at delong.com> wrote: >> And if your servers behind the LB aren't prepared for it, >> you lose a LOT of logging data, geolocation capabilities, >> and some other things if you go that route. > > Of course, anybody expecting a current IPv4 geolocation service to > provide accurate information over IPv6 over the next couple of years > is wildly optimistic (with all due respect to people in that business, > but just sayin' good luck with that...) > > Maybe you'll get some consistency about which continent they're on > based on the RIR the addresses came from, but even that's probably > dodgy if the address belongs to Hurricane Electric or Sixxs or some > other popular tunnel broker, and maybe you'll get some consistency on > "is it the same /56 as last time?", and maybe some of them will start > doing tricks like putting web bugs for > "ipv4tracker.geolocator-example.com" and > "ipv6tracker.geolocator-example.com" on the same web pages to try to > start building correlation information, and if course you need your > application that uses the information to speak IPv6 and handle 128-bit > records and not just 32-bit. > > -- > ---- > Thanks; Bill > > Note that this isn't my regular email account - It's still experimental so far. > And Google probably logs and indexes everything you send it. From shadowedstranger at gmail.com Fri Jan 28 22:42:10 2011 From: shadowedstranger at gmail.com (Jacob Broussard) Date: Fri, 28 Jan 2011 20:42:10 -0800 Subject: Bogons In-Reply-To: <20110129014139.GJ3684@hezmatt.org> References: <F6427296-2D81-40A2-B578-95BD27B8CE35@sackheads.org> <A28DCA86-6934-4ABE-B2E9-B951B013D44F@sackheads.org> <5A6D953473350C4B9995546AFE9939EE0BC136D4@RWC-EX1.corp.seven.com> <03AF91C1-A63E-47B2-9C15-BFDC1965EA95@sackheads.org> <AANLkTimzEvNKw9CSOeS+RHPxXPuNFWKV8fF1rM7aoCN8@mail.gmail.com> <20110129014139.GJ3684@hezmatt.org> Message-ID: <AANLkTi=K=o81UvX9Pc1WoKbdd4cVnN_DVtKgq2p+28W7@mail.gmail.com> You win. They had that address filtered way before I ever used it, silly me for not checking first :P What I really wanted to say on the list, though, was everyone that waits 1+ years between bogon updates can go to hell. They wait some poor flunky (me) has a customer yelling in my ear because "I could access that website fine before I switched to you".... *sigh* On Jan 28, 2011 5:44 PM, "Matthew Palmer" <mpalmer at hezmatt.org> wrote: > On Fri, Jan 28, 2011 at 12:35:43PM -0800, Jacob Broussard wrote: >> Static bogons are the bane of my existence... The pain of trying to explain >> to someone for MONTHS that they haven't updated their reference, with >> traceroutes to back it up, and they continue to say that it has something to >> do with my network. > > THey're right -- your network is using an address range they've chosen to > configure their equipment not to accept... <grin> > > - Matt > From fasterfourier at gmail.com Fri Jan 28 23:48:50 2011 From: fasterfourier at gmail.com (Robert Johnson) Date: Sat, 29 Jan 2011 00:48:50 -0500 Subject: Need provider suggestions - BGP transit over GRE tunnel In-Reply-To: <alpine.DEB.1.10.1101281733070.20241@sisler> References: <AANLkTikCHuobbeWyyk1Nng_+FE1DcDZwFFupfmUsBDs_@mail.gmail.com> <alpine.DEB.1.10.1101281733070.20241@sisler> Message-ID: <AANLkTimrNWBby0esM4+bz8pGq+J1D3OeMBV6wDUKhe9X@mail.gmail.com> My network spans a multicity geographic area using microwave radio links. The point of the GRE tunnel is to allow me to establish a BGP session to another AS using a consumer grade Internet connection (cheap) over the public Internet. I don't want to build out additional microwave paths to a new datacenter to become multihomed. On Fri, Jan 28, 2011 at 5:36 PM, C. Jon Larsen <jlarsen at richweb.com> wrote: > > I have read your email a few times and i dont see how this makes sense. > > Why do you need a public AS and PI space? Your gre tunnel wont need it or be > able to use it. A gre tunnel is just a replacement for a physical pipe. > > If your datacenter based presence goes down, you will need a pipe at your > office, or some other location speaking bgp that can annouce your block > anyway. > > > > > On Fri, 28 Jan 2011, Robert Johnson wrote: > >> My organization is planning to become multihomed in the near future. >> Currently we have redundant (router and physical path) links to a >> single AS where we get our transit, and speak BGP to them using a >> private ASN. This configuration has not been meeting our reliability >> requirements, so we will be getting our own ASN from ARIN, and moving >> from PA to PI IP space. >> >> Our new provider will be used for backup purposes only. We would like >> to minimize the monthly cost of this connection; to do this, we are >> planning to use a VZ business FIOS connection with symmetrical >> bandwidth to establish a GRE tunnel to a datacenter somewhere, and >> bring up a BGP session over that tunnel. I'd like to know if there are >> providers that offer such a service on a regular basis, and if so, if >> anyone is doing this and has words of wisdom. >> >> Thanks in advance. >> >> >> -- >> This message has been scanned for viruses and >> dangerous content by the Richweb.com MailScanner, and is >> believed to be clean. >> >> >> > From ben at adversary.org Sat Jan 29 01:43:57 2011 From: ben at adversary.org (Ben McGinnes) Date: Sat, 29 Jan 2011 18:43:57 +1100 Subject: Found: Who is responsible for no more IP addresses In-Reply-To: <15379786.2818.1296158589318.JavaMail.root@benjamin.baylink.com> References: <15379786.2818.1296158589318.JavaMail.root@benjamin.baylink.com> Message-ID: <4D43C53D.7010104@adversary.org> On 28/01/11 7:03 AM, Jay Ashworth wrote: > Let me clarify: > > The original question was (so far as I could see): "Was Fox making up the > quote where Vint took the blame for IPv4 exhaustion?" > > The answer, of course, was "no, they didn't; lots of people have the quote". If you want to see and hear footage of him repeating this and explaining, his keynote address to Linux Conf Australia is here: http://linuxconfau.blip.tv/file/4683393/ Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: OpenPGP digital signature URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110129/8161a639/attachment.bin> From owen at delong.com Sat Jan 29 03:13:40 2011 From: owen at delong.com (Owen DeLong) Date: Sat, 29 Jan 2011 01:13:40 -0800 Subject: Fwd: [listname] Fwd: Connectivity status for Egypt References: <4D43C792.5090006@sahara.com.sa> Message-ID: <BA464B90-BDFE-4AF7-8B57-AFB9325CC16F@delong.com> Anonymized because I am forwarding without permission... > > Dears, > > As per what I know from friends: > > 1. All Internet is down. Apparently one network is still working but seems to be serving the stock exchange only and few others. > 2. SMS is down. > 3. Landlines are down (at least internationally). > 4. Mobile networks seem to be on and off depending on location. For example, Vodafone is apparently working in Cairo while other networks are not !! > > God help them and bring Egypt and Egyptians out of this harmless inshallah. > Regards.. Owen From franck at genius.com Sat Jan 29 05:49:34 2011 From: franck at genius.com (Franck Martin) Date: Sun, 30 Jan 2011 00:49:34 +1300 (FJST) Subject: Need provider suggestions - BGP transit over GRE tunnel In-Reply-To: <AANLkTimrNWBby0esM4+bz8pGq+J1D3OeMBV6wDUKhe9X@mail.gmail.com> Message-ID: <23264973.1110.1296301774479.JavaMail.franck@franck-martins-macbook-pro.local> Just make sure you don't shoot yourself in the foot by telling the best route to the end of the tunnel is via the tunnel itself... I use it too: http://www.avonsys.com/blogpost367 but because I have no other choice. ----- Original Message ----- From: "Robert Johnson" <fasterfourier at gmail.com> To: "C. Jon Larsen" <jlarsen at richweb.com>, nanog at nanog.org Sent: Saturday, 29 January, 2011 6:48:50 PM Subject: Re: Need provider suggestions - BGP transit over GRE tunnel My network spans a multicity geographic area using microwave radio links. The point of the GRE tunnel is to allow me to establish a BGP session to another AS using a consumer grade Internet connection (cheap) over the public Internet. I don't want to build out additional microwave paths to a new datacenter to become multihomed. On Fri, Jan 28, 2011 at 5:36 PM, C. Jon Larsen <jlarsen at richweb.com> wrote: > > I have read your email a few times and i dont see how this makes sense. > > Why do you need a public AS and PI space? Your gre tunnel wont need it or be > able to use it. A gre tunnel is just a replacement for a physical pipe. > > If your datacenter based presence goes down, you will need a pipe at your > office, or some other location speaking bgp that can annouce your block > anyway. > From georgeb at gmail.com Sat Jan 29 06:36:28 2011 From: georgeb at gmail.com (George B.) Date: Sat, 29 Jan 2011 04:36:28 -0800 Subject: Ipv6 for the content provider In-Reply-To: <8BC2C7B1-2BB8-4710-B0EC-5C9532560890@delong.com> References: <4D406670.8040202@knownelement.com> <5A6D953473350C4B9995546AFE9939EE0BC1361D@RWC-EX1.corp.seven.com> <024EC9AD-2FD3-406A-A3DA-868152F33187@delong.com> <AANLkTin+atGQ+2JDJhzU0m2QZbTzQkSU_KcDwfTcbBaK@mail.gmail.com> <8BC2C7B1-2BB8-4710-B0EC-5C9532560890@delong.com> Message-ID: <AANLkTikM02ZiqKN=smp1Sxj1R71tzH+2dooqgY5sCFuO@mail.gmail.com> On Fri, Jan 28, 2011 at 8:04 PM, Owen DeLong <owen at delong.com> wrote: > The IPv6 geo databases actually tend to be about on par with the IPv4 > ones from what I have seen so far (which is admittedly limited as I don't > really use geolocation services). However, I still think it is important > for > people considering deploying something as you described to be aware > of the additional things that may break and factor that into their > decision about how and what to deploy. > > Owen > > > That isn't going to be the case going forward, I don't believe because our allocation from ARIN will likely be used globally and others are likely to come to the same conclusion. While I had initially considered obtaining regional allocations for operations in that region, the overhead of dealing with multiple registries, differing policies, multiple fees, etc. didn't seem worth the trouble. The ARIN allocation will likely be used in EU and APAC regions in addition to NA. From BECHA at ripe.net Sat Jan 29 06:46:00 2011 From: BECHA at ripe.net (Vesna Manojlovic) Date: Sat, 29 Jan 2011 12:46:00 +0000 Subject: [menog] Fwd: Connectivity status for Egypt In-Reply-To: <AANLkTimGBbmi6Dd6-i4Dz-iR5On+cHKJvO5fa6vAsrHa@mail.gmail.com> References: <AANLkTimUaNCRFhQqBTPM6Z=W7WUfU8fZUFHGjbqXGJsq@mail.gmail.com> <AANLkTimGBbmi6Dd6-i4Dz-iR5On+cHKJvO5fa6vAsrHa@mail.gmail.com> Message-ID: <4D440C08.9060808@ripe.net> Dear all, On 1/28/11 1:07 AM, Richard Barnes wrote: > Hey all, > Some NANOG participants are seeing hearing reports of disrupted > communications in Egypt. Are any of you seeing the same thing? > --Richard Here is the analysis of BGP table regarding what happened to the Internet in Egypt: http://stat.ripe.net/egypt/ https://labs.ripe.net/Members/akvadrako/live_eqyptian_internet_incident_analysis Vesna Manojlovic RIPE NCC Trainer > ---------- Forwarded message ---------- > From: Danny O'Brien <danny at spesh.com> > Date: Thu, Jan 27, 2011 at 6:47 PM > Subject: Connectivity status for Egypt > To: NANOG Operators' Group <nanog at nanog.org> > > > Around 2236 UCT, we lost all Internet connectivity with our contacts in > Egypt, and I'm hearing reports of (in declining order of confirmability): > > 1) Internet connectivity loss on major (broadband) ISPs > 2) No SMS > 4) Intermittent connectivity with smaller (dialup?) ISPs > 5) No mobile service in major cities -- Cairo, Alexandria > > The working assumption here is that the Egyptian government has made the > decision to shut down all external, and perhaps internal electronic > communication as a reaction to the ongoing protests in that country. > > If anyone can provide more details as to what they're seeing, the extent, > plus times and dates, it would be very useful. In moments like this there > are often many unconfirmed rumors: I'm seeking concrete reliable > confirmation which I can pass onto the press and those working to bring some > communications back up (if you have a ham radio license, there is some very > early work to provide emergency connectivity. Info at: > http://pastebin.com/fHHBqZ7Q ) > > Thank you, > > -- > dobrien at cpj.org > Danny O'Brien, Committee to Protect Journalists > gpg key: http://www.spesh.com/danny/crypto/dannyobrien-key20091106.txt > _______________________________________________ > Menog mailing list > Menog at menog.net > http://lists.menog.net/mailman/listinfo/menog > From lists at nexus6.co.za Sat Jan 29 07:35:01 2011 From: lists at nexus6.co.za (Andy Ashley) Date: Sat, 29 Jan 2011 13:35:01 +0000 Subject: DSL options in NYC for OOB access In-Reply-To: <AANLkTinBEjrL6iwm1xYujA0OZiqGzfRwgXRM_b9D6Y0=@mail.gmail.com> References: <4D3DF769.7060601@nexus6.co.za> <AANLkTinBEjrL6iwm1xYujA0OZiqGzfRwgXRM_b9D6Y0=@mail.gmail.com> Message-ID: <4D441785.7070508@nexus6.co.za> On 29/01/2011 00:16, Bill Stewart wrote: > How much bandwidth do you need? Is a dialup modem fast enough? Hi, Not much at all. Just enough for a telnet/ssh session. A dialup modem would likely do the trick, but that raises other issues about dialing up from the UK based NOC, so I think DSL will be a little more flexible for us in this case. If we must have a telephone line installed we may as well get DSL service over that. Point taken though about reliability of DSL service vs plain PSTN. I have had some offers from the right sort of companies. One in particular has everything we need (low speed, static ip, no red tape& a clue) at half the price of the others (ask me off list if you want the name). Also suggested to me was doing a swap with another provider in the facility but it seems as if cross connects may be prohibitively expensive between suites/floors there. Im going to wait for pricing on this and make a choice then. Thanks to all who responded. Regards, Andy. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From rsm at fast-serv.com Sat Jan 29 08:56:31 2011 From: rsm at fast-serv.com (Randy McAnally) Date: Sat, 29 Jan 2011 09:56:31 -0500 Subject: DSL options in NYC for OOB access In-Reply-To: <4D441785.7070508@nexus6.co.za> References: <4D3DF769.7060601@nexus6.co.za> <AANLkTinBEjrL6iwm1xYujA0OZiqGzfRwgXRM_b9D6Y0=@mail.gmail.com> <4D441785.7070508@nexus6.co.za> Message-ID: <20110129145536.M74977@fast-serv.com> On Sat, 29 Jan 2011 13:35:01 +0000, Andy Ashley wrote > if you want the name). Also suggested to me was doing a swap with > another provider in the facility but it seems as if cross connects > may be prohibitively expensive between suites/floors there. Im going > to wait for pricing on this and make a choice then. Have you looked into the cross connect cost for your DSL line? They typically aren't very cheap either. ~Randy From patrick at ianai.net Sat Jan 29 09:23:02 2011 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sat, 29 Jan 2011 10:23:02 -0500 Subject: Bogons In-Reply-To: <20110129014139.GJ3684@hezmatt.org> References: <F6427296-2D81-40A2-B578-95BD27B8CE35@sackheads.org> <A28DCA86-6934-4ABE-B2E9-B951B013D44F@sackheads.org> <5A6D953473350C4B9995546AFE9939EE0BC136D4@RWC-EX1.corp.seven.com> <03AF91C1-A63E-47B2-9C15-BFDC1965EA95@sackheads.org> <AANLkTimzEvNKw9CSOeS+RHPxXPuNFWKV8fF1rM7aoCN8@mail.gmail.com> <20110129014139.GJ3684@hezmatt.org> Message-ID: <26FEF53C-D085-4930-A298-F70F442D1291@ianai.net> On Jan 28, 2011, at 8:41 PM, Matthew Palmer wrote: > On Fri, Jan 28, 2011 at 12:35:43PM -0800, Jacob Broussard wrote: >> Static bogons are the bane of my existence... The pain of trying to explain >> to someone for MONTHS that they haven't updated their reference, with >> traceroutes to back it up, and they continue to say that it has something to >> do with my network. > > THey're right -- your network is using an address range they've chosen to > configure their equipment not to accept... <grin> The RIRs have decided to hand out the "polluted" space to large providers to ensure the greatest damage to those who are too stupid to update their filters. If you know anyone who runs a network, tell them to remove their static bogon filters today. Seriously. -- TTFN, patrick From alexb at ripe.net Sat Jan 29 09:26:55 2011 From: alexb at ripe.net (Alex Band) Date: Sat, 29 Jan 2011 16:26:55 +0100 Subject: [arin-announce] ARIN Resource Certification Update In-Reply-To: <0BC31466-09EA-4734-96B2-152453A62B90@arin.net> References: <EE59203D-907A-4AA2-BAE6-AEE7AADAC0A2@arin.net> <0BC31466-09EA-4734-96B2-152453A62B90@arin.net> Message-ID: <FDFF6713-AB2E-4447-A58B-52CD36A6113A@ripe.net> John, Thanks for the update. With regards to offering a hosted solution, as you know that is the only thing the RIPE NCC currently offers. We're developing support for the up/down protocol as I write this. To give you some perspective, one month after launching the hosted RIPE NCC Resource Certification service, 216 LIRs are using it in the RIPE Region and created 169 ROAs covering 467 prefixes. This means 40151 /24 IPv4 prefixes and 7274499 /48 IPv6 prefixes now have a valid ROA associated with them. I realize a hosted solution is not ideal, we're very open about that. But at least in our region, it seems there are quite a number of organizations who understand and accept the security trade-off of not being the owner of the private key for their resource certificate and trust their RIR to run a properly secured and audited service. So the question is, if the RIPE NCC would have required everyone to run their own certification setup using the open source tool-sets Randy mentions, would there be this much certified address space now? Looking at the depletion of IPv4 address space, it's going to be crucially important to have validatable proof who is the legitimate holder of Internet resources. I fear that by not offering a hosted certification solution, real world adoption rates will rival those of IPv6 and DNSSEC. Can the Internet community afford that? Alex Band Product Manager, RIPE NCC P.S. For those interested in which prefixes and ASs are in the RIPE NCC ROA Repository, here is the latest output in CSV format: http://lunimon.com/valid-roas-20110129.csv On 24 Jan 2011, at 21:33, John Curran wrote: > Copy to NANOG for those who aren't on ARIN lists but may be interested in this info. > FYI. > /John > > Begin forwarded message: > > From: John Curran <jcurran at arin.net<mailto:jcurran at arin.net>> > Date: January 24, 2011 2:58:52 PM EST > To: "arin-announce at arin.net<mailto:arin-announce at arin.net>" <arin-announce at arin.net<mailto:arin-announce at arin.net>> > Subject: [arin-announce] ARIN Resource Certification Update > > ARIN continues its preparations for offering production-grade resource certification > services for Internet number resources in the region. ARIN recognizes the importance > of Internet number resource certification in the region as a key element of further > securing Internet routing, and plans to rollout Resource Public Key Infrastructure (RPKI) > at the end of the second quarter of 2011 with support for the Up/Down protocol for those > ISPs who wish to certify their subdelegations via their own RPKI infrastructure. > > ARIN continues to evaluate offering a Hosting Resource Certification service for this > purpose (as an alternative to organizations having to run their own RPKI infrastructure), > but at this time it remains under active consideration and is not committed. We look > forward to discussing the need for this type of service and the organization implications > atour upcoming ARIN Members Meeting in April in San Juan, PR. > > FYI, > /John > > John Curran > President and CEO > ARIN > > _______________________________________________ > ARIN-Announce > You are receiving this message because you are subscribed to > the ARIN Announce Mailing List (ARIN-announce at arin.net<mailto: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. > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1728 bytes Desc: not available URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110129/440b07a8/attachment.bin> From Valdis.Kletnieks at vt.edu Sat Jan 29 10:21:15 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sat, 29 Jan 2011 11:21:15 -0500 Subject: Need provider suggestions - BGP transit over GRE tunnel In-Reply-To: Your message of "Sun, 30 Jan 2011 00:49:34 +1300." <23264973.1110.1296301774479.JavaMail.franck@franck-martins-macbook-pro.local> References: <23264973.1110.1296301774479.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <178705.1296318075@localhost> On Sun, 30 Jan 2011 00:49:34 +1300, Franck Martin said: > Just make sure you don't shoot yourself in the foot by telling the best route > to the end of the tunnel is via the tunnel itself... Did you mean routing *your* end of the tunnel to the tunnel itself, or announcing to the entire world that The Internet was best reached via your tunnel? I think we've seen spectacular failures in both modes... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110129/be85346e/attachment.bin> From jcurran at arin.net Sat Jan 29 10:35:50 2011 From: jcurran at arin.net (John Curran) Date: Sat, 29 Jan 2011 16:35:50 +0000 Subject: [arin-announce] ARIN Resource Certification Update In-Reply-To: <FDFF6713-AB2E-4447-A58B-52CD36A6113A@ripe.net> References: <EE59203D-907A-4AA2-BAE6-AEE7AADAC0A2@arin.net> <0BC31466-09EA-4734-96B2-152453A62B90@arin.net> <FDFF6713-AB2E-4447-A58B-52CD36A6113A@ripe.net> Message-ID: <F7BDD965-7671-431A-A87D-9D09A41A911F@arin.net> On Jan 29, 2011, at 10:26 AM, Alex Band wrote: > John, > > Thanks for the update. With regards to offering a hosted solution, as you know that is the only thing the RIPE NCC currently offers. We're developing support for the up/down protocol as I write this. Alex - Yes, congrats on rolling out that offering! Also, I wish the folks at the very best on the up/down protocol work, since (as you're likely aware) ARIN is planning to leverage that effort in our up/down service development. :-) > I realize a hosted solution is not ideal, we're very open about that. But at least in our region, it seems there are quite a number of organizations who understand and accept the security trade-off of not being the owner of the private key for their resource certificate and trust their RIR to run a properly secured and audited service. So the question is, if the RIPE NCC would have required everyone to run their own certification setup using the open source tool-sets Randy mentions, would there be this much certified address space now? For many organizations, a hosted service offers the convenience that would make deployment likely. The challenge that ARIN faces isn't with respect to whether our community trusts us to run a properly secured and audited service, but the potential implied liability to ARIN if a party alleges that the hosted service performs incorrectly. It is rather challenging to show that a "relying party" is legally bound to the terms of service in certificate practices statement, and this means that there are significant risks in the offering the service (even with it performing perfectly), since much of the normal contractual protections are not available. Imagine an organization that incorrectly enters its AS number during a ROA generation, and succeeds in taking itself off their air for a prolonged period. Depending on the damages the organization suffered as a result, it may want to claim that ARIN's Hosted RPKI system performed "incorrectly", as may those folks who were impacted by not being able to reach the organization. While ARIN's hosted system would be performing perfectly, the risk and costs to the organization in trying to defend against such (spurious) claims could be very serious. Ultimately, the ARIN Board needs to weigh such matters of benefit and risk in full against the mission and determine the appropriate direction. > Looking at the depletion of IPv4 address space, it's going to be crucially important to have validatable proof who is the legitimate holder of Internet resources. I fear that by not offering a hosted certification solution, real world adoption rates will rival those of IPv6 and DNSSEC. Can the Internet community afford that? The RPKI information regarding valid address holder is effectively same as that contained in the WHOIS, so readily available evidence of resource holder is available today. Parties already use information from the RIRs from WHOIS and routing registries to do various forms of resource & route validation; resource certification simply provides a clearer, more secure & more consistent model for this information. I'm not saying that resource certification isn't important, but do not think that characterizing its need as crucial specifically due to IPv4 depletion is the complete picture. ARIN recognizes the importance of resource certification and hence its commitment to supporting resource certification for resources in the region via Up/Down protocol. There is not a decision on a hosted RPKI offer at this time, but that is because we want to be able to discuss the benefits and risks with the community at our upcoming April meeting to make sure there is significant demand for service as well as appropriate mechanisms for safely managing the risks involved. I hope this clarifies the update message that I sent out earlier, and provides some insight into the considerations that have led ARIN's position on resource certification. Thanks! /John John Curran President and CEO ARIN From jlarsen at richweb.com Sat Jan 29 11:06:34 2011 From: jlarsen at richweb.com (C. Jon Larsen) Date: Sat, 29 Jan 2011 12:06:34 -0500 (EST) Subject: Need provider suggestions - BGP transit over GRE tunnel In-Reply-To: <23264973.1110.1296301774479.JavaMail.franck@franck-martins-macbook-pro.local> References: <23264973.1110.1296301774479.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <alpine.DEB.2.00.1101291203280.20409@jlarsen-desktop> On Sun, 30 Jan 2011, Franck Martin wrote: > Just make sure you don't shoot yourself in the foot by telling the best route to the end of the tunnel is via the tunnel itself... Right, nail up a /32 static route for the remote gre tunnel endpoint on each side. That /32 is nailed up to the next hop that you want the gre tunnel to always traverse. If that next hop becomes unavailable, the tunnel will go down, which is what you want rather than the tunnel trying to come up across some other path it can find. > I use it too: http://www.avonsys.com/blogpost367 but because I have no other choice. > > ----- Original Message ----- > From: "Robert Johnson" <fasterfourier at gmail.com> > To: "C. Jon Larsen" <jlarsen at richweb.com>, nanog at nanog.org > Sent: Saturday, 29 January, 2011 6:48:50 PM > Subject: Re: Need provider suggestions - BGP transit over GRE tunnel > > My network spans a multicity geographic area using microwave radio > links. The point of the GRE tunnel is to allow me to establish a BGP > session to another AS using a consumer grade Internet connection > (cheap) over the public Internet. I don't want to build out additional > microwave paths to a new datacenter to become multihomed. > > On Fri, Jan 28, 2011 at 5:36 PM, C. Jon Larsen <jlarsen at richweb.com> wrote: >> >> I have read your email a few times and i dont see how this makes sense. >> >> Why do you need a public AS and PI space? Your gre tunnel wont need it or be >> able to use it. A gre tunnel is just a replacement for a physical pipe. >> >> If your datacenter based presence goes down, you will need a pipe at your >> office, or some other location speaking bgp that can annouce your block >> anyway. >> > > > > -- > This message has been scanned for viruses and > dangerous content by the Richweb.com MailScanner, and is > believed to be clean. > > > From if at xip.at Sat Jan 29 11:16:43 2011 From: if at xip.at (Ingo Flaschberger) Date: Sat, 29 Jan 2011 18:16:43 +0100 (CET) Subject: [menog] Fwd: Connectivity status for Egypt In-Reply-To: <4D440C08.9060808@ripe.net> References: <AANLkTimUaNCRFhQqBTPM6Z=W7WUfU8fZUFHGjbqXGJsq@mail.gmail.com> <AANLkTimGBbmi6Dd6-i4Dz-iR5On+cHKJvO5fa6vAsrHa@mail.gmail.com> <4D440C08.9060808@ripe.net> Message-ID: <alpine.LRH.2.00.1101291809570.3098@filebunker.xip.at> > Here is the analysis of BGP table regarding what happened to the Internet in > Egypt: > > http://stat.ripe.net/egypt/ > > https://labs.ripe.net/Members/akvadrako/live_eqyptian_internet_incident_analysis Cidr report (http://www.cidr-report.org) shows this also very well: Recent Table History Date Prefixes CIDR Agg 26-01-11 345293 201663 27-01-11 344858 200621 28-01-11 342381 201194 Top 20 Net Decreased Routes per Originating AS Prefixes Change ASnum AS Description -102 102->0 AS5536 Internet-Egypt Kind regards, Ingo Flaschberger From joly at punkcast.com Sat Jan 29 11:36:21 2011 From: joly at punkcast.com (Joly MacFie) Date: Sat, 29 Jan 2011 12:36:21 -0500 Subject: Found: Who is responsible for no more IP addresses In-Reply-To: <4D43C53D.7010104@adversary.org> References: <15379786.2818.1296158589318.JavaMail.root@benjamin.baylink.com> <4D43C53D.7010104@adversary.org> Message-ID: <AANLkTikfbUuueHG2ax_HP4MW+w_3uvHA8qWVKmQPB+QT@mail.gmail.com> Thanks for the link to the vid. I see Geoff Huston spoke too. I've embedded both on http://www.isoc-ny.org/p2/?p=1713 FWIW Vint has been using this as an intro to IPv6 for years.. in fact I've got some video to edit of him speaking in 1999 - I'll look for it.. j On Sat, Jan 29, 2011 at 2:43 AM, Ben McGinnes <ben at adversary.org> wrote: > On 28/01/11 7:03 AM, Jay Ashworth wrote: > > Let me clarify: > > > > The original question was (so far as I could see): "Was Fox making up the > > quote where Vint took the blame for IPv4 exhaustion?" > > > > The answer, of course, was "no, they didn't; lots of people have the > quote". > > If you want to see and hear footage of him repeating this and > explaining, his keynote address to Linux Conf Australia is here: > > http://linuxconfau.blip.tv/file/4683393/ > > > Regards, > Ben > > -- --------------------------------------------------------------- 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 mike-nanog at tiedyenetworks.com Sat Jan 29 12:00:36 2011 From: mike-nanog at tiedyenetworks.com (Mike) Date: Sat, 29 Jan 2011 10:00:36 -0800 Subject: help needed - state of california needs a benchmark Message-ID: <4D4455C4.6080305@tiedyenetworks.com> Hello, My company is small clec / broadband provider serving rural communities in northern California, and we are the recipient of a small grant from the state thru our public utilities commission. We went out to 'middle of nowhere' and deployed adsl2+ in fact (chalk one up for the good guys!), and now that we're done, our state puc wants to gather performance data to evaluate the result of our project and ensure we delivered what we said we were going to. Bigger picture, our state is actively attempting to map broadband availability and service levels available and this data will factor into this overall picture, to be used for future grant/loan programs and other support mechanisms, so this really is going to touch every provider who serves end users in the state. The rub is, that they want to legislate that web based 'speedtest.com' is the ONLY and MOST AUTHORITATIVE metric that trumps all other considerations and that the provider is %100 at fault and responsible for making fraudulent claims if speedtest.com doesn't agree. No discussion is allowed or permitted about sync rates, packet loss, internet congestion, provider route diversity, end user computer performance problems, far end congestion issues, far end server issues or cpu loading, latency/rtt, or the like. They are going to decide that the quality of any provider service, is solely and exclusively resting on the numbers returned from 'speedtest.com' alone, period. All of you in this audience, I think, probably immediately understand the various problems with such an assertion. Its one of these situations where - to the uninitiated - it SEEMS LIKE this is the right way to do this, and it SEEMS LIKE there's some validity to whats going on - but in practice, we engineering types know it's a far different animal and should not be used for real live benchmarking of any kind where there is a demand for statistical validity. My feeling is that - if there is a need for the state to do benchmarking, then it outta be using statistically significant methodologies for same along the same lines as any other benchmark or test done by other government agencies and national standards bodies that are reproducible and dependable. The question is, as a hotbutton issue, how do we go about getting 'the message' across, how do we go about engineering something that could be considered statistically relevant, and most importantly, how do we get this to be accepted by non-technical legislators and regulators? Mike- From dwhite at olp.net Sat Jan 29 12:23:22 2011 From: dwhite at olp.net (Dan White) Date: Sat, 29 Jan 2011 12:23:22 -0600 Subject: help needed - state of california needs a benchmark In-Reply-To: <4D4455C4.6080305@tiedyenetworks.com> References: <4D4455C4.6080305@tiedyenetworks.com> Message-ID: <20110129182322.GB12632@dan.olp.net> On 29/01/11?10:00?-0800, Mike wrote: > The rub is, that they want to legislate that web based >'speedtest.com' is the ONLY and MOST AUTHORITATIVE metric that trumps >all other considerations and that the provider is %100 at fault and >responsible for making fraudulent claims if speedtest.com doesn't >agree. No discussion is allowed or permitted about sync rates, packet >loss, internet congestion, provider route diversity, end user >computer performance problems, far end congestion issues, far end >server issues or cpu loading, latency/rtt, or the like. They are >going to decide that the quality of any provider service, is solely >and exclusively resting on the numbers returned from 'speedtest.com' >alone, period. If you license the software with Ookla, you can install it on a local server and, with your permission, be listed on the speedtest.net site. When your customers visit speedtest.net, your server is, or is close to, the default server that your customers land at. You could try to convince the state that their metric is suboptimal and X is superior, but if your *customers* are anything like ours, it's even harder to educate them why remote speed tests aren't always an accurate measurement of the service you're providing. We've learned to pick our fights, and this isn't one of them. -- Dan White From jeff.richmond at gmail.com Sat Jan 29 12:29:56 2011 From: jeff.richmond at gmail.com (Jeff Richmond) Date: Sat, 29 Jan 2011 10:29:56 -0800 Subject: help needed - state of california needs a benchmark In-Reply-To: <4D4455C4.6080305@tiedyenetworks.com> References: <4D4455C4.6080305@tiedyenetworks.com> Message-ID: <C33BA4F7-D988-4108-B04D-96F13B60750D@gmail.com> Mike, nothing is perfect, so let's just start with that. What the FCC has done to measure this is to partner with Sam Knows and then have friendly DSL subs for the participating telcos to run modified CPE firmware to test against their servers. We have been collecting data for this for the past couple of months, actually. More can be found here: http://www.samknows.com/broadband/fcc_and_samknows While even that I have issues with, it certainly is better than hitting that speedtest site where anything at all problematic on the customer LAN side of the CPE can cause erroneous results. Good luck, -Jeff On Jan 29, 2011, at 10:00 AM, Mike wrote: > Hello, > > My company is small clec / broadband provider serving rural communities in northern California, and we are the recipient of a small grant from the state thru our public utilities commission. We went out to 'middle of nowhere' and deployed adsl2+ in fact (chalk one up for the good guys!), and now that we're done, our state puc wants to gather performance data to evaluate the result of our project and ensure we delivered what we said we were going to. Bigger picture, our state is actively attempting to map broadband availability and service levels available and this data will factor into this overall picture, to be used for future grant/loan programs and other support mechanisms, so this really is going to touch every provider who serves end users in the state. > > The rub is, that they want to legislate that web based 'speedtest.com' is the ONLY and MOST AUTHORITATIVE metric that trumps all other considerations and that the provider is %100 at fault and responsible for making fraudulent claims if speedtest.com doesn't agree. No discussion is allowed or permitted about sync rates, packet loss, internet congestion, provider route diversity, end user computer performance problems, far end congestion issues, far end server issues or cpu loading, latency/rtt, or the like. They are going to decide that the quality of any provider service, is solely and exclusively resting on the numbers returned from 'speedtest.com' alone, period. > > All of you in this audience, I think, probably immediately understand the various problems with such an assertion. Its one of these situations where - to the uninitiated - it SEEMS LIKE this is the right way to do this, and it SEEMS LIKE there's some validity to whats going on - but in practice, we engineering types know it's a far different animal and should not be used for real live benchmarking of any kind where there is a demand for statistical validity. > > My feeling is that - if there is a need for the state to do benchmarking, then it outta be using statistically significant methodologies for same along the same lines as any other benchmark or test done by other government agencies and national standards bodies that are reproducible and dependable. The question is, as a hotbutton issue, how do we go about getting 'the message' across, how do we go about engineering something that could be considered statistically relevant, and most importantly, how do we get this to be accepted by non-technical legislators and regulators? > > Mike- > From patrick at ianai.net Sat Jan 29 12:45:54 2011 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sat, 29 Jan 2011 13:45:54 -0500 Subject: help needed - state of california needs a benchmark In-Reply-To: <C33BA4F7-D988-4108-B04D-96F13B60750D@gmail.com> References: <4D4455C4.6080305@tiedyenetworks.com> <C33BA4F7-D988-4108-B04D-96F13B60750D@gmail.com> Message-ID: <3A315E25-42DD-4626-AB2C-5F21D4E25600@ianai.net> I think the big deal here is the "100%" thing. If Speedtest is one of many tests, then I don't particularly see the problem. It shouldn't be any more difficult to convince politicians that any system (testing or otherwise) can have problems than it is to convince them of any other hard fact. (IOW: Nearly impossible, but you have to try. :) -- TTFN, patrick On Jan 29, 2011, at 1:29 PM, Jeff Richmond wrote: > Mike, nothing is perfect, so let's just start with that. What the FCC has done to measure this is to partner with Sam Knows and then have friendly DSL subs for the participating telcos to run modified CPE firmware to test against their servers. We have been collecting data for this for the past couple of months, actually. More can be found here: > > http://www.samknows.com/broadband/fcc_and_samknows > > While even that I have issues with, it certainly is better than hitting that speedtest site where anything at all problematic on the customer LAN side of the CPE can cause erroneous results. > > Good luck, > -Jeff > > > On Jan 29, 2011, at 10:00 AM, Mike wrote: > >> Hello, >> >> My company is small clec / broadband provider serving rural communities in northern California, and we are the recipient of a small grant from the state thru our public utilities commission. We went out to 'middle of nowhere' and deployed adsl2+ in fact (chalk one up for the good guys!), and now that we're done, our state puc wants to gather performance data to evaluate the result of our project and ensure we delivered what we said we were going to. Bigger picture, our state is actively attempting to map broadband availability and service levels available and this data will factor into this overall picture, to be used for future grant/loan programs and other support mechanisms, so this really is going to touch every provider who serves end users in the state. >> >> The rub is, that they want to legislate that web based 'speedtest.com' is the ONLY and MOST AUTHORITATIVE metric that trumps all other considerations and that the provider is %100 at fault and responsible for making fraudulent claims if speedtest.com doesn't agree. No discussion is allowed or permitted about sync rates, packet loss, internet congestion, provider route diversity, end user computer performance problems, far end congestion issues, far end server issues or cpu loading, latency/rtt, or the like. They are going to decide that the quality of any provider service, is solely and exclusively resting on the numbers returned from 'speedtest.com' alone, period. >> >> All of you in this audience, I think, probably immediately understand the various problems with such an assertion. Its one of these situations where - to the uninitiated - it SEEMS LIKE this is the right way to do this, and it SEEMS LIKE there's some validity to whats going on - but in practice, we engineering types know it's a far different animal and should not be used for real live benchmarking of any kind where there is a demand for statistical validity. >> >> My feeling is that - if there is a need for the state to do benchmarking, then it outta be using statistically significant methodologies for same along the same lines as any other benchmark or test done by other government agencies and national standards bodies that are reproducible and dependable. The question is, as a hotbutton issue, how do we go about getting 'the message' across, how do we go about engineering something that could be considered statistically relevant, and most importantly, how do we get this to be accepted by non-technical legislators and regulators? >> >> Mike- >> > > From nathan at atlasnetworks.us Sat Jan 29 12:49:17 2011 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Sat, 29 Jan 2011 18:49:17 +0000 Subject: help needed - state of california needs a benchmark In-Reply-To: <20110129182322.GB12632@dan.olp.net> References: <4D4455C4.6080305@tiedyenetworks.com> <20110129182322.GB12632@dan.olp.net> Message-ID: <8C26A4FDAE599041A13EB499117D3C286B344C80@ex-mb-1.corp.atlasnetworks.us> > We've learned to pick our fights, and this isn't one of them. > > -- > Dan White The most effective mechanism I've seen for explaining the problem is latency and VOIP. Set up an artificially latency-ridden, high bandwidth connection, then connect to a PBX using a softphone. One call is generally sufficient proof of the issue. Ookla does offer another metric, at http://www.pingtest.net/, which provides some valuable additional information. You can therefore infer an argument by speedtest.net: Gov: Speedtest.net is an authorative location for all testing. Speedtest.net: Anyone can host our test application, so that is clearly false. Gov: The only important factor in certification is bandwidth to speedtest.net. Speedtest.net: We offer other connection quality tests that don't rely on bandwidth. I often find that statements people make rely on half-truths gleaned from other people, and that generally, the fastest way to conclude an argument is to go to the source and extract the complete truth, and then present in contrast. It is difficult to argue with your own source. :-) Nathan From r.engehausen at gmail.com Sat Jan 29 13:36:08 2011 From: r.engehausen at gmail.com (Roy) Date: Sat, 29 Jan 2011 11:36:08 -0800 Subject: help needed - state of california needs a benchmark In-Reply-To: <4D4455C4.6080305@tiedyenetworks.com> References: <4D4455C4.6080305@tiedyenetworks.com> Message-ID: <4D446C28.70907@gmail.com> On 1/29/2011 10:00 AM, Mike wrote: > Hello, > > My company is small clec / broadband provider serving rural > communities in northern California, and we are the recipient of a > small grant from the state thru our public utilities commission. We > went out to 'middle of nowhere' and deployed adsl2+ in fact (chalk one > up for the good guys!), and now that we're done, our state puc wants > to gather performance data to evaluate the result of our project and > ensure we delivered what we said we were going to. Bigger picture, our > state is actively attempting to map broadband availability and service > levels available and this data will factor into this overall picture, > to be used for future grant/loan programs and other support > mechanisms, so this really is going to touch every provider who serves > end users in the state. > > The rub is, that they want to legislate that web based > 'speedtest.com' is the ONLY and MOST AUTHORITATIVE metric that trumps > all other considerations and that the provider is %100 at fault and > responsible for making fraudulent claims if speedtest.com doesn't > agree. No discussion is allowed or permitted about sync rates, packet > loss, internet congestion, provider route diversity, end user computer > performance problems, far end congestion issues, far end server issues > or cpu loading, latency/rtt, or the like. They are going to decide > that the quality of any provider service, is solely and exclusively > resting on the numbers returned from 'speedtest.com' alone, period. > > All of you in this audience, I think, probably immediately > understand the various problems with such an assertion. Its one of > these situations where - to the uninitiated - it SEEMS LIKE this is > the right way to do this, and it SEEMS LIKE there's some validity to > whats going on - but in practice, we engineering types know it's a far > different animal and should not be used for real live benchmarking of > any kind where there is a demand for statistical validity. > > My feeling is that - if there is a need for the state to do > benchmarking, then it outta be using statistically significant > methodologies for same along the same lines as any other benchmark or > test done by other government agencies and national standards bodies > that are reproducible and dependable. The question is, as a hotbutton > issue, how do we go about getting 'the message' across, how do we go > about engineering something that could be considered statistically > relevant, and most importantly, how do we get this to be accepted by > non-technical legislators and regulators? > > Mike- > > You took the state's money so you are stuck with their dumb rules. Furthermore the CPUC people aren't stupid. They have highly paid consultants as well as professors from colleges in California that are advising them. Unless you have some plan for a very inexpensive alternative, don't think you are going to make any headway From tvhawaii at shaka.com Sat Jan 29 14:25:49 2011 From: tvhawaii at shaka.com (Michael Painter) Date: Sat, 29 Jan 2011 10:25:49 -1000 Subject: help needed - state of california needs a benchmark References: <4D4455C4.6080305@tiedyenetworks.com> Message-ID: <C100B4288C564EF690EE2952CF55C252@DELL16> Mike wrote: > The rub is, that they want to legislate that web based 'speedtest.com' > is the ONLY and MOST AUTHORITATIVE metric that trumps all other > considerations and that the provider is %100 at fault and responsible > for making fraudulent claims if speedtest.com doesn't agree. speedtest.net? From cra at WPI.EDU Sat Jan 29 14:33:18 2011 From: cra at WPI.EDU (Chuck Anderson) Date: Sat, 29 Jan 2011 15:33:18 -0500 Subject: help needed - state of california needs a benchmark In-Reply-To: <4D4455C4.6080305@tiedyenetworks.com> References: <4D4455C4.6080305@tiedyenetworks.com> Message-ID: <20110129203318.GA15843@angus.ind.WPI.EDU> On Sat, Jan 29, 2011 at 10:00:36AM -0800, Mike wrote: > issue, how do we go about getting 'the message' across, how do we go > about engineering something that could be considered statistically > relevant, and most importantly, how do we get this to be accepted by > non-technical legislators and regulators? How about this analogy: Using speedtest.com as the sole benchmark is like trying to test the speed and throughput of the city streets in Sacramento by seeing how long it takes to drive to New York City and back. Oh, and why should we be responsible for the speeds on the Interstate portions of that route when we only control the city streets and local secondary roads? From lists at nexus6.co.za Sat Jan 29 14:41:39 2011 From: lists at nexus6.co.za (Andy Ashley) Date: Sat, 29 Jan 2011 20:41:39 +0000 Subject: DSL options in NYC for OOB access In-Reply-To: <20110129145536.M74977@fast-serv.com> References: <4D3DF769.7060601@nexus6.co.za> <AANLkTinBEjrL6iwm1xYujA0OZiqGzfRwgXRM_b9D6Y0=@mail.gmail.com> <4D441785.7070508@nexus6.co.za> <20110129145536.M74977@fast-serv.com> Message-ID: <4D447B83.1050709@nexus6.co.za> On 29/01/2011 14:56, Randy McAnally wrote: > Have you looked into the cross connect cost for your DSL line? They typically > aren't very cheap either. > > ~Randy Im still waiting for the quote to come back from L3. Figured a copper pair would be cheaper than a fiber, but who knows? Andy. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From aservin at lacnic.net Sat Jan 29 15:06:17 2011 From: aservin at lacnic.net (Arturo Servin) Date: Sat, 29 Jan 2011 19:06:17 -0200 Subject: [arin-announce] ARIN Resource Certification Update In-Reply-To: <FDFF6713-AB2E-4447-A58B-52CD36A6113A@ripe.net> References: <EE59203D-907A-4AA2-BAE6-AEE7AADAC0A2@arin.net> <0BC31466-09EA-4734-96B2-152453A62B90@arin.net> <FDFF6713-AB2E-4447-A58B-52CD36A6113A@ripe.net> Message-ID: <F4820171-5F43-480C-B0BA-2BB9D473C75D@lacnic.net> I agree with Alex that without a hosted solution RIPE NCC wouldn't have so many ROAs today, for us, even with it, it has been more difficult to roll out RPKI among our ISPs. As many, I do not think that a hosted suits to everybody and it has some disadvantages but at leas it could help to lower the entry barrier for some. Speaking about RPKI stats, here some ROA evolution in various TAs (the data from ARIN is from their beta test, the rest are production systems): http://www.labs.lacnic.net/~rpki/rpki-evolution-report_EN.txt And visually: http://www.labs.lacnic.net/~rpki/rpki-heatmaps/latest/global-roa-heatmap.png and http://www.labs.lacnic.net/~rpki/rpki-heatmaps/latest/ To see each region. http://www.labs.lacnic.net/~rpki/rpki-heatmaps Also, bgpmon has a nice whois interface for humans to see ROAs (not sure if this link was share here or in twitter, sorry if I am duplicating): http://bgpmon.net/blog/?p=414 Best regards, -as On 29 Jan 2011, at 13:26, Alex Band wrote: > John, > > Thanks for the update. With regards to offering a hosted solution, as you know that is the only thing the RIPE NCC currently offers. We're developing support for the up/down protocol as I write this. > > To give you some perspective, one month after launching the hosted RIPE NCC Resource Certification service, 216 LIRs are using it in the RIPE Region and created 169 ROAs covering 467 prefixes. This means 40151 /24 IPv4 prefixes and 7274499 /48 IPv6 prefixes now have a valid ROA associated with them. > > I realize a hosted solution is not ideal, we're very open about that. But at least in our region, it seems there are quite a number of organizations who understand and accept the security trade-off of not being the owner of the private key for their resource certificate and trust their RIR to run a properly secured and audited service. So the question is, if the RIPE NCC would have required everyone to run their own certification setup using the open source tool-sets Randy mentions, would there be this much certified address space now? > > Looking at the depletion of IPv4 address space, it's going to be crucially important to have validatable proof who is the legitimate holder of Internet resources. I fear that by not offering a hosted certification solution, real world adoption rates will rival those of IPv6 and DNSSEC. Can the Internet community afford that? > > Alex Band > Product Manager, RIPE NCC > > P.S. For those interested in which prefixes and ASs are in the RIPE NCC ROA Repository, here is the latest output in CSV format: > http://lunimon.com/valid-roas-20110129.csv > > > > On 24 Jan 2011, at 21:33, John Curran wrote: > >> Copy to NANOG for those who aren't on ARIN lists but may be interested in this info. >> FYI. >> /John >> >> Begin forwarded message: >> >> From: John Curran <jcurran at arin.net<mailto:jcurran at arin.net>> >> Date: January 24, 2011 2:58:52 PM EST >> To: "arin-announce at arin.net<mailto:arin-announce at arin.net>" <arin-announce at arin.net<mailto:arin-announce at arin.net>> >> Subject: [arin-announce] ARIN Resource Certification Update >> >> ARIN continues its preparations for offering production-grade resource certification >> services for Internet number resources in the region. ARIN recognizes the importance >> of Internet number resource certification in the region as a key element of further >> securing Internet routing, and plans to rollout Resource Public Key Infrastructure (RPKI) >> at the end of the second quarter of 2011 with support for the Up/Down protocol for those >> ISPs who wish to certify their subdelegations via their own RPKI infrastructure. >> >> ARIN continues to evaluate offering a Hosting Resource Certification service for this >> purpose (as an alternative to organizations having to run their own RPKI infrastructure), >> but at this time it remains under active consideration and is not committed. We look >> forward to discussing the need for this type of service and the organization implications >> atour upcoming ARIN Members Meeting in April in San Juan, PR. >> >> FYI, >> /John >> >> John Curran >> President and CEO >> ARIN >> >> _______________________________________________ >> ARIN-Announce >> You are receiving this message because you are subscribed to >> the ARIN Announce Mailing List (ARIN-announce at arin.net<mailto: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 morrowc.lists at gmail.com Sat Jan 29 15:11:00 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 29 Jan 2011 16:11:00 -0500 Subject: help needed - state of california needs a benchmark In-Reply-To: <C33BA4F7-D988-4108-B04D-96F13B60750D@gmail.com> References: <4D4455C4.6080305@tiedyenetworks.com> <C33BA4F7-D988-4108-B04D-96F13B60750D@gmail.com> Message-ID: <AANLkTikSGiVRjKM9_qrGRZThMEsOzUQpV2NhRTxx_+1a@mail.gmail.com> On Sat, Jan 29, 2011 at 1:29 PM, Jeff Richmond <jeff.richmond at gmail.com> wrote: > Mike, nothing is perfect, so let's just start with that. What the FCC has done to measure this is to partner with Sam Knows and then have friendly DSL subs for the participating telcos to run modified CPE firmware to test against their servers. We have been collecting data for this for the past couple of months, actually. More can be found here: > > http://www.samknows.com/broadband/fcc_and_samknows note that samknows has some deficiencies in their platform, at least: o no ip v6 support o the home-routers/gateways/aps randomly reboot with completely non-functional setups their customer support ... isn't really available, ever. > While even that I have issues with, it certainly is better than hitting that speedtest site where anything at all problematic on the customer LAN side of the CPE can cause erroneous results. > the above aside, how about using the network test suite from Mlabs? <http://www.measurementlab.net/measurement-lab-tools> Or ask the swedish folk who've deployed 'speedtest' gear for the swedish isp/users to tst against? (common test infrastructure). -chris From jbates at brightok.net Sat Jan 29 15:24:54 2011 From: jbates at brightok.net (Jack Bates) Date: Sat, 29 Jan 2011 15:24:54 -0600 Subject: Strange L2 failure Message-ID: <4D4485A6.3040203@brightok.net> Has anyone seen issues with IOS where certain MACs fail? 54:52:00 (kvm) fails out an old 10mbit port on a 7206 running 12.2 SRE. I've never seen anything like this. DHCP worked, ARP worked, and arp debugging showed responses for arp to the MAC, however, tcpdump on the host system showed no unicast or arp responses coming from the router, while the switch management ip and other stuff on the local segment communicated fine with the vm. This broke for IPv6 as well. I changed the vm's MAC to 54:51:00, 50:52:00 and still failed. Changed it to 40:52:00 and it works for both v4 and v6. Was there a change which would cause certain hardware to not accept a MAC starting with 50: or higher? Jack From vixie at isc.org Sat Jan 29 16:00:05 2011 From: vixie at isc.org (Paul Vixie) Date: Sat, 29 Jan 2011 22:00:05 +0000 Subject: [arin-announce] ARIN Resource Certification Update In-Reply-To: Your message of "Sat, 29 Jan 2011 16:26:55 +0100." <FDFF6713-AB2E-4447-A58B-52CD36A6113A@ripe.net> References: <EE59203D-907A-4AA2-BAE6-AEE7AADAC0A2@arin.net> <0BC31466-09EA-4734-96B2-152453A62B90@arin.net> <FDFF6713-AB2E-4447-A58B-52CD36A6113A@ripe.net> Message-ID: <23824.1296338405@nsa.vix.com> > From: Alex Band <alexb at ripe.net> > Date: Sat, 29 Jan 2011 16:26:55 +0100 > > ... So the question is, if the RIPE NCC would have required everyone > to run their own certification setup using the open source tool-sets > Randy mentions, would there be this much certified address space now? i don't agree that that question is pertinent. in deployment scenario planning i've come up with three alternatives and this question is not relevant to any of them. perhaps you know a fourth alternative. here are mine. 1. people who receive routes will prefer signed vs. unsigned, and other people who can sign routes will sign them if it's easy (for example, hosted) but not if it's too hard (for example, up/down). 2. same as #1 except people who really care about their routes (like banks or asp's) will sign them even if it is hard (for example, up/down). 3. people who receive routes will ignore any unsigned routes they hear, and everyone who can sign routes will sign them no matter how hard it is. i do not expect to live long enough to see #3. the difference between #1 and #2 depends on the number of validators not the number of signed routes (since it's an incentive question). therefore small differences in the size of the set of signed routes does not matter very much in 2011, and the risk:benefit profile of hosted vs. up/down still matters far more. > Looking at the depletion of IPv4 address space, it's going to be > crucially important to have validatable proof who is the legitimate > holder of Internet resources. I fear that by not offering a hosted > certification solution, real world adoption rates will rival those of > IPv6 and DNSSEC. Can the Internet community afford that? while i am expecting a rise in address piracy following depletion, i am not expecting #3 (see above) and i think most of the piracy will be of fallow or idle address space that will therefore have no competing route (signed or otherwise). this will become more pronounced as address space holders who care about this and worry about this sign their routes -- the pirates will go after easier prey. so again we see no material difference between hosted and up/down on the deployment side or if there is a difference it is much smaller than the risk:benefit profile difference on the provisioning side. in summary, i am excited about RPKI and i've been pushing hard for in both my day job and inside the ARIN BoT, but... let's not overstate the case for it or kneejerk our way into provisioning models whose business sense has not been closely evaluated. as john curran said, ARIN will look to the community for the guideance he needs on this question. i hope to see many of you at the upcoming ARIN public policy meeting in san juan PR where this is sure to be discussed both at the podium and in the hallways and bar rooms. Paul Vixie Chairman and Chief Scientist, ISC Member, ARIN BoT From franck at genius.com Sat Jan 29 16:06:38 2011 From: franck at genius.com (Franck Martin) Date: Sun, 30 Jan 2011 11:06:38 +1300 (FJST) Subject: Found: Who is responsible for no more IP addresses In-Reply-To: <AANLkTikfbUuueHG2ax_HP4MW+w_3uvHA8qWVKmQPB+QT@mail.gmail.com> Message-ID: <13249597.1234.1296338793399.JavaMail.franck@franck-martins-macbook-pro.local> You should do a rap song... IPv6, IPv4, it is all my fault! Internet was just an experiment ----- Original Message ----- From: "Joly MacFie" <joly at punkcast.com> To: "Ben McGinnes" <ben at adversary.org> Cc: nanog at nanog.org Sent: Sunday, 30 January, 2011 6:36:21 AM Subject: Re: Found: Who is responsible for no more IP addresses Thanks for the link to the vid. I see Geoff Huston spoke too. I've embedded both on http://www.isoc-ny.org/p2/?p=1713 FWIW Vint has been using this as an intro to IPv6 for years.. in fact I've got some video to edit of him speaking in 1999 - I'll look for it.. j From don at bowenvale.co.nz Sat Jan 29 16:45:25 2011 From: don at bowenvale.co.nz (Don Gould) Date: Sun, 30 Jan 2011 11:45:25 +1300 Subject: help needed - state of california needs a benchmark In-Reply-To: <4D4455C4.6080305@tiedyenetworks.com> References: <4D4455C4.6080305@tiedyenetworks.com> Message-ID: <4D449885.2070206@bowenvale.co.nz> Morning Mike, The *New Zealand Government* don't use speedtest.net as a benchmark. Our Government uses a consulting company to provide a range of tests that address the issues you're talking about and benchmarks are published each year. http://www.comcom.govt.nz/broadband-reports The user and network communities are not 100% happy with the way this testing is done either. http://www.geekzone.co.nz/forums.asp?forumid=49&topicid=73698 Some providers are know to fudge the results by putting QoS on the test paths. http://weathermap.karen.net.nz/ is a New Zealand academic project that shows their network performance in real time. This is a very useful site for demonstrating the sort of tools that Governments should be looking for when doing performance measuring. Recent work done by Jared Kells, in Australia, on consumer level network performance shows a very interesting picture (pictures are best for political people). http://forums.whirlpool.net.au/forum-replies.cfm?t=1579142 Kells demonstrates that providers deliver very different results for national and international sites. Kells provides a set of Open Source tools to do your own testing. http://www.truenet.co.nz - John Butt - is a commercial start up providing another range of testing metrics which the user community at www.geekzone.co.nz seem to be much happier with as a proper indication of network performance. I have talked with John personally and can attest that the testing is fairly robust and addresses issues that you've raised. http://www.truenet.co.nz/how-does-it-work The recent upgrades of www.telstraclear.co.nz HFC network from DOCIS2.0 (25/2 max) to DOCIS3.0 (100/10 testing introduction speed) presented a range of challenges for John's testing. http ramp up speeds to 100mbit cause impact on test results, so John had to change the way they were testing to get a better performance presentation. Internode in Australia have learnt the hard way recently that consumer expectation of their new NBN FTTH network needs to be managed carefully. As a result of some very poor media press over the performance of an education site recently installed in Tasmania, they have engaged in quite a bit of consumer education around network performance. http://www.theaustralian.com.au/news/nation/governments-broadband-not-up-to-speed-at-tasmanian-school/story-e6frg6nf-1225961150410 - http://whrl.pl/Rcyrhz - <http://forums.whirlpool.net.au/user/6258>Simon Hackett - Internode CEO responds. *Speedtest.net* will only provide a BIR/PIR measure, and not CIR, which is not an indicator of service quality. In New Zealand SpeedTest.net is used extensively with a number of hosting servers. The information is fundamentally flawed as you have no control over what testing the end user performs. In my case I can product three different tests from a 15/2 HFC service and get 3 different results. http://www.speedtest.net/result/1133639492.png - Test 1 - The application has identified that I am located in Christchurch New Zealand so has selected a Christchurch based server for testing (www.snap.co.nz). As you can see the results show ~7.5/2.1mbits/s. http://www.speedtest.net/result/1133642520.png - Test 2 - This time I've chosen the CityLink (www.citylink.co.nz) server in Wellington New Zealand. ~6.2/1.97bits/s. http://www.speedtest.net/result/1052386636.png - Test 3 - from 12/12/10 shows ~15.1/2.15. This was tested to an Auckland, New Zealand server. I did run a set of tests this morning to the Auckland servers as well, however they are all being limited to the same numbers as the Christchurch test (1) now. None of the servers are on my providers network and performance is governed by the peering/hand overs between the networks. Christchurch - Wellington - 320km - Christchurch - Auckland - 750km straight line distances according to Google Earth. The HFC service I'm using will deliver a through put of 15/2 for some time even at peek usage times when pulling content off the providers own network. Ok, that's enough for now. I hope this helps and let me know if you need any more assistance. Cheers Don From frnkblk at iname.com Sat Jan 29 16:47:43 2011 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 29 Jan 2011 16:47:43 -0600 Subject: help needed - state of california needs a benchmark In-Reply-To: <4D4455C4.6080305@tiedyenetworks.com> References: <4D4455C4.6080305@tiedyenetworks.com> Message-ID: <009901cbc006$8abeadc0$a03c0940$@iname.com> Configure your DNS server so that speedtest.net and every variation to point to the Speedtest that you host... Frank -----Original Message----- From: Mike [mailto:mike-nanog at tiedyenetworks.com] Sent: Saturday, January 29, 2011 12:01 PM To: NANOG list Subject: help needed - state of california needs a benchmark Hello, My company is small clec / broadband provider serving rural communities in northern California, and we are the recipient of a small grant from the state thru our public utilities commission. We went out to 'middle of nowhere' and deployed adsl2+ in fact (chalk one up for the good guys!), and now that we're done, our state puc wants to gather performance data to evaluate the result of our project and ensure we delivered what we said we were going to. Bigger picture, our state is actively attempting to map broadband availability and service levels available and this data will factor into this overall picture, to be used for future grant/loan programs and other support mechanisms, so this really is going to touch every provider who serves end users in the state. The rub is, that they want to legislate that web based 'speedtest.com' is the ONLY and MOST AUTHORITATIVE metric that trumps all other considerations and that the provider is %100 at fault and responsible for making fraudulent claims if speedtest.com doesn't agree. No discussion is allowed or permitted about sync rates, packet loss, internet congestion, provider route diversity, end user computer performance problems, far end congestion issues, far end server issues or cpu loading, latency/rtt, or the like. They are going to decide that the quality of any provider service, is solely and exclusively resting on the numbers returned from 'speedtest.com' alone, period. All of you in this audience, I think, probably immediately understand the various problems with such an assertion. Its one of these situations where - to the uninitiated - it SEEMS LIKE this is the right way to do this, and it SEEMS LIKE there's some validity to whats going on - but in practice, we engineering types know it's a far different animal and should not be used for real live benchmarking of any kind where there is a demand for statistical validity. My feeling is that - if there is a need for the state to do benchmarking, then it outta be using statistically significant methodologies for same along the same lines as any other benchmark or test done by other government agencies and national standards bodies that are reproducible and dependable. The question is, as a hotbutton issue, how do we go about getting 'the message' across, how do we go about engineering something that could be considered statistically relevant, and most importantly, how do we get this to be accepted by non-technical legislators and regulators? Mike- From owen at delong.com Sat Jan 29 19:52:57 2011 From: owen at delong.com (Owen DeLong) Date: Sat, 29 Jan 2011 17:52:57 -0800 Subject: [arin-announce] ARIN Resource Certification Update In-Reply-To: <F4820171-5F43-480C-B0BA-2BB9D473C75D@lacnic.net> References: <EE59203D-907A-4AA2-BAE6-AEE7AADAC0A2@arin.net> <0BC31466-09EA-4734-96B2-152453A62B90@arin.net> <FDFF6713-AB2E-4447-A58B-52CD36A6113A@ripe.net> <F4820171-5F43-480C-B0BA-2BB9D473C75D@lacnic.net> Message-ID: <60020FA8-364E-4F19-951A-95D971FDDD76@delong.com> I don't understand why you can't have a hosted solution where the private keys are not held by the host. Seems to me you should be able to use a Java Applet to do the private key generation and store the private key on the end-user's machine, passing objects that need to be signed by the end user down to the applet for signing. This could be just as low-entry for the user, but, without the host holding the private keys. What am I missing? Owen On Jan 29, 2011, at 1:06 PM, Arturo Servin wrote: > > I agree with Alex that without a hosted solution RIPE NCC wouldn't have so many ROAs today, for us, even with it, it has been more difficult to roll out RPKI among our ISPs. As many, I do not think that a hosted suits to everybody and it has some disadvantages but at leas it could help to lower the entry barrier for some. > > > Speaking about RPKI stats, here some ROA evolution in various TAs (the data from ARIN is from their beta test, the rest are production systems): > > http://www.labs.lacnic.net/~rpki/rpki-evolution-report_EN.txt > > And visually: > > http://www.labs.lacnic.net/~rpki/rpki-heatmaps/latest/global-roa-heatmap.png > > and > > http://www.labs.lacnic.net/~rpki/rpki-heatmaps/latest/ > > To see each region. > > http://www.labs.lacnic.net/~rpki/rpki-heatmaps > > Also, bgpmon has a nice whois interface for humans to see ROAs (not sure if this link was share here or in twitter, sorry if I am duplicating): > > http://bgpmon.net/blog/?p=414 > > > Best regards, > -as > > > > On 29 Jan 2011, at 13:26, Alex Band wrote: > >> John, >> >> Thanks for the update. With regards to offering a hosted solution, as you know that is the only thing the RIPE NCC currently offers. We're developing support for the up/down protocol as I write this. >> >> To give you some perspective, one month after launching the hosted RIPE NCC Resource Certification service, 216 LIRs are using it in the RIPE Region and created 169 ROAs covering 467 prefixes. This means 40151 /24 IPv4 prefixes and 7274499 /48 IPv6 prefixes now have a valid ROA associated with them. >> >> I realize a hosted solution is not ideal, we're very open about that. But at least in our region, it seems there are quite a number of organizations who understand and accept the security trade-off of not being the owner of the private key for their resource certificate and trust their RIR to run a properly secured and audited service. So the question is, if the RIPE NCC would have required everyone to run their own certification setup using the open source tool-sets Randy mentions, would there be this much certified address space now? >> >> Looking at the depletion of IPv4 address space, it's going to be crucially important to have validatable proof who is the legitimate holder of Internet resources. I fear that by not offering a hosted certification solution, real world adoption rates will rival those of IPv6 and DNSSEC. Can the Internet community afford that? >> >> Alex Band >> Product Manager, RIPE NCC >> >> P.S. For those interested in which prefixes and ASs are in the RIPE NCC ROA Repository, here is the latest output in CSV format: >> http://lunimon.com/valid-roas-20110129.csv >> >> >> >> On 24 Jan 2011, at 21:33, John Curran wrote: >> >>> Copy to NANOG for those who aren't on ARIN lists but may be interested in this info. >>> FYI. >>> /John >>> >>> Begin forwarded message: >>> >>> From: John Curran <jcurran at arin.net<mailto:jcurran at arin.net>> >>> Date: January 24, 2011 2:58:52 PM EST >>> To: "arin-announce at arin.net<mailto:arin-announce at arin.net>" <arin-announce at arin.net<mailto:arin-announce at arin.net>> >>> Subject: [arin-announce] ARIN Resource Certification Update >>> >>> ARIN continues its preparations for offering production-grade resource certification >>> services for Internet number resources in the region. ARIN recognizes the importance >>> of Internet number resource certification in the region as a key element of further >>> securing Internet routing, and plans to rollout Resource Public Key Infrastructure (RPKI) >>> at the end of the second quarter of 2011 with support for the Up/Down protocol for those >>> ISPs who wish to certify their subdelegations via their own RPKI infrastructure. >>> >>> ARIN continues to evaluate offering a Hosting Resource Certification service for this >>> purpose (as an alternative to organizations having to run their own RPKI infrastructure), >>> but at this time it remains under active consideration and is not committed. We look >>> forward to discussing the need for this type of service and the organization implications >>> atour upcoming ARIN Members Meeting in April in San Juan, PR. >>> >>> FYI, >>> /John >>> >>> John Curran >>> President and CEO >>> ARIN >>> >>> _______________________________________________ >>> ARIN-Announce >>> You are receiving this message because you are subscribed to >>> the ARIN Announce Mailing List (ARIN-announce at arin.net<mailto: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 ml at kenweb.org Sat Jan 29 20:47:56 2011 From: ml at kenweb.org (ML) Date: Sat, 29 Jan 2011 21:47:56 -0500 Subject: Strange L2 failure In-Reply-To: <4D4485A6.3040203@brightok.net> References: <4D4485A6.3040203@brightok.net> Message-ID: <4D44D15C.90106@kenweb.org> On 1/29/2011 4:24 PM, Jack Bates wrote: > Has anyone seen issues with IOS where certain MACs fail? > > 54:52:00 (kvm) fails out an old 10mbit port on a 7206 running 12.2 SRE. > I've never seen anything like this. DHCP worked, ARP worked, and arp > debugging showed responses for arp to the MAC, however, tcpdump on the > host system showed no unicast or arp responses coming from the router, > while the switch management ip and other stuff on the local segment > communicated fine with the vm. This broke for IPv6 as well. > > I changed the vm's MAC to 54:51:00, 50:52:00 and still failed. Changed > it to 40:52:00 and it works for both v4 and v6. Was there a change which > would cause certain hardware to not accept a MAC starting with 50: or > higher? > > > Jack > I just ran into something like this yesterday. A Belkin router with a MAC of 9444.52dc.XXXX was properly learned at the IDF switch but the upstream agg switch/router wouldn't learn it. I even tried to static the MAC into the CAM..router refused. After changing the MAC address, everything worked. Best I can figure the router treated it like a broadcast MAC. DHCP snooping at the IDF and the upstream aggregation switch/router learned the IP/MAC/interface lease information. ARP entry at the router had the correct IP/MAC binding. Nothing in the CAM for the MAC of that darn Belkin. From jbates at brightok.net Sat Jan 29 21:05:58 2011 From: jbates at brightok.net (Jack Bates) Date: Sat, 29 Jan 2011 21:05:58 -0600 Subject: Strange L2 failure In-Reply-To: <4D44D15C.90106@kenweb.org> References: <4D4485A6.3040203@brightok.net> <4D44D15C.90106@kenweb.org> Message-ID: <4D44D596.3070707@brightok.net> On 1/29/2011 8:47 PM, ML wrote: > I just ran into something like this yesterday. A Belkin router with a > MAC of 9444.52dc.XXXX was properly learned at the IDF switch but the > upstream agg switch/router wouldn't learn it. I even tried to static > the MAC into the CAM..router refused. That's what really tripped me out, was that the router actually did place an ARP entry and pretended like everything should be working. Scheduling some more direct tests with packet sniffers next week when I get back in the office. I'm curious now if IOS has the issue or the line card, so we'll test off different cards direct and monitor results. Jack From jsw at inconcepts.biz Sat Jan 29 21:50:05 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Sat, 29 Jan 2011 22:50:05 -0500 Subject: ARIN IRR Authentication (was: Re: AltDB?) In-Reply-To: <EB7C0B14-A399-4572-85C9-8557F2C1BD2D@corp.arin.net> References: <59051.1294464800@nsa.vix.com> <00041A16-473F-4F96-93E8-E3CD3F83E1B2@virtualized.org> <70374.1294475040@nsa.vix.com> <m2aajb4vb7.wl%randy@psg.com> <m28vyv4uv0.wl%randy@psg.com> <5336.1294506839@nsa.vix.com> <Pine.LNX.4.61.1101081243291.5148@soloth.lewis.org> <AANLkTi=TDwNgT5WCx-sQ8NgAZ=NZWQDEWzd6+3CEW4st@mail.gmail.com> <AANLkTikCaadeah6Gub1EG43E0j_4N14Yipm+bjsyNzkw@mail.gmail.com> <m2fwt23glz.wl%randy@psg.com> <AANLkTim+_RqZLLG8BWQOnqgJ_EYDDz6tmKROq=ZGOqF=@mail.gmail.com> <1AAAEF13-B1AC-41CA-8B16-9985FD9E0EB2@arin.net> <4D2BAAE3.8080009@dougbarton.us> <BE650600-AD67-4A51-8FDF-ED3F368A6F06@arin.net> <4D2BFC80.2040305@dougbarton.us> <C6D38F6D-74D0-4E41-8A25-DE1816C860C4@arin.net> <EB7C0B14-A399-4572-85C9-8557F2C1BD2D@corp.arin.net> Message-ID: <AANLkTimdaEOJ1LmFNc+fR6vHm83R=NmbQH8-=_+Jyd3B@mail.gmail.com> On Thu, Jan 27, 2011 at 10:00 PM, John Curran <jcurran at arin.net> wrote: > Based on the ARIN's IRR authentication thread a couple of weeks ago, there > were suggestions placed into ARIN's ACSP process for changes to ARIN's IRR > system. ARIN has looked at the integration issues involved and has scheduled > an upgrade to the IRR system that will accept PGP and CRYPT-PW authentication > as well as implementing notification support for both the mnt-nfy and notify > fields by the end of August 2011. I'm glad to see that a decision was made to improve the ARIN IRR, rather than stick to status-quo or abandon it. However, this response is essentially what most folks I spoke with off-list imagined: You have an immediate operational security problem which could cause service impact to ARIN members and others relying on the ARIN IRR database, and fixing it by allowing passwords or PGP to be used is not very hard. As I have stated on this list, I believe ARIN is not organizationally capable of handling operational issues. This should make everyone very worried about any ARIN involvement in RPKI, or anything else that could possibly have short-term operational impact on networks. Your plan to fix the very simple IRR problem within eight months is a very clear demonstration that I am correct. How did you arrive at the eight month time-frame to complete this project? Can you provide more detail on what CRYPT-PW hash algorithm(s) will be supported? Specifically, the traditional DES crypt(3) is functionally obsolete, and its entire key-space can be brute-forced within a few days on one modern desktop PC. Will you follow the practice established by several other IRR databases (including MERIT RADB) and avoid exposing the hashes by way of whois output and IRR database dumps? If PGP is causing your delay, why don't you address the urgent problem of supporting no authentication mechanism at all first, and allow CRYPT-PW (perhaps with a useful hash algorithm) and then spend the remaining 7.9 months on PGP? The plan and schedule you have announced is indefensible for an operational security issue. -- Jeff S Wheeler <jsw at inconcepts.biz> Sr Network Operator? /? Innovative Network Concepts From ryan.finnesey at HarrierInvestments.com Sat Jan 29 23:30:58 2011 From: ryan.finnesey at HarrierInvestments.com (Ryan Finnesey) Date: Sat, 29 Jan 2011 21:30:58 -0800 Subject: DSL options in NYC for OOB access In-Reply-To: <4D447B83.1050709@nexus6.co.za> References: <4D3DF769.7060601@nexus6.co.za><AANLkTinBEjrL6iwm1xYujA0OZiqGzfRwgXRM_b9D6Y0=@mail.gmail.com><4D441785.7070508@nexus6.co.za><20110129145536.M74977@fast-serv.com> <4D447B83.1050709@nexus6.co.za> Message-ID: <6EFFEFBAC68377459A2E972105C759EC03539A25@EXVBE005-2.exch005intermedia.net> All this out of band management talk is making me think it is an opportunity for a supper low cost DSL offering. Maybe a good way to get read of some capacity we have. Cheers Ryan -----Original Message----- From: Andy Ashley [mailto:lists at nexus6.co.za] Sent: Saturday, January 29, 2011 3:42 PM To: nanog at nanog.org Subject: Re: DSL options in NYC for OOB access On 29/01/2011 14:56, Randy McAnally wrote: > Have you looked into the cross connect cost for your DSL line? They > typically aren't very cheap either. > > ~Randy Im still waiting for the quote to come back from L3. Figured a copper pair would be cheaper than a fiber, but who knows? Andy. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From swmike at swm.pp.se Sat Jan 29 23:57:55 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sun, 30 Jan 2011 06:57:55 +0100 (CET) Subject: help needed - state of california needs a benchmark In-Reply-To: <4D449885.2070206@bowenvale.co.nz> References: <4D4455C4.6080305@tiedyenetworks.com> <4D449885.2070206@bowenvale.co.nz> Message-ID: <alpine.DEB.1.10.1101300649060.13151@uplift.swm.pp.se> On Sun, 30 Jan 2011, Don Gould wrote: > Ok, that's enough for now. I hope this helps and let me know if you > need any more assistance. In Sweden, "Bredbandskollen.se" (translates to "Broadband check") rules supreme. It uses two parallell TCP sessions to measure speed, and the whole industry has agreed (mostly product managers were involved, little attention was given to technical arguments) to set a minimum standard for each service and let people cancel contracts or downgrade if they didn't get that level. For instance, an ADSL2+ connection sold as "up to 24 megabit/s" now let's you cancel or downgrade if you don't get 12 megabit/s TCP throughput. For 100/10 service the lower limit is 40 megabit/s. There is a requirement for the user to not use wireless and to put their computer directly into the ethernet jack (ETTH) without the use of a NAT router, because these can heavily affect service speed. It also features a guide to how to diagnose why you're getting a lower than expected speed. Customer complaints are down so generally this seems to increase customer satisfaction. My biggest objection is that with a 100/10 service download speeds can vary a lot depending what browser vendor and version one is using, TCP settings of course also play a role. The upside is that the sevice is extremely easy to use. -- Mikael Abrahamsson email: swmike at swm.pp.se From santino.codispoti at gmail.com Sun Jan 30 00:09:22 2011 From: santino.codispoti at gmail.com (Santino Codispoti) Date: Sun, 30 Jan 2011 01:09:22 -0500 Subject: DSL network build out Message-ID: <AANLkTinc+9mrXp7nyB2bPzTEXWG4tDWp7tSsE222hRST@mail.gmail.com> I am hoping for some recommendations from the group. We will shortly be building out a new network for offering DSL/ access. We are going to interface with the Covad network within: 111 8th Avenue,New York (5th Floor) 11 Great Oaks Blvd,San Francisco 427 S La Salle, Chicago We are going to try and push most of the trafic out to the internet within the same POPs but we would also like to have conntivity between the locations as well. Who would you recommend we talk with for fiber? Who would you recommend we talk with for network gear? Thank you for your help Regards Santino From joelja at bogus.com Sun Jan 30 01:31:38 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Sat, 29 Jan 2011 23:31:38 -0800 Subject: DSL options in NYC for OOB access In-Reply-To: <6EFFEFBAC68377459A2E972105C759EC03539A25@EXVBE005-2.exch005intermedia.net> References: <4D3DF769.7060601@nexus6.co.za><AANLkTinBEjrL6iwm1xYujA0OZiqGzfRwgXRM_b9D6Y0=@mail.gmail.com><4D441785.7070508@nexus6.co.za><20110129145536.M74977@fast-serv.com> <4D447B83.1050709@nexus6.co.za> <6EFFEFBAC68377459A2E972105C759EC03539A25@EXVBE005-2.exch005intermedia.net> Message-ID: <4D4513DA.8010800@bogus.com> On 1/29/11 9:30 PM, Ryan Finnesey wrote: > All this out of band management talk is making me think it is an > opportunity for a supper low cost DSL offering. Maybe a good way to get > read of some capacity we have. The key of course is that it not be coupled to the physical plant that the other circuits use. I've been in a couple of facilties recently (though not in ny) where riding into the building on twsited pair was at best costly and more generally, infeasible. joel > Cheers > Ryan > > > -----Original Message----- > From: Andy Ashley [mailto:lists at nexus6.co.za] > Sent: Saturday, January 29, 2011 3:42 PM > To: nanog at nanog.org > Subject: Re: DSL options in NYC for OOB access > > On 29/01/2011 14:56, Randy McAnally wrote: > >> Have you looked into the cross connect cost for your DSL line? They >> typically aren't very cheap either. >> >> ~Randy > Im still waiting for the quote to come back from L3. > Figured a copper pair would be cheaper than a fiber, but who knows? > > Andy. > > > -- > This message has been scanned for viruses and dangerous content by > MailScanner, and is believed to be clean. > > > > From aa at tenet.ac.za Sun Jan 30 02:23:39 2011 From: aa at tenet.ac.za (Andrew Alston) Date: Sun, 30 Jan 2011 10:23:39 +0200 Subject: Level 3's IRR Database Message-ID: <E65B3ED7E6FCBA48BC3E2FA899729216018E704D@rouwkoop.ac.za> Hi All, I've just noticed that Level 3 is allowing people to register space in its IRR database that A.) is not assigned to the people registering it and B.) is not assigned via/to Level 3. So, I have two queries A.) Are only customers of Level 3 allowed to use this database B.) Can someone from Level 3 please clarify if there are any plans to lock this down slightly At this point, it would seem that if you are a customer of level 3's, you can register any space you feel like in there, and announce anything you feel like once the filters propagate, which in my opinion completely nullifies the point of IRR in the first place. Though I think this also raises the question about IRR databases in general. Would it not be far more sane to have each RIR run a single instance each which talk to each other, which can be verified against IP address assignments, and scrap the distributed IRR systems that allow for issues like this to occur? (In the mean time I've emailed the relevant people to try and get the entries falsely registered in that database removed, and will wait and see if I get a response). Andrew Alston TENET - Chief Technology Officer Phone: +27 21 763 7181 From ryan.finnesey at HarrierInvestments.com Sun Jan 30 02:40:19 2011 From: ryan.finnesey at HarrierInvestments.com (Ryan Finnesey) Date: Sun, 30 Jan 2011 00:40:19 -0800 Subject: DSL options in NYC for OOB access In-Reply-To: <4D4513DA.8010800@bogus.com> References: <4D3DF769.7060601@nexus6.co.za><AANLkTinBEjrL6iwm1xYujA0OZiqGzfRwgXRM_b9D6Y0=@mail.gmail.com><4D441785.7070508@nexus6.co.za><20110129145536.M74977@fast-serv.com> <4D447B83.1050709@nexus6.co.za> <6EFFEFBAC68377459A2E972105C759EC03539A25@EXVBE005-2.exch005intermedia.net> <4D4513DA.8010800@bogus.com> Message-ID: <6EFFEFBAC68377459A2E972105C759EC03539A28@EXVBE005-2.exch005intermedia.net> Yes depending on the building location in most places we have two options for access cable plant (TWC, Comcast ect) or LEC. All via Layer 2. Cheers Ryan -----Original Message----- From: Joel Jaeggli [mailto:joelja at bogus.com] Sent: Sunday, January 30, 2011 2:32 AM To: Ryan Finnesey Cc: Andy Ashley; nanog at nanog.org Subject: Re: DSL options in NYC for OOB access On 1/29/11 9:30 PM, Ryan Finnesey wrote: > All this out of band management talk is making me think it is an > opportunity for a supper low cost DSL offering. Maybe a good way to > get read of some capacity we have. The key of course is that it not be coupled to the physical plant that the other circuits use. I've been in a couple of facilties recently (though not in ny) where riding into the building on twsited pair was at best costly and more generally, infeasible. joel > Cheers > Ryan > > > -----Original Message----- > From: Andy Ashley [mailto:lists at nexus6.co.za] > Sent: Saturday, January 29, 2011 3:42 PM > To: nanog at nanog.org > Subject: Re: DSL options in NYC for OOB access > > On 29/01/2011 14:56, Randy McAnally wrote: > >> Have you looked into the cross connect cost for your DSL line? They >> typically aren't very cheap either. >> >> ~Randy > Im still waiting for the quote to come back from L3. > Figured a copper pair would be cheaper than a fiber, but who knows? > > Andy. > > > -- > This message has been scanned for viruses and dangerous content by > MailScanner, and is believed to be clean. > > > > From millnert at gmail.com Sun Jan 30 03:06:03 2011 From: millnert at gmail.com (Martin Millnert) Date: Sun, 30 Jan 2011 04:06:03 -0500 Subject: Wikileaks, Friend or Foe? In-Reply-To: <AANLkTimauS=3wJ2Z3thWOw1AEO=iLK-VrhrYfGavR=2h@mail.gmail.com> References: <AANLkTimauS=3wJ2Z3thWOw1AEO=iLK-VrhrYfGavR=2h@mail.gmail.com> Message-ID: <AANLkTikz8_9fz12mEi0dXKC3TdrQDMaNUE603V-jWdhh@mail.gmail.com> On Sun, Jan 30, 2011 at 3:52 AM, Joseph Prasad <joseph.prasad at gmail.com> wrote: > A very good interview with John Young on Russia Today. > > http://www.youtube.com/watch?v=oMRUiB_8tTc One thing that Mr Young mentions in this interview is the threat secret governance poses for any free and democratic society and how there should be more debate on this with regards to the internet... There was a /very/ good debate on this at the Churchill Club in San Francisco two weeks ago, with many top tier Bay Area people in the audience: http://www.churchillclub.org/eventDetail.jsp?EVT_ID=892 Watch it at: http://fora.tv/2011/01/19/WikiLeaks_Why_It_Matters_Why_It_Doesnt Anyone interested in this topic will do good to watch this piece (1h 48m in total). If you feel hesitant to watch all of it, start with chapter 9 and 10. This piece contains plenty food for thought. Cheers, Martin From jsw at inconcepts.biz Sun Jan 30 03:08:45 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Sun, 30 Jan 2011 04:08:45 -0500 Subject: Level 3's IRR Database In-Reply-To: <E65B3ED7E6FCBA48BC3E2FA899729216018E704D@rouwkoop.ac.za> References: <E65B3ED7E6FCBA48BC3E2FA899729216018E704D@rouwkoop.ac.za> Message-ID: <AANLkTi=ZhLT0HeWkZ1f57vu6sistskj_rgibEzDiBe3Y@mail.gmail.com> On Sun, Jan 30, 2011 at 3:23 AM, Andrew Alston <aa at tenet.ac.za> wrote: > I've just noticed that Level 3 is allowing people to register space in its IRR database that A.) is not assigned to the people registering it and B.) is not assigned via/to Level 3. This is not unique to Level3 -- it is the industry standard practice and has been since the dawn of time. You must be a Level3 customer to have a mntner: for publishing to their IRR database (in theory.) Since there isn't an automatic mechanism for verifying that a given ISP is really allowed to originate a route (or provide transit for an AS, etc.) there is simply no practical way to change this at this time, without processing updates manually (and introducing human error into that yes/no authorization check.) IRR is a convenience that many networks rely on. When done correctly, this is not a bad idea by any means. In theory, RPKI will fix the real problem you are addressing -- that it is really difficult to verify whether or not a neighboring AS is allowed to carry a given route. In practice, vendors need to support it on routers, networks need to upgrade, ARIN (and other RIRs) need to do their part, and thousands of auto-pilot networks will need to be hand-held by their ISPs in order to make this happen. How soon theory can become reality is not easy to predict. How many networks have ubiquitous support for 32 bit ASN? IPv6? RPKI is a bastard thing created out of a perceived (perhaps correctly) need for real security, when in fact basically all of the events that have led to its creation (except for some scare-tactic papers and presentations) were not deliberate. This brings me to my point, which is that IRR is very good for preventing accidents and automating some common tasks. It should be "secure" to a point, but just because a route: object exists does not mean that mntner: really has authority over that address space. You can pretty much rely on the fact that the given origin AS is intentionally announcing the route, as opposed to leaking it by accident. -- Jeff S Wheeler <jsw at inconcepts.biz> Sr Network Operator? /? Innovative Network Concepts From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sun Jan 30 03:47:38 2011 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sun, 30 Jan 2011 20:17:38 +1030 Subject: /64 is "enough" until 2021 for 90% of users (was Re: Another v6 question) In-Reply-To: <E628DA61-DF9B-46D6-9E0E-C813B06A48B6@puck.nether.net> References: <AANLkTikEZVYFz+bx7MVXeht_qNnpkUEC_Mx0qhE6J9SR@mail.gmail.com> <55E7EC47-C434-4DF7-B92A-8EBC24133C53@delong.com> <AANLkTi=soS+LQoR3JYJxE8N3o9JYoxrL2dvzHZ+e5Geb@mail.gmail.com> <4F209412-3C3B-4CB6-8EB7-A25ABD1B9DBA@delong.com> <AANLkTinqipvQD-gSt1BZ5FcPT2krNhwqO5dExWrM=muG@mail.gmail.com> <67827BB1-BF59-45AF-842F-B9E1AD7A1F87@delong.com> <A5E4AFBB-92C6-464E-AAAB-07B69ECD5214@puck.nether.net> <C52BD26B-2E5B-4B8B-8CAE-8CD60E6C6DF7@delong.com> <E628DA61-DF9B-46D6-9E0E-C813B06A48B6@puck.nether.net> Message-ID: <20110130201738.33b85e0f@opy.nosense.org> On Thu, 27 Jan 2011 11:03:41 -0500 Jared Mauch <jared at puck.nether.net> wrote: > > On Jan 27, 2011, at 10:04 AM, Owen DeLong wrote: > > > > > On Jan 27, 2011, at 6:49 AM, Jared Mauch wrote: > > > >> > >> On Jan 26, 2011, at 8:33 PM, Owen DeLong wrote: > >> > >>> I'd like to see IPv4 go away in ~3 years. Any faster would be too traumatic. > >>> I think 6 years is a perfectly reasonable time frame. I think if it takes 11 years > >>> it will be because of significant foot-dragging by some key organizations. > >>> I'm not convinced that foot-dragging is as likely as some people are, but, > >>> there's enough probability to provide some wiggle room in the numbers. > >> > >> I expect that in ~3 years, we will see dual-stack and /64's handed out in conjunction with an IPv4 address as "common". > >> > >> The ipv6 zealots talking about anything but a /64 for end-site are talking about a "business class" service. Even with my static IPs at home, I have no need for more than a single /64 to be used in my wildest dreams. I could live with ~256 ips for the future. I consider my tech density "above-average". > >> > >> - Jared > > > > As one of the IPv6 zealots talking about anything but a /64 for end sites, I > > can assure you that I am talking about it for residential class service > > not business class. > > > > Your tech density may be above average for today, but, you lack vision > > for the future. > > > > Imagine a future where devices form autonomous network segments > > and negotiate prefixes and routing for those segments in a semi- > > or fully- autonomous fashion. > > > > The appliance net in the kitchen will be managed by a router. > > The RFID tags on the products in your fridge and your pantries > > will form autnonous subnets with routers embedded in the > > fridge and pantries. Each of your home entertainment clusters > > will likely form its own subnet. > > > > Even today, it is not uncommon for a residential gateway to support > > at least five segments: > > > > 1. External WAN segment shared with ISP > > 2. Internal wired network > > 3. Internal wireless network > > 4. "DMZ" segment > > 5. Guest wireless network > > > > Seriously, it's important that we do not limit our IPv6 thinking by > > our IPv4 mindset. The future is not the present and we will see > > much more advanced capabilities in the residential world > > going forward if we allow it to happen. > > > I'm not. There's certainly interesting use cases of this "IP" header type, independent of being v4 or v6. > > You're talking about the various segments, and I'm thinking about the folks from Toyota doing their ipv6 local networks integrated into vehicles. But many people are also stuck in thinking that these people need to be segmented in the first place. This "security by obscurity" mentality that being behind a VPN, being air-gapped, wired, wireless, that you are deserving of a variable class of service is part of the discussion. > > I could call out vendors that have highly sensitive data that is available "if only" you brought a cat5 cable to the office vs using their "guest" wireless. that segmentation ignores the authentication of end-stations, or person behind the keyboard. If you actually did that, you don't need to have a different 'guest' wireless vs the 'internal' wireless network. > > Now, I don't think that by reading this that an enterprise is going to clean up their act, (wired vs wireless), or stop any other silly practices using these "packet eating" firewall/nat/vpn devices. > > But tying those practices in to the equation can serve to validate the premise that these people actually need to be segmented vs solving the real security (trust) problem that exists on the end devices. You don't necessarily need to see my AppleTV on my home network, but as a guest at my home, (after authenticating to my local wireless network) you gain access to play music and control various elements of my network. I don't need to make these "public", but if they are on a public-IP, the devices should be able to be properly secured (and can be). > > I don't think I need a public and private FridgeNet to determine the quantity and quality of the beverages and offer different SLAs based on if they are on the 'guestFridgeNet' vs 'privateFridgeNet'. This is taking it a step or three too far. Most people don't know or care what their IP subnet is. Even if every time I connected a device to my network (or re-connected after power saving, etc) I incremented the usable part of my /64, it would take me some time to consume that space fully. > > I do think we're closer together than apart, but for 90% of home users, (and you can quote me on this in 10 years) a /64 will be sufficient for their uses. Anyone needing more than a /64 for their home is either going to some impractical extreme or better defined as a "prosumer" that will want a higher SLA in the first place, and therefore should pay a modest amount more. > ' I think you need to review what subnets originally and are still essential for - overcome link layer framing differences - isolate broadcast or multicast traffic from nodes that aren't interested in it or even the act of ignoring that type of traffic is unacceptably resource intensive for those types of nodes I agree with your comments about security shouldn't rely on addressing. My preferred model would be something like the bluetooth pairing model (i.e. trusted assocations) with time limit on the trust. Even then, it isn't really the machines you can't trust, it's the people behind them, and those people aren't bound to certain select machines. Subnets became security domain boundaries because (a) hosts didn't used to have any sort of firewalling capabilities, where as routers did (i.e. ACLs) and (b) hosts tended to naturally be grouped together based on where security domains would occur e.g. all of H.R.s PCs were attached to the same subnet as all those staff existed on the same building floor or area. However, even if an addressing agnostic host security association mechanisms emerges, we still have an interim period until then where security or policy by subnet is necessary, and we'll also have reasons to subnet after then - the original and same reasons why routers were invented and bridges couldn't do the job. Regards, mark. From alexb at ripe.net Sun Jan 30 04:39:36 2011 From: alexb at ripe.net (Alex Band) Date: Sun, 30 Jan 2011 11:39:36 +0100 Subject: [arin-announce] ARIN Resource Certification Update In-Reply-To: <23824.1296338405@nsa.vix.com> References: <EE59203D-907A-4AA2-BAE6-AEE7AADAC0A2@arin.net> <0BC31466-09EA-4734-96B2-152453A62B90@arin.net> <FDFF6713-AB2E-4447-A58B-52CD36A6113A@ripe.net> <23824.1296338405@nsa.vix.com> Message-ID: <43932B92-602B-4903-B2D0-F0D160821918@ripe.net> Paul, I think my question is very pertinent. Of course the number of signed prefixes directly influences the number of validators. Do you think the RIPE NCC Validator tool would have been downloaded over 100 times in the last month if there were only 5 certified prefixes? In my opinion, the widespread availability of signed prefixes and mature validation methods is key to the global success of resource certification. I agree that small differences in the size of the set of signed routes don't matter on a (relatively) short term, but the reality is that the difference would be *enormous* if we wouldn't offer a hosted solution. Practically, in the real world, why would anyone invest time and effort in altering their current BGP decision making process to accommodate for resource certification if the technology is on nobody's radar, it's hard to get your feet wet and there are just a handful of certified prefixes out there. Wouldn't it be good if network operators think: "Because it helps increase global routing security, it's easy to get started and lots of people are already involved, perhaps I should have a look at (both sides of) resource certification too." This is why I believe ? and our adoption numbers prove ? that the entry barrier to the system should be as low as possible, both on the signing side and the validation side. Once some of the people that are using the hosted platform now decide they would rather run their own non-hosted solution at a later stage, that would be even better. That immediately solves the private key situation. But there will always be a group happy to rely on the hosted model, and we cater to that. Because of the path we chose there is already a lot of operational experience being gained, resulting in a large amount of feedback from a wide range of users. This helps us shape the certification system and the validator tool, which aids quality and usability. To me, that makes a lot of business sense. This is why I think there should be as much certified address space available as possible. Otherwise this will stay a niche technology until perhaps a major event causes people to wake up (and hopefully take action). If certification has reached the necessary level of maturity at that point remains to be seen. Furthermore, preventing (future) malicious hijacking is not the *only* reason the Internet community needs better routing security, the accidental route leaking that happens every day is reason enough. -Alex On 29 Jan 2011, at 23:00, Paul Vixie wrote: >> From: Alex Band <alexb at ripe.net> >> Date: Sat, 29 Jan 2011 16:26:55 +0100 >> >> ... So the question is, if the RIPE NCC would have required everyone >> to run their own certification setup using the open source tool-sets >> Randy mentions, would there be this much certified address space now? > > i don't agree that that question is pertinent. in deployment scenario > planning i've come up with three alternatives and this question is not > relevant to any of them. perhaps you know a fourth alternative. here > are mine. > > 1. people who receive routes will prefer signed vs. unsigned, and other > people who can sign routes will sign them if it's easy (for example, > hosted) but not if it's too hard (for example, up/down). > > 2. same as #1 except people who really care about their routes (like > banks or asp's) will sign them even if it is hard (for example, up/down). > > 3. people who receive routes will ignore any unsigned routes they hear, > and everyone who can sign routes will sign them no matter how hard it is. > > i do not expect to live long enough to see #3. the difference between #1 > and #2 depends on the number of validators not the number of signed routes > (since it's an incentive question). therefore small differences in the > size of the set of signed routes does not matter very much in 2011, and > the risk:benefit profile of hosted vs. up/down still matters far more. > >> Looking at the depletion of IPv4 address space, it's going to be >> crucially important to have validatable proof who is the legitimate >> holder of Internet resources. I fear that by not offering a hosted >> certification solution, real world adoption rates will rival those of >> IPv6 and DNSSEC. Can the Internet community afford that? > > while i am expecting a rise in address piracy following depletion, i am > not expecting #3 (see above) and i think most of the piracy will be of > fallow or idle address space that will therefore have no competing route > (signed or otherwise). this will become more pronounced as address > space holders who care about this and worry about this sign their routes > -- the pirates will go after easier prey. so again we see no material > difference between hosted and up/down on the deployment side or if there > is a difference it is much smaller than the risk:benefit profile > difference on the provisioning side. > > in summary, i am excited about RPKI and i've been pushing hard for in > both my day job and inside the ARIN BoT, but... let's not overstate the > case for it or kneejerk our way into provisioning models whose business > sense has not been closely evaluated. as john curran said, ARIN will > look to the community for the guideance he needs on this question. i > hope to see many of you at the upcoming ARIN public policy meeting in > san juan PR where this is sure to be discussed both at the podium and in > the hallways and bar rooms. > > Paul Vixie > Chairman and Chief Scientist, ISC > Member, ARIN BoT > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1728 bytes Desc: not available URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110130/94b540d2/attachment.bin> From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sun Jan 30 05:01:25 2011 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sun, 30 Jan 2011 21:31:25 +1030 Subject: Another v6 question In-Reply-To: <AANLkTinwAEp1+HAk6jZ_u-8krHgC5nAJA305+Cvh3ypo@mail.gmail.com> References: <AANLkTikEZVYFz+bx7MVXeht_qNnpkUEC_Mx0qhE6J9SR@mail.gmail.com> <55E7EC47-C434-4DF7-B92A-8EBC24133C53@delong.com> <AANLkTi=soS+LQoR3JYJxE8N3o9JYoxrL2dvzHZ+e5Geb@mail.gmail.com> <4F209412-3C3B-4CB6-8EB7-A25ABD1B9DBA@delong.com> <AANLkTinqipvQD-gSt1BZ5FcPT2krNhwqO5dExWrM=muG@mail.gmail.com> <67827BB1-BF59-45AF-842F-B9E1AD7A1F87@delong.com> <AANLkTi=fJbDuv1X_cDSWMzAF7sBkF+2K7+eso97NiQBc@mail.gmail.com> <5CE30429-3FD2-4554-8D57-670DA6F15FBB@delong.com> <AANLkTinwAEp1+HAk6jZ_u-8krHgC5nAJA305+Cvh3ypo@mail.gmail.com> Message-ID: <20110130213125.5eb00206@opy.nosense.org> On Thu, 27 Jan 2011 09:20:01 -0600 Max Pierson <nmaxpierson at gmail.com> wrote: > >I'm not missing your point. I'm saying that in IPv6, we've put enough > addresses > >in to allow for things nobody has thought of in 30, 60, 90, even 100 years > and > >then some. > > As Roland said, > "Possibly, as long as we don't blow through them via exercises in profligacy > nobody has heretofore thought of, heh." > > >If I knew, then, I'd be well on my way to much greater wealth. Whatever it > is, I am only > >certain of the following things about it: > > 1. We have no idea what the requirements will be at this time. > > > I believe it was Donald Rumsfeld that said... > "But there are also unknown unknowns ? the ones we don't know we don't > know." > > What if that unknown comes in the form of "mass address consumption"? But > from your view, that's not possible, so i'll just move on. > We know both what the IPv6 addressing architecture is and what the current IANA/RIR etc. addressing policies are - nothing is an "unknown unknown". *Unexpected* "mass address consumption" is not possible unless and until the current addressing policies change. It is only those who wish to play thought games with how they could abuse 128 bit addresses that are pretending these architectural decisions and policies don't exist and won't be enforced. Mark From carlosm3011 at gmail.com Sun Jan 30 07:57:57 2011 From: carlosm3011 at gmail.com (Carlos Martinez-Cagnazzo) Date: Sun, 30 Jan 2011 11:57:57 -0200 Subject: [arin-announce] ARIN Resource Certification Update In-Reply-To: <43932B92-602B-4903-B2D0-F0D160821918@ripe.net> References: <EE59203D-907A-4AA2-BAE6-AEE7AADAC0A2@arin.net> <0BC31466-09EA-4734-96B2-152453A62B90@arin.net> <FDFF6713-AB2E-4447-A58B-52CD36A6113A@ripe.net> <23824.1296338405@nsa.vix.com> <43932B92-602B-4903-B2D0-F0D160821918@ripe.net> Message-ID: <AANLkTi=eZHzxruo4NzZKYB6VU-oi+XVG=Tz1Sg-fndHn@mail.gmail.com> What I just don?t get if, we as a society, have created institutions we trust with our *money* (AKA banks), why there can?t be institutions we trust with our crypto keys. I know that banks sometimes fail, and yes, probably "crypto banks" will sometimes fail as well, but on the whole, the failure rate of trusted institutions can be quite low, acceptably low. IMO the whole thing seems to boil down to the complex interaction of psychological, emotional and other aspects of how we perceive a certain situation. And it clearly depends on the region, just look at RIPE?s column and how it grows relentlessly (i included only a few lines, full stats can be found in the URL posted by Arturo in an earlier post) R2a. IPv4 Space Covered by ROAs (in units of /24s) ---- date | lacnic| apnic| afrinic| arin| ripe| 2011-01-11 | 17| 189| 1| 0| 28902| 2011-01-12 | 17| 189| 1| 1867.03| 32439| 2011-01-13 | 17| None| 1| 1867.03| 32810| 2011-01-14 | 17| 181| 1| 1867.03| 32819| 2011-01-15 | 17| 181| 1| 1867.03| 32875| 2011-01-16 | 17| 181| 1| 1867.03| 32875| 2011-01-17 | 17| 181| 1| 20| 32903| 2011-01-18 | 17| 181| 2| None| 33783| 2011-01-19 | 17| 177| 2| None| 35271| Hats off to RIPE People! cheers, Carlos On Sun, Jan 30, 2011 at 8:39 AM, Alex Band <alexb at ripe.net> wrote: > Paul, > > I think my question is very pertinent. Of course the number of signed prefixes directly influences the number of validators. Do you think the RIPE NCC Validator tool would have been downloaded over 100 times in the last month if there were only 5 certified prefixes? > > In my opinion, the widespread availability of signed prefixes and mature validation methods is key to the global success of resource certification. I agree that small differences in the size of the set of signed routes don't matter on a (relatively) short term, but the reality is that the difference would be *enormous* if we wouldn't offer a hosted solution. > > Practically, in the real world, why would anyone invest time and effort in altering their current BGP decision making process to accommodate for resource certification if the technology is on nobody's radar, it's hard to get your feet wet and there are just a handful of certified prefixes out there. Wouldn't it be good if network operators think: "Because it helps increase global routing security, it's easy to get started and lots of people are already involved, perhaps I should have a look at (both sides of) resource certification too." > > This is why I believe ? and our adoption numbers prove ? that the entry barrier to the system should be as low as possible, both on the signing side and the validation side. Once some of the people that are using the hosted platform now decide they would rather run their own non-hosted solution at a later stage, that would be even better. That immediately solves the private key situation. But there will always be a group happy to rely on the hosted model, and we cater to that. > > Because of the path we chose there is already a lot of operational experience being gained, resulting in a large amount of feedback from a wide range of users. This helps us shape the certification system and the validator tool, which aids quality and usability. To me, that makes a lot of business sense. This is why I think there should be as much certified address space available as possible. Otherwise this will stay a niche technology until perhaps a major event causes people to wake up (and hopefully take action). If certification has reached the necessary level of maturity at that point remains to be seen. Furthermore, preventing (future) malicious hijacking is not the *only* reason the Internet community needs better routing security, the accidental route leaking that happens every day is reason enough. > > -Alex > > On 29 Jan 2011, at 23:00, Paul Vixie wrote: > >>> From: Alex Band <alexb at ripe.net> >>> Date: Sat, 29 Jan 2011 16:26:55 +0100 >>> >>> ... So the question is, if the RIPE NCC would have required everyone >>> to run their own certification setup using the open source tool-sets >>> Randy mentions, would there be this much certified address space now? >> >> i don't agree that that question is pertinent. ?in deployment scenario >> planning i've come up with three alternatives and this question is not >> relevant to any of them. ?perhaps you know a fourth alternative. ?here >> are mine. >> >> 1. people who receive routes will prefer signed vs. unsigned, and other >> people who can sign routes will sign them if it's easy (for example, >> hosted) but not if it's too hard (for example, up/down). >> >> 2. same as #1 except people who really care about their routes (like >> banks or asp's) will sign them even if it is hard (for example, up/down). >> >> 3. people who receive routes will ignore any unsigned routes they hear, >> and everyone who can sign routes will sign them no matter how hard it is. >> >> i do not expect to live long enough to see #3. ?the difference between #1 >> and #2 depends on the number of validators not the number of signed routes >> (since it's an incentive question). ?therefore small differences in the >> size of the set of signed routes does not matter very much in 2011, and >> the risk:benefit profile of hosted vs. up/down still matters far more. >> >>> Looking at the depletion of IPv4 address space, it's going to be >>> crucially important to have validatable proof who is the legitimate >>> holder of Internet resources. I fear that by not offering a hosted >>> certification solution, real world adoption rates will rival those of >>> IPv6 and DNSSEC. Can the Internet community afford that? >> >> while i am expecting a rise in address piracy following depletion, i am >> not expecting #3 (see above) and i think most of the piracy will be of >> fallow or idle address space that will therefore have no competing route >> (signed or otherwise). ?this will become more pronounced as address >> space holders who care about this and worry about this sign their routes >> -- the pirates will go after easier prey. ?so again we see no material >> difference between hosted and up/down on the deployment side or if there >> is a difference it is much smaller than the risk:benefit profile >> difference on the provisioning side. >> >> in summary, i am excited about RPKI and i've been pushing hard for in >> both my day job and inside the ARIN BoT, but... let's not overstate the >> case for it or kneejerk our way into provisioning models whose business >> sense has not been closely evaluated. ?as john curran said, ARIN will >> look to the community for the guideance he needs on this question. ?i >> hope to see many of you at the upcoming ARIN public policy meeting in >> san juan PR where this is sure to be discussed both at the podium and in >> the hallways and bar rooms. >> >> Paul Vixie >> Chairman and Chief Scientist, ISC >> Member, ARIN BoT >> >> > > -- -- ========================= Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net ========================= From carlosm3011 at gmail.com Sun Jan 30 08:11:50 2011 From: carlosm3011 at gmail.com (Carlos Martinez-Cagnazzo) Date: Sun, 30 Jan 2011 12:11:50 -0200 Subject: [arin-announce] ARIN Resource Certification Update In-Reply-To: <60020FA8-364E-4F19-951A-95D971FDDD76@delong.com> References: <EE59203D-907A-4AA2-BAE6-AEE7AADAC0A2@arin.net> <0BC31466-09EA-4734-96B2-152453A62B90@arin.net> <FDFF6713-AB2E-4447-A58B-52CD36A6113A@ripe.net> <F4820171-5F43-480C-B0BA-2BB9D473C75D@lacnic.net> <60020FA8-364E-4F19-951A-95D971FDDD76@delong.com> Message-ID: <AANLkTin_5UrsUMDDhup8YJrBQXawqF7k_-yq8Zf7h3cY@mail.gmail.com> Do you really think that a set of keys stored in a random PC in a random office is safer than on a periodically backed-up, encrypted database? In this future I only see lost keys, keys appearing listed in something.ru domains, tons of support calls to hostmasters, and ROAs repeatedly becoming invalid, all things that will seriously harm RPKI adoption. In the end, I see two things: - Hosted solutions aren?t supposed to fit everyone, that?s why top-down is being developed. This is not news. - Hosted solutions offer a low barrier entry to smaller organizations who simply cannot develop their own PKI infrastructure. This is the case where they also lack the organizational skills to properly manage the keys themselves, so, in most cases at least, they are *better off* with a hosted solution For RPKI to succeed we have to succeed not only on the technical side but on the *human* side of things. Adoption of RPKI will only move forward if network admins have *confidence* in the stability, dependability and overall quality of the whole system. ROAs repeatedly becoming invalid for the wrong reasons will represent a death blow to RPKI adoption. For RIPE, their hosted solution is clearly meeting expectations within their region. Other region?s mileage may vary. I hope we (LACNIC) can do just as well. Have a great day! Carlos On Sat, Jan 29, 2011 at 11:52 PM, Owen DeLong <owen at delong.com> wrote: > I don't understand why you can't have a hosted solution where the private keys > are not held by the host. > > Seems to me you should be able to use a Java Applet to do the private key > generation and store the private key on the end-user's machine, passing > objects that need to be signed by the end user down to the applet for > signing. > > This could be just as low-entry for the user, but, without the host holding > the private keys. > > What am I missing? > > Owen > > On Jan 29, 2011, at 1:06 PM, Arturo Servin wrote: > >> >> ? ? ? I agree with Alex that without a hosted solution RIPE NCC wouldn't have so many ROAs today, for us, even with it, it has been more difficult to roll out RPKI among our ISPs. As many, I do not think that a hosted suits to everybody and it has some disadvantages but at leas it could help to lower the entry barrier for some. >> >> >> ? ? ? Speaking about RPKI stats, here some ROA evolution in various TAs (the data from ARIN is from their beta test, the rest are production systems): >> >> http://www.labs.lacnic.net/~rpki/rpki-evolution-report_EN.txt >> >> ? ? ? And visually: >> >> http://www.labs.lacnic.net/~rpki/rpki-heatmaps/latest/global-roa-heatmap.png >> >> ? ? ? and >> >> http://www.labs.lacnic.net/~rpki/rpki-heatmaps/latest/ >> >> ? ? ? To see each region. >> >> http://www.labs.lacnic.net/~rpki/rpki-heatmaps >> >> ? ? ? Also, bgpmon has a nice whois interface for humans to see ROAs (not sure if this link was share here or in twitter, sorry if I am duplicating): >> >> http://bgpmon.net/blog/?p=414 >> >> >> Best regards, >> -as >> >> >> >> On 29 Jan 2011, at 13:26, Alex Band wrote: >> >>> John, >>> >>> Thanks for the update. With regards to offering a hosted solution, as you know that is the only thing the RIPE NCC currently offers. We're developing support for the up/down protocol as I write this. >>> >>> To give you some perspective, one month after launching the hosted RIPE NCC Resource Certification service, 216 LIRs are using it in the RIPE Region and created 169 ROAs covering 467 prefixes. This means 40151 /24 IPv4 prefixes and 7274499 /48 IPv6 prefixes now have a valid ROA associated with them. >>> >>> I realize a hosted solution is not ideal, we're very open about that. But at least in our region, it seems there are quite a number of organizations who understand and accept the security trade-off of not being the owner of the private key for their resource certificate and trust their RIR to run a properly secured and audited service. So the question is, if the RIPE NCC would have required everyone to run their own certification setup using the open source tool-sets Randy mentions, would there be this much certified address space now? >>> >>> Looking at the depletion of IPv4 address space, it's going to be crucially important to have validatable proof who is the legitimate holder of Internet resources. I fear that by not offering a hosted certification solution, real world adoption rates will rival those of IPv6 and DNSSEC. Can the Internet community afford that? >>> >>> Alex Band >>> Product Manager, RIPE NCC >>> >>> P.S. For those interested in which prefixes and ASs are in the RIPE NCC ROA Repository, here is the latest output in CSV format: >>> http://lunimon.com/valid-roas-20110129.csv >>> >>> >>> >>> On 24 Jan 2011, at 21:33, John Curran wrote: >>> >>>> Copy to NANOG for those who aren't on ARIN lists but may be interested in this info. >>>> FYI. >>>> /John >>>> >>>> Begin forwarded message: >>>> >>>> From: John Curran <jcurran at arin.net<mailto:jcurran at arin.net>> >>>> Date: January 24, 2011 2:58:52 PM EST >>>> To: "arin-announce at arin.net<mailto:arin-announce at arin.net>" <arin-announce at arin.net<mailto:arin-announce at arin.net>> >>>> Subject: [arin-announce] ARIN Resource Certification Update >>>> >>>> ARIN continues its preparations for offering production-grade resource certification >>>> services for Internet number resources in the region. ?ARIN recognizes the importance >>>> of Internet number resource certification in the region as a key element of further >>>> securing Internet routing, and plans to rollout Resource Public Key Infrastructure (RPKI) >>>> at the end of the second quarter of 2011 with support for the Up/Down protocol for those >>>> ISPs who wish to certify their subdelegations via their own RPKI infrastructure. >>>> >>>> ARIN continues to evaluate offering a Hosting Resource Certification service for this >>>> purpose (as an alternative to organizations having to run their own RPKI infrastructure), >>>> but at this time it remains under active consideration and is not committed. ? We look >>>> forward to discussing the need for this type of service and the organization implications >>>> atour upcoming ARIN Members Meeting in April in San Juan, PR. >>>> >>>> FYI, >>>> /John >>>> >>>> John Curran >>>> President and CEO >>>> ARIN >>>> >>>> _______________________________________________ >>>> ARIN-Announce >>>> You are receiving this message because you are subscribed to >>>> the ARIN Announce Mailing List (ARIN-announce at arin.net<mailto: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. >>>> >>>> >>> > > > -- -- ========================= Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net ========================= From jcdill.lists at gmail.com Sun Jan 30 08:23:11 2011 From: jcdill.lists at gmail.com (JC Dill) Date: Sun, 30 Jan 2011 06:23:11 -0800 Subject: help needed - state of california needs a benchmark In-Reply-To: <4D446C28.70907@gmail.com> References: <4D4455C4.6080305@tiedyenetworks.com> <4D446C28.70907@gmail.com> Message-ID: <4D45744F.1060808@gmail.com> On 29/01/11 11:36 AM, Roy wrote: > On 1/29/2011 10:00 AM, Mike wrote: >> >> The rub is, that they want to legislate that web based >> 'speedtest.com' is the ONLY and MOST AUTHORITATIVE metric that trumps >> all other considerations > > You took the state's money so you are stuck with their dumb rules. As I read the OP's post, it's not a rule *YET* (they want to legislate...) and he's asking for help to convince them to adopt a better rule, which seems like a perfectly reasonable objective. jc From owen at delong.com Sun Jan 30 09:00:00 2011 From: owen at delong.com (Owen DeLong) Date: Sun, 30 Jan 2011 07:00:00 -0800 Subject: [arin-announce] ARIN Resource Certification Update In-Reply-To: <AANLkTi=eZHzxruo4NzZKYB6VU-oi+XVG=Tz1Sg-fndHn@mail.gmail.com> References: <EE59203D-907A-4AA2-BAE6-AEE7AADAC0A2@arin.net> <0BC31466-09EA-4734-96B2-152453A62B90@arin.net> <FDFF6713-AB2E-4447-A58B-52CD36A6113A@ripe.net> <23824.1296338405@nsa.vix.com> <43932B92-602B-4903-B2D0-F0D160821918@ripe.net> <AANLkTi=eZHzxruo4NzZKYB6VU-oi+XVG=Tz1Sg-fndHn@mail.gmail.com> Message-ID: <3A307F56-485B-4359-BEFD-38B68BD7ED05@delong.com> On Jan 30, 2011, at 5:57 AM, Carlos Martinez-Cagnazzo wrote: > What I just don?t get if, we as a society, have created institutions > we trust with our *money* (AKA banks), why there can?t be institutions > we trust with our crypto keys. I know that banks sometimes fail, and > yes, probably "crypto banks" will sometimes fail as well, but on the > whole, the failure rate of trusted institutions can be quite low, > acceptably low. > Banks are not an all or nothing proposition. Only a fool trusts a single bank with all of his money. On the other hand, your private key, short of a complicated key escrow environment like the one employed by ICANN for the root key for DNSSEC is an all-or-nothing proposition. EIther you completely trust the other organization, or you don't. Further, when we trust banks with our money, we trust them to hold it, but, we have separate verifiable documentation of how much they are holding for us and they are accountable to return the money to us upon demand. In the case of a private key, it's not money you hand over, it is your very identity in the digital universe. It would be akin to handing your passport to your banker and giving him the ability to replace your picture with his own and then use that passport in whatever manner he sees fit. > IMO the whole thing seems to boil down to the complex interaction of > psychological, emotional and other aspects of how we perceive a > certain situation. And it clearly depends on the region, just look at > RIPE?s column and how it grows relentlessly (i included only a few > lines, full stats can be found in the URL posted by Arturo in an > earlier post) > Yes, it is cultural and regional. Yes, it is partially a matter of psychology. > R2a. IPv4 Space Covered by ROAs (in units of /24s) > ---- > > date | lacnic| apnic| afrinic| arin| ripe| > 2011-01-11 | 17| 189| 1| 0| 28902| > 2011-01-12 | 17| 189| 1| 1867.03| 32439| > 2011-01-13 | 17| None| 1| 1867.03| 32810| > 2011-01-14 | 17| 181| 1| 1867.03| 32819| > 2011-01-15 | 17| 181| 1| 1867.03| 32875| > 2011-01-16 | 17| 181| 1| 1867.03| 32875| > 2011-01-17 | 17| 181| 1| 20| 32903| > 2011-01-18 | 17| 181| 2| None| 33783| > 2011-01-19 | 17| 177| 2| None| 35271| > > Hats off to RIPE People! > We'll see. I have no doubt that if ARIN implemented RPKI the way RIPE has, we'd see similar numbers. However, that doesn't tell the whole story and there are differences in the legal framework under which RIPE operates vs. ARIN that also present unique challenges for ARIN doing things that way. I'm not convinced that what RIPE is doing is completely in the community interest. I think holding that many organization's private keys in trust in a single central repository is somewhat irresponsible and short sighted. Yes, it creates a near-term benefit and accelerates deployment of RPKI. However, it also has risks which don't show up in your table. Owen From leen at consolejunkie.net Sun Jan 30 09:09:02 2011 From: leen at consolejunkie.net (Leen Besselink) Date: Sun, 30 Jan 2011 16:09:02 +0100 Subject: [arin-announce] ARIN Resource Certification Update In-Reply-To: <AANLkTi=eZHzxruo4NzZKYB6VU-oi+XVG=Tz1Sg-fndHn@mail.gmail.com> References: <EE59203D-907A-4AA2-BAE6-AEE7AADAC0A2@arin.net> <0BC31466-09EA-4734-96B2-152453A62B90@arin.net> <FDFF6713-AB2E-4447-A58B-52CD36A6113A@ripe.net> <23824.1296338405@nsa.vix.com> <43932B92-602B-4903-B2D0-F0D160821918@ripe.net> <AANLkTi=eZHzxruo4NzZKYB6VU-oi+XVG=Tz1Sg-fndHn@mail.gmail.com> Message-ID: <4D457F0E.7070805@consolejunkie.net> Hello Carlos, On 01/30/2011 02:57 PM, Carlos Martinez-Cagnazzo wrote: > What I just don?t get if, we as a society, have created institutions > we trust with our *money* (AKA banks), why there can?t be institutions > we trust with our crypto keys. I know that banks sometimes fail, and > yes, probably "crypto banks" will sometimes fail as well, but on the > whole, the failure rate of trusted institutions can be quite low, > acceptably low. > Well, we tried to trust the Certificate Authorities for SSL/TLS but that has failed too. And they don't even hold private keys. Your browser now indirectly trusts 1000+ (sub) certificate authorities. Do I actually trust them all ? No, I don't but they could all sign a certificate for paypal.com* which my browser would trust just fine. A simple example is CNNIC which is a Chinese government agency, the people in China don't trust them, so why should I ? Should the browser really trust a German university to sign paypal.com* ? How about an agency in the United Emirates ? How about my own government ? Or Time Warner/AOL or Ford Motor company or Google ? And so on. https://www.eff.org/files/colour_map_of_CAs.pdf https://www.eff.org/observatory http://www.youtube.com/watch?v=VUKCDm04AqI http://events.ccc.de/congress/2010/Fahrplan/events/4121.en.html http://events.ccc.de/congress/2010/Fahrplan/attachments/1777_is-the-SSLiverse-a-safe-place.pdf At this point, I would really like to see someone implement a DNS-recursive nameserver which can be configured to only trust the root to DNSSEC-sign the root zone and nothing else. And allow the owners/operators/whatever of .com only allow to sign .com. Nothing more. But that isn't really what DNSSEC was designed to do. I am however glad people are working on adding DNSSEC to the browser and some hash in DNS which tells the browser which certificate or CA's are trusted for a domain. Even though it seems to be going slow, because there are many reasons why DNSSEC won't be deployed to users any time soon. * Yes, I know Paypal.com uses an EV-certificate (green bar) and there are a lot less CA's for that, but it is just an example of a website. How about the Chinese government reading what you do on gmail while you are in China ? That is just an example of something that does not use an EV-cert. I'm not satisfied with the banks in my country either. It seems in both cases to be a race to the bottom. Cuttings costs any place they can, like reducing staff. Making it harder and harder to use cash. The CA's seem to be a race to the bottom too. They are not spending money trying to improve their systems, even though the environment around them is changing. Just trying to make money from their existing business. Because it already is a race to the bottom, might as well offer free certificates so everyone can use them to secure any site. One CA already does this: https://www.startssl.com/ They atleast to me seem to be very proactive. The problem with banks is, I've not found a good alternative yet. Fully support StartSSL and RIPE for trying to lower the bar for more security. Have a nice weekend, Leen. From owen at delong.com Sun Jan 30 09:03:55 2011 From: owen at delong.com (Owen DeLong) Date: Sun, 30 Jan 2011 07:03:55 -0800 Subject: [arin-announce] ARIN Resource Certification Update In-Reply-To: <AANLkTin_5UrsUMDDhup8YJrBQXawqF7k_-yq8Zf7h3cY@mail.gmail.com> References: <EE59203D-907A-4AA2-BAE6-AEE7AADAC0A2@arin.net> <0BC31466-09EA-4734-96B2-152453A62B90@arin.net> <FDFF6713-AB2E-4447-A58B-52CD36A6113A@ripe.net> <F4820171-5F43-480C-B0BA-2BB9D473C75D@lacnic.net> <60020FA8-364E-4F19-951A-95D971FDDD76@delong.com> <AANLkTin_5UrsUMDDhup8YJrBQXawqF7k_-yq8Zf7h3cY@mail.gmail.com> Message-ID: <08F0D3DD-D527-4A55-96AB-B414EE49342F@delong.com> On Jan 30, 2011, at 6:11 AM, Carlos Martinez-Cagnazzo wrote: > Do you really think that a set of keys stored in a random PC in a > random office is safer than on a periodically backed-up, encrypted > database? In this future I only see lost keys, keys appearing listed > in something.ru domains, tons of support calls to hostmasters, and > ROAs repeatedly becoming invalid, all things that will seriously harm > RPKI adoption. > I think that organizational key security needs to be the responsibility of the organization. I rarely use Valet parking because I don't like having my car keys left on a peg board full of easy-to-steal car keys along with many other attractive theft targets. I think that centralizing a bunch of RPKI keys on a single server makes a very attractive target. > In the end, I see two things: > > - Hosted solutions aren?t supposed to fit everyone, that?s why > top-down is being developed. This is not news. > Yep. > - Hosted solutions offer a low barrier entry to smaller organizations > who simply cannot develop their own PKI infrastructure. This is the > case where they also lack the organizational skills to properly manage > the keys themselves, so, in most cases at least, they are *better off* > with a hosted solution > They also offer an attractive target for miscreants with a huge payoff if they are ever compromised. > For RPKI to succeed we have to succeed not only on the technical side > but on the *human* side of things. Adoption of RPKI will only move > forward if network admins have *confidence* in the stability, > dependability and overall quality of the whole system. ROAs repeatedly > becoming invalid for the wrong reasons will represent a death blow to > RPKI adoption. > Succeeding on the human side includes doing things in a way that makes people comfortable with the solution. The internet has succeeded largely because we have avoided putting all of our eggs (or even major subsets of our eggs) in single baskets. Hosted RPKI private keys are an example of putting an awful lot of very important eggs into a very small basket. > For RIPE, their hosted solution is clearly meeting expectations within > their region. Other region?s mileage may vary. I hope we (LACNIC) can > do just as well. > We'll see how people feel after the first time it gets pwn3d. > Have a great day! > > Carlos > You too. Owen > On Sat, Jan 29, 2011 at 11:52 PM, Owen DeLong <owen at delong.com> wrote: >> I don't understand why you can't have a hosted solution where the private keys >> are not held by the host. >> >> Seems to me you should be able to use a Java Applet to do the private key >> generation and store the private key on the end-user's machine, passing >> objects that need to be signed by the end user down to the applet for >> signing. >> >> This could be just as low-entry for the user, but, without the host holding >> the private keys. >> >> What am I missing? >> >> Owen >> >> On Jan 29, 2011, at 1:06 PM, Arturo Servin wrote: >> >>> >>> I agree with Alex that without a hosted solution RIPE NCC wouldn't have so many ROAs today, for us, even with it, it has been more difficult to roll out RPKI among our ISPs. As many, I do not think that a hosted suits to everybody and it has some disadvantages but at leas it could help to lower the entry barrier for some. >>> >>> >>> Speaking about RPKI stats, here some ROA evolution in various TAs (the data from ARIN is from their beta test, the rest are production systems): >>> >>> http://www.labs.lacnic.net/~rpki/rpki-evolution-report_EN.txt >>> >>> And visually: >>> >>> http://www.labs.lacnic.net/~rpki/rpki-heatmaps/latest/global-roa-heatmap.png >>> >>> and >>> >>> http://www.labs.lacnic.net/~rpki/rpki-heatmaps/latest/ >>> >>> To see each region. >>> >>> http://www.labs.lacnic.net/~rpki/rpki-heatmaps >>> >>> Also, bgpmon has a nice whois interface for humans to see ROAs (not sure if this link was share here or in twitter, sorry if I am duplicating): >>> >>> http://bgpmon.net/blog/?p=414 >>> >>> >>> Best regards, >>> -as >>> >>> >>> >>> On 29 Jan 2011, at 13:26, Alex Band wrote: >>> >>>> John, >>>> >>>> Thanks for the update. With regards to offering a hosted solution, as you know that is the only thing the RIPE NCC currently offers. We're developing support for the up/down protocol as I write this. >>>> >>>> To give you some perspective, one month after launching the hosted RIPE NCC Resource Certification service, 216 LIRs are using it in the RIPE Region and created 169 ROAs covering 467 prefixes. This means 40151 /24 IPv4 prefixes and 7274499 /48 IPv6 prefixes now have a valid ROA associated with them. >>>> >>>> I realize a hosted solution is not ideal, we're very open about that. But at least in our region, it seems there are quite a number of organizations who understand and accept the security trade-off of not being the owner of the private key for their resource certificate and trust their RIR to run a properly secured and audited service. So the question is, if the RIPE NCC would have required everyone to run their own certification setup using the open source tool-sets Randy mentions, would there be this much certified address space now? >>>> >>>> Looking at the depletion of IPv4 address space, it's going to be crucially important to have validatable proof who is the legitimate holder of Internet resources. I fear that by not offering a hosted certification solution, real world adoption rates will rival those of IPv6 and DNSSEC. Can the Internet community afford that? >>>> >>>> Alex Band >>>> Product Manager, RIPE NCC >>>> >>>> P.S. For those interested in which prefixes and ASs are in the RIPE NCC ROA Repository, here is the latest output in CSV format: >>>> http://lunimon.com/valid-roas-20110129.csv >>>> >>>> >>>> >>>> On 24 Jan 2011, at 21:33, John Curran wrote: >>>> >>>>> Copy to NANOG for those who aren't on ARIN lists but may be interested in this info. >>>>> FYI. >>>>> /John >>>>> >>>>> Begin forwarded message: >>>>> >>>>> From: John Curran <jcurran at arin.net<mailto:jcurran at arin.net>> >>>>> Date: January 24, 2011 2:58:52 PM EST >>>>> To: "arin-announce at arin.net<mailto:arin-announce at arin.net>" <arin-announce at arin.net<mailto:arin-announce at arin.net>> >>>>> Subject: [arin-announce] ARIN Resource Certification Update >>>>> >>>>> ARIN continues its preparations for offering production-grade resource certification >>>>> services for Internet number resources in the region. ARIN recognizes the importance >>>>> of Internet number resource certification in the region as a key element of further >>>>> securing Internet routing, and plans to rollout Resource Public Key Infrastructure (RPKI) >>>>> at the end of the second quarter of 2011 with support for the Up/Down protocol for those >>>>> ISPs who wish to certify their subdelegations via their own RPKI infrastructure. >>>>> >>>>> ARIN continues to evaluate offering a Hosting Resource Certification service for this >>>>> purpose (as an alternative to organizations having to run their own RPKI infrastructure), >>>>> but at this time it remains under active consideration and is not committed. We look >>>>> forward to discussing the need for this type of service and the organization implications >>>>> atour upcoming ARIN Members Meeting in April in San Juan, PR. >>>>> >>>>> FYI, >>>>> /John >>>>> >>>>> John Curran >>>>> President and CEO >>>>> ARIN >>>>> >>>>> _______________________________________________ >>>>> ARIN-Announce >>>>> You are receiving this message because you are subscribed to >>>>> the ARIN Announce Mailing List (ARIN-announce at arin.net<mailto: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. >>>>> >>>>> >>>> >> >> >> > > > > -- > -- > ========================= > Carlos M. Martinez-Cagnazzo > http://www.labs.lacnic.net > ========================= From Valdis.Kletnieks at vt.edu Sun Jan 30 09:35:51 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 30 Jan 2011 10:35:51 -0500 Subject: [arin-announce] ARIN Resource Certification Update In-Reply-To: Your message of "Sun, 30 Jan 2011 11:57:57 -0200." <AANLkTi=eZHzxruo4NzZKYB6VU-oi+XVG=Tz1Sg-fndHn@mail.gmail.com> References: <EE59203D-907A-4AA2-BAE6-AEE7AADAC0A2@arin.net> <0BC31466-09EA-4734-96B2-152453A62B90@arin.net> <FDFF6713-AB2E-4447-A58B-52CD36A6113A@ripe.net> <23824.1296338405@nsa.vix.com> <43932B92-602B-4903-B2D0-F0D160821918@ripe.net> <AANLkTi=eZHzxruo4NzZKYB6VU-oi+XVG=Tz1Sg-fndHn@mail.gmail.com> Message-ID: <251912.1296401751@localhost> On Sun, 30 Jan 2011 11:57:57 -0200, Carlos Martinez-Cagnazzo said: > What I just don't get if, we as a society, have created institutions > we trust with our *money* (AKA banks), why there can't be institutions > we trust with our crypto keys. I know that banks sometimes fail, and > yes, probably "crypto banks" will sometimes fail as well, but on the > whole, the failure rate of trusted institutions can be quite low, > acceptably low. There's a big difference. If a bank screws up and loses $5,000 of my money, I can (at least potentially) sue them and recover $5,000 which is pretty much identical to the $5,000 I lost. If a key escrow company loses my private key, getting back an identical private key is exactly the *wrong* solution. Crypto keys are not interchangable like dollar bills. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110130/dbf670f2/attachment.bin> From randy at psg.com Sun Jan 30 09:51:30 2011 From: randy at psg.com (Randy Bush) Date: Mon, 31 Jan 2011 00:51:30 +0900 Subject: [arin-announce] ARIN Resource Certification Update In-Reply-To: <43932B92-602B-4903-B2D0-F0D160821918@ripe.net> References: <EE59203D-907A-4AA2-BAE6-AEE7AADAC0A2@arin.net> <0BC31466-09EA-4734-96B2-152453A62B90@arin.net> <FDFF6713-AB2E-4447-A58B-52CD36A6113A@ripe.net> <23824.1296338405@nsa.vix.com> <43932B92-602B-4903-B2D0-F0D160821918@ripe.net> Message-ID: <m239oa9ypp.wl%randy@psg.com> hi alex, just to be clear i think your web-based system is a good thing. 97.3% of your members do not want to go through the effort of installing certifying software and doing up/down with you. i am not fond of you holding folk's private keys, but that's what they get for laziness. of course you might think about john's concerns of liability, but you have less lawyers than he does, so wtf. but, as i have said, the lack of the up/down protocol is pretty serious. that remaining 2.7% of your members have 90% of the address space, they are the big providers, and they will not be happy with using your web interface no matter how posh. bottom line: i like your moving ahead. i just wish you were moving more quickly. randy From carlos at lacnic.net Sun Jan 30 10:10:11 2011 From: carlos at lacnic.net (Carlos Martinez-Cagnazzo) Date: Sun, 30 Jan 2011 14:10:11 -0200 Subject: [arin-announce] ARIN Resource Certification Update In-Reply-To: <251912.1296401751@localhost> References: <EE59203D-907A-4AA2-BAE6-AEE7AADAC0A2@arin.net> <0BC31466-09EA-4734-96B2-152453A62B90@arin.net> <FDFF6713-AB2E-4447-A58B-52CD36A6113A@ripe.net> <23824.1296338405@nsa.vix.com> <43932B92-602B-4903-B2D0-F0D160821918@ripe.net> <AANLkTi=eZHzxruo4NzZKYB6VU-oi+XVG=Tz1Sg-fndHn@mail.gmail.com> <251912.1296401751@localhost> Message-ID: <AANLkTi=z==e9yNkhwjSei2f93d43d2NT9cDcnC+wHJVq@mail.gmail.com> > >There's a big difference. If a bank screws up and loses $5,000 of my money, I > > can (at least potentially) sue them and recover $5,000 which is pretty much > > identical to the $5,000 I lost. If a key escrow company loses my private key, > > getting back an identical private key is exactly the *wrong* solution. > > > > Crypto keys are not interchangable like dollar bills. I never suggested that they were. I tried to point out a set of institutions on which we place similar, if not higher, levels of trust to those required to store a crypto key. If your crypto bank loses your key, you can always revoke and resign. And you'll be back on the air much faster than you can recover $5k from a failed bank. And please do not get me out of context, I never said the hosted solution was perfect, nor that the analogy applicable to every aspect. And I am not trying to extend the success of RIPE's hosted solution to "everybody's digital identity". It is a vertical solution that is doing well (and will hopefully continue to do so) on a vertical application. For sure, it is probably not an example you can extend to other applications. Going back to money, I would *never* trust a hosted solution to hold a key I use to access my online banking. This would clearly be a case where a hosted solution is not applicable. regards Carlos -- Carlos M. Martinez LACNIC I+D PGP KeyID 0xD51507A2 Phone: +598-2604-2222 ext. 4419 Carlos Martinez Cagnazzo <carlos at lacnic.net> From jcurran at arin.net Sun Jan 30 10:13:28 2011 From: jcurran at arin.net (John Curran) Date: Sun, 30 Jan 2011 16:13:28 +0000 Subject: ARIN IRR Authentication (was: Re: AltDB?) In-Reply-To: <AANLkTimdaEOJ1LmFNc+fR6vHm83R=NmbQH8-=_+Jyd3B@mail.gmail.com> References: <59051.1294464800@nsa.vix.com> <00041A16-473F-4F96-93E8-E3CD3F83E1B2@virtualized.org> <70374.1294475040@nsa.vix.com> <m2aajb4vb7.wl%randy@psg.com> <m28vyv4uv0.wl%randy@psg.com> <5336.1294506839@nsa.vix.com> <Pine.LNX.4.61.1101081243291.5148@soloth.lewis.org> <AANLkTi=TDwNgT5WCx-sQ8NgAZ=NZWQDEWzd6+3CEW4st@mail.gmail.com> <AANLkTikCaadeah6Gub1EG43E0j_4N14Yipm+bjsyNzkw@mail.gmail.com> <m2fwt23glz.wl%randy@psg.com> <AANLkTim+_RqZLLG8BWQOnqgJ_EYDDz6tmKROq=ZGOqF=@mail.gmail.com> <1AAAEF13-B1AC-41CA-8B16-9985FD9E0EB2@arin.net> <4D2BAAE3.8080009@dougbarton.us> <BE650600-AD67-4A51-8FDF-ED3F368A6F06@arin.net> <4D2BFC80.2040305@dougbarton.us> <C6D38F6D-74D0-4E41-8A25-DE1816C860C4@arin.net> <EB7C0B14-A399-4572-85C9-8557F2C1BD2D@corp.arin.net> <AANLkTimdaEOJ1LmFNc+fR6vHm83R=NmbQH8-=_+Jyd3B@mail.gmail.com> Message-ID: <37BC37E7-5464-484E-A1A0-C2DA47FD6EBD@arin.net> On Jan 29, 2011, at 10:50 PM, Jeff Wheeler wrote: > On Thu, Jan 27, 2011 at 10:00 PM, John Curran <jcurran at arin.net> wrote: >> Based on the ARIN's IRR authentication thread a couple of weeks ago, there >> were suggestions placed into ARIN's ACSP process for changes to ARIN's IRR >> system. ARIN has looked at the integration issues involved and has scheduled >> an upgrade to the IRR system that will accept PGP and CRYPT-PW authentication >> as well as implementing notification support for both the mnt-nfy and notify >> fields by the end of August 2011. > > I'm glad to see that a decision was made to improve the ARIN IRR, > rather than stick to status-quo or abandon it. Good to hear. > However, this response > is essentially what most folks I spoke with off-list imagined: You > have an immediate operational security problem which could cause > service impact to ARIN members and others relying on the ARIN IRR > database, and fixing it by allowing passwords or PGP to be used is not > very hard. I appreciate your estimate of the effort required to address this problem, but we're not doing this as a completely separate system but with the intention of having some level of integration with our existing ARIN Online system in the future. While this may take more effort, and was not in our original 2011 budget, we have been able to add it to plan with development to begin later in the year. > As I have stated on this list, I believe ARIN is not organizationally > capable of handling operational issues. You've asserted this belief in prior messages (as well as noting that "No one is forced to use ARIN IRR") If the IRR does not meet your needs during this period, I would recommend using one of the many alternative routing registries available. In any case, I'd like to thank you again for raising the concern about lack of IRR authentication, as it was instrumental in bringing this matter to resolution. Thanks! /John John Curran President and CEO ARIN From jyy_99 at yahoo.com Sun Jan 30 10:18:31 2011 From: jyy_99 at yahoo.com (Jessica Yu) Date: Sun, 30 Jan 2011 08:18:31 -0800 (PST) Subject: hi) Message-ID: <801154.85589.qm@web121803.mail.ne1.yahoo.com> Look good shop http://neumaticosabc.com/sales.html From carlos at lacnic.net Sun Jan 30 10:25:53 2011 From: carlos at lacnic.net (Carlos Martinez-Cagnazzo) Date: Sun, 30 Jan 2011 14:25:53 -0200 Subject: [arin-announce] ARIN Resource Certification Update In-Reply-To: <AANLkTi=z==e9yNkhwjSei2f93d43d2NT9cDcnC+wHJVq@mail.gmail.com> References: <EE59203D-907A-4AA2-BAE6-AEE7AADAC0A2@arin.net> <0BC31466-09EA-4734-96B2-152453A62B90@arin.net> <FDFF6713-AB2E-4447-A58B-52CD36A6113A@ripe.net> <23824.1296338405@nsa.vix.com> <43932B92-602B-4903-B2D0-F0D160821918@ripe.net> <AANLkTi=eZHzxruo4NzZKYB6VU-oi+XVG=Tz1Sg-fndHn@mail.gmail.com> <251912.1296401751@localhost> <AANLkTi=z==e9yNkhwjSei2f93d43d2NT9cDcnC+wHJVq@mail.gmail.com> Message-ID: <AANLkTinUzEsCXO0gyG=Xaf3FRx-5__fhs_seYxSpuRhm@mail.gmail.com> I see also that many concerns expressed here are extensions of the perceived failures of the whole CA business. I agree that the whole model of CAs has largely failed. Not only there are too many of them, but the fact that they try to operate as for-profits makes them vulnerable to all the pressures that come with the need to sell and generate revenue. The spectacular failures they have suffered in the past (certificates with Microsoft's name on them, I guess everyone remembers) have certainly not helped. Basically the only thing you now get from using SSL certs is end-to-end encryption, and for that, a self-signed certificate does just as well as a thousand dollar one from your preferred friendly CA. However, as I said on an earlier post, I still believe that the hosted solution for RPKI is a good one at this point in time for a certain group of users of a certain application. It is *very* vertical, or niche if you want. We should not try to extend it to other applications or other groups of users. Randy sums up my whole feelings on the issue. I also think we need top-down soon, and I wouldn't mind in the future seeing a nice Paretto distribution where 80% of members use the hosted solution, but account for 20% of routed space, where 20% customers use top-down accounting for 80% of routed space. Perfection is the enemy of good. Before hosted RPKI the only way of checking origin-as information was to use one of the public routing registries. A routing registry which is fed from RPKI data is a lot more trustworthy than plain email auth IRRs are. Is it pefect? Of course not. Can it be improved? Of course it can. cheers! Carlos From sthaug at nethelp.no Sun Jan 30 10:28:04 2011 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Sun, 30 Jan 2011 17:28:04 +0100 (CET) Subject: [arin-announce] ARIN Resource Certification Update In-Reply-To: <08F0D3DD-D527-4A55-96AB-B414EE49342F@delong.com> References: <60020FA8-364E-4F19-951A-95D971FDDD76@delong.com> <AANLkTin_5UrsUMDDhup8YJrBQXawqF7k_-yq8Zf7h3cY@mail.gmail.com> <08F0D3DD-D527-4A55-96AB-B414EE49342F@delong.com> Message-ID: <20110130.172804.74653776.sthaug@nethelp.no> > > - Hosted solutions offer a low barrier entry to smaller organizations > > who simply cannot develop their own PKI infrastructure. This is the > > case where they also lack the organizational skills to properly manage > > the keys themselves, so, in most cases at least, they are *better off* > > with a hosted solution > > > They also offer an attractive target for miscreants with a huge payoff > if they are ever compromised. ... > > For RIPE, their hosted solution is clearly meeting expectations within > > their region. Other region?s mileage may vary. I hope we (LACNIC) can > > do just as well. > > > We'll see how people feel after the first time it gets pwn3d. I am already trusting RIPE with my data - specifically, RIPE publishes route objects for my prefixes, and my transit providers generate their prefix lists based on these route objects. I fail to see how a hosted RPKI solution would make this situation worse. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From leen at consolejunkie.net Sun Jan 30 10:39:45 2011 From: leen at consolejunkie.net (Leen Besselink) Date: Sun, 30 Jan 2011 17:39:45 +0100 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <7E182DF5-9FBC-4C30-BDCD-AE5D88CF2368@delong.com> References: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com> <AANLkTimcZavnJN2gqayS2-piDvOAcw_nrJAREJ0EDTjp@mail.gmail.com> <op.vpt734cxtfhldh@rbeam.xactional.com> <8B0D83FB-38DD-4C4D-9870-5913425BA3A2@delong.com> <op.vpvur91htfhldh@rbeam.xactional.com> <7E182DF5-9FBC-4C30-BDCD-AE5D88CF2368@delong.com> Message-ID: <4D459451.3070207@consolejunkie.net> On 01/25/2011 11:06 PM, Owen DeLong wrote: > > >> "640k ought to be enough for anyone." >> > If IPv4 is like 640k, then, IPv6 is like having 47,223,664,828,696,452,136,959 > terabytes of RAM. I'd argue that while 640k was short sighted, I think it is > unlikely we will see machines with much more than a terabyte of RAM > in the lifetime of IPv6. > I would be very careful with such predictions. How about 2 TB of RAM ?: "...IBM can cram 1 TB of memory into a 4U chassis or 2 TB in an eight-socket box in two 4U chassis..." http://www.theregister.co.uk/2010/04/01/ibm_xeon_7500_servers/page2.html http://www.theregister.co.uk/2010/04/01/ibm_xeon_7500_servers/ I don't know who will use it or how much they will need to pay for it or even when they will be available, but they are talking about it (in this case at the last CEBIT in March). People are building some very big systems for example with lots and lots of virtual machines. From glen.kent at gmail.com Sun Jan 30 11:02:33 2011 From: glen.kent at gmail.com (Glen Kent) Date: Sun, 30 Jan 2011 22:32:33 +0530 Subject: EPC backhaul networks Message-ID: <AANLkTikcODvdkQO2TNXeaTYrrUo7RquNk=YqMx2rZcUu@mail.gmail.com> Hi, I would like to understand why there is a preference for L3 VPNs over L2 VPNs for the EPC backhaul networks? We can use both layer 2 and layer 3 VPNs for communication between the eNodeB and the MME or S-GW, so why is it that most providers prefer L3 over L2. Glen From nick at foobar.org Sun Jan 30 11:15:02 2011 From: nick at foobar.org (Nick Hilliard) Date: Sun, 30 Jan 2011 17:15:02 +0000 Subject: Level 3's IRR Database In-Reply-To: <AANLkTi=ZhLT0HeWkZ1f57vu6sistskj_rgibEzDiBe3Y@mail.gmail.com> References: <E65B3ED7E6FCBA48BC3E2FA899729216018E704D@rouwkoop.ac.za> <AANLkTi=ZhLT0HeWkZ1f57vu6sistskj_rgibEzDiBe3Y@mail.gmail.com> Message-ID: <4D459C96.3080306@foobar.org> On 30/01/2011 09:08, Jeff Wheeler wrote: > This brings me to my point, which is that IRR is very good for > preventing accidents and automating some common tasks. It should be > "secure" to a point, but just because a route: object exists does not > mean that mntner: really has authority over that address space. Depends on which IRR you use. The IRRDBs run by RIPE, APNIC and AfriNIC implement hierarchical object ownership, which means that if you're registering their address space, you can only do so if that address space legitimately belongs to you. This isn't the case on third party IRRDBs like RADB, L3 and AltDB. Nick From laurent at guerby.net Sun Jan 30 11:17:04 2011 From: laurent at guerby.net (Laurent GUERBY) Date: Sun, 30 Jan 2011 18:17:04 +0100 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <4D459451.3070207@consolejunkie.net> References: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com> <AANLkTimcZavnJN2gqayS2-piDvOAcw_nrJAREJ0EDTjp@mail.gmail.com> <op.vpt734cxtfhldh@rbeam.xactional.com> <8B0D83FB-38DD-4C4D-9870-5913425BA3A2@delong.com> <op.vpvur91htfhldh@rbeam.xactional.com> <7E182DF5-9FBC-4C30-BDCD-AE5D88CF2368@delong.com> <4D459451.3070207@consolejunkie.net> Message-ID: <1296407824.11476.226.camel@pc2.unassigned-domain> On Sun, 2011-01-30 at 17:39 +0100, Leen Besselink wrote: > On 01/25/2011 11:06 PM, Owen DeLong wrote: > > If IPv4 is like 640k, then, IPv6 is like having 47,223,664,828,696,452,136,959 > > terabytes of RAM. I'd argue that while 640k was short sighted, I think it is > > unlikely we will see machines with much more than a terabyte of RAM > > in the lifetime of IPv6. > > > I would be very careful with such predictions. How about 2 TB of RAM ?: > > "...IBM can cram 1 TB of memory into a 4U chassis or 2 TB in an > eight-socket box in two 4U chassis..." > > http://www.theregister.co.uk/2010/04/01/ibm_xeon_7500_servers/page2.html > http://www.theregister.co.uk/2010/04/01/ibm_xeon_7500_servers/ > > I don't know who will use it or how much they will need to pay for it or > even when they will be available, > but they are talking about it (in this case at the last CEBIT in March). > > People are building some very big systems for example with lots and lots > of virtual machines. On dell.com you can buy a PowerEdge R910 with 1TB RAM for around $80k. Laurent From carlosm3011 at gmail.com Sun Jan 30 11:39:36 2011 From: carlosm3011 at gmail.com (Carlos Martinez-Cagnazzo) Date: Sun, 30 Jan 2011 15:39:36 -0200 Subject: Level 3's IRR Database In-Reply-To: <E65B3ED7E6FCBA48BC3E2FA899729216018E704D@rouwkoop.ac.za> References: <E65B3ED7E6FCBA48BC3E2FA899729216018E704D@rouwkoop.ac.za> Message-ID: <AANLkTing8yEVoDSxXsa+eTV0xZuv2qkYYA-ahT26hbFx@mail.gmail.com> The solution to this problem (theoretical at least) already exist in the form of RPKI. On Sun, Jan 30, 2011 at 6:23 AM, Andrew Alston <aa at tenet.ac.za> wrote: > Hi All, > > I've just noticed that Level 3 is allowing people to register space in its IRR database that A.) is not assigned to the people registering it and B.) is not assigned via/to Level 3. > > So, I have two queries > > A.) Are only customers of Level 3 allowed to use this database > B.) Can someone from Level 3 please clarify if there are any plans to lock this down slightly > > At this point, it would seem that if you are a customer of level 3's, you can register any space you feel like in there, and announce anything you feel like once the filters propagate, which in my opinion completely nullifies the point of IRR in the first place. > > Though I think this also raises the question about IRR databases in general. ?Would it not be far more sane to have each RIR run a single instance each which talk to each other, which can be verified against IP address assignments, and scrap the distributed IRR systems that allow for issues like this to occur? > > (In the mean time I've emailed the relevant people to try and get the entries falsely registered in that database removed, and will wait and see if I get a response). > > > Andrew Alston > TENET - Chief Technology Officer > Phone: +27 21 763 7181 > > -- -- ========================= Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net ========================= From owen at delong.com Sun Jan 30 11:40:02 2011 From: owen at delong.com (Owen DeLong) Date: Sun, 30 Jan 2011 09:40:02 -0800 Subject: [arin-announce] ARIN Resource Certification Update In-Reply-To: <20110130.172804.74653776.sthaug@nethelp.no> References: <60020FA8-364E-4F19-951A-95D971FDDD76@delong.com> <AANLkTin_5UrsUMDDhup8YJrBQXawqF7k_-yq8Zf7h3cY@mail.gmail.com> <08F0D3DD-D527-4A55-96AB-B414EE49342F@delong.com> <20110130.172804.74653776.sthaug@nethelp.no> Message-ID: <6E874B74-BA89-4D11-87BC-CEC580EEC618@delong.com> On Jan 30, 2011, at 8:28 AM, sthaug at nethelp.no wrote: >>> - Hosted solutions offer a low barrier entry to smaller organizations >>> who simply cannot develop their own PKI infrastructure. This is the >>> case where they also lack the organizational skills to properly manage >>> the keys themselves, so, in most cases at least, they are *better off* >>> with a hosted solution >>> >> They also offer an attractive target for miscreants with a huge payoff >> if they are ever compromised. > ... >>> For RIPE, their hosted solution is clearly meeting expectations within >>> their region. Other region?s mileage may vary. I hope we (LACNIC) can >>> do just as well. >>> >> We'll see how people feel after the first time it gets pwn3d. > > I am already trusting RIPE with my data - specifically, RIPE publishes > route objects for my prefixes, and my transit providers generate their > prefix lists based on these route objects. I fail to see how a hosted > RPKI solution would make this situation worse. > > Steinar Haug, Nethelp consulting, sthaug at nethelp.no Because they publish data you have signed. They don't have the ability to modify the data and then sign that modification as if they were you if they aren't holding the private key. If they are holding the private key, then, you have, in essence, given them power of attorney to administer your network. If you're OK with that, more power to you. It's not the trust model I would prefer. Owen From owen at delong.com Sun Jan 30 11:48:00 2011 From: owen at delong.com (Owen DeLong) Date: Sun, 30 Jan 2011 09:48:00 -0800 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <4D459451.3070207@consolejunkie.net> References: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com> <AANLkTimcZavnJN2gqayS2-piDvOAcw_nrJAREJ0EDTjp@mail.gmail.com> <op.vpt734cxtfhldh@rbeam.xactional.com> <8B0D83FB-38DD-4C4D-9870-5913425BA3A2@delong.com> <op.vpvur91htfhldh@rbeam.xactional.com> <7E182DF5-9FBC-4C30-BDCD-AE5D88CF2368@delong.com> <4D459451.3070207@consolejunkie.net> Message-ID: <AC70689B-43B1-4D30-8177-FC46416F4BF1@delong.com> On Jan 30, 2011, at 8:39 AM, Leen Besselink wrote: > On 01/25/2011 11:06 PM, Owen DeLong wrote: >> >> >>> "640k ought to be enough for anyone." >>> >> If IPv4 is like 640k, then, IPv6 is like having 47,223,664,828,696,452,136,959 >> terabytes of RAM. I'd argue that while 640k was short sighted, I think it is >> unlikely we will see machines with much more than a terabyte of RAM >> in the lifetime of IPv6. >> > I would be very careful with such predictions. How about 2 TB of RAM ?: > Yes... I left a word out of my sentence... I think it is unlikely we will see COMMON machines with much more than a terabyte of RAM in the lifetime of IPv6. Sure, there will be the rare monster super-special-purpose thing with more RAM capacity than there is storage in many large disk farms, but, for common general purpose machines, I think it's safe to say that 47,223,664,828,696,452,136,959 terabytes ought to be enough for anyone given that even at the best of Moore's law common desktops will take 9 or more years to get to 1 Terabyte of RAM. > "...IBM can cram 1 TB of memory into a 4U chassis or 2 TB in an > eight-socket box in two 4U chassis..." > > http://www.theregister.co.uk/2010/04/01/ibm_xeon_7500_servers/page2.html > http://www.theregister.co.uk/2010/04/01/ibm_xeon_7500_servers/ > > I don't know who will use it or how much they will need to pay for it or > even when they will be available, > but they are talking about it (in this case at the last CEBIT in March). > > People are building some very big systems for example with lots and lots > of virtual machines. > > Yes... My intent, like the 640k quote, was aimed at the common desktop machine and primarily to show that since 1 TB is an inconceivably large memory footprint for any normal user today, it's going to be a long long time before 47,223,664,828,696,452,136,959 TB comes up short for anyone's needs. Owen From cb.list6 at gmail.com Sun Jan 30 11:52:43 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Sun, 30 Jan 2011 09:52:43 -0800 Subject: EPC backhaul networks In-Reply-To: <AANLkTikcODvdkQO2TNXeaTYrrUo7RquNk=YqMx2rZcUu@mail.gmail.com> References: <AANLkTikcODvdkQO2TNXeaTYrrUo7RquNk=YqMx2rZcUu@mail.gmail.com> Message-ID: <AANLkTingxgFcpXwV2ZLaLRr8ucBZQLF_c8k0weno4N51@mail.gmail.com> On Jan 30, 2011 9:03 AM, "Glen Kent" <glen.kent at gmail.com> wrote: > > Hi, > > I would like to understand why there is a preference for L3 VPNs over > L2 VPNs for the EPC backhaul networks? We can use both layer 2 and > layer 3 VPNs for communication between the eNodeB and the MME or S-GW, > so why is it that most providers prefer L3 over L2. > There are just more companies offering L2 metroE than L3 in the backhaul space. I have pushed for L3 but very few offer the speeds and reach required Cb > Glen > From carlosm3011 at gmail.com Sun Jan 30 11:56:18 2011 From: carlosm3011 at gmail.com (Carlos M. Martinez) Date: Sun, 30 Jan 2011 15:56:18 -0200 Subject: [arin-announce] ARIN Resource Certification Update In-Reply-To: <6E874B74-BA89-4D11-87BC-CEC580EEC618@delong.com> References: <60020FA8-364E-4F19-951A-95D971FDDD76@delong.com> <AANLkTin_5UrsUMDDhup8YJrBQXawqF7k_-yq8Zf7h3cY@mail.gmail.com> <08F0D3DD-D527-4A55-96AB-B414EE49342F@delong.com> <20110130.172804.74653776.sthaug@nethelp.no> <6E874B74-BA89-4D11-87BC-CEC580EEC618@delong.com> Message-ID: <4D45A642.2010908@gmail.com> Hey! >> Steinar Haug, Nethelp consulting, sthaug at nethelp.no > Because they publish data you have signed. They don't have the ability > to modify the data and then sign that modification as if they were you if > they aren't holding the private key. If they are holding the private key, > then, you have, in essence, given them power of attorney to administer > your network. > > If you're OK with that, more power to you. It's not the trust model I would > prefer. > I think that is the whole point. Hosted is fine with some, top-down will be preferred by others. Will top-down be intrinsically more secure than hosted? I am tempted to say yes, but I have some doubts on that too. What top-down certainly does is getting you out of the lawyers' sights. Mostly anyways. > Owen Carlos From Valdis.Kletnieks at vt.edu Sun Jan 30 11:57:30 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 30 Jan 2011 12:57:30 -0500 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: Your message of "Sun, 30 Jan 2011 17:39:45 +0100." <4D459451.3070207@consolejunkie.net> References: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com> <AANLkTimcZavnJN2gqayS2-piDvOAcw_nrJAREJ0EDTjp@mail.gmail.com> <op.vpt734cxtfhldh@rbeam.xactional.com> <8B0D83FB-38DD-4C4D-9870-5913425BA3A2@delong.com> <op.vpvur91htfhldh@rbeam.xactional.com> <7E182DF5-9FBC-4C30-BDCD-AE5D88CF2368@delong.com> <4D459451.3070207@consolejunkie.net> Message-ID: <257317.1296410250@localhost> On Sun, 30 Jan 2011 17:39:45 +0100, Leen Besselink said: > On 01/25/2011 11:06 PM, Owen DeLong wrote: > > > > > >> "640k ought to be enough for anyone." Remember that when this apocryphal statement was allegedly made in 1981, IBM mainframes and Crays and the like were already well in to the 64-256M of RAM area, and it was intended to apply to consumer-class machines (like what you'd run Windows on). > > If IPv4 is like 640k, then, IPv6 is like having 47,223,664,828,696,452,136,959 > > terabytes of RAM. I'd argue that while 640k was short sighted, I think it is > > unlikely we will see machines with much more than a terabyte of RAM > > in the lifetime of IPv6. > > > I would be very careful with such predictions. How about 2 TB of RAM ?: OK. A petabyte of ram instead. Better? Then IPv6 is like having 47,223,664,828,696,452,136 petabytes of RAM. Or go to an exabyte of ram. That's a million times the current highest density and still leaves you a bunch of commas in the number. We seem to be managing at best, at the bleeding edge, one comma per decade. And note that the change in units from kbytes to terabytes itself hides 3 more commas. In any case, the fact you can stick a terabyte of RAM into a 4U Dell rack mount that sucks a whole lot of power doesn't mean we're anywhere near being able to do it for consumer-class hardware. Remember, much of the growth is going to be in the embedded and special purpose systems - the smart phone/PDA/handheld game system arena, etc. How many fully loaded R910's will Dell sell, and how many iPhones will Apple sell? How long before a Blackberry or an iPhone has a terabyte of RAM? (For that matter, when will they get to a terabyte of SSD capacity?) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110130/e0fc818f/attachment.bin> From swmike at swm.pp.se Sun Jan 30 12:09:15 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sun, 30 Jan 2011 19:09:15 +0100 (CET) Subject: EPC backhaul networks In-Reply-To: <AANLkTikcODvdkQO2TNXeaTYrrUo7RquNk=YqMx2rZcUu@mail.gmail.com> References: <AANLkTikcODvdkQO2TNXeaTYrrUo7RquNk=YqMx2rZcUu@mail.gmail.com> Message-ID: <alpine.DEB.1.10.1101301905220.13151@uplift.swm.pp.se> On Sun, 30 Jan 2011, Glen Kent wrote: > I would like to understand why there is a preference for L3 VPNs over L2 > VPNs for the EPC backhaul networks? We can use both layer 2 and layer 3 > VPNs for communication between the eNodeB and the MME or S-GW, so why is > it that most providers prefer L3 over L2. Becuase the lessons learnt in the last 30 years or so of networking is that large L2 domains are considered harmful. If you subnet them down in different vlans, it means for every new vlan you need to configure something on the MME/SGW. It's just easier and safer to break it down into smaller L3 domains that you route between. -- Mikael Abrahamsson email: swmike at swm.pp.se From swmike at swm.pp.se Sun Jan 30 12:11:52 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sun, 30 Jan 2011 19:11:52 +0100 (CET) Subject: EPC backhaul networks In-Reply-To: <AANLkTingxgFcpXwV2ZLaLRr8ucBZQLF_c8k0weno4N51@mail.gmail.com> References: <AANLkTikcODvdkQO2TNXeaTYrrUo7RquNk=YqMx2rZcUu@mail.gmail.com> <AANLkTingxgFcpXwV2ZLaLRr8ucBZQLF_c8k0weno4N51@mail.gmail.com> Message-ID: <alpine.DEB.1.10.1101301909580.13151@uplift.swm.pp.se> On Sun, 30 Jan 2011, Cameron Byrne wrote: > There are just more companies offering L2 metroE than L3 in the backhaul > space. I have pushed for L3 but very few offer the speeds and reach > required Could you please elaborate on what you mean by "reach" here? -- Mikael Abrahamsson email: swmike at swm.pp.se From cb.list6 at gmail.com Sun Jan 30 13:03:39 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Sun, 30 Jan 2011 11:03:39 -0800 Subject: EPC backhaul networks In-Reply-To: <alpine.DEB.1.10.1101301909580.13151@uplift.swm.pp.se> References: <AANLkTikcODvdkQO2TNXeaTYrrUo7RquNk=YqMx2rZcUu@mail.gmail.com> <AANLkTingxgFcpXwV2ZLaLRr8ucBZQLF_c8k0weno4N51@mail.gmail.com> <alpine.DEB.1.10.1101301909580.13151@uplift.swm.pp.se> Message-ID: <AANLkTikTNTe6nCZcwHC-zML8wTgL27UEMQVTLKA4A-A9@mail.gmail.com> On Jan 30, 2011 10:11 AM, "Mikael Abrahamsson" <swmike at swm.pp.se> wrote: > > On Sun, 30 Jan 2011, Cameron Byrne wrote: >/ >> There are just more companies offering L2 metroE than L3 in the backhaul space. I have pushed for L3 but very few offer the speeds and reach required > > > Could you please elaborate on what you mean by "reach" here? > > The only way to reach 2000 cell sites in Chicago with 100megs of Ethernet handoff is with L2 metroE. There is not a feasible L3 service offered today. > -- > Mikael Abrahamsson email: swmike at swm.pp.se From owen at delong.com Sun Jan 30 13:09:38 2011 From: owen at delong.com (Owen DeLong) Date: Sun, 30 Jan 2011 11:09:38 -0800 Subject: EPC backhaul networks In-Reply-To: <alpine.DEB.1.10.1101301905220.13151@uplift.swm.pp.se> References: <AANLkTikcODvdkQO2TNXeaTYrrUo7RquNk=YqMx2rZcUu@mail.gmail.com> <alpine.DEB.1.10.1101301905220.13151@uplift.swm.pp.se> Message-ID: <6CFD14BD-BA15-48CA-8115-91A0A327FF2C@delong.com> On Jan 30, 2011, at 10:09 AM, Mikael Abrahamsson wrote: > On Sun, 30 Jan 2011, Glen Kent wrote: > >> I would like to understand why there is a preference for L3 VPNs over L2 VPNs for the EPC backhaul networks? We can use both layer 2 and layer 3 VPNs for communication between the eNodeB and the MME or S-GW, so why is it that most providers prefer L3 over L2. > > Becuase the lessons learnt in the last 30 years or so of networking is that large L2 domains are considered harmful. If you subnet them down in different vlans, it means for every new vlan you need to configure something on the MME/SGW. > > It's just easier and safer to break it down into smaller L3 domains that you route between. > It's also easier to troubleshoot when something goes boom. Owen From ping at pingpan.org Sun Jan 30 13:17:51 2011 From: ping at pingpan.org (Ping Pan) Date: Sun, 30 Jan 2011 11:17:51 -0800 Subject: EPC backhaul networks In-Reply-To: <AANLkTikTNTe6nCZcwHC-zML8wTgL27UEMQVTLKA4A-A9@mail.gmail.com> References: <AANLkTikcODvdkQO2TNXeaTYrrUo7RquNk=YqMx2rZcUu@mail.gmail.com> <AANLkTingxgFcpXwV2ZLaLRr8ucBZQLF_c8k0weno4N51@mail.gmail.com> <alpine.DEB.1.10.1101301909580.13151@uplift.swm.pp.se> <AANLkTikTNTe6nCZcwHC-zML8wTgL27UEMQVTLKA4A-A9@mail.gmail.com> Message-ID: <AANLkTi=FukGDNDye7giOaqeSMAeZoHEGoR5Fs0Rv045Z@mail.gmail.com> Heard a lot about MPLS-TP to apply in this area. What do you think? Is it for real? Thanks! Ping On Sun, Jan 30, 2011 at 11:03 AM, Cameron Byrne <cb.list6 at gmail.com> wrote: > On Jan 30, 2011 10:11 AM, "Mikael Abrahamsson" <swmike at swm.pp.se> wrote: > > > > On Sun, 30 Jan 2011, Cameron Byrne wrote: > >/ > >> There are just more companies offering L2 metroE than L3 in the backhaul > space. I have pushed for L3 but very few offer the speeds and reach > required > > > > > > Could you please elaborate on what you mean by "reach" here? > > > > > > The only way to reach 2000 cell sites in Chicago with 100megs of Ethernet > handoff is with L2 metroE. There is not a feasible L3 service offered > today. > > > -- > > Mikael Abrahamsson email: swmike at swm.pp.se > From jbates at brightok.net Sun Jan 30 13:20:51 2011 From: jbates at brightok.net (Jack Bates) Date: Sun, 30 Jan 2011 13:20:51 -0600 Subject: Level 3's IRR Database In-Reply-To: <4D459C96.3080306@foobar.org> References: <E65B3ED7E6FCBA48BC3E2FA899729216018E704D@rouwkoop.ac.za> <AANLkTi=ZhLT0HeWkZ1f57vu6sistskj_rgibEzDiBe3Y@mail.gmail.com> <4D459C96.3080306@foobar.org> Message-ID: <4D45BA13.6030705@brightok.net> On 1/30/2011 11:15 AM, Nick Hilliard wrote: > > Depends on which IRR you use. The IRRDBs run by RIPE, APNIC and > AfriNIC implement hierarchical object ownership, which means that if > you're registering their address space, you can only do so if that > address space legitimately belongs to you. This isn't the case on > third party IRRDBs like RADB, L3 and AltDB. Which is nice. I just duplicated an ARIN entry in raddb using my maintainer with all other information the same. Since Level 3 pulls based on my as-set + my maintainer list, my entry automatically updates their acl list. Does this mean I can't lie? No. However, IRR's aren't designed to top lying. they are designed to help in management and tracking issues. Jack From gbonser at seven.com Sun Jan 30 13:25:26 2011 From: gbonser at seven.com (George Bonser) Date: Sun, 30 Jan 2011 11:25:26 -0800 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <257317.1296410250@localhost> References: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com><AANLkTimcZavnJN2gqayS2-piDvOAcw_nrJAREJ0EDTjp@mail.gmail.com><op.vpt734cxtfhldh@rbeam.xactional.com><8B0D83FB-38DD-4C4D-9870-5913425BA3A2@delong.com><op.vpvur91htfhldh@rbeam.xactional.com><7E182DF5-9FBC-4C30-BDCD-AE5D88CF2368@delong.com><4D459451.3070207@consolejunkie.net> <257317.1296410250@localhost> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC1372C@RWC-EX1.corp.seven.com> > > In any case, the fact you can stick a terabyte of RAM into a 4U Dell > rack mount that sucks a whole lot of power doesn't mean we're anywhere > near being able to do it for consumer-class hardware. Remember, much > of the growth is going to be in the embedded and special purpose > systems - the smart phone/PDA/handheld game system arena, etc. How > many fully loaded R910's will Dell sell, and how many iPhones will > Apple sell? How long before a Blackberry or an iPhone has a terabyte of > RAM? (For that matter, when will they get to a terabyte of SSD > capacity?) > There are other reasons to use a /64. Some vendors have the option of storing either the /64 prefix or the entire /128 in CAM. The option to select one mode or the other is often not specific to a route but is a global option. If you want hardware switching of nets smaller than /64, you need to enable the mode that places the entire address in CAM. Doing that results in an increase in resources required to hold routes resulting in fewer routes in hardware at any given time. So hardware that, by default, places the entire address in CAM is fine, but if you have the option of using only the /64 prefix then an IPv6 route becomes less expensive (only 2x the "cost" of a v4 route in resources rather than 4x the cost). From millnert at gmail.com Sun Jan 30 13:55:10 2011 From: millnert at gmail.com (Martin Millnert) Date: Sun, 30 Jan 2011 14:55:10 -0500 Subject: A top-down RPKI model a threat to human freedom? (was Re: Level 3's IRR Database) Message-ID: <AANLkTin=vLoYD4FZFSUryYZOJOFYhq_62Fk9Dop2pqEy@mail.gmail.com> Here be dragons, On Sun, Jan 30, 2011 at 12:39 PM, Carlos Martinez-Cagnazzo <carlosm3011 at gmail.com> wrote: > The solution to this problem (theoretical at least) already exist in > the form of RPKI. Any top-down RPKI model is intrinsically flawed. Deploying an overlay of single-point(s) of failure on top of a well-functional distributed system such as the Internet does not seem like a solution to much. The Internet works reasonably well only because it is reasonably distributed. I acknowledge that: 1) there are occasionally routing problems, 2) that IPv4 will deteriorate further very rapidly as it runs out and second-hand markets pick up, 3) that spammers run BGP and abuse, seemingly primarily, the non-RIR IRR-dbs. The answer to these issues is not by default RPKI IMO. For example, how about: 1, fix them - are there any problems that hasn't been fixed or were seriously hard to fix? Enumerate and let's go specific; let's not deploy a tank to push in a screw. 2, IPv6? 3, improve/remove non-RIR IRR-dbs It should be fairly obvious, by most recently what's going on in Egypt, why allowing a government to control the Internet is a Really Bad Idea. While it is true that governments are more or less in control of the *geographic area* they govern, as is evident in Egypt, there is a serious and big difference between the ease of removing a prefix from the Internet today in a country and how easy it will be in the fully network-deployed RPKI case, because of the hierarchical model (send your tanks to the RIR office(s) instead of every single country). Yes, governments exploit capabilities given to them by technological means ("we do it just because we can" is a standing motto). A top-down RPKI model would be a severely negative development of the resilience of the Internet, especially for freedom-aspiring people (approximately equal to humankind?), who need to avert government suppression. If we are to go down this path, at the very least it must stay architecturally/technologically *impossible* for a entity from country A to via-the-hierarchical-trust-model block a prefix assigned to some entity in country B, that is assigned by B's RIR and in full accordance with the RIR policies and in no breach of any contract. If not, we're doing humanity a disservice. One that I have no doubt would simply spawn/grow further overlay-networks to counter the problem. Cheers, Martin > > On Sun, Jan 30, 2011 at 6:23 AM, Andrew Alston <aa at tenet.ac.za> wrote: >> Hi All, >> >> I've just noticed that Level 3 is allowing people to register space in its IRR database that A.) is not assigned to the people registering it and B.) is not assigned via/to Level 3. >> >> So, I have two queries >> >> A.) Are only customers of Level 3 allowed to use this database >> B.) Can someone from Level 3 please clarify if there are any plans to lock this down slightly >> >> At this point, it would seem that if you are a customer of level 3's, you can register any space you feel like in there, and announce anything you feel like once the filters propagate, which in my opinion completely nullifies the point of IRR in the first place. >> >> Though I think this also raises the question about IRR databases in general. ?Would it not be far more sane to have each RIR run a single instance each which talk to each other, which can be verified against IP address assignments, and scrap the distributed IRR systems that allow for issues like this to occur? >> >> (In the mean time I've emailed the relevant people to try and get the entries falsely registered in that database removed, and will wait and see if I get a response). >> >> >> Andrew Alston >> TENET - Chief Technology Officer >> Phone: +27 21 763 7181 >> >> > > > > -- > -- > ========================= > Carlos M. Martinez-Cagnazzo > http://www.labs.lacnic.net > ========================= > > From nick at foobar.org Sun Jan 30 14:47:06 2011 From: nick at foobar.org (Nick Hilliard) Date: Sun, 30 Jan 2011 20:47:06 +0000 Subject: Level 3's IRR Database In-Reply-To: <AANLkTing8yEVoDSxXsa+eTV0xZuv2qkYYA-ahT26hbFx@mail.gmail.com> References: <E65B3ED7E6FCBA48BC3E2FA899729216018E704D@rouwkoop.ac.za> <AANLkTing8yEVoDSxXsa+eTV0xZuv2qkYYA-ahT26hbFx@mail.gmail.com> Message-ID: <4D45CE4A.5090800@foobar.org> On 30/01/2011 17:39, Carlos Martinez-Cagnazzo wrote: > The solution to this problem (theoretical at least) already exist in > the form of RPKI. So, what are peoples' routing policies on RPKI going to be? Are people going to drop prefixes with no RPKI record? Or drop prefixes with an incorrect RPKI record? Or drop prefixes with a revoked status? I'm concerned that if we're trying to avoid another Youtube affair, the RPKI policy acceptability criteria will have to be so strict that this may have a serious effect on overall reachability via the internet. Nick From swmike at swm.pp.se Sun Jan 30 14:50:32 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sun, 30 Jan 2011 21:50:32 +0100 (CET) Subject: EPC backhaul networks In-Reply-To: <AANLkTi=FukGDNDye7giOaqeSMAeZoHEGoR5Fs0Rv045Z@mail.gmail.com> References: <AANLkTikcODvdkQO2TNXeaTYrrUo7RquNk=YqMx2rZcUu@mail.gmail.com> <AANLkTingxgFcpXwV2ZLaLRr8ucBZQLF_c8k0weno4N51@mail.gmail.com> <alpine.DEB.1.10.1101301909580.13151@uplift.swm.pp.se> <AANLkTikTNTe6nCZcwHC-zML8wTgL27UEMQVTLKA4A-A9@mail.gmail.com> <AANLkTi=FukGDNDye7giOaqeSMAeZoHEGoR5Fs0Rv045Z@mail.gmail.com> Message-ID: <alpine.DEB.1.10.1101302149360.13151@uplift.swm.pp.se> On Sun, 30 Jan 2011, Ping Pan wrote: > Heard a lot about MPLS-TP to apply in this area. What do you think? Is > it for real? MPLS-TP is great for SDH people, they don't have to learn anything new. It's the new SDH, just packet based instead of TDM. Everything else pretty much stays the same. I'm sure this is very popular in some circles, I'm not a fan though. -- Mikael Abrahamsson email: swmike at swm.pp.se From swmike at swm.pp.se Sun Jan 30 14:52:01 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sun, 30 Jan 2011 21:52:01 +0100 (CET) Subject: EPC backhaul networks In-Reply-To: <AANLkTikTNTe6nCZcwHC-zML8wTgL27UEMQVTLKA4A-A9@mail.gmail.com> References: <AANLkTikcODvdkQO2TNXeaTYrrUo7RquNk=YqMx2rZcUu@mail.gmail.com> <AANLkTingxgFcpXwV2ZLaLRr8ucBZQLF_c8k0weno4N51@mail.gmail.com> <alpine.DEB.1.10.1101301909580.13151@uplift.swm.pp.se> <AANLkTikTNTe6nCZcwHC-zML8wTgL27UEMQVTLKA4A-A9@mail.gmail.com> Message-ID: <alpine.DEB.1.10.1101302150490.13151@uplift.swm.pp.se> On Sun, 30 Jan 2011, Cameron Byrne wrote: > The only way to reach 2000 cell sites in Chicago with 100megs of > Ethernet handoff is with L2 metroE. There is not a feasible L3 service > offered today. Ah. We either rent fiber or put up our own radio links, I guess different problems in different markets. -- Mikael Abrahamsson email: swmike at swm.pp.se From cb.list6 at gmail.com Sun Jan 30 14:55:24 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Sun, 30 Jan 2011 12:55:24 -0800 Subject: EPC backhaul networks In-Reply-To: <alpine.DEB.1.10.1101302150490.13151@uplift.swm.pp.se> References: <AANLkTikcODvdkQO2TNXeaTYrrUo7RquNk=YqMx2rZcUu@mail.gmail.com> <AANLkTingxgFcpXwV2ZLaLRr8ucBZQLF_c8k0weno4N51@mail.gmail.com> <alpine.DEB.1.10.1101301909580.13151@uplift.swm.pp.se> <AANLkTikTNTe6nCZcwHC-zML8wTgL27UEMQVTLKA4A-A9@mail.gmail.com> <alpine.DEB.1.10.1101302150490.13151@uplift.swm.pp.se> Message-ID: <AANLkTi=_W8ybVtetdYaSB=PCpSuDQ2mzv-1BXaZuPAT7@mail.gmail.com> On Sun, Jan 30, 2011 at 12:52 PM, Mikael Abrahamsson <swmike at swm.pp.se> wrote: > On Sun, 30 Jan 2011, Cameron Byrne wrote: > >> The only way to reach 2000 cell sites in Chicago with 100megs of Ethernet >> handoff is with L2 metroE. ?There is not a feasible L3 service offered >> today. > > Ah. > > We either rent fiber or put up our own radio links, I guess different > problems in different markets. > Yep. I hate L2. It is a total nightmare. But, it is literally the only game in town. I blame the MEF for spreading propaganda that MetroEis the best solution for backhaul ... most people dont even think of L3 solutions.... all the telcos, cable-cos, and utilities in this space only do L2 to the cell site.... even though they all use the same Juniper and ALU gear that does L3 too ... Cameron > -- > Mikael Abrahamsson ? ?email: swmike at swm.pp.se > From carlosm3011 at gmail.com Sun Jan 30 15:06:05 2011 From: carlosm3011 at gmail.com (Carlos M. Martinez) Date: Sun, 30 Jan 2011 19:06:05 -0200 Subject: Level 3's IRR Database In-Reply-To: <4D45CE4A.5090800@foobar.org> References: <E65B3ED7E6FCBA48BC3E2FA899729216018E704D@rouwkoop.ac.za> <AANLkTing8yEVoDSxXsa+eTV0xZuv2qkYYA-ahT26hbFx@mail.gmail.com> <4D45CE4A.5090800@foobar.org> Message-ID: <4D45D2BD.6050305@gmail.com> I think we just don't know (yet) how people are going to apply RPKI. If I were operating a large network today, I would try to run RPKI in a sort of warning-only mode, i.e. getting some sort of alert if an invalid route was detected. While this wouldn't have prevented YouTube's incident, it would probably have shortened the recovery period. I think it is too early in the deployment process to start dropping routes based on RPKI alone. We'll get there at some point, I guess. cheers Carlos On 1/30/11 6:47 PM, Nick Hilliard wrote: > On 30/01/2011 17:39, Carlos Martinez-Cagnazzo wrote: >> The solution to this problem (theoretical at least) already exist in >> the form of RPKI. > > So, what are peoples' routing policies on RPKI going to be? Are > people going to drop prefixes with no RPKI record? Or drop prefixes > with an incorrect RPKI record? Or drop prefixes with a revoked status? > > I'm concerned that if we're trying to avoid another Youtube affair, > the RPKI policy acceptability criteria will have to be so strict that > this may have a serious effect on overall reachability via the internet. > > Nick From ping at pingpan.org Sun Jan 30 15:13:14 2011 From: ping at pingpan.org (Ping Pan) Date: Sun, 30 Jan 2011 13:13:14 -0800 Subject: EPC backhaul networks In-Reply-To: <AANLkTi=_W8ybVtetdYaSB=PCpSuDQ2mzv-1BXaZuPAT7@mail.gmail.com> References: <AANLkTikcODvdkQO2TNXeaTYrrUo7RquNk=YqMx2rZcUu@mail.gmail.com> <AANLkTingxgFcpXwV2ZLaLRr8ucBZQLF_c8k0weno4N51@mail.gmail.com> <alpine.DEB.1.10.1101301909580.13151@uplift.swm.pp.se> <AANLkTikTNTe6nCZcwHC-zML8wTgL27UEMQVTLKA4A-A9@mail.gmail.com> <alpine.DEB.1.10.1101302150490.13151@uplift.swm.pp.se> <AANLkTi=_W8ybVtetdYaSB=PCpSuDQ2mzv-1BXaZuPAT7@mail.gmail.com> Message-ID: <AANLkTimdXyaXQKFm1zCqKGkvfQgfrc2Qh4Y_0nOZ=0MN@mail.gmail.com> On Sun, Jan 30, 2011 at 12:55 PM, Cameron Byrne <cb.list6 at gmail.com> wrote: > Yep. I hate L2. It is a total nightmare. But, it is literally the > only game in town. I blame the MEF for spreading propaganda that > MetroEis the best solution for backhaul ... most people dont even > think of L3 solutions.... all the telcos, cable-cos, and utilities in > this space only do L2 to the cell site.... even though they all use > the same Juniper and ALU gear that does L3 too ... > Curious, do you think this will last? Thought LTE is all-IP. Why is there a need for L2 other than raw bandwidth from Ethernet links? Thanks! Ping From Valdis.Kletnieks at vt.edu Sun Jan 30 15:15:31 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 30 Jan 2011 16:15:31 -0500 Subject: Level 3's IRR Database In-Reply-To: Your message of "Sun, 30 Jan 2011 19:06:05 -0200." <4D45D2BD.6050305@gmail.com> References: <E65B3ED7E6FCBA48BC3E2FA899729216018E704D@rouwkoop.ac.za> <AANLkTing8yEVoDSxXsa+eTV0xZuv2qkYYA-ahT26hbFx@mail.gmail.com> <4D45CE4A.5090800@foobar.org> <4D45D2BD.6050305@gmail.com> Message-ID: <2856.1296422131@localhost> On Sun, 30 Jan 2011 19:06:05 -0200, "Carlos M. Martinez" said: > I think it is too early in the deployment process to start dropping > routes based on RPKI alone. We'll get there at some point, I guess. Do we really *want* to get to that point? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110130/ff301780/attachment.bin> From randy at psg.com Sun Jan 30 15:22:38 2011 From: randy at psg.com (Randy Bush) Date: Mon, 31 Jan 2011 06:22:38 +0900 Subject: Level 3's IRR Database In-Reply-To: <4D45CE4A.5090800@foobar.org> References: <E65B3ED7E6FCBA48BC3E2FA899729216018E704D@rouwkoop.ac.za> <AANLkTing8yEVoDSxXsa+eTV0xZuv2qkYYA-ahT26hbFx@mail.gmail.com> <4D45CE4A.5090800@foobar.org> Message-ID: <m2sjwa84td.wl%randy@psg.com> > So, what are peoples' routing policies on RPKI going to be? Are people > going to drop prefixes with no RPKI record? Or drop prefixes with an > incorrect RPKI record? Or drop prefixes with a revoked status? draft-ietf-sidr-rpki-origin-ops-04.txt randy From brandon at rd.bbc.co.uk Sun Jan 30 15:53:58 2011 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Sun, 30 Jan 2011 21:53:58 GMT Subject: Level 3's IRR Database Message-ID: <201101302153.VAA20188@sunf10.rd.bbc.co.uk> > > I think it is too early in the deployment process to start dropping > > routes based on RPKI alone. We'll get there at some point, I guess. > > Do we really *want* to get to that point? I thought that was the point and the goal of securing the routing infrastructure is laudable. But the voices in my head say don't trust them with control of your routes, see what happened in Egypt. brandon From bedard.phil at gmail.com Sun Jan 30 15:57:30 2011 From: bedard.phil at gmail.com (Phil Bedard) Date: Sun, 30 Jan 2011 16:57:30 -0500 Subject: EPC backhaul networks In-Reply-To: <AANLkTikcODvdkQO2TNXeaTYrrUo7RquNk=YqMx2rZcUu@mail.gmail.com> Message-ID: <C96B2A69.335EF%bedard.phil@gmail.com> Easier to troubleshoot is the main reason but also, you would not put the MME/S-GW in every segment with the eNodeB anyways, so in the end you'd really want a L3 routed solution between them. One of the things I've seen is the L3 interface for the eNodeB terminates locally on an attached smaller cell-site router via a /30 and is not part of a larger L2 service with many eNodeBs in the same broadcast domain. You can run into scale issues with L3 as well with a router at every cell site and dynamic routing, so usually it's some kind of hybrid solution. Most service providers who provide backhaul services for wireless providers do so over a L2 or PW over MPLS network. Some of the smaller ALU, etc. cell site routers have started to support L3VPN so maybe L3VPN will be a service offering in the future with all-IP EPCs. Phil On 1/30/11 12:02 PM, "Glen Kent" <glen.kent at gmail.com> wrote: >Hi, > >I would like to understand why there is a preference for L3 VPNs over >L2 VPNs for the EPC backhaul networks? We can use both layer 2 and >layer 3 VPNs for communication between the eNodeB and the MME or S-GW, >so why is it that most providers prefer L3 over L2. > >Glen > From joelja at bogus.com Sun Jan 30 16:01:08 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Sun, 30 Jan 2011 14:01:08 -0800 Subject: EPC backhaul networks In-Reply-To: <AANLkTimdXyaXQKFm1zCqKGkvfQgfrc2Qh4Y_0nOZ=0MN@mail.gmail.com> References: <AANLkTikcODvdkQO2TNXeaTYrrUo7RquNk=YqMx2rZcUu@mail.gmail.com> <AANLkTingxgFcpXwV2ZLaLRr8ucBZQLF_c8k0weno4N51@mail.gmail.com> <alpine.DEB.1.10.1101301909580.13151@uplift.swm.pp.se> <AANLkTikTNTe6nCZcwHC-zML8wTgL27UEMQVTLKA4A-A9@mail.gmail.com> <alpine.DEB.1.10.1101302150490.13151@uplift.swm.pp.se> <AANLkTi=_W8ybVtetdYaSB=PCpSuDQ2mzv-1BXaZuPAT7@mail.gmail.com> <AANLkTimdXyaXQKFm1zCqKGkvfQgfrc2Qh4Y_0nOZ=0MN@mail.gmail.com> Message-ID: <4D45DFA4.5050105@bogus.com> On 1/30/11 1:13 PM, Ping Pan wrote: > On Sun, Jan 30, 2011 at 12:55 PM, Cameron Byrne <cb.list6 at gmail.com> wrote: > >> Yep. I hate L2. It is a total nightmare. But, it is literally the >> only game in town. I blame the MEF for spreading propaganda that >> MetroEis the best solution for backhaul ... most people dont even >> think of L3 solutions.... all the telcos, cable-cos, and utilities in >> this space only do L2 to the cell site.... even though they all use >> the same Juniper and ALU gear that does L3 too ... >> > > Curious, do you think this will last? Thought LTE is all-IP. Why is there a > need for L2 other than raw bandwidth from Ethernet links? They're talking backhaul between the node-b base-stations and the radio network controller... All the traffic from the handsets is encapsulated between those two points so it's link and network layer agnostic. > Thanks! > > Ping > From jbates at brightok.net Sun Jan 30 16:08:51 2011 From: jbates at brightok.net (Jack Bates) Date: Sun, 30 Jan 2011 16:08:51 -0600 Subject: Level 3's IRR Database In-Reply-To: <4D45CE4A.5090800@foobar.org> References: <E65B3ED7E6FCBA48BC3E2FA899729216018E704D@rouwkoop.ac.za> <AANLkTing8yEVoDSxXsa+eTV0xZuv2qkYYA-ahT26hbFx@mail.gmail.com> <4D45CE4A.5090800@foobar.org> Message-ID: <4D45E173.5080401@brightok.net> On 1/30/2011 2:47 PM, Nick Hilliard wrote: > I'm concerned that if we're trying to avoid another Youtube affair, > the RPKI policy acceptability criteria will have to be so strict that > this may have a serious effect on overall reachability via the internet. Not really. Just a simple, if route invalidly signed, drop it. If route validly signed, prefer it over unsigned. That allows people to choose to protect their routes, while the vast majority of routes don't need protecting. I haven't seen the proper mechanism, though it may exist, to say (hey, I already have a route which while not as specific was signed, so bye bye). Jack From bedard.phil at gmail.com Sun Jan 30 16:33:42 2011 From: bedard.phil at gmail.com (Phil Bedard) Date: Sun, 30 Jan 2011 17:33:42 -0500 Subject: EPC backhaul networks In-Reply-To: <AANLkTi=_W8ybVtetdYaSB=PCpSuDQ2mzv-1BXaZuPAT7@mail.gmail.com> Message-ID: <C96B508E.33707%bedard.phil@gmail.com> I work for a MSO and while we do provide L2 services today for wireless backhaul, the services are based on requirements from the wireless providers and I haven't seen an RFP yet in which someone wanted a L3 service. If someone really wanted a L3VPN as a backhaul solution we could oblige them but most do not want us having anything to do with their L3 network so we provide VPLS and P2P services. I'm always wary when I see a wireless provider wanting to build a 500 site VPLS to carry traffic and we try to discourage them as much as possible, but it happens... Phil On 1/30/11 3:55 PM, "Cameron Byrne" <cb.list6 at gmail.com> wrote: >On Sun, Jan 30, 2011 at 12:52 PM, Mikael Abrahamsson <swmike at swm.pp.se> >wrote: >> On Sun, 30 Jan 2011, Cameron Byrne wrote: >> >>> The only way to reach 2000 cell sites in Chicago with 100megs of >>>Ethernet >>> handoff is with L2 metroE. There is not a feasible L3 service offered >>> today. >> >> Ah. >> >> We either rent fiber or put up our own radio links, I guess different >> problems in different markets. >> > >Yep. I hate L2. It is a total nightmare. But, it is literally the >only game in town. I blame the MEF for spreading propaganda that >MetroEis the best solution for backhaul ... most people dont even >think of L3 solutions.... all the telcos, cable-cos, and utilities in >this space only do L2 to the cell site.... even though they all use >the same Juniper and ALU gear that does L3 too ... > >Cameron > >> -- >> Mikael Abrahamsson email: swmike at swm.pp.se >> > From millnert at gmail.com Sun Jan 30 16:38:13 2011 From: millnert at gmail.com (Martin Millnert) Date: Sun, 30 Jan 2011 17:38:13 -0500 Subject: Level 3's IRR Database In-Reply-To: <4D45E173.5080401@brightok.net> References: <E65B3ED7E6FCBA48BC3E2FA899729216018E704D@rouwkoop.ac.za> <AANLkTing8yEVoDSxXsa+eTV0xZuv2qkYYA-ahT26hbFx@mail.gmail.com> <4D45CE4A.5090800@foobar.org> <4D45E173.5080401@brightok.net> Message-ID: <AANLkTinJ-EmdAnUY53k3mGpw7Y5dw2xic8-RgnEK_U+1@mail.gmail.com> On Sun, Jan 30, 2011 at 5:08 PM, Jack Bates <jbates at brightok.net> wrote: > Just a simple, if route invalidly signed, drop it. What constitutes a invalidly signed route more exactly? Would a signed route by a signer (ISP) who's status has been revoked by an entity in the RPKI-hierarchy-of-trust above (for whatever reason), be considered invalid? For example, if the Egyptian government orders an entity situated somewhere in the verification trust-chain to revoke the trust-chain for some prefixes below, because it prefers these prefixes to not be reachable by anyone, that wouldn't be very good, would it? Not seeing the upside of that model at all. Why would anyone want that? Cheers, Martin From marka at isc.org Sun Jan 30 17:01:06 2011 From: marka at isc.org (Mark Andrews) Date: Mon, 31 Jan 2011 10:01:06 +1100 Subject: [arin-announce] ARIN Resource Certification Update In-Reply-To: Your message of "Sun, 30 Jan 2011 16:09:02 BST." <4D457F0E.7070805@consolejunkie.net> References: <EE59203D-907A-4AA2-BAE6-AEE7AADAC0A2@arin.net> <0BC31466-09EA-4734-96B2-152453A62B90@arin.net> <FDFF6713-AB2E-4447-A58B-52CD36A6113A@ripe.net> <23824.1296338405@nsa.vix.com> <43932B92-602B-4903-B2D0-F0D160821918@ripe.net> <AANLkTi=eZHzxruo4NzZKYB6VU-oi+XVG=Tz1Sg-fndHn@mail.gmail.com> <4D457F0E.7070805@consolejunkie.net> Message-ID: <20110130230106.A187094D003@drugs.dv.isc.org> In message <4D457F0E.7070805 at consolejunkie.net>, Leen Besselink writes: > Hello Carlos, > > On 01/30/2011 02:57 PM, Carlos Martinez-Cagnazzo wrote: > > What I just don?t get if, we as a society, have created institutions > > we trust with our *money* (AKA banks), why there can?t be institutions > > we trust with our crypto keys. I know that banks sometimes fail, and > > yes, probably "crypto banks" will sometimes fail as well, but on the > > whole, the failure rate of trusted institutions can be quite low, > > acceptably low. > > > > Well, we tried to trust the Certificate Authorities for SSL/TLS but that > has failed too. > > And they don't even hold private keys. > > Your browser now indirectly trusts 1000+ (sub) certificate authorities. > > Do I actually trust them all ? No, I don't but they could all sign a > certificate for paypal.com* which my browser would trust just fine. > > A simple example is CNNIC which is a Chinese government agency, the people > in China don't trust them, so why should I ? > > Should the browser really trust a German university to sign paypal.com* ? > > How about an agency in the United Emirates ? How about my own government ? > > Or Time Warner/AOL or Ford Motor company or Google ? > > And so on. > > https://www.eff.org/files/colour_map_of_CAs.pdf > https://www.eff.org/observatory > http://www.youtube.com/watch?v=VUKCDm04AqI > http://events.ccc.de/congress/2010/Fahrplan/events/4121.en.html > http://events.ccc.de/congress/2010/Fahrplan/attachments/1777_is-the-SSLiverse > -a-safe-place.pdf > > At this point, I would really like to see someone implement a > DNS-recursive nameserver which can be configured to only trust the root > to DNSSEC-sign the root zone and nothing else. And allow > the owners/operators/whatever of .com only allow to sign .com. Nothing more. Every validating recursive nameserver on the planet can be configured to do exactly that. Just install the root's keys and don't install any others. You won't be able to validate as secure data from security islands but that is what you want and is becoming less necessary as TLD start to get signed and accept DS records. > But that isn't really what DNSSEC was designed to do. I am however glad > people are working on adding DNSSEC to the browser and some hash in DNS > which tells the browser which certificate or CA's are trusted for a domain. > > Even though it seems to be going slow, because there are many reasons > why DNSSEC won't be deployed to users any time soon. A user can turn on DNSSEC any time they want to. Some ISPs have already turned on DNSSEC in their customer facing resolvers. > * Yes, I know Paypal.com uses an EV-certificate (green bar) and there > are a lot less CA's for that, but > it is just an example of a website. > > How about the Chinese government reading what you do on gmail while you > are in China ? That is > just an example of something that does not use an EV-cert. > > I'm not satisfied with the banks in my country either. It seems in both > cases to be a race to the bottom. > Cuttings costs any place they can, like reducing staff. Making it harder > and harder to use cash. > > The CA's seem to be a race to the bottom too. They are not spending > money trying to improve their > systems, even though the environment around them is changing. Just > trying to make money from their > existing business. > > Because it already is a race to the bottom, might as well offer free > certificates so everyone can use them > to secure any site. One CA already does this: https://www.startssl.com/ > They atleast to me seem to be > very proactive. > > The problem with banks is, I've not found a good alternative yet. > > Fully support StartSSL and RIPE for trying to lower the bar for more > security. > > Have a nice weekend, > Leen. > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From owen at delong.com Sun Jan 30 17:02:33 2011 From: owen at delong.com (Owen DeLong) Date: Sun, 30 Jan 2011 15:02:33 -0800 Subject: EPC backhaul networks In-Reply-To: <AANLkTi=_W8ybVtetdYaSB=PCpSuDQ2mzv-1BXaZuPAT7@mail.gmail.com> References: <AANLkTikcODvdkQO2TNXeaTYrrUo7RquNk=YqMx2rZcUu@mail.gmail.com> <AANLkTingxgFcpXwV2ZLaLRr8ucBZQLF_c8k0weno4N51@mail.gmail.com> <alpine.DEB.1.10.1101301909580.13151@uplift.swm.pp.se> <AANLkTikTNTe6nCZcwHC-zML8wTgL27UEMQVTLKA4A-A9@mail.gmail.com> <alpine.DEB.1.10.1101302150490.13151@uplift.swm.pp.se> <AANLkTi=_W8ybVtetdYaSB=PCpSuDQ2mzv-1BXaZuPAT7@mail.gmail.com> Message-ID: <7F6FC03E-20C3-4091-B087-0C917D1411D6@delong.com> On Jan 30, 2011, at 12:55 PM, Cameron Byrne wrote: > On Sun, Jan 30, 2011 at 12:52 PM, Mikael Abrahamsson <swmike at swm.pp.se> wrote: >> On Sun, 30 Jan 2011, Cameron Byrne wrote: >> >>> The only way to reach 2000 cell sites in Chicago with 100megs of Ethernet >>> handoff is with L2 metroE. There is not a feasible L3 service offered >>> today. >> >> Ah. >> >> We either rent fiber or put up our own radio links, I guess different >> problems in different markets. >> > > Yep. I hate L2. It is a total nightmare. But, it is literally the > only game in town. I blame the MEF for spreading propaganda that > MetroEis the best solution for backhaul ... most people dont even > think of L3 solutions.... all the telcos, cable-cos, and utilities in > this space only do L2 to the cell site.... even though they all use > the same Juniper and ALU gear that does L3 too ... > > Cameron > >> -- >> Mikael Abrahamsson email: swmike at swm.pp.se >> I know some people that are starting to refer to it as the Meth Forum. Owen From mpetach at netflight.com Sun Jan 30 17:17:19 2011 From: mpetach at netflight.com (Matthew Petach) Date: Sun, 30 Jan 2011 15:17:19 -0800 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <4D3FBEA3.6040404@gont.com.ar> References: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com> <AANLkTimcZavnJN2gqayS2-piDvOAcw_nrJAREJ0EDTjp@mail.gmail.com> <AANLkTikHBb+cyfPxXftb5QZh136D04fkdWFMy3NFhDdi@mail.gmail.com> <4D3FBEA3.6040404@gont.com.ar> Message-ID: <AANLkTimSpkQZ7pW=jb2KB1pndmKBpkug+WtugzOcUGJP@mail.gmail.com> On Tue, Jan 25, 2011 at 10:26 PM, Fernando Gont <fernando at gont.com.ar> wrote: > On 24/01/2011 07:41 p.m., Michael Loftis wrote: > >>> Many cite concerns of potential DoS attacks by doing sweeps of IPv6 >>> networks. ?I don't think this will be a common or wide-spread problem. >>> ?The general feeling is that there is simply too much address space >>> for it to be done in any reasonable amount of time, and there is >>> almost nothing to be gained from it. >> >> The problem I see is the opening of a new, simple, DoS/DDoS scenario. >> By repetitively sweeping a targets /64 you can cause EVERYTHING in >> that /64 to stop working by overflowing the ND/ND cache, depending on >> the specific ND cache implementation and how big it is/etc. > > That depends on the ND implementation being broken enough by not > limiting the number of neighbor cache entries that are in the INCOMPLETE > state. (I'm not saying those broken implementations don't exist, though). Even without completely overflowing the ND cache, informal lab testing shows that a single laptop on a well-connected network link can send sufficient packets at a very-large-scale backbone router's connected /64 subnet to keep the router CPU at 90%, sustained, for as long as you'd like. So, while it's not a direct denial of service (the network keeps functioning, albeit under considerable pain), it's enough to impact the ability of the network to react to other dynamic loads. :/ Matt From mpetach at netflight.com Sun Jan 30 17:22:10 2011 From: mpetach at netflight.com (Matthew Petach) Date: Sun, 30 Jan 2011 15:22:10 -0800 Subject: 2011.01.30 NANOG51 community meeting notes Message-ID: <AANLkTi=iX_QHWz8wMZPf5tNBsCCz3=gNBWCbbyrXeu9k@mail.gmail.com> My hastily-jotted notes from tonight's community meeting have been posted to http://kestrel3.netflight.com/2011.01.30-NANOG51-community-meeting.txt (though it was so fast, and so non-controversial, with no input from the audience to speak of, i almost felt silly for taking notes. ^_^;; ) Matt From ml at kenweb.org Sun Jan 30 17:30:47 2011 From: ml at kenweb.org (ML) Date: Sun, 30 Jan 2011 18:30:47 -0500 Subject: Level 3's IRR Database In-Reply-To: <201101302153.VAA20188@sunf10.rd.bbc.co.uk> References: <201101302153.VAA20188@sunf10.rd.bbc.co.uk> Message-ID: <4D45F4A7.5050501@kenweb.org> On 1/30/2011 4:53 PM, Brandon Butterworth wrote: >>> I think it is too early in the deployment process to start dropping >>> routes based on RPKI alone. We'll get there at some point, I guess. >> >> Do we really *want* to get to that point? > > I thought that was the point and the goal of securing the routing > infrastructure is laudable. But the voices in my head say don't trust > them with control of your routes, see what happened in Egypt. > > brandon > I would hope the response to the USG pressuring ARIN to diddle the RPKI db would be disabling of RPKI queries by most BGP speakers. From randy at psg.com Sun Jan 30 17:35:50 2011 From: randy at psg.com (Randy Bush) Date: Mon, 31 Jan 2011 08:35:50 +0900 Subject: Level 3's IRR Database In-Reply-To: <4D45F4A7.5050501@kenweb.org> References: <201101302153.VAA20188@sunf10.rd.bbc.co.uk> <4D45F4A7.5050501@kenweb.org> Message-ID: <m2mxmi7ynd.wl%randy@psg.com> > I would hope the response to the USG pressuring ARIN to diddle the RPKI > db would be disabling of RPKI queries by most BGP speakers. no need. break down, take a break from typing, and actually read draft-ietf-sidr-rpki-origin-ops-04.txt From joe.abley at icann.org Sun Jan 30 18:16:47 2011 From: joe.abley at icann.org (Joe Abley) Date: Mon, 31 Jan 2011 00:16:47 +0000 Subject: Planned IN-ADDR.ARPA Nameserver Change Message-ID: <E1PjhRn-000O1j-W7@monster.hopcount.ca> PLANNED IN-ADDR.ARPA NAMESERVER CHANGE This is a courtesy notification of an upcoming change to the nameserver set for the IN-ADDR.ARPA zone. There is no expected impact on the functional operation of the DNS due to this change. There are no actions required by DNS server operators or end users. For more information about this work, please see <http://in-addr-transition.icann.org/>. DETAIL The IN-ADDR.ARPA zone is used to provide reverse mapping (number to name) for IPv4. The servers which currently provide authoritative DNS service for the IN-ADDR.ARPA zone are as follows: A.ROOT-SERVERS.NET B.ROOT-SERVERS.NET C.ROOT-SERVERS.NET D.ROOT-SERVERS.NET E.ROOT-SERVERS.NET F.ROOT-SERVERS.NET G.ROOT-SERVERS.NET H.ROOT-SERVERS.NET I.ROOT-SERVERS.NET K.ROOT-SERVERS.NET L.ROOT-SERVERS.NET M.ROOT-SERVERS.NET On Wednesday 2010-02-16 processing will begin to change the nameserver set to the following, as described in RFC 5855: A.IN-ADDR-SERVERS.ARPA (operated by ARIN) B.IN-ADDR-SERVERS.ARPA (operated by ICANN) C.IN-ADDR-SERVERS.ARPA (operated by AfriNIC) D.IN-ADDR-SERVERS.ARPA (operated by LACNIC) E.IN-ADDR-SERVERS.ARPA (operated by APNIC) F.IN-ADDR-SERVERS.ARPA (operated by RIPE NCC) The usual IANA process for a change in the ARPA zone involves a series of technical checks and the gathering of various authorisations, and may take several days to complete. Following this, the IN-ADDR.ARPA zone will be dropped from root servers in two groups: 1. Week of 2011-02-21 -- 2011-02-25 B, C, E, G, I, M 2. Week of 2011-02-28 -- 2011-03-11 A, D, F, H, K, L Individual root server operators will choose a time for the maintenance within their respective window and follow their usual procedures to carry out the change. Courtesy notification will be sent to this list once this change has been fully implemented. Regards, Joe Abley Director DNS Operations ICANN From jsw at inconcepts.biz Sun Jan 30 18:37:30 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Sun, 30 Jan 2011 19:37:30 -0500 Subject: [arin-announce] ARIN Resource Certification Update In-Reply-To: <6E874B74-BA89-4D11-87BC-CEC580EEC618@delong.com> References: <60020FA8-364E-4F19-951A-95D971FDDD76@delong.com> <AANLkTin_5UrsUMDDhup8YJrBQXawqF7k_-yq8Zf7h3cY@mail.gmail.com> <08F0D3DD-D527-4A55-96AB-B414EE49342F@delong.com> <20110130.172804.74653776.sthaug@nethelp.no> <6E874B74-BA89-4D11-87BC-CEC580EEC618@delong.com> Message-ID: <AANLkTi=XDz8H8JB9j4ugCCe-jt=GAXdG0PK_CX-LSp-g@mail.gmail.com> On Sun, Jan 30, 2011 at 12:40 PM, Owen DeLong <owen at delong.com> wrote: > Because they publish data you have signed. They don't have the ability > to modify the data and then sign that modification as if they were you if > they aren't holding the private key. If they are holding the private key, > then, you have, in essence, given them power of attorney to administer > your network. > > If you're OK with that, more power to you. It's not the trust model I would > prefer. I suspect that many users would prefer to trust ARIN with their private keys, if offered that choice. The reasons are simple; adoption will be more wide-spread if RPKI is easier to do; and as we all know, there are an awful lot of BGP networks which are: * on auto-pilot, with no clued in-house staff and no stable relationships with outside clue * driven by people who are somewhere between totally clueless and capable of understanding public-key encryption * driven by over-worked people who simply don't have time for another to-do of any complexity Many users would benefit from the kind of hosted service that is made available by, for example, RIPE. In fact, if they felt they could trust ARIN (or any alternative service which may exist), most of my clients would be perfectly fine with such a service, and I would not advise them to do otherwise without a valid business reason and a belief that equal or superior security would be provided by not using such a hosted service. Since ARIN holds ultimate authority over the ISP's address space anyway, if ARIN's private keys become compromised, whether or not you held onto your own keys will not matter to the rest of the world. If I understand correctly, John has expressed that ARIN's concern is they may be sued if their hosted service fails to perform, and that ordinary contractual language may be unable to limit damages if the reality is that the service-customer has no other choice but to use the ARIN service. This is clearly not a legitimate concern if there is an alternative to such an ARIN hosted service, such as using no hosted service at all, or the possibility of using another one. I don't see how the lack of ARIN providing a hosted service immediately in any way prevents them from doing so in the future. If widespread RPKI adoption doesn't happen and a few more accidental or intentional YouTube black-holes do happen, it seems likely that stakeholders will encourage ARIN to do more, and a hosted service would be an obvious step to increase adoption. As you know, my comfort level with ARIN handling tasks of an operational nature is not high; but if they are going to participate in RPKI in any way, I think they should be capable of performing similarly to RIPE. If not, we should be asking ourselves either 1) why would anyone trust RIPE with their keys; or 2) why is RIPE more trustworthy than ARIN? If the answer to that is RIPE is significantly more competent than ARIN (most folks I know are of this belief) then this discussion should not be about one technical effort. Instead, it should be about how to make ARIN better. -- Jeff S Wheeler <jsw at inconcepts.biz> Sr Network Operator? /? Innovative Network Concepts From cidr-report at potaroo.net Fri Jan 28 16:00:00 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 28 Jan 2011 14:00:00 -0800 Subject: The Cidr Report Message-ID: <201101282200.p0SM00aS068962@wattle.apnic.net> This report has been generated at Fri Jan 28 21:11:57 2011 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 21-01-11 344825 201651 22-01-11 344975 201806 23-01-11 344876 201935 24-01-11 345075 201872 25-01-11 345142 201967 26-01-11 345293 201663 27-01-11 344858 200621 28-01-11 342381 201194 AS Summary 36544 Number of ASes in routing system 15508 Number of ASes announcing only one prefix 3710 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 106681344 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'). --- 28Jan11 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 342245 201128 141117 41.2% All ASes AS6389 3710 270 3440 92.7% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 2625 409 2216 84.4% TWTC - tw telecom holdings, inc. AS19262 1841 285 1556 84.5% VZGNI-TRANSIT - Verizon Online LLC AS4766 1915 544 1371 71.6% KIXS-AS-KR Korea Telecom AS6478 1476 245 1231 83.4% ATT-INTERNET3 - AT&T Services, Inc. AS22773 1274 86 1188 93.2% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS4755 1402 341 1061 75.7% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS1785 1790 768 1022 57.1% AS-PAETEC-NET - PaeTec Communications, Inc. AS28573 1246 304 942 75.6% NET Servicos de Comunicao S.A. AS10620 1357 443 914 67.4% Telmex Colombia S.A. AS7545 1596 727 869 54.4% TPG-INTERNET-AP TPG Internet Pty Ltd AS6503 1150 376 774 67.3% Axtel, S.A.B. de C.V. AS18101 922 152 770 83.5% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS24560 1094 333 761 69.6% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS7303 886 126 760 85.8% Telecom Argentina S.A. AS4808 1032 316 716 69.4% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS3356 1186 489 697 58.8% LEVEL3 Level 3 Communications AS17488 950 281 669 70.4% HATHWAY-NET-AP Hathway IP Over Cable Internet AS18566 1125 482 643 57.2% COVAD - Covad Communications Co. AS9498 745 110 635 85.2% BBIL-AP BHARTI Airtel Ltd. AS11492 1269 648 621 48.9% CABLEONE - CABLE ONE, INC. AS17676 647 69 578 89.3% GIGAINFRA Softbank BB Corp. AS855 633 57 576 91.0% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS8151 1185 616 569 48.0% Uninet S.A. de C.V. AS7552 649 102 547 84.3% VIETEL-AS-AP Vietel Corporation AS22047 566 31 535 94.5% VTR BANDA ANCHA S.A. AS14420 614 97 517 84.2% CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP AS3549 860 352 508 59.1% GBLX Global Crossing Ltd. AS9443 570 75 495 86.8% INTERNETPRIMUS-AS-AP Primus Telecommunications AS4804 571 77 494 86.5% MPX-AS Microplex PTY LTD Total 36886 9211 27675 75.0% Top 30 total Possible Bogus Routes 5.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 5.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 5.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 24.129.192.0/19 AS7922 COMCAST-7922 - Comcast Cable Communications, Inc. 37.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 37.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 37.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 46.227.80.0/21 AS8304 AS8304 ECRITEL Company 46.227.96.0/21 AS12611 RKOM R-KOM Regensburger Telekommunikations GmbH & Co. KG 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.18.224.0/20 AS12129 123NET - 123.Net, Inc. 64.21.192.0/20 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.212.0/22 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.216.0/21 AS11610 INETNEBR-1 - Internet Nebraska Corporation 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 69.6.81.0/24 AS13442 71.19.134.0/23 AS3313 INET-AS I.NET S.p.A. 72.22.32.0/19 AS33150 72.22.61.0/24 AS33150 72.22.62.0/24 AS33150 76.77.32.0/19 AS2828 XO-AS15 - XO Communications 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 96.45.161.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.162.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.163.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.164.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.165.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.166.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.167.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.168.0/21 AS3257 TINET-BACKBONE Tinet SpA 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas 110.173.64.0/19 AS37963 CNNIC-ALIBABA-CN-NET-AP Alibaba (China) Technology Co., Ltd. 113.29.0.0/17 AS3549 GBLX Global Crossing Ltd. 113.29.0.0/20 AS3549 GBLX Global Crossing Ltd. 113.29.16.0/20 AS3549 GBLX Global Crossing Ltd. 113.29.32.0/20 AS3549 GBLX Global Crossing Ltd. 113.29.64.0/20 AS3549 GBLX Global Crossing Ltd. 115.42.28.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.30.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.40.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.42.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.44.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.47.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.48.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.49.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.50.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.51.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.52.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.53.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.54.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.55.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.56.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.57.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.58.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.59.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.61.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.62.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.63.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 116.68.136.0/21 AS28045 Pantel Communications 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 121.54.160.0/24 AS38890 121.54.161.0/24 AS38890 121.54.162.0/24 AS38890 121.54.163.0/24 AS38890 121.54.164.0/24 AS38890 121.54.166.0/24 AS38890 121.54.167.0/24 AS38890 121.200.192.0/24 AS17767 122.200.32.0/20 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 122.200.40.0/21 AS38272 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services Inc. 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 172.12.0.0/18 AS28665 PredialNet Provedor de Internet Ltda. 176.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 176.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 176.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 181.82.176.224/27 AS45976 CNYGE-AS-KR chungcheongnamdo yeongi office of education 181.82.177.0/26 AS45976 CNYGE-AS-KR chungcheongnamdo yeongi office of education 190.102.32.0/20 AS30058 FDCSERVERS - FDCservers.net 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.101.46.0/24 AS6503 Axtel, S.A.B. de C.V. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 196.6.108.0/24 AS5713 SAIX-NET 196.13.201.0/24 AS2018 TENET-1 196.13.202.0/24 AS2018 TENET-1 196.13.203.0/24 AS2018 TENET-1 196.13.204.0/24 AS2018 TENET-1 196.110.105.0/24 AS8513 SKYVISION SkyVision Network Services 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.15.4.0/24 AS4323 TWTC - tw telecom holdings, inc. 198.15.5.0/24 AS4323 TWTC - tw telecom holdings, inc. 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.99.241.0/24 AS11797 AC-NIELSEN-AS AC NIELSEN 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.175.231.0/24 AS19262 VZGNI-TRANSIT - Verizon Online LLC 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 198.182.235.0/24 AS3356 LEVEL3 Level 3 Communications 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 199.185.130.0/23 AS19662 UNISERVE-ONLINE - Uniserve On Line 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.233.92.0/24 AS26896 D102-ITC - Data 102, LLC 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.24.73.0/24 AS26061 Equant Colombia 200.24.78.0/26 AS3549 GBLX Global Crossing Ltd. 200.24.78.64/26 AS3549 GBLX Global Crossing Ltd. 202.1.224.0/24 AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000 202.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.20.108.0/23 AS17885 JKTXLNET-AS-AP PT Excelcomindo Pratama 202.58.113.0/24 AS19161 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.66.128.0/18 AS9584 GENESIS-AP Diyixian.com Limited 202.66.160.0/19 AS9584 GENESIS-AP Diyixian.com Limited 202.66.160.0/20 AS9584 GENESIS-AP Diyixian.com Limited 202.66.176.0/20 AS9584 GENESIS-AP Diyixian.com Limited 202.66.184.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.186.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.188.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.189.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.190.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.133.37.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.146.186.0/24 AS23655 SNAP-NZ-AS Snap Internet Limited 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 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.130.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.131.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.133.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 202.179.144.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.149.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.150.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.18.156.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.22.78.0/24 AS18117 HARBOURMSP-AU-AP Harbour MSP Pty. Ltd 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.27.123.0/24 AS4739 CIX-ADELAIDE-AS Internode Systems Pty Ltd 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.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.142.219.0/24 AS45149 203.175.107.0/24 AS45595 PKTELECOM-AS-PK Pakistan Telecom Company Limited 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.10.232.0/21 AS33150 204.19.14.0/23 AS577 BACOM - Bell Canada 204.209.114.0/24 AS13768 PEER1 - Peer 1 Network Inc. 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.207.148.0/23 AS812 ROGERS-CABLE - Rogers Cable Communications Inc. 205.210.145.0/24 AS11814 DISTRIBUTEL-AS11814 - DISTRIBUTEL COMMUNICATIONS LTD. 206.72.192.0/23 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 206.72.194.0/23 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 206.123.129.0/24 AS10790 INREACH-AS - InReach Internet 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.188.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.189.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.190.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.191.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.64.200.0/22 AS11730 CIL-ASN - Circle Internet LTD 208.64.240.0/21 AS13871 TELEBYTE-NW - Telebyte NW 208.73.160.0/24 AS32767 208.78.165.0/24 AS16565 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.83.54.0/24 AS23485 SEI-LLC-AS-NUM - SEI LLC 208.89.60.0/22 AS40626 208.92.196.0/22 AS10929 NETELLIGENT - Netelligent Hosting Services Inc. 208.92.199.0/24 AS26198 3MENATWORK - 3Men at Work Integrated Networks, Inc. 208.94.48.0/21 AS19406 TWRS-MA - Towerstream I, Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.141.32.0/19 AS53667 PONYNET - FranTech Solutions 209.165.239.0/24 AS209 ASN-QWEST - Qwest Communications Company, LLC 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.213.1.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 209.213.4.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 216.10.235.0/24 AS13780 NTNCOMMUNICATIONS - NTN 216.10.236.0/24 AS13780 NTNCOMMUNICATIONS - NTN 216.21.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 216.21.196.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.201.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.202.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.206.0/23 AS12251 INVISION - Invision.com, Inc. 216.58.192.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.197.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.200.0/24 AS18530 ISOMEDIA-1 - Isomedia Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.194.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 216.250.112.0/20 AS7296 ALCHEMYNET - Alchemy Communications, Inc. Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org CONFIDENTIALITY NOTICE ======================= This email message and any attachments are for the exclusive use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message along with any attachments, from your computer system. If you are the intended recipient, please be advised that the content of this message is subject to access, review and disclosure by the sender's Email System Administrator. From nonobvious at gmail.com Fri Jan 28 16:07:51 2011 From: nonobvious at gmail.com (Bill Stewart) Date: Fri, 28 Jan 2011 14:07:51 -0800 Subject: Connectivity status for Egypt In-Reply-To: <535636.53395.qm@web59603.mail.ac4.yahoo.com> References: <535636.53395.qm@web59603.mail.ac4.yahoo.com> Message-ID: <AANLkTi=xVx8-Sz=ww4AmumX9grsQPHOkPTa_AWph00VP@mail.gmail.com> On 1/28/11, andrew.wallace <andrew.wallace at rocketmail.com> wrote: > We should be asking the Egyptians to stagger the return of services so that > infrastructure isn't affected, when connectivity is deemed to be allowed to > come back online. Well, yeah, it has to be done carefully, otherwise the first guy to turn on an E1 line that announces routes for the entire country is going to have his router overheat and the blue smoke get out.... If we're lucky, the Army won't damage too much as they either win or lose. -- ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it. From nonobvious at gmail.com Fri Jan 28 16:07:51 2011 From: nonobvious at gmail.com (Bill Stewart) Date: Fri, 28 Jan 2011 14:07:51 -0800 Subject: Connectivity status for Egypt In-Reply-To: <535636.53395.qm@web59603.mail.ac4.yahoo.com> References: <535636.53395.qm@web59603.mail.ac4.yahoo.com> Message-ID: <AANLkTi=xVx8-Sz=ww4AmumX9grsQPHOkPTa_AWph00VP@mail.gmail.com> On 1/28/11, andrew.wallace <andrew.wallace at rocketmail.com> wrote: > We should be asking the Egyptians to stagger the return of services so that > infrastructure isn't affected, when connectivity is deemed to be allowed to > come back online. Well, yeah, it has to be done carefully, otherwise the first guy to turn on an E1 line that announces routes for the entire country is going to have his router overheat and the blue smoke get out.... If we're lucky, the Army won't damage too much as they either win or lose. -- ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it. From michiel at klaver.it Fri Jan 28 16:12:17 2011 From: michiel at klaver.it (Michiel Klaver) Date: Fri, 28 Jan 2011 14:12:17 -0800 Subject: Best current looking glass software builds In-Reply-To: <002701cbbf09$8b658c10$a230a430$@unwiredltd.com> References: <002701cbbf09$8b658c10$a230a430$@unwiredltd.com> Message-ID: <4D433F41.2050709@klaver.it> At 22-07-2011 20:59, Peter Kranz wrote: > Anyone done a recent scan of newer looking glass software implementations > for apache? We've used cougar's for several years, but have been problems > with its SSH implementation lately. > Development of the Version6 LookingGlass can be found here, the latest version also supports proper SSH-v2: https://github.com/Cougar/lg From deleskie at gmail.com Fri Jan 28 16:32:39 2011 From: deleskie at gmail.com (jim deleskie) Date: Fri, 28 Jan 2011 14:32:39 -0800 Subject: Connectivity status for Egypt In-Reply-To: <AANLkTimH-Ng6dpZbLVMFnAO8pf24w_DaQNjyoLyTUCq2@mail.gmail.com> References: <AANLkTimUaNCRFhQqBTPM6Z=W7WUfU8fZUFHGjbqXGJsq@mail.gmail.com> <4D421BB4.1000909@toonk.nl> <9CCC7D46-D578-4BA0-893C-BAE0D170253B@gmail.com> <4D4266DD.7000906@gmail.com> <1296200640.3123.3.camel@Decaf.NEEBU.Net> <AANLkTi=BrQ_m1ypzObszR8_Ta9hPuz_gw-x7ZJYqknJh@mail.gmail.com> <4D432C36.5070404@sneep.net> <AANLkTimH-Ng6dpZbLVMFnAO8pf24w_DaQNjyoLyTUCq2@mail.gmail.com> Message-ID: <AANLkTik=k_qQ22=2yzO-ZYMgyTaO4_t7C8OhXC4ucfX1@mail.gmail.com> iMCI or WCOM? :) On Fri, Jan 28, 2011 at 5:18 PM, Christopher Morrow <morrowc.lists at gmail.com > wrote: > On Fri, Jan 28, 2011 at 3:51 PM, Alastair Johnson <aj at sneep.net> wrote: > > > For instance, our corporate WAN links into Cairo are still up (UUNET > PIP). > > <cough> that's the MCI PIP</cough>... > > From blake at ispn.net Fri Jan 28 17:29:04 2011 From: blake at ispn.net (Blake Hudson) Date: Fri, 28 Jan 2011 15:29:04 -0800 Subject: test-ipv6.com In-Reply-To: <alpine.BSF.2.00.1101271448000.15852@goat.gigo.com> References: <alpine.BSF.2.00.1101271448000.15852@goat.gigo.com> Message-ID: <4D435140.7020207@ispn.net> Does this site have an AAAA record? If so, my DNS does not pick it up. > [root at ns1 ~]# dig AAAA test-ipv6.com > > ; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 <<>> AAAA test-ipv6.com > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12875 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;test-ipv6.com. IN AAAA > > ;; AUTHORITY SECTION: > test-ipv6.com. 360 IN SOA ns1.gigo.com. > root.ns1.gigo.com. 2011010101 86400 7200 3600000 172800 > > ;; Query time: 216 msec > ;; SERVER: 64.35.208.1#53(64.35.208.1) > ;; WHEN: Fri Jan 28 17:27:20 2011 > ;; MSG SIZE rcvd: 81 > > [root at ns1 ~]# dig AAAA www.test-ipv6.com > > ; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 <<>> AAAA www.test-ipv6.com > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12788 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;www.test-ipv6.com. IN AAAA > > ;; ANSWER SECTION: > www.test-ipv6.com. 360 IN CNAME test-ipv6.com. > > ;; AUTHORITY SECTION: > test-ipv6.com. 355 IN SOA ns1.gigo.com. > root.ns1.gigo.com. 2011010101 86400 7200 3600000 172800 > > ;; Query time: 59 msec > ;; SERVER: 64.35.208.1#53(64.35.208.1) > ;; WHEN: Fri Jan 28 17:27:25 2011 > ;; MSG SIZE rcvd: 99 -------- Original Message -------- Subject: test-ipv6.com From: Jason Fesler <jfesler at gigo.com> To: nanog at nanog.org Date: Thursday, January 27, 2011 5:08:43 PM > Several people have suggested I (re)post information about > test-ipv6.com here. > > http://test-ipv6.com .. > tests ipv4 and ipv6 by dns name > tests dual stack (will the client break on World IPv6 Day?) > tests ipv6 by IP literal (teredo can pass this) > gives advice to end user about current status and (depending on > circumstances) more information > "broken" users (can't connect to dual stack) are solicited for info > Caution: does depend on javascript. > > http://test-ipv6.com/simple_test.html > Eyeball test only for user, with instructions; no javascript required. > > Please direct any comments, flames, etc directly to me instead of the > list. I've added enough noise already :-) > > From nonobvious at gmail.com Fri Jan 28 18:02:58 2011 From: nonobvious at gmail.com (Bill Stewart) Date: Fri, 28 Jan 2011 16:02:58 -0800 Subject: Ipv6 for the content provider In-Reply-To: <024EC9AD-2FD3-406A-A3DA-868152F33187@delong.com> References: <4D406670.8040202@knownelement.com> <5A6D953473350C4B9995546AFE9939EE0BC1361D@RWC-EX1.corp.seven.com> <024EC9AD-2FD3-406A-A3DA-868152F33187@delong.com> Message-ID: <AANLkTin+atGQ+2JDJhzU0m2QZbTzQkSU_KcDwfTcbBaK@mail.gmail.com> On 1/26/11, Owen DeLong <owen at delong.com> wrote: > And if your servers behind the LB aren't prepared for it, > you lose a LOT of logging data, geolocation capabilities, > and some other things if you go that route. Of course, anybody expecting a current IPv4 geolocation service to provide accurate information over IPv6 over the next couple of years is wildly optimistic (with all due respect to people in that business, but just sayin' good luck with that...) Maybe you'll get some consistency about which continent they're on based on the RIR the addresses came from, but even that's probably dodgy if the address belongs to Hurricane Electric or Sixxs or some other popular tunnel broker, and maybe you'll get some consistency on "is it the same /56 as last time?", and maybe some of them will start doing tricks like putting web bugs for "ipv4tracker.geolocator-example.com" and "ipv6tracker.geolocator-example.com" on the same web pages to try to start building correlation information, and if course you need your application that uses the information to speak IPv6 and handle 128-bit records and not just 32-bit. -- ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it. From john at sackheads.org Fri Jan 28 18:07:09 2011 From: john at sackheads.org (John Payne) Date: Fri, 28 Jan 2011 16:07:09 -0800 Subject: What's the current state of major access networks in North America ipv6 delivery status? In-Reply-To: <4D409787.8050104@knownelement.com> References: <4D409787.8050104@knownelement.com> Message-ID: <815DAAE1-6FE7-4207-A1DE-36780533F197@sackheads.org> On Jan 26, 2011, at 4:52 PM, Charles N Wyble <charles at knownelement.com> wrote: > Comcast is currently conducting trials: > http://comcast6.net/ (anyone participated in this?) Yes, and other than the fact that their 6rd implementation only gives me a /64, I've been really happy with it. My wife doesn't even know that her iOS devices and win7 box are dual stacked :) From brunner at nic-naa.net Fri Jan 28 18:12:36 2011 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Fri, 28 Jan 2011 16:12:36 -0800 Subject: in case of prefix withdrawal, dial-out In-Reply-To: <AANLkTinGvhL9AUjP1HnU-+zLGmVmMyBCmYFZ+5-kkQpO@mail.gmail.com> References: <AANLkTimUaNCRFhQqBTPM6Z=W7WUfU8fZUFHGjbqXGJsq@mail.gmail.com> <4D421BB4.1000909@toonk.nl> <9CCC7D46-D578-4BA0-893C-BAE0D170253B@gmail.com> <4D4266DD.7000906@gmail.com> <1296200640.3123.3.camel@Decaf.NEEBU.Net> <AANLkTi=BrQ_m1ypzObszR8_Ta9hPuz_gw-x7ZJYqknJh@mail.gmail.com> <4D432C36.5070404@sneep.net> <AANLkTimH-Ng6dpZbLVMFnAO8pf24w_DaQNjyoLyTUCq2@mail.gmail.com> <AANLkTik=k_qQ22=2yzO-ZYMgyTaO4_t7C8OhXC4ucfX1@mail.gmail.com> <AANLkTinGvhL9AUjP1HnU-+zLGmVmMyBCmYFZ+5-kkQpO@mail.gmail.com> Message-ID: <4D435B74.3000307@nic-naa.net> It is my son's turn to have the laptop so I won't bother to translate. The non-francophones can use Google's auto-xlate bot. http://www.lemonde.fr/technologies/article/2011/01/28/pour-contourner-le-blocage-du-web-les-modems-56k_1471819_651865.html CONFIDENTIALITY NOTICE ======================= This email message and any attachments are for the exclusive use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message along with any attachments, from your computer system. If you are the intended recipient, please be advised that the content of this message is subject to access, review and disclosure by the sender's Email System Administrator. From nonobvious at gmail.com Fri Jan 28 18:16:08 2011 From: nonobvious at gmail.com (Bill Stewart) Date: Fri, 28 Jan 2011 16:16:08 -0800 Subject: DSL options in NYC for OOB access In-Reply-To: <4D3DF769.7060601@nexus6.co.za> References: <4D3DF769.7060601@nexus6.co.za> Message-ID: <AANLkTinBEjrL6iwm1xYujA0OZiqGzfRwgXRM_b9D6Y0=@mail.gmail.com> On 1/24/11, Andy Ashley <lists at nexus6.co.za> wrote: > Im looking for a little advice about DSL circuits in New York, > specifically at 111 8th Ave. > Going to locate a console server there for out-of-band serial management. > The router will need connectivity for remote telnet/ssh access from the NOC. How much bandwidth do you need? Is a dialup modem fast enough? Traditional phone lines often give you a much different set of reliability issues and common-mode failures than Internet connectivity, which is good. I've been very happy with Pushkablue's dialup out-of-band boxes, which give you a serial console and power supply relays. Similarly, if wireless works in the part of the building you're in, and if the building allows you to have equipment that transmits radio signals (some colos don't), that's another option, again, because it's going to have different failures than the equipment you're controlling. > I searched some obvious providers but dont really want to deal with a > huge company (Verizon, Qwest, ?) if it can be avoided. ... > Are there smaller/independent companies out there offering > this sort of thing? > I dont know much about the US DSL market, so any hints are welcome. If you don't know the market, then there's a whole lot of value in dealing with the two or three dominant players for that city, or the two dozen huge companies for the country, as opposed to the hundreds or thousands of small players. (Admittedly, having dealt with ZA's dominant player in a previous job, I'd rather use anybody else also...) -- ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it. From jeroen at unfix.org Sun Jan 30 19:16:03 2011 From: jeroen at unfix.org (Jeroen Massar) Date: Mon, 31 Jan 2011 02:16:03 +0100 Subject: test-ipv6.com In-Reply-To: <4D435140.7020207@ispn.net> References: <alpine.BSF.2.00.1101271448000.15852@goat.gigo.com> <4D435140.7020207@ispn.net> Message-ID: <4D460D53.7070302@unfix.org> On 2011-01-29 00:29, Blake Hudson wrote: > Does this site have an AAAA record? If so, my DNS does not pick it up. ipv6-test.com itself does not, and that would be 'bad' also as then when somebody has an IPv6 stack but broken connectivity they would not be able to reach that site. >From the oh so helpful FAQ @ http://test-ipv6.com/faq.html 8<------------------------------------------------------------------------- Q: Why is this web site reachable via IPv4 only? You're right, there are no AAAA records, intentionally. A percentage of users are unable to browse sites that are dual-stack. If the users can't connect, then they can't be told they have a problem. This is a big problem facing content providers today; of which, I work at one for my $dayjob. As such, the main test page requires IPv4 (either native or translated). At some point, when the percentage of "broken" users has gone significantly down, I'll consider making test-ipv6.com dual-stack.. Q: How do I test my IPv6-only host If you ask that question, chances are you don't need this site. However, if you really want to, visit http://aaaa.test-ipv6.com with your IPv6-only host. ------------------------------------------------------------------------->8 Greets, Jeroen From mbassett at intelius.com Fri Jan 28 19:39:26 2011 From: mbassett at intelius.com (Mark Bassett) Date: Fri, 28 Jan 2011 17:39:26 -0800 Subject: Upload config to juniper In-Reply-To: <AANLkTi=R6bTmpBtj=oUbyDuCG8xC-cMgEJodRhSxbTFh@mail.gmail.com> References: <AANLkTinEpsHaVcro9io3gCpHeCKwpNHg9zBSAY+7oZKJ@mail.gmail.com> <AANLkTi=R6bTmpBtj=oUbyDuCG8xC-cMgEJodRhSxbTFh@mail.gmail.com> Message-ID: <8E80582D6651CB47BE5B9CE81D63D0480D09D5F8@exchange2.intelius1.intelius.com> Actually if you use the JUNOS api and the reference scripts there are examples to do just this. -----Original Message----- From: Jimmy Hess [mailto:mysidia at gmail.com] Sent: Wednesday, January 26, 2011 6:31 PM To: Florin Veres Cc: nanog at nanog.org Subject: Re: Upload config to juniper On Mon, Jan 24, 2011 at 7:39 AM, Florin Veres <florin at futurefreedom.ro> wrote: > Hey guys, > Do any of you have any idea if it's possible to upload configuration from a > script (prefix-list updates in this case) to a JunOS device (MX)? > For Cisco devices I'm doing it using rcp. >From config mode use a "load merge" command that specifies a SCP or FTP URL. You'll need to setup SSH keys in advance to do so without an additional password for the device to download the script. Alternatively... SCP the file to a temporary file on the device then "load merge" the uploaded file, to merge config from the script. Net::SSH::Expect from CPAN to connect via ssh from perl. Something like use Net::SSH::Perl; use Net::SSH::Expect; my $ssh = Net::SSH::Expect->new( host => 'myfavoritehostname.example.com', user => 'blahblahblah', password => '1234', raw_pty => 1); $ssh->login(q[blahblah at myfavoritehostname.example.com's password]); $output1 = $ssh->exec("configure private"); # $blah = $ssh->exec("load merge username at scriptserver.example.com:/path/to/scriptfile_to_load.txt"); print scalar $ssh->exec("show | compare"); # commit -- -JH From mbassett at intelius.com Fri Jan 28 19:44:30 2011 From: mbassett at intelius.com (Mark Bassett) Date: Fri, 28 Jan 2011 17:44:30 -0800 Subject: Upload config to juniper In-Reply-To: <8E80582D6651CB47BE5B9CE81D63D0480D09D5F8@exchange2.intelius1.intelius.com> References: <AANLkTinEpsHaVcro9io3gCpHeCKwpNHg9zBSAY+7oZKJ@mail.gmail.com><AANLkTi=R6bTmpBtj=oUbyDuCG8xC-cMgEJodRhSxbTFh@mail.gmail.com> <8E80582D6651CB47BE5B9CE81D63D0480D09D5F8@exchange2.intelius1.intelius.com> Message-ID: <8E80582D6651CB47BE5B9CE81D63D0480D09D5FC@exchange2.intelius1.intelius.com> I use the Netconf API and send xml config snippets like so: <configuration> <security> <zones> <security-zone> <name>Untrust</name> <address-book> <address operation="delete"> <name>auto_ip-7</name> <ip-prefix>67.23.7.115/32</ip-prefix> </address> <address-set> <name>demo_inbound_permit</name> <address operation="delete"> <name>auto_ip-7</name> </address> </address-set> </address-book> </security-zone> </zones> </security> </configuration> -----Original Message----- From: Mark Bassett [mailto:mbassett at intelius.com] Sent: Friday, January 28, 2011 5:39 PM To: Jimmy Hess; Florin Veres Cc: nanog at nanog.org Subject: RE: Upload config to juniper Actually if you use the JUNOS api and the reference scripts there are examples to do just this. -----Original Message----- From: Jimmy Hess [mailto:mysidia at gmail.com] Sent: Wednesday, January 26, 2011 6:31 PM To: Florin Veres Cc: nanog at nanog.org Subject: Re: Upload config to juniper On Mon, Jan 24, 2011 at 7:39 AM, Florin Veres <florin at futurefreedom.ro> wrote: > Hey guys, > Do any of you have any idea if it's possible to upload configuration from a > script (prefix-list updates in this case) to a JunOS device (MX)? > For Cisco devices I'm doing it using rcp. >From config mode use a "load merge" command that specifies a SCP or FTP URL. You'll need to setup SSH keys in advance to do so without an additional password for the device to download the script. Alternatively... SCP the file to a temporary file on the device then "load merge" the uploaded file, to merge config from the script. Net::SSH::Expect from CPAN to connect via ssh from perl. Something like use Net::SSH::Perl; use Net::SSH::Expect; my $ssh = Net::SSH::Expect->new( host => 'myfavoritehostname.example.com', user => 'blahblahblah', password => '1234', raw_pty => 1); $ssh->login(q[blahblah at myfavoritehostname.example.com's password]); $output1 = $ssh->exec("configure private"); # $blah = $ssh->exec("load merge username at scriptserver.example.com:/path/to/scriptfile_to_load.txt"); print scalar $ssh->exec("show | compare"); # commit -- -JH From marka at isc.org Sun Jan 30 19:27:51 2011 From: marka at isc.org (Mark Andrews) Date: Mon, 31 Jan 2011 12:27:51 +1100 Subject: looping email Message-ID: <20110131012752.04E0194E07A@drugs.dv.isc.org> Can whomever is at NEXTAG.COM please fix the pickup service to not use to To and Cc lines when re-injecting email. IT DOES NOT WORK. IT JUST CAUSES MAIL LOOPS. Received: from mail pickup service by corpmail5.corp.nextag.com with Microsoft SMTPSVC; Sun, 30 Jan 2011 17:10:55 -0800 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From shadowedstranger at gmail.com Fri Jan 28 22:42:10 2011 From: shadowedstranger at gmail.com (Jacob Broussard) Date: Fri, 28 Jan 2011 20:42:10 -0800 Subject: Bogons In-Reply-To: <20110129014139.GJ3684@hezmatt.org> References: <F6427296-2D81-40A2-B578-95BD27B8CE35@sackheads.org> <A28DCA86-6934-4ABE-B2E9-B951B013D44F@sackheads.org> <5A6D953473350C4B9995546AFE9939EE0BC136D4@RWC-EX1.corp.seven.com> <03AF91C1-A63E-47B2-9C15-BFDC1965EA95@sackheads.org> <AANLkTimzEvNKw9CSOeS+RHPxXPuNFWKV8fF1rM7aoCN8@mail.gmail.com> <20110129014139.GJ3684@hezmatt.org> Message-ID: <AANLkTi=K=o81UvX9Pc1WoKbdd4cVnN_DVtKgq2p+28W7@mail.gmail.com> You win. They had that address filtered way before I ever used it, silly me for not checking first :P What I really wanted to say on the list, though, was everyone that waits 1+ years between bogon updates can go to hell. They wait some poor flunky (me) has a customer yelling in my ear because "I could access that website fine before I switched to you".... *sigh* On Jan 28, 2011 5:44 PM, "Matthew Palmer" <mpalmer at hezmatt.org> wrote: > On Fri, Jan 28, 2011 at 12:35:43PM -0800, Jacob Broussard wrote: >> Static bogons are the bane of my existence... The pain of trying to explain >> to someone for MONTHS that they haven't updated their reference, with >> traceroutes to back it up, and they continue to say that it has something to >> do with my network. > > THey're right -- your network is using an address range they've chosen to > configure their equipment not to accept... <grin> > > - Matt > From shadowedstranger at gmail.com Fri Jan 28 22:42:10 2011 From: shadowedstranger at gmail.com (Jacob Broussard) Date: Fri, 28 Jan 2011 20:42:10 -0800 Subject: Bogons In-Reply-To: <20110129014139.GJ3684@hezmatt.org> References: <F6427296-2D81-40A2-B578-95BD27B8CE35@sackheads.org> <A28DCA86-6934-4ABE-B2E9-B951B013D44F@sackheads.org> <5A6D953473350C4B9995546AFE9939EE0BC136D4@RWC-EX1.corp.seven.com> <03AF91C1-A63E-47B2-9C15-BFDC1965EA95@sackheads.org> <AANLkTimzEvNKw9CSOeS+RHPxXPuNFWKV8fF1rM7aoCN8@mail.gmail.com> <20110129014139.GJ3684@hezmatt.org> Message-ID: <AANLkTi=K=o81UvX9Pc1WoKbdd4cVnN_DVtKgq2p+28W7@mail.gmail.com> You win. They had that address filtered way before I ever used it, silly me for not checking first :P What I really wanted to say on the list, though, was everyone that waits 1+ years between bogon updates can go to hell. They wait some poor flunky (me) has a customer yelling in my ear because "I could access that website fine before I switched to you".... *sigh* On Jan 28, 2011 5:44 PM, "Matthew Palmer" <mpalmer at hezmatt.org> wrote: > On Fri, Jan 28, 2011 at 12:35:43PM -0800, Jacob Broussard wrote: >> Static bogons are the bane of my existence... The pain of trying to explain >> to someone for MONTHS that they haven't updated their reference, with >> traceroutes to back it up, and they continue to say that it has something to >> do with my network. > > THey're right -- your network is using an address range they've chosen to > configure their equipment not to accept... <grin> > > - Matt > From fasterfourier at gmail.com Fri Jan 28 23:48:50 2011 From: fasterfourier at gmail.com (Robert Johnson) Date: Fri, 28 Jan 2011 21:48:50 -0800 Subject: Need provider suggestions - BGP transit over GRE tunnel In-Reply-To: <alpine.DEB.1.10.1101281733070.20241@sisler> References: <AANLkTikCHuobbeWyyk1Nng_+FE1DcDZwFFupfmUsBDs_@mail.gmail.com> <alpine.DEB.1.10.1101281733070.20241@sisler> Message-ID: <AANLkTimrNWBby0esM4+bz8pGq+J1D3OeMBV6wDUKhe9X@mail.gmail.com> My network spans a multicity geographic area using microwave radio links. The point of the GRE tunnel is to allow me to establish a BGP session to another AS using a consumer grade Internet connection (cheap) over the public Internet. I don't want to build out additional microwave paths to a new datacenter to become multihomed. On Fri, Jan 28, 2011 at 5:36 PM, C. Jon Larsen <jlarsen at richweb.com> wrote: > > I have read your email a few times and i dont see how this makes sense. > > Why do you need a public AS and PI space? Your gre tunnel wont need it or be > able to use it. A gre tunnel is just a replacement for a physical pipe. > > If your datacenter based presence goes down, you will need a pipe at your > office, or some other location speaking bgp that can annouce your block > anyway. > > > > > On Fri, 28 Jan 2011, Robert Johnson wrote: > >> My organization is planning to become multihomed in the near future. >> Currently we have redundant (router and physical path) links to a >> single AS where we get our transit, and speak BGP to them using a >> private ASN. This configuration has not been meeting our reliability >> requirements, so we will be getting our own ASN from ARIN, and moving >> from PA to PI IP space. >> >> Our new provider will be used for backup purposes only. We would like >> to minimize the monthly cost of this connection; to do this, we are >> planning to use a VZ business FIOS connection with symmetrical >> bandwidth to establish a GRE tunnel to a datacenter somewhere, and >> bring up a BGP session over that tunnel. I'd like to know if there are >> providers that offer such a service on a regular basis, and if so, if >> anyone is doing this and has words of wisdom. >> >> Thanks in advance. >> >> >> -- >> This message has been scanned for viruses and >> dangerous content by the Richweb.com MailScanner, and is >> believed to be clean. >> >> >> > From bensons at queuefull.net Fri Jan 28 19:47:42 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Fri, 28 Jan 2011 17:47:42 -0800 Subject: Connectivity status for Egypt In-Reply-To: <535636.53395.qm@web59603.mail.ac4.yahoo.com> References: <535636.53395.qm@web59603.mail.ac4.yahoo.com> Message-ID: <B15A9CCC-CDC1-4A69-9FE5-D2084D646CBA@queuefull.net> On Jan 28, 2011, at 1:44 PM, andrew.wallace wrote: > We should be asking the Egyptians to stagger the return of services so that infrastructure isn't affected, when connectivity is deemed to be allowed to come back online. > > Andrew Wallace > > --- > > British IT Security Consultant You should send them an email about that. From owen at delong.com Fri Jan 28 22:04:12 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 28 Jan 2011 20:04:12 -0800 Subject: Ipv6 for the content provider In-Reply-To: <AANLkTin+atGQ+2JDJhzU0m2QZbTzQkSU_KcDwfTcbBaK@mail.gmail.com> References: <4D406670.8040202@knownelement.com> <5A6D953473350C4B9995546AFE9939EE0BC1361D@RWC-EX1.corp.seven.com> <024EC9AD-2FD3-406A-A3DA-868152F33187@delong.com> <AANLkTin+atGQ+2JDJhzU0m2QZbTzQkSU_KcDwfTcbBaK@mail.gmail.com> Message-ID: <8BC2C7B1-2BB8-4710-B0EC-5C9532560890@delong.com> The IPv6 geo databases actually tend to be about on par with the IPv4 ones from what I have seen so far (which is admittedly limited as I don't really use geolocation services). However, I still think it is important for people considering deploying something as you described to be aware of the additional things that may break and factor that into their decision about how and what to deploy. Owen On Jan 28, 2011, at 4:02 PM, Bill Stewart wrote: > On 1/26/11, Owen DeLong <owen at delong.com> wrote: >> And if your servers behind the LB aren't prepared for it, >> you lose a LOT of logging data, geolocation capabilities, >> and some other things if you go that route. > > Of course, anybody expecting a current IPv4 geolocation service to > provide accurate information over IPv6 over the next couple of years > is wildly optimistic (with all due respect to people in that business, > but just sayin' good luck with that...) > > Maybe you'll get some consistency about which continent they're on > based on the RIR the addresses came from, but even that's probably > dodgy if the address belongs to Hurricane Electric or Sixxs or some > other popular tunnel broker, and maybe you'll get some consistency on > "is it the same /56 as last time?", and maybe some of them will start > doing tricks like putting web bugs for > "ipv4tracker.geolocator-example.com" and > "ipv6tracker.geolocator-example.com" on the same web pages to try to > start building correlation information, and if course you need your > application that uses the information to speak IPv6 and handle 128-bit > records and not just 32-bit. > > -- > ---- > Thanks; Bill > > Note that this isn't my regular email account - It's still experimental so far. > And Google probably logs and indexes everything you send it. From owen at delong.com Fri Jan 28 22:04:12 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 28 Jan 2011 20:04:12 -0800 Subject: Ipv6 for the content provider In-Reply-To: <AANLkTin+atGQ+2JDJhzU0m2QZbTzQkSU_KcDwfTcbBaK@mail.gmail.com> References: <4D406670.8040202@knownelement.com> <5A6D953473350C4B9995546AFE9939EE0BC1361D@RWC-EX1.corp.seven.com> <024EC9AD-2FD3-406A-A3DA-868152F33187@delong.com> <AANLkTin+atGQ+2JDJhzU0m2QZbTzQkSU_KcDwfTcbBaK@mail.gmail.com> Message-ID: <8BC2C7B1-2BB8-4710-B0EC-5C9532560890@delong.com> The IPv6 geo databases actually tend to be about on par with the IPv4 ones from what I have seen so far (which is admittedly limited as I don't really use geolocation services). However, I still think it is important for people considering deploying something as you described to be aware of the additional things that may break and factor that into their decision about how and what to deploy. Owen On Jan 28, 2011, at 4:02 PM, Bill Stewart wrote: > On 1/26/11, Owen DeLong <owen at delong.com> wrote: >> And if your servers behind the LB aren't prepared for it, >> you lose a LOT of logging data, geolocation capabilities, >> and some other things if you go that route. > > Of course, anybody expecting a current IPv4 geolocation service to > provide accurate information over IPv6 over the next couple of years > is wildly optimistic (with all due respect to people in that business, > but just sayin' good luck with that...) > > Maybe you'll get some consistency about which continent they're on > based on the RIR the addresses came from, but even that's probably > dodgy if the address belongs to Hurricane Electric or Sixxs or some > other popular tunnel broker, and maybe you'll get some consistency on > "is it the same /56 as last time?", and maybe some of them will start > doing tricks like putting web bugs for > "ipv4tracker.geolocator-example.com" and > "ipv6tracker.geolocator-example.com" on the same web pages to try to > start building correlation information, and if course you need your > application that uses the information to speak IPv6 and handle 128-bit > records and not just 32-bit. > > -- > ---- > Thanks; Bill > > Note that this isn't my regular email account - It's still experimental so far. > And Google probably logs and indexes everything you send it. From mbassett at intelius.com Fri Jan 28 19:44:30 2011 From: mbassett at intelius.com (Mark Bassett) Date: Fri, 28 Jan 2011 17:44:30 -0800 Subject: Upload config to juniper In-Reply-To: <8E80582D6651CB47BE5B9CE81D63D0480D09D5F8@exchange2.intelius1.intelius.com> References: <AANLkTinEpsHaVcro9io3gCpHeCKwpNHg9zBSAY+7oZKJ@mail.gmail.com><AANLkTi=R6bTmpBtj=oUbyDuCG8xC-cMgEJodRhSxbTFh@mail.gmail.com> <8E80582D6651CB47BE5B9CE81D63D0480D09D5F8@exchange2.intelius1.intelius.com> Message-ID: <8E80582D6651CB47BE5B9CE81D63D0480D09D5FC@exchange2.intelius1.intelius.com> I use the Netconf API and send xml config snippets like so: <configuration> <security> <zones> <security-zone> <name>Untrust</name> <address-book> <address operation="delete"> <name>auto_ip-7</name> <ip-prefix>67.23.7.115/32</ip-prefix> </address> <address-set> <name>demo_inbound_permit</name> <address operation="delete"> <name>auto_ip-7</name> </address> </address-set> </address-book> </security-zone> </zones> </security> </configuration> -----Original Message----- From: Mark Bassett [mailto:mbassett at intelius.com] Sent: Friday, January 28, 2011 5:39 PM To: Jimmy Hess; Florin Veres Cc: nanog at nanog.org Subject: RE: Upload config to juniper Actually if you use the JUNOS api and the reference scripts there are examples to do just this. -----Original Message----- From: Jimmy Hess [mailto:mysidia at gmail.com] Sent: Wednesday, January 26, 2011 6:31 PM To: Florin Veres Cc: nanog at nanog.org Subject: Re: Upload config to juniper On Mon, Jan 24, 2011 at 7:39 AM, Florin Veres <florin at futurefreedom.ro> wrote: > Hey guys, > Do any of you have any idea if it's possible to upload configuration from a > script (prefix-list updates in this case) to a JunOS device (MX)? > For Cisco devices I'm doing it using rcp. >From config mode use a "load merge" command that specifies a SCP or FTP URL. You'll need to setup SSH keys in advance to do so without an additional password for the device to download the script. Alternatively... SCP the file to a temporary file on the device then "load merge" the uploaded file, to merge config from the script. Net::SSH::Expect from CPAN to connect via ssh from perl. Something like use Net::SSH::Perl; use Net::SSH::Expect; my $ssh = Net::SSH::Expect->new( host => 'myfavoritehostname.example.com', user => 'blahblahblah', password => '1234', raw_pty => 1); $ssh->login(q[blahblah at myfavoritehostname.example.com's password]); $output1 = $ssh->exec("configure private"); # $blah = $ssh->exec("load merge username at scriptserver.example.com:/path/to/scriptfile_to_load.txt"); print scalar $ssh->exec("show | compare"); # commit -- -JH From herro91 at gmail.com Sun Jan 30 20:03:19 2011 From: herro91 at gmail.com (Herro91) Date: Sun, 30 Jan 2011 21:03:19 -0500 Subject: Strange L2 failure In-Reply-To: <4D44D596.3070707@brightok.net> References: <4D4485A6.3040203@brightok.net> <4D44D15C.90106@kenweb.org> <4D44D596.3070707@brightok.net> Message-ID: <AANLkTinsgq=v0DeWT5TfVs3ssZNV6Yn=0cL2+yXZToa-@mail.gmail.com> I had an issue on the 28xx with a static NAT that just stopped working. The router would not publish the MAC for the nat entry. I removed the NAT entry and reapplied - and magically it worked again. On Sat, Jan 29, 2011 at 10:05 PM, Jack Bates <jbates at brightok.net> wrote: > On 1/29/2011 8:47 PM, ML wrote: > >> I just ran into something like this yesterday. A Belkin router with a MAC >> of 9444.52dc.XXXX was properly learned at the IDF switch but the upstream >> agg switch/router wouldn't learn it. I even tried to static the MAC into >> the CAM..router refused. >> > > That's what really tripped me out, was that the router actually did place > an ARP entry and pretended like everything should be working. Scheduling > some more direct tests with packet sniffers next week when I get back in the > office. > > I'm curious now if IOS has the issue or the line card, so we'll test off > different cards direct and monitor results. > > Jack > > From andree+nanog at toonk.nl Sun Jan 30 20:18:27 2011 From: andree+nanog at toonk.nl (Andree Toonk) Date: Sun, 30 Jan 2011 18:18:27 -0800 Subject: Level 3's IRR Database In-Reply-To: <m2sjwa84td.wl%randy@psg.com> References: <E65B3ED7E6FCBA48BC3E2FA899729216018E704D@rouwkoop.ac.za> <AANLkTing8yEVoDSxXsa+eTV0xZuv2qkYYA-ahT26hbFx@mail.gmail.com> <4D45CE4A.5090800@foobar.org> <m2sjwa84td.wl%randy@psg.com> Message-ID: <4D461BF3.2080903@toonk.nl> .-- My secret spy satellite informs me that at 11-01-30 1:22 PM Randy Bush wrote: >> So, what are peoples' routing policies on RPKI going to be? Are people >> going to drop prefixes with no RPKI record? Or drop prefixes with an >> incorrect RPKI record? Or drop prefixes with a revoked status? > > draft-ietf-sidr-rpki-origin-ops-04.txt Question, Based on this draft the recommended preference order is: 1) Validation ok 2) not found 3) Validation nok Suppose an operator would use local-pref to achieve this. This intention (preferring validated routes) will break, when there's a more specific announcement that doesn't validate. For example the youtube incident would not have been stopped by doing this. Are there any suggestions or recommendations for how to handle these cases? Cheers, Andree From carlosm3011 at gmail.com Sun Jan 30 20:22:41 2011 From: carlosm3011 at gmail.com (Carlos Martinez-Cagnazzo) Date: Mon, 31 Jan 2011 00:22:41 -0200 Subject: Level 3's IRR Database In-Reply-To: <201101302153.VAA20188@sunf10.rd.bbc.co.uk> References: <201101302153.VAA20188@sunf10.rd.bbc.co.uk> Message-ID: <AANLkTi=4ZM3a9MTpjAXVV+WYOEgc6fVwUBPnGHobKr-1@mail.gmail.com> Hi, this is the second mention I see of RPKI and Egypt in the same context. I sincerely fail to see the connection between both situations. Egypt cut their links the old fashioned way: they pulled the plug. I fail to see how such a situation could be made worse by RPKI. It simply has nothing to do. Not deploying RPKI won't prevent your local friendly autocrat from ordering "cut all wires" or something like that. regards Carlos On Sun, Jan 30, 2011 at 7:53 PM, Brandon Butterworth <brandon at rd.bbc.co.uk> wrote: >> > I think it is too early in the deployment process to start dropping >> > routes based on RPKI alone. We'll get there at some point, I guess. >> >> Do we really *want* to get to that point? > > I thought that was the point and the goal of securing the routing > infrastructure is laudable. But the voices in my head say don't trust > them with control of your routes, see what happened in Egypt. > > brandon > > -- -- ========================= Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net ========================= From fernando at gont.com.ar Sun Jan 30 20:24:47 2011 From: fernando at gont.com.ar (Fernando Gont) Date: Sun, 30 Jan 2011 23:24:47 -0300 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <AANLkTimSpkQZ7pW=jb2KB1pndmKBpkug+WtugzOcUGJP@mail.gmail.com> References: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com> <AANLkTimcZavnJN2gqayS2-piDvOAcw_nrJAREJ0EDTjp@mail.gmail.com> <AANLkTikHBb+cyfPxXftb5QZh136D04fkdWFMy3NFhDdi@mail.gmail.com> <4D3FBEA3.6040404@gont.com.ar> <AANLkTimSpkQZ7pW=jb2KB1pndmKBpkug+WtugzOcUGJP@mail.gmail.com> Message-ID: <4D461D6F.1010508@gont.com.ar> Hi, Matthew, On 30/01/2011 08:17 p.m., Matthew Petach wrote: >>> The problem I see is the opening of a new, simple, DoS/DDoS scenario. >>> By repetitively sweeping a targets /64 you can cause EVERYTHING in >>> that /64 to stop working by overflowing the ND/ND cache, depending on >>> the specific ND cache implementation and how big it is/etc. >> >> That depends on the ND implementation being broken enough by not >> limiting the number of neighbor cache entries that are in the INCOMPLETE >> state. (I'm not saying those broken implementations don't exist, though). > > Even without completely overflowing the ND cache, informal lab testing > shows that a single laptop on a well-connected network link can send > sufficient packets at a very-large-scale backbone router's connected /64 > subnet to keep the router CPU at 90%, sustained, for as long as you'd > like. So, while it's not a direct denial of service (the network keeps > functioning, albeit under considerable pain), it's enough to impact the > ability of the network to react to other dynamic loads. :/ This is very interesting data. Are you talking about Ciscos? Any specific model? I guess that a possible mitigation technique (implementation-based) would be to limit the number of ongoing addresses in address resolution. (i.e., once you have X ongoing ND resolutions, the router should not be engaged in ND for other addresses) -- note that addresses that the router had already resolved in the past would not suffer from this penalty, as their corresponding entries would be in states other than INCOMPLETE. Thoughts? Thanks, -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From frnkblk at iname.com Sun Jan 30 21:00:15 2011 From: frnkblk at iname.com (Frank Bulk) Date: Sun, 30 Jan 2011 21:00:15 -0600 Subject: EPC backhaul networks In-Reply-To: <AANLkTi=_W8ybVtetdYaSB=PCpSuDQ2mzv-1BXaZuPAT7@mail.gmail.com> References: <AANLkTikcODvdkQO2TNXeaTYrrUo7RquNk=YqMx2rZcUu@mail.gmail.com> <AANLkTingxgFcpXwV2ZLaLRr8ucBZQLF_c8k0weno4N51@mail.gmail.com> <alpine.DEB.1.10.1101301909580.13151@uplift.swm.pp.se> <AANLkTikTNTe6nCZcwHC-zML8wTgL27UEMQVTLKA4A-A9@mail.gmail.com> <alpine.DEB.1.10.1101302150490.13151@uplift.swm.pp.se> <AANLkTi=_W8ybVtetdYaSB=PCpSuDQ2mzv-1BXaZuPAT7@mail.gmail.com> Message-ID: <00d201cbc0f2$fcb54d70$f61fe850$@iname.com> Write the RFPs asking for L3 -- I don't think they're asking for L3. Frank -----Original Message----- From: Cameron Byrne [mailto:cb.list6 at gmail.com] Sent: Sunday, January 30, 2011 2:55 PM To: Mikael Abrahamsson Cc: nanog at nanog.org Subject: Re: EPC backhaul networks On Sun, Jan 30, 2011 at 12:52 PM, Mikael Abrahamsson <swmike at swm.pp.se> wrote: > On Sun, 30 Jan 2011, Cameron Byrne wrote: > >> The only way to reach 2000 cell sites in Chicago with 100megs of Ethernet >> handoff is with L2 metroE. ?There is not a feasible L3 service offered >> today. > > Ah. > > We either rent fiber or put up our own radio links, I guess different > problems in different markets. > Yep. I hate L2. It is a total nightmare. But, it is literally the only game in town. I blame the MEF for spreading propaganda that MetroEis the best solution for backhaul ... most people dont even think of L3 solutions.... all the telcos, cable-cos, and utilities in this space only do L2 to the cell site.... even though they all use the same Juniper and ALU gear that does L3 too ... Cameron > -- > Mikael Abrahamsson ? ?email: swmike at swm.pp.se > From owen at delong.com Sun Jan 30 20:59:32 2011 From: owen at delong.com (Owen DeLong) Date: Sun, 30 Jan 2011 18:59:32 -0800 Subject: What's the current state of major access networks in North America ipv6 delivery status? In-Reply-To: <815DAAE1-6FE7-4207-A1DE-36780533F197@sackheads.org> References: <4D409787.8050104@knownelement.com> <815DAAE1-6FE7-4207-A1DE-36780533F197@sackheads.org> Message-ID: <E3C6360F-1AF0-43FB-8B39-F9B34E957FBA@delong.com> On Jan 28, 2011, at 4:07 PM, John Payne wrote: > > > On Jan 26, 2011, at 4:52 PM, Charles N Wyble <charles at knownelement.com> wrote: > >> Comcast is currently conducting trials: >> http://comcast6.net/ (anyone participated in this?) > > Yes, and other than the fact that their 6rd implementation only gives me a /64, I've been really happy with it. My wife doesn't even know that her iOS devices and win7 box are dual stacked :) If you have CPE that will accept more than a /64 via DHCPv6, they will be glad to have you trial more. However, as yet none of the CPE seems to support that. Owen From owen at delong.com Sun Jan 30 21:07:02 2011 From: owen at delong.com (Owen DeLong) Date: Sun, 30 Jan 2011 19:07:02 -0800 Subject: NANOG lIst replay? Message-ID: <00BD3D23-12D6-4BB6-882F-3CCAE2A67EBE@delong.com> Is it my imagination, or, is the list replaying messages from several days ago? Owen From marka at isc.org Sun Jan 30 21:21:12 2011 From: marka at isc.org (Mark Andrews) Date: Mon, 31 Jan 2011 14:21:12 +1100 Subject: NANOG lIst replay? In-Reply-To: Your message of "Sun, 30 Jan 2011 19:07:02 -0800." <00BD3D23-12D6-4BB6-882F-3CCAE2A67EBE@delong.com> References: <00BD3D23-12D6-4BB6-882F-3CCAE2A67EBE@delong.com> Message-ID: <20110131032112.C9A5294FC1A@drugs.dv.isc.org> In message <00BD3D23-12D6-4BB6-882F-3CCAE2A67EBE at delong.com>, Owen DeLong writes: > Is it my imagination, or, is the list replaying messages from several = > days ago? Yes. Yet another person using microsoft's pickup service and reinjecting the email using the To and Cc headers from the email rather than specifying their own address on the command line. > Owen > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From vixie at isc.org Sun Jan 30 21:25:28 2011 From: vixie at isc.org (Paul Vixie) Date: Mon, 31 Jan 2011 03:25:28 +0000 Subject: [arin-announce] ARIN Resource Certification Update In-Reply-To: Your message of "Sun, 30 Jan 2011 11:39:36 +0100." <43932B92-602B-4903-B2D0-F0D160821918@ripe.net> References: <EE59203D-907A-4AA2-BAE6-AEE7AADAC0A2@arin.net> <0BC31466-09EA-4734-96B2-152453A62B90@arin.net> <FDFF6713-AB2E-4447-A58B-52CD36A6113A@ripe.net> <23824.1296338405@nsa.vix.com> <43932B92-602B-4903-B2D0-F0D160821918@ripe.net> Message-ID: <23758.1296444328@nsa.vix.com> > From: Alex Band <alexb at ripe.net> > Date: Sun, 30 Jan 2011 11:39:36 +0100 > > I think my question is very pertinent. Of course the number of signed > prefixes directly influences the number of validators. Do you think > the RIPE NCC Validator tool would have been downloaded over 100 times > in the last month if there were only 5 certified prefixes? i think we may be talking past each other. the number of production validators will be unrelated to any difference between "prefixes signed because signing is easy" and "prefixes signed because operators are willing to do something hard." the operators who will sign even if it's hard (for example, deploying up/down) and also the operators who will only do it if it's easy (for example, hosted at an RIR) will each not care how many production validators there are at that moment -- their decision will be made on some other basis. > Practically, in the real world, why would anyone invest time and > effort in altering their current BGP decision making process to > accommodate for resource certification if the technology is on > nobody's radar, it's hard to get your feet wet and there are just a > handful of certified prefixes out there. Wouldn't it be good if > network operators think: "Because it helps increase global routing > security, it's easy to get started and lots of people are already > involved, perhaps I should have a look at (both sides of) resource > certification too." the reasoning you're describing is what we had in mind when we built DLV as an early deployment aid for DNSSEC. we had to "break stiction" where if there were no validators there would be incentive to sign, and if there were no signatures there would be no incentive to validate. are you likewise proposing the hosted solution only as an early deployment aid? i'm really quite curious as to whether you'll continue operating an RPKI hosting capability even if it becomes unnec'y (as proved some day if many operators of all sizes demonstrate capability for up/down). if so, can you share the reasoning behind that business decision? i know it sounds like i'm arguing against a hosted solution, but i'm not. i'm just saying that network operators are going to make business decisions (comparing cost and risk to benefit) as to whether to sign and whether to validate, and RIR's are going to make business decisions (comparing cost and risk to benefit) as to what provisioning mode to offer, and i don't plan to try to tell any network operators to sign or validate based on my own criteria, nor do i plan to try to tell any RIR that they should host or do up/down based on my own criteria. it's their own criteria that matters. let's just get the best starting conditions we can get, and then expect that everybody will make the best decision they can make based on those conditions. at ISC i have been extremely interested in participating in RPKI development and i think that sra and randy (and the whole RPKI team inside IETF and among the RIRs) have done great work improving the starting conditions for anyone who has to make a business decision of whether to deploy and if so what mode to deploy in. on the ARIN BoT i have likewise been very interested in and supportive of RPKI and i'm happy to repeat john curran's words which were, ARIN is looking at the risks and benefits of various RPKI deployment scenarios, and we expect to do more public and member outreach and consultation at our upcoming meeting in san juan PR. Paul Vixie Chairman and Chief Scientist, ISC Member, ARIN BoT re: > > i don't agree that that question is pertinent. in deployment scenario > > planning i've come up with three alternatives and this question is not > > relevant to any of them. perhaps you know a fourth alternative. here > > are mine. > > > > 1. people who receive routes will prefer signed vs. unsigned, and other > > people who can sign routes will sign them if it's easy (for example, > > hosted) but not if it's too hard (for example, up/down). > > > > 2. same as #1 except people who really care about their routes (like > > banks or asp's) will sign them even if it is hard (for example, up/down). > > > > 3. people who receive routes will ignore any unsigned routes they hear, > > and everyone who can sign routes will sign them no matter how hard it is. > > > > i do not expect to live long enough to see #3. the difference between #1 > > and #2 depends on the number of validators not the number of signed routes > > (since it's an incentive question). therefore small differences in the > > size of the set of signed routes does not matter very much in 2011, and > > the risk:benefit profile of hosted vs. up/down still matters far more. > > ... From owen at delong.com Sat Jan 29 03:13:40 2011 From: owen at delong.com (Owen DeLong) Date: Sat, 29 Jan 2011 01:13:40 -0800 Subject: Fwd: [listname] Fwd: Connectivity status for Egypt References: <4D43C792.5090006@sahara.com.sa> Message-ID: <BA464B90-BDFE-4AF7-8B57-AFB9325CC16F@delong.com> Anonymized because I am forwarding without permission... > > Dears, > > As per what I know from friends: > > 1. All Internet is down. Apparently one network is still working but seems to be serving the stock exchange only and few others. > 2. SMS is down. > 3. Landlines are down (at least internationally). > 4. Mobile networks seem to be on and off depending on location. For example, Vodafone is apparently working in Cairo while other networks are not !! > > God help them and bring Egypt and Egyptians out of this harmless inshallah. > Regards.. Owen From netfortius at gmail.com Fri Jan 28 16:01:24 2011 From: netfortius at gmail.com (Stefan) Date: Fri, 28 Jan 2011 14:01:24 -0800 Subject: Connectivity status for Egypt In-Reply-To: <535636.53395.qm@web59603.mail.ac4.yahoo.com> References: <535636.53395.qm@web59603.mail.ac4.yahoo.com> Message-ID: <AANLkTimxo-GCj4Wv_naJ3Ck8ab+EK2dwwh7fVg6FrEjG@mail.gmail.com> On Fri, Jan 28, 2011 at 3:44 PM, andrew.wallace <andrew.wallace at rocketmail.com> wrote: > We should be asking the Egyptians to stagger the return of services so that infrastructure isn't affected, when connectivity is deemed to be allowed to come back online. > > Andrew Wallace > > --- > > British IT Security Consultant http://lifehacker.com/5746046/how-to-foil-a-nationwide-internet-shutdown ***Stefan Mititelu http://twitter.com/netfortius http://www.linkedin.com/in/netfortius From cidr-report at potaroo.net Fri Jan 28 16:00:02 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 28 Jan 2011 14:00:02 -0800 Subject: BGP Update Report Message-ID: <201101282200.p0SM02QR068968@wattle.apnic.net> BGP Update Report Interval: 20-Jan-11 -to- 27-Jan-11 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS32528 18632 1.3% 6210.7 -- ABBOTT Abbot Labs 2 - AS1785 18374 1.3% 10.4 -- AS-PAETEC-NET - PaeTec Communications, Inc. 3 - AS18025 16571 1.2% 460.3 -- ACE-1-WIFI-AS-AP Ace-1 Wifi Network 4 - AS35931 15587 1.1% 5195.7 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 5 - AS8452 15525 1.1% 9.4 -- TE-AS TE-AS 6 - AS33475 12203 0.9% 56.8 -- RSN-1 - RockSolid Network, Inc. 7 - AS23700 12199 0.9% 27.4 -- BM-AS-ID PT. Broadband Multimedia, Tbk 8 - AS9498 12187 0.9% 17.8 -- BBIL-AP BHARTI Airtel Ltd. 9 - AS24923 11360 0.8% 2840.0 -- SETTC South-East Transtelecom Joint Stock Co. 10 - AS24863 11133 0.8% 11.6 -- LINKdotNET-AS 11 - AS9829 10876 0.8% 28.2 -- BSNL-NIB National Internet Backbone 12 - AS15105 10194 0.7% 37.9 -- NETWORKTELEPHONE - Network Telephone Corporation 13 - AS25019 9838 0.7% 44.1 -- SAUDINETSTC-AS Autonomus System Number for SaudiNet 14 - AS17974 8548 0.6% 11.5 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 15 - AS6316 8282 0.6% 77.4 -- AS-PAETEC-NET - PaeTec Communications, Inc. 16 - AS36992 7722 0.5% 11.5 -- ETISALAT-MISR 17 - AS28573 7694 0.5% 12.1 -- NET Servicos de Comunicao S.A. 18 - AS30969 7082 0.5% 120.0 -- 19 - AS14420 6938 0.5% 11.3 -- CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP 20 - AS9198 6384 0.5% 14.0 -- KAZTELECOM-AS JSC Kazakhtelecom TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS32528 18632 1.3% 6210.7 -- ABBOTT Abbot Labs 2 - AS6401 5855 0.4% 5855.0 -- ALLST-6401 - Allstream Corp. 3 - AS35931 15587 1.1% 5195.7 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 4 - AS24923 11360 0.8% 2840.0 -- SETTC South-East Transtelecom Joint Stock Co. 5 - AS49776 2103 0.1% 2103.0 -- GORSET-AS Gorodskaya Set Ltd. 6 - AS49600 1504 0.1% 1504.0 -- LASEDA La Seda de Barcelona, S.A 7 - AS28175 1494 0.1% 1494.0 -- 8 - AS34239 1422 0.1% 1422.0 -- INTERAMERICAN General Insurance Company 9 - AS27771 2682 0.2% 1341.0 -- Instituto Venezolano de Investigaciones Cientificas 10 - AS40772 2648 0.2% 1324.0 -- VELOCITER-WIRELESS-INC - Velociter Wireless, Inc. 11 - AS36383 1764 0.1% 882.0 -- TRABERTECHNOLOGIES-NETWORK - Traber Technologies Inc. 12 - AS35914 1763 0.1% 881.5 -- FIREHOST-INC - FireHost, Inc. 13 - AS43605 659 0.1% 659.0 -- STRK-NET JSC STRK 14 - AS17408 3268 0.2% 653.6 -- ABOVE-AS-AP AboveNet Communications Taiwan 15 - AS9929 4377 0.3% 625.3 -- CNCNET-CN China Netcom Corp. 16 - AS4454 582 0.0% 582.0 -- TNET-AS - State of Tennessee 17 - AS45550 516 0.0% 516.0 -- NGT-AS-VN New Generations Telecommunications Corporation 18 - AS40168 488 0.0% 488.0 -- TOYOTA-PR - Toyota de Puerto Rico Corp. 19 - AS3 957 0.1% 333.0 -- VP-NET-SE Videoplaza AB 20 - AS18025 16571 1.2% 460.3 -- ACE-1-WIFI-AS-AP Ace-1 Wifi Network TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 213.129.96.0/19 11343 0.8% AS24923 -- SETTC South-East Transtelecom Joint Stock Co. 2 - 63.211.68.0/22 10105 0.7% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 3 - 130.36.34.0/24 9317 0.6% AS32528 -- ABBOTT Abbot Labs 4 - 130.36.35.0/24 9314 0.6% AS32528 -- ABBOTT Abbot Labs 5 - 216.126.136.0/22 7442 0.5% AS6316 -- AS-PAETEC-NET - PaeTec Communications, Inc. 6 - 159.18.255.0/24 5855 0.4% AS6401 -- ALLST-6401 - Allstream Corp. 7 - 198.140.43.0/24 5436 0.4% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 8 - 68.65.152.0/22 3700 0.2% AS11915 -- TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 9 - 67.210.226.0/24 3495 0.2% AS35914 -- FIREHOST-INC - FireHost, Inc. AS7819 -- GLOBAL-IP-NETWORKS - Global IP Networks INC 10 - 202.153.174.0/24 3254 0.2% AS17408 -- ABOVE-AS-AP AboveNet Communications Taiwan 11 - 27.123.248.0/22 3215 0.2% AS18025 -- ACE-1-WIFI-AS-AP Ace-1 Wifi Network 12 - 182.54.140.0/22 3210 0.2% AS18025 -- ACE-1-WIFI-AS-AP Ace-1 Wifi Network 13 - 182.54.148.0/22 3210 0.2% AS18025 -- ACE-1-WIFI-AS-AP Ace-1 Wifi Network 14 - 101.78.20.0/22 3199 0.2% AS18025 -- ACE-1-WIFI-AS-AP Ace-1 Wifi Network 15 - 101.78.24.0/22 3198 0.2% AS18025 -- ACE-1-WIFI-AS-AP Ace-1 Wifi Network 16 - 206.184.16.0/24 3190 0.2% AS174 -- COGENT Cogent/PSI 17 - 76.74.88.0/23 2430 0.2% AS6517 -- RELIANCEGLOBALCOM - Reliance Globalcom Services, Inc 18 - 187.86.13.0/24 2246 0.1% AS28135 -- 19 - 213.108.216.0/21 2103 0.1% AS49776 -- GORSET-AS Gorodskaya Set Ltd. 20 - 183.88.0.0/16 2072 0.1% AS45629 -- JASTEL-NETWORK-TH-AP Jasmine International Tower AS45758 -- TRIPLETNET-AS-AP TripleT Internet Internet service provider Bangkok Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org CONFIDENTIALITY NOTICE ======================= This email message and any attachments are for the exclusive use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message along with any attachments, from your computer system. If you are the intended recipient, please be advised that the content of this message is subject to access, review and disclosure by the sender's Email System Administrator. From cidr-report at potaroo.net Fri Jan 28 16:00:00 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 28 Jan 2011 14:00:00 -0800 Subject: The Cidr Report Message-ID: <201101282200.p0SM00aS068962@wattle.apnic.net> This report has been generated at Fri Jan 28 21:11:57 2011 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 21-01-11 344825 201651 22-01-11 344975 201806 23-01-11 344876 201935 24-01-11 345075 201872 25-01-11 345142 201967 26-01-11 345293 201663 27-01-11 344858 200621 28-01-11 342381 201194 AS Summary 36544 Number of ASes in routing system 15508 Number of ASes announcing only one prefix 3710 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 106681344 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'). --- 28Jan11 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 342245 201128 141117 41.2% All ASes AS6389 3710 270 3440 92.7% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 2625 409 2216 84.4% TWTC - tw telecom holdings, inc. AS19262 1841 285 1556 84.5% VZGNI-TRANSIT - Verizon Online LLC AS4766 1915 544 1371 71.6% KIXS-AS-KR Korea Telecom AS6478 1476 245 1231 83.4% ATT-INTERNET3 - AT&T Services, Inc. AS22773 1274 86 1188 93.2% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS4755 1402 341 1061 75.7% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS1785 1790 768 1022 57.1% AS-PAETEC-NET - PaeTec Communications, Inc. AS28573 1246 304 942 75.6% NET Servicos de Comunicao S.A. AS10620 1357 443 914 67.4% Telmex Colombia S.A. AS7545 1596 727 869 54.4% TPG-INTERNET-AP TPG Internet Pty Ltd AS6503 1150 376 774 67.3% Axtel, S.A.B. de C.V. AS18101 922 152 770 83.5% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS24560 1094 333 761 69.6% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS7303 886 126 760 85.8% Telecom Argentina S.A. AS4808 1032 316 716 69.4% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS3356 1186 489 697 58.8% LEVEL3 Level 3 Communications AS17488 950 281 669 70.4% HATHWAY-NET-AP Hathway IP Over Cable Internet AS18566 1125 482 643 57.2% COVAD - Covad Communications Co. AS9498 745 110 635 85.2% BBIL-AP BHARTI Airtel Ltd. AS11492 1269 648 621 48.9% CABLEONE - CABLE ONE, INC. AS17676 647 69 578 89.3% GIGAINFRA Softbank BB Corp. AS855 633 57 576 91.0% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS8151 1185 616 569 48.0% Uninet S.A. de C.V. AS7552 649 102 547 84.3% VIETEL-AS-AP Vietel Corporation AS22047 566 31 535 94.5% VTR BANDA ANCHA S.A. AS14420 614 97 517 84.2% CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP AS3549 860 352 508 59.1% GBLX Global Crossing Ltd. AS9443 570 75 495 86.8% INTERNETPRIMUS-AS-AP Primus Telecommunications AS4804 571 77 494 86.5% MPX-AS Microplex PTY LTD Total 36886 9211 27675 75.0% Top 30 total Possible Bogus Routes 5.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 5.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 5.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 24.129.192.0/19 AS7922 COMCAST-7922 - Comcast Cable Communications, Inc. 37.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 37.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 37.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 46.227.80.0/21 AS8304 AS8304 ECRITEL Company 46.227.96.0/21 AS12611 RKOM R-KOM Regensburger Telekommunikations GmbH & Co. KG 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.18.224.0/20 AS12129 123NET - 123.Net, Inc. 64.21.192.0/20 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.212.0/22 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.216.0/21 AS11610 INETNEBR-1 - Internet Nebraska Corporation 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 69.6.81.0/24 AS13442 71.19.134.0/23 AS3313 INET-AS I.NET S.p.A. 72.22.32.0/19 AS33150 72.22.61.0/24 AS33150 72.22.62.0/24 AS33150 76.77.32.0/19 AS2828 XO-AS15 - XO Communications 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 96.45.161.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.162.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.163.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.164.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.165.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.166.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.167.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.168.0/21 AS3257 TINET-BACKBONE Tinet SpA 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas 110.173.64.0/19 AS37963 CNNIC-ALIBABA-CN-NET-AP Alibaba (China) Technology Co., Ltd. 113.29.0.0/17 AS3549 GBLX Global Crossing Ltd. 113.29.0.0/20 AS3549 GBLX Global Crossing Ltd. 113.29.16.0/20 AS3549 GBLX Global Crossing Ltd. 113.29.32.0/20 AS3549 GBLX Global Crossing Ltd. 113.29.64.0/20 AS3549 GBLX Global Crossing Ltd. 115.42.28.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.30.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.40.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.42.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.44.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.47.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.48.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.49.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.50.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.51.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.52.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.53.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.54.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.55.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.56.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.57.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.58.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.59.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.61.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.62.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.63.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 116.68.136.0/21 AS28045 Pantel Communications 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 121.54.160.0/24 AS38890 121.54.161.0/24 AS38890 121.54.162.0/24 AS38890 121.54.163.0/24 AS38890 121.54.164.0/24 AS38890 121.54.166.0/24 AS38890 121.54.167.0/24 AS38890 121.200.192.0/24 AS17767 122.200.32.0/20 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 122.200.40.0/21 AS38272 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services Inc. 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 172.12.0.0/18 AS28665 PredialNet Provedor de Internet Ltda. 176.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 176.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 176.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 181.82.176.224/27 AS45976 CNYGE-AS-KR chungcheongnamdo yeongi office of education 181.82.177.0/26 AS45976 CNYGE-AS-KR chungcheongnamdo yeongi office of education 190.102.32.0/20 AS30058 FDCSERVERS - FDCservers.net 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.101.46.0/24 AS6503 Axtel, S.A.B. de C.V. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 196.6.108.0/24 AS5713 SAIX-NET 196.13.201.0/24 AS2018 TENET-1 196.13.202.0/24 AS2018 TENET-1 196.13.203.0/24 AS2018 TENET-1 196.13.204.0/24 AS2018 TENET-1 196.110.105.0/24 AS8513 SKYVISION SkyVision Network Services 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.15.4.0/24 AS4323 TWTC - tw telecom holdings, inc. 198.15.5.0/24 AS4323 TWTC - tw telecom holdings, inc. 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.99.241.0/24 AS11797 AC-NIELSEN-AS AC NIELSEN 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.175.231.0/24 AS19262 VZGNI-TRANSIT - Verizon Online LLC 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 198.182.235.0/24 AS3356 LEVEL3 Level 3 Communications 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 199.185.130.0/23 AS19662 UNISERVE-ONLINE - Uniserve On Line 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.233.92.0/24 AS26896 D102-ITC - Data 102, LLC 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.24.73.0/24 AS26061 Equant Colombia 200.24.78.0/26 AS3549 GBLX Global Crossing Ltd. 200.24.78.64/26 AS3549 GBLX Global Crossing Ltd. 202.1.224.0/24 AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000 202.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.20.108.0/23 AS17885 JKTXLNET-AS-AP PT Excelcomindo Pratama 202.58.113.0/24 AS19161 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.66.128.0/18 AS9584 GENESIS-AP Diyixian.com Limited 202.66.160.0/19 AS9584 GENESIS-AP Diyixian.com Limited 202.66.160.0/20 AS9584 GENESIS-AP Diyixian.com Limited 202.66.176.0/20 AS9584 GENESIS-AP Diyixian.com Limited 202.66.184.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.186.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.188.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.189.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.190.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.133.37.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.146.186.0/24 AS23655 SNAP-NZ-AS Snap Internet Limited 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 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.130.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.131.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.133.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 202.179.144.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.149.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.150.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.18.156.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.22.78.0/24 AS18117 HARBOURMSP-AU-AP Harbour MSP Pty. Ltd 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.27.123.0/24 AS4739 CIX-ADELAIDE-AS Internode Systems Pty Ltd 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.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.142.219.0/24 AS45149 203.175.107.0/24 AS45595 PKTELECOM-AS-PK Pakistan Telecom Company Limited 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.10.232.0/21 AS33150 204.19.14.0/23 AS577 BACOM - Bell Canada 204.209.114.0/24 AS13768 PEER1 - Peer 1 Network Inc. 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.207.148.0/23 AS812 ROGERS-CABLE - Rogers Cable Communications Inc. 205.210.145.0/24 AS11814 DISTRIBUTEL-AS11814 - DISTRIBUTEL COMMUNICATIONS LTD. 206.72.192.0/23 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 206.72.194.0/23 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 206.123.129.0/24 AS10790 INREACH-AS - InReach Internet 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.188.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.189.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.190.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.191.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.64.200.0/22 AS11730 CIL-ASN - Circle Internet LTD 208.64.240.0/21 AS13871 TELEBYTE-NW - Telebyte NW 208.73.160.0/24 AS32767 208.78.165.0/24 AS16565 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.83.54.0/24 AS23485 SEI-LLC-AS-NUM - SEI LLC 208.89.60.0/22 AS40626 208.92.196.0/22 AS10929 NETELLIGENT - Netelligent Hosting Services Inc. 208.92.199.0/24 AS26198 3MENATWORK - 3Men at Work Integrated Networks, Inc. 208.94.48.0/21 AS19406 TWRS-MA - Towerstream I, Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.141.32.0/19 AS53667 PONYNET - FranTech Solutions 209.165.239.0/24 AS209 ASN-QWEST - Qwest Communications Company, LLC 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.213.1.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 209.213.4.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 216.10.235.0/24 AS13780 NTNCOMMUNICATIONS - NTN 216.10.236.0/24 AS13780 NTNCOMMUNICATIONS - NTN 216.21.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 216.21.196.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.201.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.202.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.206.0/23 AS12251 INVISION - Invision.com, Inc. 216.58.192.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.197.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.200.0/24 AS18530 ISOMEDIA-1 - Isomedia Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.194.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 216.250.112.0/20 AS7296 ALCHEMYNET - Alchemy Communications, Inc. Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org CONFIDENTIALITY NOTICE ======================= This email message and any attachments are for the exclusive use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message along with any attachments, from your computer system. If you are the intended recipient, please be advised that the content of this message is subject to access, review and disclosure by the sender's Email System Administrator. From netfortius at gmail.com Fri Jan 28 16:01:24 2011 From: netfortius at gmail.com (Stefan) Date: Fri, 28 Jan 2011 14:01:24 -0800 Subject: Connectivity status for Egypt In-Reply-To: <535636.53395.qm@web59603.mail.ac4.yahoo.com> References: <535636.53395.qm@web59603.mail.ac4.yahoo.com> Message-ID: <AANLkTimxo-GCj4Wv_naJ3Ck8ab+EK2dwwh7fVg6FrEjG@mail.gmail.com> On Fri, Jan 28, 2011 at 3:44 PM, andrew.wallace <andrew.wallace at rocketmail.com> wrote: > We should be asking the Egyptians to stagger the return of services so that infrastructure isn't affected, when connectivity is deemed to be allowed to come back online. > > Andrew Wallace > > --- > > British IT Security Consultant http://lifehacker.com/5746046/how-to-foil-a-nationwide-internet-shutdown ***Stefan Mititelu http://twitter.com/netfortius http://www.linkedin.com/in/netfortius From michiel at klaver.it Fri Jan 28 16:12:17 2011 From: michiel at klaver.it (Michiel Klaver) Date: Fri, 28 Jan 2011 14:12:17 -0800 Subject: Best current looking glass software builds In-Reply-To: <002701cbbf09$8b658c10$a230a430$@unwiredltd.com> References: <002701cbbf09$8b658c10$a230a430$@unwiredltd.com> Message-ID: <4D433F41.2050709@klaver.it> At 22-07-2011 20:59, Peter Kranz wrote: > Anyone done a recent scan of newer looking glass software implementations > for apache? We've used cougar's for several years, but have been problems > with its SSH implementation lately. > Development of the Version6 LookingGlass can be found here, the latest version also supports proper SSH-v2: https://github.com/Cougar/lg From web at typo.org Fri Jan 28 16:15:24 2011 From: web at typo.org (Wayne E. Bouchard) Date: Fri, 28 Jan 2011 14:15:24 -0800 Subject: Connectivity status for Egypt In-Reply-To: <AANLkTi=xVx8-Sz=ww4AmumX9grsQPHOkPTa_AWph00VP@mail.gmail.com> References: <535636.53395.qm@web59603.mail.ac4.yahoo.com> <AANLkTi=xVx8-Sz=ww4AmumX9grsQPHOkPTa_AWph00VP@mail.gmail.com> Message-ID: <20110128221524.GA47761@typo.org> On Fri, Jan 28, 2011 at 02:07:51PM -0800, Bill Stewart wrote: > On 1/28/11, andrew.wallace <andrew.wallace at rocketmail.com> wrote: > > We should be asking the Egyptians to stagger the return of services so that > > infrastructure isn't affected, when connectivity is deemed to be allowed to > > come back online. > > Well, yeah, it has to be done carefully, otherwise the first guy to > turn on an E1 line that announces routes for the entire country is > going to have his router overheat and the blue smoke get out.... If > we're lucky, the Army won't damage too much as they either win or > lose. It depends on what remains functional after the fact. If there is no demand for traffic, then routes will be stable and the session will stay active. If the link fills, the session bounces as packets get dropped. It also depends on whether the person turning up that first E1 actually has much behind them and whether those people have much connectivity that doesn't require shrapnel removal. --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From web at typo.org Fri Jan 28 16:15:24 2011 From: web at typo.org (Wayne E. Bouchard) Date: Fri, 28 Jan 2011 14:15:24 -0800 Subject: Connectivity status for Egypt In-Reply-To: <AANLkTi=xVx8-Sz=ww4AmumX9grsQPHOkPTa_AWph00VP@mail.gmail.com> References: <535636.53395.qm@web59603.mail.ac4.yahoo.com> <AANLkTi=xVx8-Sz=ww4AmumX9grsQPHOkPTa_AWph00VP@mail.gmail.com> Message-ID: <20110128221524.GA47761@typo.org> On Fri, Jan 28, 2011 at 02:07:51PM -0800, Bill Stewart wrote: > On 1/28/11, andrew.wallace <andrew.wallace at rocketmail.com> wrote: > > We should be asking the Egyptians to stagger the return of services so that > > infrastructure isn't affected, when connectivity is deemed to be allowed to > > come back online. > > Well, yeah, it has to be done carefully, otherwise the first guy to > turn on an E1 line that announces routes for the entire country is > going to have his router overheat and the blue smoke get out.... If > we're lucky, the Army won't damage too much as they either win or > lose. It depends on what remains functional after the fact. If there is no demand for traffic, then routes will be stable and the session will stay active. If the link fills, the session bounces as packets get dropped. It also depends on whether the person turning up that first E1 actually has much behind them and whether those people have much connectivity that doesn't require shrapnel removal. --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From deleskie at gmail.com Fri Jan 28 16:32:39 2011 From: deleskie at gmail.com (jim deleskie) Date: Fri, 28 Jan 2011 14:32:39 -0800 Subject: Connectivity status for Egypt In-Reply-To: <AANLkTimH-Ng6dpZbLVMFnAO8pf24w_DaQNjyoLyTUCq2@mail.gmail.com> References: <AANLkTimUaNCRFhQqBTPM6Z=W7WUfU8fZUFHGjbqXGJsq@mail.gmail.com> <4D421BB4.1000909@toonk.nl> <9CCC7D46-D578-4BA0-893C-BAE0D170253B@gmail.com> <4D4266DD.7000906@gmail.com> <1296200640.3123.3.camel@Decaf.NEEBU.Net> <AANLkTi=BrQ_m1ypzObszR8_Ta9hPuz_gw-x7ZJYqknJh@mail.gmail.com> <4D432C36.5070404@sneep.net> <AANLkTimH-Ng6dpZbLVMFnAO8pf24w_DaQNjyoLyTUCq2@mail.gmail.com> Message-ID: <AANLkTik=k_qQ22=2yzO-ZYMgyTaO4_t7C8OhXC4ucfX1@mail.gmail.com> iMCI or WCOM? :) On Fri, Jan 28, 2011 at 5:18 PM, Christopher Morrow <morrowc.lists at gmail.com > wrote: > On Fri, Jan 28, 2011 at 3:51 PM, Alastair Johnson <aj at sneep.net> wrote: > > > For instance, our corporate WAN links into Cairo are still up (UUNET > PIP). > > <cough> that's the MCI PIP</cough>... > > From cidr-report at potaroo.net Fri Jan 28 16:00:02 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 28 Jan 2011 14:00:02 -0800 Subject: BGP Update Report Message-ID: <201101282200.p0SM02QR068968@wattle.apnic.net> BGP Update Report Interval: 20-Jan-11 -to- 27-Jan-11 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS32528 18632 1.3% 6210.7 -- ABBOTT Abbot Labs 2 - AS1785 18374 1.3% 10.4 -- AS-PAETEC-NET - PaeTec Communications, Inc. 3 - AS18025 16571 1.2% 460.3 -- ACE-1-WIFI-AS-AP Ace-1 Wifi Network 4 - AS35931 15587 1.1% 5195.7 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 5 - AS8452 15525 1.1% 9.4 -- TE-AS TE-AS 6 - AS33475 12203 0.9% 56.8 -- RSN-1 - RockSolid Network, Inc. 7 - AS23700 12199 0.9% 27.4 -- BM-AS-ID PT. Broadband Multimedia, Tbk 8 - AS9498 12187 0.9% 17.8 -- BBIL-AP BHARTI Airtel Ltd. 9 - AS24923 11360 0.8% 2840.0 -- SETTC South-East Transtelecom Joint Stock Co. 10 - AS24863 11133 0.8% 11.6 -- LINKdotNET-AS 11 - AS9829 10876 0.8% 28.2 -- BSNL-NIB National Internet Backbone 12 - AS15105 10194 0.7% 37.9 -- NETWORKTELEPHONE - Network Telephone Corporation 13 - AS25019 9838 0.7% 44.1 -- SAUDINETSTC-AS Autonomus System Number for SaudiNet 14 - AS17974 8548 0.6% 11.5 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 15 - AS6316 8282 0.6% 77.4 -- AS-PAETEC-NET - PaeTec Communications, Inc. 16 - AS36992 7722 0.5% 11.5 -- ETISALAT-MISR 17 - AS28573 7694 0.5% 12.1 -- NET Servicos de Comunicao S.A. 18 - AS30969 7082 0.5% 120.0 -- 19 - AS14420 6938 0.5% 11.3 -- CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP 20 - AS9198 6384 0.5% 14.0 -- KAZTELECOM-AS JSC Kazakhtelecom TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS32528 18632 1.3% 6210.7 -- ABBOTT Abbot Labs 2 - AS6401 5855 0.4% 5855.0 -- ALLST-6401 - Allstream Corp. 3 - AS35931 15587 1.1% 5195.7 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 4 - AS24923 11360 0.8% 2840.0 -- SETTC South-East Transtelecom Joint Stock Co. 5 - AS49776 2103 0.1% 2103.0 -- GORSET-AS Gorodskaya Set Ltd. 6 - AS49600 1504 0.1% 1504.0 -- LASEDA La Seda de Barcelona, S.A 7 - AS28175 1494 0.1% 1494.0 -- 8 - AS34239 1422 0.1% 1422.0 -- INTERAMERICAN General Insurance Company 9 - AS27771 2682 0.2% 1341.0 -- Instituto Venezolano de Investigaciones Cientificas 10 - AS40772 2648 0.2% 1324.0 -- VELOCITER-WIRELESS-INC - Velociter Wireless, Inc. 11 - AS36383 1764 0.1% 882.0 -- TRABERTECHNOLOGIES-NETWORK - Traber Technologies Inc. 12 - AS35914 1763 0.1% 881.5 -- FIREHOST-INC - FireHost, Inc. 13 - AS43605 659 0.1% 659.0 -- STRK-NET JSC STRK 14 - AS17408 3268 0.2% 653.6 -- ABOVE-AS-AP AboveNet Communications Taiwan 15 - AS9929 4377 0.3% 625.3 -- CNCNET-CN China Netcom Corp. 16 - AS4454 582 0.0% 582.0 -- TNET-AS - State of Tennessee 17 - AS45550 516 0.0% 516.0 -- NGT-AS-VN New Generations Telecommunications Corporation 18 - AS40168 488 0.0% 488.0 -- TOYOTA-PR - Toyota de Puerto Rico Corp. 19 - AS3 957 0.1% 333.0 -- VP-NET-SE Videoplaza AB 20 - AS18025 16571 1.2% 460.3 -- ACE-1-WIFI-AS-AP Ace-1 Wifi Network TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 213.129.96.0/19 11343 0.8% AS24923 -- SETTC South-East Transtelecom Joint Stock Co. 2 - 63.211.68.0/22 10105 0.7% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 3 - 130.36.34.0/24 9317 0.6% AS32528 -- ABBOTT Abbot Labs 4 - 130.36.35.0/24 9314 0.6% AS32528 -- ABBOTT Abbot Labs 5 - 216.126.136.0/22 7442 0.5% AS6316 -- AS-PAETEC-NET - PaeTec Communications, Inc. 6 - 159.18.255.0/24 5855 0.4% AS6401 -- ALLST-6401 - Allstream Corp. 7 - 198.140.43.0/24 5436 0.4% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 8 - 68.65.152.0/22 3700 0.2% AS11915 -- TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 9 - 67.210.226.0/24 3495 0.2% AS35914 -- FIREHOST-INC - FireHost, Inc. AS7819 -- GLOBAL-IP-NETWORKS - Global IP Networks INC 10 - 202.153.174.0/24 3254 0.2% AS17408 -- ABOVE-AS-AP AboveNet Communications Taiwan 11 - 27.123.248.0/22 3215 0.2% AS18025 -- ACE-1-WIFI-AS-AP Ace-1 Wifi Network 12 - 182.54.140.0/22 3210 0.2% AS18025 -- ACE-1-WIFI-AS-AP Ace-1 Wifi Network 13 - 182.54.148.0/22 3210 0.2% AS18025 -- ACE-1-WIFI-AS-AP Ace-1 Wifi Network 14 - 101.78.20.0/22 3199 0.2% AS18025 -- ACE-1-WIFI-AS-AP Ace-1 Wifi Network 15 - 101.78.24.0/22 3198 0.2% AS18025 -- ACE-1-WIFI-AS-AP Ace-1 Wifi Network 16 - 206.184.16.0/24 3190 0.2% AS174 -- COGENT Cogent/PSI 17 - 76.74.88.0/23 2430 0.2% AS6517 -- RELIANCEGLOBALCOM - Reliance Globalcom Services, Inc 18 - 187.86.13.0/24 2246 0.1% AS28135 -- 19 - 213.108.216.0/21 2103 0.1% AS49776 -- GORSET-AS Gorodskaya Set Ltd. 20 - 183.88.0.0/16 2072 0.1% AS45629 -- JASTEL-NETWORK-TH-AP Jasmine International Tower AS45758 -- TRIPLETNET-AS-AP TripleT Internet Internet service provider Bangkok Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org CONFIDENTIALITY NOTICE ======================= This email message and any attachments are for the exclusive use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message along with any attachments, from your computer system. If you are the intended recipient, please be advised that the content of this message is subject to access, review and disclosure by the sender's Email System Administrator. From morrowc.lists at gmail.com Fri Jan 28 17:06:03 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 28 Jan 2011 15:06:03 -0800 Subject: Connectivity status for Egypt In-Reply-To: <AANLkTik=k_qQ22=2yzO-ZYMgyTaO4_t7C8OhXC4ucfX1@mail.gmail.com> References: <AANLkTimUaNCRFhQqBTPM6Z=W7WUfU8fZUFHGjbqXGJsq@mail.gmail.com> <4D421BB4.1000909@toonk.nl> <9CCC7D46-D578-4BA0-893C-BAE0D170253B@gmail.com> <4D4266DD.7000906@gmail.com> <1296200640.3123.3.camel@Decaf.NEEBU.Net> <AANLkTi=BrQ_m1ypzObszR8_Ta9hPuz_gw-x7ZJYqknJh@mail.gmail.com> <4D432C36.5070404@sneep.net> <AANLkTimH-Ng6dpZbLVMFnAO8pf24w_DaQNjyoLyTUCq2@mail.gmail.com> <AANLkTik=k_qQ22=2yzO-ZYMgyTaO4_t7C8OhXC4ucfX1@mail.gmail.com> Message-ID: <AANLkTinGvhL9AUjP1HnU-+zLGmVmMyBCmYFZ+5-kkQpO@mail.gmail.com> On Fri, Jan 28, 2011 at 5:32 PM, jim deleskie <deleskie at gmail.com> wrote: > iMCI or WCOM? :) w (technically the folks that engineered it were mci folk... from texas. > On Fri, Jan 28, 2011 at 5:18 PM, Christopher Morrow > <morrowc.lists at gmail.com> wrote: >> >> On Fri, Jan 28, 2011 at 3:51 PM, Alastair Johnson <aj at sneep.net> wrote: >> >> > For instance, our corporate WAN links into Cairo are still up (UUNET >> > PIP). >> >> <cough> that's the MCI PIP</cough>... >> > > From morrowc.lists at gmail.com Fri Jan 28 17:06:03 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 28 Jan 2011 15:06:03 -0800 Subject: Connectivity status for Egypt In-Reply-To: <AANLkTik=k_qQ22=2yzO-ZYMgyTaO4_t7C8OhXC4ucfX1@mail.gmail.com> References: <AANLkTimUaNCRFhQqBTPM6Z=W7WUfU8fZUFHGjbqXGJsq@mail.gmail.com> <4D421BB4.1000909@toonk.nl> <9CCC7D46-D578-4BA0-893C-BAE0D170253B@gmail.com> <4D4266DD.7000906@gmail.com> <1296200640.3123.3.camel@Decaf.NEEBU.Net> <AANLkTi=BrQ_m1ypzObszR8_Ta9hPuz_gw-x7ZJYqknJh@mail.gmail.com> <4D432C36.5070404@sneep.net> <AANLkTimH-Ng6dpZbLVMFnAO8pf24w_DaQNjyoLyTUCq2@mail.gmail.com> <AANLkTik=k_qQ22=2yzO-ZYMgyTaO4_t7C8OhXC4ucfX1@mail.gmail.com> Message-ID: <AANLkTinGvhL9AUjP1HnU-+zLGmVmMyBCmYFZ+5-kkQpO@mail.gmail.com> On Fri, Jan 28, 2011 at 5:32 PM, jim deleskie <deleskie at gmail.com> wrote: > iMCI or WCOM? :) w (technically the folks that engineered it were mci folk... from texas. > On Fri, Jan 28, 2011 at 5:18 PM, Christopher Morrow > <morrowc.lists at gmail.com> wrote: >> >> On Fri, Jan 28, 2011 at 3:51 PM, Alastair Johnson <aj at sneep.net> wrote: >> >> > For instance, our corporate WAN links into Cairo are still up (UUNET >> > PIP). >> >> <cough> that's the MCI PIP</cough>... >> > > From brunner at nic-naa.net Fri Jan 28 18:12:36 2011 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Fri, 28 Jan 2011 16:12:36 -0800 Subject: in case of prefix withdrawal, dial-out In-Reply-To: <AANLkTinGvhL9AUjP1HnU-+zLGmVmMyBCmYFZ+5-kkQpO@mail.gmail.com> References: <AANLkTimUaNCRFhQqBTPM6Z=W7WUfU8fZUFHGjbqXGJsq@mail.gmail.com> <4D421BB4.1000909@toonk.nl> <9CCC7D46-D578-4BA0-893C-BAE0D170253B@gmail.com> <4D4266DD.7000906@gmail.com> <1296200640.3123.3.camel@Decaf.NEEBU.Net> <AANLkTi=BrQ_m1ypzObszR8_Ta9hPuz_gw-x7ZJYqknJh@mail.gmail.com> <4D432C36.5070404@sneep.net> <AANLkTimH-Ng6dpZbLVMFnAO8pf24w_DaQNjyoLyTUCq2@mail.gmail.com> <AANLkTik=k_qQ22=2yzO-ZYMgyTaO4_t7C8OhXC4ucfX1@mail.gmail.com> <AANLkTinGvhL9AUjP1HnU-+zLGmVmMyBCmYFZ+5-kkQpO@mail.gmail.com> Message-ID: <4D435B74.3000307@nic-naa.net> It is my son's turn to have the laptop so I won't bother to translate. The non-francophones can use Google's auto-xlate bot. http://www.lemonde.fr/technologies/article/2011/01/28/pour-contourner-le-blocage-du-web-les-modems-56k_1471819_651865.html CONFIDENTIALITY NOTICE ======================= This email message and any attachments are for the exclusive use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message along with any attachments, from your computer system. If you are the intended recipient, please be advised that the content of this message is subject to access, review and disclosure by the sender's Email System Administrator. From blake at ispn.net Fri Jan 28 17:29:04 2011 From: blake at ispn.net (Blake Hudson) Date: Fri, 28 Jan 2011 15:29:04 -0800 Subject: test-ipv6.com In-Reply-To: <alpine.BSF.2.00.1101271448000.15852@goat.gigo.com> References: <alpine.BSF.2.00.1101271448000.15852@goat.gigo.com> Message-ID: <4D435140.7020207@ispn.net> Does this site have an AAAA record? If so, my DNS does not pick it up. > [root at ns1 ~]# dig AAAA test-ipv6.com > > ; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 <<>> AAAA test-ipv6.com > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12875 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;test-ipv6.com. IN AAAA > > ;; AUTHORITY SECTION: > test-ipv6.com. 360 IN SOA ns1.gigo.com. > root.ns1.gigo.com. 2011010101 86400 7200 3600000 172800 > > ;; Query time: 216 msec > ;; SERVER: 64.35.208.1#53(64.35.208.1) > ;; WHEN: Fri Jan 28 17:27:20 2011 > ;; MSG SIZE rcvd: 81 > > [root at ns1 ~]# dig AAAA www.test-ipv6.com > > ; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 <<>> AAAA www.test-ipv6.com > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12788 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;www.test-ipv6.com. IN AAAA > > ;; ANSWER SECTION: > www.test-ipv6.com. 360 IN CNAME test-ipv6.com. > > ;; AUTHORITY SECTION: > test-ipv6.com. 355 IN SOA ns1.gigo.com. > root.ns1.gigo.com. 2011010101 86400 7200 3600000 172800 > > ;; Query time: 59 msec > ;; SERVER: 64.35.208.1#53(64.35.208.1) > ;; WHEN: Fri Jan 28 17:27:25 2011 > ;; MSG SIZE rcvd: 99 -------- Original Message -------- Subject: test-ipv6.com From: Jason Fesler <jfesler at gigo.com> To: nanog at nanog.org Date: Thursday, January 27, 2011 5:08:43 PM > Several people have suggested I (re)post information about > test-ipv6.com here. > > http://test-ipv6.com .. > tests ipv4 and ipv6 by dns name > tests dual stack (will the client break on World IPv6 Day?) > tests ipv6 by IP literal (teredo can pass this) > gives advice to end user about current status and (depending on > circumstances) more information > "broken" users (can't connect to dual stack) are solicited for info > Caution: does depend on javascript. > > http://test-ipv6.com/simple_test.html > Eyeball test only for user, with instructions; no javascript required. > > Please direct any comments, flames, etc directly to me instead of the > list. I've added enough noise already :-) > > From nonobvious at gmail.com Fri Jan 28 18:02:58 2011 From: nonobvious at gmail.com (Bill Stewart) Date: Fri, 28 Jan 2011 16:02:58 -0800 Subject: Ipv6 for the content provider In-Reply-To: <024EC9AD-2FD3-406A-A3DA-868152F33187@delong.com> References: <4D406670.8040202@knownelement.com> <5A6D953473350C4B9995546AFE9939EE0BC1361D@RWC-EX1.corp.seven.com> <024EC9AD-2FD3-406A-A3DA-868152F33187@delong.com> Message-ID: <AANLkTin+atGQ+2JDJhzU0m2QZbTzQkSU_KcDwfTcbBaK@mail.gmail.com> On 1/26/11, Owen DeLong <owen at delong.com> wrote: > And if your servers behind the LB aren't prepared for it, > you lose a LOT of logging data, geolocation capabilities, > and some other things if you go that route. Of course, anybody expecting a current IPv4 geolocation service to provide accurate information over IPv6 over the next couple of years is wildly optimistic (with all due respect to people in that business, but just sayin' good luck with that...) Maybe you'll get some consistency about which continent they're on based on the RIR the addresses came from, but even that's probably dodgy if the address belongs to Hurricane Electric or Sixxs or some other popular tunnel broker, and maybe you'll get some consistency on "is it the same /56 as last time?", and maybe some of them will start doing tricks like putting web bugs for "ipv4tracker.geolocator-example.com" and "ipv6tracker.geolocator-example.com" on the same web pages to try to start building correlation information, and if course you need your application that uses the information to speak IPv6 and handle 128-bit records and not just 32-bit. -- ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it. From nonobvious at gmail.com Fri Jan 28 18:16:08 2011 From: nonobvious at gmail.com (Bill Stewart) Date: Fri, 28 Jan 2011 16:16:08 -0800 Subject: DSL options in NYC for OOB access In-Reply-To: <4D3DF769.7060601@nexus6.co.za> References: <4D3DF769.7060601@nexus6.co.za> Message-ID: <AANLkTinBEjrL6iwm1xYujA0OZiqGzfRwgXRM_b9D6Y0=@mail.gmail.com> On 1/24/11, Andy Ashley <lists at nexus6.co.za> wrote: > Im looking for a little advice about DSL circuits in New York, > specifically at 111 8th Ave. > Going to locate a console server there for out-of-band serial management. > The router will need connectivity for remote telnet/ssh access from the NOC. How much bandwidth do you need? Is a dialup modem fast enough? Traditional phone lines often give you a much different set of reliability issues and common-mode failures than Internet connectivity, which is good. I've been very happy with Pushkablue's dialup out-of-band boxes, which give you a serial console and power supply relays. Similarly, if wireless works in the part of the building you're in, and if the building allows you to have equipment that transmits radio signals (some colos don't), that's another option, again, because it's going to have different failures than the equipment you're controlling. > I searched some obvious providers but dont really want to deal with a > huge company (Verizon, Qwest, ?) if it can be avoided. ... > Are there smaller/independent companies out there offering > this sort of thing? > I dont know much about the US DSL market, so any hints are welcome. If you don't know the market, then there's a whole lot of value in dealing with the two or three dominant players for that city, or the two dozen huge companies for the country, as opposed to the hundreds or thousands of small players. (Admittedly, having dealt with ZA's dominant player in a previous job, I'd rather use anybody else also...) -- ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it. From john at sackheads.org Fri Jan 28 18:07:09 2011 From: john at sackheads.org (John Payne) Date: Fri, 28 Jan 2011 16:07:09 -0800 Subject: What's the current state of major access networks in North America ipv6 delivery status? In-Reply-To: <4D409787.8050104@knownelement.com> References: <4D409787.8050104@knownelement.com> Message-ID: <815DAAE1-6FE7-4207-A1DE-36780533F197@sackheads.org> On Jan 26, 2011, at 4:52 PM, Charles N Wyble <charles at knownelement.com> wrote: > Comcast is currently conducting trials: > http://comcast6.net/ (anyone participated in this?) Yes, and other than the fact that their 6rd implementation only gives me a /64, I've been really happy with it. My wife doesn't even know that her iOS devices and win7 box are dual stacked :) From shadowedstranger at gmail.com Fri Jan 28 14:35:43 2011 From: shadowedstranger at gmail.com (Jacob Broussard) Date: Fri, 28 Jan 2011 12:35:43 -0800 Subject: Bogons In-Reply-To: <03AF91C1-A63E-47B2-9C15-BFDC1965EA95@sackheads.org> References: <F6427296-2D81-40A2-B578-95BD27B8CE35@sackheads.org> <A28DCA86-6934-4ABE-B2E9-B951B013D44F@sackheads.org> <5A6D953473350C4B9995546AFE9939EE0BC136D4@RWC-EX1.corp.seven.com> <03AF91C1-A63E-47B2-9C15-BFDC1965EA95@sackheads.org> Message-ID: <AANLkTimzEvNKw9CSOeS+RHPxXPuNFWKV8fF1rM7aoCN8@mail.gmail.com> Static bogons are the bane of my existence... The pain of trying to explain to someone for MONTHS that they haven't updated their reference, with traceroutes to back it up, and they continue to say that it has something to do with my network. On Jan 28, 2011 12:24 PM, "John Payne" <john at sackheads.org> wrote: > > On Jan 28, 2011, at 3:14 PM, George Bonser wrote: > >> >> >>> Now that the holidays are over and IANA v4 depletion is likely days >>> away, perhaps its time to consider stripping your bogon lists down to >>> the bare minimum, and as someone else said, declare bogons dead and >>> move to martians? >>> >>> >>> Just sayin' >>> >> >> There are still some 7,000 prefixes in the v4 "full bogons" list. These >> are such things as allocations to RIR's but have not yet been allocated. >> It's updated every four hours: >> >> >> >> http://www.team-cymru.org/Services/Bogons/fullbogons-ipv4.txt >> >> " The traditional bogon prefixes, plus prefixes that have been >> allocated to RIRs but not yet assigned by those RIRs to ISPs, end-users, >> etc. Updated every four hours." >> >> That is one probably best taken by BGP feed and not done manually. > > Yes, I was referring to static/manual bogon list. The Cymru BGP feed rocks. > > From shadowedstranger at gmail.com Fri Jan 28 14:35:43 2011 From: shadowedstranger at gmail.com (Jacob Broussard) Date: Fri, 28 Jan 2011 12:35:43 -0800 Subject: Bogons In-Reply-To: <03AF91C1-A63E-47B2-9C15-BFDC1965EA95@sackheads.org> References: <F6427296-2D81-40A2-B578-95BD27B8CE35@sackheads.org> <A28DCA86-6934-4ABE-B2E9-B951B013D44F@sackheads.org> <5A6D953473350C4B9995546AFE9939EE0BC136D4@RWC-EX1.corp.seven.com> <03AF91C1-A63E-47B2-9C15-BFDC1965EA95@sackheads.org> Message-ID: <AANLkTimzEvNKw9CSOeS+RHPxXPuNFWKV8fF1rM7aoCN8@mail.gmail.com> Static bogons are the bane of my existence... The pain of trying to explain to someone for MONTHS that they haven't updated their reference, with traceroutes to back it up, and they continue to say that it has something to do with my network. On Jan 28, 2011 12:24 PM, "John Payne" <john at sackheads.org> wrote: > > On Jan 28, 2011, at 3:14 PM, George Bonser wrote: > >> >> >>> Now that the holidays are over and IANA v4 depletion is likely days >>> away, perhaps its time to consider stripping your bogon lists down to >>> the bare minimum, and as someone else said, declare bogons dead and >>> move to martians? >>> >>> >>> Just sayin' >>> >> >> There are still some 7,000 prefixes in the v4 "full bogons" list. These >> are such things as allocations to RIR's but have not yet been allocated. >> It's updated every four hours: >> >> >> >> http://www.team-cymru.org/Services/Bogons/fullbogons-ipv4.txt >> >> " The traditional bogon prefixes, plus prefixes that have been >> allocated to RIRs but not yet assigned by those RIRs to ISPs, end-users, >> etc. Updated every four hours." >> >> That is one probably best taken by BGP feed and not done manually. > > Yes, I was referring to static/manual bogon list. The Cymru BGP feed rocks. > > From mpalmer at hezmatt.org Fri Jan 28 19:41:39 2011 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Fri, 28 Jan 2011 17:41:39 -0800 Subject: Bogons In-Reply-To: <AANLkTimzEvNKw9CSOeS+RHPxXPuNFWKV8fF1rM7aoCN8@mail.gmail.com> References: <F6427296-2D81-40A2-B578-95BD27B8CE35@sackheads.org> <A28DCA86-6934-4ABE-B2E9-B951B013D44F@sackheads.org> <5A6D953473350C4B9995546AFE9939EE0BC136D4@RWC-EX1.corp.seven.com> <03AF91C1-A63E-47B2-9C15-BFDC1965EA95@sackheads.org> <AANLkTimzEvNKw9CSOeS+RHPxXPuNFWKV8fF1rM7aoCN8@mail.gmail.com> Message-ID: <20110129014139.GJ3684@hezmatt.org> On Fri, Jan 28, 2011 at 12:35:43PM -0800, Jacob Broussard wrote: > Static bogons are the bane of my existence... The pain of trying to explain > to someone for MONTHS that they haven't updated their reference, with > traceroutes to back it up, and they continue to say that it has something to > do with my network. THey're right -- your network is using an address range they've chosen to configure their equipment not to accept... <grin> - Matt From mpalmer at hezmatt.org Fri Jan 28 19:41:39 2011 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Fri, 28 Jan 2011 17:41:39 -0800 Subject: Bogons In-Reply-To: <AANLkTimzEvNKw9CSOeS+RHPxXPuNFWKV8fF1rM7aoCN8@mail.gmail.com> References: <F6427296-2D81-40A2-B578-95BD27B8CE35@sackheads.org> <A28DCA86-6934-4ABE-B2E9-B951B013D44F@sackheads.org> <5A6D953473350C4B9995546AFE9939EE0BC136D4@RWC-EX1.corp.seven.com> <03AF91C1-A63E-47B2-9C15-BFDC1965EA95@sackheads.org> <AANLkTimzEvNKw9CSOeS+RHPxXPuNFWKV8fF1rM7aoCN8@mail.gmail.com> Message-ID: <20110129014139.GJ3684@hezmatt.org> On Fri, Jan 28, 2011 at 12:35:43PM -0800, Jacob Broussard wrote: > Static bogons are the bane of my existence... The pain of trying to explain > to someone for MONTHS that they haven't updated their reference, with > traceroutes to back it up, and they continue to say that it has something to > do with my network. THey're right -- your network is using an address range they've chosen to configure their equipment not to accept... <grin> - Matt From bensons at queuefull.net Fri Jan 28 19:47:42 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Fri, 28 Jan 2011 17:47:42 -0800 Subject: Connectivity status for Egypt In-Reply-To: <535636.53395.qm@web59603.mail.ac4.yahoo.com> References: <535636.53395.qm@web59603.mail.ac4.yahoo.com> Message-ID: <B15A9CCC-CDC1-4A69-9FE5-D2084D646CBA@queuefull.net> On Jan 28, 2011, at 1:44 PM, andrew.wallace wrote: > We should be asking the Egyptians to stagger the return of services so that infrastructure isn't affected, when connectivity is deemed to be allowed to come back online. > > Andrew Wallace > > --- > > British IT Security Consultant You should send them an email about that. From mbassett at intelius.com Fri Jan 28 19:39:26 2011 From: mbassett at intelius.com (Mark Bassett) Date: Fri, 28 Jan 2011 17:39:26 -0800 Subject: Upload config to juniper In-Reply-To: <AANLkTi=R6bTmpBtj=oUbyDuCG8xC-cMgEJodRhSxbTFh@mail.gmail.com> References: <AANLkTinEpsHaVcro9io3gCpHeCKwpNHg9zBSAY+7oZKJ@mail.gmail.com> <AANLkTi=R6bTmpBtj=oUbyDuCG8xC-cMgEJodRhSxbTFh@mail.gmail.com> Message-ID: <8E80582D6651CB47BE5B9CE81D63D0480D09D5F8@exchange2.intelius1.intelius.com> Actually if you use the JUNOS api and the reference scripts there are examples to do just this. -----Original Message----- From: Jimmy Hess [mailto:mysidia at gmail.com] Sent: Wednesday, January 26, 2011 6:31 PM To: Florin Veres Cc: nanog at nanog.org Subject: Re: Upload config to juniper On Mon, Jan 24, 2011 at 7:39 AM, Florin Veres <florin at futurefreedom.ro> wrote: > Hey guys, > Do any of you have any idea if it's possible to upload configuration from a > script (prefix-list updates in this case) to a JunOS device (MX)? > For Cisco devices I'm doing it using rcp. >From config mode use a "load merge" command that specifies a SCP or FTP URL. You'll need to setup SSH keys in advance to do so without an additional password for the device to download the script. Alternatively... SCP the file to a temporary file on the device then "load merge" the uploaded file, to merge config from the script. Net::SSH::Expect from CPAN to connect via ssh from perl. Something like use Net::SSH::Perl; use Net::SSH::Expect; my $ssh = Net::SSH::Expect->new( host => 'myfavoritehostname.example.com', user => 'blahblahblah', password => '1234', raw_pty => 1); $ssh->login(q[blahblah at myfavoritehostname.example.com's password]); $output1 = $ssh->exec("configure private"); # $blah = $ssh->exec("load merge username at scriptserver.example.com:/path/to/scriptfile_to_load.txt"); print scalar $ssh->exec("show | compare"); # commit -- -JH From fasterfourier at gmail.com Fri Jan 28 23:48:50 2011 From: fasterfourier at gmail.com (Robert Johnson) Date: Fri, 28 Jan 2011 21:48:50 -0800 Subject: Need provider suggestions - BGP transit over GRE tunnel In-Reply-To: <alpine.DEB.1.10.1101281733070.20241@sisler> References: <AANLkTikCHuobbeWyyk1Nng_+FE1DcDZwFFupfmUsBDs_@mail.gmail.com> <alpine.DEB.1.10.1101281733070.20241@sisler> Message-ID: <AANLkTimrNWBby0esM4+bz8pGq+J1D3OeMBV6wDUKhe9X@mail.gmail.com> My network spans a multicity geographic area using microwave radio links. The point of the GRE tunnel is to allow me to establish a BGP session to another AS using a consumer grade Internet connection (cheap) over the public Internet. I don't want to build out additional microwave paths to a new datacenter to become multihomed. On Fri, Jan 28, 2011 at 5:36 PM, C. Jon Larsen <jlarsen at richweb.com> wrote: > > I have read your email a few times and i dont see how this makes sense. > > Why do you need a public AS and PI space? Your gre tunnel wont need it or be > able to use it. A gre tunnel is just a replacement for a physical pipe. > > If your datacenter based presence goes down, you will need a pipe at your > office, or some other location speaking bgp that can annouce your block > anyway. > > > > > On Fri, 28 Jan 2011, Robert Johnson wrote: > >> My organization is planning to become multihomed in the near future. >> Currently we have redundant (router and physical path) links to a >> single AS where we get our transit, and speak BGP to them using a >> private ASN. This configuration has not been meeting our reliability >> requirements, so we will be getting our own ASN from ARIN, and moving >> from PA to PI IP space. >> >> Our new provider will be used for backup purposes only. We would like >> to minimize the monthly cost of this connection; to do this, we are >> planning to use a VZ business FIOS connection with symmetrical >> bandwidth to establish a GRE tunnel to a datacenter somewhere, and >> bring up a BGP session over that tunnel. I'd like to know if there are >> providers that offer such a service on a regular basis, and if so, if >> anyone is doing this and has words of wisdom. >> >> Thanks in advance. >> >> >> -- >> This message has been scanned for viruses and >> dangerous content by the Richweb.com MailScanner, and is >> believed to be clean. >> >> >> > From owen at delong.com Sat Jan 29 03:13:40 2011 From: owen at delong.com (Owen DeLong) Date: Sat, 29 Jan 2011 01:13:40 -0800 Subject: Fwd: [listname] Fwd: Connectivity status for Egypt References: <4D43C792.5090006@sahara.com.sa> Message-ID: <BA464B90-BDFE-4AF7-8B57-AFB9325CC16F@delong.com> Anonymized because I am forwarding without permission... > > Dears, > > As per what I know from friends: > > 1. All Internet is down. Apparently one network is still working but seems to be serving the stock exchange only and few others. > 2. SMS is down. > 3. Landlines are down (at least internationally). > 4. Mobile networks seem to be on and off depending on location. For example, Vodafone is apparently working in Cairo while other networks are not !! > > God help them and bring Egypt and Egyptians out of this harmless inshallah. > Regards.. Owen From franck at genius.com Sun Jan 30 23:11:14 2011 From: franck at genius.com (Franck Martin) Date: Mon, 31 Jan 2011 18:11:14 +1300 (FJST) Subject: Connectivity status for Egypt In-Reply-To: <B15A9CCC-CDC1-4A69-9FE5-D2084D646CBA@queuefull.net> Message-ID: <11119517.1574.1296450669583.JavaMail.franck@franck-martins-macbook-pro.local> ----- Original Message ----- > From: "Benson Schliesser" <bensons at queuefull.net> > To: "andrew.wallace" <andrew.wallace at rocketmail.com> > Cc: nanog at nanog.org > Sent: Saturday, 29 January, 2011 2:47:42 PM > Subject: Re: Connectivity status for Egypt > On Jan 28, 2011, at 1:44 PM, andrew.wallace wrote: > > > We should be asking the Egyptians to stagger the return of services > > so that infrastructure isn't affected, when connectivity is deemed > > to be allowed to come back online. > > > > > You should send them an email about that. They could be surprised to find their network is already up: http://www.spamhaus.org/sbl/sbl.lasso?query=SBL102595 From millnert at gmail.com Sun Jan 30 23:59:59 2011 From: millnert at gmail.com (Martin Millnert) Date: Mon, 31 Jan 2011 00:59:59 -0500 Subject: Level 3's IRR Database In-Reply-To: <AANLkTi=4ZM3a9MTpjAXVV+WYOEgc6fVwUBPnGHobKr-1@mail.gmail.com> References: <201101302153.VAA20188@sunf10.rd.bbc.co.uk> <AANLkTi=4ZM3a9MTpjAXVV+WYOEgc6fVwUBPnGHobKr-1@mail.gmail.com> Message-ID: <AANLkTi=yCvpQeS-ewq8_rBxjTgHtE6riGq_rZ84uz3Kg@mail.gmail.com> Carlos, On Sun, Jan 30, 2011 at 9:22 PM, Carlos Martinez-Cagnazzo <carlosm3011 at gmail.com> wrote: > Hi, > > this is the second mention I see of RPKI and Egypt in the same > context. I sincerely fail to see the connection between both > situations. > It is quite simple actually. 1. Governments (eventually) want to take pieces of the Internet offline, and Egypt is only the latest abundantly clear proof of this desire. 2. RPKI might make this easier to accomplish than before, effectively leading to more censorship than without it. My fear is that of the big red DELETE-FROM-THE-INTERNET-button: If the system becomes widely deployed, it is an even shorter step to make for various lawmakers in various countries to legislate how RPKI is to be used. There are obviously other ways for your local autocrat to cut the Internet down, but this would undoubtedly add a potential fine-grained mechanism on top of it that I fail to see how it will not be abused. Eg, it'd be possible to, with the right hand, require that all ISPs treats RPKI in a certain way (abstract away the censorship to all ISPs, even those in other countries(!), own routers, once the technology is in place), and with the left hand cherry pick what can be on and what can be off, at a much, much lower cost than unplugging everything (Egypt), or buying lots of cool hardware (China). (This is a bad thing, btw.) I'd happily see an explanation of RPKI that clears these fears from my mind, and I'm fairly sure that I am not crazy for having them... (Meanwhile I will read all of Randy's recommended reading.) And yes there are a myriad of other ways to shut things down from the Internet, but none of them are as integrated with the Internet as RPKI would be, right? Plus, I don't really see adding another way to shut things down as a positive thing, because of the apparent abuse-vector it represents. Regards, Martin (With tiny, tiny steps, nobody will understand how we ended up where we end up, and by then it's hard to retract.) > > On Sun, Jan 30, 2011 at 7:53 PM, Brandon Butterworth > <brandon at rd.bbc.co.uk> wrote: >>> > I think it is too early in the deployment process to start dropping >>> > routes based on RPKI alone. We'll get there at some point, I guess. >>> >>> Do we really *want* to get to that point? >> >> I thought that was the point and the goal of securing the routing >> infrastructure is laudable. But the voices in my head say don't trust >> them with control of your routes, see what happened in Egypt. >> >> brandon >> >> > > > > -- > -- > ========================= > Carlos M. Martinez-Cagnazzo > http://www.labs.lacnic.net > ========================= > > From swmike at swm.pp.se Mon Jan 31 00:58:28 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 31 Jan 2011 07:58:28 +0100 (CET) Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <AANLkTimSpkQZ7pW=jb2KB1pndmKBpkug+WtugzOcUGJP@mail.gmail.com> References: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com> <AANLkTimcZavnJN2gqayS2-piDvOAcw_nrJAREJ0EDTjp@mail.gmail.com> <AANLkTikHBb+cyfPxXftb5QZh136D04fkdWFMy3NFhDdi@mail.gmail.com> <4D3FBEA3.6040404@gont.com.ar> <AANLkTimSpkQZ7pW=jb2KB1pndmKBpkug+WtugzOcUGJP@mail.gmail.com> Message-ID: <alpine.DEB.1.10.1101310755340.13151@uplift.swm.pp.se> On Sun, 30 Jan 2011, Matthew Petach wrote: > Even without completely overflowing the ND cache, informal lab testing > shows that a single laptop on a well-connected network link can send > sufficient packets at a very-large-scale backbone router's connected /64 > subnet to keep the router CPU at 90%, sustained, for as long as you'd > like. So, while it's not a direct denial of service (the network keeps > functioning, albeit under considerable pain), it's enough to impact the > ability of the network to react to other dynamic loads. :/ At AMSIX, a Cisco 12000 running IOS will get into trouble with the 170pps of ND seen there. AMSIX doesn't do MLD snooping so everybody gets everything and on IOS 12000 ND is punted to RP and when it's busy with calculating BGP, it'll start dropping BGP sessions. An access-list filtering IPv6 multicast the router isn't subscribed to fixes the problem. -- Mikael Abrahamsson email: swmike at swm.pp.se From randy at psg.com Mon Jan 31 01:18:06 2011 From: randy at psg.com (Randy Bush) Date: Mon, 31 Jan 2011 16:18:06 +0900 Subject: Level 3's IRR Database In-Reply-To: <4D461B88.8020506@toonk.nl> References: <E65B3ED7E6FCBA48BC3E2FA899729216018E704D@rouwkoop.ac.za> <AANLkTing8yEVoDSxXsa+eTV0xZuv2qkYYA-ahT26hbFx@mail.gmail.com> <4D45CE4A.5090800@foobar.org> <m2sjwa84td.wl%randy@psg.com> <4D461B88.8020506@toonk.nl> Message-ID: <m21v3t8rtd.wl%randy@psg.com> > Based on this draft the recommended preference order is: > > 1) Validation ok > 2) not found > 3) Validation nok > > Suppose an operator would use local-pref to achieve this. > This intention (preferring validated routes) will break, when there's a > more specific announcement that doesn't validate. > For example the youtube incident would not have been stopped by doing this. i do not understand your logic. let's try to show the case 666.42.0.0/16 has a roa for as 777 666.42.1.0/24 has a roa for as 888 an announcement comes for 666.42.1.0/24 originating from as 999. are you implying that it should be marked valid? i sure don't want it to. an announcement for 666.42.0.0/16 from as 777 would still be valid. so i am not sure what your point is. please clarify with a concrete example. randy From carlosm3011 at gmail.com Mon Jan 31 04:29:50 2011 From: carlosm3011 at gmail.com (Carlos M. Martinez) Date: Mon, 31 Jan 2011 08:29:50 -0200 Subject: Level 3's IRR Database In-Reply-To: <AANLkTi=yCvpQeS-ewq8_rBxjTgHtE6riGq_rZ84uz3Kg@mail.gmail.com> References: <201101302153.VAA20188@sunf10.rd.bbc.co.uk> <AANLkTi=4ZM3a9MTpjAXVV+WYOEgc6fVwUBPnGHobKr-1@mail.gmail.com> <AANLkTi=yCvpQeS-ewq8_rBxjTgHtE6riGq_rZ84uz3Kg@mail.gmail.com> Message-ID: <4D468F1E.5020804@gmail.com> Hey Martin, I see your point and I believe it is a concern that should be addressed. tks Carlos On 1/31/11 3:59 AM, Martin Millnert wrote: > Carlos, > > On Sun, Jan 30, 2011 at 9:22 PM, Carlos Martinez-Cagnazzo > <carlosm3011 at gmail.com> wrote: >> Hi, >> >> this is the second mention I see of RPKI and Egypt in the same >> context. I sincerely fail to see the connection between both >> situations. >> > It is quite simple actually. > > 1. Governments (eventually) want to take pieces of the Internet > offline, and Egypt is only the latest abundantly clear proof of this > desire. > 2. RPKI might make this easier to accomplish than before, effectively > leading to more censorship than without it. > > My fear is that of the big red DELETE-FROM-THE-INTERNET-button: > > If the system becomes widely deployed, it is an even shorter step to > make for various lawmakers in various countries to legislate how RPKI > is to be used. > There are obviously other ways for your local autocrat to cut the > Internet down, but this would undoubtedly add a potential fine-grained > mechanism on top of it that I fail to see how it will not be abused. > Eg, it'd be possible to, with the right hand, require that all ISPs > treats RPKI in a certain way (abstract away the censorship to all > ISPs, even those in other countries(!), own routers, once the > technology is in place), and with the left hand cherry pick what can > be on and what can be off, at a much, much lower cost than unplugging > everything (Egypt), or buying lots of cool hardware (China). (This is > a bad thing, btw.) > > I'd happily see an explanation of RPKI that clears these fears from my > mind, and I'm fairly sure that I am not crazy for having them... > (Meanwhile I will read all of Randy's recommended reading.) > And yes there are a myriad of other ways to shut things down from the > Internet, but none of them are as integrated with the Internet as RPKI > would be, right? Plus, I don't really see adding another way to shut > things down as a positive thing, because of the apparent abuse-vector > it represents. > > Regards, > Martin > > (With tiny, tiny steps, nobody will understand how we ended up where > we end up, and by then it's hard to retract.) > >> On Sun, Jan 30, 2011 at 7:53 PM, Brandon Butterworth >> <brandon at rd.bbc.co.uk> wrote: >>>>> I think it is too early in the deployment process to start dropping >>>>> routes based on RPKI alone. We'll get there at some point, I guess. >>>> Do we really *want* to get to that point? >>> I thought that was the point and the goal of securing the routing >>> infrastructure is laudable. But the voices in my head say don't trust >>> them with control of your routes, see what happened in Egypt. >>> >>> brandon >>> >>> >> >> >> -- >> -- >> ========================= >> Carlos M. Martinez-Cagnazzo >> http://www.labs.lacnic.net >> ========================= >> >> From pelle at hemmop.com Mon Jan 31 05:27:43 2011 From: pelle at hemmop.com (Per Carlson) Date: Mon, 31 Jan 2011 12:27:43 +0100 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <alpine.DEB.1.10.1101310755340.13151@uplift.swm.pp.se> References: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com> <AANLkTimcZavnJN2gqayS2-piDvOAcw_nrJAREJ0EDTjp@mail.gmail.com> <AANLkTikHBb+cyfPxXftb5QZh136D04fkdWFMy3NFhDdi@mail.gmail.com> <4D3FBEA3.6040404@gont.com.ar> <AANLkTimSpkQZ7pW=jb2KB1pndmKBpkug+WtugzOcUGJP@mail.gmail.com> <alpine.DEB.1.10.1101310755340.13151@uplift.swm.pp.se> Message-ID: <AANLkTimoEST0ewMy+DZwGqve-jcq0=oNdK_L2oXv6-Ln@mail.gmail.com> > At AMSIX, a Cisco 12000 running IOS will get into trouble with the 170pps of > ND seen there. AMSIX doesn't do MLD snooping so everybody gets everything > and on IOS 12000 ND is punted to RP and when it's busy with calculating BGP, > it'll start dropping BGP sessions. Really? I've tried to duplicate the results in our lab, but I can't provoke any problems at those numbers. Is it the "other" multicast traffic that's interfering with ND? When pounding the CPU with ~30 times more (5000pps) Neighbour solicitations and flapping 1000 BGP IPv4 prefixes (out of 51000) every 5 seconds, I get the following load (worst case): 12k#sh proc cpu | ex 0.00 CPU utilization for five seconds: 99%/13%; one minute: 83%; five minutes: 76% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 29 19472 7944653 2 0.31% 0.07% 0.05% 0 PowerMgr Main 160 5120 3415 1499 0.47% 0.18% 0.06% 0 Exec 181 17016 76522129 0 0.07% 0.14% 0.15% 0 CEF RP IPC Backg 185 1992892 19727573 101 17.91% 19.36% 20.02% 0 IPv6 Input 213 256008 9155905 27 3.03% 2.80% 2.83% 0 BGP Router 216 3606044 677600 5321 64.31% 45.74% 37.41% 0 BGP Scanner 12k# Even though the load is high, there is no flaps, neither in ISIS, LDP, BFD (3 sessions with 3 x 50 ms asynch mode) nor BGP. When BGP Scanner is not running, the numbers are much lower: martin#sh proc cpu | ex 0.00 CPU utilization for five seconds: 45%/16%; one minute: 82%; five minutes: 76% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 160 5192 3454 1503 0.79% 0.20% 0.08% 0 Exec 181 17068 76522593 0 0.15% 0.15% 0.15% 0 CEF RP IPC Backg 185 2000528 19764701 101 24.79% 19.70% 20.01% 0 IPv6 Input 213 256976 9156110 28 3.03% 2.82% 2.83% 0 BGP Router martin# The hardware in question is a PRP-1 running SY9b, and the same LC (SIP-601/SPA-5x1GE-v2) is used for both ND and BGP. Note: When doing 10000pps ND, the LDP-adjacency with a neighbour on the same LC did flap occasionally. -- Pelle RFC1925, truth 11: ?Every old idea will be proposed again with a different name and ?a different presentation, regardless of whether it works. From jbates at brightok.net Mon Jan 31 07:42:06 2011 From: jbates at brightok.net (Jack Bates) Date: Mon, 31 Jan 2011 07:42:06 -0600 Subject: Level 3's IRR Database In-Reply-To: <m21v3t8rtd.wl%randy@psg.com> References: <E65B3ED7E6FCBA48BC3E2FA899729216018E704D@rouwkoop.ac.za> <AANLkTing8yEVoDSxXsa+eTV0xZuv2qkYYA-ahT26hbFx@mail.gmail.com> <4D45CE4A.5090800@foobar.org> <m2sjwa84td.wl%randy@psg.com> <4D461B88.8020506@toonk.nl> <m21v3t8rtd.wl%randy@psg.com> Message-ID: <4D46BC2E.9040909@brightok.net> On 1/31/2011 1:18 AM, Randy Bush wrote: >> Based on this draft the recommended preference order is: >> >> 1) Validation ok >> 2) not found >> 3) Validation nok >> >> Suppose an operator would use local-pref to achieve this. >> This intention (preferring validated routes) will break, when there's a >> more specific announcement that doesn't validate. >> For example the youtube incident would not have been stopped by doing this. > i do not understand your logic. > > let's try to show the case > > 666.42.0.0/16 has a roa for as 777 > 666.42.1.0/24 has a roa for as 888 > > an announcement comes for 666.42.1.0/24 originating from as 999. are > you implying that it should be marked valid? i sure don't want it to. > > an announcement for 666.42.0.0/16 from as 777 would still be valid. > Andree was saying, 666.42.0.0/16 has a roa for as 777 you start receiving 666.42.0.0/24 and 666.42.1.0/24, both unsigned. Changing preference isn't enough to stop routing, as it's a more specific route and automatically wins if it gets into the table. Jack From mir at ripe.net Mon Jan 31 07:59:31 2011 From: mir at ripe.net (Mirjam Kuehne) Date: Mon, 31 Jan 2011 14:59:31 +0100 Subject: [Fwd: [mat-wg] Visualizing the Egyptian disconnection] Message-ID: <4D46C043.8010003@ripe.net> Hi, See below a link to a visualisation of the Egyptian disconnect using the RIPE NCC Resource EXplainer tool (REX). Mirjam -------- Original Message -------- Subject: [mat-wg] Visualizing the Egyptian disconnection Date: Sun, 30 Jan 2011 18:37:05 -0500 From: Richard L. Barnes <rbarnes at bbn.com> To: mat-wg at ripe.net Hey all, Looking to find some more different ways of looking at the current events in Egypt, I thought the routing graphs that the RIPE REX tool produces could be instructive. I've collated the relevant graphs with some notes on what they show in a brief RIPE Labs article: http://labs.ripe.net/Members/rbarnes/visualizing-the-egyptian-disconnection Best, --Richard From randy at psg.com Mon Jan 31 07:59:54 2011 From: randy at psg.com (Randy Bush) Date: Mon, 31 Jan 2011 22:59:54 +0900 Subject: Level 3's IRR Database In-Reply-To: <4D46BC2E.9040909@brightok.net> References: <E65B3ED7E6FCBA48BC3E2FA899729216018E704D@rouwkoop.ac.za> <AANLkTing8yEVoDSxXsa+eTV0xZuv2qkYYA-ahT26hbFx@mail.gmail.com> <4D45CE4A.5090800@foobar.org> <m2sjwa84td.wl%randy@psg.com> <4D461B88.8020506@toonk.nl> <m21v3t8rtd.wl%randy@psg.com> <4D46BC2E.9040909@brightok.net> Message-ID: <m2wrll5g2t.wl%randy@psg.com> > 666.42.0.0/16 has a roa for as 777 > > you start receiving > > 666.42.0.0/24 and 666.42.1.0/24, both unsigned. Changing preference > isn't enough to stop routing, as it's a more specific route and > automatically wins if it gets into the table. nope when there is no roa for the arriving prefix, a roa for the covering prefix is used. see draft-pmohapat-sidr-pfx-validate-07.txt. randy From randy at psg.com Mon Jan 31 08:16:28 2011 From: randy at psg.com (Randy Bush) Date: Mon, 31 Jan 2011 23:16:28 +0900 Subject: Level 3's IRR Database In-Reply-To: <m2wrll5g2t.wl%randy@psg.com> References: <E65B3ED7E6FCBA48BC3E2FA899729216018E704D@rouwkoop.ac.za> <AANLkTing8yEVoDSxXsa+eTV0xZuv2qkYYA-ahT26hbFx@mail.gmail.com> <4D45CE4A.5090800@foobar.org> <m2sjwa84td.wl%randy@psg.com> <4D461B88.8020506@toonk.nl> <m21v3t8rtd.wl%randy@psg.com> <4D46BC2E.9040909@brightok.net> <m2wrll5g2t.wl%randy@psg.com> Message-ID: <m2vd155fb7.wl%randy@psg.com> > when there is no roa for the arriving prefix, a roa for the covering > prefix is used. see draft-pmohapat-sidr-pfx-validate-07.txt. which, btw, is why draft-ietf-sidr-rpki-origin-ops-04.txt warns Before issuing a ROA for a block, an operator MUST ensure that any sub-allocations from that block which are announced by others (e.g. customers) have ROAs in play. Otherwise, issuing a ROA for the super-block will cause the announcements of sub-allocations with no ROAs to be Invalid. randy From jabley at hopcount.ca Mon Jan 31 08:16:38 2011 From: jabley at hopcount.ca (Joe Abley) Date: Mon, 31 Jan 2011 09:16:38 -0500 Subject: Level 3's IRR Database In-Reply-To: <4D459C96.3080306@foobar.org> References: <E65B3ED7E6FCBA48BC3E2FA899729216018E704D@rouwkoop.ac.za> <AANLkTi=ZhLT0HeWkZ1f57vu6sistskj_rgibEzDiBe3Y@mail.gmail.com> <4D459C96.3080306@foobar.org> Message-ID: <D4D90B71-1078-4796-8FFE-E61DFACED3AC@hopcount.ca> On 2011-01-30, at 12:15, Nick Hilliard wrote: > On 30/01/2011 09:08, Jeff Wheeler wrote: >> This brings me to my point, which is that IRR is very good for >> preventing accidents and automating some common tasks. It should be >> "secure" to a point, but just because a route: object exists does not >> mean that mntner: really has authority over that address space. > > Depends on which IRR you use. The IRRDBs run by RIPE, APNIC and AfriNIC implement hierarchical object ownership, which means that if you're registering their address space, you can only do so if that address space legitimately belongs to you. Note that in the case of the RIPE db (and perhaps the others, I don't know) this is only the case for resources that can be traced back to a RIPE NCC-assigned netblock. I routinely register objects in the RIPE db which were assigned from other regions (e.g. ARIN). Since many European networks have procedures and automation that requires things to be in the RIPE db, using that db as your primary publication mechanism avoids the need to duplicate later. The parent object in the RIPE db for such foreign resources is inetnum: 0.0.0.0 - 255.255.255.255 netname: IANA-BLK descr: The whole IPv4 address space country: EU # Country is really world wide org: ORG-IANA1-RIPE admin-c: IANA1-RIPE tech-c: IANA1-RIPE status: ALLOCATED UNSPECIFIED remarks: The country is really worldwide. remarks: This address space is assigned at various other places in remarks: the world and might therefore not be in the RIPE database. mnt-by: RIPE-NCC-HM-MNT mnt-lower: RIPE-NCC-HM-MNT mnt-routes: RIPE-NCC-RPSL-MNT source: RIPE # Filtered and the maintainer object for routes is mntner: RIPE-NCC-RPSL-MNT descr: This maintainer may be used to create objects to represent descr: routing policy in the RIPE Database for number resources not descr: allocated or assigned from the RIPE NCC. admin-c: RD132-RIPE auth: MD5-PW $1$ScJSM7nN$Xw3aAduCRZx4QUEq8QjR5/ remarks: ******************************************************* remarks: * The password for this object is 'RPSL', without the * remarks: * quotes. Do NOT use this maintainer as 'mnt-by'. * remarks: ******************************************************* mnt-by: RIPE-DBM-MNT referral-by: RIPE-DBM-MNT source: RIPE # Filtered This means that anybody can assert pretty much anything they like, so long as the resources are not NCC-assigned. Joe From jbates at brightok.net Mon Jan 31 08:30:13 2011 From: jbates at brightok.net (Jack Bates) Date: Mon, 31 Jan 2011 08:30:13 -0600 Subject: Level 3's IRR Database In-Reply-To: <m2wrll5g2t.wl%randy@psg.com> References: <E65B3ED7E6FCBA48BC3E2FA899729216018E704D@rouwkoop.ac.za> <AANLkTing8yEVoDSxXsa+eTV0xZuv2qkYYA-ahT26hbFx@mail.gmail.com> <4D45CE4A.5090800@foobar.org> <m2sjwa84td.wl%randy@psg.com> <4D461B88.8020506@toonk.nl> <m21v3t8rtd.wl%randy@psg.com> <4D46BC2E.9040909@brightok.net> <m2wrll5g2t.wl%randy@psg.com> Message-ID: <4D46C775.1030503@brightok.net> On 1/31/2011 7:59 AM, Randy Bush wrote: > when there is no roa for the arriving prefix, a roa for the covering > prefix is used. see draft-pmohapat-sidr-pfx-validate-07.txt. Ahh, very good. I think that was the only concern. Presumably that would invalidate the route and it would be discarded vs deprefed. Jack From aa at tenet.ac.za Mon Jan 31 08:35:19 2011 From: aa at tenet.ac.za (Andrew Alston) Date: Mon, 31 Jan 2011 16:35:19 +0200 Subject: Contact at level 3 RE IRR database? Message-ID: <E65B3ED7E6FCBA48BC3E2FA899729216018E7054@rouwkoop.ac.za> Hi All, I was wondering if anyone had a direct contact at level 3 who deals with their IRR database, since my queries logged with them on Saturday to both noc@ and abuse@ have gone unanswered. I have just taken a look at the following: whois -h whois.radb.net \!gAS11908 and there is a *HUGE* amount of IP space registered in the Level3 IRR database that is propagating to the other databases that clearly does not belong to AS11908. (Beyond the initial prefix of ours that noticed). Thanks Andrew Alston TENET - Chief Technology Officer Phone: +27 21 763 7181 From randy at psg.com Mon Jan 31 08:35:49 2011 From: randy at psg.com (Randy Bush) Date: Mon, 31 Jan 2011 23:35:49 +0900 Subject: Level 3's IRR Database In-Reply-To: <4D46C775.1030503@brightok.net> References: <E65B3ED7E6FCBA48BC3E2FA899729216018E704D@rouwkoop.ac.za> <AANLkTing8yEVoDSxXsa+eTV0xZuv2qkYYA-ahT26hbFx@mail.gmail.com> <4D45CE4A.5090800@foobar.org> <m2sjwa84td.wl%randy@psg.com> <4D461B88.8020506@toonk.nl> <m21v3t8rtd.wl%randy@psg.com> <4D46BC2E.9040909@brightok.net> <m2wrll5g2t.wl%randy@psg.com> <4D46C775.1030503@brightok.net> Message-ID: <m2tygp5eey.wl%randy@psg.com> >> when there is no roa for the arriving prefix, a roa for the covering >> prefix is used. see draft-pmohapat-sidr-pfx-validate-07.txt. > Ahh, very good. I think that was the only concern. Presumably that > would invalidate the route and it would be discarded vs deprefed. well, i am not sure you want to discard it. this is where the op has to make a decision. in a world of partial deployment and ops and customers still learning how to deal with this stuff, should it be discarded? again from draft-ietf-sidr-rpki-origin-ops-04.txt Local policy using relative preference is suggested to manage the uncertainty associated with a system in flux, applying local policy to eliminate the threat of unroutability of prefixes due to ill- advised certification policies and/or incorrect certification data. E.g. until the community feels comfortable relying on RPKI data, routing on Invalid origin validity, though at a low preference, will likely be prevalent for a long time. but you configure your routers as you think best. randy From ryan.finnesey at HarrierInvestments.com Mon Jan 31 08:38:36 2011 From: ryan.finnesey at HarrierInvestments.com (Ryan Finnesey) Date: Mon, 31 Jan 2011 06:38:36 -0800 Subject: Verizon acquiring Terremark Message-ID: <6EFFEFBAC68377459A2E972105C759EC03539A93@EXVBE005-2.exch005intermedia.net> With Verizon acquiring Terremark does the group fell the NAPs will change from being carrier-neutral environments to pro Verizon? Has Verizon acquired carrier-neutral centers in the past? Cheers Ryan From nick at foobar.org Mon Jan 31 08:42:13 2011 From: nick at foobar.org (Nick Hilliard) Date: Mon, 31 Jan 2011 14:42:13 +0000 Subject: Level 3's IRR Database In-Reply-To: <D4D90B71-1078-4796-8FFE-E61DFACED3AC@hopcount.ca> References: <E65B3ED7E6FCBA48BC3E2FA899729216018E704D@rouwkoop.ac.za> <AANLkTi=ZhLT0HeWkZ1f57vu6sistskj_rgibEzDiBe3Y@mail.gmail.com> <4D459C96.3080306@foobar.org> <D4D90B71-1078-4796-8FFE-E61DFACED3AC@hopcount.ca> Message-ID: <4D46CA45.9040201@foobar.org> On 31/01/2011 14:16, Joe Abley wrote: > On 2011-01-30, at 12:15, Nick Hilliard wrote: >> Depends on which IRR you use. The IRRDBs run by RIPE, APNIC and >> AfriNIC implement hierarchical object ownership, which means that if >> you're registering their address space, you can only do so if that >> address space legitimately belongs to you. > This means that anybody can assert pretty much anything they like, so > long as the resources are not NCC-assigned. yes, indeed. I did mention "which means that if you're registering their address space...", although maybe that wasn't clear enough. Will use capital letters next time :-) Nick From jg at freedesktop.org Mon Jan 31 08:58:53 2011 From: jg at freedesktop.org (Jim Gettys) Date: Mon, 31 Jan 2011 09:58:53 -0500 Subject: help needed - state of california needs a benchmark - beware bufferbloat In-Reply-To: <4D4455C4.6080305@tiedyenetworks.com> References: <4D4455C4.6080305@tiedyenetworks.com> Message-ID: <4D46CE2D.7040602@freedesktop.org> On 01/29/2011 01:00 PM, Mike wrote: > Hello, > > My company is small clec / broadband provider serving rural communities > in northern California, and we are the recipient of a small grant from > the state thru our public utilities commission. We went out to 'middle > of nowhere' and deployed adsl2+ in fact (chalk one up for the good > guys!), and now that we're done, our state puc wants to gather > performance data to evaluate the result of our project and ensure we > delivered what we said we were going to. Bigger picture, our state is > actively attempting to map broadband availability and service levels > available and this data will factor into this overall picture, to be > used for future grant/loan programs and other support mechanisms, so > this really is going to touch every provider who serves end users in the > state. > > The rub is, that they want to legislate that web based 'speedtest.com' > is the ONLY and MOST AUTHORITATIVE metric that trumps all other > considerations and that the provider is %100 at fault and responsible > for making fraudulent claims if speedtest.com doesn't agree. No > discussion is allowed or permitted about sync rates, packet loss, > internet congestion, provider route diversity, end user computer > performance problems, far end congestion issues, far end server issues > or cpu loading, latency/rtt, or the like. They are going to decide that > the quality of any provider service, is solely and exclusively resting > on the numbers returned from 'speedtest.com' alone, period. > > All of you in this audience, I think, probably immediately understand > the various problems with such an assertion. Its one of these situations > where - to the uninitiated - it SEEMS LIKE this is the right way to do > this, and it SEEMS LIKE there's some validity to whats going on - but in > practice, we engineering types know it's a far different animal and > should not be used for real live benchmarking of any kind where there is > a demand for statistical validity. > > My feeling is that - if there is a need for the state to do > benchmarking, then it outta be using statistically significant > methodologies for same along the same lines as any other benchmark or > test done by other government agencies and national standards bodies > that are reproducible and dependable. The question is, as a hotbutton > issue, how do we go about getting 'the message' across, how do we go > about engineering something that could be considered statistically > relevant, and most importantly, how do we get this to be accepted by > non-technical legislators and regulators? Mike, For general tests of most things an ISP does, ICSI's netalyzr tests can't be beat. http://netalyzr.icsi.berkeley.edu/ There are also tests at m-lab that may be useful: http://www.measurementlab.net/ As in all pieces of software, these may have bugs; netalyzr was under detecting bufferbloat on high bandwidth links until recently; this should be fixed now, I hope. And SamKnows is doing the FCC broadband tests. The speedtest.net tests (and pingtest.net) are good as far as they go (and you can host them someplace yourself; as others have noted, having and endpoint at someplace you control is wise); but they don't tell the whole story: they miss a vital issue that has been hidden. Here's the rub: Most tests have focussed on bandwidth (now misnamed "speed" by marketing, which it isn't). Some tests have tested latency. But there have been precious few that test latency under load, which is how we've gotten into a world of hurt on broadband over the last decade, where we now have a situation where a large fraction of broadband has latencies under load measured in *seconds*. (See: http://gettys.wordpress.com/ and bufferbloat.net). These both make for fuming retail customers, as well as lots of service calls (I know, I generated quite a few myself over the years). This is a killer for lots of applications, VOIP, teleconferencing, gaming, remote desktop hosting, etc. Netalyzr tries to test for excessive buffering, as does at least one of the mlabs tests. Dave Clark and I have been talking to SamKnows and Ookla to try to get latency under load tests added to the mix. I think we've been having some traction at getting such tests added, but it's slightly too soon to tell. We also need tests to identify ISP's failing to run queue management internal to their networks, as there is both research and anecdotal data that shows that that is also much more common than it should be. Some ISP's do a wonderful job, and others don't; Van Jacobson believes this is because Sally Floyd and his classic RED algorithm is buggy, and tuning it has scared many operators off; I believe his explanation. So far, so bad. Then there is the home router/host disaster: As soon as you move the bottleneck link from the broadband hop to the 802.11 link usually beyond it these days (by higher broadband bandwidth, or by having several chimneys in your house as I do, dropping the wireless bandwidth), you run into the fact that home routers and even our operating systems sometimes have even worse buffering than the broadband gear, sometimes measured in hundreds or even thousands of *packets*. We're going to need to fix the home routers and user's operating systems. For the 802.11 case, this is hard; Van says RED won't hack it, and we need better algorithms, whether Van's unpublished nRED algorithm or Doug Leith's recent work. So you need to ensure the regulators' understand that doing testing carefully enough to know what you are looking at is hard. Tests not done directly at the broadband gear may mix this problem with the broadband connection. This is not to say tests should not be done: we're not going to get this swamp drained without the full light of day on the issue; just that current speedtest.net tests misses this entire issue right now (though may detect it in the future), and that the tests (today) aren't something you "just run" and get a simple answer, since the problem can be anywhere in a path. Maybe there will be tests that "do the right thing" for regulators in a year or two; but not now: the tests today don't identify which link is at fault, and that the problem can easily be entirely inside the customer's house, if the test tests for bufferbloat at all. I think it very important we get tests together that not only detect bufferbloat (which is very easy to detect, once you know how), but also point to where in the network the problem is occurring, to reduce the rate of complaints to something manageable, where everyone isn't having to field calls for problems they aren't responsible for (and unable to fix). You can look at a talk about bufferbloat I gave recently at: http://mirrors.bufferbloat.net/Talks/BellLabs01192011/ Let me know if I can be of help. People who want to help the bufferbloat problem please also note we recently opened a bufferbloat.net web site to help collaboration on this problem. Best regards, Jim Gettys Bell Labs On 01/06/2011 01:50 PM, Van Jacobson wrote: > Jim, > > Here's the Doug Leith paper I mentioned. As I said on the phone I > think there's an easier, more robust way to accomplish the same > thing but they have running code and I don't. You can get their > mad-wifi implementation at > http://www.hamilton.ie/tianji_li/buffersizing.html > > - van From jbates at brightok.net Mon Jan 31 09:13:59 2011 From: jbates at brightok.net (Jack Bates) Date: Mon, 31 Jan 2011 09:13:59 -0600 Subject: Contact at level 3 RE IRR database? In-Reply-To: <E65B3ED7E6FCBA48BC3E2FA899729216018E7054@rouwkoop.ac.za> References: <E65B3ED7E6FCBA48BC3E2FA899729216018E7054@rouwkoop.ac.za> Message-ID: <4D46D1B7.4020901@brightok.net> On 1/31/2011 8:35 AM, Andrew Alston wrote: > whois -h whois.radb.net \!gAS11908 and there is a *HUGE* amount of IP > space registered in the Level3 IRR database that is propagating to > the other databases that clearly does not belong to AS11908. (Beyond > the initial prefix of ours that noticed). > One thing to keep in mind. I ran into this with Cox's Level 3 entries. The Origin field in Level 3 database is often incorrect, but the entries are required for their acl's. So, even though a network may be advertised by a Cox customer, the ASN listed in L3 is Cox's ASN (which isn't unexpected since Cox is the one who entered the data). So AS11908 may be transiting those networks into Level3. Jack From jbates at brightok.net Mon Jan 31 09:15:56 2011 From: jbates at brightok.net (Jack Bates) Date: Mon, 31 Jan 2011 09:15:56 -0600 Subject: Level 3's IRR Database In-Reply-To: <m2tygp5eey.wl%randy@psg.com> References: <E65B3ED7E6FCBA48BC3E2FA899729216018E704D@rouwkoop.ac.za> <AANLkTing8yEVoDSxXsa+eTV0xZuv2qkYYA-ahT26hbFx@mail.gmail.com> <4D45CE4A.5090800@foobar.org> <m2sjwa84td.wl%randy@psg.com> <4D461B88.8020506@toonk.nl> <m21v3t8rtd.wl%randy@psg.com> <4D46BC2E.9040909@brightok.net> <m2wrll5g2t.wl%randy@psg.com> <4D46C775.1030503@brightok.net> <m2tygp5eey.wl%randy@psg.com> Message-ID: <4D46D22C.3070606@brightok.net> On 1/31/2011 8:35 AM, Randy Bush wrote: >>> when there is no roa for the arriving prefix, a roa for the covering >>> prefix is used. see draft-pmohapat-sidr-pfx-validate-07.txt. >> Ahh, very good. I think that was the only concern. Presumably that >> would invalidate the route and it would be discarded vs deprefed. > > well, i am not sure you want to discard it. this is where the op has to > make a decision. in a world of partial deployment and ops and customers > still learning how to deal with this stuff, should it be discarded? > I agree and definitely understand the turnup viewpoint. However, RPKI is useless if we don't discard invalid routes which are more specific than valid covering routes. local pref doesn't override prefix length decisions. Hijacks will continue to occur unless we issue discards... at some point. Jack From cconn at b2b2c.ca Mon Jan 31 09:23:49 2011 From: cconn at b2b2c.ca (Chris Conn) Date: Mon, 31 Jan 2011 10:23:49 -0500 Subject: Future of the IPv6 CPE survey on RIPE Labs - Your Input Needed In-Reply-To: <3D53E591D3EF17409FA82C5C0F8FC6BACE8072@sbs.B2B2Cinc.local> References: <3D53E591D3EF17409FA82C5C0F8FC6BACE8072@sbs.B2B2Cinc.local> Message-ID: <4D46D405.8050201@b2b2c.ca> > On 27/01/11 08:17 -0600, Jack Bates wrote: >> On 1/27/2011 12:57 AM, Frank Bulk wrote: >>> Have you looked at D-Link's DIR-825? It has most of the things you're >>> looking for. The DIR-655 is a more affordable option. >>> >> Haven't had the chance to look at that one. Will check it out. >> >>> In regards to (2), is it even possible to do DHCPv6-PD on with a SLAAC WAN? >>> >> It had better be, as IOS 12.2 SRE only supports SLAAC + DHCPv6-PD. >> Most of the Cisco documentation I've seen, says that is their >> beautiful layout. No more proxyarp/nd. Instead, assign a /64 to each >> subinterface, perform SLAAC, then hand out prefixes via DHCPv6-PD if >> someone needs a prefix. > > The DIR-825(Rev B) running firmware 2.05NA does. From the status screen: > > IPv6 Connection Type : Autoconfiguration (SLAAC/DHCPv6) > Network Status : Connected > > WAN IPv6 Address : 2610:b8:0:234:218:e7ff:fef8:66dc/64 > IPv6 Default Gateway : fe80::c67d:4fff:fed6:5401 > LAN IPv6 Address : 2610:b8:100f:1:218:e7ff:fef8:66db/64 > LAN IPv6 Link-Local Address : fe80::218:e7ff:fef8:66db/64 > Primary IPv6 DNS Server : 2610:b8:0:3:215:c5ff:fef3:f9c8 > Secondary IPv6 DNS Server : 2610:b8:0:3:215:c5ff:feee:9448 > DHCP-PD : Enabled > IPv6 network assigned > by DHCP-PD : 2610:b8:100f::/48 > > The latest firmware has fairly good support, but is lacking configurable v6 > firewall settings. I haven't done any firewall testing yet, but I'd imagine > all incoming v6 connections are blocked. > > The Emulator hasn't been updated yet to reflect the options in the new > firmware, but this should give you an idea of what the configuration looks > like: > > http://www.support.dlink.com/emulators/dir825_revB/203NA/adv_link_local.html > > The DIR-615 should have similar support, but I haven't upgraded it yet. Hello, As for the DIR-615, it should, but it doesn't...At least, the E3/E4 revisions I had. I contacted D-LINK support and was able to get a beta build that seems promising. But DHCP-PD over PPPoE works relatively well, minus a couple of little "features". I am hoping to have that hammered out soon, as the 615 is a capable little sub-50$ home CPE. But D-Link engineering seems receptive to my observations. I have to check the state of the firewalling in it too ;) Chris From John_Brzozowski at Cable.Comcast.com Mon Jan 31 09:26:19 2011 From: John_Brzozowski at Cable.Comcast.com (Brzozowski, John) Date: Mon, 31 Jan 2011 15:26:19 +0000 Subject: Comcast IPv6 Native Dual Stack Trials Message-ID: <C96C3EC8.8A65F%john_brzozowski@cable.comcast.com> Comcast Activates First Users With IPv6 Native Dual Stack Over DOCSIS http://blog.comcast.com/2011/01/comcast-activates-first-users-with-ipv6-nat ive-dual-stack-over-docsis.html John ========================================= John Jason Brzozowski Comcast Cable e) mailto:john_brzozowski at cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net ========================================= From jbates at brightok.net Mon Jan 31 09:28:19 2011 From: jbates at brightok.net (Jack Bates) Date: Mon, 31 Jan 2011 09:28:19 -0600 Subject: Future of the IPv6 CPE survey on RIPE Labs - Your Input Needed In-Reply-To: <4D46D405.8050201@b2b2c.ca> References: <3D53E591D3EF17409FA82C5C0F8FC6BACE8072@sbs.B2B2Cinc.local> <4D46D405.8050201@b2b2c.ca> Message-ID: <4D46D513.7090609@brightok.net> On 1/31/2011 9:23 AM, Chris Conn wrote: > As for the DIR-615, it should, but it doesn't...At least, the E3/E4 > revisions I had. I contacted D-LINK support and was able to get a beta > build that seems promising. But DHCP-PD over PPPoE works relatively > well, minus a couple of little "features". I am hoping to have that > hammered out soon, as the 615 is a capable little sub-50$ home CPE. But > D-Link engineering seems receptive to my observations. My concern as an ISP is the fact that we provide our own CPE, but customers often buy off shelf CPE. This will lead to serious interoperability issues if the whole market doesn't get their act together. Jack From jared at puck.nether.net Mon Jan 31 09:31:16 2011 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 31 Jan 2011 10:31:16 -0500 Subject: Comcast IPv6 Native Dual Stack Trials In-Reply-To: <C96C3EC8.8A65F%john_brzozowski@cable.comcast.com> References: <C96C3EC8.8A65F%john_brzozowski@cable.comcast.com> Message-ID: <20110131153116.GA7983@puck.nether.net> John, Congratulations on this important step! - Jared On Mon, Jan 31, 2011 at 03:26:19PM +0000, Brzozowski, John wrote: > Comcast Activates First Users With IPv6 Native Dual Stack Over DOCSIS > > http://blog.comcast.com/2011/01/comcast-activates-first-users-with-ipv6-nat > ive-dual-stack-over-docsis.html > > John > ========================================= > John Jason Brzozowski > Comcast Cable > e) mailto:john_brzozowski at cable.comcast.com > o) 609-377-6594 > m) 484-962-0060 > w) http://www.comcast6.net > ========================================= > > > -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From juicewvu at gmail.com Mon Jan 31 09:36:49 2011 From: juicewvu at gmail.com (Josh Smith) Date: Mon, 31 Jan 2011 10:36:49 -0500 Subject: Comcast IPv6 Native Dual Stack Trials In-Reply-To: <20110131153116.GA7983@puck.nether.net> References: <C96C3EC8.8A65F%john_brzozowski@cable.comcast.com> <20110131153116.GA7983@puck.nether.net> Message-ID: <AANLkTim4++MwwtTqyoWqrKaDmS06TWG=UsqrewxutKxd@mail.gmail.com> On Mon, Jan 31, 2011 at 10:31 AM, Jared Mauch <jared at puck.nether.net> wrote: > ? ? ? ?John, > > ? ? ? ?Congratulations on this important step! > > ? ? ? ?- Jared > > On Mon, Jan 31, 2011 at 03:26:19PM +0000, Brzozowski, John wrote: >> Comcast Activates First Users With IPv6 Native Dual Stack Over DOCSIS >> >> http://blog.comcast.com/2011/01/comcast-activates-first-users-with-ipv6-nat >> ive-dual-stack-over-docsis.html >> >> John >> ========================================= >> John Jason Brzozowski >> Comcast Cable >> e) mailto:john_brzozowski at cable.comcast.com >> o) 609-377-6594 >> m) 484-962-0060 >> w) http://www.comcast6.net >> ========================================= >> >> >> > > -- > Jared Mauch ?| pgp key available via finger from jared at puck.nether.net > clue++; ? ? ?| http://puck.nether.net/~jared/ ?My statements are only mine. > > Congratulations. Hopefully this trial makes its way to the Morgantown, WV area sooner rather than later (I'm not holding my breath) and I'll be able to reach the ipv6 internet natively instead of over my HE tunnel. Thanks, Josh Smith KD8HRX email/jabber:? juicewvu at gmail.com phone:? 304.237.9369(c) From scott at doc.net.au Mon Jan 31 09:50:28 2011 From: scott at doc.net.au (Scott Howard) Date: Mon, 31 Jan 2011 07:50:28 -0800 Subject: Verizon acquiring Terremark In-Reply-To: <6EFFEFBAC68377459A2E972105C759EC03539A93@EXVBE005-2.exch005intermedia.net> References: <6EFFEFBAC68377459A2E972105C759EC03539A93@EXVBE005-2.exch005intermedia.net> Message-ID: <AANLkTimFXwMAnas7XpTmC2cXOV-S2JGu89dChiKGfVek@mail.gmail.com> >From all accounts it will remain carrier neutral. http://www.datacenterknowledge.com/archives/2011/01/28/verizon-terremark-will-remain-carrier-neutral/ Scott. On Mon, Jan 31, 2011 at 6:38 AM, Ryan Finnesey < ryan.finnesey at harrierinvestments.com> wrote: > With Verizon acquiring Terremark does the group fell the NAPs will > change from being carrier-neutral environments to pro Verizon? Has > Verizon acquired carrier-neutral centers in the past? > > Cheers > Ryan > > > > > From dwhite at olp.net Mon Jan 31 09:51:09 2011 From: dwhite at olp.net (Dan White) Date: Mon, 31 Jan 2011 09:51:09 -0600 Subject: Future of the IPv6 CPE survey on RIPE Labs - Your Input Needed In-Reply-To: <4D46D513.7090609@brightok.net> References: <3D53E591D3EF17409FA82C5C0F8FC6BACE8072@sbs.B2B2Cinc.local> <4D46D405.8050201@b2b2c.ca> <4D46D513.7090609@brightok.net> Message-ID: <20110131155108.GC4714@dan.olp.net> On 31/01/11?09:28?-0600, Jack Bates wrote: > > >On 1/31/2011 9:23 AM, Chris Conn wrote: >>As for the DIR-615, it should, but it doesn't...At least, the E3/E4 >>revisions I had. I contacted D-LINK support and was able to get a beta >>build that seems promising. But DHCP-PD over PPPoE works relatively >>well, minus a couple of little "features". I am hoping to have that >>hammered out soon, as the 615 is a capable little sub-50$ home CPE. But >>D-Link engineering seems receptive to my observations. > >My concern as an ISP is the fact that we provide our own CPE, but >customers often buy off shelf CPE. This will lead to serious >interoperability issues if the whole market doesn't get their act >together. There's a fine line we're trying to hold with what we support. We want to establish a recommended list of residential grade routers for our customers (where appropriate), that they can purchase themselves off the shelf, without having to deal with the inevitable "you sold me this router, so you need to make it work with my Wii and I don't feel that I should have to pay you" type of headaches, if we were to actually sell the routers ourselves. That rules out 3rd party firmware like dd-wrt, since the customer is unlikely to get support when calling the vendor. At this point, I'd be happy with two good options (two different vendors) to recommend. So far, D-link is looking good. -- Dan White From jbates at brightok.net Mon Jan 31 09:56:25 2011 From: jbates at brightok.net (Jack Bates) Date: Mon, 31 Jan 2011 09:56:25 -0600 Subject: Future of the IPv6 CPE survey on RIPE Labs - Your Input Needed In-Reply-To: <20110131155108.GC4714@dan.olp.net> References: <3D53E591D3EF17409FA82C5C0F8FC6BACE8072@sbs.B2B2Cinc.local> <4D46D405.8050201@b2b2c.ca> <4D46D513.7090609@brightok.net> <20110131155108.GC4714@dan.olp.net> Message-ID: <4D46DBA9.8070708@brightok.net> On 1/31/2011 9:51 AM, Dan White wrote: > That rules out 3rd party firmware like dd-wrt, since the customer is > unlikely to get support when calling the vendor. > > At this point, I'd be happy with two good options (two different vendors) > to recommend. So far, D-link is looking good. Yeah, don't get me wrong. In most of our network, our CPE is bridging only. Customers wanted wireless and a few of the telco's were adamant about including it in their CPE (so the customer didn't have to go buy a wireless router from walmart). 90% or more of those wireless CPEs are still fully bridged (even the wireless is bridged to the wan). I've tried my hardest to keep things where IPv6 from our side will just work. What a customer buys is their concern, but we still have the danger of gear which just won't be interoperable with our setup. Jack From blake at ispn.net Mon Jan 31 11:13:08 2011 From: blake at ispn.net (Blake Hudson) Date: Mon, 31 Jan 2011 11:13:08 -0600 Subject: IPv6: numbering of point-to-point-links In-Reply-To: <4D3DA762.33E4.0097.1@globalstar.com> References: <FC64B3384195884588D252343702D23F01854588@ICABEXCCLU01B.int.sonofon.dk> <4E78852B-1695-4DEE-8B4D-C095446F2AEB@xs4all.nl> <20110124131820.GA10465@vacation.karoshi.com.> <4D3DA762.33E4.0097.1@globalstar.com> Message-ID: <4D46EDA4.2030907@ispn.net> > All of the (mostly religious) arguments about /64 versus any > smaller subnets aside, I'm curious about why one would choose > /126 over /127 for P-to-P links? Is this some kind of IPv4-think > where the all-zeros and all-ones addresses are not usable > unicast addresses? This isn't true in IPv6 (of course, it's not > strictly true in IPv4 either). Is there another reason? I setup a p2p /127 link and found that BGP would not peer over the link; Changing to /126 resolved the problem. I never looked into it further because I had intended to use /126 from the start. My guess is that while BGP should be a unicast IP, Cisco's implementation uses an anycast in some cases, disregarding the configured unicast address. Just one practical example... From blake at ispn.net Mon Jan 31 11:38:55 2011 From: blake at ispn.net (Blake Hudson) Date: Mon, 31 Jan 2011 11:38:55 -0600 Subject: Ipv6 for the content provider In-Reply-To: <79330.1296079747@localhost> References: <4D406670.8040202@knownelement.com> <20110126214802.M82382@fast-serv.com> <4D409875.2060207@knownelement.com> <79330.1296079747@localhost> Message-ID: <4D46F3AF.2000809@ispn.net> -------- Original Message -------- Subject: Re: Ipv6 for the content provider From: Valdis.Kletnieks at vt.edu To: Charles N Wyble <charles at knownelement.com> Cc: nanog at nanog.org Date: Wednesday, January 26, 2011 4:09:07 PM > On Wed, 26 Jan 2011 13:56:05 PST, Charles N Wyble said: > >>> The only issue I've faced is RHEL/CentOS doesn't have stateful connection >>> tracking for IPv6 - so ip6tables is practically worthless. >> >> Hmmmm. Interesting. I wonder if this is specific to the RedHat kernel? >> Or a problem with v6 support on Linux in general? > (Linux kernels are trying to stick to a release-every-3-months schedule). > > RHEL/CentOS 5 is using a 2.6.18 kernel. The needed support for stateful IPv6 > landed in 2.6.21 or so (so almost a year after RHEL 5 did its feature freeze). > RHEL 6 is apparently a 2.6.32 kernel so it should be there. Cutting edge kernel > is currently 2.6.38-rc2. > > I was under the impression that the later versions of 5 (e.g. 5.5, 5.6) had backported stateful connection tracking. Has anyone tested recently? We mainly use IPtables on end-servers to limit access to a few key applications (like SSH) to trusted subnets, the rest of the applications (SMTP, IMAP, HTTP, etc) are initiated from outside sources so there's no state to being with. In these setups stateful tracking is not a must, but I would still like to have it in case a rogue listener/service is started. We have many RH5 servers deployed, and moving to 6 for this feature alone seems a little much. What I would really like to see is better DoS protection in the form of tracking total number of connections (per host and per application) and new connection rate limits (per host and globally to an application). The last time I tested these features via the optional module, the module was not configurable to the scale we needed nor was it reliable at smaller scales. Perhaps I will test both of these again in RH5 and report back. From simon.perreault at viagenie.ca Mon Jan 31 11:48:34 2011 From: simon.perreault at viagenie.ca (Simon Perreault) Date: Mon, 31 Jan 2011 12:48:34 -0500 Subject: Ipv6 for the content provider In-Reply-To: <4D46F3AF.2000809@ispn.net> References: <4D406670.8040202@knownelement.com> <20110126214802.M82382@fast-serv.com> <4D409875.2060207@knownelement.com> <79330.1296079747@localhost> <4D46F3AF.2000809@ispn.net> Message-ID: <4D46F5F2.2090202@viagenie.ca> On 2011-01-31 12:38, Blake Hudson wrote: > I was under the impression that the later versions of 5 (e.g. 5.5, 5.6) > had backported stateful connection tracking. Has anyone tested recently? The command # ip6tables -A INPUT -m state --state ESTABLISHED -j ACCEPT works on CentOS 5.5. And there's no documentation for it in "man ip6tables". So it fits the backport hypothesis... Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From blake at ispn.net Mon Jan 31 11:53:22 2011 From: blake at ispn.net (Blake Hudson) Date: Mon, 31 Jan 2011 11:53:22 -0600 Subject: Ipv6 for the content provider In-Reply-To: <4D46F5F2.2090202@viagenie.ca> References: <4D406670.8040202@knownelement.com> <20110126214802.M82382@fast-serv.com> <4D409875.2060207@knownelement.com> <79330.1296079747@localhost> <4D46F3AF.2000809@ispn.net> <4D46F5F2.2090202@viagenie.ca> Message-ID: <4D46F712.2010407@ispn.net> -------- Original Message -------- Subject: Re: Ipv6 for the content provider From: Simon Perreault <simon.perreault at viagenie.ca> To: nanog at nanog.org Date: Monday, January 31, 2011 11:48:34 AM > On 2011-01-31 12:38, Blake Hudson wrote: >> I was under the impression that the later versions of 5 (e.g. 5.5, 5.6) >> had backported stateful connection tracking. Has anyone tested recently? > The command > > # ip6tables -A INPUT -m state --state ESTABLISHED -j ACCEPT > > works on CentOS 5.5. And there's no documentation for it in "man > ip6tables". So it fits the backport hypothesis... > > Simon I guess the next question is whether or not it actually works correctly.... From cgrundemann at gmail.com Mon Jan 31 12:12:36 2011 From: cgrundemann at gmail.com (Chris Grundemann) Date: Mon, 31 Jan 2011 11:12:36 -0700 Subject: Comcast IPv6 Native Dual Stack Trials In-Reply-To: <C96C3EC8.8A65F%john_brzozowski@cable.comcast.com> References: <C96C3EC8.8A65F%john_brzozowski@cable.comcast.com> Message-ID: <AANLkTingFRZ+RqUhW653Nu8ZhWQJt_ZmJS3aLh90f3ao@mail.gmail.com> Well done John! Here's to a rapid expansion of the native footprint! ~Chris On Mon, Jan 31, 2011 at 08:26, Brzozowski, John <John_Brzozowski at cable.comcast.com> wrote: > Comcast Activates First Users With IPv6 Native Dual Stack Over DOCSIS > > http://blog.comcast.com/2011/01/comcast-activates-first-users-with-ipv6-nat > ive-dual-stack-over-docsis.html > > John > ========================================= > John Jason Brzozowski > Comcast Cable > e) mailto:john_brzozowski at cable.comcast.com > o) 609-377-6594 > m) 484-962-0060 > w) http://www.comcast6.net > ========================================= > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.net www.coisoc.org From jbates at brightok.net Mon Jan 31 12:13:59 2011 From: jbates at brightok.net (Jack Bates) Date: Mon, 31 Jan 2011 12:13:59 -0600 Subject: Ipv6 for the content provider In-Reply-To: <4D46F5F2.2090202@viagenie.ca> References: <4D406670.8040202@knownelement.com> <20110126214802.M82382@fast-serv.com> <4D409875.2060207@knownelement.com> <79330.1296079747@localhost> <4D46F3AF.2000809@ispn.net> <4D46F5F2.2090202@viagenie.ca> Message-ID: <4D46FBE7.8010803@brightok.net> On 1/31/2011 11:48 AM, Simon Perreault wrote: > works on CentOS 5.5. And there's no documentation for it in "man > ip6tables". So it fits the backport hypothesis... > Not unexpected. The kernel also handles virtio for kvm. It's nowhere near vanilla. Jack From andree+nanog at toonk.nl Mon Jan 31 12:17:07 2011 From: andree+nanog at toonk.nl (Andree Toonk) Date: Mon, 31 Jan 2011 10:17:07 -0800 Subject: Level 3's IRR Database In-Reply-To: <m21v3t8rtd.wl%randy@psg.com> References: <E65B3ED7E6FCBA48BC3E2FA899729216018E704D@rouwkoop.ac.za> <AANLkTing8yEVoDSxXsa+eTV0xZuv2qkYYA-ahT26hbFx@mail.gmail.com> <4D45CE4A.5090800@foobar.org> <m2sjwa84td.wl%randy@psg.com> <4D461B88.8020506@toonk.nl> <m21v3t8rtd.wl%randy@psg.com> Message-ID: <4D46FCA3.1050509@toonk.nl> Hi Randy, .-- My secret spy satellite informs me that at 11-01-30 11:18 PM Randy Bush wrote: > so i am not sure what your point is. please clarify with a concrete > example. Adjusting a route's degree of preference in the selection algorithm based on its validation state only works if it's exactly the same prefix. Jack already sort of explained what I meant, but here's an example Assume that youtube's prefix had a roa like this Origin ASN: AS36561 Prefixes: 208.65.152.0/22 Now AS17557 start to announce a more specific: 208.65.153.0/24. Validators would classify this as Invalid (2). If we would only use local-prefs, routers would still choose to send it to AS17557 (Pakistan Telecom) as it's a more specific. So in cases where the invalid announcement is a more specific, the only way to prevent 'hijacks' is to actually drop these 'invalid' announcement from day one. I understand this is by design, but I can imagine some operators will be reluctant to actually drop routes when they start testing RPKI deployments in their networks. Cheers, Andree From rsm at fast-serv.com Mon Jan 31 12:29:18 2011 From: rsm at fast-serv.com (Randy McAnally) Date: Mon, 31 Jan 2011 13:29:18 -0500 Subject: Ipv6 for the content provider In-Reply-To: <4D46F712.2010407@ispn.net> References: <4D406670.8040202@knownelement.com> <20110126214802.M82382@fast-serv.com> <4D409875.2060207@knownelement.com> <79330.1296079747@localhost> <4D46F3AF.2000809@ispn.net> <4D46F5F2.2090202@viagenie.ca> <4D46F712.2010407@ispn.net> Message-ID: <20110131182743.M94044@fast-serv.com> On Mon, 31 Jan 2011 11:53:22 -0600, Blake Hudson wrote > > # ip6tables -A INPUT -m state --state ESTABLISHED -j ACCEPT > I guess the next question is whether or not it actually works correctly.... You can open/shut ports but you can't do anything with connection state (RELATED, ESTABLISHED, ect). For example, you have to open all upper inbound ports manually if you want to complete outbound connections. The solution is to manually build your own kernel from a vanilla source, along with all the problems that entails. ~Randy From dongting.yu at cl.cam.ac.uk Mon Jan 31 12:40:31 2011 From: dongting.yu at cl.cam.ac.uk (Dongting Yu) Date: Mon, 31 Jan 2011 18:40:31 +0000 Subject: Level 3's IRR Database In-Reply-To: <4D46FCA3.1050509@toonk.nl> References: <E65B3ED7E6FCBA48BC3E2FA899729216018E704D@rouwkoop.ac.za> <AANLkTing8yEVoDSxXsa+eTV0xZuv2qkYYA-ahT26hbFx@mail.gmail.com> <4D45CE4A.5090800@foobar.org> <m2sjwa84td.wl%randy@psg.com> <4D461B88.8020506@toonk.nl> <m21v3t8rtd.wl%randy@psg.com> <4D46FCA3.1050509@toonk.nl> Message-ID: <AANLkTimUEQmY0RZzB-mSi30WYDYFoa+csJhXjMCvSna8@mail.gmail.com> On Mon, Jan 31, 2011 at 6:17 PM, Andree Toonk <andree+nanog at toonk.nl> wrote: > > Now AS17557 start to announce a more specific: 208.65.153.0/24. Validators > would classify this as Invalid (2). Would it be classified as invalid or unknown? Or are both possible depending on whether 208.65.153.0/24 is signed? Do these two cases differ in this particular case? Dongting From mpetach at netflight.com Mon Jan 31 12:41:19 2011 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 31 Jan 2011 10:41:19 -0800 Subject: 2011.01.31 NANOG51 day 1 morning session notes posted Message-ID: <AANLkTimp3ZB799DegcMYmnCXcsgkrqE1gH6Eq4JU4owZ@mail.gmail.com> I've posted my notes from the morning session of NANOG51 from Miami up at http://kestrel3.netflight.com/2011.01.31-NANOG51-morning-notes.txt Congratulations, Josh, on the acquisition; wish I'd been able to fly out and join in the celebration. :) As always, apologies to everyone for slaughtering people's names--let me know when I've butchered yours horribly, and I'll update the page. ^_^; Matt From tony at lava.net Mon Jan 31 13:04:42 2011 From: tony at lava.net (Antonio Querubin) Date: Mon, 31 Jan 2011 09:04:42 -1000 (HST) Subject: Ipv6 for the content provider In-Reply-To: <4D46F5F2.2090202@viagenie.ca> References: <4D406670.8040202@knownelement.com> <20110126214802.M82382@fast-serv.com> <4D409875.2060207@knownelement.com> <79330.1296079747@localhost> <4D46F3AF.2000809@ispn.net> <4D46F5F2.2090202@viagenie.ca> Message-ID: <alpine.OSX.2.00.1101310858210.147@cust11794.lava.net> On Mon, 31 Jan 2011, Simon Perreault wrote: > The command > > # ip6tables -A INPUT -m state --state ESTABLISHED -j ACCEPT > > works on CentOS 5.5. And there's no documentation for it in "man > ip6tables". So it fits the backport hypothesis... While it may accept it, you may find it doesn't really work the way it should :) I had made the same assumption and discovered various problems. I ended up replacing it with: -A RH-Firewall-1-INPUT -p udp -m udp --dport 32768:61000 -j ACCEPT -A RH-Firewall-1-INPUT -p tcp -m tcp --dport 32768:61000 ! --syn -j ACCEPT which is what ip6tables ships with. You may need to adjust that port range depending on your apps. Antonio Querubin e-mail/xmpp: tony at lava.net From jbates at brightok.net Mon Jan 31 13:17:35 2011 From: jbates at brightok.net (Jack Bates) Date: Mon, 31 Jan 2011 13:17:35 -0600 Subject: Level 3's IRR Database In-Reply-To: <AANLkTimUEQmY0RZzB-mSi30WYDYFoa+csJhXjMCvSna8@mail.gmail.com> References: <E65B3ED7E6FCBA48BC3E2FA899729216018E704D@rouwkoop.ac.za> <AANLkTing8yEVoDSxXsa+eTV0xZuv2qkYYA-ahT26hbFx@mail.gmail.com> <4D45CE4A.5090800@foobar.org> <m2sjwa84td.wl%randy@psg.com> <4D461B88.8020506@toonk.nl> <m21v3t8rtd.wl%randy@psg.com> <4D46FCA3.1050509@toonk.nl> <AANLkTimUEQmY0RZzB-mSi30WYDYFoa+csJhXjMCvSna8@mail.gmail.com> Message-ID: <4D470ACF.5060803@brightok.net> On 1/31/2011 12:40 PM, Dongting Yu wrote: > Would it be classified as invalid or unknown? Or are both possible > depending on whether 208.65.153.0/24 is signed? Do these two cases > differ in this particular case? > Based on the draft it is invalid, as the shorter covering prefix is signed, so the longer prefix will inherit that signing but not be valid. Jack From lowen at pari.edu Mon Jan 31 13:18:52 2011 From: lowen at pari.edu (Lamar Owen) Date: Mon, 31 Jan 2011 14:18:52 -0500 Subject: Ipv6 for the content provider In-Reply-To: <20110131182743.M94044@fast-serv.com> References: <4D406670.8040202@knownelement.com> Message-ID: <201101311418.52615.lowen@pari.edu> On Monday, January 31, 2011 01:29:18 pm Randy McAnally wrote: > The solution is to manually build your own kernel from a vanilla source, along > with all the problems that entails. There's also the RH eMRG rt kernel which is built on substantially newer sources. You'll need to rebuild it yourself (make an RPM build tree, do rpm -i on the source RPM, rpmbuild -ba on the specfile): ftp://ftp.redhat.com/redhat/linux/enterprise/5Server/en/RHEMRG/SRPMS/kernel-rt-2.6.33.7-rt29.47.el5rt.src.rpm Then you have a kernel that has those newer features and has the integration testing with the other versions of packages installed on the system; using the yum local install, you can get automatic depsolving, too, just in case it has odd dependencies. Or you could get the newer Oracle kernel built for Oracle's RHEL rebuild. Vanilla isn't always best. Sometimes you want chocolate, or butter pecan. Some might joke that RHEL's kernel is rocky road..... and others might call it heavenly hash. Either way, it can be had for CentOS 5 without a whole lot of pain, and in a package system friendly manner. From alexb at ripe.net Mon Jan 31 13:20:52 2011 From: alexb at ripe.net (Alex Band) Date: Mon, 31 Jan 2011 20:20:52 +0100 Subject: Level 3's IRR Database In-Reply-To: <AANLkTimUEQmY0RZzB-mSi30WYDYFoa+csJhXjMCvSna8@mail.gmail.com> References: <E65B3ED7E6FCBA48BC3E2FA899729216018E704D@rouwkoop.ac.za> <AANLkTing8yEVoDSxXsa+eTV0xZuv2qkYYA-ahT26hbFx@mail.gmail.com> <4D45CE4A.5090800@foobar.org> <m2sjwa84td.wl%randy@psg.com> <4D461B88.8020506@toonk.nl> <m21v3t8rtd.wl%randy@psg.com> <4D46FCA3.1050509@toonk.nl> <AANLkTimUEQmY0RZzB-mSi30WYDYFoa+csJhXjMCvSna8@mail.gmail.com> Message-ID: <A3FBFB4F-457E-40B5-86B6-DD300B829385@ripe.net> On 31 Jan 2011, at 19:40, Dongting Yu wrote: > On Mon, Jan 31, 2011 at 6:17 PM, Andree Toonk <andree+nanog at toonk.nl> wrote: >> >> Now AS17557 start to announce a more specific: 208.65.153.0/24. Validators >> would classify this as Invalid (2). > > Would it be classified as invalid or unknown? Or are both possible > depending on whether 208.65.153.0/24 is signed? Do these two cases > differ in this particular case? No, it would classify as invalid because as Randy said earlier in the thread: Before issuing a ROA for a block, an operator MUST ensure that any sub-allocations from that block which are announced by others (e.g. customers) have ROAs in play. Otherwise, issuing a ROA for the super-block will cause the announcements of sub-allocations with no ROAs to be Invalid. In a ROA you can specify a maximum length, authorising the AS to deaggregate the prefix to the point you specify. If no max length is specified, the AS is only allowed to announce the prefix as indicated. So if the ROA for AS36561 with prefix 208.65.152.0/22 was created with no 'max length' specified, the /24 that AS17557 announces would be invalid because it's the wrong prefix length *and* because it's the wrong origin AS. If a max length of /24 was specified in the ROA, it would be invalid only because of the latter. There could be another ROA for 208.65.153.0/24 specifically, but obviously not for AS17557, so again invalid because of the wrong origin AS. Pakistan Telecom also can't create a valid ROA, because they are not the holder of the address space. -Alex From arturo.servin at gmail.com Mon Jan 31 13:42:35 2011 From: arturo.servin at gmail.com (Arturo Servin) Date: Mon, 31 Jan 2011 14:42:35 -0500 Subject: Level 3's IRR Database In-Reply-To: <A3FBFB4F-457E-40B5-86B6-DD300B829385@ripe.net> References: <E65B3ED7E6FCBA48BC3E2FA899729216018E704D@rouwkoop.ac.za> <AANLkTing8yEVoDSxXsa+eTV0xZuv2qkYYA-ahT26hbFx@mail.gmail.com> <4D45CE4A.5090800@foobar.org> <m2sjwa84td.wl%randy@psg.com> <4D461B88.8020506@toonk.nl> <m21v3t8rtd.wl%randy@psg.com> <4D46FCA3.1050509@toonk.nl> <AANLkTimUEQmY0RZzB-mSi30WYDYFoa+csJhXjMCvSna8@mail.gmail.com> <A3FBFB4F-457E-40B5-86B6-DD300B829385@ripe.net> Message-ID: <8FD816AA-EC8B-4221-BFB4-96BE4A75E3F2@gmail.com> I think the issue is not between valid vs invalid, but that using route-maps and local preference a "more specific not valid" route would be used over another "less specific valid" because of the routing decision process, right? Perhaps this would help? http://www.ietf.org/mail-archive/web/sidr/current/msg02117.html So, it is my understanding that yes, with local pref the Google vs Pakistan Telecom wouldn't have been avoided, however Google would "only need" to generate more specific routes to beat the unauthorised announce and "fix" the issue. Right? .as On 31 Jan 2011, at 14:20, Alex Band wrote: > > On 31 Jan 2011, at 19:40, Dongting Yu wrote: > >> On Mon, Jan 31, 2011 at 6:17 PM, Andree Toonk <andree+nanog at toonk.nl> wrote: >>> >>> Now AS17557 start to announce a more specific: 208.65.153.0/24. Validators >>> would classify this as Invalid (2). >> >> Would it be classified as invalid or unknown? Or are both possible >> depending on whether 208.65.153.0/24 is signed? Do these two cases >> differ in this particular case? > > No, it would classify as invalid because as Randy said earlier in the thread: > > Before issuing a ROA for a block, an operator MUST ensure that any > sub-allocations from that block which are announced by others (e.g. > customers) have ROAs in play. Otherwise, issuing a ROA for the > super-block will cause the announcements of sub-allocations with no > ROAs to be Invalid. > > In a ROA you can specify a maximum length, authorising the AS to deaggregate the prefix to the point you specify. If no max length is specified, the AS is only allowed to announce the prefix as indicated. > > So if the ROA for AS36561 with prefix 208.65.152.0/22 was created with no 'max length' specified, the /24 that AS17557 announces would be invalid because it's the wrong prefix length *and* because it's the wrong origin AS. If a max length of /24 was specified in the ROA, it would be invalid only because of the latter. > > There could be another ROA for 208.65.153.0/24 specifically, but obviously not for AS17557, so again invalid because of the wrong origin AS. Pakistan Telecom also can't create a valid ROA, because they are not the holder of the address space. > > -Alex From linux.yahoo at gmail.com Mon Jan 31 14:03:40 2011 From: linux.yahoo at gmail.com (Manu Chao) Date: Mon, 31 Jan 2011 21:03:40 +0100 Subject: MS-SMB2 Message-ID: <AANLkTikzysLg=KBMAyY2aAx3YQweDdm9pCS=h1wVoHOu@mail.gmail.com> Did anybody know from when or from which Service Pack was introduced SMB2 on Windows XP? The official documentation MS-SMB2 (v20101230) say SMB2 is only supported on Vista, Seven, 2008 and 2008 R2 while it seems (i may be wrong) supported on XP SP3? Thank you From morrowc.lists at gmail.com Mon Jan 31 14:11:27 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 31 Jan 2011 15:11:27 -0500 Subject: Level 3's IRR Database In-Reply-To: <4D46FCA3.1050509@toonk.nl> References: <E65B3ED7E6FCBA48BC3E2FA899729216018E704D@rouwkoop.ac.za> <AANLkTing8yEVoDSxXsa+eTV0xZuv2qkYYA-ahT26hbFx@mail.gmail.com> <4D45CE4A.5090800@foobar.org> <m2sjwa84td.wl%randy@psg.com> <4D461B88.8020506@toonk.nl> <m21v3t8rtd.wl%randy@psg.com> <4D46FCA3.1050509@toonk.nl> Message-ID: <AANLkTim2ABoNd-seC6pS_sNUCDxeTrabus4r2+0BkE4M@mail.gmail.com> On Mon, Jan 31, 2011 at 1:17 PM, Andree Toonk <andree+nanog at toonk.nl> wrote: > Hi Randy, > > .-- My secret spy satellite informs me that at 11-01-30 11:18 PM ?Randy Bush > wrote: > >> so i am not sure what your point is. ?please clarify with a concrete >> example. > > Adjusting a route's degree of preference in the selection algorithm based on > its validation state only works if it's exactly the same prefix. > > Jack already sort of explained what I meant, but here's an example > > Assume that youtube's prefix had a roa like this > Origin ASN: ? ? AS36561 > Prefixes: ? ? ? 208.65.152.0/22 > > Now AS17557 start to announce a more specific: 208.65.153.0/24. Validators > would classify this as Invalid (2). > If we would only use local-prefs, routers would still choose to send it to > AS17557 (Pakistan Telecom) as it's a more specific. > > So in cases where the invalid announcement is a more specific, the only way > to prevent 'hijacks' is to actually drop these 'invalid' announcement from > day one. > > I understand this is by design, but I can imagine some operators will be > reluctant to actually drop routes when they start testing RPKI deployments > in their networks. yes, but what is the way forward? From jared at puck.nether.net Mon Jan 31 14:19:05 2011 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 31 Jan 2011 15:19:05 -0500 Subject: Level 3's IRR Database In-Reply-To: <AANLkTim2ABoNd-seC6pS_sNUCDxeTrabus4r2+0BkE4M@mail.gmail.com> References: <E65B3ED7E6FCBA48BC3E2FA899729216018E704D@rouwkoop.ac.za> <AANLkTing8yEVoDSxXsa+eTV0xZuv2qkYYA-ahT26hbFx@mail.gmail.com> <4D45CE4A.5090800@foobar.org> <m2sjwa84td.wl%randy@psg.com> <4D461B88.8020506@toonk.nl> <m21v3t8rtd.wl%randy@psg.com> <4D46FCA3.1050509@toonk.nl> <AANLkTim2ABoNd-seC6pS_sNUCDxeTrabus4r2+0BkE4M@mail.gmail.com> Message-ID: <EE9A49A2-C417-4BEC-8251-3BB4C1CB20B1@puck.nether.net> On Jan 31, 2011, at 3:11 PM, Christopher Morrow wrote: >> I understand this is by design, but I can imagine some operators will be >> reluctant to actually drop routes when they start testing RPKI deployments >> in their networks. > > yes, but what is the way forward? RPKI in my IPv6? :) Someone is going to be the first person to jump into this sea. It continues to be something that I am interested in. If you look at the risk to your $dayjob, at minimum you should be looking at RPKI for your infrastructure IP space, similar to how you might obtain a certificate for your corporate website. I applaud vendors of hardware and IP services that have managed to do BCP-38 type packet filtering. It cleans up the mess others have to see. This is the same thing IMHO. We need to keep the routing infrastructure secure. This doesn't mean you have to secure your network. But I can decide that if you buy into the same security model as described via SIDR/RPKI you may obtain better preference in my network. - Jared From randy at psg.com Mon Jan 31 14:53:28 2011 From: randy at psg.com (Randy Bush) Date: Tue, 01 Feb 2011 05:53:28 +0900 Subject: Level 3's IRR Database In-Reply-To: <4D46D22C.3070606@brightok.net> References: <E65B3ED7E6FCBA48BC3E2FA899729216018E704D@rouwkoop.ac.za> <AANLkTing8yEVoDSxXsa+eTV0xZuv2qkYYA-ahT26hbFx@mail.gmail.com> <4D45CE4A.5090800@foobar.org> <m2sjwa84td.wl%randy@psg.com> <4D461B88.8020506@toonk.nl> <m21v3t8rtd.wl%randy@psg.com> <4D46BC2E.9040909@brightok.net> <m2wrll5g2t.wl%randy@psg.com> <4D46C775.1030503@brightok.net> <m2tygp5eey.wl%randy@psg.com> <4D46D22C.3070606@brightok.net> Message-ID: <m2pqrc6bhz.wl%randy@psg.com> >> well, i am not sure you want to discard it. this is where the op has to >> make a decision. in a world of partial deployment and ops and customers >> still learning how to deal with this stuff, should it be discarded? > > I agree and definitely understand the turnup viewpoint. However, RPKI is > useless if we don't discard invalid routes which are more specific than > valid covering routes. local pref doesn't override prefix length > decisions. Hijacks will continue to occur unless we issue discards... at > some point. i think that is how i would run my network. but those concerned about *any* change, might prefer being vulnerable to the youtube accident. we all have choices. randy From andree+nanog at toonk.nl Mon Jan 31 14:55:28 2011 From: andree+nanog at toonk.nl (Andree Toonk) Date: Mon, 31 Jan 2011 12:55:28 -0800 Subject: Level 3's IRR Database In-Reply-To: <AANLkTim2ABoNd-seC6pS_sNUCDxeTrabus4r2+0BkE4M@mail.gmail.com> References: <E65B3ED7E6FCBA48BC3E2FA899729216018E704D@rouwkoop.ac.za> <AANLkTing8yEVoDSxXsa+eTV0xZuv2qkYYA-ahT26hbFx@mail.gmail.com> <4D45CE4A.5090800@foobar.org> <m2sjwa84td.wl%randy@psg.com> <4D461B88.8020506@toonk.nl> <m21v3t8rtd.wl%randy@psg.com> <4D46FCA3.1050509@toonk.nl> <AANLkTim2ABoNd-seC6pS_sNUCDxeTrabus4r2+0BkE4M@mail.gmail.com> Message-ID: <4D4721C0.8090603@toonk.nl> .-- My secret spy satellite informs me that at 11-01-31 12:11 PM Christopher Morrow wrote: >> I understand this is by design, but I can imagine some operators will be >> reluctant to actually drop routes when they start testing RPKI deployments >> in their networks. > > yes, but what is the way forward? Not sure, that was my original question: Are there any suggestions or recommendations for how to handle these cases? From wesmills at wyvern.org Mon Jan 31 14:56:44 2011 From: wesmills at wyvern.org (Wes Mills) Date: Mon, 31 Jan 2011 14:56:44 -0600 Subject: MS-SMB2 In-Reply-To: <AANLkTikzysLg=KBMAyY2aAx3YQweDdm9pCS=h1wVoHOu@mail.gmail.com> References: <AANLkTikzysLg=KBMAyY2aAx3YQweDdm9pCS=h1wVoHOu@mail.gmail.com> Message-ID: <4D47220C.5000507@wyvern.org> Manu Chao wrote: > Did anybody know from when or from which Service Pack was introduced SMB2 on > Windows XP? > > The official documentation MS-SMB2 (v20101230) say SMB2 is only supported on > Vista, Seven, 2008 and 2008 R2 while it seems (i may be wrong) supported on > XP SP3? > Only Windows Vista and higher have SMB2. That version of the protocol was never backported to XP SP3 or 2003 SP2. From randy at psg.com Mon Jan 31 15:06:07 2011 From: randy at psg.com (Randy Bush) Date: Tue, 01 Feb 2011 06:06:07 +0900 Subject: Level 3's IRR Database In-Reply-To: <4D46FCA3.1050509@toonk.nl> References: <E65B3ED7E6FCBA48BC3E2FA899729216018E704D@rouwkoop.ac.za> <AANLkTing8yEVoDSxXsa+eTV0xZuv2qkYYA-ahT26hbFx@mail.gmail.com> <4D45CE4A.5090800@foobar.org> <m2sjwa84td.wl%randy@psg.com> <4D461B88.8020506@toonk.nl> <m21v3t8rtd.wl%randy@psg.com> <4D46FCA3.1050509@toonk.nl> Message-ID: <m2ipx46aww.wl%randy@psg.com> > Jack already sort of explained what I meant, but here's an example > > Assume that youtube's prefix had a roa like this > Origin ASN: AS36561 > Prefixes: 208.65.152.0/22 > > Now AS17557 start to announce a more specific: 208.65.153.0/24. > Validators would classify this as Invalid (2). > If we would only use local-prefs, routers would still choose to send > it to AS17557 (Pakistan Telecom) as it's a more specific. > > So in cases where the invalid announcement is a more specific, the > only way to prevent 'hijacks' is to actually drop these 'invalid' > announcement from day one. yes. and your point is? we all run our routers according to our views of what policy we want. some folk will want to drop that, i encourage them to, and have done my best to see that they have the capability to do so. i am in that camp. others fear rir and black helicopter control of their routing. they may not want to drop the 'bad' announcement. i tried to document how they might do so. we all have choices. the point of the design is to empower the operator to make those choices, and to do so in a simple and consistent fashion. randy From randy at psg.com Mon Jan 31 15:09:55 2011 From: randy at psg.com (Randy Bush) Date: Tue, 01 Feb 2011 06:09:55 +0900 Subject: Level 3's IRR Database In-Reply-To: <AANLkTimUEQmY0RZzB-mSi30WYDYFoa+csJhXjMCvSna8@mail.gmail.com> References: <E65B3ED7E6FCBA48BC3E2FA899729216018E704D@rouwkoop.ac.za> <AANLkTing8yEVoDSxXsa+eTV0xZuv2qkYYA-ahT26hbFx@mail.gmail.com> <4D45CE4A.5090800@foobar.org> <m2sjwa84td.wl%randy@psg.com> <4D461B88.8020506@toonk.nl> <m21v3t8rtd.wl%randy@psg.com> <4D46FCA3.1050509@toonk.nl> <AANLkTimUEQmY0RZzB-mSi30WYDYFoa+csJhXjMCvSna8@mail.gmail.com> Message-ID: <m2hbco6aqk.wl%randy@psg.com> >> Now AS17557 start to announce a more specific: 208.65.153.0/24. >> Validators would classify this as Invalid (2). > Would it be classified as invalid or unknown? invalid > Or are both possible no. the result is a single value > depending on whether 208.65.153.0/24 is signed? <pedant=on> roas, which are signed by resource certificates, bind a prefix to a set of ASs. sorry to wax pedantic. but this stuff can get crufty, and getting the nouns and verbs correct will help us navigate. randy From randy at psg.com Mon Jan 31 15:26:26 2011 From: randy at psg.com (Randy Bush) Date: Tue, 01 Feb 2011 06:26:26 +0900 Subject: IPv6: numbering of point-to-point-links In-Reply-To: <4D46EDA4.2030907@ispn.net> References: <FC64B3384195884588D252343702D23F01854588@ICABEXCCLU01B.int.sonofon.dk> <4E78852B-1695-4DEE-8B4D-C095446F2AEB@xs4all.nl> Message-ID: <m2bp2w69z1.wl%randy@psg.com> > I setup a p2p /127 link and found that BGP would not peer over the > link; on whose equipment and image? randy From jbates at brightok.net Mon Jan 31 15:30:01 2011 From: jbates at brightok.net (Jack Bates) Date: Mon, 31 Jan 2011 15:30:01 -0600 Subject: Level 3's IRR Database In-Reply-To: <m2ipx46aww.wl%randy@psg.com> References: <E65B3ED7E6FCBA48BC3E2FA899729216018E704D@rouwkoop.ac.za> <AANLkTing8yEVoDSxXsa+eTV0xZuv2qkYYA-ahT26hbFx@mail.gmail.com> <4D45CE4A.5090800@foobar.org> <m2sjwa84td.wl%randy@psg.com> <4D461B88.8020506@toonk.nl> <m21v3t8rtd.wl%randy@psg.com> <4D46FCA3.1050509@toonk.nl> <m2ipx46aww.wl%randy@psg.com> Message-ID: <4D4729D9.8090909@brightok.net> On 1/31/2011 3:06 PM, Randy Bush wrote: > some folk will want to drop that, i encourage them to, and have done my > best to see that they have the capability to do so. i am in that camp. > I definitely recommend it as BCP. > others fear rir and black helicopter control of their routing. they may > not want to drop the 'bad' announcement. i tried to document how they > might do so. I think this is fine. It will fix a few minor problems (the problem network will have to be the same length or shorter to be ignored by pref), while keeping RPKI from solving the worst of them. The best of both worlds, IMHO, is to allow all routes were are not specifically contrary to a valid route. ie, if RIR/government makes a route invalid, it will still work, unless there is an equal size or shorter route which is valid (ie, the government not only has to invalidate your route, but they also have to advertise your route or a covering route with a valid ROA). Jack From blake at ispn.net Mon Jan 31 15:31:37 2011 From: blake at ispn.net (Blake Hudson) Date: Mon, 31 Jan 2011 15:31:37 -0600 Subject: IPv6: numbering of point-to-point-links In-Reply-To: <m2bp2w69z1.wl%randy@psg.com> References: <FC64B3384195884588D252343702D23F01854588@ICABEXCCLU01B.int.sonofon.dk> <4E78852B-1695-4DEE-8B4D-C095446F2AEB@xs4all.nl> <m2bp2w69z1.wl%randy@psg.com> Message-ID: <4D472A39.3090907@ispn.net> -------- Original Message -------- Subject: Re: IPv6: numbering of point-to-point-links From: Randy Bush <randy at psg.com> To: Blake Hudson <blake at ispn.net> Cc: nanog at nanog.org Date: Monday, January 31, 2011 3:26:26 PM >> I setup a p2p /127 link and found that BGP would not peer over the >> link; > on whose equipment and image? > > randy This was with a cisco 7200 - IOS 12.4 over a HE tunnel. Debugging BGP showed no activity until the interface mask was changed, as if BGP was not active and was not attempting to peer. The remote peer's state would only display as IDLE. After changing the interface mask to /126 peering came up instantly and I did notice some BGP logging that related to the 0 address on the network. From jeffrey.lyon at blacklotus.net Mon Jan 31 15:42:58 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 31 Jan 2011 16:42:58 -0500 Subject: Verizon acquiring Terremark In-Reply-To: <AANLkTimFXwMAnas7XpTmC2cXOV-S2JGu89dChiKGfVek@mail.gmail.com> References: <6EFFEFBAC68377459A2E972105C759EC03539A93@EXVBE005-2.exch005intermedia.net> <AANLkTimFXwMAnas7XpTmC2cXOV-S2JGu89dChiKGfVek@mail.gmail.com> Message-ID: <AANLkTim4no28RBaao_gmO-TgtVSX8Tu_diC_v9wLK5fi@mail.gmail.com> One cannot be owned by a carrier and remain carrier neutral. My two cents, Jeff On Mon, Jan 31, 2011 at 10:50 AM, Scott Howard <scott at doc.net.au> wrote: > >From all accounts it will remain carrier neutral. > > http://www.datacenterknowledge.com/archives/2011/01/28/verizon-terremark-will-remain-carrier-neutral/ > > ?Scott. > > > On Mon, Jan 31, 2011 at 6:38 AM, Ryan Finnesey < > ryan.finnesey at harrierinvestments.com> wrote: > >> With Verizon acquiring Terremark does the group fell the NAPs will >> change from being carrier-neutral environments to pro Verizon? Has >> Verizon acquired carrier-neutral centers in the past? >> >> Cheers >> Ryan >> >> >> >> >> > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From randy at psg.com Mon Jan 31 15:45:17 2011 From: randy at psg.com (Randy Bush) Date: Tue, 01 Feb 2011 06:45:17 +0900 Subject: Level 3's IRR Database In-Reply-To: <4D4729D9.8090909@brightok.net> References: <E65B3ED7E6FCBA48BC3E2FA899729216018E704D@rouwkoop.ac.za> <AANLkTing8yEVoDSxXsa+eTV0xZuv2qkYYA-ahT26hbFx@mail.gmail.com> <4D45CE4A.5090800@foobar.org> <m2sjwa84td.wl%randy@psg.com> <4D461B88.8020506@toonk.nl> <m21v3t8rtd.wl%randy@psg.com> <4D46FCA3.1050509@toonk.nl> <m2ipx46aww.wl%randy@psg.com> <4D4729D9.8090909@brightok.net> Message-ID: <m239o8693m.wl%randy@psg.com> >> others fear rir and black helicopter control of their routing. they >> may not want to drop the 'bad' announcement. i tried to document how >> they might do so. > > I think this is fine. It will fix a few minor problems (the problem > network will have to be the same length or shorter to be ignored by > pref), while keeping RPKI from solving the worst of them. my routing security half agrees. i have another half which fears that we have not completely connected the dots between the egyptian net shut off of their nets and the media interests who own the us government shutting off domain names without a court order. randy From alexb at ripe.net Mon Jan 31 15:48:40 2011 From: alexb at ripe.net (Alex Band) Date: Mon, 31 Jan 2011 22:48:40 +0100 Subject: [arin-announce] ARIN Resource Certification Update In-Reply-To: <23758.1296444328@nsa.vix.com> References: <EE59203D-907A-4AA2-BAE6-AEE7AADAC0A2@arin.net> <0BC31466-09EA-4734-96B2-152453A62B90@arin.net> <FDFF6713-AB2E-4447-A58B-52CD36A6113A@ripe.net> <23824.1296338405@nsa.vix.com> <43932B92-602B-4903-B2D0-F0D160821918@ripe.net> <23758.1296444328@nsa.vix.com> Message-ID: <86145848-20CE-4DCA-A610-F52BE5A2E6FF@ripe.net> On 31 Jan 2011, at 04:25, Paul Vixie wrote: > the reasoning you're describing is what we had in mind when we built DLV > as an early deployment aid for DNSSEC. we had to "break stiction" where > if there were no validators there would be incentive to sign, and if > there were no signatures there would be no incentive to validate. are > you likewise proposing the hosted solution only as an early deployment > aid? We primarily offer hosting it is something our community want. You can now see in the adoption numbers that is true. It makes the entry barrier into the system as low as possible, which ? apart from being a good thing in itself ? aids deployment. > i'm really quite curious as to whether you'll continue operating > an RPKI hosting capability even if it becomes unnec'y (as proved some > day if many operators of all sizes demonstrate capability for up/down). > if so, can you share the reasoning behind that business decision? We're building and maintaining this with membership fees. Why would we keep something operational our members no longer want and need using their money? I sincerely doubt we'll ever get to that point soon, but we'll see. -Alex Band -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1728 bytes Desc: not available URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110131/2587b7fb/attachment.bin> From jbates at brightok.net Mon Jan 31 15:49:28 2011 From: jbates at brightok.net (Jack Bates) Date: Mon, 31 Jan 2011 15:49:28 -0600 Subject: Level 3's IRR Database In-Reply-To: <m239o8693m.wl%randy@psg.com> References: <E65B3ED7E6FCBA48BC3E2FA899729216018E704D@rouwkoop.ac.za> <AANLkTing8yEVoDSxXsa+eTV0xZuv2qkYYA-ahT26hbFx@mail.gmail.com> <4D45CE4A.5090800@foobar.org> <m2sjwa84td.wl%randy@psg.com> <4D461B88.8020506@toonk.nl> <m21v3t8rtd.wl%randy@psg.com> <4D46FCA3.1050509@toonk.nl> <m2ipx46aww.wl%randy@psg.com> <4D4729D9.8090909@brightok.net> <m239o8693m.wl%randy@psg.com> Message-ID: <4D472E68.6070906@brightok.net> On 1/31/2011 3:45 PM, Randy Bush wrote: > i have another half which fears that we have not completely connected > the dots between the egyptian net shut off of their nets and the media > interests who own the us government shutting off domain names without a > court order. > I agree, which is why I had the alternative mechanism. It allows for the best of both worlds, and if an RIR or government want to revoke an roa AND advertise the route themselves with a valid roa, they could easily have just advertised more specific routes to override the valid route. Jack From gary.buhrmaster at gmail.com Mon Jan 31 15:52:19 2011 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Mon, 31 Jan 2011 13:52:19 -0800 Subject: IPv6: numbering of point-to-point-links In-Reply-To: <4D46EDA4.2030907@ispn.net> References: <FC64B3384195884588D252343702D23F01854588@ICABEXCCLU01B.int.sonofon.dk> <4E78852B-1695-4DEE-8B4D-C095446F2AEB@xs4all.nl> <20110124131820.GA10465@vacation.karoshi.com.> <4D3DA762.33E4.0097.1@globalstar.com> <4D46EDA4.2030907@ispn.net> Message-ID: <AANLkTimXvP3dQ-Hp8Fn240Zd2Ca459n=U7QZDkC0_rys@mail.gmail.com> On Mon, Jan 31, 2011 at 09:13, Blake Hudson <blake at ispn.net> wrote: .... > I setup a p2p /127 link and found that BGP would not peer over the link; > Changing to /126 resolved the problem. I never looked into it further > because I had intended to use /126 from the start. My guess is that > while BGP should be a unicast IP, Cisco's implementation uses an anycast > in some cases, disregarding the configured unicast address. > > Just one practical example... I suspect this is very platform/version specific, as I have run BGP on a Cisco 6500 (SXI<mumble>) to a Juniper MX and we had no trouble with a /127 (although prepared to move to a /126 or whatever if needed). As always, your environment will vary. I would open a TAC case on the principal that it should work. From morrowc.lists at gmail.com Mon Jan 31 16:01:26 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 31 Jan 2011 17:01:26 -0500 Subject: Level 3's IRR Database In-Reply-To: <4D4721C0.8090603@toonk.nl> References: <E65B3ED7E6FCBA48BC3E2FA899729216018E704D@rouwkoop.ac.za> <AANLkTing8yEVoDSxXsa+eTV0xZuv2qkYYA-ahT26hbFx@mail.gmail.com> <4D45CE4A.5090800@foobar.org> <m2sjwa84td.wl%randy@psg.com> <4D461B88.8020506@toonk.nl> <m21v3t8rtd.wl%randy@psg.com> <4D46FCA3.1050509@toonk.nl> <AANLkTim2ABoNd-seC6pS_sNUCDxeTrabus4r2+0BkE4M@mail.gmail.com> <4D4721C0.8090603@toonk.nl> Message-ID: <AANLkTi=8eoXYn8Lf7UgJCB4_MXKdb1SCxhpiyF=P5LOk@mail.gmail.com> On Mon, Jan 31, 2011 at 3:55 PM, Andree Toonk <andree+nanog at toonk.nl> wrote: > .-- My secret spy satellite informs me that at 11-01-31 12:11 PM Christopher > Morrow wrote: >> yes, but what is the way forward? > > Not sure, that was my original question: > Are there any suggestions or recommendations for how to handle these cases? So... I think we should keep in mind that rPKI provides some in-protocol (and on-router) certificate checking bits (this is over simplified, on purpose). Those things allow you to validate routing data as you see it on the device, and take some policy steps to react to that decision. The other thing that rPKI gets us to is the ability to create and maintain prefix-list (or equivalent) data for routers in an automatedand verifiable manner. You could validate the prefixes your customers/peers claim to have with some cryptographic assurance... that data is tied to the allocation hierarchy, and it's kept updated by the allocation chain (IANA->RIR->NIR->LIR->EndUser). So, maybe the answer is folks will be able to better/quicker/more-accurately maintain bgp filters and drop this sort of problem in Adj-Rib-In ? -Chris From tme at americafree.tv Mon Jan 31 16:14:47 2011 From: tme at americafree.tv (Marshall Eubanks) Date: Mon, 31 Jan 2011 17:14:47 -0500 Subject: Connectivity status for Egypt In-Reply-To: <33496563.960.1296250642067.JavaMail.franck@franck-martins-macbook-pro.local> References: <33496563.960.1296250642067.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <5EEA5622-9EDA-4FD6-B4BE-F4E2C812A271@americafree.tv> As an update, BGP for Noor.net has been withdrawn. Even the Egyptian stock exchange - egyptse.com - now appears to be off the Internet. DNS for egyptse.com also appears to be down, but Noor.net is definitely withdrawn : dig www.noor.net ; <<>> DiG 9.6.0-APPLE-P2 <<>> www.noor.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15709 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.noor.net. IN A ;; ANSWER SECTION: www.noor.net. 503 IN CNAME noor.net. noor.net. 503 IN A 217.139.227.20 show ip bgp 217.139.227.20 % Network not in table Marshall On Jan 28, 2011, at 4:37 PM, Franck Martin wrote: > If I'm correct, in 2000 in Fiji, the main fiber optic cable from the national provider to the international provider was sabotaged, cutting all communications. Fortunately an Alcatel team was on the island (SCC commissioning) with the right tools and could splice it back in a few hours, otherwise Fiji would have gone dark for days... > > ----- Original Message ----- > From: "Joe Abley" <jabley at hopcount.ca> > To: "Marshall Eubanks" <tme at americafree.tv> > Cc: nanog at nanog.org > Sent: Saturday, 29 January, 2011 7:32:07 AM > Subject: Re: Connectivity status for Egypt > > > On 2011-01-28, at 11:33, Marshall Eubanks wrote: > >> On Jan 28, 2011, at 11:24 AM, Jared Mauch wrote: >> >>> I have seen nation state disconnects where light is lost. >> >> I believe that was the case for Burma, for example. > > It was not the case in Nepal in 2005 though, if I remember correctly. In that case connectivity to the outside was maintained, but access to that connectivity by people inside the country was curtailed. > > > Joe > > > From mpetach at netflight.com Mon Jan 31 16:18:25 2011 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 31 Jan 2011 14:18:25 -0800 Subject: 2011.01.31 NANOG51 day 1 afternoon session notes Message-ID: <AANLkTikB64Bt+Y--=HRsz-HPtos5xPRL6=-YZakgxquB@mail.gmail.com> I've posted my notes from the afternoon sessions, including the lighting talks, at http://kestrel3.netflight.com/2011.01.31-NANOG51-afternoon-notes.txt for those are are following along remotely, or catching up after a good round of meetings at the bar. :) Have fun at the beer and gear--sorry I can't take any notes on the IPv6 deployment experiences panel--I'm sure it would have been interesting reading, given the amount of attention v6 has been getting on the list recently. ^_^ Matt From danny at spesh.com Mon Jan 31 16:41:02 2011 From: danny at spesh.com (Danny O'Brien) Date: Mon, 31 Jan 2011 14:41:02 -0800 Subject: Connectivity status for Egypt In-Reply-To: <5EEA5622-9EDA-4FD6-B4BE-F4E2C812A271@americafree.tv> References: <33496563.960.1296250642067.JavaMail.franck@franck-martins-macbook-pro.local> <5EEA5622-9EDA-4FD6-B4BE-F4E2C812A271@americafree.tv> Message-ID: <AANLkTik10sQzAz8imCU2xmcvUkvc+jHX748qW24Sk5eD@mail.gmail.com> On Mon, Jan 31, 2011 at 2:14 PM, Marshall Eubanks <tme at americafree.tv>wrote: > As an update, BGP for Noor.net has been withdrawn. Even the Egyptian stock > exchange - egyptse.com - now appears to be off the Internet. > > Yep, Noor is now down. Those on the ground with Noor DSL in Cairo contacted their front line support, and they're saying "technical problems" that will take a few hours to fix. Does anyone has a list of routes that are still up, and seem to correlate with Egyptian locations? Andree's last list is here: http://bgpmon.net/egypt-routes-jan29-2011.txt I'm staring at looking glass output to check these remaining routes, and that seems unfair on both those offering those free services, and my own sanity... d. > DNS for egyptse.com also appears to be down, but Noor.net is definitely > withdrawn : > > dig www.noor.net > > ; <<>> DiG 9.6.0-APPLE-P2 <<>> www.noor.net > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15709 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;www.noor.net. IN A > > ;; ANSWER SECTION: > www.noor.net. 503 IN CNAME noor.net. > noor.net. 503 IN A 217.139.227.20 > > show ip bgp 217.139.227.20 > % Network not in table > > > Marshall > > > > On Jan 28, 2011, at 4:37 PM, Franck Martin wrote: > > > If I'm correct, in 2000 in Fiji, the main fiber optic cable from the > national provider to the international provider was sabotaged, cutting all > communications. Fortunately an Alcatel team was on the island (SCC > commissioning) with the right tools and could splice it back in a few hours, > otherwise Fiji would have gone dark for days... > > > > ----- Original Message ----- > > From: "Joe Abley" <jabley at hopcount.ca> > > To: "Marshall Eubanks" <tme at americafree.tv> > > Cc: nanog at nanog.org > > Sent: Saturday, 29 January, 2011 7:32:07 AM > > Subject: Re: Connectivity status for Egypt > > > > > > On 2011-01-28, at 11:33, Marshall Eubanks wrote: > > > >> On Jan 28, 2011, at 11:24 AM, Jared Mauch wrote: > >> > >>> I have seen nation state disconnects where light is lost. > >> > >> I believe that was the case for Burma, for example. > > > > It was not the case in Nepal in 2005 though, if I remember correctly. In > that case connectivity to the outside was maintained, but access to that > connectivity by people inside the country was curtailed. > > > > > > Joe > > > > > > > > > > From robt at cymru.com Mon Jan 31 16:49:17 2011 From: robt at cymru.com (Rob Thomas) Date: Mon, 31 Jan 2011 16:49:17 -0600 Subject: Connectivity status for Egypt In-Reply-To: <AANLkTik10sQzAz8imCU2xmcvUkvc+jHX748qW24Sk5eD@mail.gmail.com> References: <33496563.960.1296250642067.JavaMail.franck@franck-martins-macbook-pro.local> <5EEA5622-9EDA-4FD6-B4BE-F4E2C812A271@americafree.tv> <AANLkTik10sQzAz8imCU2xmcvUkvc+jHX748qW24Sk5eD@mail.gmail.com> Message-ID: <4D473C6D.5050001@cymru.com> Hi, Danny. > Does anyone has a list of routes that are still up, and seem to correlate > with Egyptian locations? Andree's last list is here: > http://bgpmon.net/egypt-routes-jan29-2011.txt We see the following ASNs presently: ASN CC AS Name 6762 | IT | SEABONE-NET TELECOM ITALIA SPARKLE S.p.A. 8452 | IT | TE-AS TE-AS 15834 | EG | Menanet-AS 24863 | EG | LINKdotNET-AS 28045 | DO | Pantel Communications 33782 | EG | BA-AS 33789 | EG | Internet2 36992 | EG | ETISALAT-MISR We saw the count of prefixes decrease from circa 204 to 98. We see the following IPv4 prefixes presently: IPv4 Prefix ASN 41.32.214.0/24 | 8452 41.32.215.0/24 | 8452 41.78.60.0/22 | 6762 41.129.96.0/22 | 24863 41.152.0.0/16 | 36992 41.152.0.0/17 | 36992 41.152.0.0/18 | 36992 41.152.64.0/18 | 36992 41.152.64.0/19 | 36992 41.152.128.0/17 | 36992 41.152.128.0/19 | 36992 41.152.160.0/19 | 36992 41.152.185.0/24 | 36992 41.152.192.0/18 | 36992 41.152.192.0/19 | 36992 41.152.194.0/24 | 36992 41.152.195.0/24 | 36992 41.152.197.0/24 | 36992 41.152.198.0/24 | 36992 41.153.0.0/16 | 36992 41.153.0.0/17 | 36992 41.153.0.0/19 | 36992 41.153.64.0/18 | 36992 41.153.128.0/17 | 36992 41.153.128.0/24 | 36992 41.153.133.0/24 | 36992 41.153.136.0/21 | 36992 41.153.166.0/24 | 36992 41.153.192.0/18 | 36992 41.153.195.0/24 | 36992 41.153.196.0/24 | 36992 41.153.197.0/24 | 36992 41.153.198.0/24 | 36992 41.153.199.0/24 | 36992 41.153.200.0/24 | 36992 41.153.201.0/24 | 36992 41.153.202.0/24 | 36992 41.153.203.0/24 | 36992 41.153.204.0/24 | 36992 41.153.224.0/20 | 36992 41.153.224.0/21 | 36992 41.178.15.0/24 | 24863 41.178.49.0/24 | 24863 41.178.51.0/24 | 24863 41.196.0.0/24 | 24863 41.196.200.0/24 | 24863 41.222.128.0/21 | 36992 41.222.128.0/23 | 36992 41.222.128.0/24 | 36992 41.222.129.0/24 | 36992 41.222.130.0/24 | 36992 41.222.132.0/24 | 36992 41.235.24.0/24 | 8452 62.12.96.0/19 | 15834 62.241.134.0/24 | 24863 81.4.0.0/18 | 15834 81.10.56.0/24 | 8452 81.10.81.0/24 | 8452 81.10.82.0/24 | 8452 81.10.83.0/24 | 8452 81.10.114.0/24 | 8452 81.10.116.0/22 | 8452 81.10.122.0/23 | 8452 81.10.124.0/22 | 8452 81.10.127.0/24 | 8452 81.21.100.0/24 | 33789 81.21.110.0/24 | 33789 82.201.143.0/24 | 24863 84.233.0.0/17 | 36992 163.121.128.0/24 | 8452 163.121.170.0/24 | 8452 163.121.190.0/24 | 8452 163.121.229.0/24 | 8452 195.43.10.0/24 | 24863 195.246.37.0/24 | 24863 195.246.38.0/24 | 24863 196.204.160.0/19 | 33782 196.205.23.0/24 | 24863 196.205.70.0/24 | 24863 196.205.93.0/24 | 24863 196.218.248.0/22 | 8452 196.218.252.0/22 | 8452 196.219.248.0/22 | 8452 196.219.252.0/22 | 8452 197.192.0.0/13 | 36992 197.192.0.0/17 | 36992 197.193.0.0/18 | 36992 197.193.0.0/19 | 36992 197.193.32.0/19 | 36992 197.194.128.0/17 | 36992 197.195.0.0/17 | 36992 212.103.160.0/24 | 8452 212.103.169.0/24 | 8452 213.131.64.0/24 | 24863 213.181.236.0/24 | 33789 213.247.0.0/20 | 28045 213.247.16.0/20 | 28045 217.29.128.0/20 | 15834 Thanks, Rob. -- Rob Thomas Team Cymru https://www.team-cymru.org/ "Say little and do much." M Avot 1:15 From tme at americafree.tv Mon Jan 31 16:51:04 2011 From: tme at americafree.tv (Marshall Eubanks) Date: Mon, 31 Jan 2011 17:51:04 -0500 Subject: Connectivity status for Egypt In-Reply-To: <AANLkTik10sQzAz8imCU2xmcvUkvc+jHX748qW24Sk5eD@mail.gmail.com> References: <33496563.960.1296250642067.JavaMail.franck@franck-martins-macbook-pro.local> <5EEA5622-9EDA-4FD6-B4BE-F4E2C812A271@americafree.tv> <AANLkTik10sQzAz8imCU2xmcvUkvc+jHX748qW24Sk5eD@mail.gmail.com> Message-ID: <7F3E67E7-C267-4872-A4E1-5E0742BA0F05@americafree.tv> On Jan 31, 2011, at 5:41 PM, Danny O'Brien wrote: > On Mon, Jan 31, 2011 at 2:14 PM, Marshall Eubanks <tme at americafree.tv>wrote: > >> As an update, BGP for Noor.net has been withdrawn. Even the Egyptian stock >> exchange - egyptse.com - now appears to be off the Internet. >> >> > Yep, Noor is now down. Collateral damage from all of this, as detailed in http://blog.icann.org/2011/01/status-report-on-the-dns-in-egypt/ is that the Arabic script top-level domain .masr (???) has been unavailable since the 27th, since it is is operated by NTRA of Egypt. Regards Marshall > > Those on the ground with Noor DSL in Cairo contacted their front line > support, and they're saying "technical problems" that will take a few hours > to fix. > > Does anyone has a list of routes that are still up, and seem to correlate > with Egyptian locations? Andree's last list is here: > http://bgpmon.net/egypt-routes-jan29-2011.txt > > I'm staring at looking glass output to check these remaining routes, and > that seems unfair on both those offering those free services, and my own > sanity... > > d. > > > >> DNS for egyptse.com also appears to be down, but Noor.net is definitely >> withdrawn : >> >> dig www.noor.net >> >> ; <<>> DiG 9.6.0-APPLE-P2 <<>> www.noor.net >> ;; global options: +cmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15709 >> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 >> >> ;; QUESTION SECTION: >> ;www.noor.net. IN A >> >> ;; ANSWER SECTION: >> www.noor.net. 503 IN CNAME noor.net. >> noor.net. 503 IN A 217.139.227.20 >> >> show ip bgp 217.139.227.20 >> % Network not in table >> >> >> Marshall >> >> >> >> On Jan 28, 2011, at 4:37 PM, Franck Martin wrote: >> >>> If I'm correct, in 2000 in Fiji, the main fiber optic cable from the >> national provider to the international provider was sabotaged, cutting all >> communications. Fortunately an Alcatel team was on the island (SCC >> commissioning) with the right tools and could splice it back in a few hours, >> otherwise Fiji would have gone dark for days... >>> >>> ----- Original Message ----- >>> From: "Joe Abley" <jabley at hopcount.ca> >>> To: "Marshall Eubanks" <tme at americafree.tv> >>> Cc: nanog at nanog.org >>> Sent: Saturday, 29 January, 2011 7:32:07 AM >>> Subject: Re: Connectivity status for Egypt >>> >>> >>> On 2011-01-28, at 11:33, Marshall Eubanks wrote: >>> >>>> On Jan 28, 2011, at 11:24 AM, Jared Mauch wrote: >>>> >>>>> I have seen nation state disconnects where light is lost. >>>> >>>> I believe that was the case for Burma, for example. >>> >>> It was not the case in Nepal in 2005 though, if I remember correctly. In >> that case connectivity to the outside was maintained, but access to that >> connectivity by people inside the country was curtailed. >>> >>> >>> Joe >>> >>> >>> >> >> >> >> > From randy at psg.com Mon Jan 31 17:18:28 2011 From: randy at psg.com (Randy Bush) Date: Tue, 01 Feb 2011 08:18:28 +0900 Subject: IPv6: numbering of point-to-point-links In-Reply-To: <4D472A39.3090907@ispn.net> References: <FC64B3384195884588D252343702D23F01854588@ICABEXCCLU01B.int.sonofon.dk> <4E78852B-1695-4DEE-8B4D-C095446F2AEB@xs4all.nl> <m2bp2w69z1.wl%randy@psg.com> <4D472A39.3090907@ispn.net> Message-ID: <m2tygo4q7v.wl%randy@psg.com> >>> I setup a p2p /127 link and found that BGP would not peer over the >>> link; >> on whose equipment and image? > This was with a cisco 7200 - IOS 12.4 over a HE tunnel. /me suspects tunnel From randy at psg.com Mon Jan 31 17:21:15 2011 From: randy at psg.com (Randy Bush) Date: Tue, 01 Feb 2011 08:21:15 +0900 Subject: Verizon acquiring Terremark In-Reply-To: <AANLkTim4no28RBaao_gmO-TgtVSX8Tu_diC_v9wLK5fi@mail.gmail.com> References: <6EFFEFBAC68377459A2E972105C759EC03539A93@EXVBE005-2.exch005intermedia.net> <AANLkTimFXwMAnas7XpTmC2cXOV-S2JGu89dChiKGfVek@mail.gmail.com> <AANLkTim4no28RBaao_gmO-TgtVSX8Tu_diC_v9wLK5fi@mail.gmail.com> Message-ID: <m2sjw84q38.wl%randy@psg.com> > One cannot be owned by a carrier and remain carrier neutral. i bet you also don't believe in santa claus randy From bmanning at isi.edu Mon Jan 31 17:25:44 2011 From: bmanning at isi.edu (bill manning) Date: Mon, 31 Jan 2011 15:25:44 -0800 Subject: quietly.... Message-ID: <A3704940-C282-4B4C-807F-8EC61C625F94@isi.edu> 039/8 APNIC 2011-01 whois.apnic.net ALLOCATED 106/8 APNIC 2011-01 whois.apnic.net ALLOCATED ... whimper ... From tme at americafree.tv Mon Jan 31 17:26:42 2011 From: tme at americafree.tv (Marshall Eubanks) Date: Mon, 31 Jan 2011 18:26:42 -0500 Subject: Connectivity status for Egypt In-Reply-To: <4D42C552.30902@ripe.net> References: <AANLkTimUaNCRFhQqBTPM6Z=W7WUfU8fZUFHGjbqXGJsq@mail.gmail.com><4D421BB4.1000909@toonk.nl><9CCC7D46-D578-4BA0-893C-BAE0D170253B@gmail.com><4D4266DD.7000906@gmail.com> <4D4272C9.2080406@bogus.com> <AANLkTin94dPMn_tOPUmqD+wr9oZyqJODvTTCfRxDL8rM@mail.gmail.com> <859604546CD1FF488BDB6EA94C896AFB012807E8@racexchange.race.local> <4D42C552.30902@ripe.net> Message-ID: <ECE237F8-B409-4088-BA76-62785B9F3D9D@americafree.tv> On Jan 28, 2011, at 8:32 AM, Mirjam Kuehne wrote: > Hi, > > We did some analysis of the situation in Egypt using the RIPEstat toolbox (please note, this is a prototype and we're not sure how it will handle a big load): > > http://labs.ripe.net/Members/akvadrako/live_eqyptian_internet_incident_analysis This - specifically http://stat.ripe.net/egypt/ - shows another big spike today, which is presumably when Noor.net was pulled. Marshall > > Mirjam Kuehne > RIPE NCC > > > Carlos Alcantar wrote: >> Looks like you can still make phone calls into Egypt. So it's not totally lights out... >> Carlos Alcantar >> Race Communications / Race Team Member 101 Haskins Way, So. San Francisco, CA. 94080 >> Phone: +1 415 376 3314 Fax: +1 650 246 8901 / carlos *at* race.com / www.race.com >> -----Original Message----- >> From: Paul Ferguson [mailto:fergdawgster at gmail.com] Sent: Thursday, January 27, 2011 11:46 PM >> To: Joel Jaeggli >> Cc: nanog at nanog.org >> Subject: Re: Connectivity status for Egypt >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> On Thu, Jan 27, 2011 at 11:39 PM, Joel Jaeggli <joelja at bogus.com> wrote: >>> On 1/27/11 10:49 PM, Roy wrote: >>>> Moral of the story: Separate facts from assumptions and guesses. I did some Google searches and that region has had large scale disruptions in the past. Several cables follow the same path to the Suez canal and were hit. >>> my links through the region are all fine, but they don't jump off the cable in egypt just pass through. >>> >>>> https://secure.wikimedia.org/wikipedia/en/wiki/2008_submarine_cable_d >>>> isr >>>> uption >>>> >> To my knowledge, no one has reported any cable problems in Norther Africa >> - -- and news of those problems generally travels very fast. :-) >> Also, if there *was* a cable problem on one of the paths through the vicinity, it affect more than just Egypt: >> https://secure.wikimedia.org/wikipedia/en/wiki/File:Cable_map18.svg >> I don't think it takes a leap of imagination to understand what has happened here. >> - - ferg >> -----BEGIN PGP SIGNATURE----- >> Version: PGP Desktop 9.5.3 (Build 5003) >> wj8DBQFNQnQ0q1pz9mNUZTMRAoFQAKCE8P0wINouFWUvW9GFn7FR6XVmOwCdGV/i >> VzTaxnJQOPVqyY2bP8ZraDA= >> =daOC >> -----END PGP SIGNATURE----- >> -- >> "Fergie", a.k.a. Paul Ferguson >> Engineering Architecture for the Internet >> fergdawgster(at)gmail.com >> ferg's tech blog: http://fergdawg.blogspot.com/ > > > From randy at psg.com Mon Jan 31 17:28:56 2011 From: randy at psg.com (Randy Bush) Date: Tue, 01 Feb 2011 08:28:56 +0900 Subject: quietly.... In-Reply-To: <A3704940-C282-4B4C-807F-8EC61C625F94@isi.edu> References: <A3704940-C282-4B4C-807F-8EC61C625F94@isi.edu> Message-ID: <m2r5bs4pqf.wl%randy@psg.com> > 039/8 APNIC 2011-01 whois.apnic.net ALLOCATED > 106/8 APNIC 2011-01 whois.apnic.net ALLOCATED it's been on most of the lists. sunny will probably post to nanog shortly. the announcement is really well phrased, but i will not steal sunny's thunder. randy From mpetach at netflight.com Mon Jan 31 17:30:09 2011 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 31 Jan 2011 15:30:09 -0800 Subject: quietly.... In-Reply-To: <A3704940-C282-4B4C-807F-8EC61C625F94@isi.edu> References: <A3704940-C282-4B4C-807F-8EC61C625F94@isi.edu> Message-ID: <AANLkTi=Op3EGwKtcEN3nXNX3aoLRrKHvy5gZDgeKiSwh@mail.gmail.com> On Mon, Jan 31, 2011 at 3:25 PM, bill manning <bmanning at isi.edu> wrote: > > 039/8 APNIC 2011-01 whois.apnic.net ALLOCATED > 106/8 APNIC 2011-01 whois.apnic.net ALLOCATED > > ... ?whimper ... > Almost a sigh, actually; though in a moment of horrid thread convergence and poor taste, there was some question being tossed around as to whether Egypt's space could be reused, if they're not going to use it after all... :/ Matt From randy at psg.com Mon Jan 31 17:30:15 2011 From: randy at psg.com (Randy Bush) Date: Tue, 01 Feb 2011 08:30:15 +0900 Subject: Level 3's IRR Database In-Reply-To: <8FD816AA-EC8B-4221-BFB4-96BE4A75E3F2@gmail.com> References: <E65B3ED7E6FCBA48BC3E2FA899729216018E704D@rouwkoop.ac.za> <AANLkTing8yEVoDSxXsa+eTV0xZuv2qkYYA-ahT26hbFx@mail.gmail.com> <4D45CE4A.5090800@foobar.org> <m2sjwa84td.wl%randy@psg.com> <4D461B88.8020506@toonk.nl> <m21v3t8rtd.wl%randy@psg.com> <4D46FCA3.1050509@toonk.nl> <AANLkTimUEQmY0RZzB-mSi30WYDYFoa+csJhXjMCvSna8@mail.gmail.com> <A3FBFB4F-457E-40B5-86B6-DD300B829385@ripe.net> <8FD816AA-EC8B-4221-BFB4-96BE4A75E3F2@gmail.com> Message-ID: <m2pqrc4po8.wl%randy@psg.com> > I think the issue is not between valid vs invalid, but that using > route-maps and local preference a "more specific not valid" route > would be used over another "less specific valid" because of the > routing decision process, right? in a word, no please read draft-pmohapat-sidr-pfx-validate randy From carlosm3011 at gmail.com Mon Jan 31 17:36:25 2011 From: carlosm3011 at gmail.com (Carlos Martinez-Cagnazzo) Date: Mon, 31 Jan 2011 21:36:25 -0200 Subject: quietly.... In-Reply-To: <m2r5bs4pqf.wl%randy@psg.com> References: <A3704940-C282-4B4C-807F-8EC61C625F94@isi.edu> <m2r5bs4pqf.wl%randy@psg.com> Message-ID: <AANLkTimqy7LORem3zH8zyPn21J7a-5-3v1jmiDxRvigy@mail.gmail.com> That was it :-) so long IPv4! It's been a great ride! As good old Frank said, "And now, the end is near, we face the final curtain..." cheers! Carlos On Mon, Jan 31, 2011 at 9:28 PM, Randy Bush <randy at psg.com> wrote: >> 039/8 APNIC 2011-01 whois.apnic.net ALLOCATED >> 106/8 APNIC 2011-01 whois.apnic.net ALLOCATED > > it's been on most of the lists. ?sunny will probably post to nanog > shortly. ?the announcement is really well phrased, but i will not steal > sunny's thunder. > > randy > > -- -- ========================= Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net ========================= From andree+nanog at toonk.nl Mon Jan 31 17:44:12 2011 From: andree+nanog at toonk.nl (Andree Toonk) Date: Mon, 31 Jan 2011 15:44:12 -0800 Subject: Connectivity status for Egypt In-Reply-To: <AANLkTik10sQzAz8imCU2xmcvUkvc+jHX748qW24Sk5eD@mail.gmail.com> References: <33496563.960.1296250642067.JavaMail.franck@franck-martins-macbook-pro.local> <5EEA5622-9EDA-4FD6-B4BE-F4E2C812A271@americafree.tv> <AANLkTik10sQzAz8imCU2xmcvUkvc+jHX748qW24Sk5eD@mail.gmail.com> Message-ID: <4D47494C.7020708@toonk.nl> Hi Danny, .-- My secret spy satellite informs me that at 11-01-31 2:41 PM Danny O'Brien wrote: > Does anyone has a list of routes that are still up, and seem to correlate > with Egyptian locations? Andree's last list is here: > http://bgpmon.net/egypt-routes-jan29-2011.txt Here's an updated list: http://www.bgpmon.net/egypt-routes-jan31-2011.txt Also see: http://bgpmon.net/blog/?p=450#lastupdate Cheers, Andree From nathan at atlasnetworks.us Mon Jan 31 17:52:10 2011 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Mon, 31 Jan 2011 23:52:10 +0000 Subject: Connectivity status for Egypt In-Reply-To: <4D47494C.7020708@toonk.nl> References: <33496563.960.1296250642067.JavaMail.franck@franck-martins-macbook-pro.local> <5EEA5622-9EDA-4FD6-B4BE-F4E2C812A271@americafree.tv> <AANLkTik10sQzAz8imCU2xmcvUkvc+jHX748qW24Sk5eD@mail.gmail.com> <4D47494C.7020708@toonk.nl> Message-ID: <8C26A4FDAE599041A13EB499117D3C286B34B1B0@ex-mb-1.corp.atlasnetworks.us> > Here's an updated list: > http://www.bgpmon.net/egypt-routes-jan31-2011.txt Some decent opportunities for route aggregation in that list... From leo.vegoda at icann.org Mon Jan 31 18:02:31 2011 From: leo.vegoda at icann.org (Leo Vegoda) Date: Mon, 31 Jan 2011 16:02:31 -0800 Subject: 39/8 and 106/8 allocated to APNIC Message-ID: <8048924C-8C14-4CC5-99B5-8999F4816AAF@icann.org> Hi, The IANA IPv4 registry has been updated to reflect the allocation of two IPv4 /8 blocks to APNIC in January 2011: 39/8 and 106/8. 39/8 APNIC 2011-01 whois.apnic.net ALLOCATED 106/8 APNIC 2011-01 whois.apnic.net ALLOCATED You can find the IANA IPv4 registry at: http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.txt Please update your filters as appropriate. Only five unallocated unicast IPv4 /8s remain. Regards, Leo Vegoda Number Resources Manager, IANA ICANN From pingwin at gmail.com Mon Jan 31 18:15:33 2011 From: pingwin at gmail.com (Brian Smith) Date: Mon, 31 Jan 2011 19:15:33 -0500 Subject: Collos in Memphis, TN and Louisville, KY? In-Reply-To: <C9678F62.2B0E0%graham@g-rock.net> References: <C9678F62.2B0E0%graham@g-rock.net> Message-ID: <4D4750A5.5070905@gmail.com> I don't of any specifically in both locations, however Peak10 is in Louisville as well as Nashville (if that is close enough). And I've been very happy with them. -- Brian Smith On 01/27/2011 10:08 PM, Graham Wooden wrote: > Hi folks, > > Can anyone recommend any collo's in both Memphis TN and Louisville, KY? > Preferably in their respective downtown areas? > > Thanks mucho, > > -graham > > > From patrickg at layer8llc.com Mon Jan 31 18:20:11 2011 From: patrickg at layer8llc.com (Patrick Greene) Date: Mon, 31 Jan 2011 19:20:11 -0500 Subject: quietly.... In-Reply-To: <AANLkTimqy7LORem3zH8zyPn21J7a-5-3v1jmiDxRvigy@mail.gmail.com> References: <A3704940-C282-4B4C-807F-8EC61C625F94@isi.edu> <m2r5bs4pqf.wl%randy@psg.com> <AANLkTimqy7LORem3zH8zyPn21J7a-5-3v1jmiDxRvigy@mail.gmail.com> Message-ID: <7B53B6890A4C5D4CA107ED85407DDC0E4CF59B6E00@IAD2MBX02.mex02.mlsrvr.com> I thought there are still 5 /8's left in IANA. -----Original Message----- From: Carlos Martinez-Cagnazzo [mailto:carlosm3011 at gmail.com] Sent: Monday, January 31, 2011 4:36 PM To: NANOG Subject: Re: quietly.... That was it :-) so long IPv4! It's been a great ride! As good old Frank said, "And now, the end is near, we face the final curtain..." cheers! Carlos On Mon, Jan 31, 2011 at 9:28 PM, Randy Bush <randy at psg.com> wrote: >> 039/8 APNIC 2011-01 whois.apnic.net ALLOCATED >> 106/8 APNIC 2011-01 whois.apnic.net ALLOCATED > > it's been on most of the lists. ?sunny will probably post to nanog > shortly. ?the announcement is really well phrased, but i will not > steal sunny's thunder. > > randy > > -- -- ========================= Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net ========================= From dorn at hetzel.org Mon Jan 31 18:21:49 2011 From: dorn at hetzel.org (Dorn Hetzel) Date: Mon, 31 Jan 2011 19:21:49 -0500 Subject: quietly.... In-Reply-To: <7B53B6890A4C5D4CA107ED85407DDC0E4CF59B6E00@IAD2MBX02.mex02.mlsrvr.com> References: <A3704940-C282-4B4C-807F-8EC61C625F94@isi.edu> <m2r5bs4pqf.wl%randy@psg.com> <AANLkTimqy7LORem3zH8zyPn21J7a-5-3v1jmiDxRvigy@mail.gmail.com> <7B53B6890A4C5D4CA107ED85407DDC0E4CF59B6E00@IAD2MBX02.mex02.mlsrvr.com> Message-ID: <AANLkTi=r2QKi_gLpU+Jd8pRLbUX79yZVmQkAgT+ox1wg@mail.gmail.com> I seem to recall there is an automatic endgame for those...? On Mon, Jan 31, 2011 at 7:20 PM, Patrick Greene <patrickg at layer8llc.com>wrote: > I thought there are still 5 /8's left in IANA. > > -----Original Message----- > From: Carlos Martinez-Cagnazzo [mailto:carlosm3011 at gmail.com] > Sent: Monday, January 31, 2011 4:36 PM > To: NANOG > Subject: Re: quietly.... > > That was it :-) so long IPv4! It's been a great ride! > > As good old Frank said, "And now, the end is near, we face the final > curtain..." > > cheers! > > Carlos > > On Mon, Jan 31, 2011 at 9:28 PM, Randy Bush <randy at psg.com> wrote: > >> 039/8 APNIC 2011-01 whois.apnic.net ALLOCATED > >> 106/8 APNIC 2011-01 whois.apnic.net ALLOCATED > > > > it's been on most of the lists. sunny will probably post to nanog > > shortly. the announcement is really well phrased, but i will not > > steal sunny's thunder. > > > > randy > > > > > > > > -- > -- > ========================= > Carlos M. Martinez-Cagnazzo > http://www.labs.lacnic.net > ========================= > > > From jbates at brightok.net Mon Jan 31 18:22:26 2011 From: jbates at brightok.net (Jack Bates) Date: Mon, 31 Jan 2011 18:22:26 -0600 Subject: quietly.... In-Reply-To: <7B53B6890A4C5D4CA107ED85407DDC0E4CF59B6E00@IAD2MBX02.mex02.mlsrvr.com> References: <A3704940-C282-4B4C-807F-8EC61C625F94@isi.edu> <m2r5bs4pqf.wl%randy@psg.com> <AANLkTimqy7LORem3zH8zyPn21J7a-5-3v1jmiDxRvigy@mail.gmail.com> <7B53B6890A4C5D4CA107ED85407DDC0E4CF59B6E00@IAD2MBX02.mex02.mlsrvr.com> Message-ID: <4D475242.1000302@brightok.net> On 1/31/2011 6:20 PM, Patrick Greene wrote: > I thought there are still 5 /8's left in IANA. > I thought there was an agreement that when there was only 5 /8's, each RIR would be allocated 1 /8, and IANA would be done. :) Jack From Skeeve at eintellego.net Mon Jan 31 18:26:43 2011 From: Skeeve at eintellego.net (Skeeve Stevens) Date: Tue, 1 Feb 2011 11:26:43 +1100 Subject: quietly.... In-Reply-To: <7B53B6890A4C5D4CA107ED85407DDC0E4CF59B6E00@IAD2MBX02.mex02.mlsrvr.com> Message-ID: <C96D9E53.30CE4%skeeve@eintellego.net> One each of the remaining /8?s will be allocated to each RIR. Once the RIR?s are out of space in their current supply and they only have this 1 /8 left, it will trigger policies relating to how that /8 will be allocated. ...Skeeve -- Skeeve Stevens, CEO eintellego Pty Ltd - The Networking Specialists skeeve at eintellego.net<mailto:skeeve at eintellego.net> / www.eintellego.net Phone: 1300 753 383, Fax: (+612) 8572 9954 Cell +61 (0)414 753 383 / skype://skeeve www.linkedin.com/in/skeeve ; facebook.com/eintellego -- eintellego - The Experts that the Experts call - Juniper - HP Networking - Cisco - Brocade - Arista - Allied Telesis Disclaimer: Limits of Liability and Disclaimer: This message is for the named person's use only. It may contain sensitive and private proprietary or legally privileged information. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. eintellego Pty Ltd and each legal entity in the Tefilah Pty Ltd group of companies reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of any such entity. Any reference to costs, fee quotations, contractual transactions and variations to contract terms is subject to separate confirmation in writing signed by an authorised representative of eintellego. Whilst all efforts are made to safeguard inbound and outbound e-mails, we cannot guarantee that attachments are virus-free or compatible with your systems and do not accept any liability in respect of viruses or computer problems experienced. On 1/02/11 11:20 AM, "Patrick Greene" <patrickg at layer8llc.com<mailto:patrickg at layer8llc.com>> wrote: I thought there are still 5 /8's left in IANA. -----Original Message----- From: Carlos Martinez-Cagnazzo [mailto:carlosm3011 at gmail.com] Sent: Monday, January 31, 2011 4:36 PM To: NANOG Subject: Re: quietly.... That was it :-) so long IPv4! It's been a great ride! As good old Frank said, "And now, the end is near, we face the final curtain..." cheers! Carlos On Mon, Jan 31, 2011 at 9:28 PM, Randy Bush <randy at psg.com<mailto:randy at psg.com>> wrote: 039/8 APNIC 2011-01 whois.apnic.net ALLOCATED 106/8 APNIC 2011-01 whois.apnic.net ALLOCATED it's been on most of the lists. sunny will probably post to nanog shortly. the announcement is really well phrased, but i will not steal sunny's thunder. randy -- -- ========================= Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net ========================= From george.herbert at gmail.com Mon Jan 31 18:27:41 2011 From: george.herbert at gmail.com (George Herbert) Date: Mon, 31 Jan 2011 16:27:41 -0800 Subject: quietly.... In-Reply-To: <7B53B6890A4C5D4CA107ED85407DDC0E4CF59B6E00@IAD2MBX02.mex02.mlsrvr.com> References: <A3704940-C282-4B4C-807F-8EC61C625F94@isi.edu> <m2r5bs4pqf.wl%randy@psg.com> <AANLkTimqy7LORem3zH8zyPn21J7a-5-3v1jmiDxRvigy@mail.gmail.com> <7B53B6890A4C5D4CA107ED85407DDC0E4CF59B6E00@IAD2MBX02.mex02.mlsrvr.com> Message-ID: <AANLkTinL_4mcREb6E+gspAGXkBdmZQFKf_UGR6d-1=PD@mail.gmail.com> The last 5 are, by existing agreement, to be allocated 1 per Regional registry immediately after the other /8s are exhausted. This was agreed to some time ago to ensure that no regional was disadvantaged by timing concerns on applications for space as the IANA exhaustion approached. As that has now happened, all that awaits is for the announcement of which RIR got which remaining /8. "Immediate" doesn't mean today this instant, but by agreement, they're effectively all gone right now. The large woman has walked on stage and is awaiting the orchestra director's starting the music. -george On Mon, Jan 31, 2011 at 4:20 PM, Patrick Greene <patrickg at layer8llc.com> wrote: > I thought there are still 5 /8's left in IANA. > > -----Original Message----- > From: Carlos Martinez-Cagnazzo [mailto:carlosm3011 at gmail.com] > Sent: Monday, January 31, 2011 4:36 PM > To: NANOG > Subject: Re: quietly.... > > That was it :-) so long IPv4! It's been a great ride! > > As good old Frank said, "And now, the end is near, we face the final curtain..." > > cheers! > > Carlos > > On Mon, Jan 31, 2011 at 9:28 PM, Randy Bush <randy at psg.com> wrote: >>> 039/8 APNIC 2011-01 whois.apnic.net ALLOCATED >>> 106/8 APNIC 2011-01 whois.apnic.net ALLOCATED >> >> it's been on most of the lists. ?sunny will probably post to nanog >> shortly. ?the announcement is really well phrased, but i will not >> steal sunny's thunder. >> >> randy >> >> > > > > -- > -- > ========================= > Carlos M. Martinez-Cagnazzo > http://www.labs.lacnic.net > ========================= > > > -- -george william herbert george.herbert at gmail.com From jmamodio at gmail.com Mon Jan 31 18:28:45 2011 From: jmamodio at gmail.com (Jorge Amodio) Date: Mon, 31 Jan 2011 18:28:45 -0600 Subject: quietly.... In-Reply-To: <AANLkTi=Op3EGwKtcEN3nXNX3aoLRrKHvy5gZDgeKiSwh@mail.gmail.com> References: <A3704940-C282-4B4C-807F-8EC61C625F94@isi.edu> <AANLkTi=Op3EGwKtcEN3nXNX3aoLRrKHvy5gZDgeKiSwh@mail.gmail.com> Message-ID: <AANLkTi=3A0Pp5PcvFrD3XZfa6fdM9RNDAXsLXRVNd7QH@mail.gmail.com> > Almost a sigh, actually; though in a moment of horrid thread convergence > and poor taste, there was some question being tossed around as to whether > Egypt's space could ?be reused, if they're not going to use it after all... ?:/ That's sounds like those bad jokes that some jerks tell at a funeral. -J From mpetach at netflight.com Mon Jan 31 18:31:43 2011 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 31 Jan 2011 16:31:43 -0800 Subject: quietly.... In-Reply-To: <4D475242.1000302@brightok.net> References: <A3704940-C282-4B4C-807F-8EC61C625F94@isi.edu> <m2r5bs4pqf.wl%randy@psg.com> <AANLkTimqy7LORem3zH8zyPn21J7a-5-3v1jmiDxRvigy@mail.gmail.com> <7B53B6890A4C5D4CA107ED85407DDC0E4CF59B6E00@IAD2MBX02.mex02.mlsrvr.com> <4D475242.1000302@brightok.net> Message-ID: <AANLkTinRVMvC6hHQU--3X=JHnsVW_4XyeDpvAJFZ_d1c@mail.gmail.com> On Mon, Jan 31, 2011 at 4:22 PM, Jack Bates <jbates at brightok.net> wrote: > On 1/31/2011 6:20 PM, Patrick Greene wrote: >> >> I thought there are still 5 /8's left in IANA. >> > I thought there was an agreement that when there was only 5 /8's, each RIR > would be allocated 1 /8, and IANA would be done. :) > > Jack It's more than just an agreement--it's part of the documented IANA global policy: http://www.icann.org/en/general/allocation-remaining-ipv4-space.htm We're now faction section 2 action. Matt From carlosm3011 at gmail.com Mon Jan 31 19:13:07 2011 From: carlosm3011 at gmail.com (Carlos M. Martinez) Date: Mon, 31 Jan 2011 23:13:07 -0200 Subject: quietly.... In-Reply-To: <7B53B6890A4C5D4CA107ED85407DDC0E4CF59B6E00@IAD2MBX02.mex02.mlsrvr.com> References: <A3704940-C282-4B4C-807F-8EC61C625F94@isi.edu> <m2r5bs4pqf.wl%randy@psg.com> <AANLkTimqy7LORem3zH8zyPn21J7a-5-3v1jmiDxRvigy@mail.gmail.com> <7B53B6890A4C5D4CA107ED85407DDC0E4CF59B6E00@IAD2MBX02.mex02.mlsrvr.com> Message-ID: <4D475E23.5040303@gmail.com> They are effectively gone, will be allocated in coming days or weeks, 1 per RIR. This is per global IANA policy. regards Carlos On 1/31/11 10:20 PM, Patrick Greene wrote: > I thought there are still 5 /8's left in IANA. > > -----Original Message----- > From: Carlos Martinez-Cagnazzo [mailto:carlosm3011 at gmail.com] > Sent: Monday, January 31, 2011 4:36 PM > To: NANOG > Subject: Re: quietly.... > > That was it :-) so long IPv4! It's been a great ride! > > As good old Frank said, "And now, the end is near, we face the final curtain..." > > cheers! > > Carlos > > On Mon, Jan 31, 2011 at 9:28 PM, Randy Bush <randy at psg.com> wrote: >>> 039/8 APNIC 2011-01 whois.apnic.net ALLOCATED >>> 106/8 APNIC 2011-01 whois.apnic.net ALLOCATED >> it's been on most of the lists. sunny will probably post to nanog >> shortly. the announcement is really well phrased, but i will not >> steal sunny's thunder. >> >> randy >> >> > > > -- > -- > ========================= > Carlos M. Martinez-Cagnazzo > http://www.labs.lacnic.net > ========================= From vovan at fakmoymozg.ru Mon Jan 31 20:32:25 2011 From: vovan at fakmoymozg.ru (Vovan) Date: Tue, 01 Feb 2011 05:32:25 +0300 Subject: APNIC description: "unknown" Message-ID: <2bf186b31af8bde4178750bcc83f1f5a@fakmoymozg.ru> Hello, sorry for possibly trite question, but what does this ">>UNKNOWN<<" mean? e.g.: > Network Origin AS Description > 41.222.79.0/24 36938 >>UNKNOWN<< quote from: http://thyme.rand.apnic.net/current/data-add-IANA Cheers, Vladimir From ikiris at gmail.com Mon Jan 31 21:00:53 2011 From: ikiris at gmail.com (Blake Dunlap) Date: Mon, 31 Jan 2011 21:00:53 -0600 Subject: Collos in Memphis, TN and Louisville, KY? In-Reply-To: <4D4750A5.5070905@gmail.com> References: <C9678F62.2B0E0%graham@g-rock.net> <4D4750A5.5070905@gmail.com> Message-ID: <AANLkTinDtEzs2VdKwt=QvuCt3FnPGPJMhFHKA_yb9rgc@mail.gmail.com> If you're looking in Memphis, I would at least try WorldSpice, it is an independent based out of Memphis that I have had a good bit of experience with, know the owner, etc. I say try because I have not personally seen their new data facility, so I cannot affirm what the new space looks like. -Blake (also the Owner's name, coincidentally enough) On Mon, Jan 31, 2011 at 18:15, Brian Smith <pingwin at gmail.com> wrote: > I don't of any specifically in both locations, however Peak10 is in > Louisville as well as Nashville (if that is close enough). And I've been > very happy with them. > > -- > Brian Smith > > > > On 01/27/2011 10:08 PM, Graham Wooden wrote: > >> Hi folks, >> >> Can anyone recommend any collo's in both Memphis TN and Louisville, KY? >> Preferably in their respective downtown areas? >> >> Thanks mucho, >> >> -graham >> >> >> >> > From owen at delong.com Mon Jan 31 21:00:25 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 31 Jan 2011 19:00:25 -0800 Subject: APNIC description: "unknown" In-Reply-To: <2bf186b31af8bde4178750bcc83f1f5a@fakmoymozg.ru> References: <2bf186b31af8bde4178750bcc83f1f5a@fakmoymozg.ru> Message-ID: <75B49EF8-1B3B-46F2-B510-748918047A67@delong.com> On Jan 31, 2011, at 6:32 PM, Vovan wrote: > Hello, > > sorry for possibly trite question, but what does this ">>UNKNOWN<<" mean? e.g.: > > > Network Origin AS Description > > 41.222.79.0/24 36938 >>UNKNOWN<< > > quote from: http://thyme.rand.apnic.net/current/data-add-IANA > > > Cheers, > > Vladimir It's an unallocated address being advertised by an unallocated AS number. Pretty hard to identify a contact for such a route, no? Owen From mysidia at gmail.com Mon Jan 31 21:06:36 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Mon, 31 Jan 2011 21:06:36 -0600 Subject: Verizon acquiring Terremark In-Reply-To: <AANLkTim4no28RBaao_gmO-TgtVSX8Tu_diC_v9wLK5fi@mail.gmail.com> References: <6EFFEFBAC68377459A2E972105C759EC03539A93@EXVBE005-2.exch005intermedia.net> <AANLkTimFXwMAnas7XpTmC2cXOV-S2JGu89dChiKGfVek@mail.gmail.com> <AANLkTim4no28RBaao_gmO-TgtVSX8Tu_diC_v9wLK5fi@mail.gmail.com> Message-ID: <AANLkTinBztKJ-q1HtBbcP29Kvn01emCXqteu+DGFbqj1@mail.gmail.com> On Mon, Jan 31, 2011 at 3:42 PM, Jeffrey Lyon <jeffrey.lyon at blacklotus.net> wrote: > One cannot be owned by a carrier and remain carrier neutral. > My two cents, Agreed. An organization being a fully owned subsidiary of one carrier, and claiming to be completely carrier neutral, is an indelible conflict of interest; a highly suspect claim that cannot be cleared up merely by internal policies. It's easy to tell the media that nothing is changing; textbook PR / perception management stuff, adding a little paint to hide the dings, so new buyers will not be alarmed. But what about years from now? Seems they retain the right to impose requirements, make changes in the future, or give their parent organization preferential treatment; with no real promise not to (at least not that we've seen so far). If they are serious about keeping colocation carrier neutral, they should spin off that business (or spin off the IP carrier / transit business), so that one entity has no governance control or appearance of control of the other. -- -JH From graham at g-rock.net Mon Jan 31 21:27:59 2011 From: graham at g-rock.net (Graham Wooden) Date: Mon, 31 Jan 2011 21:27:59 -0600 Subject: Collos in Memphis, TN and Louisville, KY? In-Reply-To: <AANLkTinDtEzs2VdKwt=QvuCt3FnPGPJMhFHKA_yb9rgc@mail.gmail.com> Message-ID: <C96CD9DF.2B612%graham@g-rock.net> Thanks Blake and Brian. WorldSpice has come up as a potential location in Memphis; can you forward me off-list your contact?s info? Much appreciated. -graham On 1/31/11 9:00 PM, "Blake Dunlap" <ikiris at gmail.com> wrote: > If you're looking in Memphis, I would at least try WorldSpice, it is an > independent based out of Memphis that I have had a good bit of experience > with, know the owner, etc. I say try because I have not personally seen their > new data facility, so I cannot affirm what the new space looks like. > > -Blake (also the Owner's name, coincidentally enough) > > On Mon, Jan 31, 2011 at 18:15, Brian Smith <pingwin at gmail.com> wrote: >> I don't of any specifically in both locations, however Peak10 is in >> Louisville as well as Nashville (if that is close enough). And I've been very >> happy with them. From sethm at rollernet.us Mon Jan 31 21:43:01 2011 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 31 Jan 2011 19:43:01 -0800 Subject: IPv6: numbering of point-to-point-links In-Reply-To: <4D46EDA4.2030907@ispn.net> References: <FC64B3384195884588D252343702D23F01854588@ICABEXCCLU01B.int.sonofon.dk> <4E78852B-1695-4DEE-8B4D-C095446F2AEB@xs4all.nl> <20110124131820.GA10465@vacation.karoshi.com.> <4D3DA762.33E4.0097.1@globalstar.com> <4D46EDA4.2030907@ispn.net> Message-ID: <4D478145.4030001@rollernet.us> On 1/31/11 9:13 AM, Blake Hudson wrote: > > I setup a p2p /127 link and found that BGP would not peer over the link; > Changing to /126 resolved the problem. I never looked into it further > because I had intended to use /126 from the start. My guess is that > while BGP should be a unicast IP, Cisco's implementation uses an anycast > in some cases, disregarding the configured unicast address. > > Just one practical example... > Sprint runs a /127 for my dual stack circuit with BGP; I know their side is Cisco as is mine. ~Seth From beckman at angryox.com Mon Jan 31 21:54:14 2011 From: beckman at angryox.com (Peter Beckman) Date: Mon, 31 Jan 2011 22:54:14 -0500 Subject: Verizon acquiring Terremark In-Reply-To: <AANLkTinBztKJ-q1HtBbcP29Kvn01emCXqteu+DGFbqj1@mail.gmail.com> References: <6EFFEFBAC68377459A2E972105C759EC03539A93@EXVBE005-2.exch005intermedia.net> <AANLkTimFXwMAnas7XpTmC2cXOV-S2JGu89dChiKGfVek@mail.gmail.com> <AANLkTim4no28RBaao_gmO-TgtVSX8Tu_diC_v9wLK5fi@mail.gmail.com> <AANLkTinBztKJ-q1HtBbcP29Kvn01emCXqteu+DGFbqj1@mail.gmail.com> Message-ID: <alpine.BSF.2.00.1101312250100.47306@nog.angryox.com> On Mon, 31 Jan 2011, Jimmy Hess wrote: > On Mon, Jan 31, 2011 at 3:42 PM, Jeffrey Lyon > <jeffrey.lyon at blacklotus.net> wrote: >> One cannot be owned by a carrier and remain carrier neutral. >> My two cents, > > Agreed. An organization being a fully owned subsidiary of one carrier, > and claiming to be completely carrier neutral, is an indelible conflict > of interest; One of my colleagues was discussing this today. http://bit.ly/emZ7uA -> http://www.alcatel-lucent.com/wps/portal/... Equinix has been claiming to have carrier neutral exchanges since Oct 2009. Who is using them and are they, in your opinion, being completely carrier neutral? Maybe it is possible. Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From mysidia at gmail.com Mon Jan 31 21:55:59 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Mon, 31 Jan 2011 21:55:59 -0600 Subject: quietly.... In-Reply-To: <AANLkTimqy7LORem3zH8zyPn21J7a-5-3v1jmiDxRvigy@mail.gmail.com> References: <A3704940-C282-4B4C-807F-8EC61C625F94@isi.edu> <m2r5bs4pqf.wl%randy@psg.com> <AANLkTimqy7LORem3zH8zyPn21J7a-5-3v1jmiDxRvigy@mail.gmail.com> Message-ID: <AANLkTim5ceiLHxbAyi4XWQU1zuN5eEccDGg1iQzb3Wr+@mail.gmail.com> On Mon, Jan 31, 2011 at 5:36 PM, Carlos Martinez-Cagnazzo <carlosm3011 at gmail.com> wrote: > That was it :-) so long IPv4! It's been a great ride! IPv4's not dead yet; even the first RIR exhaustion probable in 3 - 6 months doesn't end the IPv4 ride. There is some hope more IPv4 organizations will start thinking about their plans for establishing connectivity with IPv6; so they can commmunicate with IPv6-only hosts that will begin to emerge later. > As good old Frank said, "And now, the end is near, we face the final curtain..." -- -JH From richard.barnes at gmail.com Mon Jan 31 22:00:56 2011 From: richard.barnes at gmail.com (Richard Barnes) Date: Mon, 31 Jan 2011 23:00:56 -0500 Subject: APNIC description: "unknown" In-Reply-To: <75B49EF8-1B3B-46F2-B510-748918047A67@delong.com> References: <2bf186b31af8bde4178750bcc83f1f5a@fakmoymozg.ru> <75B49EF8-1B3B-46F2-B510-748918047A67@delong.com> Message-ID: <AANLkTinHBcCXzYXQy3R1KfC=vR9kR2qVZ1n-oWETofW_@mail.gmail.com> Some times they're not so anonymous :) 122.200.40.0/21 38272 >>UNKNOWN<< <http://122.200.40.5/> "Sonargaon Online Limited(SOL) is the leading Internet Service Provider in Dhaka" <http://122.200.40.5/pages/contact_us.htm> " 40/1, Rahman Plaza Shahid Faruk Road (4th Floor) Jatrabari, Dhaka Bangladesh Tel : 88-02-7553432 E-mail : info at sonargaononline.net " On Mon, Jan 31, 2011 at 10:00 PM, Owen DeLong <owen at delong.com> wrote: > > On Jan 31, 2011, at 6:32 PM, Vovan wrote: > >> Hello, >> >> sorry for possibly trite question, but what does this ">>UNKNOWN<<" mean? e.g.: >> >> > Network ? ? ? ? ? ?Origin AS ?Description >> > 41.222.79.0/24 ? ? ? 36938 ? ? >>UNKNOWN<< >> >> quote from: http://thyme.rand.apnic.net/current/data-add-IANA >> >> >> Cheers, >> >> Vladimir > > It's an unallocated address being advertised by an unallocated AS number. > > Pretty hard to identify a contact for such a route, no? > > Owen > > > From ernesto at cs.fiu.edu Mon Jan 31 22:00:56 2011 From: ernesto at cs.fiu.edu (Ernie Rubi) Date: Mon, 31 Jan 2011 23:00:56 -0500 Subject: Verizon acquiring Terremark In-Reply-To: <AANLkTinBztKJ-q1HtBbcP29Kvn01emCXqteu+DGFbqj1@mail.gmail.com> References: <6EFFEFBAC68377459A2E972105C759EC03539A93@EXVBE005-2.exch005intermedia.net> <AANLkTimFXwMAnas7XpTmC2cXOV-S2JGu89dChiKGfVek@mail.gmail.com> <AANLkTim4no28RBaao_gmO-TgtVSX8Tu_diC_v9wLK5fi@mail.gmail.com> <AANLkTinBztKJ-q1HtBbcP29Kvn01emCXqteu+DGFbqj1@mail.gmail.com> Message-ID: <C0EE67C6-F059-459B-81C6-D10190BCED10@cs.fiu.edu> Don't take this the wrong way but vote with your feet if you don't like it. Taken to its logical conclusion this is the "no one person or corporate entity is 'neutral'" rationale/argument - so what? For-profit business organizations (both VZ and TMRK are publicly traded for-profit with shareholders and dividends to pay out) engage in competition and cannot be 'neutral' in at least one definition of the word. What does neutral really mean anyways? Terremark has sold, is selling and will continue to sells services, which I am sure they would like you to 'prefer' over others. So off topic on this list... ::sleeps:: On Jan 31, 2011, at 10:06 PM, Jimmy Hess wrote: > On Mon, Jan 31, 2011 at 3:42 PM, Jeffrey Lyon > <jeffrey.lyon at blacklotus.net> wrote: >> One cannot be owned by a carrier and remain carrier neutral. >> My two cents, > > Agreed. An organization being a fully owned subsidiary of one carrier, > and claiming to be completely carrier neutral, is an indelible conflict > of interest; a highly suspect claim that cannot be cleared up merely by > internal policies. It's easy to tell the media that nothing is > changing; textbook > PR / perception management stuff, adding a little paint to hide the dings, > so new buyers will not be alarmed. > > But what about years from now? Seems they retain the right to impose > requirements, make changes in the future, or give their parent > organization preferential treatment; with no real promise not to (at > least not that we've seen so far). If they are serious about keeping > colocation carrier neutral, they should spin off that business (or > spin off the IP carrier / transit business), > so that one entity has no governance control or appearance of control > of the other. > > > -- > -JH Ernesto M. Rubi Sr. Network Engineer AMPATH/CIARA Florida International Univ, Miami Reply-to: ernesto at cs.fiu.edu Cell: 786-282-6783 From jbates at brightok.net Mon Jan 31 22:05:45 2011 From: jbates at brightok.net (Jack Bates) Date: Mon, 31 Jan 2011 22:05:45 -0600 Subject: quietly.... In-Reply-To: <AANLkTim5ceiLHxbAyi4XWQU1zuN5eEccDGg1iQzb3Wr+@mail.gmail.com> References: <A3704940-C282-4B4C-807F-8EC61C625F94@isi.edu> <m2r5bs4pqf.wl%randy@psg.com> <AANLkTimqy7LORem3zH8zyPn21J7a-5-3v1jmiDxRvigy@mail.gmail.com> <AANLkTim5ceiLHxbAyi4XWQU1zuN5eEccDGg1iQzb3Wr+@mail.gmail.com> Message-ID: <4D478699.6030306@brightok.net> On 1/31/2011 9:55 PM, Jimmy Hess wrote: > There is some hope more IPv4 organizations will start thinking about > their plans for establishing connectivity with IPv6; so they can > commmunicate with IPv6-only hosts that will begin to emerge > later. Until the core networks fix their peering relationships, I don't think it matters. My connectivity to google still sucks. Nothing else matters. :) Jack From owen at delong.com Mon Jan 31 22:10:40 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 31 Jan 2011 20:10:40 -0800 Subject: quietly.... In-Reply-To: <AANLkTim5ceiLHxbAyi4XWQU1zuN5eEccDGg1iQzb3Wr+@mail.gmail.com> References: <A3704940-C282-4B4C-807F-8EC61C625F94@isi.edu> <m2r5bs4pqf.wl%randy@psg.com> <AANLkTimqy7LORem3zH8zyPn21J7a-5-3v1jmiDxRvigy@mail.gmail.com> <AANLkTim5ceiLHxbAyi4XWQU1zuN5eEccDGg1iQzb3Wr+@mail.gmail.com> Message-ID: <4D9CB274-76C6-456C-9D1F-F6E8A84C1ADD@delong.com> On Jan 31, 2011, at 7:55 PM, Jimmy Hess wrote: > On Mon, Jan 31, 2011 at 5:36 PM, Carlos Martinez-Cagnazzo > <carlosm3011 at gmail.com> wrote: >> That was it :-) so long IPv4! It's been a great ride! > > IPv4's not dead yet; even the first RIR exhaustion probable in 3 - > 6 months doesn't end the IPv4 ride. > > There is some hope more IPv4 organizations will start thinking about > their plans for establishing connectivity with IPv6; so they can > commmunicate with IPv6-only hosts that will begin to emerge > later. > >> As good old Frank said, "And now, the end is near, we face the final curtain..." > > -- > -JH It may not be dead, but, it's is chain stoking. Owen From jack at crepinc.com Mon Jan 31 22:15:37 2011 From: jack at crepinc.com (Jack Carrozzo) Date: Mon, 31 Jan 2011 22:15:37 -0600 Subject: quietly.... In-Reply-To: <AANLkTim5ceiLHxbAyi4XWQU1zuN5eEccDGg1iQzb3Wr+@mail.gmail.com> References: <A3704940-C282-4B4C-807F-8EC61C625F94@isi.edu> <m2r5bs4pqf.wl%randy@psg.com> <AANLkTimqy7LORem3zH8zyPn21J7a-5-3v1jmiDxRvigy@mail.gmail.com> <AANLkTim5ceiLHxbAyi4XWQU1zuN5eEccDGg1iQzb3Wr+@mail.gmail.com> Message-ID: <AANLkTi=ETaMyoLROe761MQ0FT_RikAM3W+oUR_DjoNiT@mail.gmail.com> On Mon, Jan 31, 2011 at 9:55 PM, Jimmy Hess <mysidia at gmail.com> wrote: > > IPv4's not dead yet; even the first RIR exhaustion probable in 3 - > 6 months doesn't end the IPv4 ride. > > There is some hope more IPv4 organizations will start thinking about > their plans for establishing connectivity with IPv6; so they can > commmunicate with IPv6-only hosts that will begin to emerge > later. > What organizations (eye networks) will do is layer NAT till the cows come home for some years to come. Buckle up! -Jack Carrozzo From owen at delong.com Mon Jan 31 22:14:10 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 31 Jan 2011 20:14:10 -0800 Subject: APNIC description: "unknown" In-Reply-To: <AANLkTinHBcCXzYXQy3R1KfC=vR9kR2qVZ1n-oWETofW_@mail.gmail.com> References: <2bf186b31af8bde4178750bcc83f1f5a@fakmoymozg.ru> <75B49EF8-1B3B-46F2-B510-748918047A67@delong.com> <AANLkTinHBcCXzYXQy3R1KfC=vR9kR2qVZ1n-oWETofW_@mail.gmail.com> Message-ID: <2553C3FE-25D3-4B14-93C1-47BDA3330098@delong.com> Interesting... "The Leadig Provider in Dhaka" is using hijacked addresses. Owen On Jan 31, 2011, at 8:00 PM, Richard Barnes wrote: > Some times they're not so anonymous :) > > 122.200.40.0/21 38272 >>UNKNOWN<< > > <http://122.200.40.5/> > > "Sonargaon Online Limited(SOL) is the leading Internet Service > Provider in Dhaka" > > <http://122.200.40.5/pages/contact_us.htm> > > " > 40/1, Rahman Plaza > > Shahid Faruk Road (4th Floor) > > Jatrabari, Dhaka > > Bangladesh > > Tel : 88-02-7553432 > > E-mail : info at sonargaononline.net > " > > > > > On Mon, Jan 31, 2011 at 10:00 PM, Owen DeLong <owen at delong.com> wrote: >> >> On Jan 31, 2011, at 6:32 PM, Vovan wrote: >> >>> Hello, >>> >>> sorry for possibly trite question, but what does this ">>UNKNOWN<<" mean? e.g.: >>> >>>> Network Origin AS Description >>>> 41.222.79.0/24 36938 >>UNKNOWN<< >>> >>> quote from: http://thyme.rand.apnic.net/current/data-add-IANA >>> >>> >>> Cheers, >>> >>> Vladimir >> >> It's an unallocated address being advertised by an unallocated AS number. >> >> Pretty hard to identify a contact for such a route, no? >> >> Owen >> >> >> From mysidia at gmail.com Mon Jan 31 22:25:14 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Mon, 31 Jan 2011 22:25:14 -0600 Subject: Verizon acquiring Terremark In-Reply-To: <C0EE67C6-F059-459B-81C6-D10190BCED10@cs.fiu.edu> References: <6EFFEFBAC68377459A2E972105C759EC03539A93@EXVBE005-2.exch005intermedia.net> <AANLkTimFXwMAnas7XpTmC2cXOV-S2JGu89dChiKGfVek@mail.gmail.com> <AANLkTim4no28RBaao_gmO-TgtVSX8Tu_diC_v9wLK5fi@mail.gmail.com> <AANLkTinBztKJ-q1HtBbcP29Kvn01emCXqteu+DGFbqj1@mail.gmail.com> <C0EE67C6-F059-459B-81C6-D10190BCED10@cs.fiu.edu> Message-ID: <AANLkTim2GePE4O7FYn2KCLJc3s2dRNVE9e8=-k8_jvci@mail.gmail.com> On Mon, Jan 31, 2011 at 10:00 PM, Ernie Rubi <ernesto at cs.fiu.edu> wrote: [snip] > shareholders and dividends to pay out) engage in competition and cannot be > 'neutral' in at least one definition of the word. There is nothing wrong with a non-neutral facility, being a non-neutral operator of a facility, or locating at a non-neutral facility. The thing I wouldn't like is saying something is neutral, and creating circumstances that will make it impossible for it to stay true. > What does neutral really mean anyways? ?Terremark has sold, is selling and It is the same concept as network neutrality. An example of a non-neutral IP network is one where a competitor's website or service is blocked by the network operator. A facility is carrier neutral if it is operated by an independent organization. An example of a non-neutral exchange is one that only allows specific tenants to connect to other tenants; other tenants besides the chosen ones are forbidden from connecting to anyone besides a preferred tenant, or have to pay higher rates for each connection to another provider who is not a 'preferred' tenant. -- -JH From morrowc.lists at gmail.com Mon Jan 31 22:29:24 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 31 Jan 2011 23:29:24 -0500 Subject: APNIC description: "unknown" In-Reply-To: <2553C3FE-25D3-4B14-93C1-47BDA3330098@delong.com> References: <2bf186b31af8bde4178750bcc83f1f5a@fakmoymozg.ru> <75B49EF8-1B3B-46F2-B510-748918047A67@delong.com> <AANLkTinHBcCXzYXQy3R1KfC=vR9kR2qVZ1n-oWETofW_@mail.gmail.com> <2553C3FE-25D3-4B14-93C1-47BDA3330098@delong.com> Message-ID: <AANLkTik+5bKiUBiF4ucJuMf7KeOopyxp8r=b0_+MA2Tj@mail.gmail.com> On Mon, Jan 31, 2011 at 11:14 PM, Owen DeLong <owen at delong.com> wrote: > Interesting... "The Leadig Provider in Dhaka" is using hijacked addresses. .... botswana (not the same direct area. but one I happened to notice this same thing happening with this weekend) ;; QUESTION SECTION: ;bw. IN NS ;; ANSWER SECTION: bw. 86400 IN NS ns4.btc.bw. bw. 86400 IN NS rain.psg.com. bw. 86400 IN NS vpsm.btc.bw. bw. 86400 IN NS hippo.ru.ac.za. bw. 86400 IN NS bw.auth-servers.net. bw. 86400 IN NS ns1.btc.bw. ns4.btc.bw. 32809 IN A 168.167.253.20 ns1.btc.bw. 32735 IN A 168.167.168.34 NetRange: 168.167.0.0 - 168.167.255.255 CIDR: 168.167.0.0/16 OriginAS: NetName: AFRINIC-168-167-0-0 NetHandle: NET-168-167-0-0-1 Parent: NET-168-0-0-0-0 NetType: Transferred to AfriNIC Comment: This IP address range is under AFRINIC responsibility. Comment: Please see http://www.afrinic.net/ for further details, Comment: or check the WHOIS server located at whois.afrinic.net. RegDate: 2005-02-21 Updated: 2005-02-21 Ref: http://whois.arin.net/rest/net/NET-168-167-0-0-1 OrgName: African Network Information Center OrgId: AFRINIC Address: Level 11ABC Address: Raffles Tower Address: Lot 19, Cybercity City: Ebene StateProv: PostalCode: Country: MU RegDate: 2004-05-17 Updated: 2010-06-28 Comment: AfriNIC - http://www.afrinic.net Comment: The African & Indian Ocean Internet Registry Seems like Afrinic has some records-keeping-issues... -chris > Owen > > On Jan 31, 2011, at 8:00 PM, Richard Barnes wrote: > >> Some times they're not so anonymous ?:) >> >> 122.200.40.0/21 ? ? ?38272 ? ? >>UNKNOWN<< >> >> <http://122.200.40.5/> >> >> "Sonargaon Online Limited(SOL) is the leading Internet Service >> Provider in Dhaka" >> >> <http://122.200.40.5/pages/contact_us.htm> >> >> " >> 40/1, Rahman Plaza >> >> Shahid Faruk Road (4th Floor) >> >> Jatrabari, Dhaka >> >> Bangladesh >> >> Tel : 88-02-7553432 >> >> E-mail : info at sonargaononline.net >> " >> >> >> >> >> On Mon, Jan 31, 2011 at 10:00 PM, Owen DeLong <owen at delong.com> wrote: >>> >>> On Jan 31, 2011, at 6:32 PM, Vovan wrote: >>> >>>> Hello, >>>> >>>> sorry for possibly trite question, but what does this ">>UNKNOWN<<" mean? e.g.: >>>> >>>>> Network ? ? ? ? ? ?Origin AS ?Description >>>>> 41.222.79.0/24 ? ? ? 36938 ? ? >>UNKNOWN<< >>>> >>>> quote from: http://thyme.rand.apnic.net/current/data-add-IANA >>>> >>>> >>>> Cheers, >>>> >>>> Vladimir >>> >>> It's an unallocated address being advertised by an unallocated AS number. >>> >>> Pretty hard to identify a contact for such a route, no? >>> >>> Owen >>> >>> >>> > > > From jbaino at gmail.com Mon Jan 31 22:31:43 2011 From: jbaino at gmail.com (Jeremy) Date: Mon, 31 Jan 2011 22:31:43 -0600 Subject: quietly.... In-Reply-To: <AANLkTi=ETaMyoLROe761MQ0FT_RikAM3W+oUR_DjoNiT@mail.gmail.com> References: <A3704940-C282-4B4C-807F-8EC61C625F94@isi.edu> <m2r5bs4pqf.wl%randy@psg.com> <AANLkTimqy7LORem3zH8zyPn21J7a-5-3v1jmiDxRvigy@mail.gmail.com> <AANLkTim5ceiLHxbAyi4XWQU1zuN5eEccDGg1iQzb3Wr+@mail.gmail.com> <AANLkTi=ETaMyoLROe761MQ0FT_RikAM3W+oUR_DjoNiT@mail.gmail.com> Message-ID: <AANLkTi=d8uBPRVBoN0U6jntz9o2da17D2w6DuE-cKwhS@mail.gmail.com> Has there been any discussion about allocating the Class E blocks? If this doesn't count as "future use" what does? (Yes, I realize this doesn't *fix* the problem here) -Jeremy On Mon, Jan 31, 2011 at 10:15 PM, Jack Carrozzo <jack at crepinc.com> wrote: > On Mon, Jan 31, 2011 at 9:55 PM, Jimmy Hess <mysidia at gmail.com> wrote: > > > > > IPv4's not dead yet; even the first RIR exhaustion probable in 3 - > > 6 months doesn't end the IPv4 ride. > > > > There is some hope more IPv4 organizations will start thinking about > > their plans for establishing connectivity with IPv6; so they can > > commmunicate with IPv6-only hosts that will begin to emerge > > later. > > > > What organizations (eye networks) will do is layer NAT till the cows come > home for some years to come. Buckle up! > > -Jack Carrozzo > From franck at genius.com Mon Jan 31 22:33:04 2011 From: franck at genius.com (Franck Martin) Date: Tue, 1 Feb 2011 17:33:04 +1300 (FJST) Subject: APNIC description: "unknown" In-Reply-To: <2553C3FE-25D3-4B14-93C1-47BDA3330098@delong.com> Message-ID: <14343562.1934.1296534782099.JavaMail.franck@franck-martins-macbook-pro.local> and who is the upstream ISP that allows the AS to propagate? http://bgp.he.net/AS36938#_graph4 aut-num: AS37004 as-name: SUBURBAN-AS descr: Sub-Urban Telecom organisation: ORG-ST1-AFRINIC org-name: Suburban Telecom org-type: LIR descr: LIR Xtra Small country: NG address: Plot 30 Blantyre Street address: WUSE II address: ABUJA address: Abuja FCT PO 13235 e-mail: o.adeyemi at suburbantelecom.com e-mail: b.obakpolor at suburbantelecom.com and role: AS3257 Net Admin address: Tinet SpA abuse-mailbox: abuse at tinet.net Who sends them an email? ----- Original Message ----- From: "Owen DeLong" <owen at delong.com> To: "Richard Barnes" <richard.barnes at gmail.com> Cc: "NANOG" <nanog at nanog.org> Sent: Tuesday, 1 February, 2011 5:14:10 PM Subject: Re: APNIC description: "unknown" Interesting... "The Leadig Provider in Dhaka" is using hijacked addresses. Owen On Jan 31, 2011, at 8:00 PM, Richard Barnes wrote: > Some times they're not so anonymous :) > > 122.200.40.0/21 38272 >>UNKNOWN<< > > <http://122.200.40.5/> > > "Sonargaon Online Limited(SOL) is the leading Internet Service > Provider in Dhaka" > > <http://122.200.40.5/pages/contact_us.htm> > > " > 40/1, Rahman Plaza > > Shahid Faruk Road (4th Floor) > > Jatrabari, Dhaka > > Bangladesh > > Tel : 88-02-7553432 > > E-mail : info at sonargaononline.net > " > > > > > On Mon, Jan 31, 2011 at 10:00 PM, Owen DeLong <owen at delong.com> wrote: >> >> On Jan 31, 2011, at 6:32 PM, Vovan wrote: >> >>> Hello, >>> >>> sorry for possibly trite question, but what does this ">>UNKNOWN<<" mean? e.g.: >>> >>>> Network Origin AS Description >>>> 41.222.79.0/24 36938 >>UNKNOWN<< >>> >>> quote from: http://thyme.rand.apnic.net/current/data-add-IANA >>> >>> >>> Cheers, >>> >>> Vladimir >> >> It's an unallocated address being advertised by an unallocated AS number. >> >> Pretty hard to identify a contact for such a route, no? >> >> Owen >> >> >> From jfbeam at gmail.com Mon Jan 31 22:33:29 2011 From: jfbeam at gmail.com (Ricky Beam) Date: Mon, 31 Jan 2011 23:33:29 -0500 Subject: APNIC description: "unknown" In-Reply-To: <2553C3FE-25D3-4B14-93C1-47BDA3330098@delong.com> References: <2bf186b31af8bde4178750bcc83f1f5a@fakmoymozg.ru> <75B49EF8-1B3B-46F2-B510-748918047A67@delong.com> <AANLkTinHBcCXzYXQy3R1KfC=vR9kR2qVZ1n-oWETofW_@mail.gmail.com> <2553C3FE-25D3-4B14-93C1-47BDA3330098@delong.com> Message-ID: <op.vp7ix3c9tfhldh@rbeam.xactional.com> On Mon, 31 Jan 2011 23:14:10 -0500, Owen DeLong <owen at delong.com> wrote: > Interesting... "The Leadig Provider in Dhaka" is using hijacked > addresses. Not according to APNIC... % [whois.apnic.net node-5] % Whois data copyright terms http://www.apnic.net/db/dbcopyright.html inetnum: 122.200.40.0 - 122.200.47.255 netname: SONARGAONONLINE descr: Sonargaon Online Services country: BD ... From morrowc.lists at gmail.com Mon Jan 31 22:33:36 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 31 Jan 2011 23:33:36 -0500 Subject: APNIC description: "unknown" In-Reply-To: <AANLkTik+5bKiUBiF4ucJuMf7KeOopyxp8r=b0_+MA2Tj@mail.gmail.com> References: <2bf186b31af8bde4178750bcc83f1f5a@fakmoymozg.ru> <75B49EF8-1B3B-46F2-B510-748918047A67@delong.com> <AANLkTinHBcCXzYXQy3R1KfC=vR9kR2qVZ1n-oWETofW_@mail.gmail.com> <2553C3FE-25D3-4B14-93C1-47BDA3330098@delong.com> <AANLkTik+5bKiUBiF4ucJuMf7KeOopyxp8r=b0_+MA2Tj@mail.gmail.com> Message-ID: <AANLkTi=tfVYkx-q-mYHOYyBbwoqtH3ymsMkF_o1t4UKt@mail.gmail.com> curses arin-restful-output! $ whois -h whois.afrinic.net 168.167.168.34 % This is the AfriNIC Whois server. % Note: this output has been filtered. % Information related to '168.167.0.0 - 168.167.255.255' inetnum: 168.167.0.0 - 168.167.255.255 netname: BOTSNET descr: Botswana Telecommunications Corporation descr: Independance Avenue, Government Enclave (the 41 block in the original email does just show as allocated to AFRINIC only though) -Chris On Mon, Jan 31, 2011 at 11:29 PM, Christopher Morrow <morrowc.lists at gmail.com> wrote: > On Mon, Jan 31, 2011 at 11:14 PM, Owen DeLong <owen at delong.com> wrote: >> Interesting... "The Leadig Provider in Dhaka" is using hijacked addresses. > > .... botswana (not the same direct area. but one I happened to notice > this same thing happening with this weekend) > > ;; QUESTION SECTION: > ;bw. ? ? ? ? ? ? ? ? ? ? ? ? ? ?IN ? ? ?NS > > ;; ANSWER SECTION: > bw. ? ? ? ? ? ? ? ? ? ? 86400 ? IN ? ? ?NS ? ? ?ns4.btc.bw. > bw. ? ? ? ? ? ? ? ? ? ? 86400 ? IN ? ? ?NS ? ? ?rain.psg.com. > bw. ? ? ? ? ? ? ? ? ? ? 86400 ? IN ? ? ?NS ? ? ?vpsm.btc.bw. > bw. ? ? ? ? ? ? ? ? ? ? 86400 ? IN ? ? ?NS ? ? ?hippo.ru.ac.za. > bw. ? ? ? ? ? ? ? ? ? ? 86400 ? IN ? ? ?NS ? ? ?bw.auth-servers.net. > bw. ? ? ? ? ? ? ? ? ? ? 86400 ? IN ? ? ?NS ? ? ?ns1.btc.bw. > > ns4.btc.bw. ? ? ? ? ? ? 32809 ? IN ? ? ?A ? ? ? 168.167.253.20 > ns1.btc.bw. ? ? ? ? ? ? 32735 ? IN ? ? ?A ? ? ? 168.167.168.34 > > NetRange: ? ? ? 168.167.0.0 - 168.167.255.255 > CIDR: ? ? ? ? ? 168.167.0.0/16 > OriginAS: > NetName: ? ? ? ?AFRINIC-168-167-0-0 > NetHandle: ? ? ?NET-168-167-0-0-1 > Parent: ? ? ? ? NET-168-0-0-0-0 > NetType: ? ? ? ?Transferred to AfriNIC > Comment: ? ? ? ?This IP address range is under AFRINIC responsibility. > Comment: ? ? ? ?Please see http://www.afrinic.net/ for further details, > Comment: ? ? ? ?or check the WHOIS server located at whois.afrinic.net. > RegDate: ? ? ? ?2005-02-21 > Updated: ? ? ? ?2005-02-21 > Ref: ? ? ? ? ? ?http://whois.arin.net/rest/net/NET-168-167-0-0-1 > > OrgName: ? ? ? ?African Network Information Center > OrgId: ? ? ? ? ?AFRINIC > Address: ? ? ? ?Level 11ABC > Address: ? ? ? ?Raffles Tower > Address: ? ? ? ?Lot 19, Cybercity > City: ? ? ? ? ? Ebene > StateProv: > PostalCode: > Country: ? ? ? ?MU > RegDate: ? ? ? ?2004-05-17 > Updated: ? ? ? ?2010-06-28 > Comment: ? ? ? ?AfriNIC - http://www.afrinic.net > Comment: ? ? ? ?The African & Indian Ocean Internet Registry > > Seems like Afrinic has some records-keeping-issues... > > -chris > >> Owen >> >> On Jan 31, 2011, at 8:00 PM, Richard Barnes wrote: >> >>> Some times they're not so anonymous ?:) >>> >>> 122.200.40.0/21 ? ? ?38272 ? ? >>UNKNOWN<< >>> >>> <http://122.200.40.5/> >>> >>> "Sonargaon Online Limited(SOL) is the leading Internet Service >>> Provider in Dhaka" >>> >>> <http://122.200.40.5/pages/contact_us.htm> >>> >>> " >>> 40/1, Rahman Plaza >>> >>> Shahid Faruk Road (4th Floor) >>> >>> Jatrabari, Dhaka >>> >>> Bangladesh >>> >>> Tel : 88-02-7553432 >>> >>> E-mail : info at sonargaononline.net >>> " >>> >>> >>> >>> >>> On Mon, Jan 31, 2011 at 10:00 PM, Owen DeLong <owen at delong.com> wrote: >>>> >>>> On Jan 31, 2011, at 6:32 PM, Vovan wrote: >>>> >>>>> Hello, >>>>> >>>>> sorry for possibly trite question, but what does this ">>UNKNOWN<<" mean? e.g.: >>>>> >>>>>> Network ? ? ? ? ? ?Origin AS ?Description >>>>>> 41.222.79.0/24 ? ? ? 36938 ? ? >>UNKNOWN<< >>>>> >>>>> quote from: http://thyme.rand.apnic.net/current/data-add-IANA >>>>> >>>>> >>>>> Cheers, >>>>> >>>>> Vladimir >>>> >>>> It's an unallocated address being advertised by an unallocated AS number. >>>> >>>> Pretty hard to identify a contact for such a route, no? >>>> >>>> Owen >>>> >>>> >>>> >> >> >> > From owen at delong.com Mon Jan 31 22:29:16 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 31 Jan 2011 20:29:16 -0800 Subject: quietly.... In-Reply-To: <AANLkTi=ETaMyoLROe761MQ0FT_RikAM3W+oUR_DjoNiT@mail.gmail.com> References: <A3704940-C282-4B4C-807F-8EC61C625F94@isi.edu> <m2r5bs4pqf.wl%randy@psg.com> <AANLkTimqy7LORem3zH8zyPn21J7a-5-3v1jmiDxRvigy@mail.gmail.com> <AANLkTim5ceiLHxbAyi4XWQU1zuN5eEccDGg1iQzb3Wr+@mail.gmail.com> <AANLkTi=ETaMyoLROe761MQ0FT_RikAM3W+oUR_DjoNiT@mail.gmail.com> Message-ID: <DA8E1DD5-FB77-49B7-B9F0-E07F3BEF0B12@delong.com> On Jan 31, 2011, at 8:15 PM, Jack Carrozzo wrote: > On Mon, Jan 31, 2011 at 9:55 PM, Jimmy Hess <mysidia at gmail.com> wrote: > >> >> IPv4's not dead yet; even the first RIR exhaustion probable in 3 - >> 6 months doesn't end the IPv4 ride. >> >> There is some hope more IPv4 organizations will start thinking about >> their plans for establishing connectivity with IPv6; so they can >> commmunicate with IPv6-only hosts that will begin to emerge >> later. >> > > What organizations (eye networks) will do is layer NAT till the cows come > home for some years to come. Buckle up! > > -Jack Carrozzo All of the eye networks that have looked at this have realized the following things that you apparently have not: 1. Layering NAT beyond 2 deep (one provider, one subscriber) doesn't help. 2. NAT444 will break lots of things that work in current NAT44. 3. Users subjected to this environment after experiencing the limited brokenness of NAT44 or full access to the internet will not be happy. 4. Maintaining NAT444 environments will be a support headache and a costly arms race of deployments and management. 5. IPv6 will cost a lot less than NAT444 as soon as they can get their subscribers fully deployed and is a much more desirable alternative. Owen From owen at delong.com Mon Jan 31 22:38:11 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 31 Jan 2011 20:38:11 -0800 Subject: APNIC description: "unknown" In-Reply-To: <op.vp7ix3c9tfhldh@rbeam.xactional.com> References: <2bf186b31af8bde4178750bcc83f1f5a@fakmoymozg.ru> <75B49EF8-1B3B-46F2-B510-748918047A67@delong.com> <AANLkTinHBcCXzYXQy3R1KfC=vR9kR2qVZ1n-oWETofW_@mail.gmail.com> <2553C3FE-25D3-4B14-93C1-47BDA3330098@delong.com> <op.vp7ix3c9tfhldh@rbeam.xactional.com> Message-ID: <8E38FBD4-8CED-4B2F-85BA-E258FEF0E7E8@delong.com> On Jan 31, 2011, at 8:33 PM, Ricky Beam wrote: > On Mon, 31 Jan 2011 23:14:10 -0500, Owen DeLong <owen at delong.com> wrote: >> Interesting... "The Leadig Provider in Dhaka" is using hijacked addresses. > > Not according to APNIC... > > % [whois.apnic.net node-5] > % Whois data copyright terms http://www.apnic.net/db/dbcopyright.html > > inetnum: 122.200.40.0 - 122.200.47.255 > netname: SONARGAONONLINE > descr: Sonargaon Online Services > country: BD > ... Odd... That's not what I got: [owen-delongs-macbook-pro:~] owen% whois -h whois.apnic.net 122.200.40.5 % [whois.apnic.net node-4] % Whois data copyright terms http://www.apnic.net/db/dbcopyright.html inetnum: 122.0.0.0 - 123.255.255.255 netname: APNIC-AP descr: Asia Pacific Network Information Centre descr: Regional Internet Registry for the Asia-Pacific Region descr: 6 Cordelia Street descr: PO Box 3646 descr: South Brisbane, QLD 4101 descr: Australia country: AU admin-c: HM20-AP tech-c: NO4-AP mnt-by: APNIC-HM mnt-lower: APNIC-HM mnt-irt: IRT-APNIC-AP status: ALLOCATED PORTABLE changed: hm-changed at apnic.net 20060109 changed: hm-changed at apnic.net 20101116 changed: hm-changed at apnic.net 20110114 source: APNIC role: APNIC Hostmaster address: 6 Cordelia Street address: South Brisbane address: QLD 4101 country: AU phone: +61 7 3858 3100 fax-no: +61 7 3858 3199 e-mail: helpdesk at apnic.net admin-c: AMS11-AP tech-c: AH256-AP nic-hdl: HM20-AP remarks: Administrator for APNIC notify: dbmon at apnic.net mnt-by: MAINT-APNIC-AP changed: hm-changed at apnic.net 19981111 changed: dbmon at apnic.net 19990702 changed: hm-changed at apnic.net 20020211 changed: hm-changed at apnic.net 20070612 changed: hm-changed at apnic.net 20100217 changed: hm-changed at apnic.net 20101217 source: APNIC person: APNIC Network Operations address: 6 Cordelia Street address: South Brisbane address: QLD 4101 country: AU phone: +61 7 3858 3100 fax-no: +61 7 3858 3199 e-mail: netops at apnic.net nic-hdl: NO4-AP remarks: Administrator for APNIC Network Operations notify: netops at apnic.net mnt-by: MAINT-APNIC-AP changed: netops at apnic.net 19981111 changed: hostmaster at apnic.net 20020211 changed: hm-changed at apnic.net 20081205 changed: hm-changed at apnic.net 20101217 source: APNIC My apologies for any confusion. Owen From owen at delong.com Mon Jan 31 22:38:51 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 31 Jan 2011 20:38:51 -0800 Subject: quietly.... In-Reply-To: <AANLkTi=d8uBPRVBoN0U6jntz9o2da17D2w6DuE-cKwhS@mail.gmail.com> References: <A3704940-C282-4B4C-807F-8EC61C625F94@isi.edu> <m2r5bs4pqf.wl%randy@psg.com> <AANLkTimqy7LORem3zH8zyPn21J7a-5-3v1jmiDxRvigy@mail.gmail.com> <AANLkTim5ceiLHxbAyi4XWQU1zuN5eEccDGg1iQzb3Wr+@mail.gmail.com> <AANLkTi=ETaMyoLROe761MQ0FT_RikAM3W+oUR_DjoNiT@mail.gmail.com> <AANLkTi=d8uBPRVBoN0U6jntz9o2da17D2w6DuE-cKwhS@mail.gmail.com> Message-ID: <CE295659-26AC-46C4-9983-11A295FDFA15@delong.com> Discussed, Disgusted, and Dismissed. The E space would take more software upgrades to existing systems than just deploying IPv6. Owen On Jan 31, 2011, at 8:31 PM, Jeremy wrote: > Has there been any discussion about allocating the Class E blocks? If this > doesn't count as "future use" what does? (Yes, I realize this doesn't *fix* > the problem here) > > -Jeremy > > On Mon, Jan 31, 2011 at 10:15 PM, Jack Carrozzo <jack at crepinc.com> wrote: > >> On Mon, Jan 31, 2011 at 9:55 PM, Jimmy Hess <mysidia at gmail.com> wrote: >> >>> >>> IPv4's not dead yet; even the first RIR exhaustion probable in 3 - >>> 6 months doesn't end the IPv4 ride. >>> >>> There is some hope more IPv4 organizations will start thinking about >>> their plans for establishing connectivity with IPv6; so they can >>> commmunicate with IPv6-only hosts that will begin to emerge >>> later. >>> >> >> What organizations (eye networks) will do is layer NAT till the cows come >> home for some years to come. Buckle up! >> >> -Jack Carrozzo >> From fergdawgster at gmail.com Mon Jan 31 22:52:57 2011 From: fergdawgster at gmail.com (Paul Ferguson) Date: Mon, 31 Jan 2011 20:52:57 -0800 Subject: APNIC description: "unknown" In-Reply-To: <8E38FBD4-8CED-4B2F-85BA-E258FEF0E7E8@delong.com> References: <2bf186b31af8bde4178750bcc83f1f5a@fakmoymozg.ru> <75B49EF8-1B3B-46F2-B510-748918047A67@delong.com> <AANLkTinHBcCXzYXQy3R1KfC=vR9kR2qVZ1n-oWETofW_@mail.gmail.com> <2553C3FE-25D3-4B14-93C1-47BDA3330098@delong.com> <op.vp7ix3c9tfhldh@rbeam.xactional.com> <8E38FBD4-8CED-4B2F-85BA-E258FEF0E7E8@delong.com> Message-ID: <AANLkTim=yrUrCb3a40TnDBAx4rcRq8nz=DcU4+4=0cos@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 FYI: Results: % [whois.apnic.net node-3] % Whois data copyright terms http://www.apnic.net/db/dbcopyright.html inetnum: 122.200.40.0 - 122.200.47.255 netname: SONARGAONONLINE descr: Sonargaon Online Services country: BD admin-c: SI109-AP tech-c: SI109-AP remarks: -+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+ remarks: This object can only be updated by APNIC hostmasters. remarks: To update this object, please contact APNIC remarks: hostmasters and include your organisation's account remarks: name in the subject line. remarks: -+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+ changed: hm-changed at apnic.net 20061023 mnt-by: APNIC-HM mnt-lower: MAINT-BD-SONARGAONONLINE mnt-routes: MAINT-BD-SONARGAONONLINE status: ALLOCATED PORTABLE source: APNIC person: Shahidul Islam nic-hdl: SI109-AP e-mail: admin at sonargaononline.net address: Sonargaon Online Services address: 40/1 Shahid Faruque road, address: South Jatrabari, Dhaka 1204. phone: +88-02-7550787 fax-no: +88-0152-486501 country: BD changed: saleh at deshonline.net 20060925 mnt-by: MAINT-NEW source: APNIC - - ferg On Mon, Jan 31, 2011 at 8:38 PM, Owen DeLong <owen at delong.com> wrote: > > On Jan 31, 2011, at 8:33 PM, Ricky Beam wrote: > >> On Mon, 31 Jan 2011 23:14:10 -0500, Owen DeLong <owen at delong.com> wrote: >>> Interesting... "The Leadig Provider in Dhaka" is using hijacked >>> addresses. >> >> Not according to APNIC... >> >> % [whois.apnic.net node-5] >> % Whois data copyright terms http://www.apnic.net/db/dbcopyright.html >> >> inetnum: 122.200.40.0 - 122.200.47.255 >> netname: SONARGAONONLINE >> descr: Sonargaon Online Services >> country: BD >> ... > > Odd... That's not what I got: > > [owen-delongs-macbook-pro:~] owen% whois -h whois.apnic.net 122.200.40.5 > % [whois.apnic.net node-4] > % Whois data copyright terms http://www.apnic.net/db/dbcopyright.html > > inetnum: 122.0.0.0 - 123.255.255.255 > netname: APNIC-AP > descr: Asia Pacific Network Information Centre > descr: Regional Internet Registry for the Asia-Pacific Region > descr: 6 Cordelia Street > descr: PO Box 3646 > descr: South Brisbane, QLD 4101 > descr: Australia > country: AU > admin-c: HM20-AP > tech-c: NO4-AP > mnt-by: APNIC-HM > mnt-lower: APNIC-HM > mnt-irt: IRT-APNIC-AP > status: ALLOCATED PORTABLE > changed: hm-changed at apnic.net 20060109 > changed: hm-changed at apnic.net 20101116 > changed: hm-changed at apnic.net 20110114 > source: APNIC > > role: APNIC Hostmaster > address: 6 Cordelia Street > address: South Brisbane > address: QLD 4101 > country: AU > phone: +61 7 3858 3100 > fax-no: +61 7 3858 3199 > e-mail: helpdesk at apnic.net > admin-c: AMS11-AP > tech-c: AH256-AP > nic-hdl: HM20-AP > remarks: Administrator for APNIC > notify: dbmon at apnic.net > mnt-by: MAINT-APNIC-AP > changed: hm-changed at apnic.net 19981111 > changed: dbmon at apnic.net 19990702 > changed: hm-changed at apnic.net 20020211 > changed: hm-changed at apnic.net 20070612 > changed: hm-changed at apnic.net 20100217 > changed: hm-changed at apnic.net 20101217 > source: APNIC > > person: APNIC Network Operations > address: 6 Cordelia Street > address: South Brisbane > address: QLD 4101 > country: AU > phone: +61 7 3858 3100 > fax-no: +61 7 3858 3199 > e-mail: netops at apnic.net > nic-hdl: NO4-AP > remarks: Administrator for APNIC Network Operations > notify: netops at apnic.net > mnt-by: MAINT-APNIC-AP > changed: netops at apnic.net 19981111 > changed: hostmaster at apnic.net 20020211 > changed: hm-changed at apnic.net 20081205 > changed: hm-changed at apnic.net 20101217 > source: APNIC > > My apologies for any confusion. > > Owen > > -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFNR5GVq1pz9mNUZTMRAgJRAKDxMal+5IUv+9VHtlTHcCbX1p0UfwCgqcFH J0SH1yd7Vn1zmOVPq67Zzx8= =xv1i -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson ?Engineering Architecture for the Internet ?fergdawgster(at)gmail.com ?ferg's tech blog: http://fergdawg.blogspot.com/ From millnert at gmail.com Mon Jan 31 23:00:08 2011 From: millnert at gmail.com (Martin Millnert) Date: Tue, 1 Feb 2011 00:00:08 -0500 Subject: quietly.... In-Reply-To: <AANLkTi=d8uBPRVBoN0U6jntz9o2da17D2w6DuE-cKwhS@mail.gmail.com> References: <A3704940-C282-4B4C-807F-8EC61C625F94@isi.edu> <m2r5bs4pqf.wl%randy@psg.com> <AANLkTimqy7LORem3zH8zyPn21J7a-5-3v1jmiDxRvigy@mail.gmail.com> <AANLkTim5ceiLHxbAyi4XWQU1zuN5eEccDGg1iQzb3Wr+@mail.gmail.com> <AANLkTi=ETaMyoLROe761MQ0FT_RikAM3W+oUR_DjoNiT@mail.gmail.com> <AANLkTi=d8uBPRVBoN0U6jntz9o2da17D2w6DuE-cKwhS@mail.gmail.com> Message-ID: <AANLkTinrhPYXvtS5wtA0PuhtEmi3f4tN9J5KOCBF1a=5@mail.gmail.com> Jeremy, I have not heard of any IP stack that is built to accept 240/4. Neither Linux 2.6.37 nor Windows 7 accepts it, and let's not think about all routers, including CPE:s, out there. The logic goes: You are many orders of magnitudes more likely to get v6 off the ground, than 240/4 or 224/4 as unicast IPv4. 224/3 will never be very usable as public v4 space since every non-upgraded host on the Internet will be unable to send packets to them, eg, for every additional host you introduce with these addresses the worse the reachability situation becomes for the v4 Internet. Notably, this is the inverse of what happens when you introduce more hosts with native, proper IPv6, in the IPv6-Internet. Cheers, Martin On Mon, Jan 31, 2011 at 11:31 PM, Jeremy <jbaino at gmail.com> wrote: > Has there been any discussion about allocating the Class E blocks? If this > doesn't count as "future use" what does? (Yes, I realize this doesn't *fix* > the problem here) > > -Jeremy > > On Mon, Jan 31, 2011 at 10:15 PM, Jack Carrozzo <jack at crepinc.com> wrote: > >> On Mon, Jan 31, 2011 at 9:55 PM, Jimmy Hess <mysidia at gmail.com> wrote: >> >> > >> > IPv4's not dead yet; ?even the first ?RIR exhaustion probable in ?3 - >> > 6 months ?doesn't end the IPv4 ride. >> > >> > There is some hope more IPv4 organizations will start thinking about >> > their plans for establishing connectivity with IPv6; ?so they can >> > commmunicate with IPv6-only hosts that will begin to emerge >> > later. >> > >> >> What organizations (eye networks) will do is layer NAT till the cows come >> home for some years to come. Buckle up! >> >> -Jack Carrozzo >> > From swmike at swm.pp.se Mon Jan 31 23:02:07 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 1 Feb 2011 06:02:07 +0100 (CET) Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <AANLkTimoEST0ewMy+DZwGqve-jcq0=oNdK_L2oXv6-Ln@mail.gmail.com> References: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com> <AANLkTimcZavnJN2gqayS2-piDvOAcw_nrJAREJ0EDTjp@mail.gmail.com> <AANLkTikHBb+cyfPxXftb5QZh136D04fkdWFMy3NFhDdi@mail.gmail.com> <4D3FBEA3.6040404@gont.com.ar> <AANLkTimSpkQZ7pW=jb2KB1pndmKBpkug+WtugzOcUGJP@mail.gmail.com> <alpine.DEB.1.10.1101310755340.13151@uplift.swm.pp.se> <AANLkTimoEST0ewMy+DZwGqve-jcq0=oNdK_L2oXv6-Ln@mail.gmail.com> Message-ID: <alpine.DEB.1.10.1101312050150.13151@uplift.swm.pp.se> On Mon, 31 Jan 2011, Per Carlson wrote: > Really? I've tried to duplicate the results in our lab, but I can't > provoke any problems at those numbers. Is it the "other" multicast > traffic that's interfering with ND? It's a hold-queue problem. Normally IPv6 input is around 0.5% CPU on the RP, but due to IPv6 not being supported for SPD and this also seems to cause problems with IPv4 BGP traffic as well, the hold-queue (we raised it a lot) gets full and packets are tail-dropped from the hold-queue, and keepalives being lost. This has been through a full analysis by TAC and their suggestion was to filter non-needed IPv6 multicast, and it completely removed the symptom. We haven't had any major BGP session flaps since. > When pounding the CPU with ~30 times more (5000pps) Neighbour > solicitations and flapping 1000 BGP IPv4 prefixes (out of 51000) every > 5 seconds, I get the following load (worst case): We're getting many tens of thousands of prefixes from AMSIX and this peering router is in our BGP full mesh, so when peers go down, it's a lot of paths to recalculate (most of our IPv4 IBGP full mesh peers are in unique update groups for some reason on this router, that's also being analysed). Even though IOS12000 seems fairly complete as an IPv6 core router, we've been running into more and more problems like this. Cisco has implemented a lot of features but not all and for IOS, they probably never will if I understand correctly. Guess XR is the way to go if one wants to keep it for a few more years... -- Mikael Abrahamsson email: swmike at swm.pp.se From millnert at gmail.com Mon Jan 31 23:03:49 2011 From: millnert at gmail.com (Martin Millnert) Date: Tue, 1 Feb 2011 00:03:49 -0500 Subject: quietly.... In-Reply-To: <AANLkTinrhPYXvtS5wtA0PuhtEmi3f4tN9J5KOCBF1a=5@mail.gmail.com> References: <A3704940-C282-4B4C-807F-8EC61C625F94@isi.edu> <m2r5bs4pqf.wl%randy@psg.com> <AANLkTimqy7LORem3zH8zyPn21J7a-5-3v1jmiDxRvigy@mail.gmail.com> <AANLkTim5ceiLHxbAyi4XWQU1zuN5eEccDGg1iQzb3Wr+@mail.gmail.com> <AANLkTi=ETaMyoLROe761MQ0FT_RikAM3W+oUR_DjoNiT@mail.gmail.com> <AANLkTi=d8uBPRVBoN0U6jntz9o2da17D2w6DuE-cKwhS@mail.gmail.com> <AANLkTinrhPYXvtS5wtA0PuhtEmi3f4tN9J5KOCBF1a=5@mail.gmail.com> Message-ID: <AANLkTimGma+ic98dR6Zv7r+rHdEyGrtC89N7YwrHGhnm@mail.gmail.com> On Tue, Feb 1, 2011 at 12:00 AM, Martin Millnert <millnert at gmail.com> wrote: > Neither Linux 2.6.37 nor Windows 7 accepts it Oops, I was clumpsy there, apologies. When I was testing this, I messed up one of my hosts :/ It seems 240/4 *does* work as unicast v4 in Linux 2.6.37. Then it's easy, just convert everything to Linux. ;) /M From streiner at cluebyfour.org Mon Jan 31 18:49:18 2011 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Mon, 31 Jan 2011 19:49:18 -0500 (EST) Subject: quietly.... In-Reply-To: <AANLkTi=d8uBPRVBoN0U6jntz9o2da17D2w6DuE-cKwhS@mail.gmail.com> References: <A3704940-C282-4B4C-807F-8EC61C625F94@isi.edu> <m2r5bs4pqf.wl%randy@psg.com> <AANLkTimqy7LORem3zH8zyPn21J7a-5-3v1jmiDxRvigy@mail.gmail.com> <AANLkTim5ceiLHxbAyi4XWQU1zuN5eEccDGg1iQzb3Wr+@mail.gmail.com> <AANLkTi=ETaMyoLROe761MQ0FT_RikAM3W+oUR_DjoNiT@mail.gmail.com> <AANLkTi=d8uBPRVBoN0U6jntz9o2da17D2w6DuE-cKwhS@mail.gmail.com> Message-ID: <Pine.LNX.4.64.1101311942330.3637@whammy.cluebyfour.org> On Mon, 31 Jan 2011, Jeremy wrote: > Has there been any discussion about allocating the Class E blocks? If this > doesn't count as "future use" what does? (Yes, I realize this doesn't *fix* > the problem here) I think it has been discussed at various levels, but would likely have been dismissed for one or more of the following reasons: 1. A lot of people filter packets and/or prefixes 224/3 or 240/4 out of habit, right, wrong, or otherwise, so space from 240/4 is likely to have lots of reachability problems. 2. The effort expended by people to solve reachability problems from space they'd get out of 240/4 would be better put toward moving to v6. 3. Busting out 16 more /8s only delays the IPv4 endgame by about a year. jms From cb.list6 at gmail.com Mon Jan 31 23:16:50 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Mon, 31 Jan 2011 21:16:50 -0800 Subject: quietly.... In-Reply-To: <CE295659-26AC-46C4-9983-11A295FDFA15@delong.com> References: <A3704940-C282-4B4C-807F-8EC61C625F94@isi.edu> <m2r5bs4pqf.wl%randy@psg.com> <AANLkTimqy7LORem3zH8zyPn21J7a-5-3v1jmiDxRvigy@mail.gmail.com> <AANLkTim5ceiLHxbAyi4XWQU1zuN5eEccDGg1iQzb3Wr+@mail.gmail.com> <AANLkTi=ETaMyoLROe761MQ0FT_RikAM3W+oUR_DjoNiT@mail.gmail.com> <AANLkTi=d8uBPRVBoN0U6jntz9o2da17D2w6DuE-cKwhS@mail.gmail.com> <CE295659-26AC-46C4-9983-11A295FDFA15@delong.com> Message-ID: <AANLkTin-UY=7U6SFT_bHia9zF1TgUuypQkULhncvCPBd@mail.gmail.com> On Mon, Jan 31, 2011 at 8:38 PM, Owen DeLong <owen at delong.com> wrote: > Discussed, Disgusted, and Dismissed. > > The E space would take more software upgrades to existing systems than just > deploying IPv6. > It's true. It was only after discovering how much work it would take to make 240/4 like RFC 1918 (truly impossible) that I fully engaged in doing IPv6. Now, we are pretty close to launching an IPv6-only + NAT64 service to mobile customer. Cameron =========================== T-Mobile USA IPv6 Beta -> http://bit.ly/9s0Ed3 =========================== From mysidia at gmail.com Mon Jan 31 23:21:53 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Mon, 31 Jan 2011 23:21:53 -0600 Subject: quietly.... In-Reply-To: <AANLkTinrhPYXvtS5wtA0PuhtEmi3f4tN9J5KOCBF1a=5@mail.gmail.com> References: <A3704940-C282-4B4C-807F-8EC61C625F94@isi.edu> <m2r5bs4pqf.wl%randy@psg.com> <AANLkTimqy7LORem3zH8zyPn21J7a-5-3v1jmiDxRvigy@mail.gmail.com> <AANLkTim5ceiLHxbAyi4XWQU1zuN5eEccDGg1iQzb3Wr+@mail.gmail.com> <AANLkTi=ETaMyoLROe761MQ0FT_RikAM3W+oUR_DjoNiT@mail.gmail.com> <AANLkTi=d8uBPRVBoN0U6jntz9o2da17D2w6DuE-cKwhS@mail.gmail.com> <AANLkTinrhPYXvtS5wtA0PuhtEmi3f4tN9J5KOCBF1a=5@mail.gmail.com> Message-ID: <AANLkTimg=zDGSZKVAeqNK4xrKdenUJG5sO_aaNMc_-zs@mail.gmail.com> On Mon, Jan 31, 2011 at 11:00 PM, Martin Millnert <millnert at gmail.com> wrote: This has come up before, in 2007, and earlier, http://www.merit.edu/mail.archives/nanog/2007-10/msg00487.html Way too late now for unreserving 240/4 to help. Now, if it had been unreserved in 2003 or so, there might not be so many devices to upgrade. There could a case to be made for unreserving 240/4 now, so perhaps it could be used in 2020,. > Neither Linux 2.6.37 nor Windows 7 accepts it, and let's not think > about all routers, including CPE:s, out there. hm...... for Linux, there was a patch for this in 2008, in the kernel proper should be in 2.6.25 and newer, http://kerneltrap.org/mailarchive/linux-netdev/2008/1/21/587456 -- -JH From vgill at vijaygill.com Mon Jan 31 23:23:48 2011 From: vgill at vijaygill.com (vijay gill) Date: Mon, 31 Jan 2011 21:23:48 -0800 Subject: 2011.01.31 NANOG51 day 1 afternoon session notes In-Reply-To: <AANLkTikB64Bt+Y--=HRsz-HPtos5xPRL6=-YZakgxquB@mail.gmail.com> References: <AANLkTikB64Bt+Y--=HRsz-HPtos5xPRL6=-YZakgxquB@mail.gmail.com> Message-ID: <AANLkTikycF8BBy=a726cx1=n4-wEpp7_jpt7LfO9SzmQ@mail.gmail.com> On Mon, Jan 31, 2011 at 2:18 PM, Matthew Petach <mpetach at netflight.com> wrote: > I've posted my notes from the afternoon sessions, including > the lighting talks, at > > http://kestrel3.netflight.com/2011.01.31-NANOG51-afternoon-notes.txt > > for those are are following along remotely, or catching up after > a good round of meetings at the bar. ?:) > > Have fun at the beer and gear--sorry I can't take any notes > on the IPv6 deployment experiences panel--I'm sure it would > have been interesting reading, given the amount of attention > v6 has been getting on the list recently. ?^_^ thanks matt, this is almost better than being there. really appreciate your notes and hard work. /vijay > > Matt > > From nanog-post at rsuc.gweep.net Mon Jan 31 23:25:24 2011 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Tue, 1 Feb 2011 00:25:24 -0500 Subject: quietly.... In-Reply-To: <AANLkTi=d8uBPRVBoN0U6jntz9o2da17D2w6DuE-cKwhS@mail.gmail.com> References: <A3704940-C282-4B4C-807F-8EC61C625F94@isi.edu> <m2r5bs4pqf.wl%randy@psg.com> <AANLkTimqy7LORem3zH8zyPn21J7a-5-3v1jmiDxRvigy@mail.gmail.com> <AANLkTim5ceiLHxbAyi4XWQU1zuN5eEccDGg1iQzb3Wr+@mail.gmail.com> <AANLkTi=ETaMyoLROe761MQ0FT_RikAM3W+oUR_DjoNiT@mail.gmail.com> <AANLkTi=d8uBPRVBoN0U6jntz9o2da17D2w6DuE-cKwhS@mail.gmail.com> Message-ID: <20110201052524.GA31520@gweep.net> On Mon, Jan 31, 2011 at 10:31:43PM -0600, Jeremy wrote: > Has there been any discussion about allocating the Class E blocks? If this > doesn't count as "future use" what does? (Yes, I realize this doesn't *fix* > the problem here) https://puck.nether.net/pipermail/240-e Last real message? 31 Oct 2007 Done and done. V6, please. -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From cabenth at gmail.com Mon Jan 31 23:35:46 2011 From: cabenth at gmail.com (eric clark) Date: Mon, 31 Jan 2011 21:35:46 -0800 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <1296089078.6522.194.camel@karl> References: <AANLkTi=sh+gPPHoNKwME2u5zMpaS9uO20gUfZKoaSx9d@mail.gmail.com> <AANLkTimcZavnJN2gqayS2-piDvOAcw_nrJAREJ0EDTjp@mail.gmail.com> <AANLkTikHBb+cyfPxXftb5QZh136D04fkdWFMy3NFhDdi@mail.gmail.com> <4D3F0144.70107@sohonet.co.uk> <58166C50-0B72-43A0-8AB8-25E803EA1619@delong.com> <20110126043722.GA4110@skywalker.creative.net.au> <AE3E144C-64D8-46AA-9EFE-9CECF2F766FA@arbor.net> <1296089078.6522.194.camel@karl> Message-ID: <AANLkTi=+rOTn=E29MNEnGRBJc8hU6MsCCu_-cN=z+GhW@mail.gmail.com> Figure I'll throw my 2 cents into this. The way I read the RFCs, IPv6 is not IP space. Its network space. Unless I missed it last time I read through them, the RFCs do not REQUIRE hardware/software manufacturers to support VLSM beyond /64. Autoconfigure the is the name of the game for the IPv6 guys. Subsequently, while using longer prefixes is possible currently, I'd never deploy it because it could be removed from code without mention. Because of the AutoConfigure piece, I consider IPv6 to be NETWORK Space, rather than IP Space like IPv4. I'm issued a /48 which can be comprised of 65536 /64 networks, not some silly number of hosts, which can't exist because they are all duplicates of each other (MAC address = host identifier) Anyway, that's how I see the question that started this whole thing, I'd suggest using link local and RFC 4193 for internal routing and your public space for things that need public access or need to be accessed publicly. Just because they SAY there's infinite space (like they said about IPv4) doesn't mean we have to be stupid and wasteful with our space. -C If I've misread, or completely missed an RFC, I apologize. From owen at delong.com Mon Jan 31 23:56:35 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 31 Jan 2011 21:56:35 -0800 Subject: quietly.... In-Reply-To: <Pine.LNX.4.64.1101311942330.3637@whammy.cluebyfour.org> References: <A3704940-C282-4B4C-807F-8EC61C625F94@isi.edu> <m2r5bs4pqf.wl%randy@psg.com> <AANLkTimqy7LORem3zH8zyPn21J7a-5-3v1jmiDxRvigy@mail.gmail.com> <AANLkTim5ceiLHxbAyi4XWQU1zuN5eEccDGg1iQzb3Wr+@mail.gmail.com> <AANLkTi=ETaMyoLROe761MQ0FT_RikAM3W+oUR_DjoNiT@mail.gmail.com> <AANLkTi=d8uBPRVBoN0U6jntz9o2da17D2w6DuE-cKwhS@mail.gmail.com> <Pine.LNX.4.64.1101311942330.3637@whammy.cluebyfour.org> Message-ID: <D7D9A7D6-D15C-432A-B061-732959FFA915@delong.com> On Jan 31, 2011, at 4:49 PM, Justin M. Streiner wrote: > On Mon, 31 Jan 2011, Jeremy wrote: > >> Has there been any discussion about allocating the Class E blocks? If this >> doesn't count as "future use" what does? (Yes, I realize this doesn't *fix* >> the problem here) > > I think it has been discussed at various levels, but would likely have been dismissed for one or more of the following reasons: > 1. A lot of people filter packets and/or prefixes 224/3 or 240/4 out of habit, right, wrong, or otherwise, so space from 240/4 is likely to have lots of reachability problems. > Also, many systems will not accept this traffic or configuration as hard-coded system parameters. > 2. The effort expended by people to solve reachability problems from space they'd get out of 240/4 would be better put toward moving to v6. > Not to mention the software updates required to make it functional would exceed the software updates necessary for IPv6 _AND_ it has no lasting future. > 3. Busting out 16 more /8s only delays the IPv4 endgame by about a year. > Actually, if last year's consumption is any indicator, it's more like 10 months and given the accelerating consumption of IPv4 overall, I'd say less than 9 is not unlikely. I'm betting you're talking about more than 9 months to get the software and reachability issues resolved. Owen From guofei at cse.tamu.edu Thu Jan 13 16:02:46 2011 From: guofei at cse.tamu.edu (Guofei Gu) Date: Thu, 13 Jan 2011 22:02:46 -0000 Subject: Call for Papers: RAID'11 Message-ID: <9178D06552FC442991A7B5EBCFB79BE4@wallePC> Dear colleagues, please find below the Call for Papers for RAID'11 (http://raid2011.org/). Apologies for multiple copies of this announcement. Best regards, Guofei Gu Assistant Professor Department of Computer Science & Engineering Texas A&M University -------------------------------------------------------------------------- CALL FOR PAPERS RAID 2011 14th International Symposium on Recent Advances in Intrusion Detection September 20-21, 2011 SRI International, Menlo Park, CA http://raid2011.org -------------------------------------------------------------------------- This symposium, the 14th in an annual series, brings together leading researchers and practitioners from academia, government, and industry to discuss issues and technologies related to intrusion detection and defense. The Recent Advances in Intrusion Detection (RAID) International Symposium series furthers advances in intrusion defense by promoting the exchange of ideas in a broad range of topics. As in previous years, all topics related to intrusion detection, prevention and defense systems and technologies are within scope, including but not limited to the following: * Network and host intrusion detection and prevention * Anomaly and specification-based approaches * IDS cooperation and event correlation * Malware prevention, detection, analysis, containment * Web application security * Insider attack detection * Intrusion response, tolerance, and self-protection * Operational experiences with current approaches * Intrusion detection assessment and benchmarking * Attacks against intrusion detection systems * Formal models, analysis, and standards * Deception systems and honeypots * Vulnerability analysis and forensics * Adversarial machine learning for security * Visualization techniques * High-performance intrusion detection * Legal, social, and privacy issues * Network exfiltration detection * Botnet analysis, detection, and mitigation * Cyber-physical systems Important Dates --------------- Paper submission deadline: Mar 31, 2011 (11:59PM PST) Paper acceptance or rejection: June 2, 2011 Final camera-ready copy: June 16, 2011 Poster submission: June 18, 2011 (11:59PM PST) Poster acceptance or rejection: June 25, 2011 Early Bird registration closes August 1, 2011 Types of Submissions -------------------- * Full papers presenting mature research results or convincing case studies of protecting large operational networks. Papers accepted by the Program Committee will be presented at RAID 2011 and included in the Symposium?s proceedings published by Springer in its Lecture Notes in Computer Science series. Papers must include an abstract and a list of keywords, and must not exceed 20 pages in total length, formatted in LNCS-style and including the bibliography and any appendices. * Posters describing a work in progress or an innovative idea not yet sufficiently mature for a full paper. Posters are submitted for review in the form of an extended abstract that must likewise be formatted in LNCS-style and not exceed 2 pages in length. Accepted posters will be presented at RAID 2011 in a separate session, and the submitted abstracts will be published on the Symposium?s web site. All submissions (papers and poster abstracts) must be formatted according to the instructions provided by Springer (http://www.springer.com/comp/lncs/Authors.html) and then submitted electronically; details will be provided on the conference web site. Papers must list all authors and their affiliations; RAID does not require anonymized submissions. For accepted papers, at least one of the authors must attend the conference to present the paper. Further questions on the submission process may be sent to the program chairs. Submissions must not substantially duplicate work that has already been published elsewhere or is submitted in parallel to a journal or to any other conference or workshop with proceedings. Simultaneous submission of the same work to multiple venues, submission of previously published work, and plagiarism constitute dishonesty or fraud. RAID, like other scientific and technical conferences and journals, prohibits these practices and may, on the recommendation of the program chair, take action against authors who have committed them. Student Scholarships -------------------- RAID 2011 will offer student scholarships to reduce symposium attendance costs. Students should visit the web site (http://raid2011.org) to learn about availability of scholarships and application deadlines. Organizing Committee -------------------- General Chair: Alfonso Valdes, SRI International, US Program Chair: Robin Sommer, ICSI/LBNL, US Program Co-Chair: Davide Balzarotti, Eurecom, France Publication Chair: Gregor Maier, ICSI, US Publicity Chair: Guofei Gu, Texas A&M, US Program Committee ----------------- Michael Bailey, University of Michigan, US Elie Bursztein, Stanford University, US Juan Caballero, IMDEA Software, Spain Michael Collins, RedJack, US Manuel Costa, Microsoft Research, UK Marco Cova, University of Birmingham, UK Holger Dreger, Siemens AG, Germany Debin Gao, Singapore Management University, Singapore Jonathan Giffin, Georgia Tech, US Guofei Gu, Texas A&M, US Guillaume Hiet, Supelec, France Thorsten Holz, Ruhr-University Bochum, Germany Sotiris Ioannidis, FORTH, Greece Jaeyeon Jung, Intel Labs Seattle, US Syed Ali Khayam, Nat. Univ. of S&T (NUST), Pakistan Christian Kreibich, ICSI, US Christopher Kruegel, UC Santa Barbara, US Corrado Leita, Symantec Research, France Gregor Maier, ICSI, US Benjamin Morin, CDISS, France Phil Porras, SRI International, US William Robertson, UC Berkeley, US Anil Somayaji, Carleton University, Canada Angelos Stavrou, George Mason University, US Charles Wright, MIT Lincoln Laboratory, US Steering Committee ----------------- Chair: Marc Dacier, Eurecom, France Herve Debar, Telecom SudParis, France Deborah Frincke, Pacific Northwest National Lab, US Ming-Yuh Huang, The Boeing Company, US Somesh Jha, University of Wisconsin, US Erland Jonsson, Chalmers, Sweden Engin Kirda, Northeastern University, US Christopher Kruegel, UC Santa Barbara, US Wenke Lee, Georgia Tech, US Ludovic Me, Supelec, France Alfonso Valdes, SRI International, US Giovanni Vigna, UC Santa Barbara, US Andreas Wespi, IBM Research, Switzerland S. Felix Wu, UC Davis, US Diego Zamboni, IBM Research, Switzerland