- Test - lists.nanog.org

RE: Waiver of IP and AS Number Transfer Fees
by jnelson 04 Jul '02

04 Jul '02

Hey, I'll be the first to laugh it up about some of ARIN's oldschool GM-style practices, but let's not knock the staff there... I've had nothing but good experiences with the front-liners (billing and support). And I believe your cry has been heard and this clean-up and the template revision are merely portions of their restructuring. -j -----Original Message----- From: Tom Thomas [mailto:tom.thomas@i-nap.co.uk] Sent: Wednesday, July 03, 2002 9:32 PM To: m.hallgren(a)free.fr; deepak(a)ai.net; jnelson; nanog(a)merit.edu Subject: RE: Waiver of IP and AS Number Transfer Fees Michael its simple ARIN is staffed by a bunch of people who have no concept of business or reality. There reality is based on outmoded ideals enforced on them, so no wonder people do not want to go through the abuse of dealing with them. -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Michael Hallgren Sent: Wednesday, July 03, 2002 4:34 PM To: deepak(a)ai.net; jnelson; nanog(a)merit.edu Subject: RE: Waiver of IP and AS Number Transfer Fees >Please correct me if I am wrong. This is not allowing the practice of >selling IPs or ASes, I've never really come around to fully understand the notion (more and more common, it seems) of _selling_ such..? (Maybe I'm an idealist :) > but it encourages those of us who have acquired other >companies to consolidate all the registrations under a single NIC handle >(for example) to reduce the total number of contacts floating out there? > >Is my understanding accurate? > I would hope so, in a general perspective. mh >Thanks, > >DJ

1 0

Updated bogon list
by Rob Thomas 04 Jul '02

04 Jul '02

Hi, NANOGers. For those of you who don't already know... 221/8 has been allocated to APNIC, effective July 2002. It hasn't yet appeared in the routing table based on my nine eBGP feeds. My bogon templates have been modified accordingly: http://www.cymru.com/Documents/bogon-list.html Thanks, Rob. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);

1 0

Re: Sprint peering policy
by Rizzo Frank 04 Jul '02

04 Jul '02

Gordon Cook wrote: > I don't post here much Any chance of changing that? After listening to endless banter from Ralph Doncaster, I'd welcome of your latest interview with Bill St. Arnaud and Wade Hong on CANET*3.1415927. Pretty please with a plastic figurine of the delectable Ms. Jane on top? > Finally I'd like to ask a question in return. I am trying to look at > what will grow up on the ashes of the current industry collapse. Larger large players, more basement web hosters. > Fiber to the home is beginning to appear in a few > isolated areas. It will disappear just as quickly. Has, in some places. A few years back, VC's were wooed by the concept. They didn't know what the heck it was, nor did they care, so long as those pitching it (who knew even less about it, for the most part) kept dropping buzzards such as "broadband" and "fiber" over and over. Now's the wake-up call. It just isn't cost-effective, which might explain why every company offering FTTH services in the States is either f'd, soon-to-be f'd, or abandoned the plans in favor of something more viable like cable. Whatever happened to WINfirst? > Are there folk with adequate > routes and connectivity that would undertake to form a network that > might be independent of the current internet core back bone of what > (112,000 routes?) on top of which sit the half dozen or so Tier one > players that peer primarily with each other and demand transit $$$ > from everyone else? Web and email stay on the legacy backbone...new > services migrate to a backbone with a cost structure unencumbered by > the tier one oligopolists? No. > PS. Anyone interested in trekking in Nepal in October please let me > know off list. eg http://cookreport.com/everest.shtm When? I'm handnig out summaries of the Cook Report at the Princeton-Harvard game on the 26th. Then it's off to Shanghai to crash the ICANN meeting. Then Eugene to lobby for macro-allocations and true financial disclosure/accountability at the ARIN conference. Beginning of the month works best. I've been benching 300 and tracing Broadwing cross-country fiber routes by foot in preparation, hopefully you'll be able to keep up! Have any other internet luminaries expressed an interest in going? Frank "Proud to be an American" Rizzo PS: I had a bet with my boss: how many of you are watching fireworks tonight? Mail me privately and I'll post a summary to the list.

1 0

FW: Waiver of IP and AS Number Transfer Fees
by jnelson 03 Jul '02

03 Jul '02

TWiMC: No doubt most with the responsibility of doing so received this statement, but.... OWN 'M IF YOU GOT 'M--clean up the databases (Unfortunately for me I just paid a $250 on June 27th--lucky me.) j -----Original Message----- From: owner-arin-announce(a)arin.net [mailto:owner-arin-announce@arin.net] On Behalf Of Member Services Sent: Tuesday, July 02, 2002 3:59 PM To: arin-announce(a)arin.net Subject: Waiver of IP and AS Number Transfer Fees At the ARIN IX Member's Meeting there was consensus expressed that transfer fees should be waived as a means of encouraging subscribers to participate in database cleanup. The database cleanup effort is a part of the database conversion project. There was overwhelming support for such a waiver for the remainder of the fiscal year. During its June 5 meeting the ARIN Board of Trustees approved a motion to waive the fees for the transfer of AS Numbers and IP addresses for the period extending from July 1, 2002 through December 31, 2002. The Board meeting minutes can be viewed at: http://www.arin.net/library/minutes/bot/bot06052002.html ARIN Member Services

3 3

AS path fugliness?
by Mike Lewinski 03 Jul '02

03 Jul '02

Anyone else receiving huge as-path (more than 125) causing these: Jul 3 08:23:06 MDT: %BGP-3-INSUFCHUNKS: Insufficient chunk pools for aspath, requested size 268 Jul 3 08:23:46 MDT: %BGP-3-INSUFCHUNKS: Insufficient chunk pools for aspath, requested size 270 Jul 3 08:27:45 MDT: %BGP-3-INSUFCHUNKS: Insufficient chunk pools for aspath, requested size 274 Jul 3 08:31:59 MDT: %BGP-3-INSUFCHUNKS: Insufficient chunk pools for aspath, requested size 268 Jul 3 08:41:02 MDT: %BGP-3-INSUFCHUNKS: Insufficient chunk pools for aspath, requested size 268 Jul 3 08:41:43 MDT: %BGP-3-INSUFCHUNKS: Insufficient chunk pools for aspath, requested size 270 Jul 3 08:57:56 MDT: %BGP-3-INSUFCHUNKS: Insufficient chunk pools for aspath, requested size 268 Jul 3 09:04:04 MDT: %BGP-3-INSUFCHUNKS: Insufficient chunk pools for aspath, requested size 268 Jul 3 09:10:01 MDT: %BGP-3-INSUFCHUNKS: Insufficient chunk pools for aspath, requested size 268 Jul 3 09:10:52 MDT: %BGP-3-INSUFCHUNKS: Insufficient chunk pools for aspath, requested size 270 Jul 3 09:17:40 MDT: %BGP-3-INSUFCHUNKS: Insufficient chunk pools for aspath, requested size 268 (per http://www.cisco.com/warp/public/459/35.shtml ) It started just after local Qwest routes apparently recovered from some kind of nose-dive. We're still sorting through the tables trying to find out who, thus far longest I've found is about 20. Mike

5 8

Re: Network Security Requirements draft
by George Jones 03 Jul '02

03 Jul '02

"sd" == Sean Donelan <sean(a)donelan.com> writes: sd> On 18 Jun 2002, George Jones wrote: >> We (UUNET) have an internal document that we've been using for a few >> years as the basis for tests of security features of equipment to be >> connected to our backbone. We're interested in making it public so >> that it can be improved and so that others can use it. You can view >> the current draft at: sd> Its a nice draft. One issue, not with the draft, but in general on sd> network security is the lack of a transit network security architecture sd> description. The issue of how to deal with IP source routing in this sd> draft is what reminded me of this. sd> Most network security architectures are based on the internal, perimeter, sd> external network model. Bad traffic is blocked by the permiter network sd> and never allowed to pass into the internal network. But in a public sd> service provider network traffic is separated along the data, control, sd> management model. Maintaining the separation between data, control and sd> management under all conditions is the challenge. Right. Thanks. That helps clarify the actual requirement. I was headed there > 2.1.2 Enforce Use Of Management Interfaces > > Requirement It MUST be possible to configure the device such that all > management may only be done via specific management interfaces. This > requirement SHALL NOT be satisfied using a filtering mechanism on > non-management interfaces alone, since filters do not guarantee > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > separation of management and non-management traffic > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ but had not formulated it that cleanly. The actual requirement is separation of data flow and management. OOB is just one way of achieving that (that we happen to use). I'll think it over and reword. sd> Rather than disabling IP Source Route as a global setting, I think you sd> want to scrutinize traffic passing between data and control or management sd> layers. Such as to a routing process or management interface. A source sd> routed packet in the data layer just takes an unusual path through the sd> network, but becomes a security risk if it hops into the control or sd> management layer. It would be nice to enable/block source routing (and sd> strip other IP options) on a per interface basis and drop packets with sd> unexpected options at any control or management interface. I think the general requirement here is ability to accept/reject options per/interface. Once that's in place people can decide for themselves if they want source routing (or other options). I will work on rewording. Since I announced the document here, I've added: 2.3.4 Ability To Control Service Bindings Requirement The device MUST provide a means that allows the user to specify the bindings used for all listening services. It MUST support binding to a list of net-blocks and SHOULD support configuration of binding services to particular interfaces. Justification This greatly reduces the need for complex filters. It reduces the number of ports listening, and thus the number of potential avenues of attack. It insures that only traffic arriving from legitimate addresses and/or on designated interfaces can access services on the device. Implementation The default configuration as displayed by Display All Configuration Settings should list all interfaces and all potential services along with the ports they listen to, the addresses they listen to and the interfaces they bind to. These should all be made configurable. Warnings None This would allow, for instance, SSH to be bound *only* to a loopback interface. Combine this with the ability to disable options and do filtering the loopback and I think we're getting close to an acceptable way to do device management, even in-band. Thanks, -- George M. Jones | Most important ideas are uninteresting. Most interesting CISSP,CCNA,JAPH | ideas are unimportant. Not every problem has a good UUNET | solutions. Every solution have side effects. Network Security | Quoted from Dan Geer george(a)uu.net, 2002 PGP = AB33 0916 F91E E58C B023 C768 351C 57E5 271E 69DC

1 0

Re: European packet loss average increasing
by Michael.Dillon＠radianz.com 03 Jul '02

03 Jul '02

>My non-scientific measurements (i.e. pings to well known european >sites) show an increase in packet loss to about 6%, the 10 day >average previously was less than 1%. That is similar to what the Internet Traffic Report for Europe shows at this URL http://www.internettrafficreport.com/cgi-bin/tr_graphpage.pl?score/7/Europe For those who don't know, Ebone had a policy of zero packet loss on the network 99.5% of the time and we managed to exceed this on almost all of our links. In other words, the graph of packet loss was a horizontal line with the occasional small blip. The major change in the traffic report graphs is that packet loss is six times greater after the Ebone shutdown. There was also a dip in traffic levels that partially corrected itself. Presumably the bottom of the dip represents convergence and the lack of a full recovery is partly due to organizations that were not multihomed and who had not yet found alternate providers. --Michael Dillon ex-Ebone

2 1

Re: Sprint peering policy
by George William Herbert 03 Jul '02

03 Jul '02

Perhaps we need NANOG-OldFarts mailing list? >> I think this is putting the cart before the horse. >> >> We were getting upgraded bandwidth capabilities, >> fiber put in the ground, etc from traditional Telcos >> prior to the rise of the Internet; they were finding cheaper >> ways to run phone service around. > >This is totally incorrect. Ask anyone who had been in this business from the >beginning of nineties, not late nineties. How about people who were in the business or doing engineering on WANs in the late 80s? >Telcos, while upgrading their >systems, happily pointed at the PUC filings and sold you DS1 that went two >blocks for $700 per month, that being inside a city. The local loop situation was, and in many cases remains, a major problem point; at one point, the ISP I was with was paying more for the last mile from C&W facilities in each city to our POPs than for the long haul T-1 lines forming the nationwide backbone. We dropped our total telco costs by about 10% by locating our main NOC in a building housing C&W and AT&T Longlines facilities and calling in a contractor with a concrete drill to run conduit up through our ceiling into the AT&T and C&W machine rooms... All of that said, the long distance lines were already negotiable, and getting very rapidly more so, in 1991 and 1992. >> The rise of the Internet as a telecom bandwidth demand >> driver attracted the attention of investment bankers >> and capital, which then became somewhat of a set of >> complex feedback loops (capital going into all sorts >> of internet industries, infrastructure, etc, partly >> because it appeared to be good business and partly >> because of hype). The result was that speculation >> and hype drove overcapacity. > >This again is incorrect. The rise of content attracted investment bankers. Oh? And here I am wondering why the fiber plant growth started its serious upswing in the late 80s, prior to the invention of HTTP/HTML. >> Before anyone had invested serious money in any of >> the internet infrastructure companies, people were >> building out 10 megabit, T3 backbones and were talking >> to telco gear providers about what it would take to >> do 155 megabit and 622 megabit backbones and so on >> and so on. > >This is again incorrect. The people that you are talking about were UUNET >and MCI, and we are talking 1994. That's years too late. UUNet had some 10 megabit WAN links while I was still in college, using those crazy 10meg-ethernet-into-SONNET custom hardware boxes if I remember right. T3 lines were technically available and priced by 1990; nobody had the money or customer demand to justify getting them. They were being used by telcos to upgrade their POTS services, but people were already asking what we could do with them with pure stream IP data, and looking at the OC-3 and OC-12 protocols as they developed, though that was mostly driven by LAN rather than WAN. >> It was clear to those of us in the late >> 80s and early 90s that if demand kept pulling, we needed >> to keep creating bandwidth. > >There had not been demand in 80. Neither had there been demand in the >beginning of 1990s. Strange. When I started using the Internet, *the* T-1 backbone wasn't all done yet. I got a bad name a couple of times by pulling X11 releases down from MIT at times of day that it caused noticable delay in the rest of the country's coast-to-coast IP traffic. By the time I graduated college, there were three backbones, and T-1 was no longer the hottest WAN technology in use. The demand growth curve goes back a long, long ways, Alex. >> But in no way can you claim that it took a terabuck >> in capital push to make it happen. Demand pull was >> fully operational and working just fine before >> ISPs started being snapped up by phone companies >> and visa versa, and the huge money came into play. > >Yes I can. It did take terrabucks to get this industry rolling. You are mistaking terrabucks invested in capacity push as opposed to responding to demand pull. Demand pull is fine; when there's demand, if the cost model works out, you invest to support it. Capacity push is speculation on a growth curve. We didn't need that, though everyone who likes dark fiber now is acting like a kid in a candy shop since a terabuck or so was wasted on overprovisioning it... >> Hype might have been lower and growth somewhat >> slower, but I can easily see the set of people >> who were building out backbones with T-1s and >> the early fiber links having grown them up to >> networks capable of today's traffic. > >Are you talking about Net99 here? I can't even remember what year Net99 kicked off... Must have been what, 1994? I was chatting with Joe Stroup by cellphone from my inlaws place during their pre-launch nationwide tour, and the inlaws moved in there in 1994. Yes... Cook report 3.07 summary, Sept/Oct 94, seems to confirm that timing. Announced late 94, rolled out early 95. [Side note: Gordon, for historical purposes, would it be unreasonable if we asked you to make the full reports freely available if they're older than say 5 years? 3 years? Or are you still making money off the archaic gathering dust ones ... 8-) ] 1995 is not going back nearly far enough. I'm talking about pre-CIX (remember that?). Pre-NAPs. Pre-any-telcos-routing-IP. Man, 1992-4 were busy years, though. -george william herbert gherbert(a)retro.com

2 1

Re: Sprint peering policy
by Vijay Gill 02 Jul '02

02 Jul '02

Mike Leber <mleber(a)he.net> writes: > Sprint's peers aren't equal to Sprint or each other when considered by > revenue, profitability, number of customers, or geographical coverage. A good proxy for the above is to ask the question: Do X and Y feel they derive equal value (for some value of equal) by interconnecting with each other? If they think they do, then an interconnection is set up between X and Y. However, if one party feels that they do NOT derive equal value by interconnecting with the other, than that party usually balks. X states that they would only feel equal value is derived by both parties if traffic between X and the other party is n mb/s with a ratio of p:q. Y disagrees. They do not interconnect. This causes pain. Usually the pain for one party is greater than the pain for the other, unless they are really peers of each other, in which case settlement free interconnections happen. However, if there isn't equal amounts of pain being felt on both sides, then normally the party with the more hurt tries to redress the issue. Usually this imbalance in perceived value is redressed by one of the parties offering to make up the difference by some form of a transfer of money. > This is ridiculous elitism. see above. > to make sense of their peering policy, just accept the fact that each > company has policies that they believe to be in their best interests and > omit the pretense of justifying this by the movement of heavenly bodies in > the spheres. I think we are in agreement here. /vijay

20 36

Determining the ingress interfaces
by Rajesh Talpade 02 Jul '02

02 Jul '02

Hi I asked the following question here a few weeks back, and got suggestions to use "traceroute -g," traffic filters, and assume bi-directional paths are same. How do we determine the appropriate peer AS, and hence ingress interface(s) at an ISP's border routers, for traffic arriving _from_ IP address blocks not allocated to the ISP, and destined _to_ specific IP address(es) within the ISP's network ? In other words, how do we create a mapping between non-ISP-owned address blocks and the ISP's peer ASs, such that given a non-ISP-owned address block, we can determine the peer AS thru which traffic from the address block enters the ISP's network? So do you BGP-gurus think that the following approach answers the question? I would greatly appreciate your feedback. Approach: Use data from BGP tables of as many ASs as possible. One candidate that can provide such data is the routeviews project at Univ of Oregon run by Dave Meyer. The routeviews server maintains eBGP sessions with about 63 BGP speakers, and dumps "sh ip bgp" every 2 hours. Filter out all entries from latest routeviews data with destination IP address(es) that we care about listed as "Network." May need to include larger address blocks belonging to ISP as well, since destination IP address(es) may have been aggregated into them by some ASs. For each address block filtered above, determine all ASs that are peers with the ISP's AS. This can done by creating a set of all ASs that appear immediately to left of ISP's AS for each path listed to address block, making sure there are no repetitions of ASs in the set. For each peer AS, create many-to-one mapping from source ASs to peer AS. (source ASs are all ASs on each AS path, except peer AS and ISP's AS; check that no source AS maps to multiple peer AS). Associate IP address blocks with each source AS (partly using routeviews data, partly thru ARIN d/b, etc), thus creating mapping from non-ISP-owned IP address blocks to peer ASs. Use network topology info for ISP's network to determine mapping between peer AS and ingress interface(s). Example usage of approach: Determine mapping of source ASs to peer ASs for destination IP address 4.2.101.20 on Genuity's network. (Genuity only used as an example here) Relevant data from routeviews oix-full-snapshot-2002-06-23-1000.dat in "sh ip bgp" format: Network Next Hop Path * 4.0.0.0 193.0.0.56 3333 9057 3356 1 i .... (some lines deleted) * 217.75.96.60 16150 8434 286 1 1 .... (some lines deleted) * 141.142.12.1 1224 38 10514 3356 1 i .... (some lines deleted) * 4.2.101.0/24 141.142.12.1 1224 38 6325 1 i * 202.249.2.86 7500 2497 1 i * 203.194.0.5 9942 1 i * 66.203.205.62 852 1 i * 167.142.3.6 5056 1 e * 206.220.240.95 10764 1 i * 157.130.182.254 19092 1 i * 203.62.252.26 1221 4637 1 i * 202.232.1.91 2497 1 i *> 4.0.4.90 1 i Destination IP address: 4.2.101.20 Destination AS: 1 Relevant IP address blocks: 4.0.0.0, 4.2.101.0/24 Peer ASs: 3356, 286, 6325, 2497, 9942, 852, 5056, 10764, 19092, 1221, 2497 Source ASs: 3333, 9057, 16150, 8434, 1224, 38, 10514, 7500, 1221 Mapping from source ASs to peer ASs: Peer AS Source AS 3356 3333, 9057, 10514 286 16150, 8434 6325 1224, 38 2497 7500 4637 1221 The approach is based on the observation that each AS only advertises to its peers the "best" route it knows to a specific destination network. So given an AS path to a destination network in the routeviews data, the "best" path that traffic from each of the source ASs on the path would take to the destination network can be determined. e.g. * 4.0.0.0 141.142.12.1 0 1224 38 10514 3356 1 i The "best" path for local traffic of 1224 to 4.0.0.0 is 38-10514-3356-1; "best" path for local traffic of 38 is 10514-3356-1; "best" path for local traffic of 10514 is 3356-1; Hence the peer AS to use for getting to destination network can be determined for local and transit traffic of each source AS. (Is this true?) The effectiveness of the approach is dependent on the number of views captured in the "sh IP bgp" data. i.e. the more paths that are listed for a destination network, the more mappings from source ASs to peer ASs can be determined. Thanks. Rajesh.

1 0