May 1995 - lir-wg - mailman.ripe.net

Privacy of info in IP requests [was: Re: Draft internic ip allocation doc]
by Wilfried Woeber, UniVie/ACOnet 18 May '95

18 May '95

Dear Local-IR folks! I don't know how many of us are following the PI vs. PA address discussion on CIDRD and other lists, probably quite a few - apologies to those who now get just another copy - but the message as appended below strung a cord inside me. More so after talking to people from the DE-NIC a while ago, who as I understood worried about security and privacy of the information stored at their premises. I'd be really interested in the point of view of others. I recognize that we, being a SP registry for an R&D community might have have less stringent requirements, but even then the delimiting criteria become more and more blurred these days... Wilfried. PS: Mike, apologies for not asking you before hitting the LOCAL-IR list, but I think it's really something to think about... -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Vienna University : Tel: +43 1 4065822 355 Universitaetsstrasse 7 : Fax: +43 1 4065822 170 A-1010 Vienna, Austria, Europe : NIC: WW144 -------------------------------------------------------------------------- From: Mark Kosters <markk(a)internic.net> Subject: Re: Draft internic ip allocation doc To: peter(a)agis.net (Peter Kline) Date: Wed, 17 May 1995 13:40:46 -0400 (EDT) CC: markk(a)internic.net, nanog(a)merit.edu, cidrd(a)iepg.org, kimh(a)internic.net > > What's being asked for here is what a lot of businesses might consider > proprietary or trade secret type information. There are few secrets on the > Internet, we all know, once the network is in place, but plans for expansion > and new business ought to be confidential until the day the circuit is > turned on. > > To an extent this problem can be mitigated by private IP numbering, etc., > but more and more I believe people will resist submitting this kind of > information. We are very sensitive to the privacy of this information - to the point that the we are considered within the company to be fanatical on not letting anyone who is not a part of this project be able to touch our net(s) or operations area in any way. I've requested our lawyer to have a non-disclosure agreement ready for those who would like to sign up to one before submitting confidential information. Mark -- Mark Kosters markk(a)internic.net +1 703 742 4795 Software Engineer InterNIC Registration Services --------------------------------------------------------------------------------

3 2

RE: PI VS PA ADDRESS SPACE
by 116780＠ibmmail.com 18 May '95

18 May '95

Daniel Karrenberg <Daniel.Karrenberg(a)ripe.net> wrote: > >I fully agree with you. However we get a significan number of requests >from enterprises who -at this point- do not want "Internet service" but >want to build private internets with other enterprises. This demonstrates >that there is an intrinsic value in the uniqueness of a number even >without "Internet service" with a capital I. I believe that IRs should >continue to provide this uniqueness for reasonable requests. This is very similar to the position we are in - we have obtained registered addresses in the first instance (i.e. as a solution to an immediate problem) to make interconnections to other companies' networks. However, we also wished to have unique addresses for future direct Internet access, and made this clear in our applications. Having gone through the considerable hassle of setting up an enterprise registry and renumbering our networks with registered addresses, we would take a very dim view if we were then told that our addresses were then not routable over the Internet at large! Andrew Cowie uk.royal Extra X400 information begins: Originator Name: COWIEA Org Units: LIVERPOOL Organisation: NHP Domain: GB/IBMX400/ROYINT Node.Userid: IBMX400.116780 Message Id: A70726C5.MAI Sent by Name: COWIEA Org Units: LIVERPOOL Organisation: NHP Domain: GB/IBMX400/ROYINT Node.Userid: IBMX400.116780 Free Fmt Name: COWIE, Andrew / NHP Subject: RE: PI VS PA ADDRESS SPACE Recipients Name: INET INET Domain: GB/IBMX400/IBMMAIL Node.Userid: IBMMAIL.INET Free Fmt Name: INET, INET Reply request: No

1 0

None
by SAEED KHADEMI 18 May '95

18 May '95

subscribe

1 0

Re: PI vs PA Address Space
by woody＠zocalo.net 17 May '95

17 May '95

prue(a)ISI.EDU writes: > In order to charge enough to cause behavior changes the > backbones would have to charge a lot for individual routes. The > cost for internet access is quite high right now so a charge of > say $100/year would be a drop in the bucket compared to the > other costs. I'm entering the conversation in mid-stream, so please excuse me if I reiterate something. I don't know where the discussion of funding the InterNIC after public funding runs out has gone, but it seemed to me as though something exactly like this would be a reasonable means... Rather than making it revenue-neutral and handled by backbone carriers, make it a source of funding for the InterNIC, which would scale as their load increased. A combination of very small fees for domain name registration, and a somewhat larger fee for a route. But not _too_ large a fee. :-) Both intended be be passed down the food chain as far as possible, to keep people on their best behaviour. We're a mid-sized regional, with a partially-populated B, and five or six grandfathered-in Cs, that customers from way back have had. About three months ago, we decided to clean things up, and convinced several of our customers to move from a CIDR block and some of their own Cs to subnets of our B, and then stopped routing the Cs and returned the CIDR block. In order to do this, we had to do quite a bit of persuasion, and the fact that we levied a $100/year fee for routes didn't seem to make an impression on anyone. The Little Garden, another regional here, also implemented a $100/year fee, at the same time, and they're having aboutthe same results. So I think a fee would have to be up more in the $1,000-$1,500/year range, but commensurate with that, the NIC would have to be willing to give out much larger CIDR blocks, rather than lots of little ones as they seem to now. Just my thoughts. -Bill Woodcock ________________________________________________________________________________ bill woodcock woody(a)zocalo.net woody(a)applelink.apple.com user(a)host.domain.com

1 0

Re: PI vs PA Address Space
by Sean Doran 17 May '95

17 May '95

Brian Carpenter: | > Note | > that some Internet services do not require | > globally unique addresses if accessed | > through a NAT or application layer gate- | > way/firewall. | | I think you should lose the last sentence. It invites controversy. Oh, heavens, no! Not *controversy*! Horrors and heavens to betsy. The controversy is all in the minds of several IAB members and some of their friends who are worried that someone is going to force them to use NATs and application-level gateways. If any change is to be made, I'd suggest not removing the sentence above, but adding another one: "Some IAB members and other folks think the previous sentence is a radical and controversial statement that should not be put in print." Sean. P.S.: Daniel, good work, and I appreciate the difficult issues you had to work through in order to put the draft together. Any other comments I'd have to make have been put forward by Mike Norris. - -- Sean Doran <smd(a)cesium.clock.org>

1 0

Re: PI vs PA Address Space
by prue＠ISI.EDU 17 May '95

17 May '95

Daniel, I like what you have done with this document. I believe what we need to get the market drive to force behavior we want (global routability) our backbone service providers should charge us for routing an individual net number. An individual net number is a classful net number or a CIDR block. This should be a yearly charge. The regional service providers would then pass this cost on to their customers. In the case of CIDR blocks the charge would be proportionally smaller. The regionals shouldn't be the driving force for this charging because the problem associated with PI routes doesn't affect all of the regionals the same way. There are regionals which still use default routing toward the backbone and do not carry full routing tables. I can't decide if we want class B's to be charged more than class C's. Us old timers with lots of class B's wouldn't like that. It would however encourage folks with class A's and B's that are inefficiently assigning address space to turn back expensive to keep network numbers. While I think that our backbone providers should charge us for individual routes, I do not want them to use this as a form of revenue enhancement but instead as a form of social reengineering encouraging good behavior. So the charge should be offset with a decrease in the basic charge rate. There is one problem with this scheme. In order to charge enough to cause behavior changes the backbones would have to charge a lot for individual routes. The cost for internet access is quite high right now so a charge of say $100/year would be a drop in the bucket compared to the other costs. So the market drive to use PA address space would be small. It would however have a effect on the dial-in customers who are connecting the cheapest way possible. Just my $.02 worth. Walt

1 0

Re: Draft internic ip allocation doc
by Mike Norris 17 May '95

17 May '95

For info and sorry for multiple postings. Mike ------- Forwarded Message Return-Path: owner-eot(a)ebone.net Received: by sunic.sunet.se (8.6.8/2.03) id SAA27422; Tue, 16 May 1995 18:08:47 GMT Received: from nico.aarnet.edu.au by sunic.sunet.se (8.6.8/2.03) id UAA27201; Tue, 16 May 1995 20:07:08 +0200 Received: from slam.internic.net (slam.internic.net [198.41.0.20]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id DAA00639 for <cidrd(a)iepg.org>; Wed, 17 May 1995 03:24:29 +1000 Received: (markk@localhost) by slam.internic.net (8.6.11/SLAM-1) id NAA00394; Tue, 16 May 1995 13:23:20 -0400 From: Mark Kosters <markk(a)internic.net> Message-Id: <199505161723.NAA00394(a)slam.internic.net> Subject: Draft internic ip allocation doc To: nanog(a)merit.edu, cidrd(a)iepg.org Date: Tue, 16 May 1995 13:23:19 -0400 (EDT) Cc: markk(a)internic.net, kimh(a)internic.net X-Mailer: ELM [version 2.4 PL24alpha4] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 8162 Status: O Hi As you know, our past unwritten policy was to only dole out ip space to isps that were directly connected to major routing exchange points, or those whose requirements exceeded their upstream providers desire to allocate from their own space. After numerous discussions, we have developed the following document to be our new procedure for allocating space. We hope there is consensus amongst us. If there is not too much negative commentary, the InterNIC would like to start allocating space in terms of this document very soon. Also, the document below is an interim measure in lieu of the rfc1466bis document which is under construction. Thanks Mark and Kim INTERNIC IP ALLOCATION GUIDELINES FOR INTERNET SERVICE PROVIDERS (ISP) The InterNIC Registry, under the authority of the Internet Assigned Numbers Authority, allocates blocks of address space to Internet Service Providers (ISP) for the purpose of using that space with their customers. ISPs and others not located in the InterNIC's geographical area of responsibility should contact the appropriate Regional Registry for information on how to obtain IP addresses. The following is a list of Regional Registries and National NICs that have authority to allocate IP addresses: Other Regional Registries RIPE NCC (European Registry) hostmaster(a)ripe.net APNIC (Asia Pacific Registry) hostmaster(a)apnic.net InterNIC Delegated Registries within the Americas CA*net (Canadian NIC) ipregist(a)canet.ca RNP (Brazilian Registry) gomide(a)fapq.fapesp.br To aid in the utilization of Classless Interdomain Routing (CIDR), ISPs are encouraged to request address space from their upstream provider, it must be noted that the upstream provider maintains control of the allocated block unless explicitly and contractually stated otherwise. However, CIDR blocks may be allocated directly from the InterNIC if necessary. The following guidelines have been established in an attempt to allocate address space to ISPs in a way that is fair but will address the issues of router table growth and IP address preservation. This document also details procedures that must be followed by ALL ISPs receiving address space which is then leased to their customers. ISP GUIDELINES - ---------------------------------------- Due to technical and implementation constraints on the Internet routing system and the possibility of routing overload, certain policies may need to be enforced by the major transit providers providers in order to reduce the number of globally advertised routes. These potential policies may include setting of limits on the size of prefixes added to the routing tables, filtering of non-aggregated routes, etc. Therefore, addresses obtained directly from the InterNIC (non-provider-based, also known as portable) are not guaranteed to be routable on the Internet. Therefore, if rich connectivity across the Internet is to be maintained, follow these steps when requesting address space: 1. Ask your provider 2. Ask your provider's provider 3. Ask the InterNIC registry as a last resort. Again note that if addresses are allocated directly from the InterNIC, they will be the least likely to be routable across the Internet. ISPs requesting address space from the InterNIC are required to complete the IP template reserved for ISPs. The template can be found at rs.internic.net, ftp/templates/ISP-CIDR-block.txt. [URL = ftp://rs.internic.net/ftp/templates/ISP-CIDR-block.txt] Any request judged to be lacking sufficient details will be returned to the requestor for additional information. In an effort to ensure that CIDR is implemented and utilized as efficiently as possible, the InterNIC Registry issues blocks of addresses on appropriate "CIDR-supported" bit boundaries. Network Providers will also need to be aware of the procedures that define bit boundary IP address allocation, and utilize these procedures when assigning IP address space to their respective customers. The following documents contain important information related to CIDR: RFC 1338 - Supernetting: an Address Assignment and Aggregation Strategy RFC 1482 - Aggregation Support in the NSFNET Policy-Based Routing Database RFC 1517 - Applicability Statement for the Implementation of Classless Inter-Domain Routing RFC 1518 - An Architecture for IP Address Allocation with CIDR RFC 1519 - Classless Inter-Domain Routing (CIDR) : an Address Assignment and Aggregation Strategy RFC 1520 - Exchanging Routing Information Across Provider Boundaries in the CIDR Environment Determination of CIDR block allocation size is the responsibility of the InterNIC, this allocation is based on the ISP's 3 - 6 month requirement and other information the InterNIC deems necessary. Please note, allocations are not based solely on a predicted customer base. Initial allocations will be relatively small. Subsequent allocated blocks may be increased based on utilization verification supplied to the InterNIC. Subsequent allocations of CIDR block addresses will be based on need; this need will be demonstrated based on the number of reassignment actions that have been transmitted to the InterNIC Registry. Reassignment information is to be forwarded to the InterNIC within 7 days of the assignment so that the WHOIS may be maintained efficiently. Transmission of reassignment information is also necessary for the following reasons: a) To ensure that a provider has exhausted, or is about to exhaust its current CIDR allocation such that an additional allocation is justified. b) To allow operational people to see which organization is using the network and who to contact in the event of operational/security problems, etc. c) To assist in IP allocation studies. There are two options available for tracking reassignment information: 1) Shared WHOIS Project (SWIP) Reassignment actions can be submitted by utilizing the database exchange format defined by the SWIP project. Information regarding SWIP may be obtained via anonymous FTP from rs.internic.net (198.41.0.5). The files may be found under the ftp/pub/swip directory. [ URL = ftp://rs.internic.net/ftp/pub/swip ] 2) RWhois RWhois is a distributed database for hierarchical information. Information on RWHOIS can be found at rs.internic.net, ftp/pub/rwhois. [ URL = ftp://rs.internic.net/ftp/pub/rwhois ] ALL ISPs, regardless of where they receive their CIDR blocks should either SWIP the reassignment information or establish an RWHOIS server. If SWIP is the chosen method, ISPs should register with the InterNIC as an ISP to receive a maintainer ID necessary to SWIP the reassignment information. ISPs are required to assign address space based on utilization efficiency. To this end, ISPs should have documented justification available for each assignment. The InterNIC may at any time ask to see this justification, if not available, this could impact future allocations. Any ISP whose customer has a requirement of 64 Class C's or more should forward the template to the InterNIC for review. The following information should accompany the request: Network engineering plans, including subnets and host counts, and hosts per subnet with projected utilization rates and associated confidence levels of those projects for one and two years in the future. Deployment schedule for the network, including major milestones for each subnet Network topology diagrams All ISPs receiving /16 prefix blocks from the InterNIC will be responsible for maintaining all IN-ADDR.ARPA domain records for their respective customers. The InterNIC Registry will only be responsible for the maintenance of IN-ADDR.ARPA domain records for those CIDR blocks with prefixes longer than /16 issued directly from the InterNIC. - -- Mark Kosters markk(a)internic.net +1 703 742 4795 Software Engineer InterNIC Registration Services ------- End of Forwarded Message

1 0

RE: last second action completed
by Havard Eidnes 12 May '95

12 May '95

> I do agree in general with the idea, but can we (ISP's) provide > the same level of service to those VSE's? How are we (Local > IR's) going to handle Domain Name Services for those VSE's > customers? With an emphasis on in-addr.arpa resolving? A way to solve the in-addr.arpa problem without introducing new and over-complicated mechanisms into the DNS was mentioned by Geert Jan de Groot at the last RIPE meeting, but for reasons unknown to me this was not discussed much (I think I even heard some critisism of the approach). Anyway, this message describes how I understood Geert's scheme -- I think it has some important merits worth considering. The trick is to use CNAME records and to further extend the DNS tree downwards (adding the possibility for delegation) in the in-addr.arpa tree. The following example illustrates the approach. Let's assume we have assigned the address spaces 158.36.155.0/25 158.36.155.128/26 158.36.155.192/26 to three different parties, and we wish to make it possible for the owners of these address spaces to administrate their own in-addr.arpa DNS mappings. This can be done by setting up the zone file for the 155.36.158.in-addr.arpa domain like this: $ORIGIN 155.36.158.in-addr.arpa. ; 0 NS some.name.server. 0 NS some.other.name.server. ; 128 NS some.name.server.too. 128 NS some.other.name.server.too. ; 192 NS some.third.name.server. 192 NS some.other.third.name.server. ; 1 CNAME 1.0.155.36.158.in-addr.arpa. 2 CNAME 2.0.155.36.158.in-addr.arpa. 3 CNAME 3.0.155.36.158.in-addr.arpa. ; etc. ; 129 CNAME 129.128.155.36.158.in-addr.arpa. 130 CNAME 130.128.155.36.158.in-addr.arpa. 131 CNAME 131.128.155.36.158.in-addr.arpa. ; etc. ; 193 CNAME 193.192.155.36.158.in-addr.arpa. 194 CNAME 194.192.155.36.158.in-addr.arpa. 195 CNAME 195.192.155.36.158.in-addr.arpa. ; etc. and the zone file for 0.155.36.158.in-addr.arpa might look something like this: $ORIGIN 0.155.36.158.in-addr.arpa. ; 1 PTR my.machine.name. 2 PTR his.machine.name. ; etc. This approach makes it necessary to have approx. 256 CNAME records lying around more or less permanently for each size-256 chunk you want to split up this way. Some people might view this as ugly. It is however quite easy to automatically generate the CNAMEs once and for all, given that the way the split of the address space is determined. This approach has the huge advantage that there should be no need to modify any already-deployed software, and the lookup mechanisms in the DNS do not have to be modified to acommodate this splitting of the responsibility for the address->name translation. I have been briefly presented the other proposed solutions for dealing with this probem in the DNS, and I must say that this approach with CNAMEs is far more elegant and simple than any of the other approaches. - Håvard

1 0

Address assignment tool available
by Nigel Titley 11 May '95

11 May '95

Following discussions with Mike after the Local IR WG at Rome I'm making available the address allocation tool we use here. It is based on 'tree' which uses the allocation algorithm in RFC1219. However the original 'tree' had several serious bugs and a number of limitations. We have fixed many of the bugs, added manual pages and added a number of features which we consider necessary in a production environment. Anyone is welcome to pick it up from ftp://ftp.bt.net/networking/tools/tree/tree-2.1.tar.Z Nigel -------------------------------------------------------------------- Nigel Titley --- BTnet E-mail: Nigel.Titley(a)bt.net Tel: +44 1442 237674 "Well I'm disenchanted too, we're all disenchanted." (James Thurber)

1 0

RE: last second action completed
by Alain Golan 09 May '95

09 May '95

I do agree in general with the idea, but can we (ISP's) provide the same level of service to those VSE's ? How are we (Local IR's) going to handle Domain Name Services for those VSE's customers ? With an emphasis on in-addr.arpa resolving ? /Alain On Mon, 08 May 1995 13:57:38 +0200 Daniel Karrenberg wrote: >This is to complete an action on Mike Norris to re-send >the original message concerning VSEs. > >Please refer to the archives for the discussion >that followed. > >Daniel > >------- Forwarded Message > >Date: Fri, 20 May 1994 09:57:15 +0200 >From: Daniel Karrenberg <Daniel.Karrenberg(a)ripe.net> >Sender: dfk(a)reif.ripe.net >To: Erik-Jan Bos <erik-jan.bos(a)surfnet.nl> >cc: Local IR <local-ir(a)ripe.net> >Subject: Re: Address space for individuals > > > > Erik-Jan Bos <erik-jan.bos(a)SURFnet.nl> writes: > > > This sums up my personal opinion. > > > > Great, quite along my personal opinion, but we need a consistent > > approach among all Local IRs. > >We will write something up next week. If someone else does before >us we can use that! > >My proposal would read like: > > - very small enterprises (VSEs) are those <32 hosts now > > - last resort registries will not assign address space to VSEs > > - VSEs can use private address space (RFC1697) > - VSEs are easy to renumber once they connect > - VSEs are likely to connect with one host only > > - service provider registries will assign VSEs smaller amounts > of address space than 8 bits where possible > > - service provider registries will register these smaller amounts > in the RIPE database when possible > >Rationale: > > Very many VSEs with 8 bits of address space each will use up > too much address space. > > > >Is this acceptable to all? > >Implementation: If this was accepted the NCC could accept classles >inetnums very soon even before the indexing is fully classless. > >Question: Should we publish such things as RIPE documents or just >circulate them among registries as "current practise recommendations". >I personally think we should publish them, but have heared reservations. > >Daniel > > >------- End of Forwarded Message > > ------------------------------------- E-mail: Alain Golan <alain(a)NetVision.net.il> Date: 05/08/95 Time: 16:02:40 This message was sent by Chameleon -------------------------------------

1 0