- address-policy-wg - mailman.ripe.net

FW: [address-policy-wg] Fwd: 2005-01 One Week to End of Discussion Period: HD Ratio for IPv4
by quin.collier＠bt.com 17 Nov '05

17 Nov '05

I can confirm that BT supports the proposal to move to an HD ratio approach for IPv4. Regards, Quin Collier -----Original Message----- From: address-policy-wg-admin(a)ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Hans Petter Holen Sent: 07 November 2005 18:22 To: address-policy-wg(a)ripe.net Subject: [address-policy-wg] Fwd: 2005-01 One Week to End of Discussion Period: HD Ratio for IPv4 Dear WG, At the meeting in Amsterdam I requested participation from the signatories to the ETNO letter. As chair of the wg I would like to understand from the participants of this WG, representing the signatories to the ETNO position - why you have chosen not to participate in the discussion in the Address Policy WG but rather develop this position in another organization. I will not move this proposal to last call before this clarified to the Address Policy working group. Best Regards, Hans Petter Holen Address Policy WG.

1 0

HD Ratio for IPv4
by Kelaidi Christina 11 Nov '05

11 Nov '05

My company believes that the proposal for the calculation of the HD ratio to measure IPv4 usage is a an improvement to the existing one and we would like to support once again this new policy proposal. Christina Kelaidi GD Regulatory Affairs OTE S.A. 99 Kifissias Av. 15124 Maroussi Greece tel: +30 2106117205 e-mail: kelaidi(a)ote.gr

1 0

RE: address-policy-wg digest, Vol 1 #315 - 2 msgs - Checking details of assignments
by Fred Langford 08 Nov '05

08 Nov '05

Hi, More of a general question but will RIPE be authenticating the details (address, abuse etc) of the IP assignments to ensure the integrity of the database? Regards Fred Langford Fred Langford Internet Research Analyst Internet Watch Foundation t +44 (0)1223 237700 www.iwf.org.uk -----Original Message----- From: address-policy-wg-admin(a)ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of address-policy-wg-request(a)ripe.net Sent: 08 November 2005 11:00 To: address-policy-wg(a)ripe.net Subject: address-policy-wg digest, Vol 1 #315 - 2 msgs Send address-policy-wg mailing list submissions to address-policy-wg(a)ripe.net To subscribe or unsubscribe via the World Wide Web, visit http://www.ripe.net/mailman/listinfo/address-policy-wg or, via email, send a message with subject or body 'help' to address-policy-wg-request(a)ripe.net You can reach the person managing the list at address-policy-wg-admin(a)ripe.net When replying, please edit your Subject line so it is more specific than "Re: Contents of address-policy-wg digest..." Today's Topics: 1. Fwd: 2005-01 One Week to End of Discussion Period: HD Ratio for IPv4 (Hans Petter Holen) 2. Re: [ipv6-wg] IPv6 micro allocation or something else? (Pekka Savola) --__--__-- Message: 1 Date: Mon, 07 Nov 2005 19:21:31 +0100 From: Hans Petter Holen <hph(a)oslo.net> To: address-policy-wg(a)ripe.net Subject: [address-policy-wg] Fwd: 2005-01 One Week to End of Discussion Period: HD Ratio for IPv4 This is a multi-part message in MIME format. --------------050809070908030505050308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear WG, At the meeting in Amsterdam I requested participation from the signatories to the ETNO letter. As chair of the wg I would like to understand from the participants of this WG, representing the signatories to the ETNO position - why you have chosen not to participate in the discussion in the Address Policy WG but rather develop this position in another organization. I will not move this proposal to last call before this clarified to the Address Policy working group. Best Regards, Hans Petter Holen Address Policy WG. --------------050809070908030505050308 Content-Type: message/rfc822; name*0="[address-policy-wg] ETNO comments on AD ratio for IPv4 addresses"; name*1=" allocation.eml" Content-Transfer-Encoding: 8bit Content-Disposition: inline; filename*0="[address-policy-wg] ETNO comments on AD ratio for IPv4 addre"; filename*1="sses allocation.eml" Return-Path: <address-policy-wg-admin(a)ripe.net> Received: from smtp220.tiscali.dk (smtp220.tiscali.dk [62.79.79.114]) by i.dont.no (8.12.10/8.12.10) with ESMTP id i8GD3O9Z028063 for <hph(a)dont.no>; Thu, 16 Sep 2004 12:03:24 -0100 Received: from cpmail.dk.tiscali.com (mail.tiscali.dk [212.54.64.159]) by smtp220.tiscali.dk (8.12.11/8.12.11) with ESMTP id i8GD3OPS091657 for <hph(a)dont.no>; Thu, 16 Sep 2004 15:03:24 +0200 (CEST) (envelope-from address-policy-wg-admin(a)ripe.net) Delivered-To: hpholen(a)tiscali.no Received: from postboy.ripe.net (193.0.0.201) by cpmail.dk.tiscali.com (6.7.018) id 412F265D0014F272 for hpholen(a)tiscali.no; Thu, 16 Sep 2004 15:03:22 +0200 Received: from postboy.ripe.net (localhost [127.0.0.1]) by postboy.ripe.net (Postfix) with ESMTP id 12CB179C2D; Thu, 16 Sep 2004 14:59:02 +0200 (CEST) Delivered-To: address-policy-wg(a)lists.ripe.net Received: by postboy.ripe.net (Postfix, from userid 8) id 9C0C079D57; Thu, 16 Sep 2004 12:01:21 +0200 (CEST) Received: from postman.ripe.net (postman.ripe.net [193.0.0.199]) by postboy.ripe.net (Postfix) with ESMTP id 8FF5479D56 for <address-policy-wg(a)postboy.ripe.net>; Thu, 16 Sep 2004 12:01:21 +0200 (CEST) Received: by postman.ripe.net (Postfix, from userid 8) id 8A7D34FC46; Thu, 16 Sep 2004 12:01:21 +0200 (CEST) Received: from etno.be (138.206-78-194.adsl-fix.skynet.be [194.78.206.138]) by postman.ripe.net (Postfix) with ESMTP id 8FE554E26F for <address-policy-wg(a)ripe.net>; Thu, 16 Sep 2004 12:01:20 +0200 (CEST) Received: from etnodebecker ([192.168.1.1]) by etno.be (etno.be [192.168.1.253]) (MDaemon.PRO.v6.8.4.R) with ESMTP id 44-md50000000012.tmp for <address-policy-wg(a)ripe.net>; Thu, 16 Sep 2004 12:01:04 +0200 Reply-To: <debecker(a)etno.be> From: "Debecker J.L." <debecker(a)etno.be> To: <address-policy-wg(a)ripe.net> Cc: <gerd.wiedenhaupt(a)t-systems.com>, <alain.bidron(a)francetelecom.com>, "Michael Bartholomew" <bartholomew(a)etno.be> Organization: ETNO Message-ID: <001101c49bd4$126111e0$0101a8c0(a)etno.be> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal X-Spam-Processed: etno.be, Thu, 16 Sep 2004 12:01:04 +0200 (not processed: message from valid local sender) X-Lookup-Warning: HELO/EHLO lookup on etnodebecker does not match 192.168.1.1 X-MDRemoteIP: 192.168.1.1 X-Return-Path: debecker(a)etno.be X-MDaemon-Deliver-To: address-policy-wg(a)ripe.net X-RIPE-Spam-Level: ** X-RIPE-Spam-Status: U 0.499986 / 1.8 / 0.0 / disabled X-RIPE-Signature: 80201789b55f74e2c7bf4670a81825e0 Subject: [address-policy-wg] ETNO comments on AD ratio for IPv4 addresses allocation Sender: address-policy-wg-admin(a)ripe.net Errors-To: address-policy-wg-admin(a)ripe.net X-BeenThere: address-policy-wg(a)ripe.net X-Mailman-Version: 2.0.13 Precedence: bulk List-Id: Developing policies relating to the management and registration of Internet addresses and routing identifiers <address-policy-wg.ripe.net> List-Post: <mailto:address-policy-wg@ripe.net> X-RIPE-Lists: Developing policies relating to the management and registration of Internet addresses and routing identifiers <address-policy-wg.ripe.net> List-Subscribe: <http://www.ripe.net/mailman/listinfo/address-policy-wg>, <mailto:address-policy-wg-request@ripe.net?subject=subscribe> List-Unsubscribe: <http://www.ripe.net/mailman/listinfo/address-policy-wg>, <mailto:address-policy-wg-request@ripe.net?subject=unsubscribe> List-Help: <mailto:address-policy-wg-request@ripe.net?subject=help> List-Archive: <http://www.ripe.net/mailman/private/address-policy-wg/> Date: Thu, 16 Sep 2004 12:01:01 +0200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by i.dont.no id i8GD3O9Z028063 RIPE Dear Sir, Madam, ETNO, representing 41 major telecom operators from 34 European countries, has studied the proposal to replace the fixed utilisation criteria of 80% in IPv4 address space allocation, by criteria based on AD (Assignment Density) ratio. Our conclusions are formulated in the attached Expert Contribution EC064. The document is the unanimous opinion of ETNO Members represented in the ETNO Frequency Management Working Group and has been endorsed by the ETNO Board. We are all prepared to discuss these comments in more detail and whenever useful. ETNO will be pleased to contribute to the further development of Europe's views on the issue. Best regards, Michael Bartholomew ETNO Director ------------------------- September 2004 ETNO Expert Contribution on AD ratio for IPv4 addresses allocation Executive Summary ETNO (1) has considered the proposal to replace the fixed utilisation criteria of 80% in IPv4 address space allocation, by a criteria based on AD (Assignment Density) ratio. ETNO strongly support the proposal and suggest selecting an AD ratio of 0.966. ETNO further suggest to the RIRs to monitor the impact of this measure on address consumption and periodically report on it to the addressing community. Background During the RIPE 48 meeting in Amsterdam, a proposal was presented by APNIC to replace the fixed utilisation criteria of 80% to request additional IPv4 addresses blocks, by a criteria based on "AD ratio" value. This ratio value corresponds to a logarithmic scale and corresponds to a percentage utilisation, which decreases as the size of the address space grows. The presentation can be downloaded at: http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-ap-hd-ratio.p df The decision was made to take the discussion to the RIPE Address-policy working group mailing list and to ask for some feed back from the community. As most European Telecommunications Network Operators' Association 1(ETNO) members are large or extra-large Local Internet Registries in Europe, representing an important part of these categories in the RIPE region, this proposal was considered and analysed with attention. Findings 1- This proposal fairly takes into account addressing hierarchies used in large and extra-large registries and introduces a useful level of flexibility for those registries. 2- The Local Internet Registries using the 80% criteria may continue to do so and will not be impacted by the new policy. 3- Complicated calculation or administrative burden should be easily avoided to registries choosing this method using simple chart or software through LIR portal. 4- As analysed by APNIC, the impact on address consumption is limited to a maximum around 20% and can be easily controlled and monitored using a rather conservative approach (AD ratio of 0.966). 5- This impact can be partly counterbalanced by reducing the number of small and extra-small registries whose existence is only justified by management overhead of large registries with current 80% criteria, and has a positive impact on address aggregation. 6- No additional impact on registrations is seen in RIPE region, as infrastructure assignments are already registered in the database. Conclusion ETNO strongly supports this proposal and suggest selecting a conservative AD ratio value of 0.966. ETNO also suggest to the RIRs to monitor the use of this facility and its impact on address consumption, and periodically report on it to the addressing community. (1) The European Telecommunications Network Operators' Association is representing 41 major companies from 34 European countries, providing electronic communications networks over fixed, mobile or personal communications systems. ETNO's primary purpose is to establish a constructive dialogue between its member companies and actors involved in the development of the European Information Society to the benefit of users. More information on ETNO can be found at: www.etno.be ETNO Expert Contribution EC064 (2004/09) --------------050809070908030505050308-- --__--__-- Message: 2 Date: Tue, 8 Nov 2005 03:43:59 +0200 (EET) From: Pekka Savola <pekkas(a)netcore.fi> To: Andreas =?ISO-8859-1?Q?B=E4=DF=2FDenic?= <baess(a)denic.de> cc: address-policy-wg(a)ripe.net, ipv6-wg(a)ripe.net, ipv6-wg-admin(a)ripe.net, Mohacsi Janos <mohacsi(a)niif.hu> Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1589707168-1824570081-1131332849=:12767 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1; FORMAT=flowed Content-Transfer-Encoding: 8BIT Content-ID: <Pine.LNX.4.64.0511070508011.12767(a)netcore.fi> On Tue, 1 Nov 2005, Andreas Bäß/Denic wrote: >>>> 4. Allocate /48 to primary hu DNS server that is globally routable? >>>> Are there similar to /48 from 2001:0500::/30 in RIPE region? >>>> >>>> - I think this is the cleanest solution. >>>> >>>> Can we discuss this issue on the working group or mailing lists? >>>> >>>> I saw a proposal: >>>> http://www.ripe.net/ripe/policies/proposals/2005-2.html >>>> >>>> In my opinion this can solve the problem.... > > I have not seen any discussions that think it is a bad idea to assign > several network resources to TLD administrators which will enable them > to operate their nameservers according to RFC3258. > > When we have reviewed the discussions we felt that your objection > against the proposal was because of the size of the assignment. I'm > planning to submit revised proposal with a reduced prefix length which > better fits with other assignment policies. If you are opposing to the > new proposal I would be glad to know as soon as it is submitted. Yes. Let me clarify my objections: 1) special policy for ccTLDs (if they do not anycast) is not IMHO needed as assignments from (some of the) transits should be enough; 2) special policy for any arbitrary service, if anycast, does not seem justified because it's too open-ended; 3) ccTLD combined with requirement to anycast it appears to be suitably well justified operationally and technically. In addition, a) we have enough address space that allocating a (v6) /32 is not waste. b) I'm strongly opposed to creating any special micro-allocation blocks which is just waiting for getting the worms out hence a). So, I'd say that if the policy proposal is 3) with a (v6) /32, I shouldn't have a problem with it. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings --1589707168-1824570081-1131332849=:12767-- End of address-policy-wg Digest -- This message has been scanned for viruses and potentially harmful content by StreamShield Protector.

1 0

Fwd: 2005-01 One Week to End of Discussion Period: HD Ratio for IPv4
by Hans Petter Holen 07 Nov '05

07 Nov '05

Dear WG, At the meeting in Amsterdam I requested participation from the signatories to the ETNO letter. As chair of the wg I would like to understand from the participants of this WG, representing the signatories to the ETNO position - why you have chosen not to participate in the discussion in the Address Policy WG but rather develop this position in another organization. I will not move this proposal to last call before this clarified to the Address Policy working group. Best Regards, Hans Petter Holen Address Policy WG.

1 0

2005-08 New Policy Proposal
by RIPE NCC Policy Coordinator 03 Nov '05

03 Nov '05

PDP Number: 2005-08 Proposal to Amend the IPv6 Assignment and Utilisation Requirement Policy Dear Colleagues, A proposed change to RIPE Document ripe-ripe-267 is now available for discussion. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2005-08.html We encourage you to review this proposal and send your comments to <address-policy-wg(a)ripe.net> before 2 November 2005. After this date, we will prepare a draft RIPE document. We will let you know when this is available. There is a new mailing list for announcing policy proposals and tracking them through the policy development process. You can subscribe to the policy-announce list at: http://www.ripe.net/mailman/listinfo/policy-announce Regards Adrian Bedford RIPE NCC

13 30

(no subject)
by Eri Chatzifotiou 31 Oct '05

31 Oct '05

We are gr.tpp We have a point of presence, which is in Cyprus (Different Country) and for now, we are using a /24 Subnet for their needs. The problem is that they need to anounce this subnet through a different isp then the one that we are using. They want only to anounce the 82.197.100.0 /255 to their isp cooperator. Thank you

1 0

New RIPE Document available: RIPE-353
by RIPE NCC Document Announcement Service 13 Oct '05

13 Oct '05

New RIPE Document Announcement -------------------------------------- A new RIPE Document is available from the RIPE Document store. Ref: ripe-353 Title: ASN Missing In Action, A Comparison of RIR Statistics and RIS Reality Author: Henk Uijterwaal, Rene Wilhelm Date: October 2005 Format: PDF=763999 Obsoletes: Obsoleted by: Updates: Updated by: Short content description ------------------------- In this paper, we look at Autonomous System Number (ASN) assignments by the Regional Internet Registries (RIRs) and the number of unique ASNs seen by routers on the Internet. Accessing the RIPE document store --------------------------------- You can access the RIPE documents in HTML format via our website at the following URL:. http://www.ripe.net/docs/ripe-353.html The RIPE Document Store is also available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs. The URLs for the new documents on the FTP-server are: ftp://ftp.ripe.net/ripe/docs/ripe-353.pdf PDF version Kind Regards, RIPE NCC Document Announcement Service

1 0

Re: [address-policy-wg] 2005-08 New Policy Proposal
by Michael.Dillon＠btradianz.com 06 Oct '05

06 Oct '05

> The answer is "the RIPE policies have no answers how to do things that > are in violation of the RIPE policies" - and assigning 10 IPv6 addresses > is against the policy. Assigning 10 IPv6 addresses is *NOT* against RIPE policy! It may come as a surprise to those of you who do not speak English as a native language, but the word "assign" is a synonym of the word "allocate" and both have a very general meaning of distributing something to multiple recipients. The fact that RIR policies use these synonyms in specific and distinct ways does not change the fact that anyone who learns English as a language of communication will learn that these two words mean the same thing and can be substituted for one another. Even worse (Horrors!) these two words can be used in business outside of the context of the RIRs. ISPs can allocate circuit bandwidth to customers, assign them to router ports, distribute IP addresses to them, etc. Inside the business he can certainly assign 10 addresses to his customer, however the very fact that he is choosing to allocate the customer 10 addresses shows that he is doing a private act. Since it is a private act, we don't want to know that he distributed 10 addresses to this customer and therefore, the allotment of 10 addresses does not need to be registered in the RIPE database. If he had given out an entire /64 to the customer we still don't need to see this apportionment in the database. The addresses designated for a customer only need to be seen in the database when the act of earmarking these addresses for customer use is in alignment with the RIPE policy. Presumably, at a technical level, if there is no route created in the service provider's OSPF or ISIS then it doesn't need to be published. But don't take my word for that because I really don't understand what RPE-267 3.3 says. > The policy is a bit vague here, admitted. I agree. --Michael Dillon

3 2

Re: [address-policy-wg] 2005-08 New Policy Proposal
by Michael.Dillon＠btradianz.com 06 Oct '05

06 Oct '05

> Would there be any real value in registering private users in Whois? > How likely is it that the end user could provide assistance to > whoever contacted them? Finally we are getting to the heart of the question which is about administrative procedure, i.e. policies, not about technology. The technology specifies that a "network" should be assigned a /64 but this thing called a "network" may not be an Ethernet broadcast domain. Different people will do different things with devices and this will lead them to use different address allocation strategies. For instance, consider an RS-232 cable daisychained through a factory with modems to handle the signal strength amplification when the signal gets too strong. Imagine 10 devices attached to this daisy chained RS 232 cable which use IPv6 to communicate. One might consider this a network or one might not. Is this decision a public policy decision or not? It really depends on where one puts the boundary between the public domain of the RIR and the private domain of the end user. Where should this boundary be? Is the current definition of the boundary too fuzzy? Does the RIR database contain more detail than it should because of the fuzziness of this boundary? Is the current definition of the boundary too tightly aligned with the 1990's world of ISPs and end users where ISPs use PDH and SDH networks while end users use Ethernet? What should go in the RIR database? What should stay out of the database because it is nobody else's business? --Michael Dillon

2 1

RIPE 51 - Address Policy WG Agenda (Draft)
by Andrea Borgato 05 Oct '05

05 Oct '05

Hello to everybody. Here in the following you can find Address Policy WG final draft of agenda. Regards, Andrea Borgato - Address Policy WG co-chair ----------------------------- CUT HERE ----------------------------- RIPE 51 - Address Policy Working Group Agenda (Draft) When: Wednesday, October 12, 2005, 14:00 - 15:30 Where: Grand Ballroom, Hotel Krasnapolsky, Amsterdam A. Administrative Matters - Welcome - Select a scribe - Distribute participants list - Finalise agenda - Approve minutes from RIPE 50: http://www.ripe.net/ripe/wg/address-policy/r50-minutes.html B. Policy overview - Regional policy overview -- status of the PDP and transition to the PDP -- summary of the status of the current regional proposals started under the "beta test of the PDP" and now in "official PDP" http://www.ripe.net/ripe/policies/proposals/ - Global policy overview -- Status of the IPv4 Global Policy -- Status of the IPv6 Global Policy C. Policy proposal: #2005-01: IPv4-HD-Ratio Action on: HPH D. Policy proposal: #2005-02: TLD Anycast Allocation Policy Action on: Andreas Baess / Leo Vegoda (short update and current status) E. Policy proposal: #2005-03: IPv6 initial allocation criteria Action on: Andy Furnell / Leo Vegoda (current status and go ahead with discussion from mailing list) F. Policy proposal: #2005-04: definition of an "end site", Eric Schmidt (this definitely needs time for discussion - 15minutes?) G. Policy proposal: #2005-09 "global IPv6 distribution: ICANN/IANA->RIRs" (short update, now formally run through the PDP) H. Policy proposal: #2005-08 (Kurtis Lindqvist, Geoff Huston - RIPE IPv6 change of endsite allocations from /48 to /56) (need time for discussions) Z. Any other Business ----------------------------- CUT HERE -----------------------------

1 0

2005-09 New Policy Proposal
by RIPE NCC Policy Coordinator 04 Oct '05

04 Oct '05

PDP Number: 2005-09 Internet Assigned Numbers Authority (IANA) Policy for Allocation of IPv6 Blocks to Regional Internet Registries Dear Colleagues A new RIPE Policy has been proposed and is now available for discussion. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2005-09.html We encourage you to review this proposal and send your comments to <address-policy-wg(a)ripe.net> before 1 November 2005. After this date, we will prepare a draft RIPE Document. We will let you know when this is available. Regards Adrian Bedford RIPE NCC

1 0

RIPE Policy Development Process
by Paul Rendek 01 Sep '05

01 Sep '05

Dear Colleagues We are pleased to announce that Rob Blokzijl, RIPE Chair, has published a new RIPE Document, "Policy Development Process in RIPE", (ripe-350). This document formally describes the policy development process. The updated process is operational from today, 1 September 2005. A new RIPE web page describes all the active policy proposals and their status. Each proposal has a page showing its history, status and all supporting documentation. This page can be found at: http://www.ripe.net/ripe/policies/proposals/index.html A new mailing list <policy-announce(a)ripe.net> has been created for announcing policy proposals and tracking them through the policy development process. This is not a discussion list; discussions will continue to take place on relevant RIPE Working Group lists and at RIPE Meetings. You can subscribe to the policy-announce list at: http://www.ripe.net/mailman/listinfo/policy-announce List archives are available at: http://www.ripe.net/ripe/maillists/archives/policy-announce/ Kind regards Paul Rendek Head of Member Services and Communications RIPE NCC

1 0

RE: [address-policy-wg] last Call: Policy proposal #beta HD ratio policy proposal
by Kristian Rastas 29 Aug '05

29 Aug '05

Hello all, correction time, on the contrary what I expressed in my previous message during summer, Local Internet Registry fi.sonera supports ETNO's proposal on HD-ratio. My previous message should be taken solely as a personal flameout based on my misinterpretation of the situation and lack of timely and correct information back then. Accidents do happen, unfortunately. I'm also sorry for littering the discussion list with my confusing message. That should not happen again, not even accidentally. With regrets, Kristian Rastas, fi.sonera "The only completely consistent people are the dead" -Aldous Huxley

1 0

Fwd: Re: [AA] Aanvraag IPv6 adressen
by Aad van der Zanden 25 Aug '05

25 Aug '05

Dear Sir/Madam IPv6 is one of the key research areas within NC3A and we have come across an issue on addressing. I have presented my questions to SURFnet ( which you can find below ) Since Surfnet has not yet presented their views yet I continued my search. I came acros the ECP IPv6 portal and a presentation by Rumy Kanis from RIPE NCC. http://www.ecp.nl/ipv6/docs/Rumy_Kanis_27apr05#1 which refers to IPv6 plicy and this seems relevant to our problem. I am wondering if you can lead me to the right channel for some more guidance on the issue of global IPv6 addres assignments for large geographical distributed organisations like NATO , We are also curious in which database tools are used by RIRs ? Could you help me in finding the right sources or people to get more clearness on this issue so we can further expand our IPv6 work. Regards Aad van der Zanden. >Date: Fri, 05 Aug 2005 09:34:43 +0200 >To: Jasper Distelbrink <jasper.distelbrink(a)surfnet.nl>,Rogier Spoor ><rogier.spoor(a)surfnet.nl> >From: Aad van der Zanden <Aad.van.der.Zanden(a)nc3a.nato.int> >Subject: Re: [AA] Aanvraag IPv6 adressen >Cc: >selm,jan-willem.smaal@nc3a.nato.int,levente.janovszki@nc3a.nato.int,goode,martin.gerritsen@nc3a.nato.int > > >Dear Jasper /Rogier > >In March '05 our first official IPv6 block has been assigned to us; >2001:0610:0B20::/48. As it turns out, the policy is that even any home >user gets a /48 assigned as a minimum. One starts wondering whether a /48 >is then a proper size if one is allocating v6 addresses to an organisation >that has currently approx 500 people as well as numerous pilot networks >spread over several locations. > >So after a review on the IPv6 address assignment ( and tryiing to sqeeuze >all in the /48 ) we have come across a much broader view on assignment of >IPv6 address space. Our Agency takes part or iniitated numerous networking >initiatives that are ( or becoming ) pilots to larger scale >implementations. These network can have external connectivity ( sometimes >exceeding international borders as well). Next to this these network may >have several security classifications levels/layers. > >As an example: >We have a network called NGCS. It now simulates only 5-7 Headquarter >locations; the network is built upon two or more security levels/layers. >So every "Headquarter" has at least these layers. > - An "open layer" that is still a closed IP environment but may > be using the internet as bearer one day - still it needs IPv6 capability now > - a closed encrypted ( by means of IP crypto ) layer of networks > - still it requires IPv6 capability now > - some closed usergroups built on top by means of firewalls - > also requires IPv6 capability to be studied >This pilot network is the first phase to the generic NATO IPv4/IPv6 >provisioning network so will scale to be a very large network in the end. > >How should we approach the IPv6 address assignment for this network in >your view? >Could we currently apply for a larger IPv6 address space for the pilot for >the open layer too from SURFnet? And what about the closed IP layer in the >pilot? >What if the deployment becomes a fact - who will provide the NATO IPv6 >addresses if some of those Headquarters are not directly ISP connected >Who is going to provide the closed layer IPv6 addresses? Since there is no >private IPv6 address space, where should this address block come from ? ( >so in the early pilot stage and in the "operational" stage?) > >Other networks exist which are built upon (NC3A private ) infrastructure >which crosses international borders to regional offices. So if we plan to >deploy IPv6 on these networks too. How do we go about implementing IPv6 >addressing here? > >It would help if you could outline the SURFnet approach to these >interesting issues. >For now - can we apply for more IPv6 address space ( or a larger block ) >to cover all these pilot networks ? > >Regards > Aad

2 1

New Document available: RIPE-349
by RIPE NCC Document Announcement Service 27 Jul '05

27 Jul '05

New RIPE Document Announcement -------------------------------------- A new document is available from the RIPE Document store. Ref: ripe-349 Title: Address Space Managed by the RIPE NCC Author: Leo Vegoda RIPE NCC Date: 27 July 2005 Format: PDF=31257 TXT=2986 Obsoletes: ripe-348 Short content description ------------------------- This document details the address space managed by the RIPE NCC and the longest prefixes allocated or assigned from different address ranges. The new version was needed to correct errors in the previous document. Accessing the RIPE Document store --------------------------------- You can access this RIPE Documents in HTML format at: http://www.ripe.net/docs/ripe-349.html The RIPE Document Store is also available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs. The URLs for the new document on the FTP-server are: ftp://ftp.ripe.net/ripe/docs/ripe-349.pdf PDF version ftp://ftp.ripe.net/ripe/docs/ripe-349.txt plain text version

1 0

The Register: ICANN prez delivers internet vision
by Hans Petter Holen 21 Jul '05

21 Jul '05

1 0

Presentation of the WGIG Report
by Axel Pawlik 20 Jul '05

20 Jul '05

Dear Colleagues, The WGIG Report was presented in Geneva on 18 July at a meeting open to all stakeholders. The Report of the Working Group on Internet Governance was previously transmitted on 14 July by United Nations Secretary-General Kofi A. Annan to the President of the Preparatory Committee of the World Summit on the Information Society, Ambassador Janis Karklins, and the WSIS Secretary-General, Mr Yoshio Utsumi. The document is available from the WGIG web site in all UN languages at: http://www.wgig.org/WGIG-Report.html More details on the meeting and the transcripts from the morning and afternoon session proceedings are also available at: http://www.wgig.org/index.html Regards, Axel Pawlik Managing Director RIPE NCC

1 0

New IPv6 Address Block Allocated to RIPE NCC
by leo vegoda 20 Jul '05

20 Jul '05

Dear Colleagues, The RIPE NCC received the IPv6 address range 2A01:0000::/23 from the IANA in July 2005. We will begin making allocations from this block in the near future. You may wish to adjust any filters you have in place accordingly. More information on the IP space administered by the RIPE NCC can be found on our web site at: https://www.ripe.net/ripe/docs/ripe-ncc-managed-address-space.html This document has been updated to to provide extra information about the IPv6 address space we manage, following some requests we received. I hope people find the new format useful. Regards, -- leo vegoda Registration Services Manager RIPE NCC

1 0

IPv6 Policy Clarification - Initial allocation criteria "c)"
by Laura Cobley 19 Jul '05

19 Jul '05

Dear Colleagues, As explained in the email sent on Mon, 14 Jun 2004: http://www.ripe.net/ripe/mail-archives/address-policy-wg/2004/msg00240.html This is the second mail request for clarification of the IPv6 Address Allocation and Assignment Policy. Below is an excerpt from the IPv6 Address Allocation and Assignment Policy: 5.1.1. Initial allocation criteria "c)" "To qualify for an initial allocation of IPv6 address space, an organisation must [...] plan to provide IPv6 connectivity to organisations to which it will assign /48s by advertising that connectivity through its single aggregated address allocation" LIRs who operate closed/private networks appear not to qualify because the address space in these networks will not be advertised. Was this the community's intention? Best Regards, Laura Cobley Registration Services RIPE NCC

9 12

Administrative: New chair email address
by Hans Petter Holen 18 Jul '05

18 Jul '05

Dear all, Following my change of jobs last year from Tiscali to Visma, and as a consequence of Tiscali having sold its Nowegian operations to the former incumbent Telenor, its Swedish opreations to Spray-Lycos and its Danish operations to Tele2; I am changing my personal email address from my private Tiscali subscription to hph(a)oslo.net This will also remove the technical difficulties of delayed email and unsolicited virus scan messages my former employee has imposed on me. The tiscali.no address will still work for some time - but maybe not for more than a year into the future. The Oslo.net domain is however mine to keep - the only remaining memory of the first Norwegian comercial consumer ISP Oslonett - for norwegian readers there are some historic material at the web site. Best Regards Hans Petter Holen Private email: hph(a)oslo.net PS: Appologies for the followin messages to the list: this is most likely due to some new anti-virus software imposed upon me. Antigen_EXFE01HI(a)smarthost3.tiscali.dk wrote: >The entire message "RE: [address-policy-wg] last Call: Policy proposal #beta HD ratio policy proposal", originally sent to you by address-policy-wg-admin(a)ripe.net (address-policy-wg-admin(a)ripe.net), has been forwarded to you from the Antigen Quarantine area. >This message may have been re-scanned by Antigen and handled according to the appropriate scan job's settings. > > > ><<Entire Message.eml>> > >

1 0

Re: [address-policy-wg] FWD: [GLOBAL-V6] draft-narten-iana-rir-ipv6-considerations-00.txt
by Thomas Narten 15 Jul '05

15 Jul '05

Niall Murphy <niallm(a)enigma.ie> writes: > Thomas, all, > > I'd welcome discussion/feedback on it, and this list seems as good a > > place as any. > > > > http://www.ietf.org/internet-drafts/draft-narten-iana-rir-ipv6-consideratio… > This is nit-picking, but for the sake of clarity: > 2.7. Utilization > In IPv4, the utilization of a chunk of address space is defined as > the ratio of the actual number of host assignments to the theoretical > maximum number of host assignments. For example, a /24 in IPv4 can > number 256 hosts [...] > A /24 can't number 256 hosts; it can number 254. Well, for the purposes of this draft, it's probably best to understand how the RIRs themselves measure utilization. Surely, they just count the raw numbers and don't try to exclude broadcast addresses and such. Thomas

1 0

FWD: [GLOBAL-V6] draft-narten-iana-rir-ipv6-considerations-00.txt
by Thomas Narten 15 Jul '05

15 Jul '05

FYI. The global-v6 list appears to still be active, and perhaps we can revive the list to talk about things that really cross the entire RIR community. Thomas ------- Forwarded Message From: Thomas Narten <narten(a)us.ibm.com> To: global-v6(a)lists.apnic.net Date: Thu, 14 Jul 2005 09:40:34 +0200 Subject: [GLOBAL-V6] draft-narten-iana-rir-ipv6-considerations-00.txt I think/hope the global-v6 is still in operation, so this is a bit of a test... I've written a document that attempts to give background and describe the bigger picture w.r.t. IPv6 address space management and the various issues that are now being discussed (e.g., hd ratio, /48 boundary, etc.). This document is intended to provide information and explain the broader landscape, rather than propose specific changes, etc. I'd welcome discussion/feedback on it, and this list seems as good a place as any. http://www.ietf.org/internet-drafts/draft-narten-iana-rir-ipv6-consideratio… Likewise, there is another document that will be discussed at the upcoming Paris IETF meeting. http://www.ietf.org/internet-drafts/draft-narten-ipv6-3177bis-48boundary-00… That document will be discussed in the IPv6 WG: http://www.ietf.org/html.charters/ipv6-charter.html mailing list: https://www1.ietf.org/mailman/listinfo/ipv6 Finally, significant discussion on the general topic has already place (and continues) in the ARIN and RIPE regions. Folk may want to review/follow some of the discussions that have taken place there: http://www.ripe.net/mailman/listinfo/address-policy-wg http://lists.arin.net/mailman/listinfo/ppml (I believe the pointers to the ARIN/RIPE discussions have been sent to APNIC lists, but I don't believe a lot of discussion has taken place there - yet). Thomas _______________________________________________ global-v6 mailing list global-v6(a)lists.apnic.net http://mailman.apnic.net/mailman/listinfo/global-v6 ------- End of Forwarded Message

5 4

RE: [address-policy-wg] last Call: Policy proposal #beta HD ratio policy proposal
by BIDRON Alain ROSI/DAS 14 Jul '05

14 Jul '05

According to the proposal documented in the APNIC region, http://www.apnic.net/docs/policy/discussions/prop-020-v001.txt the proposal is based on the HD value 0.96. I think it is better to have the same value for all RIRs. Best regards. Alain -----Message d'origine----- De : Koepp, Karsten [mailto:Karsten.Koepp@lambdanet.net] Envoyé : mardi 12 juillet 2005 12:20 À : BIDRON Alain ROSI/DAS Cc : address-policy-wg(a)ripe.net; Hans Petter Holen Objet : RE: [address-policy-wg] last Call: Policy proposal #beta HD ratio policy proposal Bonjour Alain, thanks for your reply. Why have you changed the HD value recommended by APNIC and ETNO from 0.966 to 0.96? Using HD of 0.966 APNIC was projecting an increased IPv4 address consumption of 22%. In case of fr.telecom the lower value drives the required address consumption from 58% to 53%. Please explain this change. For others: APNIC: https://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-ap-hd-ratio. pdf ETNO: http://www.etno.be/pp/EC064%20-%20NANI%20EC%20on%20IPv4%20AD%20ratio.pdf I am personally still not convinced but I have no experience in running such networks as Alain does. regards Karsten > -----Original Message----- > From: BIDRON Alain ROSI/DAS [mailto:alain.bidron@francetelecom.com] > Sent: Tuesday, July 12, 2005 10:19 AM > To: Koepp, Karsten; Hans Petter Holen > Cc: address-policy-wg(a)ripe.net > Subject: RE: [address-policy-wg] last Call: Policy proposal #beta HD > ratio policy proposal > > > Dear Karsten, > When you manage an X-large registry you have several levels > of management. > In such a situation, meeting the 80% criteria is much more > difficult (if possible) than with a small registry with only > one level. > The proposal is clearly not to advantage or to disadvantage > some registries but simply to take into account in fair way > different situations in order to have enough flexibility for > a better management. > > Regarding the support from the community, I have to mention > that this proposal was considered by ETNO, whose members > representing are a large part of X large registries in the > RIPE region, and unanimously supported. > > You can find this expression for support at > www.etno.be Document EC064. > > Leo Debecker posted this contribution from ETNO to the mailing list. > Be aware that this support comes from the following ETNO members. > This is not one voice but 41. > · Auna Telecomunicaciones > · Belgacom > · BH Telecom (Bosnia and Herzegovina) > · BT (British Telecom) > · BTC (Bulgarian Telecommunications Company) > · Cesky Telecom > · Community of Yugoslav PTT > · Croatian Telecom > · Cyprus Telecommunications Authority > · Deutsche Telekom > · Eircom > · Elion Enterprises Ltd > · Elisa Communications Corporation > · Entreprise des Postes et Télécommunications Luxembourg > · Finnet Group > · France Telecom > · Invitel > · Koninklijke KPN > · Lattelekom > · Makedonski telekomunikacii > · Maltacom > · Matáv Hungarian Telecommunications Company > · Netia S.A. > · OTE > · Portugal Telecom > · Rom Telecom > · Síminn (Iceland Telecom Ltd.) > · Slovak Telecom > · Societatea Nationala de Radiocomunicatii (SNR) > · Swisscom > · TDC > · Tele 2 > · Telecom Italia > · Telefonica > · Telekom Austria > · Telekom Slovenije > · Telekomunikacja Polska > · Telenor > · TeliaSonera > · Türk Telekomünikasyon > · VIPnet > Regards > > -----Message d'origine----- > De : address-policy-wg-admin(a)ripe.net > [mailto:address-policy-wg-admin@ripe.net]De la part de Koepp, Karsten > Envoyé : jeudi 7 juillet 2005 12:34 > À : 'Hans Petter Holen' > Cc : address-policy-wg(a)ripe.net > Objet : RE: [address-policy-wg] last Call: Policy proposal #beta HD > ratio policy proposal > > > Hello Hans Petter and al, > > I am AGAINST the proposal. > > I would like Alain to better explain his need for better IP > address management. He is the only voice I have seen *for* > the proposal. Nobody is supporting Alain, instead Iljitsch > has brought profound comments *against*, and there were some > cynic comments - also *against*. > > From my point of view, I would like to see the current policy > remain in place, because with IPv4 we much more have a conservation > than an aggregation goal (or an internal aggregation need) > Large LIRs already receive /10s and I cannot see the proposal > will have "some limited impact" on address consumption. If > giant LIRs will only be mandated to occupy 52% instead of 80% of > their v4-IPs (I have done this calculation for DTAG and FT), this > is in my view going to cut our resources significantly. > > So, does the new PDP request a counter proposal to maintain > current policy, I guess no, just enough people have to say > no. Also, people in support of the proposal please raise your > hands. > > regards Karsten > eu.lambdanet > > > -----Original Message----- > > From: Hans Petter Holen [mailto:hpholen@tiscali.no] > > Sent: Friday, July 01, 2005 12:37 AM > > Cc: address-policy-wg(a)ripe.net > > Subject: [address-policy-wg] last Call: Policy proposal > #beta HD ratio > > policy proposal > > > > > > Hans Petter Holen wrote: > > Following the discussion on the mailinglist prior to and > > after posting > > the formal proposal I have seen no proposals to modify the > > proposal and > > would like to move the proposal into the conclustion phase in > > the policy > > development process > http://www.ripe.net/ripe/draft-documents/pdp.html > > > > Last cal will end at July 15th. > > > > Best Regards > > > > Hans Petter Holen > > WG Chair > > > > > Thanks Alain, > > > I'll as the new PDP is not in operation yet, I'll add this > > to my list > > > as #beta v1 > > > > > > I propose that we enter into the Discussion phase for 4 > weeks from > > > date until April 4. > > > > > > -hph > > > > > > BIDRON Alain ROSI/DAS wrote: > > > > > >> Dear Colleagues > > >> Referring to the minutes of the last RIPE Policy Working Group > > >> meeting and to the action list as updated during that > > meeting, I have > > >> to make a formal proposal on use of HD ratio for IPV4. > > >> Here is this policy proposal. > > >> In order to be consistent with the PDP Draft proposal > > coming from Rob > > >> Blokzijl I have used the template provided in the new > PDP proposal. > > >> Best regards. > > >> Alain > > >> > > >> > > >> _________________________________________________________ > > >> 1. Policy Proposal Name: IPv4-HD-Ratio > > >> 2. Author > > >> a. name: Alain Bidron > > >> b. e-mail: alain.bidron(a)francetelecom.com > > >> c. telephone: +33 1 44 44 27 75 > > >> d. organisation: France Telecom > > >> 3. Proposal Version: V0 > > >> 4. Submission Date: 02/02/2005 > > >> 5. Suggested WG for discussion and publication: Address Policy WG > > >> 6. Proposal type: modify > > >> 7. Policy term: permanent > > >> 8. Summary of proposal: Internet address space is managed > > >> hierarchically: > > >> - IANA allocates space to Regional Internet Registries (RIRs). > > >> - RIRs allocate space to Local Internet Registries (LIRs). > > >> - LIRs assign space to End Users. > > >> > > >> At each level, some address space may be reserved for future > > >> expansion and/or efficient aggregation. As more > > hierarchical levels > > >> are introduced, the overall efficiency of the address > space usage > > >> decreases. > > >> > > >> The HD ratio (Host-Density ratio) is a way to measure > > address space > > >> usage [RFC 3194]. The HD ratio value can relate to a > percentage of > > >> usage, which decreases as the amount of address space > grows. This > > >> allows for the decreasing efficiency that occurs with more > > >> hierarchical levels. > > >> > > >> The HD ratio is currently used to measure IPv6 address > space usage > > >> [ipv6-address-policy]. The IPv6 Address Allocation and > Assignment > > >> Policy considers a block of IPv6 address space to be > > 'used' when its > > >> HD ratio reaches 0.80. This is a manageable figure > > ("values of 80% or > > >> less correspond to comfortable trade-offs between pain and > > >> efficiency" [RFC 3194]). > > >> > > >> This document proposes using the HD ratio to measure IPv4 > > usage. The > > >> proposed value of the HD ratio for IPv4 is 0.96. > > >> > > >> 9. Policy text: > > >> a. Current: "An LIR may receive an additional allocation > > when about > > >> eighty percent (80%) of all the address space currently > > allocated to > > >> it is used in valid assignments or sub-allocations." > > >> b. New: "An LIR may receive an additional allocation when > > its total > > >> allocated address space usage meets the HD-Ratio value of 0.96." > > >> > > >> 10. Rationale: > > >> > > >> a. Background > > >> The current document, "IPv4 Address Allocation and Assignment > > >> Policies for the RIPE NCC Service Region" [ipv4-address-policy], > > >> considers a block of IPv4 addresses to be 'used' when 80% of the > > >> addresses within the block have been sub-allocated or > > assigned. This > > >> is applied to all address blocks, regardless of size. > > >> Current policies assume a hierarchical system of address space > > >> delegation. However, they do not make any allowance for > > hierarchical > > >> management within allocated address space. For LIRs in > > particular, a > > >> hierarchical approach is often required for assignment > of address > > >> space to service elements such as customer networks, individual > > >> Points of Presence (PoPs), regionalised topologies, and > > even distinct > > >> ISP products. Small network infrastructures may require simple > > >> hierarchies, but large infrastructures can require several > > levels of > > >> address space subdivision. These levels of hierarchy are not > > >> recognised by the current policy framework and are highly > > restricted > > >> by the "80% rule". As a result, managing large blocks is often > > >> difficult, requiring large internal routing tables > and/or frequent > > >> renumbering of internal address blocks. > > >> > > >> One of the goals of the RIR system is to avoid unnecessary > > depletion > > >> of IPv4 address space. However, address management > > policies must also > > >> be practical in terms of how much management overhead > they cause. > > >> When large amounts of address space are involved, the "80% > > rule" can > > >> result in more work for an LIR. > > >> > > >> Basing usage on the HD ratio should lead to equal levels of > > >> management overhead across the board, rather than penalising the > > >> holders of large address blocks. > > >> > > >> b.Impact > > >> To see a rough estimation of the immediate impact of this > > proposal, > > >> an HD Ratio value of 0.96 was applied to the average amount of > > >> address space held by an LIR in the RIPE NCC Service > Region. This > > >> showed that on average, LIRs would qualify for an additional > > >> allocation block when they have assigned or sub-allocated > > about 59% > > >> of their allocated address space. > > >> > > >> c.Arguments supporting the proposal. > > >> This proposal fairly takes into account addressing > > hierarchies used > > >> in large and extra-large registries and introduces a > > useful level of > > >> flexibility for those registries > > >> The local Internet registries using the 80% criteria may > > continue to > > >> do so and will not be impacted by the new policy. > > >> The RIPE NCC will provide support to minimise complicated > > >> calculations or administrative burden to LIRs. > > >> > > >> d. Arguments opposing the proposal. > > >> This proposal will have some limited impact on IPV4 > > address consumption. > > >> > > >> > > >> > > >> > > >> Appendix A. The HD ratio > > >> > > >> The HD ratio is calculated as follows [RFC 3194]: > > >> > > >> HD = log(U)/log(S) > > >> > > >> Where: > > >> > > >> S is the size of the address block concerned, and > > U is > > >> the number of addresses used. > > >> > > >> Note: The current IPv4 policy considers addresses to be > > 'used' once > > >> they are assigned or sub-allocated by the LIR. > > >> Appendix B. Selection of HD ratio value > > >> > > >> We should decide an appropriate HD ratio value on a > > rational basis. > > >> To do this, we make certain assumptions about the number > > of "hidden" > > >> hierarchical levels involved in managing address blocks > of various > > >> sizes. If we assume there is 80% usage at each level, we > > can easily > > >> calculate the overall usage. > > >> > > >> The following table proposes a set of hierarchical > levels which we > > >> can reasonably expect within different amounts of address > > space. If a > > >> usage of 80% is achieved at each hierarchical level, then > > the overall > > >> usage will be (0.80 to the power of "n"). It is then possible to > > >> calculate HD ratio values from this value. > > >> > > >> Size range Level Utilisation HD ratio > > >> (prefix) (n) (0.80**n) > (calculated) > > >> /24 to /20 1 80% > > .960 to .973 > > >> /20 to /16 1.5 72% > > .961 to .970 > > >> /16 to /12 2 64% > > .960 to .968 > > >> /12 to /8 2.5 57.2% > > .960 to .966 > > >> /8 to /4 3 51.20% > > .960 to .966 > > >> The levels of hierarchy listed above are based on > assumptions > > >> about the likely size and structure of LIRs holding > > address blocks of > > >> these sizes. A reasonable HD ratio value may be 0.96 (a > > round figure > > >> which occurs within most of these ranges) from the table > > above. The > > >> following table gives the usage requirements for IPv4 > > address blocks > > >> from /24 to /8 for this value. > > >> > > >> IPv4 Addresses Addresses > > Util% > > >> prefix total used > > >> 24 256 > > 205 > > >> 80.11% > > >> 23 512 399 > > 77.92% > > >> 22 1024 776 > > 75.79% > > >> 21 2048 1510 > > 73.71% > > >> 20 4096 2937 > > 71.70% > > >> 19 8192 5713 > > 69.74% > > >> 18 16384 11113 > > 67.83% > > >> 17 32768 21619 > > 65.98% > > >> 16 65536 42055 > > 64.17% > > >> 15 131072 81811 > > 62.42% > > >> 14 262144 159147 > > 60.71% > > >> 13 524288 309590 > > 59.05% > > >> 12 1048576 602249 > > 57.43% > > >> 11 2097152 1171560 > > 55.86% > > >> 10 4194304 2279048 > > 54.34% > > >> 9 8388608 4433455 > > 52.85% > > >> 8 16777216 8624444 > > 51.41% > > >> > > >> Note: This table provides values for CIDR blocks, but the same > > >> calculations can be made for non-CIDR blocks. > > >> > > >> As an example, an LIR holding a total amount of address > > space equal > > >> to a /16 would be able to receive more address space > when they had > > >> sub-allocated or assigned 64.17% of that space; while an > > LIR holding > > >> a /9 would be able to receive more space when they had > > sub-allocated > > >> or assigned 52.85% of their address space. > > >> > > >> Appendix C. References > > >> [RFC 3194] "The Host-Density ratio for address assignment > > efficiency: An > > >> update on the H ratio", A. Durand, C.Huitema, November 2001. > > >> [ipv6-address-policy] RIPE NCC document: "IPv6 Address > > Allocation and > > >> Assignment Policy" > > http://www.ripe.net/ripe/docs/ipv6policy.html > > >> [ipv4-address-policy] RIPE NCC document: "IPv4 Address > > Allocation and > > >> Assignment Policies for the RIPE NCC Service Region" > > >> http://www.ripe.net/ripe/docs/ipv4-policies.html > > >> > > >> > > >> > > > > >

1 0

Policy Proposal #eta : IPv6 Address Allocation and Assignment Policy - definition for "End-Site
by Hans Petter Holen 13 Jul '05

13 Jul '05

Dear Address Policy WG, Please find enclosed a policy proposal from Eric Schmidt. This proposal is entered into the discussion phase with a deadline of 4 weeks - August 10th. Best Regards, Hans Petter Holen AC Chair 1.Number: #Eta 2.Policy Proposal Name: IPv6 Address Allocation and Assignment Policy - definition for "End-Site" 3.Author a.name: Eric Schmidt b.e-mail: erics(a)t-com.net c.telephone: ++49 441 234 4592 d.organisation: Deutsche Telekom AG 4.Proposal Version: 5.Submission Date: 2005-05-13 6.Suggested WG for discussion and publication: address-policy-wg or ipv6-wg 7.Proposal type: modify a.new, modify, or delete. 8.Policy term: permanent a.temporary, permanent, or renewable. 9.Summary of proposal There are various terms for "end-site" in the IPv6 allocation and assignment policy (ripe-267) and the RFC3177. We need to have a finally definition for "end-site" to establish clear internal assignment policies 10. Policy text a.Current (if modify): 2.9. End Site An End Site is defined as an End User (subscriber) who has a business relationship with a service provider that involves: that service provider assigning address space to the End User that service provider providing transit service for the End User to other sites that service provider carrying the End User's traffic that service provider advertising an aggregate prefix route that contains the End User's assignment b.New: 2.9 End Site End-Site defines a customer´s network with an own link to the ISP. The customer could run various networks on different locations (e.g. multiple branches). As long as the networks are all independent and have no internal connection, each network is defined as a single end-site. If the networks have internal connection and only one common link to the ISP, these networks are summarized to one end-site. 2.9a A customer is an End User (subscriber) who has a business relationship with a service provider that involves: that service provider assigning address space to the End User that service provider providing transit service for the End User to other sites that service provider carrying the End User's traffic that service provider advertising an aggregate prefix route that contains the End User's assignment 11. Rationale: a.Arguments supporting the proposal At last we will have a concrete definition for end-site. There are a lot of discussions even in different RIR regions and as far as i know non of this has reached an conclusion. The rfc3177 defines end site as single edge networks, this is pretty close to my proposal and i think it is easier to update a RIPE policy than an rfc. This question was discussed in the IPv6 maillist before and it looks like that this definition could get a majority approval In the IPv6 End User Site Assignment Request Form (ripe-308) the requester has to confirm that he read the policy document. It is hard for a customer to understand these improper terms. This proposal should not be combined with the /48 /56 discussion which is on at the moment. It´s just a matter of definition b.Arguments opposing the proposal i can´t see anything against this .....

8 12

RE: [address-policy-wg] last Call: Policy proposal #beta HD ratio policy proposal
by BIDRON Alain ROSI/DAS 13 Jul '05

13 Jul '05

Dear Karsten, When you manage an X-large registry you have several levels of management. In such a situation, meeting the 80% criteria is much more difficult (if possible) than with a small registry with only one level. The proposal is clearly not to advantage or to disadvantage some registries but simply to take into account in fair way different situations in order to have enough flexibility for a better management. Regarding the support from the community, I have to mention that this proposal was considered by ETNO, whose members representing are a large part of X large registries in the RIPE region, and unanimously supported. You can find this expression for support at www.etno.be Document EC064. Leo Debecker posted this contribution from ETNO to the mailing list. Be aware that this support comes from the following ETNO members. This is not one voice but 41. · Auna Telecomunicaciones · Belgacom · BH Telecom (Bosnia and Herzegovina) · BT (British Telecom) · BTC (Bulgarian Telecommunications Company) · Cesky Telecom · Community of Yugoslav PTT · Croatian Telecom · Cyprus Telecommunications Authority · Deutsche Telekom · Eircom · Elion Enterprises Ltd · Elisa Communications Corporation · Entreprise des Postes et Télécommunications Luxembourg · Finnet Group · France Telecom · Invitel · Koninklijke KPN · Lattelekom · Makedonski telekomunikacii · Maltacom · Matáv Hungarian Telecommunications Company · Netia S.A. · OTE · Portugal Telecom · Rom Telecom · Síminn (Iceland Telecom Ltd.) · Slovak Telecom · Societatea Nationala de Radiocomunicatii (SNR) · Swisscom · TDC · Tele 2 · Telecom Italia · Telefonica · Telekom Austria · Telekom Slovenije · Telekomunikacja Polska · Telenor · TeliaSonera · Türk Telekomünikasyon · VIPnet Regards -----Message d'origine----- De : address-policy-wg-admin(a)ripe.net [mailto:address-policy-wg-admin@ripe.net]De la part de Koepp, Karsten Envoyé : jeudi 7 juillet 2005 12:34 À : 'Hans Petter Holen' Cc : address-policy-wg(a)ripe.net Objet : RE: [address-policy-wg] last Call: Policy proposal #beta HD ratio policy proposal Hello Hans Petter and al, I am AGAINST the proposal. I would like Alain to better explain his need for better IP address management. He is the only voice I have seen *for* the proposal. Nobody is supporting Alain, instead Iljitsch has brought profound comments *against*, and there were some cynic comments - also *against*. >From my point of view, I would like to see the current policy remain in place, because with IPv4 we much more have a conservation than an aggregation goal (or an internal aggregation need) Large LIRs already receive /10s and I cannot see the proposal will have "some limited impact" on address consumption. If giant LIRs will only be mandated to occupy 52% instead of 80% of their v4-IPs (I have done this calculation for DTAG and FT), this is in my view going to cut our resources significantly. So, does the new PDP request a counter proposal to maintain current policy, I guess no, just enough people have to say no. Also, people in support of the proposal please raise your hands. regards Karsten eu.lambdanet > -----Original Message----- > From: Hans Petter Holen [mailto:hpholen@tiscali.no] > Sent: Friday, July 01, 2005 12:37 AM > Cc: address-policy-wg(a)ripe.net > Subject: [address-policy-wg] last Call: Policy proposal #beta HD ratio > policy proposal > > > Hans Petter Holen wrote: > Following the discussion on the mailinglist prior to and > after posting > the formal proposal I have seen no proposals to modify the > proposal and > would like to move the proposal into the conclustion phase in > the policy > development process http://www.ripe.net/ripe/draft-documents/pdp.html > > Last cal will end at July 15th. > > Best Regards > > Hans Petter Holen > WG Chair > > > Thanks Alain, > > I'll as the new PDP is not in operation yet, I'll add this > to my list > > as #beta v1 > > > > I propose that we enter into the Discussion phase for 4 weeks from > > date until April 4. > > > > -hph > > > > BIDRON Alain ROSI/DAS wrote: > > > >> Dear Colleagues > >> Referring to the minutes of the last RIPE Policy Working Group > >> meeting and to the action list as updated during that > meeting, I have > >> to make a formal proposal on use of HD ratio for IPV4. > >> Here is this policy proposal. > >> In order to be consistent with the PDP Draft proposal > coming from Rob > >> Blokzijl I have used the template provided in the new PDP proposal. > >> Best regards. > >> Alain > >> > >> > >> _________________________________________________________ > >> 1. Policy Proposal Name: IPv4-HD-Ratio > >> 2. Author > >> a. name: Alain Bidron > >> b. e-mail: alain.bidron(a)francetelecom.com > >> c. telephone: +33 1 44 44 27 75 > >> d. organisation: France Telecom > >> 3. Proposal Version: V0 > >> 4. Submission Date: 02/02/2005 > >> 5. Suggested WG for discussion and publication: Address Policy WG > >> 6. Proposal type: modify > >> 7. Policy term: permanent > >> 8. Summary of proposal: Internet address space is managed > >> hierarchically: > >> - IANA allocates space to Regional Internet Registries (RIRs). > >> - RIRs allocate space to Local Internet Registries (LIRs). > >> - LIRs assign space to End Users. > >> > >> At each level, some address space may be reserved for future > >> expansion and/or efficient aggregation. As more > hierarchical levels > >> are introduced, the overall efficiency of the address space usage > >> decreases. > >> > >> The HD ratio (Host-Density ratio) is a way to measure > address space > >> usage [RFC 3194]. The HD ratio value can relate to a percentage of > >> usage, which decreases as the amount of address space grows. This > >> allows for the decreasing efficiency that occurs with more > >> hierarchical levels. > >> > >> The HD ratio is currently used to measure IPv6 address space usage > >> [ipv6-address-policy]. The IPv6 Address Allocation and Assignment > >> Policy considers a block of IPv6 address space to be > 'used' when its > >> HD ratio reaches 0.80. This is a manageable figure > ("values of 80% or > >> less correspond to comfortable trade-offs between pain and > >> efficiency" [RFC 3194]). > >> > >> This document proposes using the HD ratio to measure IPv4 > usage. The > >> proposed value of the HD ratio for IPv4 is 0.96. > >> > >> 9. Policy text: > >> a. Current: "An LIR may receive an additional allocation > when about > >> eighty percent (80%) of all the address space currently > allocated to > >> it is used in valid assignments or sub-allocations." > >> b. New: "An LIR may receive an additional allocation when > its total > >> allocated address space usage meets the HD-Ratio value of 0.96." > >> > >> 10. Rationale: > >> > >> a. Background > >> The current document, "IPv4 Address Allocation and Assignment > >> Policies for the RIPE NCC Service Region" [ipv4-address-policy], > >> considers a block of IPv4 addresses to be 'used' when 80% of the > >> addresses within the block have been sub-allocated or > assigned. This > >> is applied to all address blocks, regardless of size. > >> Current policies assume a hierarchical system of address space > >> delegation. However, they do not make any allowance for > hierarchical > >> management within allocated address space. For LIRs in > particular, a > >> hierarchical approach is often required for assignment of address > >> space to service elements such as customer networks, individual > >> Points of Presence (PoPs), regionalised topologies, and > even distinct > >> ISP products. Small network infrastructures may require simple > >> hierarchies, but large infrastructures can require several > levels of > >> address space subdivision. These levels of hierarchy are not > >> recognised by the current policy framework and are highly > restricted > >> by the "80% rule". As a result, managing large blocks is often > >> difficult, requiring large internal routing tables and/or frequent > >> renumbering of internal address blocks. > >> > >> One of the goals of the RIR system is to avoid unnecessary > depletion > >> of IPv4 address space. However, address management > policies must also > >> be practical in terms of how much management overhead they cause. > >> When large amounts of address space are involved, the "80% > rule" can > >> result in more work for an LIR. > >> > >> Basing usage on the HD ratio should lead to equal levels of > >> management overhead across the board, rather than penalising the > >> holders of large address blocks. > >> > >> b.Impact > >> To see a rough estimation of the immediate impact of this > proposal, > >> an HD Ratio value of 0.96 was applied to the average amount of > >> address space held by an LIR in the RIPE NCC Service Region. This > >> showed that on average, LIRs would qualify for an additional > >> allocation block when they have assigned or sub-allocated > about 59% > >> of their allocated address space. > >> > >> c.Arguments supporting the proposal. > >> This proposal fairly takes into account addressing > hierarchies used > >> in large and extra-large registries and introduces a > useful level of > >> flexibility for those registries > >> The local Internet registries using the 80% criteria may > continue to > >> do so and will not be impacted by the new policy. > >> The RIPE NCC will provide support to minimise complicated > >> calculations or administrative burden to LIRs. > >> > >> d. Arguments opposing the proposal. > >> This proposal will have some limited impact on IPV4 > address consumption. > >> > >> > >> > >> > >> Appendix A. The HD ratio > >> > >> The HD ratio is calculated as follows [RFC 3194]: > >> > >> HD = log(U)/log(S) > >> > >> Where: > >> > >> S is the size of the address block concerned, and > U is > >> the number of addresses used. > >> > >> Note: The current IPv4 policy considers addresses to be > 'used' once > >> they are assigned or sub-allocated by the LIR. > >> Appendix B. Selection of HD ratio value > >> > >> We should decide an appropriate HD ratio value on a > rational basis. > >> To do this, we make certain assumptions about the number > of "hidden" > >> hierarchical levels involved in managing address blocks of various > >> sizes. If we assume there is 80% usage at each level, we > can easily > >> calculate the overall usage. > >> > >> The following table proposes a set of hierarchical levels which we > >> can reasonably expect within different amounts of address > space. If a > >> usage of 80% is achieved at each hierarchical level, then > the overall > >> usage will be (0.80 to the power of "n"). It is then possible to > >> calculate HD ratio values from this value. > >> > >> Size range Level Utilisation HD ratio > >> (prefix) (n) (0.80**n) (calculated) > >> /24 to /20 1 80% > .960 to .973 > >> /20 to /16 1.5 72% > .961 to .970 > >> /16 to /12 2 64% > .960 to .968 > >> /12 to /8 2.5 57.2% > .960 to .966 > >> /8 to /4 3 51.20% > .960 to .966 > >> The levels of hierarchy listed above are based on assumptions > >> about the likely size and structure of LIRs holding > address blocks of > >> these sizes. A reasonable HD ratio value may be 0.96 (a > round figure > >> which occurs within most of these ranges) from the table > above. The > >> following table gives the usage requirements for IPv4 > address blocks > >> from /24 to /8 for this value. > >> > >> IPv4 Addresses Addresses > Util% > >> prefix total used > >> 24 256 > 205 > >> 80.11% > >> 23 512 399 > 77.92% > >> 22 1024 776 > 75.79% > >> 21 2048 1510 > 73.71% > >> 20 4096 2937 > 71.70% > >> 19 8192 5713 > 69.74% > >> 18 16384 11113 > 67.83% > >> 17 32768 21619 > 65.98% > >> 16 65536 42055 > 64.17% > >> 15 131072 81811 > 62.42% > >> 14 262144 159147 > 60.71% > >> 13 524288 309590 > 59.05% > >> 12 1048576 602249 > 57.43% > >> 11 2097152 1171560 > 55.86% > >> 10 4194304 2279048 > 54.34% > >> 9 8388608 4433455 > 52.85% > >> 8 16777216 8624444 > 51.41% > >> > >> Note: This table provides values for CIDR blocks, but the same > >> calculations can be made for non-CIDR blocks. > >> > >> As an example, an LIR holding a total amount of address > space equal > >> to a /16 would be able to receive more address space when they had > >> sub-allocated or assigned 64.17% of that space; while an > LIR holding > >> a /9 would be able to receive more space when they had > sub-allocated > >> or assigned 52.85% of their address space. > >> > >> Appendix C. References > >> [RFC 3194] "The Host-Density ratio for address assignment > efficiency: An > >> update on the H ratio", A. Durand, C.Huitema, November 2001. > >> [ipv6-address-policy] RIPE NCC document: "IPv6 Address > Allocation and > >> Assignment Policy" > http://www.ripe.net/ripe/docs/ipv6policy.html > >> [ipv4-address-policy] RIPE NCC document: "IPv4 Address > Allocation and > >> Assignment Policies for the RIPE NCC Service Region" > >> http://www.ripe.net/ripe/docs/ipv4-policies.html > >> > >> > >> > >

2 1