January 2011 - Test - lists.nanog.org

NIST IPv6 document
by Jeff Wheeler 06 Jan '11

06 Jan '11

On Thu, Jan 6, 2011 at 12:17 AM, Joe Greco <jgreco(a)ns.sol.net> wrote: > However, that's not the only potential use! A client that initiates > each new outbound connection from a different IP address is doing > something Really Good. No, Joe, it is not doing anything Good. This would require the software being written to make such random address selection, add more entries to the router's NDP table, and it would DoS the box's own router if an outbound scan were initiated from the host machine. Again, you totally fail to understand the problem. I should just attach a "facepalm" graphic to my reply and stop bothering with your idiocy, but it is important that as many people as possible understand these issues. Every additional person who is expressing concern to their vendors brings us closer to a solution. In addition, if the machine can choose another random IPv6 address in the /64 for each new outgoing connection, it could just as easily source all its outgoing connections from ... a single IPv6 address that does not accept any incoming connections. I will grant that this does not prevent "magic packet" attacks against bugs in the machine in kernel space, and that the machine could be the recipient of a DoS attack; but your proposed solution has no advantage in the case of, say, SQL Slammer 6, or other attacks exploiting vulnerabilities in user-space. On Thu, Jan 6, 2011 at 12:25 AM, Owen DeLong <owen(a)delong.com> wrote: > Is there any reason we really need to care what size other people use for their Point to Point > links? > > Personally, I think /64 works just fine. > > I won't criticize anyone for using it. It's what I choose to use. You should care what size you choose, Owen. I would if I was your customer. There are several reasons why. If you configure a /64 on a point-to-point interface e.g. SONET, some current platforms will bounce any "scan" packets back and forth between the two hosts until the TTL expires, which means an attacker can saturate the point-to-point link with two orders of magnitude less attack traffic than the link capacity. This is very bad. Also, if the link is a LAN, you are vulnerable to the ARP/NDP problem. This may be a per-interface issue on your box, or it may be a global one. In the per-interface case, most likely, the failure mode will be okay; but some vendors (including Juniper?) will eventually expire the ARP/NDP entry even though there is active traffic, and may be unable to re-learn it when needed due to the attack, which would break the link between routers. On the other hand, if it's a global issue, it will break NDP on the entire router, affecting all interfaces by whatever the platform's failure mode is. Obviously, that is worse. This is why "RFC compliant" is wrong, Owen. That a learned, experienced person such as yourself has no clue what the underlying problem is exemplifies my point: much, much more noise needs to be made about this issue. A lot of smart people have known about it for years but nothing is being done. Anyone can choose not to use /64 on their point-to-point links with no consequence to their business. Customers aren't going to choose another vendor because they are likely never even aware of it. The operational problem is that customers will want it on the PE/CE LANs, hosting center LANs, and so on; and right now, if you tell them "we can't do that," they have trouble believing you because the standard says otherwise, and a lot of other networks are currently doing it (because they think they don't have a choice other than to lose potential customers.) However, if you are running /64 instead of something like /124 on your VLANs or SONET circuits between routers, you should change this practice as soon as practical. Not doing so once you have been educated about this problem because it is "the standard" is very stupid. Pretty much every major transit network has figured this out and are doing it on their interfaces to BGP customers, too, either optionally, by default, or as the only choice. The industry standard must change to be non-hostile toward choosing a smaller subnet size than /64 to give coverage to those of us who do understand what we are doing as we roll out IPv6 to customers. -- Jeff S Wheeler <jsw(a)inconcepts.biz> Sr Network Operator / Innovative Network Concepts

10 12

The FCC on IPv6
by Steven Bellovin 06 Jan '11

06 Jan '11

http://hraunfoss.fcc.gov/edocs_public/attachmatch/DOC-303870A1.pdf --Steve Bellovin, http://www.cs.columbia.edu/~smb

1 0

Verizon DSL Transport Contact?
by nanog＠velocity.net 06 Jan '11

06 Jan '11

Hello NANOG, Excuse me if I've missed something, but I cannot seem to get to the proper Verizon tech to get this corrected. We're an ISP in Erie, PA who "leases" Verizon DSL service. Verizon then drops this service on an ATM PVC on a DS3 that we terminate into our own gear. The current problem is that every evening between 6 and 10 pm localtime (think residential peak hours) we get packet loss (1-30%) to several DSL customers. The customers call complaining that browsing is slow and that they lose packets and cannot play games, watch Netflix, etc. There are other customers that ride the same DS3s that do not experience any packet loss. The physical DS3s are not taking errors and are well under 50% capacity during the problem period. The problem DSL circuits come from a few different COs here, ERIEPAXW and ERIEPAXS at least. All I can assume is that the DS3/OC3/etc that transports this data from some point to ERIEPAXM (where we connect via DS3) gets full. The problem goes away after 10pm and crops back up the next day. Sometimes it lasts 15 minutes, sometimes all 4 hours. I have detailed logs and locations of the circuits to provide to a Verizon tech if needed. Thanks, Velocity.Net

2 1

Where to go for connectivity in VA / DC
by bas 06 Jan '11

06 Jan '11

Hi, We've recently opened a POP in northern Virginia. The DC does not have a lot of connectivity options to choose from. So we've ordered dark fiber to Equinix Ashburn DC2, we will light it up with our own DWDM, and pick up connectivity there. We do however need a second point to pick up connectivity for redundancy purposes. (that runway from IAD is pretty scary) Initially we had thought to pick up that connectivity at Coresite K-street. However many of the carriers we use are not available at K-street. What would you guys advise us to go to for lots of connectivity options. Thanks, Bas

2 1

The tale of a single MAC
by Graham Wooden 06 Jan '11

06 Jan '11

Hi there, I encountered an interesting issue today and I found it so bizarre so I thought I would share it. I brought online a spare server to help offload some of the recent VMs that I have been deploying. Around the same time this new machine (we¹ll call it Server-B) came online, another machine which has been online for about a year now stopped responding to our monitoring (and we¹ll name this Server-A). I logged into the switch and saw that the machine that stopped responding was in the same VLAN as this newly deployed, and then quickly noticed that Server-A¹s MAC address was now on Server-B¹s switch port. ³What the ...² was my initial response. I went ahead and moved Server-B¹s to another VLAN, updated the switchport, cleared the ARP, and Server-A came back to life. Happy new year to me. So here is the interesting part... Both servers are HP Proliant DL380 G4s, and both of their NIC1 and NIC2 MACs addresses are exactly the same. Not spoofd and the OS drivers are not mucking with them ... They¹re burned-in I triple checked them in their respective BIOS screen. I acquired these two machines at different times and both were from the grey market. The ³What the ...² is sitting fresh in my mind ... How can this be? In the last 15 years of being in IT, I have never encountered a ³burned-in² duplicated MACs across two physically different machines. What are the odds, that HP would dup¹d them and that both would eventually end up at my shop? Or maybe this type of thing isn¹t big of deal... ? -graham

24 31

New AS Number Blocks allocated to the RIPE NCC
by Ingrid Wijte 06 Jan '11

06 Jan '11

Dear Colleagues, The RIPE NCC received the following AS Number Blocks from the IANA in January 2011. 56320-57343 57344-58367 197632-198655 You may want to update your records accordingly. Best regards, Ingrid Wijte Registration Services Assistant Manager RIPE NCC

1 0

Spamming and ssh attack from a customers
by Tarig Ahmed 06 Jan '11

06 Jan '11

hi all I am receiving emails from many servers saying that: this ip (from a customer) is trying to attacking one of our servers. Is it appropriate to filter ssh, telnet, and smtp from my customers, or just forward the message to my customer contact persons? Thanks in advance.. Tarig Yassin Ahmed

4 3

Qwest access problems
by Wes Bachman 06 Jan '11

06 Jan '11

Anyone seeing problems with Qwest access circuits this evening? Our AT&T GigE circuit with Qwest LEC has bounced twice. Oddly when I went to check it out from home, my Qwest DSL was down at the exact same time, and appeared to come back up at around the same time. I'm in eastern Iowa. I haven't heard anything from Qwest or AT&T so far, and received no notice of any planned maintenance? -Wes Bachman Leepfrog Technologies, Inc.

1 0

Clearwire/Clear for branch office connectivity?
by Brandon Galbraith 06 Jan '11

06 Jan '11

Is anyone using Clearwire/Clear's wireless broadband offering for stationary branch offices/remote equipment monitoring? Looking for results/experiences off-list. We're looking at it for industrial telemetry, and have spoken to people using ATT and VZW who are doing the same, but we wanted to look at Clear as well. Curious as to reliability, link performance, and support quality. Thanks! Brandon -- Brandon Galbraith US Voice: 630.492.0464

8 7

Holiday Songs
by Paul WALL 06 Jan '11

06 Jan '11

An old classic, but maybe it will help put everyone in the holiday spirit. The Twelve Days of NYIIX ------------------------ On the first day of Christmas, NYIIX gave to me, A BPDU from someone's spanning tree. On the second day of Christmas, NYIIX gave to me, Two forwarding loops, And a BPDU from someone's spanning tree. On the third day of Christmas, NYIIX gave to me, Three routing leaks, Two forwarding loops, And a BPDU from someone's spanning tree. On the fourth day of Christmas, NYIIX gave to me, Four Foundry crashes, Three routing leaks, Two forwarding loops, And a BPDU from someone's spanning tree. On the fifth day of Christmas, NYIIX gave to me, Five flapping sessions, Four Foundry crashes, Three routing leaks, Two forwarding loops, And a BPDU from someone's spanning tree. On the sixth day of Christmas, NYIIX gave to me, Six maintenances notices, Five flapping sessions, Four Foundry crashes, Three routing leaks, Two forwarding loops, And a BPDU from someone's spanning tree. On the seventh day of Christmas, NYIIX gave to me, Seven broadcast floods, Six maintenances notices, Five flapping sessions, Four Foundry crashes, Three routing leaks, Two forwarding loops, And a BPDU from someone's spanning tree. On the eighth day of Christmas, NYIIX gave to me, Eight defaulting peers, Seven broadcast floods, Six maintenances notices, Five flapping sessions, Four Foundry crashes, Three routing leaks, Two forwarding loops, And a BPDU from someone's spanning tree. On the ninth day of Christmas, NYIIX gave to me, Nine CDP neighbors, Eight defaulting peers, Seven broadcast floods, Six maintenances notices, Five flapping sessions, Four Foundry crashes, Three routing leaks, Two forwarding loops, And a BPDU from someone's spanning tree. On the tenth day of Christmas, NYIIX gave to me, Ten proxy ARPs, Nine CDP neighbors, Eight defaulting peers, Seven broadcast floods, Six maintenances notices, Five flapping sessions, Four Foundry crashes, Three routing leaks, Two forwarding loops, And a BPDU from someone's spanning tree. On the eleventh day of Christmas, NYIIX gave to me, Eleven OSPF hellos, Ten proxy ARPs, Nine CDP neighbors, Eight defaulting peers, Seven broadcast floods, Six maintenances notices, Five flapping sessions, Four Foundry crashes, Three routing leaks, Two forwarding loops, And a BPDU from someone's spanning tree. On the twelfth day of Christmas, NYIIX gave to me, Twelve peers in half-duplex, Eleven OSPF hellos, Ten proxy ARPs, Nine CDP neighbors, Eight defaulting peers, Seven broadcast floods, Six maintenances notices, Five flapping sessions, Four Foundry crashes, Three routing leaks, Two forwarding loops, And a BPDU from someone's spanning tree.

4 4