- NANOG - lists.nanog.org

Re: How relable does the Internet need to be? (Was: Re: Converged Network Threat)
by Michael.Dillon＠radianz.com 28 Feb '04

28 Feb '04

>> I think the Internet is doing pretty well save some IOS code problems >> from time to time, and the typical root server hicups. >I'm interested to know what you mean by "typical root server hicups". >I'm trying to think of an incident which left the Internet generally >unable to receive answers to queries on the root zone, but I can't >think of one. There have been several incidents in which some root servers have hiccuped, sometimes being down for several days. But since the service they provide has N+12 resiliency, the service itself has never been unavailable. Similarly, the Internet has always had N+1 or better vendor resiliency so IOS can have problems while the non-IOS vendor (or vendors) keep on running. In fact, I would argue that N+1 vendor resiliency is a good thing for you to implement in your network and N+2 vendor resiliency is a good thing for the Internet as a whole. Let's hope that vendor P manages to get some critical mass in the market along with J and C. --Michael Dillon

3 2

Sail Ho! (was Re: Lawsuit on ICANN ...)
by Eric Brunner-Williams in Portland Maine 27 Feb '04

27 Feb '04

http://fightwls.com/

1 0

RE: How relable does the Internet need to be? (Was: Re: Converged Network Threat)
by Wesley Vaux 27 Feb '04

27 Feb '04

Mobile IP phones will be the same as everything else. For different roaming areas you'll get a different IP address and the services will be handled that way. I think someone will come out with it as soon as they figure out how to put together a worldwide network that will support it. I don't think the internet is fast enough nor robust enough to handle a phone network on top of it. This is just my oppinion. -----Original Message----- From: Jeff Shultz [mailto:jeffshultz@wvi.com] Sent: Friday, February 27, 2004 2:50 PM To: nanog(a)merit.edu Subject: Re: How relable does the Internet need to be? (Was: Re: Converged Network Threat) ** Reply to message from Petri Helenius <pete(a)he.iki.fi> on Fri, 27 Feb 2004 21:19:48 +0200 > Valdis.Kletnieks(a)vt.edu wrote: > > >20 years ago, 911 was able to say "unless you're the rare beast with > >a cell phone, basing it on the physical service address that the > >copper runs to would probably work alright in 99% of the cases". > > > >Let's not make the same mistake again. > > > > > > > So all IP phones should be outside of buildings and equipped with GPS > or Galileo receivers? > > Pete Does anyone actually offer a mobile IP phone service yet? Does anyone plan to? With Vonage you have to tell them where you are located so they can set your 911 service up to the proper 911 center. With cell phones it's based on the cell it comes into. If some sort of truly mobile IP based phone comes in, I'd guess that the provider is going to have to set it up to where the local router (or associated VOIP device) "listens" to the VOIP traffic for a 911 call, intercepts it and sends it to the local 911 center - my presumption is that they'll have to have a router of some sort in the local area to handle the mobile IP traffic. The GPS idea isn't a bad one either - since I think most new cell phones are coming out with this (it's been mandated, right?) it's a cheap addition and can be used by whatever the router redirects the call to for a better determination of the call center if the phone has the info. The easier solution would probably be for the "mobile IP phone service" to set it up as a dynamic address thing, where the phone number is assigned to the MAC address and the system updates a central index of what IP address is currently serving what phone number. And by whatever "DHCP" server assigned the address, that would be used to determine the 911 center most appropriate. As for the varied emergency numbers used throughout the world and such... if you are visiting a foreign country, take the time to figure out what the local (national) emergency numbers are. Much easier than an overly complex technological solution. Or add an "emergency" button on the phone that will send a signal that the switch will read as whatever the national emergency number is. Experience here: last summer I was at Ft. Campbell, KY, and a friend and I drove on the local interstate down to Nashville - when you get on the Interstate there you are in Tennesse, then you are in Kentucky for a short period (a few miles) and then back to Tennesse. I had to call 911on my cell for an accident and was connectted to a 911 center in Tennesee... but since I was on the Kentucky stretch of freeway they had to transfer me over to the local Kentucky 911 center. No problem. I suspect that as long as the VOIP 911 thing can get you "close" to the correct 911 center, they'll be able to handle the rest of the switching needed. And realistically - that's probably a better solution than trying to come up with an overly complex technological solution. These are supposed to be phones after all, not "dumb" ELT devices. Let the OT rants begin.... -- Jeff Shultz Loose nut behind the wheel.

1 0

Best Common Practice - Listening to local routes from peers?
by Michael Smith 27 Feb '04

27 Feb '04

Hello: We have a customer of a customer who is attempting to send traffic from IP space we control, through the Internet and back into us via one of our transit connections. I have filters in place that block all inbound traffic from the blocks I announce coming in over my transit and peering connections. This is breaking the downstream customer ability to route from them, through UUNet, and back to me. I'm curious what the Best Common Practice is for this type of scenario. I have always used this type of filtering as a way to bury source-spoofed traffic in a DDOS situation but I'm not sure if it's appropriate, generally speaking. If other operators would like to reply directly to me I would be more than happy to summarize to the list. Thank you for any assistance you can provide. Michael Smith mksmith(a)noanet.net

5 6

RE: IPv6 reverse lookup - lame delegation?
by Jeroen Massar 27 Feb '04

27 Feb '04

-----BEGIN PGP SIGNED MESSAGE----- Nico Schottelius [mailto:nico-nanog@schottelius.org] wrote: > Hello! > > I am more or less new to nanog (reading it about half a year), > so please correct me, if I do something wrong. > > Jeroen Massar [Tue, Feb 10, 2004 at 02:07:27PM +0100]: > > Jun-ichiro itojun Hagino wrote: > > > if i try to log into my machines back in tokyo by IPv6 > SSH, it takes > > > very long time. i guess i found the reason - > (possible) lame delegation > > > of blah.ip6.int. ip6.arpa. query returns instantly. > > > how could we fix it? > > > > By fixing the software as ip6.int was deprecated 2 years+++ > > ago as you should already know. > > I've read the RFC and also talked to some people using IPv6 adresses, > especially some using 6to4 (2002:/16). > > As far as I know the reverse mapping for 2002 is only > available through ip6.int, or am I wrong? Not wrong but correct. Delegations for that block can be requested by emailing hostmaster(a)ep.net But Geoff Huston has already published this draft: http://www.ietf.org/internet-drafts/draft-huston-6to4-reverse-dns-01.txt Which should solve the 6to4 problem. Personally I would say that 6to4 shouldn't be given reverse though, if people require that they are better off getting either native or tunneled IPv6 instead of this transition method especially because of the low deployment of 6to4 relays. > I think this is because 2002: is a test zone. But for me using > it almost always the only way to have reverse mapping is ip6.int. Get yourself a tunneled or native prefix from a LIR closeby. 6to4 is not testing, it is transition and it works(tm). Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / http://unfix.org/~jeroen iQA/AwUBQD8r8CmqKFIzPnwjEQKKHgCgqUR7Pj9cTamJlNBTEknTyF7k4BcAoKQP mum12QVg91rWgM2R2sqNDjU8 =6MzS -----END PGP SIGNATURE-----

1 0

The Cidr Report
by cidr-report＠potaroo.net 27 Feb '04

27 Feb '04

This report has been generated at Fri Feb 27 21:48:07 2004 AEST. The report analyses the BGP Routing Table of an AS4637 (Reach) router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org/as4637 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 20-02-04 131753 91870 21-02-04 131854 91847 22-02-04 131784 91848 23-02-04 131722 91867 24-02-04 131767 91928 25-02-04 131802 91999 26-02-04 131901 92037 27-02-04 132022 92097 AS Summary 16629 Number of ASes in routing system 6685 Number of ASes announcing only one prefix 1383 Largest number of prefixes announced by an AS AS7018 : ATTW AT&T WorldNet Services 73468672 Largest address span announced by an AS (/32s) AS568 : DISOUN DISO-UNRRA Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 27Feb04 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 131958 92173 39785 30.1% All ASes AS4323 689 203 486 70.5% TWC-34 Time Warner Communications, Inc. AS6197 734 300 434 59.1% BNS-14 BellSouth Network Solutions, Inc AS7018 1383 965 418 30.2% ATTW AT&T WorldNet Services AS701 1323 949 374 28.3% UU UUNET Technologies, Inc. AS27364 382 33 349 91.4% ARMC Armstrong Cable Services AS6198 545 215 330 60.6% BNS-14 BellSouth Network Solutions, Inc AS4134 652 329 323 49.5% CHINANET-BACKBONE No.31,Jin-rong Street AS22909 344 29 315 91.6% CMCS Comcast Cable Communications, Inc. AS22773 347 37 310 89.3% CXAB Cox Communications Inc. Atlanta AS9583 350 43 307 87.7% SATYAMNET-AS Satyam Infoway Ltd., AS1239 947 663 284 30.0% SPRN Sprint AS4355 385 101 284 73.8% ERSD EARTHLINK, INC AS6347 365 87 278 76.2% SAVV SAVVIS Communications Corporation AS1221 901 647 254 28.2% ASN-TELSTRA Telstra Pty Ltd AS17676 294 41 253 86.1% JPNIC-JP-ASN-BLOCK Japan Network Information Center AS6478 270 40 230 85.2% ATTW AT&T WorldNet Services AS6140 360 131 229 63.6% IMPSA ImpSat AS25844 243 16 227 93.4% SASMFL-2 Skadden, Arps, Slate, Meagher & Flom LLP AS209 714 500 214 30.0% QWEST-4 Qwest AS14654 216 4 212 98.1% WAYPOR-3 Wayport AS11305 242 41 201 83.1% INTERL-80 Interland Incorporated AS7843 411 212 199 48.4% ADELPH-13 Adelphia Corp. AS2386 431 239 192 44.5% ADCS-1 AT&T Data Communications Services AS5668 346 159 187 54.0% CIH-12 CenturyTel Internet Holdings, Inc. AS20115 610 425 185 30.3% CHARTE-72 Charter Communications AS4766 422 238 184 43.6% KIX Korea Internet Exchange for "96 World Internet Exposition AS4519 203 20 183 90.1% MAASCO Maas Communications AS9929 209 30 179 85.6% CNCNET-CN China Netcom Corp. AS6327 207 29 178 86.0% SHAWC-2 Shaw Communications Inc. AS15270 213 40 173 81.2% PDP-14 PaeTec.net -a division of PaeTecCommunications, Inc. Total 14738 6766 7972 54.1% Top 30 total Possible Bogus Routes 24.138.80.0/20 AS11260 AHSICHCL Andara High Speed Internet c/o Halifax Cable Ltd. 64.46.0.0/18 AS7850 IHIGHW iHighway.net, Inc. 64.46.4.0/22 AS11711 TULARO TULAROSA COMMUNICATIONS 64.46.12.0/24 AS7850 IHIGHW iHighway.net, Inc. 64.46.27.0/24 AS8674 NETNOD-IX Netnod Internet Exchange Sverige AB 64.46.34.0/24 AS3408 64.46.60.0/24 AS7850 IHIGHW iHighway.net, Inc. 64.46.63.0/24 AS7850 IHIGHW iHighway.net, Inc. 64.62.126.0/23 AS25700 SWIFTD SWIFTDESK VENTURE 66.114.0.0/19 AS16526 BIRCHT Birch Telecom, Inc. 66.114.28.0/24 AS15083 INMM Infolink Communication Services, Inc. 66.114.29.0/24 AS15083 INMM Infolink Communication Services, Inc. 66.114.30.0/24 AS15083 INMM Infolink Communication Services, Inc. 66.114.31.0/24 AS15083 INMM Infolink Communication Services, Inc. 69.8.128.0/17 AS7260 NORL Norlight Telecommunications 132.0.0.0/10 AS568 DISOUN DISO-UNRRA 137.0.0.0/13 AS568 DISOUN DISO-UNRRA 138.136.0.0/13 AS568 DISOUN DISO-UNRRA 158.0.0.0/13 AS568 DISOUN DISO-UNRRA 192.30.93.0/24 AS17757 HPAUS-AP HP Australia 192.30.94.0/24 AS17757 HPAUS-AP HP Australia 192.30.127.0/24 AS719 LANLINK Elisa Oyj 192.43.230.0/24 AS4738 SAARDNET-AS South Australian Academic Research and Development Network 192.44.0.0/19 AS702 AS702 MCI EMEA 192.64.84.0/24 AS5515 SONERA-GLOBAL-IP Sonera Solution Autonomous System 192.81.182.0/24 AS719 LANLINK Elisa Oyj 192.81.183.0/24 AS719 LANLINK Elisa Oyj 192.81.184.0/24 AS719 LANLINK Elisa Oyj 192.83.16.0/20 AS5515 SONERA-GLOBAL-IP Sonera Solution Autonomous System 192.83.32.0/19 AS5515 SONERA-GLOBAL-IP Sonera Solution Autonomous System 192.83.64.0/19 AS5515 SONERA-GLOBAL-IP Sonera Solution Autonomous System 192.83.96.0/22 AS5515 SONERA-GLOBAL-IP Sonera Solution Autonomous System 192.83.100.0/24 AS5515 SONERA-GLOBAL-IP Sonera Solution Autonomous System 192.119.135.0/24 AS270 NASA National Aeronautics and Space Administration 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.133.6.0/24 AS4004 GLOBALONE-EQUANT-UK Equant UK Autonomous System 192.135.50.0/24 AS7018 ATTW AT&T WorldNet Services 192.136.71.0/24 AS719 LANLINK Elisa Oyj 192.136.79.0/24 AS719 LANLINK Elisa Oyj 192.153.144.0/21 AS568 DISOUN DISO-UNRRA 192.172.0.0/19 AS568 DISOUN DISO-UNRRA 192.188.208.0/20 AS568 DISOUN DISO-UNRRA 192.243.32.0/23 AS2044 PALINA Palin Aquisitions Inc. 198.23.26.0/24 AS4390 BELLAT-7 Bell Atlantic, Inc. 198.97.72.0/21 AS568 DISOUN DISO-UNRRA 198.97.80.0/20 AS568 DISOUN DISO-UNRRA 198.97.88.0/24 AS89 NUSC-1 Naval Underwater Systems Center 198.97.192.0/20 AS568 DISOUN DISO-UNRRA 198.97.240.0/20 AS568 DISOUN DISO-UNRRA 198.101.4.0/22 AS568 DISOUN DISO-UNRRA 198.136.32.0/20 AS19329 MCBCC Martin County Board of County Commissioners 198.144.32.0/19 AS3998 CITY CityNet, Inc. 198.161.87.0/24 AS6539 GTGR GT Group Telecom Services Corp. 198.161.165.0/24 AS852 AGTA Telus Advanced Communications 198.163.155.0/24 AS684 MRN Manitoba Regional Network 198.167.0.0/16 AS7456 INS-51 Interhop Network SERVICES Inc. 198.167.163.0/24 AS15290 ACCA-2 Allstream Corp. Corporation Allstream 198.168.0.0/16 AS701 UU UUNET Technologies, Inc. 198.169.0.0/16 AS803 SASK SaskTel 198.232.133.0/24 AS23075 SKOTOS Skotos Tech, Inc 199.10.0.0/16 AS568 DISOUN DISO-UNRRA 199.60.0.0/20 AS271 UBC-3 University of British Columbia 199.84.0.0/16 AS701 UU UUNET Technologies, Inc. 199.114.0.0/18 AS568 DISOUN DISO-UNRRA 199.114.0.0/21 AS568 DISOUN DISO-UNRRA 199.114.128.0/18 AS568 DISOUN DISO-UNRRA 199.114.130.0/24 AS721 DNIC DoD Network Information Center 199.114.132.0/24 AS721 DNIC DoD Network Information Center 199.114.136.0/24 AS1913 DLA-8 Defense Logistics Agency 199.114.138.0/24 AS721 DNIC DoD Network Information Center 199.114.140.0/24 AS3544 DISAUN DISA/UNRRA 199.114.142.0/24 AS721 DNIC DoD Network Information Center 199.114.144.0/24 AS721 DNIC DoD Network Information Center 199.114.148.0/24 AS721 DNIC DoD Network Information Center 199.114.150.0/24 AS721 DNIC DoD Network Information Center 199.114.152.0/24 AS1913 DLA-8 Defense Logistics Agency 199.114.154.0/24 AS1733 ADP-41 AF DDN PMO 199.114.156.0/24 AS1913 DLA-8 Defense Logistics Agency 199.114.160.0/24 AS1733 ADP-41 AF DDN PMO 199.120.32.0/19 AS16582 NXLI NEXTLEVEL INTERNET, INC. 199.121.0.0/16 AS568 DISOUN DISO-UNRRA 199.123.0.0/18 AS568 DISOUN DISO-UNRRA 199.123.16.0/20 AS568 DISOUN DISO-UNRRA 199.123.80.0/21 AS568 DISOUN DISO-UNRRA 199.189.32.0/19 AS7332 IQUEST IQuest Internet 199.202.0.0/16 AS701 UU UUNET Technologies, Inc. 202.2.64.0/20 AS9729 IS-AP iAdvantage Limited 202.47.1.0/24 AS7491 PI-PH-AS-AP PI-PHILIPINES 202.70.0.0/20 AS4658 NETFRONT-AS NETFRONT I.T. LIMITED (HONG KONG) 202.70.24.0/24 AS17888 SINGTEL-HK SingTel Hong Kong Limited 202.70.28.0/24 AS4515 ERX-STAR Star Internet Services Ltd. 202.70.240.0/20 AS4058 LINKAGENET-AP CPCNet Hong Kong Ltd. 202.73.128.0/22 AS4058 LINKAGENET-AP CPCNet Hong Kong Ltd. 202.86.128.0/24 AS4755 VSNL-AS Videsh Sanchar Nigam Ltd. Autonomous System 202.86.142.0/24 AS30362 HAWAI-1 Hawaii-Pacific Teleport 202.86.171.0/24 AS4755 VSNL-AS Videsh Sanchar Nigam Ltd. Autonomous System 202.86.172.0/23 AS4755 VSNL-AS Videsh Sanchar Nigam Ltd. Autonomous System 202.86.190.0/24 AS4750 LOXLEY-TH Loxley Information Co., Ltd. 202.93.0.0/20 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 202.122.76.0/24 AS17553 TIMELESS-AP System Integration provider 202.133.3.0/24 AS9335 CIP-JAPAN-AS-AP ATT IPlus 202.143.56.0/21 AS4761 INDOSAT1-AP INDOSATNET-ASN 202.149.240.0/20 AS4761 INDOSAT1-AP INDOSATNET-ASN 202.149.240.0/21 AS4761 INDOSAT1-AP INDOSATNET-ASN 202.149.248.0/21 AS4761 INDOSAT1-AP INDOSATNET-ASN 202.155.243.0/24 AS4795 INDOSAT2-ID-AP INDOSATNET-ASN 202.170.128.0/22 AS4755 VSNL-AS Videsh Sanchar Nigam Ltd. Autonomous System 202.170.133.0/24 AS4755 VSNL-AS Videsh Sanchar Nigam Ltd. Autonomous System 202.170.134.0/23 AS4755 VSNL-AS Videsh Sanchar Nigam Ltd. Autonomous System 203.32.4.0/23 AS7617 203.62.0.0/17 AS7572 AARNET-ACT-RNO Australian Academic and Reasearch Network (AARNet) 203.86.2.0/23 AS4058 LINKAGENET-AP CPCNet Hong Kong Ltd. 203.87.224.0/19 AS4799 CHINA169-JT CNCGROUP old Jitong IP network 203.132.107.0/24 AS10236 FOXGOLD-NET-AU-AP FOXGOLD COMMUNICATIONS 203.132.108.0/24 AS10236 FOXGOLD-NET-AU-AP FOXGOLD COMMUNICATIONS 203.132.118.0/24 AS18065 CENTRALDATA-WA Central Data Pty Ltd. 203.132.122.0/24 AS4802 WANTREE-AS-AP Wantree Development 203.132.123.0/24 AS18065 CENTRALDATA-WA Central Data Pty Ltd. 203.132.124.0/24 AS18065 CENTRALDATA-WA Central Data Pty Ltd. 204.69.144.0/22 AS5668 CIH-12 CenturyTel Internet Holdings, Inc. 204.154.125.0/24 AS3952 TELLAB-1 TELLABS Operations, Inc. 204.154.126.0/24 AS3952 TELLAB-1 TELLABS Operations, Inc. 204.154.127.0/24 AS3952 TELLAB-1 TELLABS Operations, Inc. 204.194.110.0/23 AS30653 EXOBI Exobit Networks Inc. 205.150.0.0/15 AS701 UU UUNET Technologies, Inc. 206.41.32.0/19 AS14824 NCC-105 NewSouth Communications Corp. 206.81.187.0/24 AS19194 SNL-8 Sentris Network LLC 206.108.34.0/24 AS852 AGTA Telus Advanced Communications 206.108.35.0/24 AS852 AGTA Telus Advanced Communications 206.167.57.0/24 AS376 RISQR-3 Reseau Interordinateurs Scientique Quebecois (RISQ) 206.191.64.0/18 AS15290 ACCA-2 Allstream Corp. Corporation Allstream 206.251.69.0/24 AS27429 TIL-33 Telesat International Ltd. 207.162.192.0/19 AS4589 EASYNET Easynet Group Plc 207.231.96.0/19 AS11194 NUNETI NuNet Inc 208.81.187.0/24 AS19194 SNL-8 Sentris Network LLC 209.169.219.0/24 AS189 GNTY Genuity 209.169.223.0/24 AS189 GNTY Genuity 209.205.69.0/24 AS21578 Universidad autonoma de Bucaramanga 209.205.70.0/24 AS21578 Universidad autonoma de Bucaramanga 209.205.81.0/24 AS15066 SkyNet de Colombia S.A. 209.205.82.0/24 AS15066 SkyNet de Colombia S.A. 209.205.84.0/24 AS15066 SkyNet de Colombia S.A. 209.205.95.0/24 AS6347 SAVV SAVVIS Communications Corporation 209.213.32.0/19 AS10629 INS-52 Inter-Pacific Network Services 209.213.50.0/24 AS10629 INS-52 Inter-Pacific Network Services 209.213.51.0/24 AS10629 INS-52 Inter-Pacific Network Services 209.213.55.0/24 AS10629 INS-52 Inter-Pacific Network Services 209.213.56.0/24 AS10629 INS-52 Inter-Pacific Network Services 209.222.137.0/24 AS27429 TIL-33 Telesat International Ltd. 209.240.96.0/19 AS10815 KCNETI-1 KCnet, Inc. 209.251.0.0/19 AS11036 SISCOM-1 SISCOM, Inc 209.251.64.0/19 AS10266 MDCN MDC, Inc. 210.213.0.0/19 AS6453 GIEUROPE Teleglobe America Inc. 216.18.224.0/21 AS11458 IMBRIS-1 IMBRIS, INC. 216.18.224.0/22 AS11458 IMBRIS-1 IMBRIS, INC. 216.18.228.0/22 AS11458 IMBRIS-1 IMBRIS, INC. 216.36.46.0/24 AS7176 GTEIEUROPE-AS Genuity European AS 216.36.47.0/24 AS7176 GTEIEUROPE-AS Genuity European AS 216.96.128.0/18 AS7018 ATTW AT&T WorldNet Services Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog(a)merit.edu eof-list(a)ripe.net apops(a)apops.net routing-wg(a)ripe.net afnog(a)afnog.org

1 0

RE: Lawsuit on ICANN (was: Re: A few words on VeriSign's sitefind er)
by Pendergrass, Greg 27 Feb '04

27 Feb '04

OT I know, but this has to be the quote of the week: "Working the ICANN process is like being nibbled to death by ducks, it takes forever, it doesn't make sense, and in the end we're still dead in the water." said Tom Galvin, VeriSign's vice president for government relations. With oratory like that how can they possibly loose? ;) GP -----Original Message----- From: Deepak Jain [mailto:deepak@ai.net] Sent: 26 February 2004 21:51 To: nanog(a)merit.edu Subject: Lawsuit on ICANN (was: Re: A few words on VeriSign's sitefinder) Since no one else has mentioned this: http://biz.yahoo.com/rc/040226/tech_verisign_2.html > Vodafone Global Content Services Limited Registered Office: Vodafone House, The Connection, Newbury, Berkshire RG14 2FN Registered in England No. 4064873 This e-mail is for the addressee(s) only. If you are not an addressee, you must not distribute, disclose, copy, use or rely on this e-mail or its contents, and you must immediately notify the sender and delete this e-mail and all copies from your system. Any unauthorised use may be unlawful. The information contained in this e-mail is confidential and may also be legally privileged.

1 0

ICANN/Registry Agreement:
by Deepak Jain 27 Feb '04

27 Feb '04

Doesn't sitefinder give one registry superior access to the registry's resources than the others, etc, etc? --- http://www.icann.org/tlds/agreements/verisign/registry-agmt-apph-16apr01.htm VeriSign Equivalent Access Certification VeriSign, as Registry Operator ("VGRS"), makes the following certification: 1. All registrars (including any registrar affiliated with VGRS) connect to the Shared Registration System Gateway via the Internet by utilizing the same maximum number of IP addresses and SSL certificate authentication. 2. VGRS has made the current version of the registrar toolkit software accessible to all registrars and has made any updates available to all registrars on the same schedule. 3. All registrars have the same level of access to VGRS customer support personnel via telephone, e-mail and the VGRS website. 4. All registrars have the same level of access to the VGRS registry resources to resolve registry/registrar or registrar/registrar disputes and technical and/or administrative customer service issues. 5. All registrars have the same level of access to VGRS-generated data to reconcile their registration activities from VGRS Web and ftp servers. 6. All registrars may perform basic automated registrar account management functions using the same registrar tool made available to all registrars by VGRS. 7. The Shared Registration System does not include any algorithms or protocols that differentiate among registrars with respect to functionality, including database access, system priorities and overall performance. 8. All VGRS-assigned personnel have been directed not to give preferential treatment to any particular registrar. 9. I have taken reasonable steps to verify that the foregoing representations are being complied with. This Certification is dated this the __ day of __________, _____.

4 4

A few words on VeriSign's sitefinder
by David Monosov 27 Feb '04

27 Feb '04

Sorry for barging in to this fine mailing list like this; long time reader, first time contributor. We, as the Internet engineering community, have made a great mistake. Actually, it wasn't even one large mistake, but a series of small ones. Engineers are busy people, and most us work under the constraints of the organizational entities we serve (be it ISPs, non-internet corporates, or even non-profits). Few of us have time for politics; even fewer have the desire and motivation for politics, and those of us who do try usually end up facing a brick wall of stubbornness, lack of understanding of the underlying technical issues, or just a deaf ear. In the meanwhile however, the Internet has made its way into many homes, businesses, and organizations. Today, one can easily state that the Internet has become a social framework, a business infrastructure, and most of all, a critical global communication network. The way the Internet works affects great and many people, in great and many ways; the Internet has power - and where there is power, there are struggles to take control over that power, and exploit it. This is apparently one of the beauties of democratic capitalism (under which I will be so bold to presume many of us live). Yet, with capitalism in mind, as a society we come together and place limitations, protocols, and procedures in order to limit the extent on which a single capitalist or a corporate entity can disrupt the life, safety, and freedom of society at large for their private agenda. Most democratic capitalistic countries have strict controls over issues such as environment, business practices, and public safety (I don't think many of us would like to visit a shopping mall built with no other considerations in mind besides the cost of construction materials, as we realize some engineering principles need to be put into practice during construction for the building to be considered reasonably safe.) Our mistake is that of ignorance. With all this said, and in nothing more than my own humble opinion, I would like to bring the following to your attention: The current situation with VeriSign is unacceptable, regardless of SiteFinder (even though the former serves a good example as for *why* it is unacceptable). The DNS (applicable RFC and IETF documents) provides very clear definition of country-specific top level domains, such as ".nl", ".jp", or even ".tv". It is the full right of the governing body of each country to assign a commercial or non-commercial entity to manage the assignments of such domains in a way in which their political system sees fit. The United States of America has the '.us' top level domain for that specific purpose. Many people argue that ".com", ".net", and ".org" are of American origin (and date back to ARPAnet and DoD), this is a sensible and true argument, however - real life practice is such that those 3 top level domains are used by various internet-connected entities worldwide. There is *no reason whatsoever* the control over those entities will be in the hands of a commercial entity. They constitute an integral part of the "Internet fabric" at least as much as the TCP/IP protocol itself from the social and usability POV. They are global, and integral to the correct operation of the Internet at large. In fact, those 3 domains exist "in cyberspace"; they do not have geographic or political borders, and the management of those TLDs has to be in the hands of a non-profit organization which is interested in *technical and organizational management*, not in making a dollar. If there are (and we can all see there are, else VeriSign wouldn't have such a successful stock) dollars to be made on those top level domains, or more specifically - the .net and .com domains currently managed by VeriSign, those dollars should be contributed back to the Internet community - and used to resolve technical and organizational issues (and there are many of those, from spam to security, or even basic coordination of effort), rather than benefit a handful of capitalistic shareholders. Root servers, and the .net, .com (as well as .org) domains belong to the world now; Welcome to the global democracy, brought to you by the ability to send packets across the globe at the speed of light. We all rely on them, and their management should be done in a way appropriate for their status. There are many capable organizations worldwide which could assume such a task. ISC (previously mentioned in this context) would indeed be a fine choice as it has proven itself to be reliable and politically independent over time. I would recommend all of you to rally your organizations and companies behind you, and advocate a change toward the previously mentioned direction. Power is a dangerous thing, especially in the wrong hands. We will all suffer to different extents for many years down the line if nothing is done today to put things straight. It's time to put an end to quasi-science, quasi-politics, and power struggles in favor of strict engineering with social and technical considerations in mind. We all know it's the only way to make it right. --- David 'wEEkAY' Monosov david dot monosov at futureinquestion dot net

10 14

Re: Converged Networks Threat (Was: Level3 Outage)
by Michael.Dillon＠radianz.com 26 Feb '04

26 Feb '04

>> This is possible today. Build your own routers using >> the right microkernel, OSKIT and the Click Modular Router >> software and you can have this. When we restrict ourselves >> only to router packages from major vendors then we are >> doomed to using outdated technology at inflated prices. >Tell you what Michael, build me some of those, have it pass my labs >and I'll give you millions in business. Deal? The problem with your lab is that you have too many millions to give. In order to win those millions people would have to prove that their box is at least as good as C and J in the core of the largest Internet backbones in the world. That is an awfully big hurdle and attempting it costs so much money that anyone would be a fool to try it unless they already had millions in the bank. History shows that if you can build a mousetrap that is technically better than anything on the market, your best route for success is to sell it into niche markets where the customer appreciates the technical advances that you can provide and is willing to pay for those technical advances. I don't think that describes the larger Internet provider networks. --Michael Dillon

8 10