From gherbert at crl.com Thu Feb 1 00:00:34 1996 From: gherbert at crl.com (George Herbert) Date: Wed, 31 Jan 1996 15:00:34 -0800 Subject: Policy Statement on Address Space Allocations In-Reply-To: Your message of "Wed, 31 Jan 1996 14:13:06 PST." <96Jan31.141316pst.5776@cesium.clock.org> Message-ID: <199601312300.AA16462@mail.crl.com> >| 1) Provider X can announce the aggregate outside of the area & thus >| give free transit to the whole area; or >| >| 2) Provider X can announce just provider X's customers outside of the >| area, thus defeating the gain from aggregation; or >| >| 3) Provider X can be paid by everyone else in the area to provide >| transit to the entire area to where ever else Provider X connects to. > >Just to be vicious, I think I should mention option #4: >Provider X can announce the aggregate outside of the area and >drop packets bound for people in the area who do not pay >Provider X for transiting packets to them. Option 5: Provider X can announce nothing outside the area, except to people who are paying X for transit to all X-reachable sites and networks. This would work great if all the backbones touch down in the area. Customers out in the Rest of the World get transit through their backbone to all the area sites. Other regional networks or areas get transit to it via whomever they get global transit from. It only gets really touchy if few of the backbones touch down in the area. I think that the intended target area (SF Bay Area) already has everyone of interest... getting this to work would merely require getting everyone to play in the party, not having anyone bring wires to the house. They're already here. -george From Nick at Wirehub.Net Thu Feb 1 02:32:11 1996 From: Nick at Wirehub.Net (Nick Vermeulen) Date: Thu, 1 Feb 1996 02:32:11 +0100 Subject: Policy Statement on Address Space Allocations Message-ID: <199602010127.BAA16402@poindexter.wirehub.nl> Hi, imho, most multi-homed sites can do with a partial routing table; organisations who want or need to have full routing tables should put extra RAM in their backbonerouters to meet demand. When 64 MByte isn't enough anymore...buy a cisco 7500 series which can hold 128 MByte RAM. you can minimize the number of your full-routingtable routers with ebgp multihop features (for multi-homed customers) in the mean time...monitoring routing tables and notifying net-admins that advertise less efficient aggregates will help. i don't think renumbering the networks of ISP customers is a real-world solution (they will really hate you for that). ip-ip tunnels have lot's of problems and overhead too. in short: optimize aggregation within current assignments, hope that it helpes, and lobby for budgets if it doesn't. that sounds real-world to me... cheers, Nick Vermeulen Wirehub! Internet eMail : nick at wirehub.net Oudedijk 196 tel : +31 (10) 4110403 3061 AS Rotterdam fax : +31 (10) 4113556 From jnc at ginger.lcs.mit.edu Thu Feb 1 07:13:35 1996 From: jnc at ginger.lcs.mit.edu (Noel Chiappa) Date: Thu, 1 Feb 96 01:13:35 -0500 Subject: Policy Statement on Address Space Allocations Message-ID: <9602010613.AA16424@ginger.lcs.mit.edu> From: George Herbert It only gets really touchy if few of the backbones touch down in the area. Unfortunately, this is exactly the case in which geographic addressing doesn't work so well any more, and we have no way to mandate that backbones touch down. Noel From curtis at ans.net Thu Feb 1 07:19:29 1996 From: curtis at ans.net (Curtis Villamizar) Date: Thu, 01 Feb 1996 01:19:29 -0500 Subject: Policy Statement on Address Space Allocations In-Reply-To: Your message of "Wed, 31 Jan 1996 15:56:55 EST." Message-ID: <199602010619.BAA08012@brookfield.ans.net> In message , Jon Zeeff writes: > > All this discussion seems to be about work arounds for the real > problem. Namely, that the current hardware/software/protocols > can't handle what is actually a small number of routes. Absolutely. The problem stems from inadequate foresight on the part of router vendors and providers being unable to sufficiently influence router designs so that the needs of high end providers are met. There isn't a whole lot of viable choices at the high end. > Restricting announcements of new routes should be one of the last > things considered. I fully agree. It was one of the last things considered. Quite a while ago on this list it was pointed out that address leasing and coerced renumbering (its coming down to forced) was something we wanted to prepare the community for but that we were hoping to avoid. It might be that better routers and/or better methods of configuring aggregation help take some of the pressure off and change things back from "forced renumbering" to "encouraged renumbering". That hasn't happenned yet. > Here is one - for whatever reasons, we have a provider who can't seem > to correctly announce an aggregate and instead, announces several > specifics. Nobody says anything about this inefficiency - not to us or > to them. Some automated process watching for things like this and > sending an advisory email might help quite a bit. Tony Bates used to do this and send it to the list. Its not as if no one has thought of this. Curtis From GeertJan.deGroot at ripe.net Thu Feb 1 12:58:41 1996 From: GeertJan.deGroot at ripe.net (Geert Jan de Groot) Date: Thu, 01 Feb 1996 12:58:41 +0100 Subject: Policy Statement on Address Space Allocations In-Reply-To: Your message of "Thu, 01 Feb 1996 02:32:11 +0100." <199602010127.BAA16402@poindexter.wirehub.nl> Message-ID: <9602011158.AA00635@ncc.ripe.net> Hi Nick, On Thu, 1 Feb 1996 02:32:11 +0100 "Nick Vermeulen" wrote: > imho, most multi-homed sites can do with a partial routing table; > organisations who want or need to have full routing tables should put > extra RAM in their backbonerouters to meet demand. When 64 MByte > isn't enough anymore...buy a cisco 7500 series which can hold 128 > MByte RAM. you can minimize the number of your full-routingtable > routers with ebgp multihop features (for multi-homed customers) > in the mean time...monitoring routing tables and notifying net-admins > that advertise less efficient aggregates will help. If the problem is just adding a few SIMMs then people would do that. The real problem is that current routing protocols require more growth in resources such as CPU and memory than technology improvements can offer. One can roughly say that CPU's double in speed every 24 months; and as you know the Internet doubles every 10 months, thus the net grows faster than new technology can offer additional resources. The only way to cope with that is to make a 100% growth of the net result in much less than a 100% growth in resource requirements; the only mechanism of which we know it's working is hierarchical routing, which requires people to renumber if they change provider. If people don't renumber, then they will add significantly to the strain the net is seeing already and the whole discussion started because one of the US ISP's announced to implement some policy to archieve this which has very bad side effects. There are a couple of approaches to archive hierarchical routing: - prefix-length filtering as announced by said US ISP (this is by far the worst choice IMHO) - prefix-charging (this has some non-technical problems which aren't resolved yet) - community consensus on limitation of prefixes The whole issue has been discussed at the RIPE-meeting earlier this week; I don't think I saw you there. It isn't a matter of adding some SIMMs; some of the people who have brought up their concern on this are running Cisco hardware that isn't even available commercially yet, and yet need to do everything they can to keep their boxes running. They are seeing some 50% of CPU utilisation on their routers during normal operation, see the growth curve in this and know that once it reaches 100% (causing the box to roll over and die), they won't be able to buy a faster box because none is available. I have seen MCI slow-starting one of its routers by hand during the IETF in Dallas some weeks ago and it was a very scary sight. The technical background on the current problems has been discussed back and forth on the IETF CIDRD working group, and I invite you to read the mailing list archives as your suggestion and its problems has been discussed there already. I'm attaching the charter of the WG below for your convienence. Geert Jan --- CIDR Deployment (cidrd) ----------------------- Charter Current status: active working group Chair(s): Vince Fuller Tony Li Operational Requirements Area Director(s): Scott Bradner Michael O'Dell Mailing lists: General Discussion:cidrd at iepg.org To Subscribe: cidrd-request at iepg.org Archive: ftp://aarnet.edu.au/pub/mailing-lists/cidrd* Description of Working Group: The CIDR Deployment Working Group will be a forum for coordinating the deployment, engineering, and operation of classless routing protocols and procedures in the global Internet. This activity will include, but not be limited to: - Deployment of CIDR addressing and routing in the global Internet. Will include coordination of deployment of new exterior routing protocols, such as BGP4, which support CIDR. - Develop mechanisms and procedures for sharing operational information to aim the operation. - Development of procedures, policies, and mechanisms to improve the utilization efficiency of the IPv4 address space. - Work on longer-term strategies for hierarchical, CIDR-based addressing and routing. Examples include class A subnetting and provider block sub-allocation along geographical/topological boundaries as is done for 193.0.0.0 and 194.0.0.0 in Europe. Initially, this working group will be simply the reincarnation of the BGP Deployment Working Group under a new name. Goals and Milestones: Ongoing Provide forum for discussion of initial CIDR/BGP4 deployment on the global Internet. Done Establish final charter, goals, and long-term group agenda. Feb 94 Work on inter-provider coordination of routing in the CIDR environment. Apr 94 Publish initial guideline document on CIDR allocation procedures (work in progress). Apr 94 Publish guidelines for usage of variable-length subnetting. Apr 94 Start work on document of inter-provider routing coordination. Apr 94 Begin work on document of aggregation guidelines. Jul 94 Begin work on document for long-term CIDR use, including subnetting of class As. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ May 95 Jan 96 Implications of Various Address Allocation Policies for Internet Routing May 95 Oct 95 An Appeal to the Internet Community to Return Unused IP Networks (Prefixes) to the IANA May 95 New Classless in-addr.arpa delegation May 95 Dec 95 Observations on the use of Components of the Class A Address Space within the Internet Jul 95 Jan 96 Address Allocation for Private Internets Request For Comments: None to date. From jon at branch.com Thu Feb 1 15:09:49 1996 From: jon at branch.com (Jon Zeeff) Date: Thu, 1 Feb 1996 09:09:49 -0500 (EST) Subject: Policy Statement on Address Space Allocations In-Reply-To: <199602010619.BAA08012@brookfield.ans.net> from "Curtis Villamizar" at Feb 1, 96 01:19:29 am Message-ID: > > to them. Some automated process watching for things like this and > > sending an advisory email might help quite a bit. > > Tony Bates used to do this and send it to the list. Its not as if no > one has thought of this. To the list? I don't see what good that would do - it should go to the owner of the addresses and the parties announcing it. This hasn't been done. Another factoid to consider - I know of a company that has a Class C that they don't use. To my knowledge, nobody has ever even asked that they give it up. Some automated email process could do this without much effort. I (and others) have suggested forced aggregation except for routes that are specifically registered as "don't aggregate". I haven't seen any movement towards that. From edm at halcyon.com Thu Feb 1 17:57:19 1996 From: edm at halcyon.com (Ed Morin) Date: Thu, 1 Feb 1996 08:57:19 -0800 (PST) Subject: Policy Statement on Address Space Allocations In-Reply-To: Message-ID: Worse yet, I applied for several class-C's for companies years ago (before the CIDR stuff really got off the ground) that I _know_ are obsolete, but the Internic won't let me recycle them. I should have left my name on them in some way I guess. The problem is, the address listed is obsolete, the phones disconnected and in one case the contact is dead! So, how is one supposed to try and recycle in this sort of situation? On Thu, 1 Feb 1996, Jon Zeeff wrote: > > > to them. Some automated process watching for things like this and > > > sending an advisory email might help quite a bit. > > > > Tony Bates used to do this and send it to the list. Its not as if no > > one has thought of this. > > To the list? I don't see what good that would do - it should go to the > owner of the addresses and the parties announcing it. This hasn't been > done. > > Another factoid to consider - I know of a company that has a Class C that > they don't use. To my knowledge, nobody has ever even asked that > they give it up. Some automated email process could do this without > much effort. > > I (and others) have suggested forced aggregation except for routes > that are specifically registered as "don't aggregate". I haven't > seen any movement towards that. > > Ed Morin Northwest Nexus Inc. (206) 455-3505 (voice) Professional Internet Services edm at nwnexus.WA.COM From bmanning at ISI.EDU Thu Feb 1 18:38:43 1996 From: bmanning at ISI.EDU (Bill Manning) Date: Thu, 1 Feb 1996 09:38:43 -0800 (PST) Subject: Policy Statement on Address Space Allocations In-Reply-To: from "Jon Zeeff" at Feb 1, 96 09:09:49 am Message-ID: <199602011738.AA16056@zephyr.isi.edu> > Another factoid to consider - I know of a company that has a Class C that > they don't use. To my knowledge, nobody has ever even asked that > they give it up. Some automated email process could do this without > much effort. > Well, almost. The IPGR robot is, in fact, doing just that. As an aside, for my own private entertainment, I'm conducting a straw poll. If you beleive that prefix filtering is the right way to address this problem: or If you beleive that prefix charging is the right way to address this problem: or Gentle Renumbering requests will work. Your selection to me in private mail. Door prizes at NANOG for the attending participants. -- --bill From bmanning at ISI.EDU Thu Feb 1 18:39:50 1996 From: bmanning at ISI.EDU (Bill Manning) Date: Thu, 1 Feb 1996 09:39:50 -0800 (PST) Subject: Policy Statement on Address Space Allocations In-Reply-To: from "Ed Morin" at Feb 1, 96 08:57:19 am Message-ID: <199602011739.AA16093@zephyr.isi.edu> > > Worse yet, I applied for several class-C's for companies years ago (before > the CIDR stuff really got off the ground) that I _know_ are obsolete, but > the Internic won't let me recycle them. I should have left my name on them > in some way I guess. The problem is, the address listed is obsolete, the > phones disconnected and in one case the contact is dead! So, how is one > supposed to try and recycle in this sort of situation? > Let me know which ones they are, and I'll ensure they get taken care of. -- --bill From jon at branch.com Thu Feb 1 19:21:08 1996 From: jon at branch.com (Jon Zeeff) Date: Thu, 1 Feb 1996 13:21:08 -0500 (EST) Subject: Policy Statement on Address Space Allocations In-Reply-To: <199602011738.AA16056@zephyr.isi.edu> from "Bill Manning" at Feb 1, 96 09:38:43 am Message-ID: > > Another factoid to consider - I know of a company that has a Class C that > > they don't use. To my knowledge, nobody has ever even asked that > > they give it up. Some automated email process could do this without > > much effort. > > > Well, almost. The IPGR robot is, in fact, doing just that. Based on never having received such an email and knowing of several others who haven't either, I disagree. From gherbert at crl.com Thu Feb 1 20:17:16 1996 From: gherbert at crl.com (George Herbert) Date: Thu, 01 Feb 1996 11:17:16 -0800 Subject: Policy Statement on Address Space Allocations In-Reply-To: Your message of "Thu, 01 Feb 1996 01:13:35 EST." <9602010613.AA16424@ginger.lcs.mit.edu> Message-ID: <199602011917.AA27031@mail.crl.com> > It only gets really touchy if few of the backbones touch down in the area. > >Unfortunately, this is exactly the case in which geographic addressing doesn't >work so well any more, and we have no way to mandate that backbones touch down. Name a backbone which doesn't come into the San Francisco Bay Area. This is the area I want to try the idea out in. In terms of physical touchdowns, they are all in place. The only barrier is getting most of the backbones to willingly participate in the experiment. A very significant chunk of new domains and new ISPs are here, in the 415/408/510 area code regions (and 707, which is next door and could be included if we wanted...). -george william herbert gherbert at crl.com From sob at academ.com Thu Feb 1 20:30:43 1996 From: sob at academ.com (Stan Barber) Date: Thu, 1 Feb 1996 13:30:43 CST Subject: Policy Statement on Address Space Allocations Message-ID: <199602011930.NAA02218@academ.com> Well, John... I have received two of these emails. So, I disagree with you. -- Stan | Academ Consulting Services |internet: sob at academ.com Olan | For more info on academ, see this |uucp: {mcsun|amdahl}!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine. From huddle at mci.net Thu Feb 1 20:44:41 1996 From: huddle at mci.net (Scott Huddle) Date: Thu, 1 Feb 1996 14:44:41 -0500 Subject: Policy Statement on Address Space Allocations Message-ID: <199602011944.OAA16296@new6.Reston.mci.net> > > It only gets really touchy if few of the backbones touch down in the area. > > > >Unfortunately, this is exactly the case in which geographic addressing doesn't > >work so well any more, and we have no way to mandate that backbones touch down. > > Name a backbone which doesn't come into the San Francisco Bay Area. Um, all of the rest of the world's providers. > This is the area I want to try the idea out in. In terms of physical > touchdowns, they are all in place. The only barrier is getting most > of the backbones to willingly participate in the experiment. And whats your business case that'll do this? > A very significant chunk of new domains and new ISPs are here, > in the 415/408/510 area code regions (and 707, which is next door > and could be included if we wanted...). So build it. -scott From gherbert at crl.com Thu Feb 1 22:28:20 1996 From: gherbert at crl.com (George Herbert) Date: Thu, 01 Feb 1996 13:28:20 -0800 Subject: Policy Statement on Address Space Allocations In-Reply-To: Your message of "Thu, 01 Feb 1996 14:44:41 EST." <199602011944.OAA16296@new6.Reston.mci.net> Message-ID: <199602012128.AA24842@mail.crl.com> 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. >> This is the area I want to try the idea out in. In terms of physical >> touchdowns, they are all in place. The only barrier is getting most >> of the backbones to willingly participate in the experiment. > >And whats your business case that'll do this? That the number of routes seen at core routers outside the area can drop dramatically, which is certainly beneficial for the core routers in all the backbones I know of... >> A very significant chunk of new domains and new ISPs are here, >> in the 415/408/510 area code regions (and 707, which is next door >> and could be included if we wanted...). > >So build it. There is a reason I'm talking about it here. The people who will have to agree to join it at the backbone level tend to be here. If I can't convince them on the mailing list i'm wasting my time elsewhere if I start to build it. -george From asp at uunet.uu.net Thu Feb 1 22:55:30 1996 From: asp at uunet.uu.net (Andrew Partan) Date: Thu, 1 Feb 1996 16:55:30 -0500 (EST) Subject: Policy Statement on Address Space Allocations In-Reply-To: <199602012128.AA24842@mail.crl.com> from "George Herbert" at Feb 1, 96 01:28:20 pm Message-ID: > >And whats your business case that'll do this? > > That the number of routes seen at core routers outside the area can > drop dramatically, which is certainly beneficial for the core routers > in all the backbones I know of... If I participate in this, then I have to see all of the more specific routes and if I want routing to work in the rest of my backbone, then all of my routers have to see all of these routes also. Humm - where is the savings here? --asp From huddle at mci.net Thu Feb 1 23:28:00 1996 From: huddle at mci.net (Scott Huddle) Date: Thu, 1 Feb 1996 17:28:00 -0500 Subject: Policy Statement on Address Space Allocations Message-ID: <199602012228.RAA16380@new6.Reston.mci.net> > 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 From bmanning at ISI.EDU Thu Feb 1 23:29:21 1996 From: bmanning at ISI.EDU (Bill Manning) Date: Thu, 1 Feb 1996 14:29:21 -0800 (PST) Subject: Policy Statement on Address Space Allocations In-Reply-To: from "Jon Zeeff" at Feb 1, 96 01:21:08 pm Message-ID: <199602012229.AA27885@zephyr.isi.edu> > > > > Another factoid to consider - I know of a company that has a Class C that > > > they don't use. To my knowledge, nobody has ever even asked that > > > they give it up. Some automated email process could do this without > > > much effort. > > > > > Well, almost. The IPGR robot is, in fact, doing just that. > > Based on never having received such an email and knowing of > several others who haven't either, I disagree. > "All in good time my pretty..." 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 25% - in use & unwilling to renumber 15% - willing to renumber or return This is from ~6,000 delegated entries. If all goes well, we can find some new area to work on sometime in later this year. Have any suggestions? 198.x.x.x? The old /16 space? --bill From gherbert at crl.com Fri Feb 2 00:02:56 1996 From: gherbert at crl.com (George Herbert) Date: Thu, 01 Feb 1996 15:02:56 -0800 Subject: Policy Statement on Address Space Allocations In-Reply-To: Your message of "Thu, 01 Feb 1996 16:55:30 EST." Message-ID: <199602012302.AA14496@mail.crl.com> Your routers within the SF Bay Area have to see all the routes. Your routers outside the SF Bay Area can carry the /8. What's so hard about this? -george From gherbert at crl.com Fri Feb 2 00:09:59 1996 From: gherbert at crl.com (George Herbert) Date: Thu, 01 Feb 1996 15:09:59 -0800 Subject: Policy Statement on Address Space Allocations In-Reply-To: Your message of "Thu, 01 Feb 1996 17:28:00 EST." <199602012228.RAA16380@new6.Reston.mci.net> Message-ID: <199602012310.AA15971@mail.crl.com> >> 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? How do Pipex and Dante get global routes right now? >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? More likely, it limits the number of areas you can apply this idea cleanly to. Poorly-connected areas won't get such blocks. The more backbones in an area, the easier (technically and politically) to put such a block there. The question is how much you get out of the areas we can do this to... which could be quite a lot. Just the SF Bay Area is a large chunk of the Internet as a whole... it won't be forever, but it is now and its growth patterns could positively or negatively shape how other areas grow later. -george From jon at branch.com Fri Feb 2 01:15:13 1996 From: jon at branch.com (Jon Zeeff) Date: Thu, 1 Feb 1996 19:15:13 -0500 (EST) Subject: Policy Statement on Address Space Allocations In-Reply-To: <199602012229.AA27885@zephyr.isi.edu> from "Bill Manning" at Feb 1, 96 02:29:21 pm Message-ID: > 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. From iljitsch at unix1.bart.nl Fri Feb 2 01:25:04 1996 From: iljitsch at unix1.bart.nl (Iljitsch van Beijnum) Date: Fri, 2 Feb 1996 01:25:04 +0100 (MET) Subject: Policy Statement on Address Space Allocations In-Reply-To: <9602011158.AA00635@ncc.ripe.net> from "Geert Jan de Groot" at Feb 1, 96 12:58:41 pm Message-ID: <199602020025.BAA16234@unix1.bart.nl> > If the problem is just adding a few SIMMs then people would do that. > The real problem is that current routing protocols require more growth > in resources such as CPU and memory than technology improvements > can offer. One can roughly say that CPU's double in speed every 24 months; > and as you know the Internet doubles every 10 months, thus the net > grows faster than new technology can offer additional resources. This is all supposing you can only use ONE router for that specific CPU intensive task you have in mind. Now please correct me if I'm wrong, but if a router with full routing from 10 peers can't handle things, why not deploy another router and let both of them handle half the peers. > There are a couple of approaches to archive hierarchical routing: Let's turn the problem around and have a look at it from a different perspective. The problem is: too many routes. Solutions: renumber and aggregate. Renumbering should be happening as we speak... About aggregation: this isn't always possible. Many people want to be dual-homed to avoid loss of service. A few days ago, I proposed that in stead of using provider independent address space, multihomed customers should use provider aggregatable address space so that if their long prefix suffers filtering, they only suffer partial unreachability. Now here version two of my proposal: Address space that is aggregatable by TWO (maybe even more) service providers. That way at least ISP's are able to aggregate the customers they have in common. Suppose ISPs A, B and C all have 100 customers. 10% of those are multihomed. That would make for one or a few announcements for the 90 customers that aren't (maybe 10 announcements for A, B and C together). And another 15 announcements from the 15 multihomed customers. But if we create A-B, B-C and C-A aggregates, there would only be another 3 routes. This amounts to considerable savings, even if any two given ISPs only have a small amount of multi-homed customers in common. From bmanning at ISI.EDU Fri Feb 2 01:42:32 1996 From: bmanning at ISI.EDU (Bill Manning) Date: Thu, 1 Feb 1996 16:42:32 -0800 (PST) Subject: Policy Statement on Address Space Allocations In-Reply-To: from "Jon Zeeff" at Feb 1, 96 07:15:13 pm Message-ID: <199602020042.AA04358@zephyr.isi.edu> > > > > 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. > Interesting indeed. Lets see... Nobody can contact you .. is that the admin/tech contact, the administrative entity (corp, gov, agency etc) or ???? Addresses not reachable .. From which vantage point is this measuerment taken? Some period .. Like the 99 year lease on HongKong? Perhaps there is better wisdom out there on correct metrics for these values. From my limited viewpoint, the only way to recover the space is a voluntary return, based on the original allocation policies. There may be other incentives applied to facilitate the return, but strong-arm tactics and coersion, threats and hostile actions are not my favorites. I'd prefer to take almost any other action than blacklisting and hijacking. To take such actions, while it can be rationalized as a technological means to protect a networks internal stability, is presumptious and rude at best and legally indefensable at worst. Now if there are existant policies -in place-, that constrain the prefix handling, then your questions have been answered. Just my humble opinion. --bill From G.Huston at aarnet.edu.au Fri Feb 2 04:16:18 1996 From: G.Huston at aarnet.edu.au (Geoff Huston) Date: Fri, 2 Feb 1996 14:16:18 +1100 (EST) Subject: Policy Statement on Address Space Allocations In-Reply-To: from "Jon Zeeff" at Feb 1, 96 07:15:13 pm Message-ID: <199602020316.OAA26998@nico.aarnet.edu.au> > > > 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. How about a policy which says that if you fail to pay an annual amount by a due date then a process is commenced with an outcome such that your registration details expire and the associated number space is no longer registered to you. Geoff From pferguso at cisco.com Fri Feb 2 04:27:36 1996 From: pferguso at cisco.com (Paul Ferguson) Date: Thu, 01 Feb 1996 22:27:36 -0500 Subject: Policy Statement on Address Space Allocations Message-ID: <199602020326.TAA21060@lint.cisco.com> At 02:16 PM 2/2/96 +1100, Geoff Huston 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. > >How about a policy which says that if you fail to pay an annual amount >by a due date then a process is commenced with an outcome such that >your registration details expire and the associated number space is no >longer registered to you. > >Geoff > Would this process, perhaps, be associated with a route announcement charging scheme? - paul From curtis at ans.net Fri Feb 2 06:35:54 1996 From: curtis at ans.net (Curtis Villamizar) Date: Fri, 02 Feb 1996 00:35:54 -0500 Subject: Policy Statement on Address Space Allocations In-Reply-To: Your message of "Thu, 01 Feb 1996 15:09:59 PST." <199602012310.AA15971@mail.crl.com> Message-ID: <199602020536.AAA14358@brookfield.ans.net> In message <199602012310.AA15971 at mail.crl.com>, George Herbert writes: > > >> 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? > > 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. And each of these I'm sure has routes all over the 192/8 space. Curtis From HANK at VM.TAU.AC.IL Fri Feb 2 08:10:28 1996 From: HANK at VM.TAU.AC.IL (Hank Nussbacher) Date: Fri, 02 Feb 96 08:10:28 IST Subject: Policy Statement on Address Space Allocations In-Reply-To: Message of Fri, 2 Feb 1996 14:16:18 +1100 (EST) from Message-ID: <9602020612.AA15321@ncc.ripe.net> On Fri, 2 Feb 1996 14:16:18 +1100 (EST) you said: >> >> > 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. > >How about a policy which says that if you fail to pay an annual amount >by a due date then a process is commenced with an outcome such that >your registration details expire and the associated number space is no >longer registered to you. and how about a waive of the fee if you return smaller aggregates for a larger one (I started doing something similiar in Israel 3 months ago). > >Geoff > Hank From c-huegen at quad.quadrunner.com Fri Feb 2 09:37:46 1996 From: c-huegen at quad.quadrunner.com (Craig A. Huegen) Date: Fri, 2 Feb 1996 00:37:46 -0800 (PST) Subject: Policy Statement on Address Space Allocations In-Reply-To: Message-ID: On Thu, 1 Feb 1996, Jon Zeeff wrote: > > > Another factoid to consider - I know of a company that has a Class C that > > > they don't use. To my knowledge, nobody has ever even asked that > > > they give it up. Some automated email process could do this without > > > much effort. > > > > > Well, almost. The IPGR robot is, in fact, doing just that. > > Based on never having received such an email and knowing of > several others who haven't either, I disagree. Ah, but yes it is... The other day, I received the following message below asking us if we were still using the network provided to us. Since we are using it, we politely replied; I'm sure many more people than I were contacted for older networks. /cah ---- Craig A. Huegen Phone: (408) 428-8404 Communications Engineer Fax: (408) 428-8513 Electronic Data Systems / Pyramid Technology Corporation Mail Stop SJ1-1-107, 3860 North First Street, San Jose, CA 95134 --- Begin enclosed mail --- Date: Mon, 22 Jan 1996 11:46:37 -0800 From: ipgr at ISI.EDU To: chuegen at pyramid.com, ipgr at ISI.EDU Subject: Network Number Usage Survey-- 192.107.50.0 Hi, We have been asked by members of the PIER Working Group of the IETF, with the approval of the IANA and Internic, to conduct a survey of a section of the IPv4 address space. Your address appeared in the InterNIC database as the likely person to ask about the following set of network numbers: Pyramid Technology Corporation (NET-RELIANT-HV) Network number: 192.107.50.0 If you are not the correct contact, please forward this message to the right person if you can. If you are, we would like to know: Is your organization still using this address space? If you are not using it-- would you be willing to return this address to the IANA for reallocation? Your answers are important in planning future allocation of the IP address space. Thank you for your time. --- End Mail --- From nh at ireland.eu.net Fri Feb 2 12:20:33 1996 From: nh at ireland.eu.net (Nick Hilliard) Date: Fri, 2 Feb 1996 11:20:33 +0000 (GMT) Subject: Policy Statement on Address Space Allocations In-Reply-To: <199602020042.AA04358@zephyr.isi.edu> from "Bill Manning" at Feb 1, 96 04:42:32 pm Message-ID: <9602021120.aa13636@relay.Ieunet.ie> > Perhaps there is better wisdom out there on correct metrics > for these values. From my limited viewpoint, the only way > to recover the space is a voluntary return, based on the > original allocation policies. There must be some mechanism implemented whereby address space will return to the IANA after a specified period of time unless otherwise requested by the prefix holder. Otherwise what will happen is that this 60% (or some other large percentage when the figures finally settle) of the 192/8 address space will effectively be lost from the internet with no real means of retrieving it. A system like this without any garbage collection mechanism is eventually going to fill up with defunct allocations and the cruft of years past -- something which is not an option when dealing with limited address space. > as a technological means to protect a networks internal > stability, is presumptious and rude at best and legally > indefensable at worst. How are the InterNIC coping with the new domain name charging scheme? If this were successful, a similar scheme might be considered for address prefixes. The legal consequences are similar if not quite the same, and one is really no more rude or presumptious than the other. Nick From bmanning at ISI.EDU Fri Feb 2 15:07:11 1996 From: bmanning at ISI.EDU (Bill Manning) Date: Fri, 2 Feb 1996 06:07:11 -0800 (PST) Subject: Policy Statement on Address Space Allocations In-Reply-To: <9602021120.aa13636@relay.Ieunet.ie> from "Nick Hilliard" at Feb 2, 96 11:20:33 am Message-ID: <199602021407.AA25614@zephyr.isi.edu> > > for these values. From my limited viewpoint, the only way > > to recover the space is a voluntary return, based on the > > original allocation policies. > > There must be some mechanism implemented whereby address space will return > to the IANA after a specified period of time unless otherwise requested by > the prefix holder. There were a couple of methods suggested here: preemptive hijacking - voluntary return - periodic fees - Hijacking has a number of interesting problems Periodic fees will take a year or more to implement Voluntary return can be done -now-. Which method is the least stressfull and has reasonable impact on the existing routing table crunch? > > as a technological means to protect a networks internal > > stability, is presumptious and rude at best and legally > > indefensable at worst. > > How are the InterNIC coping with the new domain name charging scheme? If > this were successful, a similar scheme might be considered for address > prefixes. The legal consequences are similar if not quite the same, and > one is really no more rude or presumptious than the other. Not quite the same beast. Domain lables are -not- a finite resource. There are a wide range of viable alternatives to paying the InterNIC fees. > > Nick > -- --bill From GeertJan.deGroot at ripe.net Fri Feb 2 15:23:36 1996 From: GeertJan.deGroot at ripe.net (Geert Jan de Groot) Date: Fri, 02 Feb 1996 15:23:36 +0100 Subject: Action point 22.13: Inic & handles Message-ID: <9602021423.AA24335@ncc.ripe.net> I forgot to bring up the following action point during the meeting: * 22.13 Geert-Jan de Groot To try to follow up with the InterNIC about accepting person objects with RIPE-Handles. I received the following message from the Internic, which indicates that this problem is solved. Many thanks to Mark and the rest of the Inic bunch for fixing it. My apologies for not formally bringing it up during the meeting; too many things going on at once I guess. On the other requests (such as in-addr glue record authentication) I can report that they're working on it, and we are discussing some details which have to be resolved. Stay tuned. Geert Jan ------- Forwarded Message Date: Wed, 24 Jan 1996 12:55:11 -0500 From: Mark Kosters To: geertjan.degroot at ripe.net Subject: ripe handles Geert Jan We now will accept ripe handles for domains as well. We just finished testing and have deployed the new software. [....] From hcb at clark.net Fri Feb 2 16:48:18 1996 From: hcb at clark.net (Howard Berkowitz) Date: Fri, 2 Feb 1996 10:48:18 -0500 (EST) Subject: Policy Statement on Address Space Allocations In-Reply-To: from "Jon Zeeff" at Feb 1, 96 07:15:13 pm Message-ID: <199602021548.KAA09058@clark.net> > > > > 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? This is not a trivial question, because I am aware, at least, of an assortment of military networks who have registered addresses, connect with other arbitrary military networks with their own registered addresses, and really need some assurance that these internetworks will have unique addresses. Internetworks != Internet, so valid assignments may not be Internet reachable. From Jarmo.Oksanen at tele.fi Fri Feb 2 19:20:58 1996 From: Jarmo.Oksanen at tele.fi (Jarmo.Oksanen at tele.fi) Date: Fri, 2 Feb 1996 20:20:58 +0200 (EET) Subject: a question Message-ID: <9602021820.AA15329@karppi.dat.tele.fi> Hello, During the last RIPE-23 there were discussions about renumbering the 192 C- classes assigned in Europe. Is the renumbering just 'under' discussion or is it really going on? We have several 192 blocks, like 192.58.41 - 192.58.89 192.83.0 - 192.83.100 192.89.0 - 192.89.255 192.130.0 - 192.130.255 192.194.0 - 192.194.255 I think the blocks 192.58 and 192.83 should renumber, but the rest of the blocks are /16 routes. Is there really needs to renumber these blocks? Could somebody 'update' me about this renumbering? Thank you! Japi -- Jarmo Oksanen Telecom Finland Ltd Telephone: +358 2040 72419 Mobile phone: +358 400 737 684 Fax: +358 2040 72669 From michael at memra.com Fri Feb 2 20:27:40 1996 From: michael at memra.com (Michael Dillon) Date: Fri, 2 Feb 1996 11:27:40 -0800 (PST) Subject: Policy Statement on Address Space Allocations In-Reply-To: <199602021407.AA25614@zephyr.isi.edu> Message-ID: On Fri, 2 Feb 1996, Bill Manning wrote: > > There must be some mechanism implemented whereby address space will return > > to the IANA after a specified period of time unless otherwise requested by > > the prefix holder. > > There were a couple of methods suggested here: > > preemptive hijacking - > voluntary return - > periodic fees - > > Hijacking has a number of interesting problems > Periodic fees will take a year or more to implement > Voluntary return can be done -now-. > > Which method is the least stressfull and has reasonable impact > on the existing routing table crunch? You don't neccessarily need addresses returned to solve routing table crunch. If contact with the address owner really is impossible, then they are not using the addresses on the global Internet and therefore their addresses can be aggregated with other live addresses. The best way to do this would be to move all live addresses out of the block and just drop the whole block for the time being. Of course this means that other people would need to renumber into more router-friendly prefixes but that's what PIER is all about. Michael Dillon Voice: +1-604-546-8022 Memra Software Inc. Fax: +1-604-546-3049 http://www.memra.com E-mail: michael at memra.com From david at dirigo.mint.net Fri Feb 2 20:29:09 1996 From: david at dirigo.mint.net (David Miller) Date: Fri, 2 Feb 1996 14:29:09 -0500 (EST) Subject: Policy Statement on Address Space Allocations In-Reply-To: <199602021548.KAA09058@clark.net> Message-ID: 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? 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! From curtis at ans.net Fri Feb 2 20:43:23 1996 From: curtis at ans.net (Curtis Villamizar) Date: Fri, 02 Feb 1996 14:43:23 -0500 Subject: Policy Statement on Address Space Allocations In-Reply-To: Your message of "Fri, 02 Feb 1996 06:07:11 PST." <199602021407.AA25614@zephyr.isi.edu> Message-ID: <199602021943.OAA18515@brookfield.ans.net> In message <199602021407.AA25614 at zephyr.isi.edu>, Bill Manning writes: > > There were a couple of methods suggested here: > > preemptive hijacking - > voluntary return - > periodic fees - > > Hijacking has a number of interesting problems Bill, There is no need to call it hijacking. If an organization registered an address they are responsible for keeping the contact name up to date. If they don't announce the route, they have not provided a valid contact, and there is no way to contact them, including publishing a list on major mailing lists, then it should be safe to recover the address since every reasonable effort was made to contact them. If a route is not announced, this is a NOOP anyway. If the route is announced, go through the AS path and/or traceroute asking the provider closest to the route for a contact name. Just send a "Dear IP Provider" letter stating "This appears to be your customer but we have no way to contact them. Can you help?". Most providers have a way of contacting their customers. This should help with the 60% that can't be contacted. Yes - I know this is work, so don't take this as a complaint that you are doing something you should be, just a suggestion for dealing with this problem. Curtis From gherbert at crl.com Fri Feb 2 20:46:21 1996 From: gherbert at crl.com (George Herbert) Date: Fri, 02 Feb 1996 11:46:21 -0800 Subject: Policy Statement on Address Space Allocations In-Reply-To: Your message of "Fri, 02 Feb 1996 00:35:54 EST." <199602020536.AAA14358@brookfield.ans.net> Message-ID: <199602021946.AA16364@mail.crl.com> >> 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? There are already geographically limited large providers, they just aren't well aggregated. The transit problems have been dealt with before and will be dealt with again. -george From bmanning at ISI.EDU Fri Feb 2 20:55:34 1996 From: bmanning at ISI.EDU (bmanning at ISI.EDU) Date: Fri, 2 Feb 1996 11:55:34 -0800 (PST) Subject: Policy Statement on Address Space Allocations In-Reply-To: <199602021943.OAA18515@brookfield.ans.net> from "Curtis Villamizar" at Feb 2, 96 02:43:23 pm Message-ID: <199602021955.AA19696@zed.isi.edu> > > > In message <199602021407.AA25614 at zephyr.isi.edu>, Bill Manning writes: > > > > There were a couple of methods suggested here: > > > > preemptive hijacking - > > voluntary return - > > periodic fees - > > > > Hijacking has a number of interesting problems > > Bill, > > There is no need to call it hijacking. > > If an organization registered an address they are responsible for > keeping the contact name up to date. The kicker is, where are they keeping the data? InterNIC ? DDNnic? RIPEncc? The problem is compounded with the InterNIC and the DDNnic keeping authoritative data over the same space. Can you say "SRI connected/unconnected database problems"... sure you can. > This should help with the 60% that can't be contacted. Yes - I know > this is work, so don't take this as a complaint that you are doing > something you should be, just a suggestion for dealing with this > problem. In fact, that is exactly why a robot mailer is not a cureall. The process followed is close to yoru description. Hence a slower pace of progress than many would like. This swamp is -deep-. --bill From iljitsch at unix1.bart.nl Fri Feb 2 22:19:13 1996 From: iljitsch at unix1.bart.nl (Iljitsch van Beijnum) Date: Fri, 2 Feb 1996 22:19:13 +0100 (MET) Subject: Policy Statement on Address Space Allocations In-Reply-To: from "Michael Dillon" at Feb 2, 96 11:27:40 am Message-ID: <199602022119.WAA03293@unix1.bart.nl> > On Fri, 2 Feb 1996, Bill Manning wrote: > You don't neccessarily need addresses returned to solve routing table > crunch. If contact with the address owner really is impossible, then they > are not using the addresses on the global Internet and therefore their > addresses can be aggregated with other live addresses. I should think the case where someone is NOT using addresses but DOES announce them is quite rare... From G.Huston at aarnet.edu.au Sat Feb 3 00:31:53 1996 From: G.Huston at aarnet.edu.au (Geoff Huston) Date: Sat, 3 Feb 1996 10:31:53 +1100 (EST) Subject: Policy Statement on Address Space Allocations In-Reply-To: <199602020326.TAA21060@lint.cisco.com> from "Paul Ferguson" at Feb 1, 96 10:27:36 pm Message-ID: <199602022331.KAA12797@nico.aarnet.edu.au> Currently: 60% - invalid or missing contact information reponses: a - 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. b - How about a policy which says that if you fail to pay an annual amount by a due date then a process is commenced with an outcome such that your registration details expire and the associated number space is no longer registered to you. And comment on b Would this process, perhaps, be associated with a route announcement charging scheme? My response is no, the two are not logically associated. My response is that one way to reverse the roles and place the responsibility on the entity to reestablish contact regularly with the registry rather than have the registry valiantly try to contact the entity is to introduce payments with a default action of lapse of registration. This is an potential administrative action associated with the objective of ensuring the integrity and usefulness of the single address pool which constitutes the IP playground. Route charing schemes are a different beast - they are one possible measure which could be introduced by Internet operators intended to place pressure on the operational environment and direct this pressure toward achieving a routeable Internet by offering financial inducements to measures which decrease the number of discretely routed components of the address space. Thanks, Geoff From bmanning at ISI.EDU Sat Feb 3 01:24:20 1996 From: bmanning at ISI.EDU (bmanning at ISI.EDU) Date: Fri, 2 Feb 1996 16:24:20 -0800 (PST) Subject: Policy Statement on Address Space Allocations In-Reply-To: <199602021946.AA16364@mail.crl.com> from "George Herbert" at Feb 2, 96 11:46:21 am Message-ID: <199602030024.AA19906@zed.isi.edu> > > > >> 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? I'd bet the bbnplanet peer at mae-east, if i had a clue. Its the closest touchdown where they all meet. --bill From curtis at ans.net Sat Feb 3 01:32:40 1996 From: curtis at ans.net (Curtis Villamizar) Date: Fri, 02 Feb 1996 19:32:40 -0500 Subject: Policy Statement on Address Space Allocations In-Reply-To: Your message of "Fri, 02 Feb 1996 14:43:23 EST." <199602021943.OAA18515@brookfield.ans.net> Message-ID: <199602030032.TAA19652@brookfield.ans.net> > > If an organization registered an address they are responsible for > > keeping the contact name up to date. If they don't announce the > > route, they have not provided a valid contact, and there is no way to > > contact them, including publishing a list on major mailing lists, then > > it should be safe to recover the address since every reasonable effort > > was made to contact them. If a route is not announced, this is a NOOP > > anyway. > > Curtis, > You idiot - how could you say such a thing. What about the poor guy > who is using the net behind a firewall. ;-) > -- Curtis Curtis You ignorant bozo - I meant it has no effect on routing table size. Any attempt to recover it is a NOOP until we actually need the 192/8 space which won't be for a very long time (after A space is exhausted). ;-) -- Curtis ps - I trust its perfectly acceptable to email flaming insults when replying to yourself. From curtis at ans.net Sat Feb 3 01:44:16 1996 From: curtis at ans.net (Curtis Villamizar) Date: Fri, 02 Feb 1996 19:44:16 -0500 Subject: Policy Statement on Address Space Allocations In-Reply-To: Your message of "Fri, 02 Feb 1996 11:46:21 PST." <199602021946.AA16364@mail.crl.com> Message-ID: <199602030044.TAA19694@brookfield.ans.net> In message <199602021946.AA16364 at 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. > There are already geographically limited large providers, > they just aren't well aggregated. The transit problems have > been dealt with before and will be dealt with again. Yes and if every geographically limited provider contracted the same transit provider your proposal would have no holes in it, but they didn't. > -george Curtis From gherbert at crl.com Sat Feb 3 02:27:33 1996 From: gherbert at crl.com (George Herbert) Date: Fri, 02 Feb 1996 17:27:33 -0800 Subject: Policy Statement on Address Space Allocations In-Reply-To: Your message of "Fri, 02 Feb 1996 19:44:16 EST." <199602030044.TAA19694@brookfield.ans.net> Message-ID: <199602030127.AA03799@mail.crl.com> >Suranet is at MeaEast. Barrnet is presently an MCI transit customer. >> There are already geographically limited large providers, >> they just aren't well aggregated. The transit problems have >> been dealt with before and will be dealt with again. >Yes and if every geographically limited provider contracted the same >transit provider your proposal would have no holes in it, but they >didn't. That doesn't matter. What matters is if the geographically limited providers contracted for transit with providers that touch down in the area or not. If yes, no problem. If no, then we have a dead zone and need to figure out how to get the routing working. MCI is in the Bay Area. I don't know what we'd do for Sura; are they paying someone for generalized transit, or just peering? -george william herbert gherbert at crl.com From curtis at ans.net Sat Feb 3 03:55:08 1996 From: curtis at ans.net (Curtis Villamizar) Date: Fri, 02 Feb 1996 21:55:08 -0500 Subject: Policy Statement on Address Space Allocations In-Reply-To: Your message of "Fri, 02 Feb 1996 17:27:33 PST." <199602030127.AA03799@mail.crl.com> Message-ID: <199602030255.VAA20516@brookfield.ans.net> In message <199602030127.AA03799 at mail.crl.com>, George Herbert writes: > > MCI is in the Bay Area. I don't know what we'd do for Sura; > are they paying someone for generalized transit, or just peering? You question was how Pipex reaches Suranet. Suranet reaches the west coast via MCI. The transit issue is who transits the portion of 192/8 to providers like Pipex that just touch the East coast and don't have transit to the West coast, just access to direct customers of US providers who are at MaeEast (and for some MaeEast and Sprint NAP). A peering arrangement at a US West coast interconnect and no US transit agreement does not get you transit to a lot of places. If all of the major providers send traffic to 192/8, someone then has to provide transit to the portion of 192/8 that you can't get to from the West coast without a transit arrangement. Alternately, you could just require all of the providers who peer with someone with no transit agreement to the West coast to carry all the 192/8 prefixes for that peer only. What you then have is an agreement to do cross provider aggregation with any exchange interprovider traffic for a specific aggregate at a specific point only, with consideration given to the holes in the aggregate by every participating provider. This can be done in principle but would require more control over configuration than some providers are currently capable of. If you further scale back the idea to only providers whose router configuration is sufficiently automated to handle this, you start with the null set today, with one or two providers talking in the IETF RPS WG about being able to do this in a short while (which seems to be working out to be a large value of short:). > -george william herbert > gherbert at crl.com Curtis From HANK at VM.TAU.AC.IL Sun Feb 4 08:06:49 1996 From: HANK at VM.TAU.AC.IL (Hank Nussbacher) Date: Sun, 04 Feb 96 08:06:49 IST Subject: Policy Statement on Address Space Allocations In-Reply-To: Message of Fri, 2 Feb 1996 14:29:09 -0500 (EST) from Message-ID: <9602040608.AA25769@ncc.ripe.net> 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 From david at dirigo.mint.net Sun Feb 4 14:37:18 1996 From: david at dirigo.mint.net (David Miller) Date: Sun, 4 Feb 1996 08:37:18 -0500 (EST) Subject: Policy Statement on Address Space Allocations In-Reply-To: <199602040608.BAA03311@dirigo.mint.net> Message-ID: 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! From alan at gi.net Mon Feb 5 20:11:54 1996 From: alan at gi.net (Alan Hannan) Date: Mon, 5 Feb 1996 13:11:54 -0600 (CST) Subject: Policy Statement on Address Space Allocations In-Reply-To: <199601291642.QAA09648@diamond.xara.net> from "Alex.Bligh" at Jan 29, 96 04:42:34 pm Message-ID: <199602051911.NAA28018@westie.gi.net> ......... Alex.Bligh is rumored to have said: ] > No they don't. You can ask the RIPE NCC for special PI space to assign to ] > this customer. It seems they have a "chemical waste dump" to satisfy ] > this kind of requests from. ] Ah. That will be the "chemical waste dump" that Daniel K said ] he didn't care about whether it got routed or not (no offence ] Daniel - neither do I), and is all but unaggregatable so presumably ] Sprintlink et al. won't want to waste their CPUs routing it as well. ] What hope for a customer with those IP numbers? Learn how to renumber. It really is possible, you know. -alan From vaf at valinor.barrnet.net Mon Feb 5 21:00:29 1996 From: vaf at valinor.barrnet.net (Vince Fuller) Date: Mon, 5 Feb 96 12:00:29 PST Subject: Policy Statement on Address Space Allocations In-Reply-To: Your message of Fri, 02 Feb 1996 19:44:16 -0500 Message-ID: In message <199602021946.AA16364 at 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 From andresb at uninet.ee Wed Feb 7 16:38:28 1996 From: andresb at uninet.ee (Andres Bauman) Date: Wed, 7 Feb 1996 17:38:28 +0200 (EET) Subject: Classless in-addr.arpa delegation Message-ID: 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 at uninet.ee AS Nosper Ltd. | Phone: +372 6308858 Ravala pst. 10 | Fax: +372 6317984 EE0001, Tallinn, Estonia | From pferguso at cisco.com Wed Feb 7 17:09:18 1996 From: pferguso at cisco.com (Paul Ferguson) Date: Wed, 07 Feb 1996 11:09:18 -0500 Subject: Policy Statement on Address Space Allocations Message-ID: <199602071608.IAA29362@lint.cisco.com> 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 From GeertJan.deGroot at ripe.net Wed Feb 7 17:18:17 1996 From: GeertJan.deGroot at ripe.net (Geert Jan de Groot) Date: Wed, 07 Feb 1996 17:18:17 +0100 Subject: Classless in-addr.arpa delegation In-Reply-To: Your message of "Wed, 07 Feb 1996 17:38:28 +0200." Message-ID: <9602071618.AA08622@ncc.ripe.net> On Wed, 7 Feb 1996 17:38:28 +0200 (EET) Andres Bauman wrote: > 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" There has been a beta release of bind 4.9.3 which had this problem. That bind version has been superceded by newer beta versions, which in turn are obsoleted by 4.9.3-REL (-P1). Earlier versions of bind do not have this problem; later versions don't have it either as explained above. It is just some beta-versions that used to have this problem Since FreeBSD uses shared libraries, I think it is easy to replace the obsolete beta code with a more recent resolver. Does this solve your problem? Geert Jan From gel at aix1.danadata.dk Wed Feb 7 17:51:42 1996 From: gel at aix1.danadata.dk (Gert Elnegaard) Date: Wed, 7 Feb 1996 17:51:42 +0100 (NFT) Subject: Classless in-addr.arpa delegation In-Reply-To: Message-ID: 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)). Regards Gert Elnegaard On Wed, 7 Feb 1996, Andres Bauman wrote: > 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 From Havard.Eidnes at runit.sintef.no Fri Feb 9 14:13:05 1996 From: Havard.Eidnes at runit.sintef.no (Havard.Eidnes at runit.sintef.no) Date: Fri, 09 Feb 1996 14:13:05 +0100 Subject: Classless in-addr.arpa delegation In-Reply-To: Your message of "Wed, 7 Feb 1996 17:51:42 +0100 (NFT)" References: Message-ID: <199602091313.OAA23370@vader.runit.sintef.no> > 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 From mnorris at dalkey.hea.ie Mon Feb 12 09:38:29 1996 From: mnorris at dalkey.hea.ie (Mike Norris) Date: Mon, 12 Feb 96 08:38:29 +0000 Subject: Local IR minutes, 29-30 Jan 1996 Message-ID: <9602120838.AA27860@dalkey.hea.ie> 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 into the general database update procedure. In future, it was proposed that in-addr updates could be sent to 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 . From ed at texas.net Wed Feb 14 20:34:28 1996 From: ed at texas.net (Edward Henigin) Date: Wed, 14 Feb 1996 13:34:28 -0600 (CST) Subject: Policy Statement on Address Space Allocations In-Reply-To: <199602020042.AA04358@zephyr.isi.edu> Message-ID: On Thu, 1 Feb 1996, Bill Manning wrote: > There may be other incentives > applied to facilitate the return, but strong-arm tactics > and coersion, threats and hostile actions are not my favorites. > I'd prefer to take almost any other action than blacklisting and > hijacking. To take such actions, while it can be rationalized > as a technological means to protect a networks internal > stability, is presumptious and rude at best and legally > indefensable at worst. so what you're saying is, if a Government (agency) were to take such action, it could work..??? but then again, we don't *want* government involved... where's daddy when you need him ? Love/hate relationship to say the least. From mn at tremere.ios.com Thu Feb 15 04:51:09 1996 From: mn at tremere.ios.com (mike) Date: Wed, 14 Feb 1996 22:51:09 -0500 (EST) Subject: Policy Statement on Address Space Allocations In-Reply-To: Message-ID: On Wed, 14 Feb 1996, Edward Henigin wrote: > On Thu, 1 Feb 1996, Bill Manning wrote: > > There may be other incentives > > applied to facilitate the return, but strong-arm tactics > > and coersion, threats and hostile actions are not my favorites. > > I'd prefer to take almost any other action than blacklisting and > > hijacking. To take such actions, while it can be rationalized > > as a technological means to protect a networks internal > > stability, is presumptious and rude at best and legally > > indefensable at worst. > > so what you're saying is, if a Government (agency) were to take such > action, it could work..??? > > but then again, we don't *want* government involved... well, then there are a couple of simple rules to be observed 1) dont piss off the international community and declare Internet to US owned (like the guy who posted 'he is sick of his country to provide support for others who don't deserve it'. 2) work for seamless interoperability, and this means cast out people or corporations who do noe 3) don't implement anything that causes friction , is not backwards compatible, or deprives communities (which can be nations, networks, religious aggregations or sex maniacs) from expressing themselves *between themselves* (watch the stars!). Be conservative in what you receive, leading edge in what you provide Simple, no? Mike (this .sig is really only for id, not for anything else!) > > where's daddy when you need him ? Love/hate relationship to > say the least. > ---------------------------------------------------------- IDT Michael F. Nittmann --------- Senior Network Architect \ / (201) 928 4456 ------- (201) 928 1888 FAX \ / mn at tremere.ios.com --- V IOS From training at ripe.net Fri Feb 16 11:24:39 1996 From: training at ripe.net (RIPE NCC Training) Date: Fri, 16 Feb 1996 11:24:39 +0100 Subject: Local IR Training Courses Message-ID: <9602161024.AA08167@ncc.ripe.net> Dear Local IR's, There are still places for the Training Courses in Paris at the 26th February 1996 and in Lisbon the 25th March 1996. Please find the announcements in separate mails. If you would like to attend, please send the attached registration form to asap. If you have further questions, please don't hesitate to contact us. Kind regards, Mirjam Kuehne RIPE NCC Training Team ------------------------ From training at ripe.net Fri Feb 16 11:25:35 1996 From: training at ripe.net (RIPE NCC Training) Date: Fri, 16 Feb 1996 11:25:35 +0100 Subject: Announcement for Local IR Training Course in Paris Message-ID: <9602161025.AA08203@ncc.ripe.net> * * * Announcement * * * Local Internet Registries Training Course Date: Monday, 26th February 1996 Time: 0900 - 1700 Venue: Hyatt Hotel Airport Charles de Gaulle Paris France -------------- next part -------------- Course Audience --------------- The target audience for this course is personnel of European Local Internet Registries that contribute to the RIPE NCC. Material Covered ---------------- The course is a one day introduction on Internet name, address and routing policy registration procedures in Europe. It also teaches how to query and use the information registered for operational purposes. This includes the following material and activities: o Overview of name, address and routing registration procedures. o Responsibilities of both RIPE NCC and Local IR's to each other. o Wider context of the Delegated Registry system and relevant issues (IPv4 address depletion, CIDR) and how this relates to IP requests. o How to use the RIPE NCC Database. o Use of AS numbers, Routing Registry concepts and an introduction to using PRIDE tools. o DNS feedback on commor errors, how to request delegations, and pointers to useful tools. We again stress that this course will *not* teach Local Registries on how to run their business as Internet Service Providers. It is clearly focussed on registration procedures and the interaction between the RIPE NCC and local IR's. A detailed outline is appended below. The course itself will include lunch and will be free. This of course does not include your travel and subsitence ;-). How to Register --------------- Please send an RSVP to if you would like to attend the course. If you have previously approached us about attending this course, we ask you to confirm that you (or a colleague) will be attending. Registrations will be accepted on a first come, first served basis. If the course is oversubscribed, we will give priority to local IRs who have paid the signup fee in 1995. If it is still oversubscribed, we will accept only one person per new local registry. We will provide additional course dates in Amsterdam as necessary. If a number of local registries so request, we will present courses at other European locations. If you would like a local course or have any questions or suggestions, please do not hesitate to contact us. The RIPE NCC Training Team: Mirjam Kuehne, Daniel Karrenberg --- Course Outline -------------- For this second course, we will provide a slidebook and a reader on the day of the course, as well as electronically. Once feedback is received, it is planned to make detailed documentation available in the form of a guide much like the PRIDE guide. The program will divide the actual content into the following sections: 1. Introduction For those unfamiliar with the Delegated Internet Registry system and the RIPE NCC, this section will give a historical overview of how we have arrived at today's model of operation and why training of local IR's is a much needed activity. 2. IP Registry procedures This section will clarify the procedures between the RIPE NCC and local IR's with respect to requests for IP address space. It will take a step by step approach on how to complete documentation, the kind of information that is required, what the "handholding" procedure is, how to deal with very large requests, and very small requests, and more generally what criteria the RIPE NCC and local IR's use for their customers in the context of CIDR and IPv4 address depletion. 3. RIPE NCC Database This section will explain what the RIPE NCC Database is and how it fits into the scheme of other registry databases. It will cover how to create and update RIPE NCC Database objects and will explain how to query the database. 4. Routing Registry procedures This section will examine AS numbers, when you need them and how to request them. This will be set within the context of how AS numbers are used as part of the RIPE Routing Registry. Understanding the basic principles behind the Internet Routing Registry and how registering your policy is an important element in the global schema. This section will also include a brief introduction to the PRIDE tools and how they can be useful to you. 5. DNS procedures Where to request forward and reverse domain delegation. Which documentation should be completed. How reverse domain delegation requests are processed at the RIPE NCC (with a useful tool). We will also take a look at common errors in setting up DNS with respect to relevant RFCs and RIPE recommendations. Feedback Please! Throughout the course there will be ample chance for feedback and discussion with an emphasis for you to tell us how we can improve ;-). -------------- next part -------------- %%%%%%%%%%% PLEASE NOTE %%%%%%%%%%% Our handling of ALL course registrations is fully automated. To register for the course, please complete the registration form and send it to . Please send only the registration form in your reply and edit out all other text. Add in a value in the `box' area marked between the square brackets (i.e. "[" and "]" s). If you have any questions about the training course or your registration form, please contact us at . You will receive a notification message that your request has been processed. Many thanks, and look forward to seeing you, RIPE NCC Training Team ---------------------------------------------------------------------------- %START PART 1 - Registration 1) Your name Enter First name, Last name in FULL e.g. John Doe Mary-Beth Walton # NAME [ ] 2) Your Registry ID (format: country-code.) # REG [ ] 3) Your e-mail address # EMAIL [ ] 4) The course you plan to attend (date and location) # COURSE [ ] %END From training at ripe.net Fri Feb 16 11:26:07 1996 From: training at ripe.net (RIPE NCC Training) Date: Fri, 16 Feb 1996 11:26:07 +0100 Subject: Announcement for Local IR Training Course in Lisbon Message-ID: <9602161026.AA08216@ncc.ripe.net> * * * Announcement * * * Local Internet Registries Training Course Date: Monday, 25th March, 1996 Time: 0900 - 1700 Venue: RCCN Fundacao Calculo Cientifico Nacional (FCCN) Rede da Comunidade Cientifica Nacional Av. do Brasil, 101 1799 Lisboa Codex Portugal -------------- next part -------------- Course Audience --------------- The target audience for this course is personnel of European Local Internet Registries that contribute to the RIPE NCC. Material Covered ---------------- The course is a one day introduction on Internet name, address and routing policy registration procedures in Europe. It also teaches how to query and use the information registered for operational purposes. This includes the following material and activities: o Overview of name, address and routing registration procedures. o Responsibilities of both RIPE NCC and Local IR's to each other. o Wider context of the Delegated Registry system and relevant issues (IPv4 address depletion, CIDR) and how this relates to IP requests. o How to use the RIPE NCC Database. o Use of AS numbers, Routing Registry concepts and an introduction to using PRIDE tools. o DNS feedback on commor errors, how to request delegations, and pointers to useful tools. We again stress that this course will *not* teach Local Registries on how to run their business as Internet Service Providers. It is clearly focussed on registration procedures and the interaction between the RIPE NCC and local IR's. A detailed outline is appended below. The course itself will include lunch and will be free. This of course does not include your travel and subsitence ;-). How to Register --------------- Please send an RSVP to if you would like to attend the course. If you have previously approached us about attending this course, we ask you to confirm that you (or a colleague) will be attending. Registrations will be accepted on a first come, first served basis. If the course is oversubscribed, we will give priority to local IRs who have paid the signup fee in 1995. If it is still oversubscribed, we will accept only one person per new local registry. We will provide additional course dates in Amsterdam as necessary. If a number of local registries so request, we will present courses at other European locations. If you would like a local course or have any questions or suggestions, please do not hesitate to contact us. The RIPE NCC Training Team: Mirjam Kuehne, Daniel Karrenberg --- Course Outline -------------- For this second course, we will provide a slidebook and a reader on the day of the course, as well as electronically. Once feedback is received, it is planned to make detailed documentation available in the form of a guide much like the PRIDE guide. The program will divide the actual content into the following sections: 1. Introduction For those unfamiliar with the Delegated Internet Registry system and the RIPE NCC, this section will give a historical overview of how we have arrived at today's model of operation and why training of local IR's is a much needed activity. 2. IP Registry procedures This section will clarify the procedures between the RIPE NCC and local IR's with respect to requests for IP address space. It will take a step by step approach on how to complete documentation, the kind of information that is required, what the "handholding" procedure is, how to deal with very large requests, and very small requests, and more generally what criteria the RIPE NCC and local IR's use for their customers in the context of CIDR and IPv4 address depletion. 3. RIPE NCC Database This section will explain what the RIPE NCC Database is and how it fits into the scheme of other registry databases. It will cover how to create and update RIPE NCC Database objects and will explain how to query the database. 4. Routing Registry procedures This section will examine AS numbers, when you need them and how to request them. This will be set within the context of how AS numbers are used as part of the RIPE Routing Registry. Understanding the basic principles behind the Internet Routing Registry and how registering your policy is an important element in the global schema. This section will also include a brief introduction to the PRIDE tools and how they can be useful to you. 5. DNS procedures Where to request forward and reverse domain delegation. Which documentation should be completed. How reverse domain delegation requests are processed at the RIPE NCC (with a useful tool). We will also take a look at common errors in setting up DNS with respect to relevant RFCs and RIPE recommendations. Feedback Please! Throughout the course there will be ample chance for feedback and discussion with an emphasis for you to tell us how we can improve ;-). -------------- next part -------------- %%%%%%%%%%% PLEASE NOTE %%%%%%%%%%% Our handling of ALL course registrations is fully automated. To register for the course, please complete the registration form and send it to . Please send only the registration form in your reply and edit out all other text. Add in a value in the `box' area marked between the square brackets (i.e. "[" and "]" s). If you have any questions about the training course or your registration form, please contact us at . You will receive a notification message that your request has been processed. Many thanks, and look forward to seeing you, RIPE NCC Training Team ---------------------------------------------------------------------------- %START PART 1 - Registration 1) Your name Enter First name, Last name in FULL e.g. John Doe Mary-Beth Walton # NAME [ ] 2) Your Registry ID (format: country-code.) # REG [ ] 3) Your e-mail address # EMAIL [ ] 4) The course you plan to attend (date and location) # COURSE [ ] %END From ptacnik at ns.bohemia.net Fri Feb 16 12:37:26 1996 From: ptacnik at ns.bohemia.net (Josef Ptacnik) Date: Fri, 16 Feb 96 12:37:26 +0100 (MET) Subject: No subject Message-ID: Jedine co Vam mohu nabidnou k okamzitemu odberu je publikace InternetROADMAP - Pruvodce svetem Internetu, kterou si u nas muzete vyzvednout za 150,-Kc+DPH. From liman at sunet.se Fri Feb 16 15:33:02 1996 From: liman at sunet.se (Lars-Johan Liman) Date: Fri, 16 Feb 1996 15:33:02 +0100 Subject: No subject In-Reply-To: Your message of "Fri, 16 Feb 1996 12:37:26 +0100." Message-ID: <199602161433.PAA00545@fliptop.pilsnet.sunet.se> > Jedine co Vam mohu nabidnou k okamzitemu odberu je publikace > InternetROADMAP - Pruvodce svetem Internetu, kterou si u nas > muzete vyzvednout za 150,-Kc+DPH. Jag har tyv?rr inte en aning, men fr?ga g?rna i informationsdisken. :-) Glada h?lsningar /Liman #------------------------------------------------------------------------- # Lars-Johan Liman ! Internet: liman at sunet.se # Ebone/NORDUnet/SUNET Operations Centre ! BITNET : LIMAN at SEARN # Royal Institute of Technology, Sweden ! HTTP : //www.sunet.se/~liman # ! Voice : Int +46 8 - 790 65 60 #------------------------------------------------------------------------- From training at ripe.net Mon Feb 19 12:03:19 1996 From: training at ripe.net (RIPE NCC Training) Date: Mon, 19 Feb 1996 12:03:19 +0100 Subject: Local IR Training Course - Registration Closed Message-ID: <9602191103.AA14417@ncc.ripe.net> Dear Local IR's, The registration for the Local IR Training course in Paris, 25th February 1996 has now been closed. As the course was oversubscribed, we were regrettably, not able to accept everyone. As soon as we have scheduled additional Training Courses, we will announce them to . If your registration could not be accepted this time, please register again for the next course to confirm your continued interest in attending. If you are interested in having a course in your country for a number of local IR's, we would be happy to do this. To discuss this further, please send mail to . Kind regards, Mirjam Kuehne RIPE NCC Training Team From training at ripe.net Mon Feb 19 12:14:10 1996 From: training at ripe.net (RIPE NCC Training) Date: Mon, 19 Feb 1996 12:14:10 +0100 Subject: Registration Closed - Correction Message-ID: <9602191114.AA14532@ncc.ripe.net> Dear Local IR's, In my last mail was a mistake. I meant: The registration for the Local IR Training course in Paris, 26th February 1996 ^^^^ has now been closed. [...] We don't give courses on Sunday yet ;-) Sorry about the confusion, Mirjam Kuehne RIPE NCC From TGEUDENS at pwinet.upj.com Wed Feb 21 22:42:48 1996 From: TGEUDENS at pwinet.upj.com (TGEUDENS at pwinet.upj.com) Date: Wed, 21 Feb 1996 16:42:48 -0500 Subject: access discussion database Message-ID: <12b3e870@pwinet.upj.com> I assume this is the way to auto-register to this discussion database. In case I misunderstaood anything, I apologize Regards, Tony Geudens Pharmacia & Upjohn Inc. From philip at buckley.demon.co.uk Tue Feb 27 11:52:31 1996 From: philip at buckley.demon.co.uk (Philip Buckley) Date: Tue, 27 Feb 1996 11:52:31 +0100 Subject: Additional questions Message-ID: <825416592.16145.0@buckley.demon.co.uk> Hello Dave, Thanks for the files on the requirements. We'll be incorporating these over the next few days. Please find attached the additional questions that I mentioned last Friday. If you have any problems I'm at home to-day (01525 373136) and at Sema tomorrow (0171 830 4281). Thanks. Philip -------------- next part -------------- A non-text attachment was scrubbed... Name: DSADDQS.DOC Type: application/octet-stream Size: 12800 bytes Desc: not available URL: -------------- next part -------------- Philip Buckley ---------------------------------------------------------------------------- ----------- Internet: philip at buckley.demon.co.uk (MIME attachments) Internet: Philip.Buckley at mail.sema.co.uk (uuencoded attachments) Voicebank: 0171 706 5260 (+44 171 706 5260) Telephone: Sema Group: 0171 830 4281 (+44 171 830 4281) NHS-wide networking programme Central Communications Management Group: 0121 454 6166 (+44 121 454 6166) From philip at buckley.demon.co.uk Tue Feb 27 12:38:03 1996 From: philip at buckley.demon.co.uk (Philip Buckley) Date: Tue, 27 Feb 1996 12:38:03 +0100 Subject: Sorry for previous email - Wrong destinations !!! Message-ID: <825416853.17217.0@buckley.demon.co.uk> Dear all, Sorry for the last email - the only person who didn't get it was Dave Stead! Philip Philip Buckley ---------------------------------------------------------------------------- ----------- Internet: philip at buckley.demon.co.uk (MIME attachments) Internet: Philip.Buckley at mail.sema.co.uk (uuencoded attachments) Voicebank: 0171 706 5260 (+44 171 706 5260) Telephone: Sema Group: 0171 830 4281 (+44 171 830 4281) NHS-wide networking programme Central Communications Management Group: 0121 454 6166 (+44 121 454 6166) From training at ripe.net Thu Feb 29 16:50:07 1996 From: training at ripe.net (RIPE NCC Training) Date: Thu, 29 Feb 1996 16:50:07 +0100 Subject: Local IR Training Course - Registration Closed Message-ID: <9602291550.AA24952@ncc.ripe.net> Dear Local IR's, The registration for the Local IR Training course in Lisbon, 25th March 1996 has now been closed. As the course was oversubscribed, we were regrettably, not able to accept everyone. As soon as we have scheduled additional Training Courses, we will announce them to . If your registration could not be accepted this time, please register again for the next course to confirm your continued interest in attending. If you are interested in having a course in your country for a number of local IR's, we would be happy to do this. To discuss this further, please send mail to . Kind regards, Naomi de Bruyn RIPE NCC Training Team From GeertJan.deGroot at ripe.net Thu Feb 1 19:28:31 1996 From: GeertJan.deGroot at ripe.net (Geert Jan de Groot) Date: Thu, 01 Feb 1996 19:28:31 +0100 Subject: New mailing list: tld-admin@ripe.net Message-ID: <9602011828.AA08699@ncc.ripe.net> As requested at the last RIPE meeting, I have set up a new mailing list for TLD administrators: tld-admin at ripe.net. This is a closed mailing list; per request of the WG, only people who are maintaining a TLD are allowed to subscribe. As we need to verify requestor's affiliation, please send subscription requests to tld-admin-request at ripe.net including the name of the TLD you are administering. Please keep in mind that we need to verify things by hand and therefore some time may lapse processing requests. The maillist is archived, but again only privately so if you need a copy of the archive, please ask tld-admin-request at ripe.net. I'd like the TLD-admins to consider if they feel it is a good idea that the parties listed in RFC1591 (IANA, APNIC, InterNIC and RIPE NCC) are also allowed to subscribe or if the list should be restricted to TLD admins only. Let's party! Geert Jan