December 2013 - 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

Call for Presentations RIPE 68
by Filiz Yilmaz 12 Feb '14

12 Feb '14

Dear colleagues, Please find the CFP for RIPE 68 below or at https://ripe68.ripe.net/submit-topic/cfp/. The deadline for submissions is 2 March 2014. Please also note that speakers do not receive any extra reduction or funding towards the meeting fee at the RIPE Meetings. Kind regards Filiz Yilmaz RIPE PC Chair 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 68 will take place from 12 – 16 May 2014 in Warsaw, Poland. 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 68. 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://ripe68.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 2 March 2014, using the meeting submission system at https://ripe68.ripe.net/submit-topic/guidelines/. Proposals submitted after this date will be considered on a space-available basis. - Lightning talks should also be submitted using the meeting submission system (https://ripe68.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://ripe68.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 panelists, presenters and moderators. - Due to potential technical issues, it is expected that most, if not all, presenters/panelists 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. ---------------------

1 1

AT&T UVERSE Native IPv6, a HOWTO
by Andrew D Kirch 09 Jan '14

09 Jan '14

Special thanks to Alexander from AT&T's "Tier-2" dept, though my suspicion is that that is not where he works, as he seems exceptionally clueful. Additional thanks to Owen DeLong who finally got me off my ass to actually do this, I'll see you in the sky! Ok, is this core routing? not really, but it's nice to see a major clue injection over at AT&T Uverse. I'm using this to document the MASSIVE bureaucratic PITA which is getting native IPv6 on uverse. You'll start from the default service on a 2wire "modem" (for values of modem that equate to profanity). If you have the Motorola NVG589, count yourself lucky and skip most of these steps. Abandon all hope ye who enter here.... Step 1: contact AT&T Uverse support and complain that you need IPv6 (because we all need it, I in fact do for work). Step 2: general confusion as the level 1 droid doesn't know what IPv6 is, politely request to be transferred to tier 2 step 3: you will be told that tier 2 is a paid service, invoke the almighty FCC and ask to speak with a supervisor, expect a long hold here. step 4: you arrive at tier 2, mention that IPv6 won't work on your 2wire and that AT&T has broken your protocol 41 tunnel with <insert tunnel broker here, usually HE> step 5: you'll need to get your 2wire replaced with a Motorola NVG589. Again you will be threatened with a cost to upgrade, mine was waived due to the work requirement. I'd guess some additional complaining and escalation will get this fee waived. My recollection was it was $100. The new modem is good news for quite a few reasons, the 2wire sucks, the Motorola sucks significantly less, and has a built in battery backup, but mine lacked the battery. step 6: you'll receive the motorola by mail, or have a tech install it, they actually had a tech in my area and I had an AT&T tech at my door in less than 20 minutes from when I got off the phone with tier-2 (I about died from the shock). step 7: configure the motorola (192.168.1.254) for passthrough, DHCPS-dynamic, disable the firewall, the "advanced" firewall, hpna, wireless, etc. Step 8: reboot to push the public IP to your real router. step 9: head over to the Motorola's home network tab, and in the status window you'll see: IPv6 Status Available Global IPv6 Address 2602:306:cddd:xxxx::1/64 Link-local IPv6 Address fe80::923e:abff:xxxx:7e40 Router Advertisement Prefix 2602:306:cddd:xxxx::/64 IPV6 Delegated LAN Prefix 2602:306:cddd:xxxx:: 2602:306:cddd:xxxx:: In reality additional poking leads me to believe AT&T gives you a rather generous /60, but how to use it? step 10: set up dhcpv6, example for mikrotik follows (but should be easily convertible to nearly any router): /ipv6> export # dec/31/2001 20:26:03 by RouterOS 6.6 # software id = 5F2Y-X73L # /ipv6 address add address=2602:306:cddd:xxxx::1 from-pool=AT&T interface=bridge1 /ipv6 dhcp-client add add-default-route=yes interface=ether10 pool-name=AT&T I hope that this is of help to someone. Andrew

36 101

Vyatta to VyOS
by Ray Soucy 07 Jan '14

07 Jan '14

Many here might be interested, In response to Brocade not giving the community edition of Vyatta much attention recently, some of the more active community members have created a fork of the GPL code used in Vyatta. It's called VyOS, and yesterday they released 1.0. http://vyos.net/ I've been playing with the development builds and it seems to be every bit as stable as the Vyatta releases. Will be interesting to see how the project unfolds :-) -- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net

8 8

turning on comcast v6
by Randy Bush 06 Jan '14

06 Jan '14

http://comcast6.net/ tells me that the local cmts is v6 enabled. my modem, a cisco dpc3008, is in the supported products list. so how do i turn the sucker on? randy

54 139

Comcast/Level3 issues
by Douglas Wheet 05 Jan '14

05 Jan '14

Looking for a networking contact at comcast and/or level3. I've been having some slow speed issues with hitting some sites that's going through level3 and I think there might be some congestion. Doug

4 3