- Test - lists.nanog.org

Re: Network Connectivity... Dealing with Providers
by J. Oquendo 17 Nov '06

17 Nov '06

Kuechel, Mark wrote: > Sounds like you are trouble shooting a VoIP issue several networks > removed from the actual user. First step is to get into their network > via telnet and start from there. Is this a jitter issue on some or all > calls? Has the customer done a traffic study on their own LAN to see if > there is not some sort of congestion there? Pings from afar are not used > to trouble shoot issues in depth: Lots of posting on this. Has the > clients Bandwidth utilization been looked at to their provider? Give us > more. > Pings and traceroutes weren't the only tests I've done. Here is my capacity when dealing with this client: When something happens and I need to do some VoIP related stuff (extension changes, etc), I mainly log in via SSH from one of four points, a DSL connection CTTEL, Level3, GBLX, and Verio. When my lab's CTTel DSL connection fails I jump on a DS3 (GBLX), when that fails, I jump on to a machine in Texas and most of the times one of them is going to let me in. Now, I have had failures from two points to all points at sporadic times. So I do the obvious traceroutes, pings, etc.. Now a provider can be quick to tell me "check your line" but come on now... 4 different lines are failing to connect here. (This doesn't include the fact that if I can't get in... What makes you think voice data is getting in?) So, for my testing, I'm doing a functional (its fugly) test from all four locations to my client, and from my client to all four. My data is going to be a collection of ping tests, traceroute test (tcptraceroute), bing test, etc.... I was hoping to get feedback on other tools... I have Radarping as well but don't feel like using it. I want to be able to leave something running 24x7 until Friday. I'd like for it to be opensource so the provider doesn't cry "your network voodoo tools don't count!". I want to be able to go back and say "Listen these tools are industry standard tools from CAIDA (or elsewhere), and they're used by engineers all across the board. I've done a fair test and its obviously coming from your network.." So to answer your bandwidth question, bandwidth (according to the provider) is under 50% capacity with "sporadic spikes" as their engineers have seen while on the phone with them. Sporadic means nothing to me. I have a 63% packet loss which means even if I was equipped with an OC768, the bandwidth means nothing if the packets aren't going through. "Here's your Lamborghini Murcielago Sir. It does 200mph. Although from time to time you'll only do 126mph..." Traffic internally, I've put on QoS maps, but with or without them same errors occur. It's not an issue of echoes, its more of calls to specific DID's dropping, not going through, caller can hear - receiver can't. All the while some lines work, others don't. Couple this with my Nagios test going bonkers - I configured Nagios to monitor from my client to Google, Yahoo, MSN and I can see loss from here to the outside world so it's twofold. Short of my client running me over with his FX45, I'm even running out of patience with my client's provider. -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo echo @infiltrated|sed 's/^/sil/g;s/$/.net/g' http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x1383A743 "How a man plays the game shows something of his character - how he loses shows all" - Mr. Luckey

4 6

ietf-bcp38bis mailing list [Was: RFC2827-bis comments solicitation]
by Fergie 17 Nov '06

17 Nov '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 As a follow-up to my previous message re: "RFC2827-bis comments solicitation", we now have a dedicated mailing list for discussion of bringing BCP38 up-to-date: [snip] ietf-bcp38bis mailing list The ietf-bcp38bis mailing list is for discussing an update to BCP 38, "Network Ingress Filtering". To subscribe to the mailing list, send a message to: ietf-bcp38bis-request(a)vpnc.org ...with the single word 'subscribe' in the body of the message. [snip] The web site for this mailing list is sponsored by the VPN Consortium. If you have any suggestions for additions or corrections to this web page, please send them to paul.hoffman(at)vpnc.org. Many thanks to Paul Hoffman for hosting the list. - - ferg > >First, sorry for any duplicates, but we wanted to reach all >interested parties. > >After several discussions with many different folks last week >at IETF 67 in San Diego, as well as various people over the >course of the past few months, Dan Senie and I have decided to >undertake an effort to "update" RFC2827/BCP38 [1]. > >I know that I'm not the only person who has heard various >discussions in the past couple of years that concluded that >(paraphrased), "BCP38 needs to be updated." > >Now is your chance to speak up. :-) > >We would very much like to solicit comments & suggestions from the >community-at-large on areas where you feel BCP38 is lacking, or in >areas where you feel it does not properly address with regards to >prohibiting source-spoofed traffic from any given administrative >network boundary, given that some technical aspects of the Internet >may have changed since it's publication. > >While we acknowledge that a uniform application of a source address >verification architecture/ingress filtering scheme will not mitigate >_all_ "unwanted traffic" [2] in the Internet, it will most certainly >address the issue of hosts which attempt to source-spoof traffic into >the Internet. > >I have not set up a mailing list for this yet, but if there is >enough discussion/input, I will make an effort to do so (or perhaps >the SAVA mailing list [3] might be a good place for discussion). In >the interim, you can contact me or Dan directly: > > Paul Ferguson: fergdawg(at)netzero.net > Dan Senie: dts(at)senie.com > > >Thanks, > >fergie & dan > >p.s. Also, for anyone who might be interesting in related work, >there is an effort to bring some additional work into the IETF >called SAVA, or Source Address Validation Architecture [4]. > > >[1] http://www.rfc-editor.org/rfc/rfc2827.txt >[2] http://www.iab.org/about/workshops/unwantedtraffic/index.html >[3] http://www.nrc.tsinghua.edu.cn/mailman/listinfo/sava >[4] >http://www.nrc.tsinghua.edu.cn/pipermail/sava/2006-September/000004.html -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.1 (Build 1557) wj8DBQFFXgK9q1pz9mNUZTMRArqOAKDzeVk2VCfD/Ru0OtrgtNLyJ90MqACePChS 2dqaaWAbXonj185jAtwnZ8Q= =jieX -----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

Weekly Routing Table Report
by Routing Analysis Role Account 17 Nov '06

17 Nov '06

This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats(a)lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith <pfs(a)cisco.com>. Routing Table Report 04:00 +10GMT Sat 18 Nov, 2006 Analysis Summary ---------------- BGP routing table entries examined: 203977 Prefixes after maximum aggregation: 110635 Unique aggregates announced to Internet: 99054 Total ASes present in the Internet Routing Table: 23714 Origin-only ASes present in the Internet Routing Table: 20668 Origin ASes announcing only one prefix: 9968 Transit ASes present in the Internet Routing Table: 3046 Transit-only ASes present in the Internet Routing Table: 82 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 29 Max AS path prepend of ASN (36728) 27 Prefixes from unregistered ASNs in the Routing Table: 1 Unregistered ASNs in the Routing Table: 3 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 7 Number of addresses announced to Internet: 1636930476 Equivalent to 97 /8s, 145 /16s and 147 /24s Percentage of available address space announced: 44.2 Percentage of allocated address space announced: 62.7 Percentage of available address space allocated: 70.5 Total number of prefixes smaller than registry allocations: 103463 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 45034 Total APNIC prefixes after maximum aggregation: 18334 Prefixes being announced from the APNIC address blocks: 42613 Unique aggregates announced from the APNIC address blocks: 18655 APNIC Region origin ASes present in the Internet Routing Table: 2761 APNIC Region origin ASes announcing only one prefix: 779 APNIC Region transit ASes present in the Internet Routing Table: 411 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 16 Number of APNIC addresses announced to Internet: 269241056 Equivalent to 16 /8s, 12 /16s and 74 /24s Percentage of available APNIC address space announced: 84.2 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911 APNIC Address Blocks 58/7, 60/7, 121/8, 122/7, 124/7, 126/8, 202/7 210/7, 218/7, 220/7 and 222/8 ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 101463 Total ARIN prefixes after maximum aggregation: 59963 Prefixes being announced from the ARIN address blocks: 74702 Unique aggregates announced from the ARIN address blocks: 28353 ARIN Region origin ASes present in the Internet Routing Table: 11159 ARIN Region origin ASes announcing only one prefix: 4256 ARIN Region transit ASes present in the Internet Routing Table: 1032 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 29 Number of ARIN addresses announced to Internet: 310888832 Equivalent to 18 /8s, 135 /16s and 201 /24s Percentage of available ARIN address space announced: 68.6 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959 ARIN Address Blocks 24/8, 63/8, 64/5, 72/6, 76/8, 96/6, 199/8, 204/6, 208/7 and 216/8 RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 41751 Total RIPE prefixes after maximum aggregation: 27478 Prefixes being announced from the RIPE address blocks: 38656 Unique aggregates announced from the RIPE address blocks: 25768 RIPE Region origin ASes present in the Internet Routing Table: 8794 RIPE Region origin ASes announcing only one prefix: 4639 RIPE Region transit ASes present in the Internet Routing Table: 1412 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 22 Number of RIPE addresses announced to Internet: 276008708 Equivalent to 16 /8s, 115 /16s and 143 /24s Percentage of available RIPE address space announced: 74.8 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-41983 RIPE Address Blocks 62/8, 77/8, 78/7, 80/5, 88/6, 193/8, 194/7, 212/7 and 217/8 LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 13339 Total LACNIC prefixes after maximum aggregation: 3928 Prefixes being announced from the LACNIC address blocks: 11292 Unique aggregates announced from the LACNIC address blocks: 6919 LACNIC Region origin ASes present in the Internet Routing Table: 751 LACNIC Region origin ASes announcing only one prefix: 246 LACNIC Region transit ASes present in the Internet Routing Table: 132 Average LACNIC Region AS path length visible: 4.1 Max LACNIC Region AS path length visible: 17 Number of LACNIC addresses announced to Internet: 34189056 Equivalent to 2 /8s, 9 /16s and 175 /24s Percentage of available LACNIC address space announced: 50.9 LACNIC AS Blocks 26592-26623, 27648-28671, plus ERX transfers LACNIC Address Blocks 189/8, 190/8, 200/7 AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 2389 Total AfriNIC prefixes after maximum aggregation: 932 Prefixes being announced from the AfriNIC address blocks: 1656 Unique aggregates announced from the AfriNIC address blocks: 1052 AfriNIC Region origin ASes present in the Internet Routing Table: 167 AfriNIC Region origin ASes announcing only one prefix: 48 AfriNIC Region transit ASes present in the Internet Routing Table: 27 Average AfriNIC Region AS path length visible: 3.5 Max AfriNIC Region AS path length visible: 14 Number of AfriNIC addresses announced to Internet: 4487168 Equivalent to 0 /8s, 68 /16s and 120 /24s Percentage of available AfriNIC address space announced: 13.4 AfriNIC AS Blocks 36864-37887 & ERX transfers AfriNIC Address Blocks 41/8, 196/8 APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4134 1231 8533 248 CHINANET-BACKBONE 4755 1032 384 67 Videsh Sanchar Nigam Ltd. Aut 9583 935 109 15 Sify Limited 9498 884 212 64 BHARTI BT INTERNET LTD. 23577 772 35 702 KRNIC 4766 743 4945 305 Korea Telecom (KIX) 1221 584 1714 449 Telstra Pty Ltd 17488 552 34 18 Hathway IP Over Cable Interne 7545 547 124 73 TPG Internet Pty Ltd 17676 500 10934 64 Softbank BB Corp. 18101 482 86 21 Reliance Infocom Ltd Internet 9443 443 111 74 Primus Telecommunications 9942 440 82 132 COMindico Australia 4812 439 749 63 China Telecom (Shanghai) 17849 430 36 126 Telecommunications Technology 4802 411 86 151 Wantree Development 17974 369 129 12 PT TELEKOMUNIKASI INDONESIA 17557 368 32 179 Pakistan Telecom 2907 333 1749 310 SINET Japan 4837 320 3553 138 chinanet IDC center beijing n ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 7018 1545 6188 980 AT&T WorldNet Services 2386 1109 570 738 AT&T Data Communications Serv 4323 1038 804 298 Time Warner Telecom 6197 1023 626 496 BellSouth Network Solutions, 18566 977 272 8 Covad Communications 701 948 6706 772 UUNET Technologies, Inc. 174 945 6822 870 Cogent Communications 721 846 21922 302 DLA Systems Automation Center 1239 838 2731 585 Sprint 20115 834 687 413 Charter Communications 11492 806 98 15 Cable One 19262 784 2436 177 Verizon Global Networks 22773 714 1743 41 Cox Communications, Inc. 209 709 3761 553 Qwest 7011 691 213 431 Citizens Utilities 852 592 1084 386 Telus Advanced Communications 19916 567 48 57 OLM LLC 5668 550 161 19 CenturyTel Internet Holdings, 6198 548 526 255 BellSouth Network Solutions, 855 540 250 74 Canadian Research Network RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 702 553 1929 431 UUNET - Commercial IP service 3301 313 1200 296 TeliaNet Sweden 3320 298 4992 246 Deutsche Telekom AG 24863 286 44 27 LINKdotNET AS number 8220 272 472 262 COLT Telecommunications 6746 259 92 236 Dynamic Network Technologies, 680 250 2041 246 DFN-IP service G-WiN 3246 230 459 219 Song Networks 9116 228 134 23 Goldenlines main autonomous s 8708 221 279 208 Romania Data Systems S.A. 3215 219 1964 93 France Telecom Transpac 1257 218 1073 172 SWIPnet Swedish IP Network 8551 215 198 30 Bezeq International 3269 208 2357 75 TELECOM ITALIA 30890 194 17 83 SC Kappa Invexim SRL 5416 188 13 13 BATELCO-BH 3300 176 171 95 AUCS Communications Services 6830 173 695 38 UPC Distribution Services 786 171 1779 171 The JANET IP Service 3352 168 1703 31 Ibernet, Internet Access Netw LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 759 1921 208 UniNet S.A. de C.V. 11830 484 299 19 Instituto Costarricense de El 11172 400 101 89 Servicios Alestra S.A de C.V 16814 329 20 8 NSS, S.A. 22047 307 206 11 VTR PUNTO NET S.A. 6471 266 74 30 ENTEL CHILE S.A. 14117 254 16 13 Telefonica del Sur S.A. 6147 223 150 23 Telefonica Del Peru 7303 214 96 38 Telecom Argentina Stet-France 6503 209 170 94 AVANTEL, S.A. 11556 195 96 4 Cable-Wireless Panama 10481 181 72 8 Prima S.A. 21826 151 20 34 INTERCABLE 23216 143 19 43 RAMtelecom Telecomunicaciones 19169 139 9 22 Telconet 19429 135 84 34 E.T.B. 14522 130 20 13 SatNet S.A. 18822 129 8 10 TELEFONICA MANQUEHUE 7910 127 9 35 ANDINET ON LINE 7738 116 442 21 Telecomunicacoes da Bahia S.A AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 3741 293 804 233 The Internet Solution 8452 186 60 9 TEDATA 15475 153 84 4 Nile Online 6713 145 139 12 Itissalat Al-MAGHRIB 2018 133 297 111 Tertiary Education Network 5536 122 8 17 Internet Egypt Network 24835 116 48 6 RAYA Telecom - Egypt 33783 110 6 4 EEPAD TISP TELECOM & INTERNET 2905 78 173 71 The Internetworking Company o 2561 56 6 2 Egyptian Universities Network 15706 56 12 4 Sudatel Internet Exchange Aut 12455 40 6 3 Jambonet Autonomous system 5713 36 293 32 Telkom SA Ltd 33774 34 8 21 AS Number for Telecom Algeria 16637 33 21 25 Johnnic e-Ventures 8524 31 2 5 AUCEGYPT Autonomous System 23889 30 9 12 MAURITIUS TELECOM 21280 26 4 4 Swift Global Kenya Ltd.Is an 10798 23 1 14 Standard Bank of South Africa 33766 21 2 1 Nyala Communications Pty Ltd Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4134 1231 983 CHINANET-BACKBONE 18566 977 969 Covad Communications 4755 1032 965 Videsh Sanchar Nigam Ltd. Aut 9583 935 920 Sify Limited 9498 884 820 BHARTI BT INTERNET LTD. 11492 806 791 Cable One 4323 1038 740 Time Warner Telecom 22773 714 673 Cox Communications, Inc. 19262 784 607 Verizon Global Networks 8151 759 551 UniNet S.A. de C.V. 721 846 544 DLA Systems Automation Center 17488 552 534 Hathway IP Over Cable Interne 5668 550 531 CenturyTel Internet Holdings, 6197 1023 527 BellSouth Network Solutions, 19916 567 510 OLM LLC 7545 547 474 TPG Internet Pty Ltd 855 540 466 Canadian Research Network 11830 484 465 Instituto Costarricense de El 18101 482 461 Reliance Infocom Ltd Internet 15270 485 451 PaeTec.net -a division of Pae List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 24409 UNALLOCATED 203.119.29.0/24 9808 Guangdong Mobile Com Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 198.18.0.0/15 8895 KACST/ISU Riyadh Autonomous S Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 132.0.0.0/10 721 DLA Systems Automation Center 137.0.0.0/13 721 DLA Systems Automation Center 158.0.0.0/13 721 DLA Systems Automation Center 192.44.0.0/24 5501 Fraunhofer Gesellschaft 192.44.0.0/19 702 UUNET - Commercial IP service 192.70.164.0/24 25689 National Research Council of 192.172.0.0/19 721 DLA Systems Automation Center Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:19 /9:10 /10:13 /11:30 /12:110 /13:220 /14:398 /15:795 /16:9058 /17:3599 /18:5810 /19:12653 /20:14225 /21:12745 /22:16148 /23:17608 /24:108822 /25:661 /26:476 /27:359 /28:67 /29:41 /30:80 /31:0 /32:30 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 18566 960 977 Covad Communications 2386 827 1109 AT&T Data Communications Serv 7018 822 1545 AT&T WorldNet Services 6197 802 1023 BellSouth Network Solutions, 11492 792 806 Cable One 9583 766 935 Sify Limited 23577 758 772 KRNIC 7011 596 691 Citizens Utilities 19916 562 567 OLM LLC 4766 554 743 Korea Telecom (KIX) 9498 535 884 BHARTI BT INTERNET LTD. 4755 462 1032 Videsh Sanchar Nigam Ltd. Aut 15270 455 485 PaeTec.net -a division of Pae 855 436 540 Canadian Research Network 5668 426 550 CenturyTel Internet Holdings, 1239 420 838 Sprint 17849 416 430 Telecommunications Technology 18101 415 482 Reliance Infocom Ltd Internet 6198 388 548 BellSouth Network Solutions, 33588 387 408 Bresnan Communications, LLC. Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:9 8:61 9:1 12:1639 13:1 15:15 16:3 17:3 18:4 20:39 24:850 25:1 32:56 38:265 40:57 41:23 44:2 47:8 52:4 53:1 55:1 56:3 57:26 58:263 59:319 60:221 61:946 62:1060 63:1880 64:3164 65:2285 66:3050 67:658 68:657 69:1700 70:403 71:114 72:996 74:112 75:42 76:14 80:830 81:749 82:641 83:385 84:457 85:759 86:418 87:419 88:244 89:619 91:75 121:67 122:27 123:3 124:440 125:708 128:290 129:206 130:125 131:315 132:35 133:9 134:177 135:42 136:179 137:113 138:186 139:49 140:525 141:134 142:347 143:192 144:246 145:67 146:324 147:138 148:367 149:175 150:115 151:118 152:83 153:121 154:5 155:261 156:147 157:161 158:152 159:173 160:98 161:88 162:215 163:154 164:237 165:235 166:243 167:270 168:488 169:124 170:389 171:11 190:287 192:5745 193:3579 194:2779 195:2138 196:878 198:3779 199:3292 200:4576 201:954 202:6948 203:7152 204:3934 205:2089 206:2416 207:2896 208:2326 209:3556 210:2166 211:873 212:1372 213:1448 214:382 215:39 216:4130 217:1164 218:341 219:257 220:794 221:356 222:250 End of report Report Website: http://thyme.apnic.net

1 0

ARIN Lawsuit - Comments anyone?
by Chris Jester 17 Nov '06

17 Nov '06

Im wondering how people feel about the response by Mr Ryan, ARIN's legal arsenal. I was forwarded this and would love to know how the networks out there feel about it. Is a long read, but certainly a worthwile one considering the outcome of the case may change IP's as we know them today. I am leaning toward ARINS point of view on the matter, however there are always changes I would hope they make to the way they do things. At the same time, I do believe there has to be an ARIN keeping things in order for the rest of us. So my vote is 60% with RYAN and ARIN. Yours? Vote please in the court of public opinion. --snip-- MR. RYAN: So why is your lawyer talking to you? Let me tell you that there's been a development that we wanted to share with you. As we were leaving Montreal at the last meeting, on the evening that we were flying home, ARIN was sued in California, and we wanted to share some of the information about that with you. This has been the first time literally that we could do so in a meeting capacity; and so as part of our open and transparent processes, we thought we'd let you know that we had been sued in a major way. And let me talk briefly about what has occurred and what we're doing about that. The story is actually a little bit convoluted. It begins in 1998. There was a man named Richard Kremen who is a cyber squatter who had squatted on a name called Sex.com, among other things that he owned. His Sex.com domain name was stolen according to him by a man named Cohen. Mr. Cohen hijacked that and disappeared to Israel and other places in the world, and a lawsuit between these two gentlemen ensued. Mr. Kremen was the person aggrieved. In 2001, unknown to ARIN and without any notice to us, on a day in the course of this lawsuit, the United States District Court in San Jose issued an order, ordering ARIN to turn over certain IP resources that Cohen or people that Mr. Kremen and the court believed were associated with Cohen had obtained from ARIN. No one has ever said that ARIN acted improperly in issuing resources, but what they were, in essence, saying in the court order is that Cohen used money that had been Kremen's to obtain the resources, and in lieu of the money, we were to transfer the resources to Mr. Kremen. So if you've got that, Cohen is the bad guy, according to the court. The court issues an order without ARIN being there. A court order tells you to do something. Well, in 2003, in December of 2003, I had been General Counsel for you about 30 days at that point. We received the order approximately two years after it had been issued. It was provided to us in a formal way, and Mr. Kremen asked us to obey the order. That is, to revoke the IP resources that were held by Mr. Cohen and transfer them to Mr. Kremen. We agreed to do so, so long as Mr. Kremen would do what all of you have done since ARIN began in 1998, which is apply for the resources and sign the normal RSA. Mr. Kremen refused to do that and has refused to the current date. His theory is that he doesn't have to do that because he has a court order, and our theory is that we have a certain set of rules and requirements, and that you have to obey the rules and requirements of the community, and we don't read the court order as giving Mr. Kremen a permanent pass from the rules that all of you obey. We've tried to be very cordial with Mr. Kremen. We believe that Mr. Kremen may have been badly treated by Mr. Cohen, but he certainly has never been badly treated by us. During the time that we've been negotiating with him, we agreed to what was called a standstill order, that there would be no court activity while we negotiated. We turned over thousands of pages of documents within ARIN's control to help him find assets that Mr. Cohen might have had. We revoked resources that were held by Mr. Cohen or his associates that were covered by the 2001 order when they were not paid for. In other words, by our own processes, we were very aggressively trying to recover these resources so that they weren't out there. On the other hand, we ultimately could not reach a conclusion with Mr. Cohen -- pardon me -- with Mr. Kremen because he refused to sign the paperwork even if we filled it out for him. What happened in 2006 is that Mr. Cohen was arrested and extradited to the United States, and we had hoped that by that extradition, that this matter -- that the tension over the matter would go away. We were wrong about that. In April, ARIN was sued by Mr. Kremen, and Mr. Kremen's fundamental issues are not just that we didn't turn over the resources to him. His theory is that this room is an unnecessary and -- unnecessary place to be. He's never been to this room to talk about policy, but his argument is that IP resources are actually property. They're like domain names. They're like a Ford LTD. They're like this computer screen that's sitting next to me. They are a piece of property that can be owned. And, of course, that's not consistent with the entire theory by which the internet community governs IP resources. Fundamentally, he wants to create a market and argue that if you hold IP resources, you are the owner of property, just like a Ford LTD, rather than that those IP resources belong to the internet community, that they are issued by an RIR, like ARIN, to you, but that they can be revoked if you use them improperly or if you don't pay for them, and then they can be reissued to another person who is in need of them. So he's fundamentally attacking the process that we have in his lawsuit. He's claiming that we are an anti-competitive conspiracy that offends Federal Antitrust Law and that offends California Fair Trade Act, and so we are involved in a major piece of litigation with him. The status of that litigation is as follows: He filed a complaint against us in April. ARIN has aggressively responded to this. Where we had been cordial and respectful for the past three years in negotiating and seeking a solution, now that we've been attacked, and we believe improperly, we are defending that lawsuit vigorously, and that was a decision that the Board made. With regard to that defense, we have two issues that we have raised. First, we've gone back to the court and said that the court in its 2001 order ought to consider modifying the order to make it clear that Mr. Kremen, like everyone else, has to sign an RSA and has to pay for the resources in the future. Second, we filed a motion to dismiss his lawsuit. Now, a motion to dismiss a lawsuit is a motion that is disfavored in law. The way that the court is required to look at a motion to dismiss a lawsuit it has to presume, the judge has to presume, that everything that the plaintiff said is true. Even if, for example, it's not. So, for example, Mr. Kremen has claimed that IP resources are property, the court has to accept it as true simply because he said it. Notwithstanding that, we filed a motion to dismiss, and we are awaiting oral argument. I will be arguing this case on October 23rd, a week from Monday, in United States District Court in San Jose. And for those of you -- there's no reason why you would know me, but I've been an Assistant U.S. attorney. I grew up in courthouses. This is what I do. And so I'm going to argue the case myself. I happen to be a litigator, and I'll be arguing that with a team of lawyers. It's a very complex case. I would say that the pleadings in this case now would be about this high. We've spent hundreds of thousands of dollars responding to this over time and dealing with Mr. Kremen. So those two aspects, the change in the 2001 order and the motion to dismiss, will both be argued on the same day. So I really want to say a couple of things from the heart to you. One is that Mr. Kremen is a legacy address holder. He has legacy address blocks. He understands the game of IP resources very well. He's never participated, to our knowledge, in this process of coming here and saying that anything about the ARIN community is proper or improper or arguing that we should have a different policy process. In effect, his lawsuit invites the United States court to substitute a legal process for what you do. Second, right now, you know, Mr. Kremen is a man who has very, very significant resources. He has investigators. He has a team of lawyers that, frankly, are very talented. You know, you can get very good lawyers if you have money, and we are involved in very serious litigation. So what I'd like to do is to suggest that I'm here now to answer your questions. I'll be glad to answer them on the record in the room. I'm glad to have you catch me in the corridor, but I need you to understand that we are under legal attack, and just the very fact that we would do this in an open forum, I think, talks about the values that we have in this room that we try and deal with one another as adults, we try and work out the issues of the future of policy in this room. This is a fundamental attack on the policy process. That's -- you know, you should not misunderstand what this is about. It's fundamentally asking that the current rules that we've developed for the community from RFC processes at the IETF to all of the things that you do will not be the way that we go forward. I need you to be thoughtful about what's happening on public policy lists during this period. Some of the threads of public policy lists emanating from this lawsuit will likely end up in court. So be thoughtful about what you say and what you do on lists as you address these things. Everyone, of course, should continue to express how you feel about the public policy process. The public policy process in this meeting will go forward, notwithstanding that there's a lawsuit addressing fundamentally these issues. So we wanted you to know this. I really appreciate the Board and Ray suggesting that we take this head-on and tell you about it. I think some of you had seen a list activity related to this. If you have any questions or if the Board has any comments, I'd be glad to take them right now and, you know, answer them as best we can. MR. CURRAN: Microphones are open. I see Ole. MR. RYAN: While you're coming to the microphone, let me just say, we will keep you updated about this. I want to be very clear about this. I don't know if the court will rule from the bench. When we say rule from the bench, that the court will make a decision on October 23rd. If the court does, whether that decision is good or bad from my perspective, we'll certainly share with you any of the court's decision and our commentary on that. It may well be that the court will take the matter under advisement and think about it, and I now have grown hairless thinking about when judges will decide things. I have one case that's now pending for 21 months since I've argued it. I obviously confused the judge that day because's he's not quite sure what to do with it. But I can't tell you a timetable of when the next milestone will occur other than the oral argument on the 23rd. Sir. MR. CURRAN: Name and affiliation. MR. JACOBSEN: Good morning, Counsel. I'm Ole Jacobsen with Cisco. I was just wondering if the information about the thing in San Jose would be posted somewhere since I assume a fair number of the people in this room are kind of sort of in that area. Are we allowed to come listen? MR. RYAN: Yes. The court is open. It's before a Judge Ware, W-A-R-E, in his courtroom in the San Jose courthouse at 9:00 a.m. on Monday, October 23rd, and I'd be delighted, by the way, if, for example, Cisco's legal officer, you know, sent a lawyer, if people in the Valley -- you know, I think it's very useful for you to actually observe these things, and, frankly, for the people who are engineers, it might be very interesting to see how the legal system addresses fundamental issues which you understand but which will be new to the judge. MR. JACOBSEN: So it's not like sausage-making? MR. RYAN: Well, as an officer of the court, I'm not going to answer that question. MR. CURRAN: Any other questions? MR. RYAN: There's one other issue. We have every reason to believe that because Mr. Kremen is a very colorful individual and his fight with Mr. Cohen has been this is the sort of stuff that you write interesting articles about, that there will be press interest in this issue, both because of the colorfulness of the people that are involved and also because of the fundamental IP issues to the extent that the press understands the second issue. It will probably be the former issue that generates press coverage. If you find out that reporters are calling around on this, I'd be very interested in knowing that. We obviously have our own views on what we would like to say to the press that may be not unlike what I told you this morning. So if you could let ARIN staff know if the press is contacting you on this, it will be so that we can call them affirmatively and let them know our views on the subject. You know, you might get called by the press, you know, as they're doing a story on this as they're trying to understand what the IP issues are. MR. CURRAN: Okay. Steve, thank you for your time. Oh, Sam. MR. WEILER: Sam Weiler, SPARTA. I'm not quite sure what to make of your request that we be thoughtful in our mailing list postings. I'm wondering if you can be a little more concrete. Is there anything you'd like to see the community do, say in our public policy process, to help ARIN -- to help the community defend this process. MR. RYAN: Well, look. I'm not here to coach you on how you feel about the public policy process, any of you. You know what I mean? I think by your very presence in this room, you say that this process is a valuable one. That process is under attack. You can make your own conclusion about how you want to address that. And let me say this. We live in a grown-up world now. Okay. When I go home at night, I may be -- I go home to my family, and they know my good points and my bad points. We're family. We know ARIN has good points and bad points. When you're fundamentally attacked, you have to decide whether, you know, it's time to focus on big picture points. Is the public policy process an important thing? Is the way we govern the internet something valuable? Do we want a market in IPv4 and IPv6 where people sell it on EBay as opposed to distributing it based on requirements that the community sets. In this sense, Sam, you know, if you want to -- if anyone wants to support or criticize ARIN, I just ask them to be aware that there's a lawsuit on that fundamentally attacks us, but, you know, we're not thin-skinned. You can still say things that are critical of us, if that's how you feel. This is a democracy, and this is a fundamentally democratic process in this room. If you believe that you want to defend that when you're responding, be my guest. I hope -- Sam, thank you for the -- frankly, I appreciate being asked that question, and I hope that that is helpful in answering it. MR. CURRAN: Any other questions for Counsel? Okay. Thank you very much, Steve. MR. PLZAK: All right. As a reminder, Steve said he would be available for the next two days if you want to engage him in a conversation in the hallways or whenever. And so if you had some questions and you didn't want to express them here this morning, he would be still glad to meet with you and discuss these matters with you. So on with the meeting.

4 3

contacts at dlink and netgear?
by Gadi Evron 17 Nov '06

17 Nov '06

Hi. I do not send this email message in lightly. I have all but given up on contacts for dlink and netgear. If anyone can help reaching a security savvy person there, it would be very appreciated. The subject matter is potential compromise of many of their clients if I can't reach them. Thank you, Gadi.

2 1

How to get a list of research and academic ISP ?
by Maciej Kurant 16 Nov '06

16 Nov '06

Dear all, I am a PhD student at EPFL, Switzerland. My recent research interest is in large scale differences between the commercial and academic parts of the Internet. Of course, in order to perform this kind of studies I need a way to distinguish between these two worlds. I've learnt that Abilene does not provide commercial connectivity. This means that BGP prefixes and AS paths announced by Abilene BGP routers should lead only to research and academic destinations. I have extracted (from the BGP tables at http://abilene.internet2.edu/observatory) a list of all such destinations and obtained 1333 ASes (for data form July 2006). The number looks reasonable, but I would like to be sure that I am not making a mistake. Therefore I would be grateful if you could answer the following questions: 1) Is this approach to obtain a list of research and academic ISPs correct? 2) Do you maybe know of such lists compiled before? 3) If I keep not only the destination ASes, but also all ASes on the AS paths towards these destination I obtain a list of about 1400 ASes. How should I understand this? Does it mean that some research and academic destinations are reachable from Abilene only by traversing the commercial Internet? 4) Of course, research and academic ASes are often well connected to the commercial Internet. My guess is that in most cases their peering relationship is "customer-provider", where commercial ASes are providers. Is it possible that an academic AS is a provider for some commercial ASes? If so, does it happen often? Thank you in advance for your comments. Maciej Kurant ============================================= EPFL IC ISC LCA3 Maciej Kurant PhD Student CH-1015 Lausanne, Switzerland web site: <http://lcawww.epfl.ch/kurant> http://lcawww.epfl.ch/kurant =============================================

5 4

Network Connectivity... Dealing with Providers
by J. Oquendo 15 Nov '06

15 Nov '06

Semi off-topic... I have a client using an unnamed provider right now. My throughput to my client is horrible, their connection is horrible, their provider swears its not them... I can traceroute and ping till I'm blue in the face and show data to the provider (who thinks packet loss is not that big of a deal) but it seems to be getting me nowhere... What steps, methods, and or tools has anyone else used for monitoring connectivity. I have 3 ways of connecting to my client via Verio, Level3, and GBLX I plan to test all of my locations. Sometimes one of my connections gets stuck but the others work, other times all my connections fail... I segmented it to one of 3 routers in my clients path but I want to be fair to their provider so I'm looking to do some UNBIASED testing. So far I'm thinking bing, iperf, and some traceroutes but I wanted to get an overall view perhaps of something someone else has done that has helped them. Anyone care to discuss their methods or tools for dealing with a situation like this? ... I'm not in the ISP field anymore (VoIP now) so I stand nothing to gain/lose by pointing out a flaw in the provider... I just want my clients network to normalize at this point instead of having to wait until their provider's routers decide they actually want to forward packets instead of letting them roam around who knows where... Thanks in advance ... And definitely no need for the off-topic police to start a thread on how off topic this is... (Hence the intro) -- ==================================================== J. Oquendo http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x1383A743 sil . infiltrated @ net http://www.infiltrated.net The happiness of society is the end of government. John Adams

1 0

Anyone from SBC with networking clue available?
by Drew Weaver 15 Nov '06

15 Nov '06

thanks, -Drew

1 0

CWDM equipment (current favorites)
by Deepak Jain 15 Nov '06

15 Nov '06

A few years ago, NANOG had a discussion regarding various CWDM vendors. Repeatedly MRV was brought up as a good option for metro-area LAN type applications. Since then, I have actually touched some of the MRV product line personally and found it (and their customer support)... less than ideal. (not comparing to anyone else, and no one is really ideal). The bigger problem was that the devices seem to be less than intuitive, but rock solid once they are working. (which is what everyone praised them for). We need to place a new order for some new fiber builds and were considering some other vendors. Especially in the nx2.5G and nx10G (are CWDM x-cievers even available in 10G yet?) range. Anyone have any new favorites? I'll be glad to summarize/commiserate. :) Thanks in advance, DJ

6 6

Lucent GBE (4 x VC4) clues needed
by Saku Ytti 15 Nov '06

15 Nov '06

(oops technical question in nanog, wearing my asbestos suit) Consider this topology GSR - 3750 --(GE over 4xVC4) - NSE100 - NSE100 --(GE over 4xVC4) -- 3550 - GSR All other fibres are dark fibres, except marked. When we ping either NSE100 <-> GSR leg, when there is no background traffic there is no packet loss. If there is even few Mbps, lets say 10Mbps of background traffic we get 1-5% packet loss on 1500 bytes, and bit less packet loss on small packets. As background traffic increases packet loss quickly increases. We tried to replace (GSR-3750) with 7600, but same issue persisted. We've measured both Lucent GBE legs with having loop in other end and pushing tests from EXFO and Smartbits gear through the loop, no errors can be detected in RFC tests. There isn't very much that can be configured in the Lucent, and we've tried pretty much every setting. We've tried to set autonego on and off in every gear in the path, without any changes to observed behaviour. We've also tried to use use 1xVC4, without any changes to the behaviour. All VC4's in given leg are using same path. Even though we test the packet loss pinging from router link to router link, same packet loss is experienced for transit traffic also. We've tried to turn PXF off in NSE100. Packets between NSE100 <-> NSE100 over dark fibre are not lost. We're pretty much utterly without clues. All I can think off is some obscure IFG issue, that is, NSE100 would have less than perfect timing for IFG which would confuse Lucent regarding what is part of which frame. Does stuff like this really happen? NSE100 drops bad IP packets in PXF and there is only shared counter, so I can't tell if I get CRC for IP, I just loose the packets. But IS-IS is not handled in PXF, and I get %CLNS-4-LSPCKSUM and %CLNS-3-BADPACKET messages over both Lucent legs, but not between the NSE100's. So I assume the packets are not dropped, but broken. I swear next time I'll complain about some political issue, thanks, -- ++ytti

3 6