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

New IPv4 blocks allocated to the RIPE NCC
by Filiz Yilmaz 05 Jul '05

05 Jul '05

Dear Colleagues, The RIPE NCC received the IPv4 address ranges 89.0.0.0/8, 90.0.0.0/8 and 91.0.0.0/8 from the IANA in June 2005. We will begin allocating from these ranges in the near future. The longest prefixes to be allocated and assigned from these /8s are as follows: IPv4 Range Longest Prefix 89/8 /21 90/8 /21 91/8 /29 You may wish to adjust any filters you have in place accordingly. You can find more information on the IP space administered by the RIPE NCC on our website at: https://www.ripe.net/ripe/docs/ripe-ncc-managed-address-space.html Kind regards, -- Filiz Yilmaz RIPE NCC

1 0

Policy Proposal: #epsilon Policy text modifications to take account of,ICANN recognition of AfriNIC as a fully functioning RIR.
by Hans Petter Holen 01 Jul '05

01 Jul '05

Dear All, With the formal recognition of AfriNIC as a fully functioning RIR there is no need to still have special policy provisions for the AfriNIC region in the RIPE NCC region. http://www.nro.net/archive/news/20050411-afrinic-final-recognition.html As I do not expect much discussion on this Item I propose to end the discussion period by May 1st. 1.Number (assigned by the RIPE NCC) #epsilon 2.Policy Proposal Name: Policy text modifications to take account of ICANN recognition of AfriNIC as a fully functioning RIR. 3.Author a.name: Adiel Akplogan b.e-mail: adiel(a)afrinic.net c.telephone:+230 259 2409 d.organisation: AfriNIC 4.Proposal Version: 1.0 5.Submission Date: 6.Suggested WG for discussion and publication Address Policy Working Group 7.Proposal type: modify a.new, modify, or delete. 8.Policy term: renewable a.temporary, permanent, or renewable. 9.Summary of proposal To modify the policy document text to reflect full recognition of AfriNIC as a functioning RIR. 10. Policy text a.Current (if modify): "1.0 Introduction The RIPE NCC is an independent association and serves as one of four Regional Internet Registries (RIRs). Its service region incorporates Europe, the Middle East, Central Asia and African countries located north of the equator." b.New: "1.0 Introduction The RIPE NCC is an independent association and serves as one of /five/ Regional Internet Registries (RIRs). Its service region incorporates Europe, the Middle East, and Central Asia." a.Current (if modify): "5.1 First Allocation The RIPE NCC's minimum allocation size is /21. The minimum allocation size for countries in Africa is /22." b.New: "5.1 First Allocation The RIPE NCC's minimum allocation size is /21." 11. Rationale: a.Arguments supporting the proposal With the recognition of AfriNIC as a fully functioning and independant RIR there is a need to modify this document reflecting this change. b.Arguments opposing the proposal None.

1 1

HD ratio policy proposal
by BIDRON Alain ROSI/DAS 01 Jul '05

01 Jul '05

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 2

Policy Proposal: #Zeta Adding Regional Boundaries to policy documents
by Hans Petter Holen 01 Jul '05

01 Jul '05

Dear Address Policy WG, This policy proposal is nothing more than an editorial change - but we still feel it is fair to run it trough the PDP. As I do not expect much discussion I propose the discussion phase to end by May 1st. While I am voicing this proposal the suggestion actualy comes from our excellent RIPE NCC staff. Thanks leo for pointing this out. Best Regards Hans Petter Holen Address Policy 1. Number Zeta 2. Policy Proposal Name: Adding Regional Boundaries to policy documents 3. Author a. name: Hans Petter Holen b. e-mail: hpholen(a)tiscali.no c. telephone: +47 45066054 d. organisation: Visma IT AS 4. Proposal Version: 5. Submission Date: 16/4-2005 6. Suggested WG for discussion and publication Address policy type 7. Proposal type: a. modify 8. Policy term: a. permanent 9. Summary of proposal Our AS assignment policy has the following statement in it: "The RIPE NCC assigns AS Numbers for Autonomous Systems located in the RIPE NCC service region" Neither the IPv4 nor the IPv6 policy documents have such a clear statement in them. It might be a good idea to add a similar statement to those documents when they are updated. 10. Policy text a. Current (if modify): b. New: 11. Rationale: a. Arguments supporting the proposal Clearification of the scope of the documents b. Arguments opposing the proposal n/a

1 2

NRO Comments on Proposed Review Procedure for ASO Policy Proposals
by Axel Pawlik 22 Jun '05

22 Jun '05

Dear Colleagues, On 17 June 2005, the Number Resource Organization submitted to ICANN their comments to the updated Proposed Review Procedure for ASO Policy Proposals. These comments can be found on the NRO website at: http://www.nro.net/documents/nro25.html The proposed review procedure is available from the ICANN website at: http://www.icann.org/announcements/announcement-31may05.htm Regards, Axel Pawlik Managing Director RIPE NCC

1 0

Statements to the Working Group on Internet Governance (WGIG)
by Axel Pawlik 16 Jun '05

16 Jun '05

Dear Colleagues, During the fourth Working Group on Internet Governance (WGIG) Meeting, the Number Resource Organization (NRO) released a statement on the role of ICANN and governments in the management of Internet resources and global technical co-ordination. The original document is on the NRO website at: http://www.nro.net/documents/nro24.html The Address Supporting Organization Address Council (ASO AC) also submitted a statement on the role of the Regional Internet Registries in global allocation policy. The original document is on the ASO website at: http://www.aso.icann.org/documents/wgig-comments-v31.pdf All other statements submitted to the fourth WGIG Meeting can be found at: http://www.wgig.org/ Regards, Axel Pawlik Managing Director RIPE NCC

1 0

ICANN Call for Comments on Proposed Review Procedure for ASO Policy Proposals
by Axel Pawlik 06 Jun '05

06 Jun '05

Dear Colleagues, ICANN has called for a second round of public comments on the "Review Procedure to Handle Policy Proposals Submitted by the ASO Address Council in Line with the ASO MoU." Comments received from the first public comment period have been analysed and considered in the updated version of the procedure, which is posted for a second round of public comments on the ICANN website. All members of the Internet community are invited to submit their comments. For further information and to submit comments, please visit the ICANN website at: http://www.icann.org/announcements/announcement-31may05.htm The deadline for comments is 21 June 2005. Regards, Axel Pawlik Managing Director RIPE NCC

1 0

RIPE 50 Report
by Nick Hyrka 25 May '05

25 May '05

[Apologies for duplicate e-mails.] RIPE 50 Report Dear Colleagues, The RIPE 50 Meeting took place from 2 - 6 May 2005 at the Clarion Hotel, Stockholm, Sweden. There were over 375 participants at the meeting. Attendees also included government representatives and representatives from AfriNIC, APNIC, ARIN, LACNIC and ICANN. HIGHLIGHTS Highlights of RIPE 50 included: - The successful implementation of the new RIPE Meeting format into three days on operational and technical content followed by two days on policy related issues. - An update on the ICANN ASO Address Council. This presentation is available at: http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50-plenary-fri-… - A commentary on the ITU-T Proposal for National Address Registries for IPv6 by Geoff Huston, APNIC. This presentation is available at: http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50-plenary-wed-… - Final discussion on the RIPE Policy Development Process. More information about this will appear on www.ripe.net shortly. Afilias, Arbor Networks, Cisco Systems, Force10 Networks, Netnod, NIKHEF, Nokia, TeliaSonera and the RIPE NCC are thanked for the support they provided to the meeting. TeliaSonera are thanked for the provision of the meeting Internet connectivity. PRESENTATIONS All the Plenary and Working Group presentations from RIPE 50 can be viewed at: http://www.ripe.net/ripe/meetings/ripe-50/presentations/index.html SUMMARY ADDRESS POLICY WORKING GROUP - It was agreed that the Address Policy Working Group Chairs will make a formal proposal that global policies should go through the RIPE Policy Development Process. - There was discussion on the TLD anycast allocation policy proposal, the IPv6 proposal to remove the 200 customers requirement, the proposal for removal of the Africa Special Policy, the proposal to add regional boundaries to policy documents and the IPv4-HD-Ratio proposal. ANTI-SPAM WORKING GROUP - There was discussion on whether ripe-206 should be revised to reflect the updates to the LINX BCP document that was used as the base for the original ripe-206. - There was discussion about anti-spammers sometimes behaving worse than spammers, and action placed on the Working Group Chair to start work on a document for best practise for spam complaints. DATABASE WORKING GROUP - It was agreed that a proposal on the "country:" attribute should be prepared. This will be done by the RIPE NCC. - It was noted that changes to the RIPE Database for abuse are now in production. DNS WORKING GROUP - It was agreed that the DNS Working Group Chair will produce a proposal to solve the problem that changes to reverse DNS nameservers cannot have multiple names. - There was discussion on whether the DNS Working Group should take over the work to produce a RIPE Document on AAAA resolution issues. - It was agreed that the RIPE NCC will produce statistics on anycast placement for K-root and the RIPE region Hostcount in time for RIPE 51. - It was noted that DNSSEC RFCs have been published, and that DNSSEC is being tested in Sweden in the .se domain. EIX WORKING GROUP - It was noted that the Switching Wish-List Version 3.0 will be published soon by Mike Hughes, and that version 3.1 will be published after RIPE 51. - There was discussion about public versus private peering. ENUM WORKING GROUP - It was agreed that Niall O'Reilly and Carsten Schiefner will be the new ENUM Working Group Chairs. - It was noted that the IETF is continuing work on ENUM standards. - It was agreed that the ENUM Working Group will continue to work as it has in the past, with an emphasis on the exchange of operational experience. IPV6 WORKING GROUP - It was decided that the RIPE Whois Database will continue to include more services that run in native IPv6. - It was agreed that the community needs to produce a revised Internet draft before RIPE 51 to formally address the demands of RFC3177, particularly the /48 recommendation. - It was noted that the IPv6 Working Group needs to decide where it wishes to house the new, operational IPv6 mailing list. RIPE NCC SERVICES WORKING GROUP - There was discussion on the value of the Hostcount. It was agreed that the RIPE NCC should continue working on this, and that the RIPE NCC should write and put a new Hostcount into service. ROUTING WORKING GROUP - There was discussion on route flap damping and de-aggregation practices raised by Philip Smith in the RIPE 50 Plenary. - Lorenzo Colliti (RIPE NCC) presented the research work of Roma Tre University on active BGP probing to discover AS level topology of the Internet. TEST TRAFFIC WORKING GROUP - It was agreed that the community should provide a proposal on how TTM infrastructure could be used to certify the quality of service provided by ISPs and to verify Service Level Agreements. - Henk Uijterwaal gave an update on the status of the TTM project - Thomas Wana presented work done to improve the accuracy of TTM time measurements and a proposal to create even greater accuracy by using DAG cards for measurement. - There was discussion on the future directions for the TTM project and it was agreed that the TTM infrastructure and measurements could be leveraged to certify the quality of service provided by ISPs. The Working Group agreed that the RIPE NCC, as a trusted third party, could perform the measurements and publish the results. CO-LOCATED PEERING BoF Netnod, LINX and AMS-IX hosted a peering BoF co-located at RIPE 50 on Sunday, 1 May, where peering policies were presented. CO-LOCATED LOBSTER TUTORIAL A tutorial entitled "Passive Network Traffic Monitoring" was organised on Friday, 6 May, by the consortium of LOBSTER, a European IST Project on Large-Scale Monitoring of Broadband Internet Infrastructures. RIPE 50 WEBCASTING AND ARCHIVES During RIPE 50, the RIPE NCC collected feedback from participants watching the webcast and listening to the audiocasts. The mediums used for this were IRC and Jabber. Archives of presentations, webcasts and IRC/Jabber feedback from RIPE 50 are available at: http://www.ripe.net/ripe/meetings/ripe-50/sessions-archive.html HOSTMASTER CONSULTATION CENTRE (HCC) The RIPE NCC Hostmaster Consultation Centre was open at RIPE 50, allowing RIPE NCC Members to discuss issues relating to their business directly with RIPE NCC Hostmasters. "MEET & GREET" The RIPE NCC's "Meet & Greet" was available for first-time RIPE Meeting attendees at RIPE 50. "Meet & Greet" introduces newcomers to the meetings, to key attendees from the RIPE community and to social events throughout the week. More information can be obtained by contacting <meet-greet(a)ripe.net>. RIPE 50 REFERENCE PAGE A complete list of RIPE 50 sessions, tutorials and presentations can be found at: http://www.ripe.net/ripe/meetings/ripe-50 RIPE 51 RIPE 51 will be held in Amsterdam, the Netherlands from 10 - 14 October 2005. Information on RIPE 51 is available at: http://www.ripe.net/ripe/meetings/ripe-51 If you have any questions about RIPE Meetings, please contact <meeting(a)ripe.net>.

2 1

IPv4 allocation monitoring tool
by Iljitsch van Beijnum 23 May '05

23 May '05

Hi, I've been looking at the IPv4 allocations lately, in order to figure out how soon we're going to run out. I made a little tool to search the data in different ways: http://www.bgpexpert.com/addrspace.php It doesn't do anything fancy: just collect the public stats from the different RIR FTP servers once in a while and dump the records in a database, which can then be searched with the page above, with results such as: RIR Country Addresses Date 78.51 M 2000 89.02 M 2001 69.02 M 2002 87.67 M 2003 123.93 M 2004 79.86 M 2005 Another interesting one: RIR Country Addresses Date US 1305.90 M JP 138.33 M EU 114.01 M Let me know if you have any questions or suggestions. Iljitsch van Beijnum

2 1

RIPE DB: disclosure of commertial information
by Max Tulyev 20 May '05

20 May '05

Hi! I have very strange situation. One company I support, an ISP, wants to become a LIR. But they do not want to put information about their clients' assignments into the RIPE DB, because of there is a possibility to steal clients (most of them - major clients) using RIPE DB, and they says that there already was some incidents. Really, you can see RIPE DB for assignments of LIR to have its client list with name of organisation, size (larger client have larger assignment), address, phone, fax, email, and even administrative and technical contact persons. Only you need to do - is to send (or even talk with) better offer addressing it to certain people... What do you think about it? -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)

13 19