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

2005-02 Draft Document will be produced (IP Assignments for anycasting DNS)
by RIPE NCC Policy Coordinator 26 Jan '06

26 Jan '06

PDP Number: 2005-02 IP Assignments for anycasting DNS Dear Colleagues The discussion period for the new RIPE Document described in 2005-02 has ended. A draft document will now be prepared for review. We will publish the document shortly. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2005-2.html Regards Adrian Bedford RIPE NCC

1 0

Policy Proposal Withdrawn - 2005-04
by RIPE NCC Policy Coordinator 24 Jan '06

24 Jan '06

Dear Colleagues PDP Number: 2005-04 IPv6 Address Allocation and Assignment Policy - Definition for "End-Site" The proposed change to RIPE Document ripe-267 has been withdrawn. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2005-4.html Regards Adrian Bedford RIPE NCC

1 0

200 customer requirements for IPv6
by Marc van Selm 18 Jan '06

18 Jan '06

Following up on the discussion during RIPE-51, I have not heard much discussion on "200 customer requirement for IPv6" rule. So I would like to hear your views on this. During RIPE-51 the proposal to remove the rule caught serious objections. I can sympathise with those but I do have an issue that I'd like feedback on. I am investigating how NATO should acquire IPv6 address space. NATO will use multiple transmission providers, NATO owned transmission and national networks. Also transmission contracts will have to be opened for bidding every few years. That makes requesting IP space from an ISP a non starter. So we explore the LIR route. Note that NATO has a service provider under its umbrella that provides service towards the other NATO organisations. They operate independently and are like an ISP (and more) for that matter. They are just not selling outside NATO. At this time it is reasonably hard to specify the 200 /48 that will be given out for the "IPv6 Initial Allocation Request". Having reached about 130 or so on my list (not finished yet) I can't help wondering why RIPE-NCC should care about a list of sites that they only a vague clue of what they are and have no means of verification if the list is correct. Having said that, I get the feeling that the 200 rule only ads admin overhead and has limited actual power. Now NATO could include a summarised version in the Initial Allocation and do something like: Subnet: /48 1 year 5 regional sites (/48 per site = 5x /48) Subnet: /48 1 year 20 subordinate sites to the 5 regional sites (/48 per site = 5x 20x /48 = 100 /48) Subnet: /48 2 year 40 deployed elements (/48 per site = 40x /48) Subnet: /48 2 year 70 Crisis Response Operation locations (/48 per location = 70 x /48) Total: 215x /48 Note that the numbers are fiction but they are not very unrealistic as we also need to include standby elements that are ready to go (power up, aim dish and run) systems. Although close to the truth, RIPE-NCC would have no way of verifying this and providing a detailed list would bury RIPE-NCC in details that they don't care about and also cannot verify. I can't help feeling this rule is written for ISPs but will be counter productive for NATO and organisations with a very large privately operated enterprice network. I also can't help the feeling that its a paper tiger. So isn't there another way to achieve the same result as this rule was intended for? Any views? Marc -- Marc van Selm NATO C3 Agency CIS Division E-mail: marc.van.selm(a)nc3a.nato.int (PGP capable)

23 75

FW: AfriNIC to start allocating from 41/8
by leo vegoda 18 Jan '06

18 Jan '06

Dear Colleagues, The announcement below is should be of interest. Regards, -- leo vegoda RIPE NCC Registration Services Manager -----Original Message----- From: afrinic-discuss-bounces(a)afrinic.net [mailto:afrinic-discuss-bounces@afrinic.net] On Behalf Of Ernest, B.M (AfriNIC - ZA) Sent: 16 January 2006 12:59 To: afrinic-discuss(a)afrinic.net Cc: ioz(a)internet.org.za; afnog(a)afnog.org Subject: [afrinic-discuss] AfriNIC to start allocating from 41/8 Dear Colleagues, As you may be aware, AfriNIC received a 41/8 block from IANA in April 2005. With effect from February 2006, all IPv4 address space allocated within the AfriNIC service region will be made from 41/8. The 196/8 block previously used for allocations in AfriNIC service region will now be used only for direct end-user (PI) assignments. This is therefore a notice that any filters you have may need appropriate adjustments. Kind regards, Ernest, AfriNIC. _______________________________________________ afrinic-discuss mailing list afrinic-discuss(a)afrinic.net http://lists.afrinic.net/mailman/listinfo.cgi/afrinic-discuss

1 0

ASO Call for Nominations for ICANN Board Seat
by Paul Rendek 06 Jan '06

06 Jan '06

[Apologies for duplicate e-mails] This message is sent on behalf of the Address Supporting Organization: Dear Colleagues, In compliance with the ASO MoU and ICANN bylaws the Address Council hereby calls for nominations to the ICANN Board to fill the ASO seat currently held by Mouhamet Diop, whose term expires in June of 2006. This nomination period will close on April 4, 2006. Nominations may be submitted by anyone by sending email to: nominations(a)aso.icann.org. Nominations must include the following information: • Full name of person being nominated • Contact email address for person being nominated • Contact telephone number (if available) of the person being nominated • Full name of the person making the nomination • Contact email address for the person making the nomination • Contact telephone number of the person making the nomination Nominations will be reviewed in accordance with the ASO Board of Directors selection procedures, as documented on the ASO website. ASO Secretariat http://www.aso.icann.org

1 0

RIPE 51 Report
by Nick Hyrka 05 Jan '06

05 Jan '06

[Apologies for duplicate e-mails.] RIPE 51 REPORT The RIPE 51 Meeting took place from 10 - 14 October 2005 at the Hotel Krasnapolsky, Amsterdam, the Netherlands. There were 320 attendees at the meeting. Attendees also included government representatives and representatives from AfriNIC, APNIC, ARIN, LACNIC and ICANN. Highlights of RIPE 51 included the announcement of the RIPE NCC E-learning Centre, a free online resource available to both members of the RIPE NCC and non-members. More information about the E-Learning Centre is available at: http://e-learning.ripe.net Global Crossing, the Amsterdam Internet Exchange, Force10 Networks and the RIPE NCC are thanked for the support they provided to the meeting. Global Voice Networks are thanked for the provision of the meeting Internet connectivity. PRESENTATIONS All the Plenary and Working Group presentations from RIPE 51 can be viewed at: http://www.ripe.net/ripe/meetings/ripe-51/presentations/index.html SUMMARY OF WORKING GROUP SESSIONS ADDRESS POLICY WORKING GROUP Action Points: The text for the policy proposals below will be reviewed by the following people, after concerns were raised by the working group: - #2005-02: TLD anycast allocation policy (Andreas Baess); - #2005-03: Removal of the 200 customer assignments requirement and referral to /48 assignments from the IPv6 initial allocation criteria (Andy Furnell); - #2005-04: IPv6 Address Allocation and Assignment Policy definition for end site (Eric Schmidt); - #2005-08: Proposal to Amend the IPv6 Assignment and Utilisation Requirement Policy (Geoff Huston and Kurtis Lindqvist). The working group chairs will set deadlines for discussion after these reviews. Highlights: The working group discussed the six policy proposals that are currently ongoing. The list of current proposals can be seen at: http://www.ripe.net/ripe/policies/proposals/ The working group agreed that a session should be scheduled at a future RIPE Meeting to discuss what mechanisms the community needs for a working Internet after the exhaustion of IPv4 address space. ANTI-SPAM WORKING GROUP Action Points: - Rodney Tillotson: Submit LINX BCP as a revised ripe-206 using the Policy Development Process (PDP). Highlights: - The document on which ripe-206 is based has been updated, and ripe-206 will be revised. - Greylisting discussion showed some consider it harmful, and some use it. - DKIM is an up-and-coming authentication technique. DATABASE WORKING GROUP Action Points: - RIPE NCC: Change the behaviour of the RIPE Whois Database server to return IRT objects by default. - RIPE NCC: Contact anti-spam tool writers to make them aware of the default behaviour change regarding IRT objects. - Peter Koch: Start a Policy Development Process to deprecate CRYPT-PW authorisation in the RIPE Whois Database. - RIPE NCC: Write a document describing the use of the IRT object in the RIPE Whois Database. - Wilfried Woeber: Start a Policy Development Process proposal to make the "country:" attribute in inet(6)num object optional and multiple. - RIPE NCC: Check Gnu Privacy Guard (GnuPG) compatibility before implementing changes to the RIPE Whois Database to prevent replay attacks. - RIPE NCC: Check if contacts can be properly mapped in IRIS (admin-c and tech-c). - RIPE NCC: Check what are other missing attributes in IRIS that are needed for the RIPE community. - Matt Rowley (ARIN): Check if other Routing Registries support RPSLng. - RIPE NCC: Implement the proposed DNSSEC changes. Highlights: - It was noted that there is an ongoing effort for improving documentation regarding the RIPE Whois Database. - It was noted that IRIS prototype server is now implemented and run by the RIPE NCC. DNS WORKING GROUP Action Points: - 51.1 RIPE NCC/Andrei Robachevsky: Agree with RIRs on a date for decommissioning of IP6.INT reverse mapping services. Outline and communicate procedure to be followed based on the presentation made during the working group session. - 51.2 Lars-Johan Liman: Draft a proposal on the future of the RIPE NCC Secondary DNS Service. To be dealt with in co-operation with the RIPE NCC Services Working Group. - 51.3 Peter Koch: Draft text and initiate discussion on the mailing list towards an update of ripe-203 along the lines of the presentation brought to the working group. - 51.4 Carsten Schiefner: Provide text for a proposal for the RIPE NCC to implement ENUM DNS predelegation checks. Also explore the field of regular post delegation sanity checks in the e164.arpa tree. Highlights: - Peter Koch announced that the Policy Proposal 2005-07, "Introducing DNSSEC Service to Reverse DNS Trees" had now completed its run through the formal Policy Proposal Process. As the DNS Working Group Chairs had received no formal objections to it, they declared consensus had been reached. The policy is now published as a RIPE Document: http://www.ripe.net/ripe/docs/ripe-359.html EIX WORKING GROUP Action Points: There were no actions from this working group. Highlights: - The minutes of the RIPE 50 EIX Working Group were approved. - There were 13 short IXP update presentations from EURO-IX, AMS-IX, DE-CIX, INEX, LINX, NDIX, LONAP, Netnod, NIX, NIX.CZ, SFINX, Terremark, VIX. - It was agreed that the as-set object is the appropriate object for showing members of internet exchanges on the RIPE Database. - There was a presentation by Mike Hughes from LINX about Voice over Internet Protocol (VoIP) peering. The presentation questioned people's assertions about the subject, and pointed out how the term had become somewhat overloaded. The presentation showed how VoIP peering affects IXPs, and what IXPs may want or not want to do in this area. ENUM WORKING GROUP Action Points: - RIPE NCC: Publish statistics from all e164.arpa servers. - Carsten Schiefner: Let the RIPE NCC know the details of missing links related to the indexation of requests. - RIPE NCC: Check whether the quarterly reports to the Internet Architecture Board (IAB) on ENUM operations are still necessary. - Peter Koch: Continue counting the reverse delegations in the 9.4.e164.arpa tree and report the results at RIPE 52. - Jim Reid: Stimulate discussion on testbed numbers/ranges. - Carsten Schiefner: Work with the RIPE NCC on ways to help improve the quality of DNS within the e164.arpa tree. - All: Help test Austria's ENUM reachability (see the message on the list). Highlights: - Work on ENUM-related IETF standards continues. - New deployment and operations statistics are being published. - Test activities are expanding. IPv6 WORKING GROUP Action Points: - 51.1 David Kessens: Ask the RIPE NCC to revise the acronym list in the registration package to remove obsolete terms as TLA & NLA Status: Completed - 51.2 RIPE NCC: Create a link from the IPv6 Working Group page to the APNIC events page: http://apnic.net/info/calendar/index.html Status: To be done - 51.3 RIPE NCC: Provide traffic reports on IPv6 usage during the RIPE meetings. If available, data from earlier meetings will be made available as well. Status: To be done RIPE NCC SERVICES WORKING GROUP There were no actions and highlights from this working group. ROUTING WORKING GROUP Action Points: - Philip Smith/Geoff Huston: Produce a document describing why route flap damping is harmful, and why ripe-229 no longer applies. Highlights: - There was discussion on route flap damping. It was agreed that ripe-229 on this subject is obsolete and should be replaced by a new document. It was agreed that this new document should describe why ISPs should not switch on flap damping in their routers, as well as explaining why and noting if there are any exceptions. - There was discussion on a possible Route Aggregation Policy. Joao will evaluate the feasibility of such a document together with some volunteers, including Mike Hughes and Philip Smith. - Arife Vural (RIPE NCC) presented an update on the status of the Routing Information Service (RIS) project. TEST TRAFFIC WORKING GROUP Action points: - RIPE NCC: Research the Multicast connectivity of the test-boxes. - All: Think about how to get more measurement nodes in TTM. Highlights: - Proposal to measure Multicast using TTM. - Consumer Broadband Measurements draft sent to the list and shortly discussed in the working group. - Discussion on how to measure DNSMON from more nodes worldwide. RIPE 51 WEBCASTING AND ARCHIVES During RIPE 51, 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 51 are available at: http://www.ripe.net/ripe/meetings/ripe-51/sessions-archive.html RIPE NCC MEMBER SERVICES CENTRE The RIPE NCC Member Services Centre was introduced at RIPE 51 as a replacement to the Hostmaster Consultation Centre and enabled attendees to talk face-to-face with representatives from the RIPE NCC Registration Services, Finance, Training, Software Engineering and Technical Departments. "MEET & GREET" The RIPE NCC's "Meet & Greet" was available for first-time RIPE Meeting attendees at RIPE 51. "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 51 REFERENCE PAGE A complete list of RIPE 51 sessions and presentations can be found at: http://www.ripe.net/ripe/meetings/ripe-51 RIPE 52 RIPE 52 will be held in Istanbul, Turkey from 24 - 28 April 2006. More information on RIPE 52 will soon be available at: http://www.ripe.net/ripe/meetings/ripe-52/index.html If you have any questions about RIPE Meetings, please contact <meeting(a)ripe.net>.

1 0

Final Reminder: RIPE NCC Regional Meeting Qatar, 17-18 January 2006
by Paul Rendek 03 Jan '06

03 Jan '06

[Apologies for duplicate e-mails] Dear Colleagues, Registration will soon close for the RIPE NCC Regional Meeting, taking place at the Doha Marriott Hotel, Qatar, 17-18 January 2006. Registration will close on Friday, 13 January 2006. If you have not yet registered, please register today at: www.ripe.net/qatar2006/register MEETING AGENDA This RIPE NCC Regional Meeting is specifically designed to provide participants with a forum to discuss topics related to IP networking in the Middle East region. The latest draft meeting agenda is available at: http://www.ripe.net/meetings/regional/qatar-2006/agenda.html SEMINARS All meeting attendees are invited to attend the RIPE NCC seminars taking place on Wednesday 18 January, from 14:00. - The DNSSEC Seminar aims to outline the features of DNSSEC and related tools and introduces the relevant RIPE NCC services. - The Routing Registry (RR) Seminar aims to teach the features of Routing Registry and related tools, introduce the relevant RIPE NCC services and explain the basics of Routing Policy Specification Language (RPSL). SCHEDULE AN APPOINTMENT WITH RIPE NCC IP RESOURCE ANALYSTS During the meeting, attendees can schedule an appointment with RIPE NCC IP Resource Analysts to discuss issues relating to their business. For more information, or to schedule an appointment, please see: http://www.ripe.net/meetings/regional/qatar-2006/ip-resource-analysts.html MORE INFORMATION Attendance to RIPE NCC Regional Meetings is open and free of charge. However, attendees are responsible for covering their own travel and accommodation costs. More details about the RIPE NCC Regional Meeting in Qatar are available at: http://www.ripe.net/qatar2006 Please send any questions to: <contact(a)ripe.net> Regards, Paul Rendek Head of Member Services & Communications RIPE NCC

1 0

2005 IPv4 Address Use Report
by Iljitsch van Beijnum 01 Jan '06

01 Jan '06

According to AfriNIC, APNIC, ARIN, LACNIC and RIPE NCC statistics as published on their respective FTP servers, they gave out 165.45 million IPv4 addresses in 2005. Out of 3706.65 million usable IPv4 addresses, 1468.61 million are still available as of januari 1, 2006. Breakdown by Regional Internet Registry over the past few years: 2000 2001 2002 2003 2004 2005 AfriNIC 0.56 0.38 0.25 0.21 0.51 1.89 APNIC 21.08 28.84 27.08 33.08 42.92 53.97 ARIN 30.96 32.76 21.02 22.14 33.51 36.30 LACNIC 0.88 1.57 0.65 2.62 3.77 11.04 RIPE NCC 24.88 25.39 19.94 29.72 47.75 62.25 Total 78.35 88.95 68.93 87.77 128.45 165.45 AfriNIC gives out address space in Africa, APNIC in the Asia-Pacific region, ARIN in North America, LACNIC in Latin American and the Caribbean and the RIPE NCC in Europe, the former Soviet Union and the Middle East. Note that the RIRs tend to change their records retroactively from time to time. For instance, the januari 1, 2005 records show that only 117.3 million addresses were given out in 2004. Also, reclaimed address space isn't listed explicitly. From the fact that the 1-1-2005 records show 1939 million addresses given out before 2004 but the 1-1-2006 records show 1928.48 million addresses for the same period, we can conclude that 11.15 million addresses given out before 2004 have been reclaimed in 2005. The Internet Assigned Numbers Authority (IANA, part of ICANN) keeps an overview of the IPv4 address space at http://www.iana.org/ assignments/ipv4-address-space. The list consists of 256 blocks of 16.78 million addresses. Breakdown: Delegated to Blocks Addresses (millions) AfriNIC 1 16.78 APNIC 16 268.44 ARIN 23 385.88 LACNIC 4 67.11 RIPE NCC 19 318.77 Various 50 838.86 End-user 43 721.42 Available 65 1090.52 Of the 1895.83 million addresses delegated to the five Regional Internet Registries, 1517.74 million have been delegated to end-users or ISPs by the RIRs, and 378.09 million are still available. Along with the 1090.52 million addresses still available in the IANA global pool this makes the total number of available addresses 1468.61 million. The size of address blocks given follows an interesting trend. The table below shows the number of requests for a certain range of block sizes (equal or higher than the first, lower than the second value). 2000 2001 2002 2003 2004 2005 < 1000 326 474 547 745 1022 1309 1000 - 8000 652 1176 897 1009 1516 1891 8000 - 64k 1440 868 822 1014 1100 1039 64k - 500k 354 262 163 215 404 309 500k - 2M 19 39 29 46 61 60 > 2M 3 5 5 6 7 18 The number of blocks in the two smallest categories have increased rapidly, but not as fast as the number of blocks in the largest category, in relative numbers at least. However, the increase in large blocks has a very dramatic effect while the small blocks are insignificant, when looking at the millions of addresses involved: 2000 2001 2002 2003 2004 2005 < 1000 0.10 0.16 0.18 0.25 0.35 0.44 1000 - 8000 2.42 4.47 3.23 3.45 4.49 5.07 8000 - 64k 18.79 12.81 11.35 14.00 15.99 15.46 64k - 500k 35.98 32.19 20.28 25.51 42.01 34.23 500k - 2M 12.68 24.64 21.30 31.98 44.63 41.63 > 2M 8.39 14.68 12.58 12.58 20.97 68.62 The medium-sized blocks seem most affected by the burst of the internet bubble. Another way to look at the same data: Year Blocks Addresses (M) Average block size 2000 2794 78.35 28043 2001 2824 88.95 31497 2002 2463 68.93 27985 2003 3035 87.77 28921 2004 4110 128.45 31252 2005 4626 165.45 35765 The 2222.38 million addresses currently in use aren't very evenly distributed over the countries in the world. The current top 15 is: Country Addresses US 1324.93 M United States JP 143.00 M Japan EU 113.87 M Multi-country in Europe CN 74.39 M China CA 67.43 M Canada DE 51.13 M Germany FR 45.16 M France KR 41.91 M Korea UK 40.18 M United Kingdom GB 33.63 M Great Britain AU 26.87 M Australia IT 18.39 M Italy BR 17.17 M Brazil NL 16.40 M Netherlands ES 16.29 M Spain The US holds 60% of the IPv4 address space. The other countries in the list together hold another 32%. A copy of this information and a tool to perform queries on the base data is available at http://www.bgpexpert.com/addrspace2005.php

1 0

Re: [ipv6-wg] IPv6 PI
by Roger Jorgensen 31 Dec '05

31 Dec '05

On Mon, 21 Nov 2005, Lea Roberts wrote: <snip> > the problem with using ASNs is that when you think over the projected > lifetime of IPv6, there will be *lots* of ASNs. Note that the 4-byte ASN > draft is entering the standards track in IETF. Don't think that tying PI > to ASNs is anything more that passing the problem to the next generation > (if that long... :-) > > It would seem obvious that as network connectivity becomes essential for > doing business, it must be reliable. It is unwise to carry forward the > IPv4 multi-homing model for network resilience with just faith that the > system will be able to scale to an ever larger number of routes. IPv6 has > so far failed to deliver on its original promise of seamless renumbering > and multi-homing using multiple prefixes. The hard problems still need to > be solved in a way that can scale for decades to come. Can't we all just drop using the word multihoming and IPv6 PI? They all reflect back to how thing was done with IPv4 and those ways are doomed to fail with IPv6 simply due to the size of the IP space. Last I checked around there were some promissing new proposal on the way for how to solve this very basic problem. And in the meantime, drop the thought about multihoming and PI space, start to think about other ways to use the possibility IPv6 give us. Just to mention maybe the biggest advantage, we have that extended header part of IPv6, it give us endless possibilities. and yes I do have some idea about how it can be done but no one really bother to consider geo-based IP's either so... :) Not to forget it quite likely will undermine the entire business case for how ISP's today operate. -- ------------------------------ Roger Jorgensen | rogerj(a)stud.cs.uit.no | - IPv6 is The Key! http://www.jorgensen.no | roger(a)jorgensen.no -------------------------------------------------------

29 125

New IPv6 Address Block Allocated to the RIPE NCC
by filiz＠ripe.net 31 Dec '05

31 Dec '05

[Apologies for Duplicates] Dear Colleagues The RIPE NCC received the IPv6 address range 2A01:0000::/16 from the IANA in December 2005. 2A01:0000::/23 was allocated to the RIPE NCC in July 2005. This latest range includes that previous allocation. You may wish to adjust any filters you have in place accordingly. You can find more information about the IP space administered by the RIPE NCC on our web site at: https://www.ripe.net/ripe/docs/ripe-ncc-managed-address-space.html Regards, Filiz Yilmaz RIPE NCC

5 5