- NANOG - lists.nanog.org

Re: links on the blink
by William Allen Simpson 15 Nov '95

15 Nov '95

> From: "Mike O'Dell" <mo(a)uunet.uu.net> > by the time we get anything that new installed, it had better be able > to go a lot faster than OC12 or we'll be right back in the same pot > on the day we put it in service. > I disagree with this position. The fibers installed to do OC-12 will certainly do OC-48 when it becomes available. And the next x4 jump as well. > Native packets over SONET is indeed The Right Thing To Do. > As author of PPP over SONET/SDH, I get queries from time to time about when this will be available. There are at least 2 unannounced products in development. I expect they will begin delivering OC-12 next summer, and OC-48 the following year. > The more interesting question is what is the difference between > switching and routing, and what is the role of each as the networks > grow in size, capacity, and bitrate. (And no, I don't mean cells.) > I also expect that _routing_ at that rate is the hard part. Maybe being a link kind of guy, the link parts just look easier to me. I expect _switching_ at that rate to be even harder than routing if they are cells; the times are just too short. But the usual packet size isn't much more than 3-6 cells, so the scale isn't as much better as we would hope. We tried to make 1500 bytes ubiquitous with PPP, but too much host software still uses 512 bytes anytime it thinks the destination is "remote", even when there is 1500 bytes end-to-end. Bill.Simpson(a)um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

2 1

Routing wars pending?
by Hank Nussbacher 15 Nov '95

15 Nov '95

I would like to bring up the matter of address ownership. Here is the story: ILAN acts as registry of last resort in Israel. It owns and assigns IP addresses in the 192.114-118.0.0 address range. These 5 blocks are owned by ILAN (AS378). Over the years, many IP addresses have been assigned - in the past to individual companies and more lately CIDR blocks to local ISPs. ILAN takes a �50 one time fee to register the IP address for the requestor. Company FOO which has a class C decides to leave their current ISP - D. They move to ISP - N - which has their own CIDR block and does the good thing - forces the company to renumber and then informs ILAN that the company has relinquished the old class C. This allows me to reclaim IP addresses and form blocks of /22 and /21 which previously could not be done. All good up to this point. ISP D says since they paid the �50 registration fee - they now own the class C forever. I tell them that that is not the case and that the address was registered in the name of the company and not in the name of the ISP. They reassign the class C to other customers - at the same time I have reassigned the reallocated class C to some one else. Their upstream service provider - U - says to D: "Please inform me to delete the networks below from your access-list per Ilan request. It is a policy of U to only delete networks per U's customer request and not anyone else. This issues needs to resolved by you and ILAN and once it has been resolved, please let me what networks to delete." Ok so far. I trust D and ILAN will resolve this peacefully. But what about cases where it cannot be resolved peacfully? The routing tables are gonna start growing. ILAN withdrew 190 routes on August 1st when it started announcing 192.114.0.0/16 and 192.115.0.0/16. Now, since D is announcing a more specific (/24) - it turns out that his route supercedes my larger aggregate. How to combat it? I would have to start reannouncing all my specifics so as to counter-override his /24. What were to happen if this ISP picked a chunk of unused IP address space in my blocks, and started advertising it as /24s? His upstream service provider - U - just accepts it and starts routing. We maintain the authoritative source for IP address ownership in whois.ripe.net. We found that the upstream service provider - U - went and added a route object in whois.ra.net for the /24s (there are 2 cases now) - basely solely on the word of ISP D. So now there is a contradiction between the two databases. Now if D were to start advertising many unallocated /24s, I would be in a big problem and have to restart announcing my specifics. What are people doing in this area today? Are we going to start seeing routing wars? Thanks, Hank Nussbacher Israel

2 1

Re: Routing wars pending?
by Akira Kato 15 Nov '95

15 Nov '95

At the moment, JPNIC -- the Japanese country NIC -- charges 20,000 yen (about $200) for one-time transaction fee to register the IP address for the requestor. JPNIC delegates address blocks to Japanese NSPs, and the address assignment from the delegated space by a NSP is charged 10,000 yen (about $100). This discount is intended to cover NSP's cost to talk with not-well-knowledged-clients and cost to submit their request form in emails. JPNIC does not monitor how much NSPs actually charges their clients. When a client changes its NSP, JPNIC does not currently charge the one-time registeration fee to the client unless the new address space is not larger than before. This is because these change requests are usually submitted in emails and JPNIC people do not have to talk the requester nor have to create a form from snail-mailed or faxed applications. -- Akira Kato, WIDE Project

1 0

unscribe
by Steve Dix 15 Nov '95

15 Nov '95

unsubscribe Steve Dix (sdix(a)nic.ddn.mil)

1 0

Re: Routing wars pending?
by Sean Doran 15 Nov '95

15 Nov '95

Hm, routing wars. Fun stuff. Expect much heat on this shortly... :( Essentially, the point-of-appeal would probably be the IEPG or NANOG mailing lists, and who would get believed would probably get worked out after some protracted flameage, consultations with lawyers, and arguments about how routing registry technologies will save the planet from routing wars, pollution, and too-strong coffee. My own personal advice wrt people who are thinking of using others' address space without permission is pretty simple: don't do it, you'll lose. Sean.

2 1

Re: Motion for a new POST NSF AUP
by Robert Moskowitz 15 Nov '95

15 Nov '95

At 10:56 AM 10/16/95 +0100, Havard.Eidnes(a)runit.sintef.no wrote: >> Another suggestion was that SMTP headers always contain the >> IP address. I've seen this in quite a few mailers already. >> All we need is a slight modification to the SMTP Receipt >> standard. This could be a Best Current Practice, quickly >> published! > >Hm, this is already covered. RFC 1123 says: > > 5.2.8 DATA Command: RFC-821 Section 4.1.1 >... > * The FROM field SHOULD contain both (1) the name of the > source host as presented in the HELO command and (2) a > domain literal containing the IP address of the source, > determined from the TCP connection. Big deal. Since it is only SHOULD many mailers, like CDC's MAIL*Hub profess not to support it, as it is not a MUST... Robert Moskowitz Chrysler Corporation (810) 758-8212

1 0

Re: AS690 advisory update
by ser-rr＠ser.bbnplanet.net 14 Nov '95

14 Nov '95

Oh, and sorry about that spam. *cringe* _k

1 0

Who has OC3 backbones?
by Michael Dillon 14 Nov '95

14 Nov '95

On the IAP list the question recently came up whether any NorthAm NSP's currently have operational OC3 backbones (or portions thereof). I would appreciate it if somebody would post their current status (and future rollout schedules?) regards OC3 on either this list or on iap(a)vma.cc.nd.edu To subscribe, send subscribe IAP to the address listserv(a)vma.cc.nd.edu Thanks. Michael Dillon Voice: +1-604-546-8022 Memra Software Inc. Fax: +1-604-542-4130 http://www.memra.com E-mail: michael(a)memra.com

1 0

Re: AS690 advisory update
by The BBN NACR Account 14 Nov '95

14 Nov '95

Greetings- Your request has been received by our IP addressing staff, and will be attended to as soon as possible. The staff member in charge of your request will notify you when it is completed. Due to the volume of mail processed, it may take up to one business week to complete your request. Requests for new IP addresses may take longer to process. If you have a question about your request, or need to refer to it later, your NACR ticket number is SER1114-162451. Please include this id in any mail pertaining to this request. Additionally, if you are looking for any of our forms, please check our ftp server at ftp://ftp.ser.bbnplanet.net/pub/forms -NACR

1 0

Re: AS690 advisory update
by ser-rr＠ser.bbnplanet.net 14 Nov '95

14 Nov '95

What happens if policy changes for those AS'es? i.e., AS279 decides to no longer route to AS690 via AS3561, but changes to route through AS701. (*grin*) How is new policy to be determined, either for new ASes, or for existing ones that drastically change their routing policies? _k > Elliot, > > Ignore the advisory. If AS2 is the origin, we will route traffic > for that particular prefix/masklen using the most common policy > already in place for routes in AS2. > > If the common policy is for us to send traffic destined for AS2 > via our peer AS1, we will continue to do so for the new prefix/masklen. > > Steve > > > > > > After this time, AS690 advisories will be ignored. Policy toward > > > routes registered in the IRR will be based solely on origin AS. > > > The origin AS will be expanded to the set of route objects registered > > > for that origin AS; the resulting list of prefixes will be used in > > > generating router configurations, as today. > > > > in the case of AS#1 routing AS#2, suppose AS#2 sent in the route object > > and list themselves as the origin, and put AS#1 in the advisory. in the > > new scenario, will ANS now only allow routes coming via the ASN in the > > ORIGIN field? i.e. will AS#2 have to change the ANS in the origin field > > to AS#1 so ANS knows where to look for for the routes? > > > > - elliot alby/sprintlink implementation > >

2 1