May 2014 - Test - lists.nanog.org

common checks performed when passing on an IPv4 PA allocation from one end-customer to another
by Martin T 23 Feb '16

23 Feb '16

Hi, when one end-customer has been using for example /24 IPv4 allocation for a while and returns this(for example changes an ISP) to LIR, then are there some good practices before handing out this same /24 to a new customer? I guess LIR should: 1) remove all the DNS PTR records, classless of classful delegations 2) check if some of the IP addresses are in DNSBL(maybe the previous customer was a spammer). Example with 93.184.216.0/24: $ for ip in {0..255}.216.184.93;\ > do for addr in \ > cbl.abuseat.org \ > dnsbl.inps.de \ > no-more-funn.moensted.dk \ > dnsbl.sorbs.net \ > bl.spamcannibal.org \ > bl.spamcop.net \ > psbl.surriel.com \ > dnsrbl.swinog.ch; \ > do dig @8.8.8.8 "$ip"."$addr" +short | grep -q "^127.0.0." && \ > echo "DNSBL-Alarm: $ip is listed on $addr"; done; done $ Anything else? regards, Martin

2 4

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

06 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

The state of TACACS+
by Robert Drake 05 Jan '15

05 Jan '15

Ever since first using it I've always liked tacacs+. Having said that I've grown to dislike some things about it recently. I guess, there have always been problems but I've been willing to leave them alone. I don't have time to give the code a real deep inspection, so I'm interested in others thoughts about it. I suspect people have just left it alone because it works. Also I apologize if this is too verbose or technical, or not technical enough, or just hard to read. History: TACACS+ was proposed as a standard to the IETF. They never adopted it and let the standards draft expire in 1998. Since then there have been no official changes to the code. Much has happened between now and then. I specifically was interested in parsing tac_plus logs correctly. After finding idiosyncrasies I decided to look at the source and the RFC to see what was really happening. Logging, or why I got into this mess: In the accounting log, fields are sometimes logged in different order. It appears the client is logging whatever it receives without parsing it or modifying it. That means the remote system is sending them in different orders, so technically the fault lies with them. However, it seems too trusting to take in data and log it without looking at it. This can also cause issues when you send a command like (Cisco) "dir /all nvram:" on a box with many files. The device expands the command to include everything on the nvram (important because you might want to deny access to that command based on something it expanded), but it gets truncated somewhere (not sure if it's the device buffer that is full, tac_plus, or the logging part. I might tcpdump for a while to see if I can figure out what it looks like on the wire) I'm not sure if there are security implications there. Encryption: The existing security consists of md5 XOR <content> with the md5 being composed of a running series of 16 byte hashes, taking the previous hash as part of the seed of the next hash. A sequence number is used so simple replay shouldn't be a factor. Depending on how vulnerable iterative md5 is to it, and how much time you had to sniff the traffic, I would think this would be highly vulnerable to chosen plaintext if you already have a user-level login, or at least partial known plaintext (with the assumption they make backups, you can guess that at least some of the packets will have "show running-config" and other common commands). They also don't pad the encrypted string so you can guess the command (or password) based on the length of the encrypted data. For a better description of the encryption you can read the draft: http://tools.ietf.org/html/draft-grant-tacacs-02 I found an article from May, 2000 which shows that the encryption scheme chosen was insufficient even then. http://www.openwall.com/articles/TACACS+-Protocol-Security For new crypto I would advise multiple cipher support with negotiation so you know what each client and server is capable of. If the client and server supported multiple keys (with a keyid) it would be easier to roll keys frequently, or if it isn't too much overhead they could use public key. Clients: As for clients, Wikipedia lists several that seem to be based on the original open-source tac_plus from Cisco. shrubbery.net has the "official" version that debian and freebsd use. I looked at some of the others and they all seemed to derive from Cisco's code directly or shrubbery.net code, but they retained the name and started doing their own versioning. All the webpages look like they're from 1995. In some cases I think it's intentional but in some ways it shows a lack of care for the code, like it's been dropped since 2000. Documentation is old: This only applies to shrubbery.net's version. I didn't look at the other ones that closely. While all of it appears valid, one Q&A in the FAQ was about IOS 10.3/11.0. Performance questions use the sparc 2 as a target machine. There isn't an INSTALL or README, just the FAQ/CHANGES/COPYING (and a tac_plus.conf manpage), so the learning curve for new users is probably pretty steep. Also there isn't a clear maintainer. The best email address I found was listed in the tacacs+.spec file, for packaging on rpm systems. If you hit the website they give some hints with some outdated, though still functional links. And they list the official email as tac_plus(a)shrubbery.net Conclusion: Did everyone already know this but me? If so have you moved to Kerberos? Can Kerberos do everything TACACS+ was doing for router authorization? I've got gear that only supports radius and tacacsplus, so in some cases I have no choice but to use one of those, neither of which I would trust over an unencrypted wire. If TACACS+ isn't a dead end then it needs a push to bring the protocol to a new version. There are big name vendors involved in making supported clients and servers. There should be someone invested in keeping it secure and adding features.

19 30

pay.gov and IPv6
by Matthew Kaufman 27 Oct '14

27 Oct '14

Random IPv6 complaint of the day: redirects from FCC.gov to pay.gov fail when clients have IPv6 enabled. Work fine if IPv6 is off. One more set of client computers that should be dual-stacked are now relegated to IPv4-only until someone remembers to turn it back on for each of them... sigh. Matthew Kaufman

9 14

Getting pretty close to default IPv4 route maximum for 6500/7600 routers.
by Drew Weaver 13 Jun '14

13 Jun '14

Hi all, I am wondering if maybe we should make some kind of concerted effort to remind folks about the IPv4 routing table inching closer and closer to the 512K route mark. We are at about 94/95% right now of 512K. For most of us, the 512K route mark is arbitrary but for a lot of folks who may still be running 6500/7600 or other routers which are by default configured to crash and burn after 512K routes; it may be a valuable public service. Even if you don't have this scenario in your network today; chances are you connect to someone who connects to someone who connects to someone (etc...) that does. In case anyone wants to check on a 6500, you can run: show platform hardware capacity pfc and then look under L3 Forwarding Resources. Just something to think about before it becomes a story the community talks about for the next decade. -Drew

25 44

Re: Getting pretty close to default IPv4 route maximum for 6500/7600 routers.
by Larry Sheldon 11 Jun '14

11 Jun '14

On 5/6/2014 10:39 AM, Drew Weaver wrote: > Just something to think about before it becomes a story the community > talks about for the next decade. Like we have for the last two? -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker)

12 16

Off Topic Friday
by Alain Hebert 02 Jun '14

02 Jun '14

Well happy friday. We're planning to build a MPLS lab this summer. If anyone has suggestion for cheap hardware to simulate a implementation of all the RFC's from the Core to the CPE. it would be greatly appreciated. >From our research, It is pretty much all over the place, like the vendor did it on purpose to milk all the money they could from the spec :). As usual, off-list would be best. PS: I'll forward a summary of the information to the people interested by this subject. -- ----- Alain Hebert ahebert(a)pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443

5 5

BGP Update Report
by cidr-report＠potaroo.net 30 May '14

30 May '14

BGP Update Report Interval: 22-May-14 -to- 29-May-14 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9829 110737 4.6% 107.2 -- BSNL-NIB National Internet Backbone,IN 2 - AS16625 72210 3.0% 451.3 -- AKAMAI-AS - Akamai Technologies, Inc.,US 3 - AS28885 47124 1.9% 306.0 -- OMANTEL-NAP-AS OmanTel NAP,OM 4 - AS8402 40557 1.7% 53.2 -- CORBINA-AS OJSC "Vimpelcom",RU 5 - AS28573 35149 1.4% 9.2 -- NET Serviços de Comunicação S.A.,BR 6 - AS48159 32851 1.4% 157.9 -- TIC-AS Telecommunication Infrastructure Company,IR 7 - AS23752 23801 1.0% 355.2 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 8 - AS10481 21890 0.9% 4.1 -- Prima S.A.,AR 9 - AS41691 20865 0.9% 907.2 -- SUMTEL-AS-RIPE Summa Telecom LLC,RU 10 - AS25184 17174 0.7% 134.2 -- AFRANET AFRANET Co. Tehran, Iran,IR 11 - AS14259 15809 0.7% 1317.4 -- Gtd Internet S.A.,CL 12 - AS4775 15800 0.7% 1128.6 -- GLOBE-TELECOM-AS Globe Telecoms,PH 13 - AS7552 14663 0.6% 12.1 -- VIETEL-AS-AP Viettel Corporation,VN 14 - AS27738 13362 0.6% 23.2 -- Ecuadortelecom S.A.,EC 15 - AS6629 12610 0.5% 12610.0 -- NOAA-AS - NOAA,US 16 - AS10620 11591 0.5% 4.8 -- Telmex Colombia S.A.,CO 17 - AS5800 11367 0.5% 77.3 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center,US 18 - AS6713 10934 0.5% 18.7 -- IAM-AS,MA 19 - AS35819 10655 0.4% 20.7 -- MOBILY-AS Etihad Etisalat Company (Mobily),SA 20 - AS647 10263 0.4% 77.2 -- DNIC-ASBLK-00616-00665 - DoD Network Information Center,US TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS6629 12610 0.5% 12610.0 -- NOAA-AS - NOAA,US 2 - AS6459 7679 0.3% 7679.0 -- TRANSBEAM - I-2000, Inc.,US 3 - AS54465 7263 0.3% 7263.0 -- QPM-AS-1 - QuickPlay Media Inc.,US 4 - AS60345 10114 0.4% 5057.0 -- NBITI-AS Nahjol Balagheh International Research Institution,IR 5 - AS45590 2803 0.1% 2803.0 -- HGCINTNET-AS-AP Hutch Connect,HK 6 - AS18135 9019 0.4% 1803.8 -- BTV BTV Cable television,JP 7 - AS3 1491 0.1% 1987.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 8 - AS60134 1351 0.1% 1351.0 -- FRESHNET-AS FreshNet Ltd.,UA 9 - AS14259 15809 0.7% 1317.4 -- Gtd Internet S.A.,CL 10 - AS4775 15800 0.7% 1128.6 -- GLOBE-TELECOM-AS Globe Telecoms,PH 11 - AS24683 1022 0.0% 1022.0 -- OSU-AS State Educational Institution of Higher Professional Education Orenburg State University,RU 12 - AS41691 20865 0.9% 907.2 -- SUMTEL-AS-RIPE Summa Telecom LLC,RU 13 - AS61976 694 0.0% 694.0 -- CODESPRING-AS Codespring SRL,RO 14 - AS4 645 0.0% 1417.0 -- ISI-AS - University of Southern California,US 15 - AS43095 571 0.0% 571.0 -- FUNDSERVICEBANK-NET OJSC FUNDSERVICEBANK,RU 16 - AS37447 2280 0.1% 570.0 -- OASIS-SPRL,CD 17 - AS44960 553 0.0% 553.0 -- CRYSTAL-SYSTEM-AS Crystal System SRL,RO 18 - AS37115 521 0.0% 521.0 -- TMP-UG,UG 19 - AS28236 2060 0.1% 515.0 -- PRTURBO INTERNET WIRELLESS EPP LTDA,BR 20 - AS53149 3563 0.1% 509.0 -- csc machado cia ltda,BR TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 89.221.206.0/24 20783 0.8% AS41691 -- SUMTEL-AS-RIPE Summa Telecom LLC,RU 2 - 192.58.232.0/24 12610 0.5% AS6629 -- NOAA-AS - NOAA,US 3 - 202.70.64.0/21 11787 0.5% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 4 - 202.70.88.0/21 11489 0.5% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 5 - 78.109.192.0/20 10107 0.4% AS25184 -- AFRANET AFRANET Co. Tehran, Iran,IR 6 - 184.31.240.0/20 9337 0.4% AS16625 -- AKAMAI-AS - Akamai Technologies, Inc.,US 7 - 184.25.164.0/22 9240 0.4% AS16625 -- AKAMAI-AS - Akamai Technologies, Inc.,US 8 - 184.24.154.0/23 9238 0.4% AS16625 -- AKAMAI-AS - Akamai Technologies, Inc.,US 9 - 23.46.144.0/20 9055 0.3% AS16625 -- AKAMAI-AS - Akamai Technologies, Inc.,US 10 - 42.83.48.0/20 9012 0.3% AS18135 -- BTV BTV Cable television,JP 11 - 172.224.144.0/20 8793 0.3% AS16625 -- AKAMAI-AS - Akamai Technologies, Inc.,US 12 - 172.224.160.0/22 8733 0.3% AS16625 -- AKAMAI-AS - Akamai Technologies, Inc.,US 13 - 172.224.128.0/20 8691 0.3% AS16625 -- AKAMAI-AS - Akamai Technologies, Inc.,US 14 - 172.224.114.0/23 8642 0.3% AS16625 -- AKAMAI-AS - Akamai Technologies, Inc.,US 15 - 120.28.62.0/24 7957 0.3% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms,PH 16 - 205.247.12.0/24 7679 0.3% AS6459 -- TRANSBEAM - I-2000, Inc.,US 17 - 222.127.0.0/24 7559 0.3% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms,PH 18 - 206.152.15.0/24 7263 0.3% AS54465 -- QPM-AS-1 - QuickPlay Media Inc.,US 19 - 78.158.184.0/24 5083 0.2% AS60345 -- NBITI-AS Nahjol Balagheh International Research Institution,IR 20 - 5.160.10.0/24 5031 0.2% AS60345 -- NBITI-AS Nahjol Balagheh International Research Institution,IR Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog(a)nanog.org eof-list(a)ripe.net apops(a)apops.net routing-wg(a)ripe.net afnog(a)afnog.org

1 0