- NANOG - lists.nanog.org

Fw: ATT CDPD
by Ronald W. Jean 08 Jul '05

08 Jul '05

----- Original Message ----- From: Ronald W. Jean To: nanog(a)merit.edu Sent: Friday, July 08, 2005 8:00 AM Subject: ATT CDPD Can anyone tell me the status of CDPD in the ATT network? Thanks RonJ

1 0

The Cidr Report
by cidr-report＠potaroo.net 08 Jul '05

08 Jul '05

This report has been generated at Fri Jul 8 21:46:31 2005 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 01-07-05 161844 110253 02-07-05 161945 110291 03-07-05 161936 110251 04-07-05 161979 110171 05-07-05 161865 110332 06-07-05 162173 110414 07-07-05 162308 110338 08-07-05 162251 110458 AS Summary 19872 Number of ASes in routing system 8171 Number of ASes announcing only one prefix 1481 Largest number of prefixes announced by an AS AS7018 : ATT-INTERNET4 - AT&T WorldNet Services 90546944 Largest address span announced by an AS (/32s) AS721 : DLA-ASNBLOCK-AS - DoD Network Information Center 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'). --- 08Jul05 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 162376 110454 51922 32.0% All ASes AS4323 1120 223 897 80.1% TWTC - Time Warner Telecom AS18566 826 8 818 99.0% COVAD - Covad Communications AS4134 914 231 683 74.7% CHINANET-BACKBONE No.31,Jin-rong Street AS721 1100 562 538 48.9% DLA-ASNBLOCK-AS - DoD Network Information Center AS27364 555 22 533 96.0% ACS-INTERNET - Armstrong Cable Services AS7018 1481 963 518 35.0% ATT-INTERNET4 - AT&T WorldNet Services AS7725 499 17 482 96.6% CCH-AS7 - Comcast Cable Communications Holdings, Inc AS22773 499 25 474 95.0% CCINET-2 - Cox Communications Inc. AS6197 927 506 421 45.4% BATI-ATL - BellSouth Network Solutions, Inc AS3602 542 150 392 72.3% SPRINT-CA-AS - Sprint Canada Inc. AS17676 437 81 356 81.5% JPNIC-JP-ASN-BLOCK Japan Network Information Center AS6467 383 34 349 91.1% ESPIRECOMM - e.spire Communications, Inc. AS9929 356 49 307 86.2% CNCNET-CN China Netcom Corp. AS4766 577 281 296 51.3% KIXS-AS-KR Korea Telecom AS14654 281 12 269 95.7% WAYPORT - Wayport AS6140 395 142 253 64.1% IMPSAT-USA - ImpSat AS15270 311 59 252 81.0% AS-PAETEC-NET - PaeTec.net -a division of PaeTecCommunications, Inc. AS5668 484 236 248 51.2% AS-5668 - CenturyTel Internet Holdings, Inc. AS1239 883 639 244 27.6% SPRINTLINK - Sprint AS23126 260 20 240 92.3% KMCTELCOM-DIA - KMC Telecom, Inc. AS4755 529 296 233 44.0% VSNL-AS Videsh Sanchar Nigam Ltd. Autonomous System AS6167 300 67 233 77.7% CELLCO-PART - Cellco Partnership AS2386 891 659 232 26.0% INS-AS - AT&T Data Communications Services AS6198 463 240 223 48.2% BATI-MIA - BellSouth Network Solutions, Inc AS812 242 20 222 91.7% ROGERS-CABLE - Rogers Cable Inc. AS7545 503 287 216 42.9% TPG-INTERNET-AP TPG Internet Pty Ltd AS9498 327 114 213 65.1% BBIL-AP BHARTI BT INTERNET LTD. AS11456 312 99 213 68.3% NUVOX - NuVox Communications, Inc. AS6478 378 167 211 55.8% ATT-INTERNET3 - AT&T WorldNet Services AS9583 757 564 193 25.5% SIFY-AS-IN Sify Limited Total 17532 6773 10759 61.4% Top 30 total Possible Bogus Routes 24.246.0.0/17 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.246.128.0/18 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 64.9.224.0/19 AS209 ASN-QWEST - Qwest 64.17.32.0/24 AS13488 CBWU-13488 - Continental Broadband Florida, Inc DBA WebUnited 64.17.33.0/24 AS13488 CBWU-13488 - Continental Broadband Florida, Inc DBA WebUnited 64.17.37.0/24 AS13488 CBWU-13488 - Continental Broadband Florida, Inc DBA WebUnited 64.127.0.0/18 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 66.37.96.0/20 AS3764 IA-HOU-AS - Internet America, Inc. 66.187.96.0/22 AS9227 ONEHUNDRED-AS-AP ONE HUNDRED SERVICES, INC. 66.187.96.0/24 AS9227 ONEHUNDRED-AS-AP ONE HUNDRED SERVICES, INC. 66.187.97.0/24 AS9227 ONEHUNDRED-AS-AP ONE HUNDRED SERVICES, INC. 66.187.98.0/24 AS9227 ONEHUNDRED-AS-AP ONE HUNDRED SERVICES, INC. 66.187.99.0/24 AS9227 ONEHUNDRED-AS-AP ONE HUNDRED SERVICES, INC. 66.187.100.0/24 AS18194 PMMSI-AS-AP Philippine Multi-Media 66.187.101.0/24 AS18194 PMMSI-AS-AP Philippine Multi-Media 66.187.102.0/24 AS18194 PMMSI-AS-AP Philippine Multi-Media 66.187.103.0/24 AS18194 PMMSI-AS-AP Philippine Multi-Media 66.187.104.0/24 AS18194 PMMSI-AS-AP Philippine Multi-Media 66.187.105.0/24 AS18194 PMMSI-AS-AP Philippine Multi-Media 66.187.108.0/24 AS10026 ANC Asia Netcom Corporation 66.205.193.0/24 AS174 COGENT Cogent/PSI 66.205.194.0/24 AS174 COGENT Cogent/PSI 66.205.206.0/24 AS21510 TRISTAR - Tristar Communications 70.64.0.0/13 AS6327 SHAW - Shaw Communications Inc. 72.24.0.0/16 AS11492 CABLEONE - CABLE ONE 72.29.80.0/24 AS22659 LIQUIDIX - LIQUID COMMUNICATIONS, INC. 72.29.81.0/24 AS22659 LIQUIDIX - LIQUID COMMUNICATIONS, INC. 72.29.82.0/24 AS22659 LIQUIDIX - LIQUID COMMUNICATIONS, INC. 72.29.83.0/24 AS22659 LIQUIDIX - LIQUID COMMUNICATIONS, INC. 72.29.84.0/24 AS22659 LIQUIDIX - LIQUID COMMUNICATIONS, INC. 72.29.85.0/24 AS22659 LIQUIDIX - LIQUID COMMUNICATIONS, INC. 72.29.86.0/24 AS22659 LIQUIDIX - LIQUID COMMUNICATIONS, INC. 72.29.87.0/24 AS22659 LIQUIDIX - LIQUID COMMUNICATIONS, INC. 72.29.88.0/24 AS22659 LIQUIDIX - LIQUID COMMUNICATIONS, INC. 72.29.89.0/24 AS22659 LIQUIDIX - LIQUID COMMUNICATIONS, INC. 72.29.90.0/24 AS22659 LIQUIDIX - LIQUID COMMUNICATIONS, INC. 72.29.91.0/24 AS22659 LIQUIDIX - LIQUID COMMUNICATIONS, INC. 72.29.92.0/24 AS22659 LIQUIDIX - LIQUID COMMUNICATIONS, INC. 72.29.93.0/24 AS22659 LIQUIDIX - LIQUID COMMUNICATIONS, INC. 72.29.94.0/24 AS22659 LIQUIDIX - LIQUID COMMUNICATIONS, INC. 72.29.95.0/24 AS22659 LIQUIDIX - LIQUID COMMUNICATIONS, INC. 87.233.0.0/16 AS15703 TRUESERVER-AS TrueServer BV AS number 132.0.0.0/10 AS721 DLA-ASNBLOCK-AS - DoD Network Information Center 137.0.0.0/13 AS721 DLA-ASNBLOCK-AS - DoD Network Information Center 138.136.0.0/13 AS721 DLA-ASNBLOCK-AS - DoD Network Information Center 158.0.0.0/13 AS721 DLA-ASNBLOCK-AS - DoD Network Information Center 163.142.0.0/16 AS2500 JPNIC-ASBLOCK-AP JPNIC 190.192.193.0/24 AS3301 TELIANET-SWEDEN TeliaNet Sweden 192.30.93.0/24 AS17757 HPAUS-AP HP Australia 192.30.94.0/24 AS17757 HPAUS-AP HP Australia 192.40.105.0/24 AS5515 SONERA-GLOBAL-IP Sonera Solution Autonomous System 192.43.230.0/24 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 192.44.0.0/19 AS702 AS702 MCI EMEA - Commercial IP service provider in Europe 192.44.0.0/24 AS5501 FRAUNHOFER-CLUSTER-BW Fraunhofer Gesellschaft 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.81.182.0/24 AS719 ELISA-AS Elisa Oyj 192.81.183.0/24 AS719 ELISA-AS Elisa Oyj 192.81.184.0/24 AS719 ELISA-AS Elisa Oyj 192.88.99.0/24 AS29259 DE-IABG-TELEPORT IABG Teleport, DE 192.107.104.0/24 AS6458 GUATEL 192.119.135.0/24 AS270 PSCNI-AS - 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 & Greece Autonomous System 192.135.50.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 192.136.53.0/24 AS8346 SONATEL-AS Autonomous System 192.153.144.0/21 AS721 DLA-ASNBLOCK-AS - DoD Network Information Center 192.172.0.0/19 AS721 DLA-ASNBLOCK-AS - DoD Network Information Center 192.188.208.0/20 AS721 DLA-ASNBLOCK-AS - DoD Network Information Center 192.200.100.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 193.30.28.0/22 AS12374 LFNET-AS01 LF.net Netzwerksysteme GmbH 193.32.19.0/24 AS702 AS702 MCI EMEA - Commercial IP service provider in Europe 193.32.20.0/23 AS702 AS702 MCI EMEA - Commercial IP service provider in Europe 193.36.1.0/24 AS8220 COLT COLT Telecommunications 193.37.69.0/24 AS2856 BT-UK-AS BTnet UK Regional network 193.37.236.0/24 AS702 AS702 MCI EMEA - Commercial IP service provider in Europe 193.47.71.0/24 AS31027 NIANET-AS nianet is a Danish carrier and Internet Service Provider 193.110.77.0/24 AS3356 LEVEL3 Level 3 Communications 193.110.78.0/24 AS3356 LEVEL3 Level 3 Communications 193.110.79.0/24 AS3356 LEVEL3 Level 3 Communications 193.110.97.0/24 AS3356 LEVEL3 Level 3 Communications 194.31.227.0/24 AS21461 TRANSFAIRNET Transfair-net GmbH Krefeld 194.32.174.0/23 AS8426 CLARANET-AS ClaraNET 194.59.176.0/20 AS1273 CW Cable & Wireless 194.59.178.0/24 AS8481 TRANSNET transnet INTERNET Services 194.153.156.0/24 AS24865 KMITCHELL-AS Keith Mitchell's Network 194.246.72.0/23 AS8893 ARTFILES-AS Artfiles New Media GmbH 196.2.95.0/24 AS8668 TELONE-AS TelOne Zimbabwe P/L 196.3.162.0/24 AS6083 AFRINIC African Network Information Center 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.97.72.0/21 AS721 DLA-ASNBLOCK-AS - DoD Network Information Center 198.97.80.0/20 AS721 DLA-ASNBLOCK-AS - DoD Network Information Center 198.97.88.0/24 AS89 NUSC-CSTLNET-AS - Naval Underwater Systems Center 198.97.240.0/20 AS721 DLA-ASNBLOCK-AS - DoD Network Information Center 198.97.247.0/24 AS3475 LANT-AFLOAT - Department of the Navy 198.101.4.0/22 AS721 DLA-ASNBLOCK-AS - DoD Network Information Center 198.136.32.0/20 AS19329 MCNET - Martin County Board of County Commissioners 198.144.32.0/19 AS3998 CITY-NET - CityNet, Inc. 198.160.171.0/24 AS7046 UUNET-CUSTOMER - UUNET Technologies, Inc. 198.161.87.0/24 AS6539 GROUPTLCOM - GT Group Telecom Services Corp. 198.163.155.0/24 AS684 MTSAL-ASN - MTS Allstream Inc. 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.167.163.0/24 AS15290 ALLST-15290 - Allstream Corp. Corporation Allstream 198.168.0.0/16 AS701 ALTERNET-AS - UUNET Technologies, Inc. 198.169.0.0/16 AS803 SASKTEL - SaskTel 198.203.254.0/23 AS7046 UUNET-CUSTOMER - UUNET Technologies, Inc. 198.232.133.0/24 AS23075 SKOTOS-AS - Skotos Tech, Inc 199.9.128.0/17 AS668 ASN-ASNET-NET-AS - Defense Research and Engineering Network 199.10.0.0/16 AS721 DLA-ASNBLOCK-AS - DoD Network Information Center 199.60.0.0/20 AS271 BCNET-AS - University of British Columbia 199.96.44.0/23 AS19092 360NETWORKS-US - 360Networks (USA) Inc. 199.96.46.0/24 AS19092 360NETWORKS-US - 360Networks (USA) Inc. 199.114.0.0/21 AS721 DLA-ASNBLOCK-AS - DoD Network Information Center 199.114.128.0/18 AS721 DLA-ASNBLOCK-AS - DoD Network Information Center 199.114.130.0/24 AS721 DLA-ASNBLOCK-AS - DoD Network Information Center 199.114.132.0/24 AS721 DLA-ASNBLOCK-AS - DoD Network Information Center 199.114.134.0/24 AS3541 ITSDN-U4 - DISA/UNRRA 199.114.136.0/24 AS27044 DDN-ASNBLK1 - DoD Network Information Center 199.114.138.0/24 AS721 DLA-ASNBLOCK-AS - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DISA/UNRRA 199.114.142.0/24 AS721 DLA-ASNBLOCK-AS - DoD Network Information Center 199.114.148.0/24 AS721 DLA-ASNBLOCK-AS - DoD Network Information Center 199.114.150.0/24 AS721 DLA-ASNBLOCK-AS - DoD Network Information Center 199.114.152.0/24 AS27033 DDN-ASNBLK1 - DoD Network Information Center 199.114.153.0/24 AS27034 DDN-ASNBLK1 - DoD Network Information Center 199.114.154.0/24 AS1733 CENTAF-SWA - AF DDN PMO 199.114.160.0/24 AS1733 CENTAF-SWA - AF DDN PMO 199.120.32.0/19 AS16582 NEXTLEVELINTERNET - NEXTLEVEL INTERNET, INC. 199.121.0.0/16 AS721 DLA-ASNBLOCK-AS - DoD Network Information Center 199.123.0.0/18 AS721 DLA-ASNBLOCK-AS - DoD Network Information Center 199.123.16.0/20 AS721 DLA-ASNBLOCK-AS - DoD Network Information Center 199.123.80.0/21 AS721 DLA-ASNBLOCK-AS - DoD Network Information Center 199.189.32.0/19 AS7332 IQUEST-AS - IQuest Internet 199.202.0.0/16 AS701 ALTERNET-AS - UUNET Technologies, Inc. 199.246.116.0/24 AS813 UUNET-AS1 - UUNET Technologies, Inc. 200.49.0.0/20 AS14551 ALTERNET-SA-AS - UUNET Technologies, Inc. 200.49.8.0/21 AS6140 IMPSAT-USA - ImpSat 202.86.252.0/22 AS4748 RESOLINK-AS Resources Linke Network Limited 202.93.0.0/20 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 203.62.0.0/17 AS7572 AARNET-ACT-RNO Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.99.0.0/19 AS17746 ORCONINTERNET-NZ-AP Orcon Internet 203.99.142.0/24 AS9826 ILINK-HK-AP iLink.net Ltd 203.210.69.0/24 AS17536 PRODIGY-AS-AP Prodidgy Telecommunications 204.48.118.0/23 AS29912 CITIZENS-PROPERTY-INSURANCE-CORPORATION - Citizens Property Insurance Corporation 204.48.119.0/24 AS29912 CITIZENS-PROPERTY-INSURANCE-CORPORATION - Citizens Property Insurance Corporation 204.154.125.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.154.126.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.154.127.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.194.110.0/23 AS30653 EXOBIT - Exobit Networks Inc. 205.150.0.0/15 AS701 ALTERNET-AS - UUNET Technologies, Inc. 206.108.96.0/19 AS577 BACOM - Bell Advanced Communications Inc. 206.128.104.0/21 AS11709 VIC - VIRTUAL INTERACTIVE CENTER 206.167.57.0/24 AS376 RISQ-AS - Reseau Interordinateurs Scientique Quebecois (RISQ) 206.191.64.0/18 AS15290 ALLST-15290 - Allstream Corp. Corporation Allstream 206.191.96.0/19 AS15290 ALLST-15290 - Allstream Corp. Corporation Allstream 207.32.160.0/19 AS14563 MICROCAST - Microcast, Inc 207.32.219.0/24 AS4508 NETSOUTH - American Registry for Internet Numbers 207.32.220.0/24 AS4508 NETSOUTH - American Registry for Internet Numbers 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc 208.53.224.0/19 AS13576 SDNET - SOUTH DAKOTA NETWORK 208.138.48.0/20 AS6971 ATG-1 - Advanced Telcom Group, Inc 209.40.208.0/21 AS16592 Cybernet El Salvador 209.40.216.0/21 AS16592 Cybernet El Salvador 209.44.124.0/24 AS22241 ICCEPTS - Integrated Communications Concepts 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.213.32.0/19 AS10629 INTERPAC - Inter-Pacific Network Services 209.251.0.0/19 AS11036 SISCOM - SISCOM, Inc 216.37.110.0/23 AS4264 CERNET-ASN-BLOCK - California Education and Research Federation Network 216.82.160.0/20 AS20481 CALYX-NL Calyx Internet B.V. Netherlands 216.96.128.0/18 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.145.200.0/21 AS20304 JVLNET - JVLNET Internet Services 216.171.96.0/20 AS3356 LEVEL3 Level 3 Communications 216.178.37.0/24 AS3356 LEVEL3 Level 3 Communications 216.178.39.0/24 AS3356 LEVEL3 Level 3 Communications 216.178.42.0/24 AS3356 LEVEL3 Level 3 Communications 216.178.43.0/24 AS3356 LEVEL3 Level 3 Communications 216.228.64.0/21 AS6295 WHIDBEY1 - Whidbey Internet 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: OMB: IPv6 by June 2008
by Alexei Roudnev 07 Jul '05

07 Jul '05

What's the problem with independent address space for every entity (company, family, enterprise) which wants it? Big routing tables? Is RT of 1,000,000 routes BIG? I do not think so. Memory is cheap, modern routing schemas like CEF are effective. How many entities do we have on earth? It was a problem, but it IS NOT ANYMORE. IPSec - see all ISAKMP schema and IPSEC security associations, and see IPSec incompatibilities. Compare with SSL (works out-of-the-box in 99.999% cases, and allows both, full and hard security with root certificates etc, or simple security based on _ok, I trust you first time, then we can work_. Why MS uses PPTP? Because it is much more practuical vs IPSec. IPv4 was strong because it was designed by practical people and not so much by commiteets., IPv6 was designed by commiteets mainly. Do you know, that 'camel is horse designed by commiteet'? ----- Original Message ----- From: "Mohacsi Janos" <mohacsi(a)niif.hu> To: "Alexei Roudnev" <alex(a)relcom.net> Cc: "Daniel Golding" <dgolding(a)burtongroup.com>; "Scott McGrath" <mcgrath(a)fas.harvard.edu>; "David Conrad" <david.conrad(a)nominum.com>; <nanog(a)merit.edu> Sent: Thursday, July 07, 2005 1:08 AM Subject: Re: OMB: IPv6 by June 2008 > > > > > On Wed, 6 Jul 2005, Alexei Roudnev wrote: > > > > > IPv6 is an excellent example of _second system_ (do you remember book, > > written by Brooks many years ago?) Happu engineers put all their crazy ideas > > together into the second version of first 9succesfull) thing, and they > > wonder why it do not work properly. > > OS/360 is one example, IPv6 will be another. > > But I think IPv6 will one day a primary system. > > > > > > IPv6 address allocation schema is terrible (who decided to use SP dependent > > spaces?), security is terrible (who designed IPSec protocol?) and so so on. > > > If you can propose better solution to not to blow up routing table with > large number of entries you can speak at IETF v6ops. > > What is the problem with IPSec? > > > > > Unfortunately, it can fail only if something else will be created, which do > > not looks so. > > Regards, > > > Janos Mohacsi > Network Engineer, Research Associate > NIIF/HUNGARNET, HUNGARY > Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98 > > > ----- Original Message ----- > > From: "Daniel Golding" <dgolding(a)burtongroup.com> > > To: "Scott McGrath" <mcgrath(a)fas.harvard.edu>; "David Conrad" > > <david.conrad(a)nominum.com> > > Cc: <nanog(a)merit.edu> > > Sent: Wednesday, July 06, 2005 8:58 AM > > Subject: Re: OMB: IPv6 by June 2008 > > > > > >> > >> > >> There is an element of fear-mongering in this discussion - that's why many > >> of us react poorly to the idea of IPv6. How so? > >> > >> - We are running out of IPv4 space! > >> - We are falling behind <#insert scary group to reinforce fear of Other>! > >> - We are not on the technical cutting edge! > >> > >> Fear is a convenient motivator when facts are lacking. I've read the above > >> three reasons, all of which are provable incorrect or simple fear > > mongering, > >> repeatedly. The assertions that we are falling behind the Chinese or > >> Japanese are weak echoes of past fears. > >> > >> The market is our friend. Attempts to claim that technology trumps the > >> market end badly - anyone remember 2001? The market sees little value in > > v6 > >> right now. The market likes NAT and multihoming, even if many of us don't. > >> > >> Attempts to regulate IPv6 into use are as foolish as the use of fear-based > >> marketing. The gain is simply not worth the investment required. > >> > >> - Daniel Golding > >> > >> On 7/6/05 11:41 AM, "Scott McGrath" <mcgrath(a)fas.harvard.edu> wrote: > >> > >>> > >>> > >>> You do make some good points as IPv6 does not address routing > > scalability > >>> or multi-homing which would indeed make a contribution to lower OPEX and > >>> be easier to 'sell' to the financial people. > >>> > >>> As I read the spec it makes multi-homing more difficult since you are > >>> expected to receive space only from your SP there will be no 'portable > >>> assignments' as we know them today. If my reading of the spec is > >>> incorrect someone please point me in the right direction. > >>> > >>> IPv6's hex based nature is really a joy to work with IPv6 definitely > > fails > >>> the human factors part of the equation. > >>> > >>> Scott C. McGrath > >>> > >>> On Wed, 6 Jul 2005, David Conrad wrote: > >>> > >>>> On Jul 6, 2005, at 7:57 AM, Scott McGrath wrote: > >>>>> IPv6 would have been adopted much sooner if the protocol had been > >>>>> written > >>>>> as an extension of IPv4 and in this case it could have slid in > >>>>> under the > >>>>> accounting departments radar since new equipment and applications > >>>>> would > >>>>> not be needed. > >>>> > >>>> IPv6 would have been adopted much sooner if it had solved a problem > >>>> that caused significant numbers of end users or large scale ISPs real > >>>> pain. If IPv6 had actually addressed one or more of routing > >>>> scalability, multi-homing, or transparent renumbering all the hand > >>>> wringing about how the Asians and Europeans are going to overtake the > >>>> US would not occur. Instead, IPv6 dealt with a problem that, for the > >>>> most part, does not immediately affect the US market but which > >>>> (arguably) does affect the other regions. I guess you can, if you > >>>> like, blame it on the accountants... > >>>> > >>>> Rgds, > >>>> -drc > >>>> > >> > >> -- > >> Daniel Golding > >> Network and Telecommunications Strategies > >> Burton Group > >> > >> > > > >

6 5

FW: Request for Peering with AS4788 at Equinix SJO/ASH/LA
by Jason Sloderbeck 07 Jul '05

07 Jul '05

We are peered with Equinix Direct and Internap in San Jose and have received a couple solicitations from random companies to peer, though we're not a provider of transit. I have no desire to find new peers, so I'm not considering the offer below -- just wondering if this is a red flag that's worth passing on. I am skeptical, but I suppose this could be harmless. FWIW, I've seen AS4788 on old CIDR reports under "Possible Bogus Routes": http://www.ripe.net/ripe/maillists/archives/routing-wg/2003/msg00146.htm l -Jason -- Jason Sloderbeck Positive Networks jason(a)positivenetworks.net ________________________________ From: Muhawira Muhamed [mailto:muhawira@tm.net.my] Sent: Wednesday, July 06, 2005 9:38 PM To: ipadmin(a)positivenetworks.net Subject: Request for Peering with AS4788 at Equinix SJO/ASH/LA Dear Peering Admin, We are TMNet(AS4788) and would like to peer with you on EQUINIX/PAIX. Below are our details. ASNUM - 4788 AS Set - AS4788 Website - http://www.tm.net.my <http://www.tm.net.my/> IP - (206.223.116.149) [Equinix-San Jose] IP - (206.223.123.63) [Equinix-Los Angeles] IP - (206.223.115.149) [Equinix - Ashburn] IP - (198.32.176.26) [PAIX-Palo Alto] IP - (195.66.224.47) [LINX - London] IP - (217.79.160.135) [XPE - London] IP - (210.171.224.194) [JPIX - Japan] IP - (192.145.251.44) [KINX - Korea] IP - (202.40.161.213) [HKIX - Hong Kong] IPv6 - (2001:7f8:4:0::12b4:1) [LINX - London] IPv6 - (2001:504:0:1::4788:1) [Equinix - San Jose] IPv6 - (2001:504:0:2::4788:1) [Equinix - Ashburn] Advertised prefixes (IPv4): ~ 215 Contact/Support : peering@tm.net.my/noc@tm.net.my NOC Phone : +60322404600 If you would like to set up peering with us please respond with your details and confirmation that you have set your end up and we will complete our end. If you have received this email twice then please accept our apologies. This would have been due to an outbound mail issue which meant we had to resend the email. Please let us know. Thank you. Muhawira Muhamed CORE IMPLEMENTATION DIVISION, TELEKOM MALAYSIA BERHAD (128740-P), TM Annexe, No.1 Lengkok Pantai Baru, 59200 Kuala Lumpur. Malaysia (+ 8 GMT) tel:+ 603 2240 3040 fax: + 603 2240 3234

3 2

RE: OMB: IPv6 by June 2008
by Kuhtz, Christian 07 Jul '05

07 Jul '05

> My feeling is that the question isn't how much memory, but > rather how > much CPU and bandwidth is necessary to deal with routing thrash. Sure. Resources in the end. > Yes, you can aggregate different things to try to reduce the number > of entries, but that would seem to go against the general > idea Alexei > was suggesting. I mean, I'm an entity, and it'd be cool to have my > own routed PI address and not have to deal with reconfiguring my > network when I took my laptop from work to home... Sure. But, you think the majority of employers feel warm and fuzzy about this...? I would say the answer is a violent "hell no"... Most security folks get moderately freaked out by people moving machines back and forth, let alone IP addresses. ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 162

1 0

RE: mh (RE: OMB: IPv6 by June 2008)
by Kuhtz, Christian 07 Jul '05

07 Jul '05

> From: Joe Abley [mailto:jabley@isc.org] > On 2005-07-07, at 10:10, Kuhtz, Christian wrote: > > > Anyone here care to share operator perspectives shim6 and the > > like? Do > > we actually have anything that anyone considers workable (not whether > > somebody can make it happen, but viable in a commercial > > environment) for > > mh? > > There is no operational or implementation experience with shim6 at > this time, that I know of (the technical specifications for shim6 are > currently incomplete). The shim6 working group has its first meeting > in August in Paris, after which the goal is to progress quickly to a > set of specifications which can be implemented. > > As an easy-to-read overview of the shim6 approach, the following > rough draft may be useful: > > http://www.ietf.org/internet-drafts/draft-ietf-shim6-arch-00.txt > Thanks, I'm fully aware of where shim6 is right now. I'm asking if anyone feels this is headed anywhere useful or if we got anything else we can use to facilitate mh. To me, this is still a glaring hole as it has been for years now and nobody seems to be making any fundamental progress here. Partially probably because the deck seems to be fundamentally stacked against mh, which doesn't appear to have been a design criteria in the first place. Thanks, Christian The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 163

4 3

RE: OMB: IPv6 by June 2008
by Kuhtz, Christian 07 Jul '05

07 Jul '05

> > Compare with SSL (works out-of-the-box in 99.999% cases, > > and allows both, full and hard security with root certificates etc, or > > simple security based on _ok, I trust you first time, then we can > > work_. > > If I'm on the same shared medium as you I can kill your SSL session > with one packet. Only if shared medium = vanilla CSMA/CD Ethernet or the like. Just because 'transport' is shared, doesn't mean you as the consumer of information carried by the network have visibility. ***** "The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers." 118

2 1

RE: mh (RE: OMB: IPv6 by June 2008)
by Kuhtz, Christian 07 Jul '05

07 Jul '05

> I've been poking around with end-host / end-network multihoming at the > transport and application layers. See, e.g., MONET, a multi-homed Web > proxy designed to achieve high availability: > > http://nms.lcs.mit.edu/ron/ronweb/ > > In general, this kind of end-host informed multihoming has a lot of > potential for improving availability and performance (because the > end-points actually see what they're getting), but at the cost of some > extra implementation complexity. The shim6 mechanism (in the general > sense, not speaking to the specifics of shim6 negotiation, etc.), when > augmented with some end-host smarts, could be a nice way to do end-host > based multihoming in the ipv6 context. But, isn't that just a host based approach in the end and not a solution for entire networks? And if it isn't for entire networks, why do I need any to any connectivity anyway? I know, there's nothing that prevents it (or any schema like it, including shim6) from being network to network, but, good grief, what a huge amount of overhead to design around a requirements flaw. This sort of Moebius strip logic that's used to explain/solve the problem which has been created is fun to watch, but really just sucks in the end. One could argue, however, that we don't need multihoming, we all need to pour money into CDNs for things we really care about and lets somebody else do the worrying. . And it all seems like such a hack. Hurray, network based services are back. The PSTN is dead, long live the PSTN. Argh. Thanks, Christian The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 163

1 0

RE: OMB: IPv6 by June 2008
by Kuhtz, Christian 07 Jul '05

07 Jul '05

> we're off on the usual strange tangents. next will be whether > it is ethical to walk in your neighbor's open house if they're > running ipv6:-). Why of course it is. Afterall, anyone should be able to engage in any (group hug|rape) at any time of their chosing with anyone else. And if you don't lock your door, barricade it, build a moat, with automatic machine gun fire etc, well, then it's your fault that it happened to you.. isn't it. Afterall, you dressed for the part by showing up with your own 128-bit ball and chain. Except for the odd case where hugs are actually being passed out. Oh, sorry, was that too cynical? > ipv4 has some problems. the world has hacked around the major > ones with things such as [holding nose] nat. the ivtf came up > with a technically weak second system syndrome patch which has > yet to show enough sizzle to sell against the hacks to ipv4. > so the ivtf, a decade out, is trying to hack to make it work. > a shim on top of second system syndrome. i am not holding my > my breath. Ditto. > market physics will say whether scaling issues with nat et al. > are sufficiently obnoxious to cause ipv6 to become sufficiently > attractive; no amount of conjecturbation <tm> here will change > that. if it becomes enabling and profitable, then folk will > deploy and move. if not, they won't. life is simple. It is possible that outside NA deployment volume may change NA deployment habits. We're already not in the driver seat with several networking technologies as we previously were. Plain old economics. A 'maybe'. The real question is if and how operators should prepare for their deployments. Some of us run a bit more than a mom and pop shop and when massive infrastructures are being revamp where it would be nice if there was a clear direction where to place bets. Short of saying "hey, it's all layer 2, why do I care." I guess I could always go pay a consultant for a "non answer". ;-) Thanks, Christian The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 163

1 0

ICANN Posts New gTLD Questions Paper
by Fergie (Paul Ferguson) 07 Jul '05

07 Jul '05

..and I've hit my post limit for the day. :-) http://icann.org/announcements/announcement-06jul05.htm - ferg -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net ferg's tech blog: http://fergdawg.blogspot.com/

1 0