February 1996 - lir-wg - mailman.ripe.net

Re: Policy Statement on Address Space Allocations
by jnc＠ginger.lcs.mit.edu 15 Feb '96

15 Feb '96

From: Geoff Huston <G.Huston(a)aarnet.edu.au> it will be economically infeasible IF we continue with this strange system of zero dollar interconnections we use as a peering model. ... In the same way that giving away IP addresses and giving away IP routing can only be described as a very bad case of irrational behaviour, especially when the underlying resource is under stress ... then I'd also note that giving away transit is similarly a case completely irrational behaviour! All this points to a desperate need for a more realistic economic structure to be used within a number of key aspects of Internet infrastructure. Geoff, while I sort of agree with you, please note that the current "free" models in all these areas do have one real advantage, which is that they are simple. Perhaps we will need "more realistic economic structure[s]", but I can more or less guarantee you that those will be more complex as well. Also, that complexity has a cost, which also has to be figured in. (The classic example is long-distance telephone service, where the cost of creting the bill is said to be far larger than the cost of the underlying service.) Finally, given past history, I suspect that the 'Net community, and particularly the 'Net technical community, is going to have a painful transition, on the emotional level and others, to this brave new world of more commercial structures, and the inevitable technical impacts that causes. That has certainly been the case in every such step in the past... Noel

14 23

Local IR minutes, 29-30 Jan 1996
by Mike Norris 12 Feb '96

12 Feb '96

Lo and behold, the Local IR minutes which Anne had produced ages ago, but which got delayed by.... ...your humble servant, Mike Norris Local IR working group Minutes RIPE 23 Amsterdam, 30th January 1996 Chair: Mike Norris Scribe: Anne Lord At the working group meeting there were 111 attenders. 1. Preliminaries A scribe was volunteered :) and the agenda which was previously circulated to the Local IR mailing list was agreed with some modifications to the order of the discussion. The minutes will reflect the order in which items appeared on the agenda. 2. RIPE 22 2.1 Minutes The minutes of the 22nd RIPE meeting had been circulated shortly after that meeting to the Local IR mailing list for comment and minor corrections were made to the text. The minutes were then accepted. 2.2.Review of actions Action 21.3 on Daniel Karrenberg, Mike Norris To draft a recommendation on charging by local IRs until September. Action is still open. A first outline had been written but needed further study and elaboration before a draft would be sent to the list. Action 22.1 on Mike Norris and RIPE NCC To find volunteers from the Local IR working group to continue working on the revision of ripe-104++ without waiting for the publication of rfc1466++. This action was closed. In addition to the RIPE NCC, the members of the editorial committee were: Mike Norris Wilfried Woeber Sabine Dolderer Hans Petter Holen Holger Weinhardt Janos Zsako 3. Reports from registries 3.1 European Regional Registry (RIPE NCC) As the formal report from the European IR was presented in the RIPE meeting plenary, the report to the working group was brief. The shortened report was as follows: * there are now 308 local IR`s. * the predictions for the workload for 1995 were accurate. * new staff are now fully trained. * the "wait" queue is now empty ("wait" queue is non-assigned requests). * approximately one new registry per working day is now being signed up. 3.2 Other Registries There were no comments from other local registries. It was suggested that this might be a good opportunity to organise a local IR workshop in conjunction with the next meeting. There was consensus within the group that this should not be organised in parallel with the EOF meeting. An action item was taken on by the RIPE NCC. Action: RIPE NCC To organise a Local IR workshop in conjunction with RIPE24. 4. Registry Procedures 4.1 European registries - ripe-104++ The draft document "European Internet Registry, Policies and Procedures" (ftp://ftp.ripe.net/ripe/drafts/ripe-104++.{txt,ps} was previously circulated to the Local IR mailing list for comment. There has been and still was considerable discussion on the mailing list. Within the working group the aim was to isolae the salient points and to resolve any differences of opinion so that consensus could be agreed and the document progressed. The following points were discussed: Assignment procedures VSE's - - It was commented that the assignment procedures are too complicated for VSE's. The common situation being one or two externally facing hosts and the rest behind a firewall. It was suggested that the end customer does not necessarily have to complete a network number application form in such cases, but the information might be collected by the Local IR. The important point is however, that the information is archived. PI/PA address space issues - - There was a discussion about PA (Provider Aggregatable) and PI (Provider Independent) address space. If your customer insists, PI address space can be allocated. Local IR's can apply on a per case basis for PI address space from the EU IR or they can apply for a PI block. As specified in ripe-127, there will be no guarantees over the routability of such blocks assigned and using such address space is *strongly* discouraged. - - It was also suggested that ripe-104++ could include a sentence to strongly recommend that ISP's/Local IR's should *not* accept PA address space from new customers which is outside their own CIDR address space. This was agreed. - - There was a question about the existing allocation registration information in the RIPE database. It was agreed that unless a contractual arrangement existed with the customer, assignments in the RIPE database without the "status" attribute marked as PA are considered PI (Provider Independent). If local IR's can make such contractual arrangements retrospectively, then such allocations can be considered PA and marked as such. Agreed. - - Assignments of address space are only valid as long as the assignment criteria under which the original addresses were allocated are still true. Agreed. - - It was suggested that the assignment messages from the RIPE NCC could be made clearer to reflect the significance of the PA assigned address space. Renumbering - - There was some discussion around the procedures for renumbering. It was agreed, that this would be encouraged by making the procedures as easy as possible for those who had agreed to renumber and words to the effect that the size of the previous assignment would not be questioned unless the efficiency was extremely low. Reservations Policy - - It was agreed to base assignments on a 2 year plan from the requestor. No reservations policy was endorsed. Static assignments for dial up - - The document strongly discourages the use of static IP assignments for dial up service. Strongly discourages means that if a strong technical reason is given and accepted, then assignments will be made for a vastly shortened time scale - 3 months was mentioned. Assignment window anomaly - - The largest current assignment window for any local IR is /19 -1. This refers to the amount of address space that they can assign without referring first to the RIPE NCC. The proposal in ripe-104++ was to reduce this to /20. After some discussion and by way of compromise, it was agreed to make the new maximum /19 rather than /20. However, for every local IR with a /19 -1 assignment window, the current value of it's assignment window will be set to /20, with the understanding that it can be increased to a /19 based on the usual criteria (as specified in ripe-104++). It was agreed that this would come into effect immediately after the meeting. Work remaining on ripe-104++ Sections 5,6,7 and 8 remain to be drafted. Section 5 will be drafted shortly after the RIPE meeting when the editorial committee meet and the draft will be circulated to the list shortly after the meeting. 5. Registry services and charges 5.1 RIPE NCC charging model The contributors committee had agreed on a charging model for 1996. All documents relating to the Contributors Committee meetings and revenue and expenditure documents can be found in: ftp://ftp.ripe.net/ripe/new-registry/ncc-co/ 5.2 Charging by local IR's As reported under item 2.2 a draft outline had been prepared. The reviewed document will be circulated to the mailing list after the RIPE meeting, once it has been reviewed and edited. The main emphasis of the document is that it is acceptable practise for Local IR's to charge for their services. There will probably also be some wording included to the effect that any remaining Last Resort Registries should not charge for profit. 6. Tools All Local IR's were encouraged to make any tools developed for local use available to the wider community if they thought that they could be useful to others. The RIPE NCC offered to "house" these tools and make their location visible. 7. Input from other Working Groups 7.1 DNS Ripe-105 will be incorporated into ripe-104++. 7.2 Database A proposal was made to the Database WG mailing list to incorporate the functionality of <auto-inaddr(a)ripe.net> into the general database update procedure. In future, it was proposed that in-addr updates could be sent to <auto-dbm(a)ripe.net> with a special tag which could be something like "INADDRREQUEST". 8. AOB 8.1 Reverse delegation of networks for partially assigned class B networks There was a question about in-addr.arpa delegations for assigned portions of class B address space. It was suggested that either you could ask the Internic to delegate 128 zones to the Local IR or to channel this request through the RIPE NCC. It was suggested that it might be useful to include a reference to this in ripe-104++. Action: RIPE NCC To include a paragraph on procedures for the reverse delegation of partially assigned class B networks. 8.2 Handing back of networks from block 192.0.0.0/8 In a mail of the PIER working group it was proposed that by 1997 users of non-aggregatable 192 address space should consider renumbering. There was a question concerning where 192 address space should be returned to. It was suggested to return it to the RIPE NCC in all cases, and the RIPE NCC will handle it as appropriate. Any queries can be sent to the RIPE NCC <hostmaster(a)ripe.net>.

1 0

Re: Classless in-addr.arpa delegation
by Havard.Eidnes＠runit.sintef.no 09 Feb '96

09 Feb '96

> IBM AIX 4.1.4 with the shipped BIND 4.9.3 and resolver library has > the very same problem.(earlier AIX versions do not(old BIND version)). If I am not much mistaken there is an update available from IBM which fixes this problem. The beta versions of BIND 4.9.3 should be exterminated and replaced with the release version as soon as possible. - Håvard

1 0

Classless in-addr.arpa delegation
by Andres Bauman 07 Feb '96

07 Feb '96

Hi There is at least one operating system, where this method described in draft-degroot-classless-inaddr-00.txt, and supposed by RIPE, does not work. It is FreeBSD. Their resolver libarary cannot handle CNAME answers for PTR queries. In their case you just see on console something like: Feb 7 16:53:00 cache traceroute: gethostby*.gethostanswer: asked for "177.96.40.193.in-addr.arpa", got "177.128.96.40.193.in-addr.arpa" Regards, ANdres ----------------------------------------------------------- Andres Bauman | Internet: andresb(a)uninet.ee AS Nosper Ltd. | Phone: +372 6308858 Ravala pst. 10 | Fax: +372 6317984 EE0001, Tallinn, Estonia |

3 2

Re: Policy Statement on Address Space Allocations
by Paul Ferguson 07 Feb '96

07 Feb '96

At 01:11 PM 2/5/96 -0600, Alan Hannan wrote: > > Learn how to renumber. It really is possible, you know. > > -alan > So, Alan, are you volunteering to help us out in PIER? ;-) - paul

1 0

Re: Policy Statement on Address Space Allocations
by Vince Fuller 05 Feb '96

05 Feb '96

In message <199602021946.AA16364(a)mail.crl.com>, George Herbert writes: > > >> How do Pipex and Dante get global routes right now? > > > >Oh.. from a whole bunch of different places. > > > > ANS customer routes from ANS > > MCI customer routes from MCI > > SprintLink customer routes from Sprint > > Alternet customer routes from Alternet > > AUNET routes from EUNET > > ... > > > >You get the idea. > > How do they get to Barrnet? SURAnet? Etc? Suranet is at MeaEast. Barrnet is presently an MCI transit customer. Actually, the situation is a bit more complicated than this (in case anyone really wants to know). It is the case that each of the BBN Planet regions are MCI transit customers, but BBN Planet also has presence at MAE-East, FIX-East, MAE-West, and the Pennsauken NAP. We are in the process of finalizing the peering policy for BBN Planet as an integrated whole. In the near future, we will send a notice to the provider community that describes our policy and invites others to establish bi-lateral peering agreements with us. Vince Fuller, BBN Planet Network Engineering

1 0

Re: Policy Statement on Address Space Allocations
by Sean Doran 05 Feb '96

05 Feb '96

> The same ISP has said publicly that they will route /19 prefixes in our > address space: 193/8 and 194/8. The discussion is still going over > future /8s. But read the last paragraph of the policy statement! Sure, there is no filtering in 193/8 and 194/8, and as a result we have VERY poor aggregation. Consider this random cut-and-paste from 194/8. * 194.19.36.0 144.228.101.1 1 90 0 1239 701 3300 3301 5381 i * 194.19.37.0 144.228.101.1 1 90 0 1239 701 3300 3301 5381 i * 194.19.40.0 144.228.101.1 1 90 0 1239 701 3300 3301 5381 i * 194.19.54.0 144.228.101.1 1 90 0 1239 701 3300 3301 5381 i * 194.19.55.0 144.228.101.1 1 90 0 1239 701 3300 3301 5381 i * 194.19.60.0 144.228.101.1 1 90 0 1239 701 3300 3301 5381 i * 194.19.192.0 144.228.101.1 1 90 0 1239 701 3300 3301 5427 i * 194.20.0.0/15 144.228.101.1 1 90 0 1239 701 3302 ? * 194.20.8.0/21 144.228.101.1 1 90 0 1239 701 3302 3313 i * 194.20.16.0 144.228.101.1 1 90 0 1239 701 3300 ? * 194.20.19.0 144.228.101.1 1 90 0 1239 701 3300 5392 i * 194.20.20.0/22 144.228.101.1 1 90 0 1239 701 3397 ? *>i194.20.32.0/22 144.228.121.118 10 100 0 3345 i * 194.20.36.0/22 144.228.101.1 1 90 0 1239 701 3300 5392 i * 194.20.40.0/23 144.228.101.1 1 90 0 1239 701 3302 3313 ? * 194.20.42.0 144.228.101.1 1 90 0 1239 701 3302 3313 i * 194.20.44.0/22 144.228.101.1 1 90 0 1239 701 3302 3313 i * 194.20.49.0 144.228.101.1 1 90 0 1239 701 3302 3313 ? * 194.20.50.0/23 144.228.101.1 1 90 0 1239 701 3302 3313 i * 194.20.52.0/22 144.228.101.1 1 90 0 1239 701 3302 3313 i * 194.20.56.0/23 144.228.101.1 1 90 0 1239 701 3302 3313 i * 194.20.60.0/22 144.228.101.1 1 90 0 1239 701 3302 3313 i * 194.20.64.0/19 144.228.101.1 1 90 0 1239 701 3302 1267 i * 194.20.96.0/21 144.228.101.1 1 90 0 1239 701 3269 5394 i * 194.20.104.0/22 144.228.101.1 1 90 0 1239 701 3300 5392 i * 194.20.108.0/22 144.228.101.1 1 90 0 1239 701 3302 3313 i * 194.20.112.0/22 144.228.101.1 1 90 0 1239 701 3302 3313 i * 194.20.120.0/21 144.228.101.1 1 90 0 1239 701 3302 3313 ? * 194.20.136.0 144.228.101.1 1 90 0 1239 701 3300 5392 i * 194.20.137.0 144.228.101.1 1 90 0 1239 701 3300 5392 i * 194.20.138.0 144.228.101.1 1 90 0 1239 701 3300 5392 i * 194.20.139.0 144.228.101.1 1 90 0 1239 701 3300 5392 i Putting in a filter on 195.0.0.0/8 that will permit ONLY /18s and shorter prefixes is the only means I can see at this time that will make this kind of b.s. impossible. Indeed, if I put inbound filters on these announcements (and many other similar examples in 194/8) today, I would bet that within two days, everything that can be aggregated above, in Europe and by AlterNet, would be aggregated. If you have some technical means by which you can guarantee that no future allocations will result in rafts of unaggregated addresses like the random chunk cut and pasted above, then I would like to know about it. > I wonder where that rumour comes from. It is certainly not the RIPE NCC > allocation policy. this is a good time to set the record straight on this > and related things. This is *not* an attack on Tony who, I am sure, was > quoting some rumour in good faith. Yah, yah, Daniel, it's a giant conspiracy against you and Tim Bass. > 1) The initial allocation for a newly established local registry (ISP) > *always* is a /19. There will be no discussion about this. > This is fixed, cast in stone, immutable, ... you get the idea. Ah, so Mr "we need to find compromises" of the last message when referring to me not being willing to abandon the goal of an absolute maximum of 1024 prefixes only (and hopefully far fewer) in every /8 remaining in the old-style class C space is not so flexible as he wants me to be? Not that I care; I'm not prone to compromise myself, frankly. I just find the change in your tone from one message to the next awfully amusing. > Note that we make /19 allocations even though one particular ISP is > telling the world that /18 is the minimum you ought to have these days. Yup. And when you make the /19 allocations, you should tell them that in 195/8, if they are announcing a /19, a /20, a /21, a /22, a /23 or a /24, that will not work if they want to talk to SprintLink via a non-customer path. If not, well, I have this neat archive of plenty of warnings I've posted on several lists, and I work with a team of good people in program management, marketing, media relations and legal who went through this in a rather more controversial atmosphere when the filters on 206/8+ went in place, cutting off people who previously had gotten accidental connectivity using long prefixes. Filters on ranges of addresses that have not yet been allocated from is much simpler to defend on all fronts. > Our experience suggests that /18 is too much to assign to any newly > established local registry. It is too wasteful. On the other hand we > cannot live without policy #1. So we decided to stick to /19s. Well, you're the registry. I can only tell you the consequences, and that I won't lift a finger to make exceptions when people start whining, "but RIPE didn't TELL me it wouldn't work!". > It should be noted that we have started allocating hierarchically from > 193/8 when the InterNIC was still using 192/8. So we feel that we have > quite a good track record concerning routing aggregation and address > space conservation too. We consider our policy a good compromise > between aggregation and conservation and our community backs this > policy. I don't disagree that historically RIPE's allocation policy has been *excellent*. However, there are two problems: firstly, it is insufficient in and of itself to prevent things like the stuff above, and secondly there is a disconnect between allocations and announcements. So, let's kill two birds at once: first, an enforcement mechanism to push people into announcing only one prefix per allocation, and second, increase the size of the initial allocation, which will tend to push people away from RIPE as the registry of first choice. I'm sorry if that hurts your income, RIPE. Sean.

11 27

Re: Policy Statement on Address Space Allocations
by David Miller 04 Feb '96

04 Feb '96

On Sun, 4 Feb 1996, Hank Nussbacher wrote: > On Fri, 2 Feb 1996 14:29:09 -0500 (EST) you said: > > > >I would also be curious how the 60% missing is counted. > > > >If an organization places 99% of their addresses behind a firewall do all > >those not count? > > If you have a class B and use a firewall, then a /27 should be more > than is needed on the global Internet and they should use an address > from RFC1597 internally and return the /16. While that certainly sounds nice from the current context, there are other reasons for wanting unique address space. Things like mergers come to mind, as well as the expectation of better security in ipv6. --- David Miller ---------------------------------------------------------------------------- It's *amazing* what one can accomplish when one doesn't know what one can't do!

1 0

Re: Policy Statement on Address Space Allocations
by Hank Nussbacher 04 Feb '96

04 Feb '96

On Fri, 2 Feb 1996 14:29:09 -0500 (EST) you said: >On Fri, 2 Feb 1996, Howard Berkowitz wrote: > >> > > We are working on the 192.x.x.x swamp right now. >> > > Rough estimates (with much more accurate data @ NANOG) >> > > >> > > 60% - invalid or missing contact information >> > >> > This is interesting. How about a policy that says if nobody can contact >you >> > and none of your addresses are reachable, then after some period, your >> > addresses get recycled. >> > >> > >> By addresses not being reachable, are you effectively saying that any >> enterprise that does not want to connect to the Internet must use >> RFC1597 address space? >> >> Anyone have an idea how much of the address space is used for >> registered addresses of organizations that do not connect to the Internet? > >I would also be curious how the 60% missing is counted. > >If an organization places 99% of their addresses behind a firewall do all >those not count? If you have a class B and use a firewall, then a /27 should be more than is needed on the global Internet and they should use an address from RFC1597 internally and return the /16. > >Unfortunately, I don't think we can base much policy on whether or what % >of addresses are reachable from the internet. > >--- David Miller >---------------------------------------------------------------------------- > It's *amazing* what one can accomplish when > one doesn't know what one can't do! > Hank

1 0

Re: Policy Statement on Address Space Allocations
by Scott Huddle 03 Feb '96

03 Feb '96

> Scott Huddle writes: > >> Name a backbone which doesn't come into the San Francisco Bay Area. > > > >Um, all of the rest of the world's providers. > > Backbone, Scott. Backbone. You, Sprint, PSI, Alternet, > Net-99, etc. All the rest of the world's providers are getting > transit from some backbone. If all the transit backbones are in the > area the problem is merely political. They aren't... ICM, Pipex, and Dante to name three. Sprintlink may play nice and handle ICM, what do you plan to do to address the others? And for the next trick, how do you scale your solution to the next site? Does your solution require sites of all the backbone providers to be at each metropolitan exchange? Doesn't this put a limit in the number of providers that can do this? -scott

4 7