January 2011 - Test - lists.nanog.org

Re: Future of the IPv6 CPE survey on RIPE Labs - Your Input Needed
by Brielle 27 Jan '11

27 Jan '11

On Thu, January 27, 2011 2:31 pm, Joel Jaeggli wrote: > On 1/27/11 10:01 AM, Jim Gettys wrote: >> For god's sake, stay away from the DIR-825(Rev A), which has been effectively abandoned by DLINK support and has no IPv6 support at all. > pretty sure you can't find those on the shelf... > The current model I bought on a lark for someone for christmas 2009 and have subsequently purchased several more, and not just becasue of the ipv6 support. The DIR-615 Rev C1 and higher are fairly decent, and both OpenWRT and DD-WRT capable. The TrendNet TEW623BRP and friends of that era are basically rebranded DIR-615 C1s. Both are fairly inexpensive and quite capable once you get rid of the stock software. -- Brielle Bruns http://www.sosdg.org / http://www.ahbl.org

1 0

RE: Future of the IPv6 CPE survey on RIPE Labs - Your Input Needed
by Scott Weeks 27 Jan '11

27 Jan '11

--- frnkblk(a)iname.com wrote: From: "Frank Bulk" <frnkblk(a)iname.com> Have you looked at D-Link's DIR-825? It has most of the things you're ------------------------------------------- Ewww, yuck! "...this router utilizes dual active firewalls (SPI and NAT) to prevent potential attacks from across the Internet." ftp://ftp.dlink.com/Gateway/dir825/Manual/dir825_manual_110.zip scott

2 1

Future of the IPv6 CPE survey on RIPE Labs - Your Input Needed
by Mirjam Kuehne 27 Jan '11

27 Jan '11

[apologies for duplicates] Hello, Based on new information we received since the last publication, we updated the IPv6 CPE matrix: http://labs.ripe.net/Members/mirjam/ipv6-cpe-survey-updated-january-2011 In order to make this information more useful for a large user base, we are preparing a detailed survey to gather more structural feedback about the range of equipment that is currently in use. Not only would we like you to participate in this survey, but we also ask for your help in identifying the right survey questions. Please find a call for input on RIPE Labs: http://labs.ripe.net/Members/marco/future-of-the-ipv6-cpe-survey-more-input… Kind Regards, Mirjam Kuehne & Marco Hogewoning RIPE NCC

11 17

Re: [dnsext] Historical root keys: The Large Router Vendor Speaks
by Jay Ashworth 27 Jan '11

27 Jan '11

----- Original Message ----- > From: "John Bashinski" <jbash(a)cisco.com> > Well, this has generated some interesting messages, and apparently > some people think that the "large router vendor" in question should > speak for itself. Yay! > Realities > ========= > 5. Some of the people installing these products (frankly including some > of the professional network gear) will have no clue what DNSSEC is > or what cryptography is. > > 6. In the case of the consumer gear, the cost to us of helping the > customer deal with any DNSSEC failure will be greater than the entire profit > we make on the device. > > 7. Even for professional gear, customers don't want to pay their staff > to mess with this, and we don't want to pay our staff to support > them. > > 8. Lots of our products get drop-shipped to people's field offices, > get plugged in by a wire-plugger-inner who basically just checks > that the lights are on and goes on to the next task, and then > have to fend for themselves, at least enough to be able to talk > to the NOC and await further instructions. > > Implication B: As much as it possibly can, anything we do must work > without human intervention, and especially without very skilled > intervention. We know there will be problems, but we MUST minimize > them and minimize the amount of "touch" required to fix them. > > Implication C: Social engineering is almost always a bigger risk than > cryptographic failure, especially at the device end of the > communication chain. That block of (correct) observations, coupled with later ones which I've elided for space, suggests to me the following observation: There is a limit to the maximum practical security and trust which can be engineered into the Internet at Large, absent some investment by specific users/network operators who require more. That observation shouldn't apply to the people who actually have a reason to be on this list -- backbone operators and professional DNS zone server operators *should* make that investment, as a contribution to the Public Good... but you can't necessarily expect it at the edge. My experience, and the integration of all the things I've learned in doing this for 25 years, is that complexity reaches a tipping point; there's only so much of it you can allow and still have a stable system -- and the complexity "attack surface" is at least proportional to the size of the system itself; something the size of The Entire Internet has even more stringent limits in that regard than, say, an enterprise LAN/WAN. So while I applaud Cisco's (or, more properly, John's) evaluation of the situation, and statement of goals -- and I agree with nearly everything he says -- my personal opinion is that there's a practical limit as to how close to the edge you can push the event horizon without the whole thing falling over... and I don't think that number's 100%. Cheers, -- jra

1 0

Re: Found: Who is responsible for no more IP addresses
by Jay Ashworth 27 Jan '11

27 Jan '11

[ Sorry; forgot to address this to the list, earlier. ] ----- Original Message ----- > From: "Brian Johnson" <bjohnson(a)drtel.com> > I'm a bit torn on this issue. I haven't even heard any other > "main-stream" sources say anything on this topic. But Incorrect info > is bad too. > > I hope the viewers who watched this are getting the gist that > "Something wicked this way comes". :) Vint was quoted as saying this some months ago, I believe in a story linked from Slashdot on a reputable news outlet. Sure enough: https://encrypted.google.com/search?q=vint+cerf+IP+address Cheers, -- jra

1 0

Contact at Dynadot
by Christopher 27 Jan '11

27 Jan '11

I have been knocking down this Romanian IRC botnet since Thanksgiving and Dynadot has been dragging their feet. I even called and talked to someone in tech support, which was an Asian guy with a small grasp of English but that's another discussion, and still they say they are "investigating it" Does anyone have a personal contact at Dynadot to get this escalated? It's painfully obvious and needs no investigation because they can look at the past DNS records for this subdomains to see the constant changes and updates with totally random IP addresses - customer DSL IP addresses, Russia, China, EDU institutions worldwide, etc. Please contact me off list. Thank you

1 0

NANOG 51 (Miami): ISP Security BOF
by Paul Scanlon 27 Jan '11

27 Jan '11

Hi All, Happy New Year. NANOG 51 in Miami is rapidly approaching, January 30 - February 2, and we are looking for topics for the ISP Security BOF. Eric Osterweil and I are going to be moderating this year with the assistance of Danny McPherson. We would very much like to hear your feedback regarding topics of interest for the session. If you have any security related topics that you would like to hear about, not hear about, or be willing to speak about, please let one of us know as soon as possible, feedback to the list obviously welcome. Slides are welcome but not required. Much thanks, Eric & Paul ------------------------------------ Paul Scanlon Arbor Networks +1.303.477.0919 office +1.303.810.7260 mobile ------------------------------------

2 2

Re: NANOG Digest, Vol 36, Issue 141
by Ivan Brunello 27 Jan '11

27 Jan '11

> > Message: 10 > Date: Tue, 25 Jan 2011 16:11:46 -0500 > From: Christopher <caldcv(a)gmail.com> > Subject: Re: Network Naming > To: nanog(a)nanog.org > Message-ID: <4D3F3C92.9050401(a)gmail.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > I usually name them after ex-girlfriends > > > On 01/25/2011 03:50 PM, Nick Olsen wrote: > > Whats the rule of thumb for naming gear these days > > (routers,switches...etc). Or is there one? > > > > looks like level3 does something like > > interface.routertype.location.level3.net > > > > Nick Olsen > > Network Operations > > (855) FLSPEED x106 > > > > > > > I would then get short of names VERY FAST :-) Ivan Brunello Net Ops ....

2 1

Re: Using IPv6 with prefixes shorter than a /64 on a LAN
by bmanning＠vacation.karoshi.com 26 Jan '11

26 Jan '11

well... you are correct - he did say shorter. me - i'd hollar for my good friends Fred and Radia (helped w/ the old vitalink mess) on the best way to manage an arp storm and/or cam table of a /64 of MAC addresses. :) It was hard enough to manage a "lan"/single broadcast domain that was global in scope and had 300,000 devices on it. "route when you can, bridge when you must" --bill On Mon, Jan 24, 2011 at 08:58:25AM -0800, Owen DeLong wrote: > Bill... Last I looked, /120 was longer than /64, not shorter. > > What I'm not understanding would be why anyone would want to use > something shorter than /64 on a LAN. > > Owen > > On Jan 24, 2011, at 5:28 AM, bmanning(a)vacation.karoshi.com wrote: > > > as a test case, i built a small home network out of /120. works just fine. > > my home network has been native IPv6 for about 5 years now, using a /96 and IVI. > > > > some thoughts. disable RD/RA/ND. > > none of the DHCPv6 code works like DHCP, so I re-wrote > > client and server code so that it does. > > static address assignment is a good thing for services like DNS/HTTP > > secure dynmaic update is your friend > > > > summary - its not easy, vendors don't want to help. but it can be done. > > > > --bill > > > > > > On Mon, Jan 24, 2011 at 10:59:59AM -0200, Carlos Martinez-Cagnazzo wrote: > >> The subject says it all... anyone with experience with a setup like this ? > >> > >> I am particularly wondering about possible NDP breakage. > >> > >> cheers! > >> > >> Carlos > >> > >> -- > >> -- > >> ========================= > >> Carlos M. Martinez-Cagnazzo > >> http://www.labs.lacnic.net > >> ========================= >

3 4

IPv6 filtering
by Franck Martin 26 Jan '11

26 Jan '11

• ipv6 41 IPv6 # IPv6 • ipv6-route 43 IPv6-Route # Routing Header for IPv6 • ipv6-frag 44 IPv6-Frag # Fragment Header for IPv6 • ipv6-crypt 50 IPv6-Crypt # Encryption Header for IPv6 • ipv6-auth 51 IPv6-Auth # Authentication Header for IPv6 • ipv6-icmp 58 IPv6-ICMP icmpv6 icmp6 # ICMP for IPv6 • ipv6-nonxt 59 IPv6-NoNxt # No Next Header for IPv6 • ipv6-opts 60 IPv6-Opts # Destination Options for IPv6 Ok filtering ipv6 and ipv6-icmp is understood, it is like ipv4. But what about the others, should they be blocked, restricted? Does a ios "deny ipv6 any any" affect them?

9 9