Re: draft-ietf-mpls-ldp-ipv6-16
On 19/Feb/15 19:03, Phil Bedard wrote: ASR9K IOS-XR 5.3.0 Release Notes: IPv6 Support in MPLS LDP: Starting from release 5.3.0, support for native MPLS LDP over IPv6 is enabled to continue providing existing services seamlessly while enabling new ones. The attributes and capabilities of the existing MPLS LDP have been extended to be IPv6 aware. This is based off the -12 draft, that LDP over v6 draft has seen a lot of contention for various reasons. Details at: http://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r5-3/mp ls/configuration/guide/b-mpls-cg53x-asr9k/b-mpls-cg53x-asr9k_chapter_010.ht ml#concept_FA2F48EE4A2044458FE25897118AFBA4 If you have CCO access you can download the 5.3.0 XRv VMs and play around with it. Getting IPv6 support in LDP is one thing. This is one document that we need to keep track to know what MPLS applications currently running off of LDPv4 still need to be ported to run over LDPv6: http://tools.ietf.org/html/draft-george-mpls-ipv6-only-gap-04 Mark.
Re: OT - Small DNS appliances for remote offices.
If your time is worth anything, you can't beat the Mac Mini, especially for a branch office mission-critical application like DNS. I just picked up a Mini from BestBuy for $480. I plugged it in, applied the latest updates, purchased the MacOSX Server component from the Apples Store ($19), and then via the Server control panel enabled DNS with forwarding. Total time from unboxing to working DNS: 20 minutes. The Server component smartly ships with all services disabled, in contrast to a lot of Linux distros, so it's pretty secure out of the box. You can harden it a bit more with the built-in PF firewall. The machine is also IPv6 ready out of the box, so my new DNS server automatically services both IPv4 and IPv6 clients. You get Apple's warranty and full support. Any Apple store can do testing and repair. And with a dual-core 1.4GHz I5 and 4GB memory, it's going to handle loads of DNS requests. Of course, if your time is worth little, spend a lot of time tweaking slow, unsupported, incomplete solutions. -mel On Feb 19, 2015, at 11:32 AM, Denys Fedoryshchenko de...@visp.net.lb wrote: On 2015-02-19 18:26, valdis.kletni...@vt.edu wrote: On Thu, 19 Feb 2015 14:52:42 +, David Reader said: I'm using several to connect sensors, actuators, and such to a private network, which it's great for - but I'd think at least twice before deploying one as a public-serving host in user-experience-critical role in a remote location. I have a Pi that's found a purpose in life as a remote smokeping sensor and related network monitoring, a task it does quite nicely. Note that they just released the Pi 2, which goes from the original single-core ARM V6 to a quad-core ARM V7, and increases memory from 256M to1G. All at the same price point. That may change the calculus. I admit not having gotten one in hand to play with yet. Weird thing - it still has Ethernet over ugly USB 2.0 That kills any interest to run it for any serious networking applications. --- Best regards, Denys
Re: OT - Small DNS appliances for remote offices.
On 2015-02-19 18:26, valdis.kletni...@vt.edu wrote: On Thu, 19 Feb 2015 14:52:42 +, David Reader said: I'm using several to connect sensors, actuators, and such to a private network, which it's great for - but I'd think at least twice before deploying one as a public-serving host in user-experience-critical role in a remote location. I have a Pi that's found a purpose in life as a remote smokeping sensor and related network monitoring, a task it does quite nicely. Note that they just released the Pi 2, which goes from the original single-core ARM V6 to a quad-core ARM V7, and increases memory from 256M to1G. All at the same price point. That may change the calculus. I admit not having gotten one in hand to play with yet. Weird thing - it still has Ethernet over ugly USB 2.0 That kills any interest to run it for any serious networking applications. --- Best regards, Denys
Re: OT - Small DNS appliances for remote offices.
older apple tv will work as well :) Colin On 19 Feb 2015, at 19:47, Mel Beckman m...@beckman.org wrote: If your time is worth anything, you can't beat the Mac Mini, especially for a branch office mission-critical application like DNS. I just picked up a Mini from BestBuy for $480. I plugged it in, applied the latest updates, purchased the MacOSX Server component from the Apples Store ($19), and then via the Server control panel enabled DNS with forwarding. Total time from unboxing to working DNS: 20 minutes. The Server component smartly ships with all services disabled, in contrast to a lot of Linux distros, so it's pretty secure out of the box. You can harden it a bit more with the built-in PF firewall. The machine is also IPv6 ready out of the box, so my new DNS server automatically services both IPv4 and IPv6 clients. You get Apple's warranty and full support. Any Apple store can do testing and repair. And with a dual-core 1.4GHz I5 and 4GB memory, it's going to handle loads of DNS requests. Of course, if your time is worth little, spend a lot of time tweaking slow, unsupported, incomplete solutions. -mel On Feb 19, 2015, at 11:32 AM, Denys Fedoryshchenko de...@visp.net.lb wrote: On 2015-02-19 18:26, valdis.kletni...@vt.edu wrote: On Thu, 19 Feb 2015 14:52:42 +, David Reader said: I'm using several to connect sensors, actuators, and such to a private network, which it's great for - but I'd think at least twice before deploying one as a public-serving host in user-experience-critical role in a remote location. I have a Pi that's found a purpose in life as a remote smokeping sensor and related network monitoring, a task it does quite nicely. Note that they just released the Pi 2, which goes from the original single-core ARM V6 to a quad-core ARM V7, and increases memory from 256M to1G. All at the same price point. That may change the calculus. I admit not having gotten one in hand to play with yet. Weird thing - it still has Ethernet over ugly USB 2.0 That kills any interest to run it for any serious networking applications. --- Best regards, Denys
Re: OT - Small DNS appliances for remote offices.
If you have a lot of locations, as I believe Ray is looking for, all of this is a manual process you need to do for each instance. That is slow and inefficient. If you're doing more than a few, you probably want something you can PXE boot for provisioning and manage with your preferred DevOps tools. It also sounds like he wants to run anycast for this service, so probably needs a BGP speaker and other site-specific configuration that I assume is not covered by the cookie-cutter OSX tools. Of course you could still do it this way with a Mac Mini running some other OS, but why would you want to when there are plenty of other mini-PC options that are more appropriate? Also: With Apple dropping their Pro products and leaving customers in the lurch, and no longer having any actual server hardware, I would have very little confidence in their server software product's quality or likely longevity. And of course they're mum on their plans, so it's impossible to plan around if they decide to exit the market. Keenan On 02/19/2015 11:47 AM, Mel Beckman wrote: If your time is worth anything, you can't beat the Mac Mini, especially for a branch office mission-critical application like DNS. I just picked up a Mini from BestBuy for $480. I plugged it in, applied the latest updates, purchased the MacOSX Server component from the Apples Store ($19), and then via the Server control panel enabled DNS with forwarding. Total time from unboxing to working DNS: 20 minutes. The Server component smartly ships with all services disabled, in contrast to a lot of Linux distros, so it's pretty secure out of the box. You can harden it a bit more with the built-in PF firewall. The machine is also IPv6 ready out of the box, so my new DNS server automatically services both IPv4 and IPv6 clients. You get Apple's warranty and full support. Any Apple store can do testing and repair. And with a dual-core 1.4GHz I5 and 4GB memory, it's going to handle loads of DNS requests. Of course, if your time is worth little, spend a lot of time tweaking slow, unsupported, incomplete solutions. -mel On Feb 19, 2015, at 11:32 AM, Denys Fedoryshchenko de...@visp.net.lb wrote: On 2015-02-19 18:26, valdis.kletni...@vt.edu wrote: On Thu, 19 Feb 2015 14:52:42 +, David Reader said: I'm using several to connect sensors, actuators, and such to a private network, which it's great for - but I'd think at least twice before deploying one as a public-serving host in user-experience-critical role in a remote location. I have a Pi that's found a purpose in life as a remote smokeping sensor and related network monitoring, a task it does quite nicely. Note that they just released the Pi 2, which goes from the original single-core ARM V6 to a quad-core ARM V7, and increases memory from 256M to1G. All at the same price point. That may change the calculus. I admit not having gotten one in hand to play with yet. Weird thing - it still has Ethernet over ugly USB 2.0 That kills any interest to run it for any serious networking applications. --- Best regards, Denys
Re: OT - Small DNS appliances for remote offices.
Keenan, Red. Herrings. You can provision macs over the network. That's one of the functions of Mac OSX Server OS. It's trivial to then promote them to servers themselves. All remotely. Also, the Mac is running a full BIND9 implementation, not some cutdown version. Yes the GUI is minimal, but there's no need to use the GUI, and you don't even have a GUI on other platforms for the most part. BGP speaker? Come on, you're gilding the lily. Yes, Apple is silent about its plans. But the Mac Mini and Server OS have been well supported for over a decade. I don't know why you're bringing server hardware into this, the whole point of the discussion is to avoid using server hardware. And how much open source road map has failed to materialize? Lots! The future-proofing argument cuts both ways, my friend. You may have little confidence in Apple, but the rest of the world seems to have great confidence. Just look at Apple's stock performance and market cap. As a famous scientist one said: The absence of data is not data. :-) -mel beckman On Feb 19, 2015, at 12:43 PM, Keenan Tims kt...@stargate.camailto:kt...@stargate.ca wrote: If you have a lot of locations, as I believe Ray is looking for, all of this is a manual process you need to do for each instance. That is slow and inefficient. If you're doing more than a few, you probably want something you can PXE boot for provisioning and manage with your preferred DevOps tools. It also sounds like he wants to run anycast for this service, so probably needs a BGP speaker and other site-specific configuration that I assume is not covered by the cookie-cutter OSX tools. Of course you could still do it this way with a Mac Mini running some other OS, but why would you want to when there are plenty of other mini-PC options that are more appropriate? Also: With Apple dropping their Pro products and leaving customers in the lurch, and no longer having any actual server hardware, I would have very little confidence in their server software product's quality org likely longevity. And of course they're mum on their plans, so it's impossible to plan around if they decide to exit the market. Keenan On 02/19/2015 11:47 AM, Mel Beckman wrote: If your time is worth anything, you can't beat the Mac Mini, especially for a branch office mission-critical application like DNS. I just picked up a Mini from BestBuy for $480. I plugged it in, applied the latest updates, purchased the MacOSX Server component from the Apples Store ($19), and then via the Server control panel enabled DNS with forwarding. Total time from unboxing to working DNS: 20 minutes. The Server component smartly ships with all services disabled, in contrast to a lot of Linux distros, so it's pretty secure out of the box. You can harden it a bit more with the built-in PF firewall. The machine is also IPv6 ready out of the box, so my new DNS server automatically services both IPv4 and IPv6 clients. You get Apple's warranty and full support. Any Apple store can do testing and repair. And with a dual-core 1.4GHz I5 and 4GB memory, it's going to handle loads of DNS requests. Of course, if your time is worth little, spend a lot of time tweaking slow, unsupported, incomplete solutions. -mel On Feb 19, 2015, at 11:32 AM, Denys Fedoryshchenko de...@visp.net.lbmailto:de...@visp.net.lb wrote: On 2015-02-19 18:26, valdis.kletni...@vt.edumailto:valdis.kletni...@vt.edu wrote: On Thu, 19 Feb 2015 14:52:42 +, David Reader said: I'm using several to connect sensors, actuators, and such to a private network, which it's great for - but I'd think at least twice before deploying one as a public-serving host in user-experience-critical role in a remote location. I have a Pi that's found a purpose in life as a remote smokeping sensor and related network monitoring, a task it does quite nicely. Note that they just released the Pi 2, which goes from the original single-core ARM V6 to a quad-core ARM V7, and increases memory from 256M to1G. All at the same price point. That may change the calculus. I admit not having gotten one in hand to play with yet. Weird thing - it still has Ethernet over ugly USB 2.0 That kills any interest to run it for any serious networking applications. --- Best regards, Denys
Re: OT - Small DNS appliances for remote offices.
here here, apple kits rocks for low end server work, sun kit rocks for high end server work. Colin On 19 Feb 2015, at 20:55, Mel Beckman m...@beckman.org wrote: Keenan, Red. Herrings. You can provision macs over the network. That's one of the functions of Mac OSX Server OS. It's trivial to then promote them to servers themselves. All remotely. Also, the Mac is running a full BIND9 implementation, not some cutdown version. Yes the GUI is minimal, but there's no need to use the GUI, and you don't even have a GUI on other platforms for the most part. BGP speaker? Come on, you're gilding the lily. Yes, Apple is silent about its plans. But the Mac Mini and Server OS have been well supported for over a decade. I don't know why you're bringing server hardware into this, the whole point of the discussion is to avoid using server hardware. And how much open source road map has failed to materialize? Lots! The future-proofing argument cuts both ways, my friend. You may have little confidence in Apple, but the rest of the world seems to have great confidence. Just look at Apple's stock performance and market cap. As a famous scientist one said: The absence of data is not data. :-) -mel beckman On Feb 19, 2015, at 12:43 PM, Keenan Tims kt...@stargate.camailto:kt...@stargate.ca wrote: If you have a lot of locations, as I believe Ray is looking for, all of this is a manual process you need to do for each instance. That is slow and inefficient. If you're doing more than a few, you probably want something you can PXE boot for provisioning and manage with your preferred DevOps tools. It also sounds like he wants to run anycast for this service, so probably needs a BGP speaker and other site-specific configuration that I assume is not covered by the cookie-cutter OSX tools. Of course you could still do it this way with a Mac Mini running some other OS, but why would you want to when there are plenty of other mini-PC options that are more appropriate? Also: With Apple dropping their Pro products and leaving customers in the lurch, and no longer having any actual server hardware, I would have very little confidence in their server software product's quality org likely longevity. And of course they're mum on their plans, so it's impossible to plan around if they decide to exit the market. Keenan On 02/19/2015 11:47 AM, Mel Beckman wrote: If your time is worth anything, you can't beat the Mac Mini, especially for a branch office mission-critical application like DNS. I just picked up a Mini from BestBuy for $480. I plugged it in, applied the latest updates, purchased the MacOSX Server component from the Apples Store ($19), and then via the Server control panel enabled DNS with forwarding. Total time from unboxing to working DNS: 20 minutes. The Server component smartly ships with all services disabled, in contrast to a lot of Linux distros, so it's pretty secure out of the box. You can harden it a bit more with the built-in PF firewall. The machine is also IPv6 ready out of the box, so my new DNS server automatically services both IPv4 and IPv6 clients. You get Apple's warranty and full support. Any Apple store can do testing and repair. And with a dual-core 1.4GHz I5 and 4GB memory, it's going to handle loads of DNS requests. Of course, if your time is worth little, spend a lot of time tweaking slow, unsupported, incomplete solutions. -mel On Feb 19, 2015, at 11:32 AM, Denys Fedoryshchenko de...@visp.net.lbmailto:de...@visp.net.lb wrote: On 2015-02-19 18:26, valdis.kletni...@vt.edumailto:valdis.kletni...@vt.edu wrote: On Thu, 19 Feb 2015 14:52:42 +, David Reader said: I'm using several to connect sensors, actuators, and such to a private network, which it's great for - but I'd think at least twice before deploying one as a public-serving host in user-experience-critical role in a remote location. I have a Pi that's found a purpose in life as a remote smokeping sensor and related network monitoring, a task it does quite nicely. Note that they just released the Pi 2, which goes from the original single-core ARM V6 to a quad-core ARM V7, and increases memory from 256M to1G. All at the same price point. That may change the calculus. I admit not having gotten one in hand to play with yet. Weird thing - it still has Ethernet over ugly USB 2.0 That kills any interest to run it for any serious networking applications. --- Best regards, Denys
Re: OT - Small DNS appliances for remote offices.
Bryan Seitz se...@bsd-unix.net writes: odroid-c1 + eMMC module + RTC battery + case + power adapter. Should run you about $75 *AND* wouldn't be bad for running NTP as well. I haven't looked into the details of the clock, so wouldn't be bad is probably true, notably good, well, that would be a task for someone with experience doing clock benchmarking and who can describe MAVAR without looking it up. The gig-e port on the C1 has been observed to push 405Mbps TX and 940Mbps+ RX via iperf. The 405 Mbps for TX. I've seen around 30 Mbyte/sec on single stream TCP RX. Got 99.5 Mbyte/sec from a Mac Mini in the same subnet so that's not a limit of the host on the other end of the benchmark. I call shenanigans on the 940 Mbps iperf number though. The HSIC bus is only 480 Mbit/sec. Two pints of beer in a one pint glass would be some trick. -r
Re: Intrusion Detection recommendations
I now have a few moments to discuss Security Onion, and why it works well for a many small and mid-sided organization. Security Onion is a Linux distro for IDS, NSM, and log management. The whole thing can be run on a single, or separated systems, based on the needs, network and security architecture, and budget. From a IDS sensor standpoint it contains;1.Snort, Suricata – Focused on network-based signature detection, or what I call “the barn door is open, and the horse is gone” detection. This is because someone needs to be compromised, take to time to send out signatures (or purchase them) before you can use them. Great if the attack is against everyone, or a small community of people that will share this information, but not so good if you are the target.2. Bro – Network based packet and protocol classifier, which when configured, preform:a.Internal intelligence analysisb.Full session, Bidirectional net flow analysisc. File extractiond.Network Reconnaissancee.Behavior and statically analysis on the flowf. And much more3.OSSEC – A comprehensive host based intrusion detection system with fine grained application/server specific policies across multiple platforms such as Linux, Solaris, AIX, HP-UX, BSD, Windows, Mac and Vmware ESX. To catch the traffic, you have:1.Sguil: The Analyst Console for Network Security Monitoring2.Squert is a web application that is used to query and view event data stored in a Sguil database (typically IDS alert data). Squert is a visual tool that attempts to provide additional context to events through the use of metadata, time series representations and weighted and logically grouped result sets. The hope is that these views will prompt questions that otherwise may not have been asked.3. Snorby is a ruby on rails web application for network security monitoring that interfaces with current popular intrusion detection systems (Snort, Suricata and Sagan). The basic fundamental concepts behind Snorby are *simplicity*, organization and power. The project goal is to create a free, open source and highly competitive application for network monitoring for both private and enterprise use.4. ELSA is a centralized syslog framework built on Syslog-NG, MySQL, and Sphinx full-text search. It provides a fully asynchronous web-based query interface that normalizes logs and makes searching billions of them for arbitrary strings as easy as searching the web. Packet Capture and analysis: 1.Xplico is a network forensics analysis tool (NFAT), which is a software that reconstructs the contents of acquisitions performed with a packet sniffer (e.g. Wireshark, tcpdump, Netsniff-ng).2.NetworkMiner is a Network Forensic Analysis Tool (NFAT) for Windows (but also works in Linux / Mac OS X / FreeBSD). NetworkMiner can be used as a passive network sniffer/packet capturing tool in order to detect operating systems, sessions, hostnames, open ports etc. without putting any traffic on the network. NetworkMiner can also parse PCAP files for off-line analysis and to regenerate/reassemble transmitted files and certificates from PCAP files. The only thing you are missing is a SEIM, which I recommend the ELK stack. This includes:1.elasticsearch - for distributed restful search and analytics2.logstash - manage events and logs - elasticsearch works seamlessly with logstash to collect, parse, index, and search logs3.kibana - visualize logs and time-stamped data - elasticsearch works seamlessly with kibana to let you see and interact with your dataAll of the above items are Open Source, have free and paid training and support, if needed. One can save millions of dollars and get the newest capabilities. Contact me off list if you have questions. Disclosure: I do not sell these products, but I use them. Joe Klein Inveniam viam aut faciam On Fri, Feb 13, 2015 at 12:40 PM, Andy Ringsmuth a...@newslink.com wrote: NANOG'ers, I've been tasked by our company president to learn about, investigate and recommend an intrusion detection system for our company. We're a smaller outfit, less than 100 employees, entirely Apple-based. Macs, iPhones, some Mac Mini servers, etc., and a fiber connection to the world. We are protected by a FreeBSD firewall setup, and we stay current on updates/patches from Apple and FreeBSD, but that's as far as my expertise goes. Initially, what do people recommend for: 1. Crash course in intrusion detection as a whole 2. Suggestions or recommendations for intrusion detection hardware or software 3. Other things I'm likely overlooking Thank you all in advance for your wisdom. Andy Ringsmuth a...@newslink.com News Link – Manager Technology Facilities 2201 Winthrop Rd., Lincoln, NE 68502-4158 (402) 475-6397(402) 304-0083 cellular
Re: OT - Small DNS appliances for remote offices.
Denys Fedoryshchenko de...@visp.net.lb writes: Beaglebone has gigabit mac, but due some errata it is not used in gigabit mode, it is 100M (which is maybe enough for small office). But it is hardware mac. The Beaglebone Black rev C BOM calls out the ethernet phy chip as LAN8710A-EZC-TR which is 10/100 so there's your constraint. The MAC is built into the SoC and according to the datasheet the AM3358B is 10/100/1000. Another hardware MAC on inexpensive board it is Odroid-C1. Difficulty: hardware MAC tells you nothing about how it's connected, either on the board or internally in the SoC. Ethernet on Multibus and Ethernet on PCIe (neither likely on an embedded ARM ;-) are both hardware MAC yet the bus-constrained bandwidths will differ by several orders of magnitude. -r
RE: Re: Intrusion Detection recommendations
These are all excellent tools for a dedicated knowledgeable network security person to use. The most important element being the dedicated knowledgeable network security person. --p -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Jimmy Hess Sent: Saturday, February 14, 2015 12:57 PM To: Randy Bush Cc: North American Network Operators' Group Subject: [EXTERNAL]Re: Intrusion Detection recommendations On Sat, Feb 14, 2015 at 2:38 AM, Randy Bush ra...@psg.com wrote: Bro, SNORT, SGUIL, Tcpdump, and Wireshark are some nice tools. By itself, a single install of Snort/Bro is not necessarily a complete IDS, as it cannot inspect the contents of outgoing SSL sessions, so there can still be Javascript/attacks against the browser, or SQL injection attempts encapsulated in the encrypted tunnels;I am not aware of an open source tool to help you with SSH/SSL interception/SSL decryption for implementation of network-based IDS. You also need a hand-crafted rule for each threat that you want Snort to identify... Most likely this entails making decisions about what commercial ruleset(s) you want to use and then buying the appropriate subscriptions. if you were comfortable enough with freebsd to use it as a firewall, you can run your traffic through, or mirror it to, a freebsd box running https://www.bro.org/ or https://www.snort.org/ two quite reasonable and powerful open source systems randy -- -JH
Re: OT - Small DNS appliances for remote offices.
Beaglebone has gigabit mac, but due some errata it is not used in gigabit mode, it is 100M (which is maybe enough for small office). But it is hardware mac. Another hardware MAC on inexpensive board it is Odroid-C1. But stability of all this boards in heavy networking use is under question, i didn't tested them yet intensively for same purpose. On 2015-02-19 02:27, Geoff Mulligan wrote: The BeagleBone Black uses flash memory to hold the system image which allows it to boot quickly. I'm running Ubuntu Trusty 14.04 and it seems stable. Geoff *-- Presidential Innovation Fellow | The White House* On 02/18/2015 05:20 PM, Bacon Zombie wrote: You also have to watch out for issues with the Pi corrupting SD cards. On 19 Feb 2015 01:04, Geoff Mulligan nano...@mulligan.org wrote: I have used the BeagleBone to run a few simple servers. I don't know if the ethernet port on the Bone is on the USB bus. It is slightly more expensive than a PI, but they have worked well for me. Geoff On 02/18/2015 04:44 PM, Peter Loron wrote: For any site where you would use a Pi as the DNS cache, it won't be an issue. DNS isn't that heavy at those query rates. Yeah, it would be awesome if they'd been able to get a SoC that included ethernet. -Pete On 2015-02-18 15:08, Robert Webb wrote: What I do not like about the Pi is the network port is on the USB bus and thus limited to USB speeds. div Original message /divdivFrom: Maxwell Cole mcole.mailingli...@gmail.com /divdivDate:02/18/2015 4:30 PM (GMT-05:00) /divdivTo: nanog@nanog.org 'NANOG list' nanog@nanog.org /divdivSubject: Re: OT - Small DNS appliances for remote offices. /divdiv /div --- Best regards, Denys
RE: Re: Intrusion Detection recommendations
I believe the ASA was first developed as the PIX on Plan 9. The OS that came out of that was originally called Finesse OS, but was later renamed as PIX OS. After Cisco purchased the PIX and renamed it to the ASA, they began using a Linux kernel around PIX OS V8. --p -Original Message- From: NANOG [mailto:nanog-bounces+patrick.darden=p66@nanog.org] On Behalf Of Justin M. Streiner Sent: Saturday, February 14, 2015 3:28 AM To: nanog@nanog.org Subject: [EXTERNAL]Re: Intrusion Detection recommendations On Fri, 13 Feb 2015, Rich Kulawiec wrote: On Fri, Feb 13, 2015 at 02:45:46PM -0600, Rafael Possamai wrote: I am a huge fan of FreeBSD, but for a medium/large business I'd definitely use a fairly well tested security appliance like Cisco's ASA. Closed-source software is faith-based security. The ASA, like so many network/security appliances anymore, runs Linux (or *BSD) under the hood, however I don't know how old or horribly mangled it is. jms
Re: OT - Small DNS appliances for remote offices.
On 2015-02-19 15:13, Rob Seastrom wrote: Denys Fedoryshchenko de...@visp.net.lb writes: Beaglebone has gigabit mac, but due some errata it is not used in gigabit mode, it is 100M (which is maybe enough for small office). But it is hardware mac. The Beaglebone Black rev C BOM calls out the ethernet phy chip as LAN8710A-EZC-TR which is 10/100 so there's your constraint. The MAC is built into the SoC and according to the datasheet the AM3358B is 10/100/1000. Another hardware MAC on inexpensive board it is Odroid-C1. Difficulty: hardware MAC tells you nothing about how it's connected, either on the board or internally in the SoC. Ethernet on Multibus and Ethernet on PCIe (neither likely on an embedded ARM ;-) are both hardware MAC yet the bus-constrained bandwidths will differ by several orders of magnitude. -r Well, i guess for DNS it wont matter much(400Mbit or full capacity). But stability of driverand archievable pps rate on it, due poor code - can be a question. And mostly this products are Network enabled, but networking are very lightly used, not as it is used on appliances, 24/7 traffic, sometimes malicious. About Beaglebone, probably reason is this errata: While the AM335x GP EVM has a Gb Ethernet PHY, AR8031A, on the base board, the PCB was designed to use internal clock delay mode of the RGMII interface and the AM335x does not support the internal clock delay mode. Therefore, if operating the Ethernet in Gb mode, there may be problems with the performance/function due to this. The AR8031A PHY supports internal delay mode. This can be enabled by software to guarantee Gb operation. However, this cannot be done to enable internal delay mode for Ethernet booting of course. Or maybe they just put 100Mbit PHY to make BOM cost less. As far as i know, Raspberry PI ethernet over USB might be fine for DNS too, but before it had issues with large data transfers (ethernet driver hangs). No idea about now. --- Best regards, Denys
RE: Re: Intrusion Detection recommendations
+10 The original SANS DDOS task force, and many others since, have emphasized this. Filter your Outbound! Bogons for obvious reasons, BGP3 to keep routing multipliers, non-internals to keep from being used as an amplifier network, the list goes on. Be a good network neighbor. --p -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Rich Kulawiec Sent: Saturday, February 14, 2015 4:29 PM To: nanog@nanog.org Subject: [EXTERNAL]Re: Intrusion Detection recommendations . . . This reminds me to bring up a point that can't be stressed enough: it's just as important to block *outbound* traffic as inbound. Ask Anthem. Or Target. Or the ghosts of the Trojans. ;) . . . .
Re: OT - Small DNS appliances for remote offices.
On Thu, Feb 19, 2015 at 06:18:43AM -0500, Rob Seastrom wrote: Bryan Seitz se...@bsd-unix.net writes: odroid-c1 + eMMC module + RTC battery + case + power adapter. Should run you about $75 *AND* wouldn't be bad for running NTP as well. I haven't looked into the details of the clock, so wouldn't be bad is probably true, notably good, well, that would be a task for someone with experience doing clock benchmarking and who can describe MAVAR without looking it up. The gig-e port on the C1 has been observed to push 405Mbps TX and 940Mbps+ RX via iperf. The 405 Mbps for TX. I've seen around 30 Mbyte/sec on single stream TCP RX. Got 99.5 Mbyte/sec from a Mac Mini in the same subnet so that's not a limit of the host on the other end of the benchmark. I call shenanigans on the 940 Mbps iperf number though. The HSIC bus is only 480 Mbit/sec. Two pints of beer in a one pint glass would be some trick. http://dn.odroid.com/homebackup/201411241452444193.jpg I don't think it lives on the 480Mbit/sec limited bus here. [ 3] local 192.168.1.4 port 53391 connected with 192.168.1.21 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 488 MBytes 409 Mbits/sec [ 4] local 192.168.1.4 port 5001 connected with 192.168.1.21 port 34581 [ ID] Interval Transfer Bandwidth [ 4] 0.0-10.0 sec 1.09 GBytes 939 Mbits/sec -- Bryan G. Seitz
Re: Intrusion Detection recommendations
The PIX was originally developed as a “Network Translation, Inc.” box (translation.com http://translation.com/). (John Mayes, Brantley Coile, Johnson Wu) Cisco continued the PIX name for many years and through some major changes to the operating system. A later round of major changes had it renamed to ASA. Up through PIX 7 the PIX and ASA ran the same code releases. With PIX 8, PIX continued on the Finesse OS line, but ASA went to a Linux kernel. http://en.wikipedia.org/wiki/Cisco_PIX http://en.wikipedia.org/wiki/Cisco_PIX Owen Cisco bought that and renamed it PIX On Feb 19, 2015, at 5:59 AM, Darden, Patrick patrick.dar...@p66.com wrote: I believe the ASA was first developed as the PIX on Plan 9. The OS that came out of that was originally called Finesse OS, but was later renamed as PIX OS. After Cisco purchased the PIX and renamed it to the ASA, they began using a Linux kernel around PIX OS V8. --p -Original Message- From: NANOG [mailto:nanog-bounces+patrick.darden=p66@nanog.org] On Behalf Of Justin M. Streiner Sent: Saturday, February 14, 2015 3:28 AM To: nanog@nanog.org Subject: [EXTERNAL]Re: Intrusion Detection recommendations On Fri, 13 Feb 2015, Rich Kulawiec wrote: On Fri, Feb 13, 2015 at 02:45:46PM -0600, Rafael Possamai wrote: I am a huge fan of FreeBSD, but for a medium/large business I'd definitely use a fairly well tested security appliance like Cisco's ASA. Closed-source software is faith-based security. The ASA, like so many network/security appliances anymore, runs Linux (or *BSD) under the hood, however I don't know how old or horribly mangled it is. jms
RE: HTTPv6 access to www.centurylink.com and www.qwest.com are down
I never heard back from anyone, but the two sites came back up 1:59 pm Central time, so it was down just over a week. Now it Frank -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Frank Bulk Sent: Sunday, February 15, 2015 9:39 PM To: nanog@nanog.org Subject: FW: HTTPv6 access to www.centurylink.com and www.qwest.com are down Emails to what I thought were CenturyLink's NOC have gone unanswered, and the other email address resulted in an automated you're not allowed to send emails to that group. Frank -Original Message- From: Frank Bulk Sent: Thursday, February 12, 2015 8:22 AM To: netw...@centurytel.net; 'n...@qwest.net' Subject: HTTPv6 access to www.centurylink.com and www.qwest.com are down According to our monitoring system, HTTPv6 access to www.centurylink.com and www.qwest.com have been down since 12:05 am U.S. Central, responding with a Connection refused. I've tested from two vantage points to confirm that it's not just our prefix. Diagnostic output can be found below. Regards, Frank Bulk Premier Communications root@nagios:~/tmp/ipv6# wget -6 www.centurylink.com --2015-02-12 08:18:22-- http://www.centurylink.com/ Resolving www.centurylink.com... 2001:428:b21:1::20 Connecting to www.centurylink.com|2001:428:b21:1::20|:80... failed: Connection refused. root@nagios:~/tmp/ipv6# root@nagios:~/tmp/ipv6# tcptraceroute6 www.centurylink.com traceroute to www.centurylink.com (2001:428:b21:1::20) from 2607:fe28:0:1000::5, port 80, from port 60661, 30 hops max, 60 bytes packets 1 router-core.mtcnet.net (2607:fe28:0:1000::1) 0.555 ms 19.811 ms 1.632 ms 2 sxct.sxcy.mtcnet.net (2607:fe28:11:1002::197) 0.185 ms 0.196 ms 0.115 ms 3 v6-premier.sxcy-mlx.fbnt.netins.net (2001:5f8:7f0a:2::1) 1.641 ms 1.617 ms 1.585 ms 4 v6-ins-db4-te-0-6-0-4-219.desm.netins.net (2001:5f8:1:1::1) 8.146 ms 8.003 ms 8.051 ms 5 v6-ins-dc1-te-7-4.desm.netins.net (2001:5f8::26:2) 8.035 ms 7.954 ms 7.928 ms 6 2610:18:18b:c000::11 (2610:18:18b:c000::11) 12.925 ms 12.941 ms 12.896 ms 7 mcr1.minneapolis-mn.us.xo.net (2610:18::30b8) 22.254 ms 22.234 ms 22.238 ms 8 2610:18::5802 (2610:18::5802) 32.891 ms 25.156 ms 22.868 ms 9 2610:18::2072 (2610:18::2072) 23.894 ms 22.264 ms 22.759 ms 10 2610:18:16:3000::da (2610:18:16:3000::da) 18.543 ms 18.513 ms 18.569 ms 11 2001:428::205:171:2:52 (2001:428::205:171:2:52) 28.482 ms 28.512 ms 28.549 ms 12 2001:428:1c02:2::2 (2001:428:1c02:2::2) 28.254 ms 28.277 ms 28.238 ms 13 * 2001:428:b21:fc03::2 (2001:428:b21:fc03::2) 28.871 ms 28.608 ms 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * root@nagios:~/tmp/ipv6#
Re: OT - Small DNS appliances for remote offices.
On Wed, Feb 18, 2015 at 7:24 PM, Domenick Petrella domenick.petre...@gmail.com wrote: The BeagleBone's ethernet is directly connected to the SoC, so you would get a higher throughput ceiling than the rpi. sounds super important... question though, what's the expected average/normal/budgeted rate for the remote office connection to the intertubes? + or 1 10mbps ?
Re: v6 deagg
On Thu, Feb 19, 2015 at 10:16 PM, manning bill bmann...@isi.edu wrote: and then there are the loons who will locally push /64 or longer, some of which may leak. 2001:2b8:46:::/64 ... a fairly extensive list actually show route table inet6.0 | grep ^2 | except /4[876543210] | except /3 | except /2 | count Count: 297 lines Some are likely my local network's interfaces (so skip ~50 or so? to be generous) and some might be my provider's customers? (but they shouldn't send me shorter than a /48, right?) -chris (note on another observation point I don't see this sort of thing so perhaps it's just one upstream in a collection... I'll ask them seperately)
Re: v6 deagg
Instead, we may find network equipment vendors might ship with larger/faster TCAM, and faster processing to handle increasing routing table demands. We've been hearing the end is nigh! for a decade, and as far as I can tell, we are no closer to the end than when we started. Maybe some equipment refresh cycles will increase, and some providers will have to make a choice to upgrade sooner than later. But, as network engineers and architects, surely we all know that nothing is static, and growth will continue to accelerate. Better be ready, or some of us will be left behind. On Thu, Feb 19, 2015 at 7:29 PM, Jima na...@jima.us wrote: That might be a little more valid once we move past 2000::/3 -- at the moment, more like IPv4 /29s. Alas, /48 seems to be the generally accepted maximum prefix length, so, yeah, this could be unfortunate. Jima On 2015-02-19 20:16, manning bill wrote: and then there are the loons who will locally push /64 or longer, some of which may leak. even if things were sane nothing longer than a /32 were to be in the table, are we not looking at the functional equivalent of v4 host routes? /bill PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 19February2015Thursday, at 19:07, Randy Bush ra...@psg.com wrote: in a discussion with some fellow researchers, the subject of ipv6 deaggregation arose; will it be less or more than we see in ipv4? in http://archive.psg.com/jsac-deagg.pdf it was thought that multi-homing, traffic engineering, and the /24 pollution disease were the drivers. multi-homing seems to be increasing, while the other two were stable as a relative measure to total growth. so, at first blush, we thought v6 would be about the same as v4. but then we considered that v6 allocations seem to be /32s, and the longest propagating route seems to be /48, leaving 16 bits with which the deaggregators can play. while in v4 it was /24s out of a /19 or /20, four or five bits. this does not bode well. randy -- Brent Jones br...@brentrjones.com
RE: OT - Small DNS appliances for remote offices.
If you're already installing a Cisco router, maybe look at an SRE-V module? You could install a VM/OS on the router. Cheers,Josh
draft-ietf-mpls-ldp-ipv6-16
I notice draft-ietf-mpls-ldp-ipv6-16 was posted February 11, 2015. What is the chance of getting working code this decade? I would quite like to play with this new fangled IPv6 widget... (Okay, I'd like to stop using IPv4 for infrastructure. LDP is the last piece for me.) -- Tim:
Re: OT - Small DNS appliances for remote offices.
On Thu, 19 Feb 2015 14:52:42 +, David Reader said: I'm using several to connect sensors, actuators, and such to a private network, which it's great for - but I'd think at least twice before deploying one as a public-serving host in user-experience-critical role in a remote location. I have a Pi that's found a purpose in life as a remote smokeping sensor and related network monitoring, a task it does quite nicely. Note that they just released the Pi 2, which goes from the original single-core ARM V6 to a quad-core ARM V7, and increases memory from 256M to1G. All at the same price point. That may change the calculus. I admit not having gotten one in hand to play with yet. pgpYKCg49tsqp.pgp Description: PGP signature
Re: draft-ietf-mpls-ldp-ipv6-16
Subject: draft-ietf-mpls-ldp-ipv6-16 Date: Thu, Feb 19, 2015 at 11:06:40AM -0500 Quoting Tim Durack (tdur...@gmail.com): I notice draft-ietf-mpls-ldp-ipv6-16 was posted February 11, 2015. What is the chance of getting working code this decade? I would quite like to play with this new fangled IPv6 widget... (Okay, I'd like to stop using IPv4 for infrastructure. LDP is the last piece for me.) One of the vendors has promised v6 ldp this year (as in 2015). Given the interesting bugs that surfaced when we tried a couple years ago, well, I'm at least breathing shallowly. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 I'm having a BIG BANG THEORY!! signature.asc Description: Digital signature
Re: OT - Small DNS appliances for remote offices.
On Thu, 19 Feb 2015 15:26:36 +0200 Denys Fedoryshchenko de...@visp.net.lb wrote: As far as i know, Raspberry PI ethernet over USB might be fine for DNS too, but before it had issues with large data transfers (ethernet driver hangs). No idea about now. On Thu, 19 Feb 2015 15:26:36 +0200 Denys Fedoryshchenko de...@visp.net.lb wrote: As far as i know, Raspberry PI ethernet over USB might be fine for DNS too, but before it had issues with large data transfers (ethernet driver hangs). No idea about now. AIUI the problem with the RPi isn't so much that the Ethernet NIC sits on a USB interface, it's that the RPi USB interface is very basic and requires a great deal of host interaction to work. It presents a very high interrupt load, and that can lead to problems. Remember that the RPi, fantastic as it is, was developed as a low cost educational aid. It can be used with great success in other fields, but you should consider its limitations. I'm using several to connect sensors, actuators, and such to a private network, which it's great for - but I'd think at least twice before deploying one as a public-serving host in user-experience-critical role in a remote location. d.
Re: OT - Small DNS appliances for remote offices.
People, processor of this hardware will be killed before the 100M ethernet be the problem. -- Eduardo Schoedler 2015-02-19 12:52 GMT-02:00 David Reader david.rea...@zeninternet.co.uk: On Thu, 19 Feb 2015 15:26:36 +0200 Denys Fedoryshchenko de...@visp.net.lb wrote: As far as i know, Raspberry PI ethernet over USB might be fine for DNS too, but before it had issues with large data transfers (ethernet driver hangs). No idea about now. On Thu, 19 Feb 2015 15:26:36 +0200 Denys Fedoryshchenko de...@visp.net.lb wrote: As far as i know, Raspberry PI ethernet over USB might be fine for DNS too, but before it had issues with large data transfers (ethernet driver hangs). No idea about now. AIUI the problem with the RPi isn't so much that the Ethernet NIC sits on a USB interface, it's that the RPi USB interface is very basic and requires a great deal of host interaction to work. It presents a very high interrupt load, and that can lead to problems. Remember that the RPi, fantastic as it is, was developed as a low cost educational aid. It can be used with great success in other fields, but you should consider its limitations. I'm using several to connect sensors, actuators, and such to a private network, which it's great for - but I'd think at least twice before deploying one as a public-serving host in user-experience-critical role in a remote location. d. -- Eduardo Schoedler
Re: draft-ietf-mpls-ldp-ipv6-16
ASR9K IOS-XR 5.3.0 Release Notes: IPv6 Support in MPLS LDP: Starting from release 5.3.0, support for native MPLS LDP over IPv6 is enabled to continue providing existing services seamlessly while enabling new ones. The attributes and capabilities of the existing MPLS LDP have been extended to be IPv6 aware. This is based off the -12 draft, that LDP over v6 draft has seen a lot of contention for various reasons. Details at: http://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r5-3/mp ls/configuration/guide/b-mpls-cg53x-asr9k/b-mpls-cg53x-asr9k_chapter_010.ht ml#concept_FA2F48EE4A2044458FE25897118AFBA4 If you have CCO access you can download the 5.3.0 XRv VMs and play around with it. Phil On 2/19/15, 16:06, Tim Durack tdur...@gmail.com wrote: I notice draft-ietf-mpls-ldp-ipv6-16 was posted February 11, 2015. What is the chance of getting working code this decade? I would quite like to play with this new fangled IPv6 widget... (Okay, I'd like to stop using IPv4 for infrastructure. LDP is the last piece for me.) -- Tim:
Re: v6 deagg
and then there are the loons who will locally push /64 or longer, some of which may leak. even if things were sane nothing longer than a /32 were to be in the table, are we not looking at the functional equivalent of v4 host routes? /bill PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 19February2015Thursday, at 19:07, Randy Bush ra...@psg.com wrote: in a discussion with some fellow researchers, the subject of ipv6 deaggregation arose; will it be less or more than we see in ipv4? in http://archive.psg.com/jsac-deagg.pdf it was thought that multi-homing, traffic engineering, and the /24 pollution disease were the drivers. multi-homing seems to be increasing, while the other two were stable as a relative measure to total growth. so, at first blush, we thought v6 would be about the same as v4. but then we considered that v6 allocations seem to be /32s, and the longest propagating route seems to be /48, leaving 16 bits with which the deaggregators can play. while in v4 it was /24s out of a /19 or /20, four or five bits. this does not bode well. randy
Re: draft-ietf-mpls-ldp-ipv6-16
On 2/19/15, 2:27 PM, Mark Tinka mark.ti...@seacom.mu wrote: Getting IPv6 support in LDP is one thing. This is one document that we need to keep track to know what MPLS applications currently running off of LDPv4 still need to be ported to run over LDPv6: http://tools.ietf.org/html/draft-george-mpls-ipv6-only-gap-04 The document has come out the other side of the IETF sausage grinder now: https://tools.ietf.org/html/rfc7439 Unfortunately, it's just a list of the gaps. It is worth leaning on your vendors of choice to ensure that they have people focused on addressing these issues, as not all of them have volunteers to write the documents necessary to close those gaps yet. Thanks Wes George This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
Re: v6 deagg
That might be a little more valid once we move past 2000::/3 -- at the moment, more like IPv4 /29s. Alas, /48 seems to be the generally accepted maximum prefix length, so, yeah, this could be unfortunate. Jima On 2015-02-19 20:16, manning bill wrote: and then there are the loons who will locally push /64 or longer, some of which may leak. even if things were sane nothing longer than a /32 were to be in the table, are we not looking at the functional equivalent of v4 host routes? /bill PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 19February2015Thursday, at 19:07, Randy Bush ra...@psg.com wrote: in a discussion with some fellow researchers, the subject of ipv6 deaggregation arose; will it be less or more than we see in ipv4? in http://archive.psg.com/jsac-deagg.pdf it was thought that multi-homing, traffic engineering, and the /24 pollution disease were the drivers. multi-homing seems to be increasing, while the other two were stable as a relative measure to total growth. so, at first blush, we thought v6 would be about the same as v4. but then we considered that v6 allocations seem to be /32s, and the longest propagating route seems to be /48, leaving 16 bits with which the deaggregators can play. while in v4 it was /24s out of a /19 or /20, four or five bits. this does not bode well. randy
Re: OT - Small DNS appliances for remote offices.
The BeagleBone's ethernet is directly connected to the SoC, so you would get a higher throughput ceiling than the rpi. On Wed, Feb 18, 2015, 19:03 Geoff Mulligan nano...@mulligan.org wrote: I have used the BeagleBone to run a few simple servers. I don't know if the ethernet port on the Bone is on the USB bus. It is slightly more expensive than a PI, but they have worked well for me. Geoff On 02/18/2015 04:44 PM, Peter Loron wrote: For any site where you would use a Pi as the DNS cache, it won't be an issue. DNS isn't that heavy at those query rates. Yeah, it would be awesome if they'd been able to get a SoC that included ethernet. -Pete On 2015-02-18 15:08, Robert Webb wrote: What I do not like about the Pi is the network port is on the USB bus and thus limited to USB speeds. div Original message /divdivFrom: Maxwell Cole mcole.mailingli...@gmail.com /divdivDate:02/18/2015 4:30 PM (GMT-05:00) /divdivTo: nanog@nanog.org 'NANOG list' nanog@nanog.org /divdivSubject: Re: OT - Small DNS appliances for remote offices. /divdiv /div
Re: Call For Presentations RIPE 70, submission deadline 1 March 2015
Just a reminder that this deadline is coming up! We can't wait to see your submissions :) Leslie On Tue, Jan 13, 2015 at 5:57 AM, Benno Overeinder be...@nlnetlabs.nl wrote: Dear colleagues, Please find the CFP for RIPE 70 below. The deadline for submissions is 1 March 2015. Please also note that speakers do not receive any extra reduction or funding towards the meeting fee at the RIPE Meetings. Kind regards, Benno Overeinder for the RIPE Programme Committee http://www.ripe.net/ripe/meetings/ripe-meetings/pc Call for Presentations A RIPE Meeting is an open event where Internet Service Providers, network operators and other interested parties get together. Although the meeting is mostly technical, it is also a chance for people to meet and network with others in their field. RIPE 70 will take place from 11-15 May 2015 in Amsterdam, The Netherlands. The RIPE Programme Committee (PC) is now seeking content proposals from the RIPE community for the plenary session presentations, BoFs (Birds of a Feather sessions), panels, workshops, tutorials and lightning talks at RIPE 70. The PC is looking for presentations covering topics of network engineering and operations, including but not limited to: - IPv6 deployment - Managing IPv4 scarcity in operations - Commercial transactions of IPv4 addresses - Data centre technologies - Network and DNS operations - Internet governance and regulatory practices - Network and routing security - Content delivery - Internet peering and mobile data exchange Submissions RIPE Meeting attendees are quite sensitive to keeping presentations non-commercial, and product marketing talks are strongly discouraged. Repeated audience feedback shows that the most successful talks focus on operational experience, research results, or case studies. For example, presenters wishing to describe a commercial solution should focus on the underlying technology and not attempt a product demonstration. The RIPE PC accepts proposals for different presentation formats, including plenary session presentations, tutorials, workshops, BoFs (Birds of a Feather sessions) and lightning talks. See the full descriptions of these formats at https://ripe70.ripe.net/submit-topic/presentation-formats/ Presenters who are proposing a panel or BoF are encouraged to include speakers from several (perhaps even competing) companies and/or a neutral facilitator. In addition to presentations selected in advance for the plenary, the RIPE PC also offers several time slots for lightning talks, which are selected immediately before or during the conference. The following general requirements apply: - Proposals for plenary session presentations, BoFs, panels, workshops and tutorials must be submitted for full consideration no later than 1 March 2015, using the meeting submission system at https://ripe70.ripe.net/submit-topic/submission-form/. Proposals submitted after this date will be considered on a space-available basis. Important Dates regarding RIPE 70 can be found at: https://ripe70.ripe.net/programme/important-dates/ - Lightning talks should also be submitted using the meeting submission system (https://ripe70.ripe.net/submit-topic/submission-form/) and can be submitted just days before the RIPE Meeting starts or even during the meeting week. The allocation of lightning talk slots will be announced in short notice – in some cases on the same day but often one day prior to the relevant session. - Presenters should indicate how much time they will require. See more information on time slot allocations per presentation format at https://ripe70.ripe.net/submit-topic/presentation-formats/. - Proposals for talks will only be considered by the PC if they contain at least draft presentation slides (slides may be updated later on). For panels, proposals must contain a clear description, as well as the names of invited panellists, presenters and moderators. - Due to potential technical issues, it is expected that most, if not all, presenters/panellists will be physically present at the RIPE Meeting. If you have any questions or requests concerning content submissions, please email pc [at] ripe [dot] net. -- Benno J. Overeinder NLnet Labs http://www.nlnetlabs.nl/
v6 deagg
in a discussion with some fellow researchers, the subject of ipv6 deaggregation arose; will it be less or more than we see in ipv4? in http://archive.psg.com/jsac-deagg.pdf it was thought that multi-homing, traffic engineering, and the /24 pollution disease were the drivers. multi-homing seems to be increasing, while the other two were stable as a relative measure to total growth. so, at first blush, we thought v6 would be about the same as v4. but then we considered that v6 allocations seem to be /32s, and the longest propagating route seems to be /48, leaving 16 bits with which the deaggregators can play. while in v4 it was /24s out of a /19 or /20, four or five bits. this does not bode well. randy
