- Test - lists.nanog.org

Re: Policy Statement on Address Space Allocations
by huitema＠pax.inria.fr 29 Jan '96

29 Jan '96

At 8:04 PM 27/1/96, Hank Nussbacher wrote: >What this has to do with RIPE allocation policies is beyond >me. Everyone in the European realm suffers from extremely high >tariffs. So what? Because tariff distort topologies. In the short term, if you drew a map that used tariffs as the metric of your topology, the Atlantic would hardly be larger than the Rhine. This in itself is at cross purpose with the local implementation of CIDR, i.e. allocation of addresses to European networks from a European block by the RIPE NCC. If you look at the medium term, the perspective is even more interesting. Deregulation will gradually take place in the next three years. It will most probably result in lower tariffs for some lines, but not all, and definitely not at the same time. Take the map which I mentioned above. Imagine it printed on a fin sheet of elastic rubber, not paper. The effect of deregulation is that for the next three years the rubber will be constantly deformed, shrinking here and inflating there, and you are very lucky if you can predict where and when. To believe that this would not have some influence on addressing and internetworking is at least shortsighted. Christian Huitema

2 1

Re: Static IP addresses for Dial-up
by Lixia Zhang 29 Jan '96

29 Jan '96

> Yes. Combine this with IP over Direct-TV, where the PC address must be > synchronized between the out-bound telephone channel (semi-permanent) and > the in-bound satellite channel (permanent). Also combine with IP mobility, > which assumes that the mobile is keeping its IP address while roaming. > Also combine with IP over CATv, where a PC at home has essentially the same > requirement as a PC at work. > > All in all, at least one address per computer is a very reasonable goal, > one which we have zero reason to legislate away. I agree with Christian completely Lixia

1 0

Static IP addresses for Dial-up
by Peter Dawe 29 Jan '96

29 Jan '96

Demon Internet Services provide an IP address for every dial-up customer. Most other ISPs have taken the view that this is a waste of valuable IP space and allocate IP addresses dynamically. How should our industry respond to ISPs who behave selfishly and do not take into account the good of the network? Peter Dawe Unipalm PIPEX

5 4

Re: Static IP addresses for Dial-up
by huitema＠pax.inria.fr 29 Jan '96

29 Jan '96

At 9:36 PM 29/1/96, Robert Elz <kre(a)munnari.OZ.AU> wrote: >Incidentally, absolutely no-one seems to doubt that if I have >two systems at home, on a baby-lan, I can have a /29 or /30 >statically assigned to me (at 50% or less address effeciency), >but that if I have just one it seems I'm not supposed to have >a /32 (100% address effeciency). Weird... Yes. Combine this with IP over Direct-TV, where the PC address must be synchronized between the out-bound telephone channel (semi-permanent) and the in-bound satellite channel (permanent). Also combine with IP mobility, which assumes that the mobile is keeping its IP address while roaming. Also combine with IP over CATv, where a PC at home has essentially the same requirement as a PC at work. All in all, at least one address per computer is a very reasonable goal, one which we have zero reason to legislate away. Christian Huitema

1 0

Re: Policy Statement on Address Space Allocations
by Sean Doran 29 Jan '96

29 Jan '96

| PS: Here's Sprint's sister company's current announcement of routes | *originating* in its AS as I see them - I do hope Sprint takes the honest | path if it does refuse to carry short announcements and not route all bar | 4 of these nets, as well as a similar long list from AS1239 :-) I'm | not convinced Sprint has the moral highground here.... Moral high ground does not interest me. Working networks interest me. I have to carry the ^1239_ routes internally anyway to get my customers able to talk to each other. I don't need to carry your routes at all, unless one of my customers wants to talk to you. It's a simple thing, elegantly described by Jeff Young earlier today. It was also elegantly described by Yakov Rekhter in his CIDRD presentation of the concepts of Push and Pull. Ordinarily I would answer "filter away; we've been prepared for this kind of filter being applied against us since day #1 (although admittedly it's not going to be too pretty if someone wants to talk to you and suddenly can't. been there, done that)". As a mechanism for motivating our customers to aggregate better than they could, an important provider doing a similar sort of inbound filtering likely would be much more widely effective than the occasional Seanogram to various customers warning of doom and the possibilities of being filtered, which sometimes seem to be completely ignored. This filtering is analagous to how ANS is able to get people to register their prefixes in the RADB or run into inbound announcement filters that will stop you from talking with AOL and other ANS customers. As you note, AS 4000 is run by a different company, and you shouldn't punish them just because I'm an arrogant asshole, as I have no control over or involvement with their routing strategies. (I'm not even sure that I'm entirely popular over there. ;-) ) However, yes, they are not aggregating as well as they could be, and are announcing more-specific-routes that are completely subsumed by aggregates. Some of those folks are here and should feel free to speak for themselves. Hi guys! :) Sean. | Network Next Hop Metric LocPrf Weight Path | *> 160.214.0.0 194.68.130.50 0 4000 ? | *> 163.164.0.0 194.68.130.50 0 4000 ? | *> 194.41.63.0 194.68.130.50 0 4000 ? | *> 194.106.0.0/19 194.68.130.50 0 4000 ? | *> 194.106.32.0 194.68.130.50 0 4000 ? | *> 194.106.33.0 194.68.130.50 0 4000 ? | *> 194.106.34.0 194.68.130.50 0 4000 ? | *> 194.126.64.0/19 194.68.130.50 0 4000 ? | *> 194.133.0.0/19 194.68.130.50 0 4000 i | *> 194.133.4.0/23 194.68.130.50 0 4000 ? | *> 194.133.6.0 194.68.130.50 0 4000 ? | *> 194.133.7.0 194.68.130.50 0 4000 ? | *> 194.133.8.0 194.68.130.50 0 4000 ? | *> 194.133.15.0 194.68.130.50 0 4000 ? | *> 194.133.24.0 194.68.130.50 0 4000 ? | *> 194.133.28.0 194.68.130.50 0 4000 ? | *> 194.140.128.0/19 194.68.130.50 0 4000 ? | *> 194.140.224.0/21 194.68.130.50 0 4000 ? | *> 194.149.192.0/18 194.68.130.50 0 4000 ? | *> 194.158.0.0/20 194.68.130.50 0 4000 ? | *> 194.176.96.0/19 194.68.130.50 0 4000 ? | *> 194.204.96.0/23 194.68.130.50 0 4000 ? | *> 196.27.0.0 194.68.130.50 0 4000 ? | *> 196.27.1.0 194.68.130.50 0 4000 ? | *> 198.169.26.0 194.68.130.50 0 4000 ? | *> 204.59.0.0/16 194.68.130.50 0 4000 i | *> 204.83.37.0 194.68.130.50 0 4000 ? | *> 204.83.237.0 194.68.130.50 0 4000 ? | *> 204.83.254.0 194.68.130.50 0 4000 ? | *> 206.49.64.0/18 194.68.130.50 0 4000 i | *> 206.49.65.0 194.68.130.50 0 4000 ?

3 2

Re: Policy Statement on Address Space Allocations
by Robert A. Rosenberg 29 Jan '96

29 Jan '96

At 23:45 1/26/96, Matthew Kaufman wrote: >They >gave us a /21. We used it right up and asked for a big block again. They >gave us a /20. We argued with them about it, and they refused to budge, so >we went ahead and used it up to. Then we asked for a big block again. THAT >time they believed us. We got a /16. Had they given us the /16 the first >time, we'd have 2 fewer announcements in 204.*, and still not be quite done >using it up. InterNIC's error was not in doing what they did to you but in not aligning the 1st (or at least the 2nd) of those blocks on a RATIONAL boundary (such as /16) and giving you your CIDR Block from the front end of the range [reserving the rest for your expansion needs for a designated period of time (or until they needed to recycle the unused part of the /16 block for other users)]. Since the InterNIC assigned blocks are not going to be able to be aggregated anyway, why not just allocate them on large boundaries and leave room for expansion that will NOT introduce a new announcement when the ISP comes back for another Block. They can do Garbage Collection when they run out of the larger CIDR blocks and need to reclaim the "wasted" space (there is no downside to this method that is worse then the current system of supplying non-contiguous CIDR blocks to the same ISP [as in your case]). If you ask for a /16 to hold you for 1 or 2 years, then they should give it to you but only allow you to use the first /21 until it is full and you can justify expanding it with a /20 or to a /19 (ie: Give you a /19.5 in lieu of the /20 they gave you). If after the 1 or 2 year period is over and you are only using the first /19, then they can leave the 2nd /19 as an expansion area and reissue the other 6 /19s for other ISPs.

2 1

Re: Policy Statement on Address Space Allocations
by Sean Donelan 29 Jan '96

29 Jan '96

>" The InterNIC allocates addresses to ISPs based on the slow start > procedure as detailed in the ISP guidelines. Please utilize the /19, > once you have reassigned the /19 and SWIPped them you may request > additional address space and if the InterNIC feels you are assigning > them efficiently you may request additional address space." Because of this policy ISP's should start getting allocations from the InterNIC as soon as possible. If you get allocations from another provider, you don't gain any history with the InterNIC. All of that history goes to the provider's allocations, not yours. When you outgrow a provider (and the provider's provider), and later go to the InterNIC, you start over again with 'slow start.' I made this mistake, and it has cost me dearly over the years. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

6 6

Re: Policy Statement on Address Space Allocations
by Robert A. Rosenberg 28 Jan '96

28 Jan '96

At 0:16 1/27/96, Alan Hannan wrote: > Noone in the world complained that Windows 95 couldn't read apple IIe > diskettes. Can it read MS-DOS 5.25 Disks? If not, the Apple II problem is subsumed under the media support one <g>. Windows is very self-centered. It can't read Macintosh Disks (you have to create your Windows disks on the Mac to transfer the data since the Mac has no problems reading/writing Windows Media).

1 0

Re: Creative routing (was Re: Policy Statement ...)
by Sean Donelan 28 Jan '96

28 Jan '96

>Well, there's an alternate tactic for a tiny tiny company. I was thinking of a slightly simplier example. Nevertheless, Mr. Doran's example confirms NSP engineers are capable of all sorts of routing hacks when it is in their self-interest to do so. Even if it means introducing a /32 into their network. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

2 1

Re: Policy Statement on Address Space Allocations
by Sean Doran 27 Jan '96

27 Jan '96

This is a very interesting question involving economics of the Internet, which are still very fuzzy. I think it would make an interesting experiment. Certainly there has been lots of talk about putting something big like wuarchive.wustl.edu or ftp.uu.net into something obscure to see what breaks. There are existence proofs of sorts that popular sites can have an effect: ftp.uu.net's insistence on IN-ADDR.ARPA mappings is the one that pops into my mind immediately. Some experiments, like exp39, involved moving root nameservers into a subnet of 39/8. However, nobody has yet said, "I am Playbeing, I have content people want to get to, I can leak a /32 if I want to, and everyone will have to carry it or explain to their users why they can't get their sex-on-demand". Perhaps that's because people are afraid that there is so much other interesting content out there that disconnectivity of any sort from their customer-base would be fatal, in that users would find alternatives fairly quickly. "Click here." <click> (time passes) "Error." This happens so frequently and for so many reasons that friends of mine who are somewhat more typical dialup users would simply ignore the link or site and move on to something else.[*] There certainly is alot of competition on the content front these days. Can a big web site afford to have people thinking, "stoopid Netscape, their server is down"? Or would they be crafty and say, "all our information has now moved to _a new site_; if you get a time-out error then you should _send email to your Internet Service Provider_ telling them so"? Interesting stuff. Sean. [*] I'm different. I want to know why it doesn't work. I gather that doing traceroutes and looking at routers is atypical behaviour.

1 0