- Test - lists.nanog.org

RE: Best way to get of Bogon list?
by Majid Farid 26 Nov '04

26 Nov '04

www.as400.ibm.com www.americanexpress.ca & .com intuit.com list goes on and on. -- Majid. -----Original Message----- From: Hank Nussbacher [mailto:hank@mail.iucc.ac.il] Sent: Friday, November 26, 2004 1:00 AM To: Majid Farid Cc: Jon Lewis; nanog(a)merit.edu Subject: RE: Best way to get of Bogon list? On Thu, 25 Nov 2004, Majid Farid wrote: > > Jon, > > I will lend you the IP list I have so far. IBM is top of the list for > sure :) > > The bogon entry was removed in Aug for 72.0.0.0/8 yet people haven't > revisited to update the filters. Can you give a few concrete examples? Thanks, Hank > > > Changes in version 2.5 (02 AUG 2004) > 71/8 and 72/8 allocated to ARIN (AUG 2004). Removed from the bogon > lists. > > Thanks for all the response people. > > -- > Majid. > > -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of > Jon Lewis > Sent: Thursday, November 25, 2004 10:30 PM > To: nanog(a)merit.edu > Subject: Re: Best way to get of Bogon list? > > > On Fri, 26 Nov 2004, Suresh Ramasubramanian wrote: > > > I hate to say it, but that is the only way. > > > > You aren't dealing with a single bogon blocking list, you're dealing > with a > > whole lot of providers who are way behind the times and you just have > to go on > > contacting them one at a time. > > Its not even just providers. If it were, it'd be relatively easy to > just > find and call each NOC. You're likely to have bogon issues with few > large > providers. It's mostly smaller providers and end user networks...some > of > which are quite large or high profile. > > Do what I did and give people a way to test connectivity from both > affected and unaffected space and setup a 'hall of shame' page listing > the > IPs/networks that are behind broken filters. > > If someone will lend me appropriate /24's, I'll copy 69box.atlantic.net > into 70box, 71box, etc. and come up with a large (fairly comprehensive) > list of IPs behind broken bogon filters. > > ---------------------------------------------------------------------- > Jon Lewis | I route > Senior Network Engineer | therefore you are > Atlantic Net | > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > > > > +++++++++++++++++++++++++++++++++++++++++++ > This Mail Was Scanned By Mail-seCure System > at the Tel-Aviv University CC. >

1 0

The Cidr Report
by cidr-report＠potaroo.net 26 Nov '04

26 Nov '04

This report has been generated at Fri Nov 26 21:45:44 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 19-11-04 149080 102724 20-11-04 149096 102822 21-11-04 149197 102962 22-11-04 149221 103004 23-11-04 149311 102886 24-11-04 149271 102987 25-11-04 149387 103170 26-11-04 149492 103139 AS Summary 18460 Number of ASes in routing system 7546 Number of ASes announcing only one prefix 1405 Largest number of prefixes announced by an AS AS7018 : ATTW AT&T WorldNet Services 87145984 Largest address span announced by an AS (/32s) AS721 : DNIC 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'). --- 26Nov04 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 149527 103159 46368 31.0% All ASes AS18566 754 6 748 99.2% CVAD Covad Communications AS4134 831 179 652 78.5% CHINANET-BACKBONE No.31,Jin-rong Street AS4323 807 228 579 71.7% TWTC Time Warner Telecom AS7018 1405 994 411 29.3% ATTW AT&T WorldNet Services AS27364 444 33 411 92.6% ARMC Armstrong Cable Services AS22773 405 20 385 95.1% CXA Cox Communications Inc. AS6197 806 429 377 46.8% BNS-14 BellSouth Network Solutions, Inc AS701 1226 881 345 28.1% UU UUNET Technologies, Inc. AS22909 415 87 328 79.0% CMCS Comcast Cable Communications, Inc. AS1239 934 623 311 33.3% SPRN Sprint AS9929 340 34 306 90.0% CNCNET-CN China Netcom Corp. AS17676 382 78 304 79.6% JPNIC-JP-ASN-BLOCK Japan Network Information Center AS7843 478 177 301 63.0% ADELPH-13 Adelphia Corp. AS4355 384 99 285 74.2% ERSD EARTHLINK, INC AS6478 435 156 279 64.1% ATTW AT&T WorldNet Services AS21502 273 3 270 98.9% ASN-NUMERICABLE NUMERICABLE is a cabled network in France, AS4766 531 268 263 49.5% KIXS-AS-KR Korea Telecom AS14654 262 6 256 97.7% WAYPOR-3 Wayport AS9443 362 113 249 68.8% INTERNETPRIMUS-AS-AP Primus Telecommunications AS15557 371 126 245 66.0% LDCOMNET LDCOM NETWORKS AS6140 373 131 242 64.9% IMPSA ImpSat AS721 1039 803 236 22.7% DNIC DoD Network Information Center AS25844 244 17 227 93.0% SASMFL-2 Skadden, Arps, Slate, Meagher & Flom LLP AS2386 847 622 225 26.6% ADCS-1 AT&T Data Communications Services AS1221 790 567 223 28.2% ASN-TELSTRA Telstra Pty Ltd AS6198 434 221 213 49.1% BNS-14 BellSouth Network Solutions, Inc AS4814 210 6 204 97.1% CHINA169-BBN CNCGROUP IP network¡ªChina169 Beijing Broadband Network AS5668 417 213 204 48.9% CIH-12 CenturyTel Internet Holdings, Inc. AS9583 554 358 196 35.4% SIFY-AS-IN Sify Limited AS15270 232 38 194 83.6% PDP-14 PaeTec.net -a division of PaeTecCommunications, Inc. Total 16985 7516 9469 55.7% Top 30 total Possible Bogus Routes 24.138.80.0/20 AS11260 AHSICHCL Andara High Speed Internet c/o Halifax Cable Ltd. 24.246.0.0/17 AS7018 ATTW AT&T WorldNet Services 24.246.38.0/24 AS25994 NPGCAB NPG Cable, INC 24.246.128.0/18 AS7018 ATTW AT&T WorldNet Services 64.17.0.0/18 AS174 COGENT Cogent/PSI 64.17.32.0/24 AS5024 BRIDGE-75 BridgeNet, LC 64.17.33.0/24 AS5024 BRIDGE-75 BridgeNet, LC 64.17.37.0/24 AS5024 BRIDGE-75 BridgeNet, LC 64.46.27.0/24 AS8674 NETNOD-IX Netnod Internet Exchange Sverige AB 64.57.160.0/19 AS3561 SAVVI-3 Savvis 64.92.128.0/19 AS3561 SAVVI-3 Savvis 64.127.0.0/18 AS7018 ATTW AT&T WorldNet Services 64.209.192.0/18 AS3561 SAVVI-3 Savvis 69.26.32.0/19 AS17307 VIRTEL-15 Virtela Communications 132.0.0.0/10 AS721 DNIC DoD Network Information Center 137.0.0.0/13 AS721 DNIC DoD Network Information Center 138.136.0.0/13 AS721 DNIC DoD Network Information Center 158.0.0.0/13 AS721 DNIC DoD Network Information Center 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 ELISA-AS Elisa Oyj 192.40.105.0/24 AS5515 SONERA-GLOBAL-IP Sonera Solution Autonomous System 192.44.0.0/19 AS702 AS702 MCI EMEA - Commercial IP service provider in Europe 192.70.164.0/24 AS25689 NRCC-2 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.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 & Greece Autonomous System 192.135.50.0/24 AS7018 ATTW AT&T WorldNet Services 192.153.144.0/21 AS721 DNIC DoD Network Information Center 192.172.0.0/19 AS721 DNIC DoD Network Information Center 192.188.208.0/20 AS721 DNIC DoD Network Information Center 192.243.32.0/23 AS2044 PALINA Palin Aquisitions Inc. 196.2.95.0/24 AS8668 TELONE-AS TelOne Zimbabwe P/L 198.23.26.0/24 AS4390 BELLAT-7 Bell Atlantic, Inc. 198.97.72.0/21 AS721 DNIC DoD Network Information Center 198.97.80.0/20 AS721 DNIC DoD Network Information Center 198.97.88.0/24 AS89 NUSC-1 Naval Underwater Systems Center 198.97.240.0/20 AS721 DNIC DoD Network Information Center 198.97.247.0/24 AS3475 DEPART-52 Department of the Navy 198.101.4.0/22 AS721 DNIC DoD Network Information Center 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 AS721 DNIC DoD Network Information Center 199.60.0.0/20 AS271 UBC-3 University of British Columbia 199.96.44.0/23 AS19092 360NE-1 360Networks (USA) Inc. 199.96.46.0/24 AS19092 360NE-1 360Networks (USA) Inc. 199.114.0.0/18 AS568 DISOUN DISO-UNRRA 199.114.0.0/21 AS721 DNIC DoD Network Information Center 199.114.128.0/18 AS721 DNIC DoD Network Information Center 199.114.130.0/24 AS721 DNIC DoD Network Information Center 199.114.132.0/24 AS721 DNIC DoD Network Information Center 199.114.134.0/24 AS3541 DISAUN DISA/UNRRA 199.114.136.0/24 AS27044 DNIC DoD Network Information Center 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 AS27033 DNIC DoD Network Information Center 199.114.154.0/24 AS1733 ADP-41 AF DDN PMO 199.114.156.0/24 AS27034 DNIC DoD Network Information Center 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 AS721 DNIC DoD Network Information Center 199.123.0.0/18 AS721 DNIC DoD Network Information Center 199.123.16.0/20 AS721 DNIC DoD Network Information Center 199.123.80.0/21 AS721 DNIC DoD Network Information Center 199.189.32.0/19 AS7332 IQUEST IQuest Internet 199.197.8.0/22 AS21814 PARSON-18 Parsons Corp. 199.202.0.0/16 AS701 UU UUNET Technologies, Inc. 202.70.28.0/24 AS4515 ERX-STAR Star Internet Services Ltd. 202.72.68.0/24 AS17433 PHILWEB-AP PhilWeb.Com, Inc. 202.72.69.0/24 AS17433 PHILWEB-AP PhilWeb.Com, Inc. 202.72.70.0/24 AS17433 PHILWEB-AP PhilWeb.Com, Inc. 202.72.71.0/24 AS17433 PHILWEB-AP PhilWeb.Com, Inc. 202.72.72.0/21 AS17433 PHILWEB-AP PhilWeb.Com, Inc. 202.72.72.0/24 AS17433 PHILWEB-AP PhilWeb.Com, Inc. 202.72.73.0/24 AS17433 PHILWEB-AP PhilWeb.Com, Inc. 202.72.75.0/24 AS17433 PHILWEB-AP PhilWeb.Com, Inc. 202.72.76.0/24 AS17433 PHILWEB-AP PhilWeb.Com, Inc. 202.72.78.0/24 AS17433 PHILWEB-AP PhilWeb.Com, Inc. 202.72.79.0/24 AS17433 PHILWEB-AP PhilWeb.Com, Inc. 202.73.128.0/22 AS4058 LINKAGENET-AP CPCNet Hong Kong Ltd. 202.93.0.0/20 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 202.164.224.0/19 AS7599 IPXC-AS-AP IP Exchange 203.32.4.0/23 AS7617 TELEONE-HK TeleTeleOne (HK) Limited 203.62.0.0/17 AS7572 AARNET-ACT-RNO Australian Academic and Reasearch Network (AARNet) 203.99.0.0/19 AS17746 ORCONINTERNET-NZ-AP Orcon Internet 203.170.14.0/23 AS6648 ASN-SKYINTERNET Autonomous System Number peering of Sky Internet - BAYANTEL Inc. - Philppines 203.210.69.0/24 AS17536 PRODIGY-AS-AP Prodidgy Telecommunications 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.29.168.0/21 AS10248 IPI Internet Partners, Inc. 206.128.104.0/21 AS11709 VIIN VIRTUAL INTERACTIVE CENTER 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.253.190.0/23 AS8123 POLYBA Polybase 207.47.254.0/24 AS701 UU UUNET Technologies, Inc. 207.231.96.0/19 AS11194 NUNETI NuNet Inc 208.81.187.0/24 AS19194 SNL-8 Sentris Network LLC 208.138.48.0/20 AS7955 SOURCE-48 SourceNet Corporation 209.17.71.0/24 AS32272 CLEAR-17 ClearSkye Communications Inc 209.17.79.0/24 AS32272 CLEAR-17 ClearSkye Communications Inc 209.17.80.0/24 AS32272 CLEAR-17 ClearSkye Communications Inc 209.27.51.0/24 AS14132 INTERN-582 Internet Gateway Inc. 209.172.0.0/18 AS7770 TRTI Triton Technologies, Inc. 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 INS-52 Inter-Pacific Network Services 209.213.48.0/24 AS10629 INS-52 Inter-Pacific Network Services 209.213.49.0/24 AS10629 INS-52 Inter-Pacific Network Services 209.213.50.0/24 AS10629 INS-52 Inter-Pacific Network Services 209.251.0.0/19 AS11036 SISCOM-1 SISCOM, Inc 216.37.110.0/23 AS4264 CERFN California Education and Research Federation Network 216.96.128.0/18 AS7018 ATTW AT&T WorldNet Services 216.145.156.0/24 AS20304 JIS-32 JVLNET Internet Services 216.145.158.0/24 AS20304 JIS-32 JVLNET Internet Services 216.145.176.0/21 AS20304 JIS-32 JVLNET Internet Services 216.145.177.0/24 AS20304 JIS-32 JVLNET Internet Services 216.145.178.0/24 AS20304 JIS-32 JVLNET Internet Services 216.145.184.0/21 AS10758 INWAVE INWave Internet, Inc 216.145.184.0/24 AS10758 INWAVE INWave Internet, Inc 216.145.185.0/24 AS10758 INWAVE INWave Internet, Inc 216.145.186.0/24 AS10758 INWAVE INWave Internet, Inc 216.145.187.0/24 AS10758 INWAVE INWave Internet, Inc 216.145.188.0/24 AS10758 INWAVE INWave Internet, Inc 216.145.189.0/24 AS10758 INWAVE INWave Internet, Inc 216.145.190.0/24 AS10758 INWAVE INWave Internet, Inc 216.145.191.0/24 AS10758 INWAVE INWave Internet, Inc 216.145.200.0/21 AS20304 JIS-32 JVLNET Internet Services 216.168.64.0/19 AS174 COGENT Cogent/PSI 216.171.96.0/20 AS3356 LEVEL3 Level 3 Communications 216.186.151.0/24 AS3356 LEVEL3 Level 3 Communications 216.186.152.0/21 AS3356 LEVEL3 Level 3 Communications 216.186.160.0/23 AS3356 LEVEL3 Level 3 Communications 216.186.164.0/22 AS3356 LEVEL3 Level 3 Communications 216.186.192.0/22 AS3356 LEVEL3 Level 3 Communications 216.186.198.0/23 AS3356 LEVEL3 Level 3 Communications 216.186.248.0/23 AS3356 LEVEL3 Level 3 Communications 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 swinog(a)swinog.ch

1 0

Re: BBC does IPv6 ;) (Was: large multi-site enterprises and PI prefix [Re: who gets a /32)
by Brandon Butterworth 26 Nov '04

26 Nov '04

> An end site is defined as an end user ... Legal people make a lot from interpreting such documents so it's best not to stare too long at them. > As such, it appears to be a catch 22. If your organization has transit > and PA space, apparently, as I read the policy, that would preclude you > from qualifying as an LIR Anyone starting out will be an end site, if that meant you could only ever be an end site then there'd be nothing but end sites. Skip to the not an end site section and meet those requirements instead. > I think we definitely need > to review v6 allocation policy and improve its consistency and ability > to meet the needs of the community if v6 is to make real progress towards > broad adoption. I think working on the technical deficiences others have outlined would help more. brandon

2 1

RE: Best way to get of Bogon list?
by Majid Farid 26 Nov '04

26 Nov '04

Jon, I will lend you the IP list I have so far. IBM is top of the list for sure :) The bogon entry was removed in Aug for 72.0.0.0/8 yet people haven't revisited to update the filters. Changes in version 2.5 (02 AUG 2004) 71/8 and 72/8 allocated to ARIN (AUG 2004). Removed from the bogon lists. Thanks for all the response people. -- Majid. -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Jon Lewis Sent: Thursday, November 25, 2004 10:30 PM To: nanog(a)merit.edu Subject: Re: Best way to get of Bogon list? On Fri, 26 Nov 2004, Suresh Ramasubramanian wrote: > I hate to say it, but that is the only way. > > You aren't dealing with a single bogon blocking list, you're dealing with a > whole lot of providers who are way behind the times and you just have to go on > contacting them one at a time. Its not even just providers. If it were, it'd be relatively easy to just find and call each NOC. You're likely to have bogon issues with few large providers. It's mostly smaller providers and end user networks...some of which are quite large or high profile. Do what I did and give people a way to test connectivity from both affected and unaffected space and setup a 'hall of shame' page listing the IPs/networks that are behind broken filters. If someone will lend me appropriate /24's, I'll copy 69box.atlantic.net into 70box, 71box, etc. and come up with a large (fairly comprehensive) list of IPs behind broken bogon filters. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________

2 1

Re: who gets a /32 [Re: IPV6 renumbering painless?]
by Paul Vixie 26 Nov '04

26 Nov '04

> > you are drastically misunderstanding my hopes, my goals, and my role. > > Please explain them then. briefly, because i consider myself off-topic and sue probably does also. the problem statement answered by the ipngwg was wrong. they thought they were supposed to "solve the shortage of address space problem", but that wasn't the most serious problem then (and is not now). the right problem statement would be to "solve the shortage of PORTABLE address space problem". note the insertion of the word "portable" before "address space". the big problem in 1992 and the big problem now is that a wal-mart corporate desktop will either have an ambigious address (behind a NAT), or a hard-to-renumber isp-price-locked address (provider assigned), or a takes-a-slot-in-the-global routing-table address (provider independent). three strikes and you're out! none of those three things is acceptable, not even as a compromise. i have not looked in on the multi6 wg this year. my bad. perhaps you've come up with a fourth alternative, or a way of softening one of the three existing alternatives to the point where its benefits outweigh its costs. but everything i've actually looked at either resolves the cost/benefit in favour of some minority of which neither isc nor wal-mart is a part, or which would have been equally applicable to ipv4 such that all we needed was the gimmick itself, not 128-bit addresses, if only we'd been willing to pay this much pain back before ipngwg's work was complete. ipng needed rapid renumbering, including renumbering tcp endpoints realtime and including multihoming where you can add and delete PA interface addresses whe way commercial RAID vendors add and delete disk drives. the people in putative "charge" of this said either (a) they didn't agree, (b) they didn't understand, or (c) they didn't have time to add more requirements. now it's 2004 and lo and behold, the problems of 1992 are still with us, but now we have better terminology to describe them. you can be locked into a provider's pricing and service quality; or you can run NAT; or you can find a way to get your own slot in the global routing table. we have the same shortage of portable addresses now that we had in 1992, even though we have increased the overall supply of address space by a factor of 2**96. if multi6 offers a fourth alternative, it would probably also have worked with ipv4, in which case why did we spend years working on 128-bit addressing? i strongly believe that the isp community who pays ARIN's bills will decide that the best way to grow the industry is to let folks like ford and wal-mart have their own /32's, and that there will be a spectrum of r e n u m b e r i n g d i f f i c u l t y easy--------------------------moderate------------------------impossible with PA+NAT on the left (home dsl, cable); wal-mart and ford on the right with endsystem PI, and folks like isc in the middle, doing some kind of multi6 thing, whose costs while high will be lower than the renumbering penalty. since the arin BoT has no policy formation role, i'm expecting to be able to voice an opinion that weighs exactly as much as everybody else's, and to vote ultimately on whatever the policy formation function comes up with. so there. those are my views. aren't you glad you asked? > It's wrong if these issues that have global impact are decided regionally. yes. i understand that the acid rain people, the ozone layer people, the ice cap people, the whale people, and the ocean oxygen level people, all have that same complaint. human nature on a grand scale isn't always pretty.

5 5

Best way to get of Bogon list?
by Majid Farid 26 Nov '04

26 Nov '04

Good Day, I have question for the list what would be best/fastest way to get off bogon list. Arin allocated us a /19 2 months ago (72.1.192.0/19) We find that a lot of providers aren't accepting the BGP advertisements for that block because the block 72.0.0.0/8 was on bogon list. Thanks. Regards, Majid Farid ISP Specialist Telecom Ottawa Limited. majidfarid(a)telecomottawa.com [P] 613.225.4631 ext 7220 [F] 613.225.0636

2 1

RE: ULA and RIR cost-recovery
by Owen DeLong 25 Nov '04

25 Nov '04

>> Well... I'm saying, at least, that I'd rather change the RIR policy and >> work >> in an open and consistent manner based on input from the operational >> community and other stakeholders than have the IETF start setting >> allocation >> policy for PI space while pretending that isn't what is happening. If >> the IETF wants to set such a policy for UGA, then, fine, let's do that. >> However, >> pretending that it's not globally routable and trying to use that as an >> excuse to slide this into position is a fallacy that ignores the real >> world >> implications. > > ULAs are clearly routable over whatever scope people decide to. This was > also true of the SiteLocal prefix that ULAs are replacing. The only > difference is that ULAs have explicit text to avoid routing ambiguity > where SL didn't. I argued against deprecating SL partly on the basis that > it had the potential for ambiguity which would be a disincentive for > grey-market PI use. I understand and agree with your point about them > being a potential problem, but that potential is easily mitigated by > providing an economically viable alternative. > I was also opposed to deprecating SL on the same basis. However, just because SL was deprecated doesn't make me think ULA is a good idea. If we're going to have PI space, we should have PI space. Dividing it up into multiple classes based on how much you paid to register it doesn't make sense to me. > None of the organizations that are getting long IPv4 allocations will > qualify for an IPv6 prefix. There is an implicit concession that it is too > late to close the barn door for IPv4, but for IPv6 it is currently locked > tight by those that want to maintain control. > I don't believe that to be true. I think that a reasonable allocation policy for PI space in v6 would move forward in ARIN. I think that the recent adoption of 2002-3 and 2003-15 is evidence that the makeup and participation in ARIN has shifted. I also think that you underestimate the number of people who believe that PI space should be the norm, not the exception, and, that failure of v6 WG to address this in a meaningful way is not a good thing for v6 future. > Multi-homing is only one reason for PI space, and people get so hung up on > that one that they forget that the simple ability to change providers > without massive effort is just as important. > Changing providers without massive effort can be accomplished through a number of other methods. Multihoming is the more generic case. > Failure is too strong a term, but it is true that work is not complete. > The issue is many assumptions have been made at all layers of the system > about the alignment of all those characteristics, so just ripping them > out doesn't really solve anything more than the routing problem. Even if > the multi6 follow-on groups come up with a technical approach that splits > the functions, all the rest of the infrastructure will need to adapt and > that will take much longer than rolling out IPv6. > I do not believe that the v6 protocol will ever actually address those issues. Most of the necessary foundation for addressing them has been removed (A6, DNAME, mandatory autoconf). Agreed on the latter half, that's why I think that IPv6 should have addressed these early on and built those capabilities into the migration process. Adding them as hacks later has most of the disadvantages and reasons that they haven't been added to v4. That is why I chose the term failure. > Making a change that intentionally breaks fundamental assumptions will > meet much greater deployment resistance than something that intentionally > minimized such changes. Call the intentional minimization a failure if you > must, but from my perspective the only real failure will be to let the > Internet collapse into something less capable of delivering end user > services than X.25 was. > Here, we probably end up agreeing to disagree. I think that we could have built v6 to break the fundamental assumptions in such a way that the impact of those breaks was minimized. Yes, there would be deployment resistance, but, I don't think significantly more than exists for current v6. Owen

1 0

RE: ULA and RIR cost-recovery
by Owen DeLong 24 Nov '04

24 Nov '04

--On Wednesday, November 24, 2004 11:40 -0800 Tony Hain <alh-ietf(a)tndh.net> wrote: > Owen DeLong wrote: >> > I have never been a fan of the registered ULAs, and have argued against >> > the IETF's attempts to state specific monetary values or lifetime >> > practice as a directive to the RIRs; but I am equally bothered by the >> > thought that the operator community would feel a need to fight against >> > something that really doesn't impact them. >> >> Perhaps it is because in the perception of the operator community, we do >> not believe it will not impact us. The reality is that once registered >> ULAs >> become available, the next and obvious step will be enterprises that >> receive >> them demanding that their providers route them. Economic pressure will >> override IETF ideal, and, operator impact is the obvious result. > > This argument is basically saying that the RIR membership knows it is > forcing allocation policies that are counter to the market demand. The > only way ULAs could be considered for grey market PI use is due to lack > of any alternative mechanism to meet the real customer requirement for > independence. > Well... I'm saying, at least, that I'd rather change the RIR policy and work in an open and consistent manner based on input from the operational community and other stakeholders than have the IETF start setting allocation policy for PI space while pretending that isn't what is happening. If the IETF wants to set such a policy for UGA, then, fine, let's do that. However, pretending that it's not globally routable and trying to use that as an excuse to slide this into position is a fallacy that ignores the real world implications. > The current problem is that the RIR membership has self-selected to a > state where they set policies that ensure the end customer has no > alternative except to be locked into their provider's address space. > Everyone acknowledges that the demand for PI space is real while > simultaneously refusing to seriously deal with it (and the > re-architecting of fundamental assumptions about the Internet effort of > multi6, while serious, is not a short term solution). > This is absolutely not true. RIPE allocates /24s and smaller. I don't know APNICs current MAU. ARIN will allocate /22s and will probably consider smaller allocations either at the next meeting or the one after that. > My to-do list for the next couple of weeks has an item to ask for a BoF at > the next IETF on an interim moderately aggregatible PI approach. I cc'd > the Internet ADs since this is as good a time as any to start the > process. I have a proposal on the table, but I care more about a real > solution than I do about that specific approach. At the same time I > continue to get comments like: 'Your geographic addressing proposal > (draft-hain-ipv6-pi-addr-07.txt) is very attractive to us (it's pretty > much ideal, really)', so it probably makes a good starting point for > discussion. > Agreed. I'd like to see a real solution that allows any organization that wants to multihome to get PI space or have us solve the underlying problems so that address portability becomes irrelevant (better, I think, in the long term). As I see it, IP Addresses are currently used for the following purposes: Destination Endpoint Identifier (resolvable by requiring a solid directory service) Source Endpoint Identifier (mostly doesn't matter when this changes) Source Endpoint Authentication (this is bad and we should be using something better that actually identifies the host (or better yet in most cases, user) in a meaningful way) Host authorization (Same issue(s) as previous statement) Portion of Service authorizatoin decisions (again, same issues as previous two) In the early days of the ipng working group, there was hope that v6 would solve these issues. Sadly, after rejecting TUBA because it didn't solve these things, v6 has devolved into a similar failure. Owen

2 1

RADB question
by Paul Ryan 24 Nov '04

24 Nov '04

Just a quick question regarding RADB - how are you guys dealing with abuse complaints sent to the "radb-notify" or "radb-maint" e-mail addresses. I have some ideas but wanted to get a concensus from the commmunity ... Thoughts anyone ????? Regards, Paul

2 1

Looking for AT&T abuse_rbl contact
by D. Campbell MacInnes 24 Nov '04

24 Nov '04

Can anyone who is or has a good contact at the abuse_rbl desk at att.net please contact me offlist? (This is regarding their email blacklists). Abuse_rbl(a)att.net, abuse_rbl(a)abuse-att.net, and abuse(a)att.net are all known and have proved ineffective. Thank you in advance. --Campbell

1 0