December 2011 - NANOG - lists.nanog.org

Recent DNS attacks from China?
by Leland Vandervort 02 Dec '11

02 Dec '11

Hi All, I am wondering if anyone else is seeing a sudden increase in DNS attacks emanating from chinese IP addresses? Over the past 24 hours we've seen a sudden rash of chinese IPs attacking our DNS servers in the order of 5 to 10 million PPS for periods of 5 to 10 mins, repeated every 20 to 30 minutes. This anomalous traffic started roughly 24 hours ago, and while we've had occasions of anomalous chinese traffic, never anything of this type. Anyone else? Regards, Leland

11 13

IPv6 prefixes longer then /64: are they possible in DOCSIS networks?
by Dmitry Cherkasov 02 Dec '11

02 Dec '11

Hello everybody, It is commonly agreed that /64 is maximal length for LANs because if we use longer prefix we introduce conflict with stateless address autoconfiguration (SLAAC) based on EUI-64 spec. But SLAAC is not used in DOCSIS networks. So there seems to be no objections to use smaller networks per cable interfaces of CMTS. I was not able to find any recommendations anywhere including Cable Labs specs for using prefixes not greater then /64 in DOCSIS networks. Some tech from ISP assumed that DHCPv6 server may generate interface ID part of IPv6 address similarly to EUI-64 so MAC address of the device can easily be obtained from its IPv6 address, but this does not seem like convincing argument. What do you think? Dmitry Cherkasov

24 69

APRICOT-2012: Call for Papers
by Mark Tinka 02 Dec '11

02 Dec '11

Asia Pacific Regional Internet Conference on Operational Technologies (APRICOT) 21 February - 2 March 2012, New Delhi, India http://www.apricot2012.net CALL FOR PAPERS =============== The APRICOT 2012 Programme Committee is now seeking contributions for Presentations and Tutorials for APRICOT 2012. We are looking for people and proposals that would: - Offer a technical tutorial on an appropriate topic; and/or - Participate in the technical conference sessions as a speaker; and/or - Convene and chair a Birds of a Feather (BOF) session. Please submit proposals on-line at: http://submission.apnic.net/ CONFERENCE MILESTONES --------------------- Call for Papers Opens: 22 November 2011 First Draft Program Published: 19 December 2011 Final Deadline for Submissions: 10 February 2012 Final Program Published: 17 February 2012 Final Slides Received: 25 February 2012 PROGRAM MATERIAL ---------------- The APRICOT Programme is organised in three parts, including workshops, tutorials and the conference. The APNIC Policy SIG and Annual Members Meeting will be held during the APRICOT conference. Topics for tutorials and conference would include amongst others relevant to Internet Operations and Technologies: - IPv4 / IPv6 Routing and operations - IPv4 address runout / IPv6 deployment and transition technologies - Backbone operations - ISP and Carrier services - Network security issues (NSP-SEC, DDoS Anti-Spam, Anti-Malware) - Peering / IXPs - DNS / DNSSEC - Internet policy (Security, Regulation, Content Management, Addressing, etc) - Access and Transport Technologies, including broadband deployment, Cable/DSL, wireless, WiMax, metro ethernet, fiber network, MPLS - Content & Service Delivery (Multicast, Voice, Video, "telepresence", Gaming) CfP SUBMISSION -------------- All draft and complete slides must be submitted in PDF format only. Draft slides for both tutorials and conference sessions MUST be provided with CfP submissions otherwise the Programme Committee will be unable to review the submission. For work in progress, the most current information available at time of submission is acceptable. Final slides are to be provided by the specified deadline for publication on the APRICOT website. While the majority of speaking slots will be filled by the first submission deadline, a limited number of slots may be available up to the final submission deadline for presentations that are exceptionally timely, important, or of critical operational importance. Please submit on-line at: http://submission.apnic.net/ Any questions or concerns should be addressed to the Programme Committee by e-mail at: pc-chairs at apricot.net We look forward to receiving your presentation proposals. Mark Tinka & Jonny Martin Co-Chairs, APRICOT Programme Committee program(a)apricot.net

1 0

bgp update destroying transit on redback routers ?
by Igor Ybema 02 Dec '11

02 Dec '11

Hi there, Since about 15:00u GMT we receive bgp updates from our transit which destroys the bgp sessions with them with message: send NOTIFICATION: 3/9 (update: optional attribute error) with 11 byte data. mxReadMs=610 We use redback smartedge routers (SE100) currently for BGP. Anyone who have seen this also? regards, Igor

7 11

Link local for P-t-P links? (Was: IPv6 prefixes longer then /64: are they possible in DOCSIS networks?)
by Mike Jones 02 Dec '11

02 Dec '11

On 1 December 2011 00:55, Jimmy Hess <mysidia(a)gmail.com> wrote: > Please explain. What are the better ways that you would propose > of mitigating ND table overflows? > If you can show a rational alternative, then it would be persuasive as > a better option. > Link-Local? For "true" P-t-P links I guess you don't need any addresses on the interfaces (I don't on my 6in4 tunnels), but I assume most people are referring to ethernet type cross connects, so Link-Local addresses. As long as each device has at least 1 address assigned somewhere (loopback?) that it can use for management/packet generation purposes you don't need an address on every link like you used to do with IPv4. Now that there are plenty of addresses you don't need as many :) I suspect there are probably some practical issues with link-local on some kit and some network configurations due to lack of people doing it this way, but in theory there shouldn't be any reason that you couldn't use link-local for all your links then just have a /128 assigned to each routers loopback for management/packet generation purposes. This could remove overheads of worrying about address assignment for those links, you just need a single /128 per router. Depending on the network it might be better to statically set link locals rather than using automatic ones (fe80::1 and fe80::2 for 'upstream' and 'downstream' or whatever rules you currently use for deciding which end is 1 and which is 2) You could also do something similar for datacentres assigning blocks to customer servers, instead of configuring a /64 for each customer, or a /48 then giving customers blocks inside that to use, just configure a single /64 and give each customer a single address from that block with unassigned ones filtered, then route a /64 to them for any "extra addresses" they might want. Chances are if they need more than a couple of addresses they probably want them routed to them anyway rather than using ND for them all. The issue of dynamic assignments to end customers in a non-datacentre setting is a little more difficult, but I wonder how badly CPEs would break if you tried using DHCPv6 to give them back their link-local addresses, then DHCPv6-PD delegating by routing to their link local address, probably a lot worse than if you just used a /112 of global space. I don't think this area has too many issues though because DHCP ensures that the actual addresses on the links are all known, so this just needs to be used for filtering unknown addresses. Then there's just the question of what to do about the edge networks where SLAAC might be used and where you don't have such strict control over address assignment, i'll pass on that one for now. Link locals aren't as useful nearer to the edges, but for the backbones and datacentre networks they should be able to solve most of the biggest problems with ND attacks. The edge networks where just using link locals isn't really an option you can probably put a stateful firewall in quite easily, as these will be the edge default gateways that clients are sending their traffic directly to rather than needing to be done in the core. Although there really should be an option for users to open the firewall for inbound connections. Am I a complete idiot missing some obvious major issues with link locals, or am i just the only one not thinking IPv4-think? Opinions? :) - Mike

6 7

[NANOG-announce] NANOG54 (San Diego, Feb 5-8, 2012): Early Bird Registration Expiring on Sunday, 12/4
by Dave Temkin 01 Dec '11

01 Dec '11

Please note that the Early Bird registration for NANOG54 expires on Sunday, 12/4. Register now and save $75 off the regular registration fee! Also, as a reminder, the Call for Presentations is still open! Have something that you think is relevant to the NANOG community and would like to have the chance to present it? Please see http://www.nanog.org/meetings/nanog54/callforpresentations.html for more information. Looking forward to seeing you in sunny San Diego! -Dave (For the NANOG Program Committee) _______________________________________________ NANOG-announce mailing list NANOG-announce(a)nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce

1 0

MPLS based routing
by Meftah Tayeb 01 Dec '11

01 Dec '11

hello guys, if i want to label my routes in a cisco router i did run through ldp configuration step now i see that labels are distributed, but if i traceroute it from another router i didn't see the icmp arg for the mpls label did i miss anything? atached my configuration :) Meftah Tayeb IT Consulting http://www.tmvoip.com/ phone: +21321656139 Mobile: +213660347746 __________ Information from ESET NOD32 Antivirus, version of virus signature database 6678 (20111202) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com

1 0

Re: bgp update destroying transit on redback routers ?
by Olivier Benghozi 01 Dec '11

01 Dec '11

Alexandre Snarskii <snar(a)snar.spb.ru> wrote: > AGGREGATOR is an optional transitive attribute of length 6. > The attribute contains the last AS number that formed the > aggregate route (encoded as 2 octets), followed by the IP > address of the BGP speaker that formed the aggregate route > (encoded as 4 octets). Usage of this attribute is described > in 5.1.7 > > And what to do with 4-byte AS-numbers then? That would explain the 8 bytes. Hi, we also have some issues with this here, the update message the Redback logged is: ffff ffff ffff ffff ffff ffff ffff ffff 0049 02 0000 002e 4001 01 00 4002 12 02 04 00000513 00000d1c 0000b611 0000b611 4003 04 50ef82c1 4006 00 c007 08 00 0000 0000 0000 00 16 ce7d a4 The prefix is 206.125.164.0/22, AS-PATH is 1299 3356 46609 46609 (Telia, Level3, and finally Hostlogistic with one prepend). The AGGREGATOR is full of 0. I guess this could be what bothers the Redback/Ericsson code. I see the same route by other sessions, and the aggregator looks OK, since the sh bgp says: 206.125.164.0/22 [...] 8218 4436 46609 46609 [...] Origin incomplete, localpref 100, med 100, weight 100, external, best aggregator: 206.125.165.242, AS 46609, atomic-aggregate So Hostlogistic route to Level3 is malformed (according to the RFC, the AGGREGATOR content is mandatory if the attribute is present), but their route to NLayer is OK. Or maybe a Level3 router has a problem? Anyway, our Redback/Ericsson routers are the problem now, since the other vendors don't throw away the BGP sessions... I've opened a case at Ericsson, still waiting for an answer :-/ regards, Olivier Benghozi Wifirst

2 1

Re: HP IPv6 RA Guard
by Ray Soucy 01 Dec '11

01 Dec '11

Comment can be appreciated but please remove the I2 WG address from responses unless it's something you want to blast to that community, I don't want them upset at me for filling their inbox with a 40 email NANOG thread (you know how this list can get). ;-) On Wed, Nov 30, 2011 at 9:52 PM, Brent Jones <brent(a)brentrjones.com> wrote: > > > On Wed, Nov 30, 2011 at 5:53 PM, Ray Soucy <rps(a)maine.edu> wrote: >> >> This is great news. >> >> I wonder if this is evidence that they plan to continue to develop the >> Procurve line and eventually abandon the 3Com line. Uncertainty of >> which line would win out has kept me (and others I'm sure) from >> wanting to invest in anything HP. >> > > > Some of us have chosen not to invest in anything HP for a long time > > > > -Brent Jones -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/

1 0

Re: HP IPv6 RA Guard
by Ray Soucy 01 Dec '11

01 Dec '11

This is great news. I wonder if this is evidence that they plan to continue to develop the Procurve line and eventually abandon the 3Com line. Uncertainty of which line would win out has kept me (and others I'm sure) from wanting to invest in anything HP. On Wed, Nov 30, 2011 at 8:40 PM, Jason Mueller <jasmuell(a)indiana.edu> wrote: > All, > > I received HP code today that implements RA guard (K.15.07.0002). This is for the 5400, 8200, 3500 series switches. The feature blocks both RAs (ICMP type 134) and IPv6 redirects (ICMP type 137). > > Here is the CLI command syntax: > [no] ipv6 ra-guard ports <port-list> [log] > > This should be included in their next general release of K.15 series code. > > No word on my request for IPv6 DHCP snooping. I generally get an HP drafted version of special feature requests, when they accept them for development. I don't have any record of that, so I sent a gentle reminder to HP tonight. > > -Jason > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/

1 0