October 2002 - lir-wg - mailman.ripe.net

Goodbye All
by Stephen Burley 15 Oct '02

15 Oct '02

Hi Just a quick note to say thankyou and bye. My job at the struggling telecoms giant Worldcom has come to an end, what they will do not i do not know but then thats Worldcoms approach to everything i suppose. Anyway thankyou for the enjoyable times i have spent talking to you all and for enriching my life. I have had a great time being part of this ever changing community and i wish you all the best for the future. I do not know where i go from here but then maybe its time to change my path in life, recently i have found my self unable to keep abreast of most of the issues so my lack of mails will probably not be missed. I will miss all of you who knew me and no doubt some of you will breath a sigh of relief. Anyway i wish the community all the success in the world and please do not loose sight of the RIPE ideals that this community was built on. Hope our paths cross again some day. Regards, Stephen Burley Former UUNET EMEA Hostmaster.

1 0

assignment policy
by pop3.tjantik.dk 15 Oct '02

15 Oct '02

Hey everybody We have a customer who has build a rather large ethernet MAN network in there local area (potentialy 50.000 privat customers), they have chosen us to provide the internet capacity for there solution. Now the issue of Fixed IP addresses comes up. The solution they have designed for there network, requires a /30 for each customes that requests a fixed IP address. Is this "allowed" in current RIPE policies ? Nicolaj Ottsen

3 2

RE: [lir-wg] Reserved addresses
by Daniel N. Rasmussen 11 Oct '02

11 Oct '02

Hi Peter, > Could someone explain to me what the nets marked "reserved" > in for example > http://kmserv.com/testbed/ip-space.txt are expected to be > used for? Special stuff or RIR address space? Well, looking at the above link and comparing it to the most recent one (http://www.iana.org/assignments/ipv4-address-space), I would say the latter. Eg. 068-079/8 IANA - Reserved Sep 81 now 068/8 ARIN Jun 01 069/8 ARIN Aug 02 070-079/8 IANA - Reserved Sep 81 > Peter B. Juul, > Uni·C (PBJ255-RIPE) Regards, Daniel Rasmussen dk.uunet

9 10

Mailing List Software Migration
by RIPE NCC WebMaster 10 Oct '02

10 Oct '02

Dear Mailing List Subscriber, The RIPE NCC will change its mailing list software from "majordomo" to "mailman" on 17 October 2002. The new mailing list software will give users more options to manage their subscriptions to the RIPE and RIPE NCC mailing lists. Additionally, this change is being made to ensure stability and continuity of mailing list management and archiving. The new mailing list software will give users a number of options using a web interface: - Subscribing and Unsubscribing to mailing lists - Reviewing general information about the mailing lists - Viewing subscriptions to mailing lists - Temporarily disabling mail delivery - Choosing between regular and digests of mailing list postings - Acknowledgements to postings The web interface will be located at the following URL: http://www.ripe.net/mailman/ As well as using the web interface, mailing list users can manage their subscription and retrieve information by using an e-mail client. Further details on this are available at the above URL. Please note that if mailing list users are already subscribed to one or more mailing lists, they do not have to take any action. Messages can still be sent to the regular mailing lists addresses and subscriptions will not have to be re-confirmed. If you have any questions about this migration, please feel free to send an e-mail to <webmaster(a)ripe.net> Kind Regards, Jeroen Bet RIPE NCC Mailing List Moderation

1 0

Re: [lir-wg] Reserved addresses
by Michael.Dillon＠radianz.com 10 Oct '02

10 Oct '02

>In a current project a number of addresses is needed for closed IP >communication between a number of institutions. That is an internetwork, often called an internet. The Internet Protocol (IP) was invented specifically for this purpose. >The logical choice for >this is some RFC1918-space, but certain people fear that no matter what >1918-addresses we may choose they may be in use internally in the involved >networks and thus unavailable to this project. Those people are right. The logical choice for IP addresses on an internet is to use addresses from the RIR. It doesn't matter whether this internet is connected to the Internet or not. >Someone else, however, picked up on the fact that there's a large number >of addresses just marked "reserved" by IANA, and they probably are not in >use, so why don't we just grab e.g. 82.0.0.0/8? Because all of the organizations in your internet will also be connected to the Internet as well. When the 82/8 space starts to be used on the Internet, each organization will have to deal with routing and/or reachability issues in their internal networks. In order to avoid this kind of mess, the IETF set up the IANA so that organizations building TCP/IP networks could register for globally unique IP addresses. Even though the mechanisms have changed since then (CIDR and the RIRs) the basic principle still holds. There is no requirement that an organization must allow everyone to access their network in order to justify globally registered IP space. It is better for you to register the number of addresses that you actually need rather than hijack the entire 82/8 range. -- Michael Dillon

1 0

ICANN Reform
by Hans Petter Holen 10 Oct '02

10 Oct '02

Dear lir-wg, On the topic if the ICANN reform http://www.icann.org/committees/evol-reform/blueprint-20jun02.htm With reference to the RIR joint statement of June 20th http://www.ripe.net/ripencc/about/regional/rir-icann-statement-20020620.html and the response from the ICANN reform committee: http://www.icann.org/committees/evol-reform/update-16sep02.htm and the discussion at the RIPE meeting I would like to ask the lir-wg members to study theese statements and actively participate in the ICANN reform process. Either by: 1) Discussion on this list, and with clear advice to your AC members on how you wish to advice us to act. or 2) submitting your oppinion directly to the ERC http://www.icann.org/committees/evol-reform/blueprint-20jun02.htm Best Regards, Hans Petter Holen lir-wg chair

5 10

RIR Blueprint for Evolution and Reform of Internet Address Management
by Axel Pawlik 10 Oct '02

10 Oct '02

Dear all, The Regional Internet Registries (RIR) have published a document entitled, "RIR Blueprint for Evolution and Reform of Internet Address Management." This document is available at: http://www.ripe.net/ripencc/about/regional/nrr-blueprint-20021009.html The RIRs have also sent this document to the Chair of the ICANN Board, the Chair of the ICANN Evolution and Reform Committee, and the ICANN President and CEO. The RIRs welcome feedback from the Internet addressing community on the contents of this document. To facilitate discussion focused on this document, a dedicated mailing list has been established and is open to all interested parties. Subscription information for the NRR-Blueprint mailing list is available at: http://www.arin.net/mailing_lists/index.html All comments sent to the NRR-Blueprint mailing list will be publicly archived at the following location. http://www.arin.net/mailing_lists/nrr-blueprint/index.html kind regards, Axel Pawlik Managing Director RIPE NCC

1 0

Correction..pay ICANN $17,476,267 *each year* for EACH /8.
by Jim Fleming 09 Oct '02

09 Oct '02

Correction..pay ICANN $17,476,267 *each year* for EACH /8. ----- Original Message ----- From: "Jim Fleming" <JimFleming(a)ameritech.net> To: <lir-wg(a)ripe.net> Sent: Wednesday, October 09, 2002 10:45 AM Subject: Paying Market Value for Address Space Leases...pay ICANN $1,7476,267 *each year* for EACH /8. > ISPs sell (lease) a "virtual product" called an IP address for $10 to $15 per month. > > ARIN should get one month's revenue on an annual basis. > > ICANN should get one month's revenue on an annual basis. > ==== > > A /8 is 16,777,216 such products. At an average of $12.50 per month, that is > $209,715,200 from the ISP to ARIN each year. > > ARIN can then pay ICANN $1,7476,267 *each year* for EACH /8. > > http://www.iana.org/assignments/ipv4-address-space > 063/8 ARIN Apr 97 > 064/8 ARIN Jul 99 > 065/8 ARIN Jul 00 > 066/8 ARIN Jul 00 > 067/8 ARIN May 01 > 068/8 ARIN Jun 01 > 069/8 ARIN Aug 02 > 199/8 ARIN - North America May 93 > 200/8 ARIN - Central and South America May 93 > 204/8 ARIN - North America Mar 94 > 205/8 ARIN - North America Mar 94 > 206/8 ARIN - North America Apr 95 > 207/8 ARIN - North America Nov 95 > 208/8 ARIN - North America Apr 96 > 209/8 ARIN - North America Jun 96 > 216/8 ARIN - North America Apr 98 > ===== > > > Jim Fleming > 2002:[IPv4]:000X:03DB:...IPv8 is closer than you think...IPv16 is even closer... > http://www.ietf.com > http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt > http://ipv8.dyndns.tv > http://ipv8.dyns.cx > http://ipv8.no-ip.com > http://ipv8.no-ip.biz > http://ipv8.no-ip.info > http://ipv8.myip.us > http://ipv8.dyn.ee > http://ipv8.community.net.au > >

1 0

Reserved addresses
by Peter B. Juul 09 Oct '02

09 Oct '02

This may not be the best list for posting this question in, but I've been unable to figure out which one to use instead. Please forgive me. In a current project a number of addresses is needed for closed IP communication between a number of institutions. The logical choice for this is some RFC1918-space, but certain people fear that no matter what 1918-addresses we may choose they may be in use internally in the involved networks and thus unavailable to this project. My knee-jerk response as a somewhat conscientious networker is "So what? We'll just have to pick some addresses not presently in use. There should be plenty. Yes, it will take coordination, but that's life." Someone else, however, picked up on the fact that there's a large number of addresses just marked "reserved" by IANA, and they probably are not in use, so why don't we just grab e.g. 82.0.0.0/8? I really want to avoid this and stay within the RFC1918-nets, but I need a good response. Could someone explain to me what the nets marked "reserved" in for example http://kmserv.com/testbed/ip-space.txt are expected to be used for? Special stuff or RIR address space? Peter B. Juul, Uni·C (PBJ255-RIPE)

1 0

Re: Re: [lir-wg] ICANN Reform
by Sabine Dolderer/Denic 08 Oct '02

08 Oct '02

Hello, maybe I can come in the debate with some practical experiences from the ccTLD side as we are suffering some problems since some time. On 08.10.2002 21:53 Hans Petter Holen <hpholen(a)tiscali.no> wrote: > > > > --On 8. oktober 2002 11:06 +0900 Randy Bush <randy(a)psg.com> wrote: > > > to paraphrase from a private conversation: > > > > note that the iana function is the only formal link between the > > ietf and the registries, and we should be careful of what we break. > > the ietf does not want to start writing rir (and N other fiefdoms) > > consideration sections in rfcs. > > So a design criteria for whatever scenario we are looking at should be to > maintain this link. (ie co-organisation of the IETF-IANA function and the > RIR-IANA function. > > > there are a number of different roles of the iana function, what > > different parties need from the iana function, and their/our > > respective relationships to and through the iana. the rir position > > seems to be to break away from the iana. the ietf position, such > > as it is, seems more to coordinate the non-dnso iana functions in > > the iana in a way well detached from icann dnso politics. > > I think the root of the concern is the strong link between the percived de > facto policy makers (ICANN staff) and the IANA staff. > > I belive this concern is only true if it is in fact so that ICANN staff > makes policy desicions (or suggests them to the board who ratifies them > without public process) that is unfortunately done on a regular basis at least in the ccTLD area and you should be aware that unless there are no contractual safegards they may try it for the RIRs. > > The cause for this concern is that while some of us see something as a > policy desicion others don't. > > The very fundamental question is perhaps: > - Are there any desicions at all to be taken by ICANN which does not > require an open transparent process ? In the domain area ICANN have took a lot of decisions in the past without using an open and transparent process even when ccTLDs told them not to do so and - and - that was the biggest surprise to me - nobody - including the ICANN board - cares. It starts with the complete ignorance in how ccTLDs want to organize themselves, unilateral changes in the IANA policies, blocking of necesarry technical changes, developing a new CC-structure wihin ICANN without taking into account the work of the ccSO ... > > Looking carefully at that question I realise that it can be generalized: > - Are there any desicions at all to be taken by X which does not require an > open transparent process ? > > where X = {ICANN, RIPE NCC, ARIN, APNIC, IETF, ASO, ...} > > and this it is where it gets interesting: the question should be if X=ICANN thinks they don't need an open & transparent process has Y= (RIPE NCC, ARIN, APNIC, IETF, ASO, ...) the possibility to stop them to implement policies just by doing. > - the concern is exactly the same at both sides of the ICANN vs RIR > discussion... > > -hph > > Sabine -- Sabine Dolderer DENIC eG Wiesenhüttenplatz 26 D-60329 Frankfurt eMail: Sabine.Dolderer(a)denic.de Fon: +49 69 27235 0 Fax: +49 69 27235 235

1 0