July 2013 - Test - lists.nanog.org

Big day for IPv6 - 1% native penetration
by Tomas Podermanski 05 Jan '16

05 Jan '16

Hi, It seems that today is a "big day" for IPv6. It is the very first time when native IPv6 on google statistics (http://www.google.com/intl/en/ipv6/statistics.html) reached 1%. Some might say it is tremendous success after 16 years of deploying IPv6 :-) T.

87 261

How are you doing DHCPv6 ?
by Randy Carpenter 02 Apr '15

02 Apr '15

I am wondering how people out there are using DHCPv6 to handle assigning prefixes to end users. We have a requirement for it to be a redundant server that is centrally located. DHCPv6 will be relayed from each customer access segment. We have been looking at using ISC dhcpd, as that is what we use for v4. However, it currently does not support any redundancy. It also does not do very much useful logging for DHCPv6 requests. Certainly not enough to keep track of users and devices. So, my questions are: How are you doing DHCPv6 with Prefix Delegation? What software are you using? When DHCPv6 with Prefix Delegation seems to be about the only way to deploy IPv6 to end users in a generic device-agnostic fashion, I am wondering why it is so difficult to find a working solution. thanks, -Randy -- | Randy Carpenter | Vice President - IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (800)578-6381, Opt. 1 ----

13 37

Generating IPv6 list with filtergen.level3.net
by Smith, Courtney 28 Mar '15

28 Mar '15

Anyone out there know how to generate a IPv6 list Level3's filtergen? I tried Google but didn't find anything. () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

4 4

Blocking private AS
by Thomas Magill 27 Nov '13

27 Nov '13

I am thinking about implementing a filter to block all traffic with private AS numbers in the path. I see quite a few in my table though so I am concerned I might block some legitimate traffic. In some cases, these are just prefixes with the private appended to the end but a few have the private as a transit. Is this a good idea or would I likely be blocking too much legitimate traffic? The filter I am using currently shows the following: BGP table version is 5462394, local router ID is 209.112.253.4 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path * i58.68.109.0/24 x.x.x.x 0 100 0 6130 9498 10201 65534 i *> y.y.y.y 0 6130 9498 10201 65534 i * i68.115.224.0/24 x.x.x.x 0 100 0 6130 19151 20115 65011 i *> y.y.y.y 0 6130 19151 20115 65011 i * 85.112.22.0/24 y.y.y.y 0 6130 6939 23148 64532 64532 64532 64532 64532 64532 64532 64532 64532 i *> 93.189.194.0/24 y.y.y.y 0 6130 3549 39386 39386 39386 25233 65000 47146 i * i x.x.x.x 0 100 0 6130 3549 39386 39386 39386 25233 65000 47146 i *> 96.60.243.0/24 y.y.y.y 0 6130 2828 4181 65528 i * i x.x.x.x 0 100 0 6130 2828 4181 65528 i * i96.61.232.0/24 x.x.x.x 0 100 0 6130 2828 4181 65527 i *> y.y.y.y 0 6130 2828 4181 65527 i * i96.61.233.0/24 x.x.x.x 0 100 0 6130 2828 4181 65527 i *> y.y.y.y 0 6130 2828 4181 65527 i * i96.61.234.0/24 x.x.x.x 0 100 0 6130 2828 4181 65527 i *> y.y.y.y 0 6130 2828 4181 65527 i *> 148.207.2.0/24 y.y.y.y 0 6130 2828 3257 16531 13579 65090 i * i x.x.x.x 0 100 0 6130 2828 3257 16531 13579 65090 i *> 148.207.40.0/24 y.y.y.y 0 6130 2828 3257 16531 13579 65090 i * i x.x.x.x 0 100 0 6130 2828 3257 16531 13579 65090 i *> 148.207.97.0/24 y.y.y.y 0 6130 2828 3257 16531 13579 65090 i * i x.x.x.x 0 100 0 6130 2828 3257 16531 13579 65090 i * 170.34.100.0/24 y.y.y.y 0 6130 19151 20115 65011 ? * 170.34.104.0/24 y.y.y.y 0 6130 19151 20115 65011 ? * 170.34.113.0/24 y.y.y.y 0 6130 19151 20115 65011 ? * i174.35.1.0/24 x.x.x.x 0 100 0 6130 16467 64565 i * i174.47.199.0/24 x.x.x.x 0 100 0 6130 2828 4323 15065 65123 i *> y.y.y.y 0 6130 2828 4323 15065 65123 i * i192.109.61.0 x.x.x.x 0 100 0 6130 19151 20115 65011 i *> y.y.y.y 0 6130 19151 20115 65011 i *> 196.216.249.0 y.y.y.y 0 6130 2828 3257 8513 8513 8513 36881 65000 36896 37062 i * i x.x.x.x 0 100 0 6130 2828 3257 8513 8513 8513 36881 65000 36896 37062 i Network Next Hop Metric LocPrf Weight Path *> 209.172.69.128/30 y.y.y.y 0 6130 16467 64565 i * i x.x.x.x 0 100 0 6130 16467 64565 i *> 213.146.161.0 y.y.y.y 0 6130 2828 174 64679 48493 i * i x.x.x.x 0 100 0 6130 2828 174 64679 48493 i Thomas Magill Network Engineer Office: (858) 909-3777 Cell: (858) 869-9685 mailto:tmagill@providecommerce.com <mailto:tmagill@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/>

3 2

Network topology
by Colin Alston 15 Nov '13

15 Nov '13

Hi all I'm considering trying to come up with some means to automatically detect a networks topology and draw pretty pictures. This is somewhat boring though if a network isn't well arranged with VLANs and q-tag trunk routers and so on (It will just look like a big cloud of junk connected off an assumed switch). Is there any kind of cunning trick to detect standard layer2 switches along a path without stuff like STP?

9 12

NFSen plugin - ddd
by Andrew Jones 29 Oct '13

29 Oct '13

Hi All, Does anyone have a copy of the DDoS detection plugin for NFSen called ddd that they could send to me? According to a blog article [1] I read, it used to be available at [2]. It's not there, and I haven't had any luck trying to track it down the usual ways. If anyone is able to provide a copy, I'd appreciate it. Thanks, Jonesy [1] http://www.ccieflyer.com/2010-01-JasonRowley.php [2] http://www.synacknetworks.com/ddd/ddd.zip

3 3

NANOG 59 - Important Schedule Notice & Call For Presentations. Please read!
by David Temkin 24 Aug '13

24 Aug '13

NANOG Community, I hope everyone enjoyed New Orleans as much as I did! It's truly one of my favorite cities in the world. Fresh off a great meeting, we're already starting to get ready for NANOG 59 in Phoenix. If you have a topic you'd like to speak about, the program committee would love to consider it. Please watch http://www.nanog.org/meetings/nanog59/callforpresentations for more information. After considering feedback from members, speakers, ARIN, and sponsors we have decided to make a small tweak to the program timing at NANOG 59. We will continue with the Monday-Wednesday format, however we will move the ARIN Track and Tutorials to Tuesday morning, highlighting their importance to the program. The program will begin on Monday morning at 10:00AM followed by our popular Newcomers Lunch. The exact schedule layout can be found at http://www.nanog.org/meetings/nanog59/preagenda and is also attached in JPG format to this email. If you wish to submit a presentation, please keep these important dates in mind: Presentation Abstracts and Draft Slides Due: 16-Aug-2013 Slides Due: 30-Aug-2013 Topic List Posted: 06-Sep-2013 Final Agenda Published: 27-Sep-2013 Please submit your materials to http://pc.nanog.org Looking forward to seeing everyone in Phoenix! -Dave Temkin (Chair, NANOG Program Committee)

1 3

SNMP DDoS: the vulnerability you might not know you have
by bottiger 22 Aug '13

22 Aug '13

Before you skim past this email because you already read the Prolexic report on it or some other article on the internet, there are 2 disturbing properties that I haven't found anywhere else online. 1) After sending abuse emails to many networks, we received many angry replies that they monitored their traffic for days without seeing anything (even as we were being attacked) and that their IPs were spoofed and would block us for spamming them. What we discovered was that their firewalls/routers/gateways coming from vendors like Cisco and SonicWall apparently didn't record SNMP traffic going in or out of themselves. We confirmed this multiple times by running a query to an IP that was claimed to be clean and watching the response come 10-60 seconds later because the device was being so heavily abused. 2) SNMP reflection offers the largest amplification factor by far, even surpassing DNS, Chargen, or NTP by a wide margin. I have tested a 68 byte query and received responses of up to 30,000 to 60,000 bytes. The trick is to use GetBulkRequest to start enumerating from the first OID and setting max repetitions to a large number. This is contrary to the other articles online which suggest a much smaller amplification factor with other queries. This protocol is also prevalent in many devices ranging from routers to printers. To solve this problem you should block SNMP traffic coming from outside your network and whitelist outside IPs that require it.

17 34

.gov DNSSEC operational message
by Wessels, Duane 14 Aug '13

14 Aug '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 An algorithm roll for the .gov zone will occur at the end of August, 2013. This notice is provided as a courtesy to the DNSSEC community. No action should be required on your part. The .gov zone is currently signed with algorithm 7 (RSASHA1-NSEC3-SHA1) and will be changed to use algorithm 8 (RSA/SHA-256), bringing it in line with other top-level domains such as as .com, .net, and the root zone. The zone will be signed with both algorithms for a period of approximately 10 days. Further scheduling details will be provided one week before the algorithm roll begins. Duane W. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJR+BwJAAoJEGyZpGmowJiNb1QIAL4VURzp377H7iX8ZaBfljTt pdj6gTyChZe4M4AwTslT3woTBMwJZsOYxMKFnGcPoxFd0ROT1HuFKt1JE5G6ITBN +qHQJFplgU4SBKcknAcIL5/0DXgqeGVR9JYsbkRiytocp89eBWx8lhZuVRqQCRDw u/ZiKluAd32ioSosuzAJJawRp0PZQKJX8/WQ5HnLPeDpH3jHDR21I5RDp35l8X0x GIiD9+UV1yivYr4JhjLfVqTkToND+m3rwG7c6VwUf8PxCv5mEJN3sFpC72HsRvCd uNipDuwaAcYLFCx3mSUsuXjUttUXe9yFE9v3rPZ286eMo5GqVvs+Zy7yjrQuOpU= =p/aG -----END PGP SIGNATURE-----

1 1

which firewall product?
by William Herrin 05 Aug '13

05 Aug '13

Hi folks, I'm trying to identify a firewall appliance for one of my customers. The wrinkle is: it has to be able to inspect packets inside an IPIP tunnel and accept/reject based on IP address, TCP port number and standard things like that. On the packet carried *inside* the IPIP tunnel packet. >From what I can tell, the Cisco ASA can't do this. Linux iptables can (with the u32 match module) but the customer wants an appliance, not a server. What appliances do you know of that can do this? Is there a different Cisco box? A Juniper firewall? Anything else? Thanks in advance, Bill Herrin -- William D. Herrin ................ herrin(a)dirtside.com bill(a)herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004

12 16