- Test - lists.nanog.org

F.ROOT-SERVERS.NET IPv6 address has changed.
by Mark Andrews 05 Feb '08

05 Feb '08

With the official deployment of IPv6 addresses for the root servers, F.ROOT-SERVERS.NET IPv6 address changed. The old address, 2001:500::1035, is no longer valid and will be turn off at some point. The new address is 2001:500:2f::f. This will only affect users that have deliberately overridden the responses returned by the root servers. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews(a)isc.org

1 0

Fourth cable damaged in Middle Eest (Qatar to UAE)
by Sean Donelan 05 Feb '08

05 Feb '08

A fourth submarine cable in the middle east was damaged Sunday between Haloul, Qatar and Das, United Arab Emirates. This is in addition to the damage affecting FLAG, SAE-ME-WE4, FALCON cables. Afer reviewing surveillance video of the area, Egypt's ministry of maritime transportation is reporting no ships were near the FLAG or SAE-ME-WE4 cables 12-hours before or after the cable damage near Alexanderia, Egypt. The reason for outage of the cables has not been identified yet.

19 23

Re: Fourth cable damaged in Middle Eest (Qatar to UAE)
by Frank Coluccio 04 Feb '08

04 Feb '08

This will be my only post on this subject after biting my tongue for several days:) Some members will appreciate this item I came across earlier, I'm sure. As always, caveat emptor. Where is the USS Jimmy Carter? By Dave | February 3, 2008 http://tinyurl.com/3y7zgu List members -- and lurking students, in particular, should NOT take much of what's been posted _on _this _topic _ too seriously or regard everything written as factual. This cautionary note applies equally to the article I've posted above, as well. 73s,

5 5

Aggregation for IPv4-compatible IPv6 address space
by snort bsd 04 Feb '08

04 Feb '08

Hi all: With IPv4-compatible IPv6 address space, could I aggregate the address space? say 192.168.0.0/16 become ::192.168/112? or It must be converted to native IPv6 address space? Just wondering, Get the name you always wanted with the new y7mail email address. www.yahoo7.com.au/y7mail

4 3

Jeanette Symons (1962-2008) a commerical Internet Pioneer
by John Lee 04 Feb '08

04 Feb '08

It was with great sadness that I read about the un-timely death of my friend and colleague Jeanette in a plane crash in Maine. Jeanette died flying, which was one of the activities she loved to do. I meet her before she started flying and when she moved back to California she took up flying. We would be talking on the phone and she would say that it was VFR and she needed to go. VFR - Visual Flight Rules for flying without instruments which was all she was rated for at the time. I meet Jeanette at Hayes Microcomputer Products where we were working on a project together. People would think that we were brother and sister since we both had curly back hair and looked alike. When she wanted to move back to California, which she missed, I introduced her to Rob Ryan the head of Haye's West coast operations. When she was in Georgia we would eat Chinese, made by my wife, at my place. When we were in California we would eat Sushi at several of her favorite places in Western San Francisco and Oakland. Jeanette, Rob, Jay Duncanson and Steve Speckenbach left Hayes to start Ascend Communications and developed the TNT central site dial up modem, ISDN and Ethernet switch that handled most of the dial up Internet traffic for years. Ascend was purchased by Lucent and she and Mori started Zhone Technologies. Her new venture was started because her children wanted to blog with their friends and she was worried about them being on line. Jeanette will be missed. John Lee

3 2

Blackholes and IXs and Completing the Attack.
by Ben Butler 04 Feb '08

04 Feb '08

Hi, I have been working away on remote trigger blackholing and community based client initiated blackholing into transit ASes. It got me thinking that while this works great with a handful of upstream transit peers it does not really scale very well at an Internet Exchange with a high overhead configuring things for many peers. Plus if your IX connection is saturated that means legitimate traffic must be getting degraded - even if your router is coping and blackholing the interconnect is still flat lined. The only ways into an AS are via transit, public IX or private interconnects. If we want to extend the blackholing to secure IXs peers as well as into transits. So my idea.... Is to have an IX route reflector configured with ACLs locking it down to exclusively BGP with the IX peer IP of the member. The IX route reflector would be configured to have per peer prefix filters per peer auto generated from registered AS macro for each peer from the RIPE,ARIN,APNIC etc databases. This should mean the router will not accept announcements for any /32 that is not part of the routes announced by that AS (it would be even better to tie it down to a match on origin AS as well). Plus the router will only talk to IX peers - no global transit. This hopefully will ensure a relatively protected router that is only accessible from the edge routers we want and also secured to only accept filtered announcements for black holing and in consequence enable the system to be trusted similar to Team Cymaru. Then all a member AS of the exchange does is announce any /32 from their IP block that they would like other members to Null route in their AS to this reflector. There are people way smarter than me on this list and the above is not implemented at any of the IXs I am connected to, so why is the above a dumb idea / what have I missed that makes the above unworkable because it does seem kind of obvious now I have done some work with this. Kind Regards Ben Butler ++++++++++++++++++++++++++++++++++++++++++ C2 Internet Ltd Globe House, The Gullet, Nantwich, Cheshire, CW5 5RL E mailto:ben.butler@c2internet.net W http://www.c2internet.net/ B1 http://c2internet.blogspot.com/ B2 http://c2noc.blogspot.com/ T +44-(0)845-658-0020 F +44-(0)845-658-0070 All quotes & services from C2 are bound by our standard terms and conditions which are available on our website at: http://www.c2internet.net/legal/main.htm#tandc C2 Internet Limited is a company registered in England and Wales with company number 03910154 Our VAT Registration number is GB 752 7650 17

10 22

Re: Blackholes and IXs and Completing the Attack.
by Rick Astley 03 Feb '08

03 Feb '08

I see your point, but I think maintaining the box for the control session would also require a decent amount of work. Presumably, since you must all adhere to some quasi-standard to communicate with the control peer, you could probably also agree on creating a standard BGP community (ie. 64666:666 & no-export) to use and just skip the middle man. Granted, I am kind of new as well, and I assume if the solution were that simple more people would be using it. On Feb 2, 2008 9:07 PM, Ben Butler <ben.butler(a)c2internet.net> wrote: > Hi, > > Agreed, but when you have >100 peers that is still a fair bit of work. I > know technically how to do it and am doing this with transits but then there > are only seven of those. It is not a question of how or can, but should / > is it valuable / constructive? > > The starting point in the thought process having just done it for transits > was right ok, now how do we sensibly scale this to apply it at IXes without > everyone having to run round contacting everyone else and to see if there > was an easier way of doing things, hence the suggestion. Plus it keeps > things nice a separated, your IX peering sessions announce just the main > prefixes, the session to the "blackhole reflector" can be in a separate > peer-group and you only send the /32s to the reflector. You don't have to > worry about who uses which communities as each member that chooses to peer > with the reflector is able to apply an inbound routemaps of their own > choosing to any prefixes they receive from this reflector at each individual > IX. > > Given that an ISP has elected to Complete the attack on a host that is > being DoSed, for whatever reason, and they have chosen to send blackhole > announcements to transit the logical extension seems to be to automate the > sending of them to IXs to try to further cut down on traffic. This seems > like a easy way, internally you just community tag on the trigger box for > where you want the announcement to go, transit, internal, customers, IX > all,1 2 not 3 - whatever - and BGP sends it out. Easy, and a single system > to send out all updates when you choose to and easy to remove when you want > to take it out again. > > If you subscribe to completing the attack as a strategy, then the > suggestion seemed like an easy way of rolling it out to the next logical > point after transit. > > Kind Regards > > Ben > >

2 1

adsl line tester
by Ingo Flaschberger 03 Feb '08

03 Feb '08

Hi, I'm searching a good adsl2+ line tester. Can anynone recommend a good one? Kind regards, ingo flaschberger

3 2

IPv6 Connectivity Saga (part n+1)
by Thomas Kühne 03 Feb '08

03 Feb '08

I took a DMOZ[1] dump, extracted all unique domain-name port combinations and checked their IPv6 connectivity. 3 388 012 : 100.000% : total 3 260 296 : 96.230% : IPv4 only 122 560 : 3.620% : bad NS 3 372 : 0.100% : IPv6 working 1 694 : 0.050% : broken or "fake" IPv6 broken: TCP connect failed fake: IPv6 mapped IPv4 addresses (e.g. ::ffff:1.2.3.4) 33.4% of all services that advertised IPv6 failed to deliver or in other words the IPv6 failure rate is ten times the NS failure rate. Seems high, thus a cross check via TLDs' NS: 270 : 100.0% : TLD total (excluding the IDN tests) 268 : 99.3% : IPv4 working 2 : 0.7% : IPv4 broken (HM and KP) 177 : 65.6% : IPv6 working 8 : 3.0% : IPv6 broken 1910 : 100.0% : NS total 1500 : 78.5% : IPv4 only 31 : 1.6% : IPv4 broken 356 : 19.1% : IPv6 working 23 : 1.2% : IPv6 broken IPv6 failure rates of 4.3% (TLD) and 6.1% (NS) is lower than the above 33.4% but are still significantly higher than the IPv4 failure rates of 0.7% (TLD) and 1.6% (NS). TLD root-NSs usually are managed by dedicated infrastructure organisations thus better trouble shooting than the DMOZ listed ones get is expected and suggests the above 33.4% failure rate isn't some kind of sampling artifact. About 4 days later I did a more detailed check of the hosts with broken IPv6: 1624 : hosts total 827 : connection timed out 382 : no route to host 249 : connection refused 95 : network unreachable 54 : SixXS never received a route announcement for that block 43 : broadcast address 30 : * IPv4 in IPv6 22 : IPv6 assignments reclaimed (3ffe::/16) 16 : * no IPv6 (::) 12 : * IPv4 only 10 : * IPv6 working 4 : IPv6 never assigned 4 : local (fe80::/10) 2 : local (::1) 2 : broken NS Issues(cases not marked with a star) do tend to arise but why are fundamental issues like "connection timed out", "no route to host" and "connection refused" so frequent? (testing was done from 2a01:4d0:102::31) Thomas [1] http://www.dmoz.org/help/getdata.html

4 4

Re: Blackholes and IXs and Completing the Attack.
by Paul Ferguson 03 Feb '08

03 Feb '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- Roland Dobbins <rdobbins(a)cisco.com> wrote: >On Feb 3, 2008, at 4:50 AM, Paul Ferguson wrote: > >> We (Trend Micro) do something similar to this -- a black-hole BGP >> feed of known botnet C&Cs, such that the C&C channel is effectively >> black-holed. > >What's the trigger (pardon the pun, heh) and process for removing IPs from the blackhole list post-cleanup, in Trend's case? > We have a team that does the vetting/validation and when the C&Cs are taken down (or "decommissioned") they are removed from the feed. >Is there a notification mechanism so that folks who may not subscribe to Trend's service but who are unwittingly hosting a botnet C&C are made aware of same? > Well, we try to notify the owners of the identified hosts, but it is not always successful... and sometimes the sheer churn is prohibitive. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFHpTu1q1pz9mNUZTMRAu+CAJ94j6AgqZgrMQ6b8HoPLyy4zBRcNgCfejWn dAE2T+i2MtvpAJ2PNJmdTpc= =N+iF -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/

1 0