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

New IPv6 Address Block Allocated to RIPE NCC
by leo vegoda 16 Dec '04

16 Dec '04

Dear Colleagues, The RIPE NCC received the IPv6 address range 2001:4C00::/23 from the IANA in December 2004. 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/smallest-alloc-sizes.html> Regards, -- leo vegoda Registration Services Manager RIPE NCC

1 0

ICANN Strategic Plan - Call for public comments
by Axel Pawlik 09 Dec '04

09 Dec '04

Dear Colleagues, ICANN has released a three year ICANN Strategic Plan for public comment, available at: http://www.icann.org/strategic-plan/strategic-plan-16nov04.pdf The Regional Internet Registries (RIRs) will gather comments on this document from each of their regional communities before making a joint statement through the Number Resource Organization (NRO) in February 2005. We encourage you to review the ICANN Strategic Plan document and send any comments you have to:<icann-plan(a)ripe.net>. Please send your comments by 10 February 2005. Regards, Axel Pawlik Managing Director RIPE NCC

1 0

NRO Response to ITU Comments on the Management of Internet Protocol (IP) Addresses
by Axel Pawlik 15 Nov '04

15 Nov '04

Dear Colleagues, As part of the World Summit on the Information Society (WSIS) process, a proposal has been made that could dramatically affect the way Internet number resources are distributed and managed. On 21 October 2004, the Director of ITU-TSB published a memorandum, "ITU and Internet Governance" for public comment. This memorandum includes a proposal to create a new IPv6 address space distribution process, based solely on national authorities. This could have a serious impact on RIPE NCC Members, Internet operators and the global Internet community at large. The Number Resource Organization (NRO), on behalf of the Regional Internet Registries, has prepared a public response to the ITU memorandum detailing the flaws of the proposal and the negative impact it would have on Internet operations. A summary of this response is available at: http://www.nro.net/documents/nro18.html The full response is available at: http://www.nro.net/documents/nro17.html The original ITU memorandum is available at: http://www.itu.int/ITU-T/tsb-director/itut-wsis/files/zhao-netgov01.doc We urge our members and others in the Internet community to make their views about this issue known. Without your support being *visible* and *explicit* the bottom-up, consensus based model on which the success of the Internet has been founded may be replaced by the top-down bureaucracy of "Internet Governance". To show your support: - RIPE NCC Members: Log in to the LIR Portal and tick the support box. If you do not have an LIR Portal account, please email your expression of support to: contact(a)ripe.net - Non-members: Please email to: im-support(a)ripe.net. An email archive of expressions of support will be available at: http://www.ripe.net/maillists/ncc-archives/im-support/ - ITU-TSB Members: Please also contact your ITU member state representative to voice your concerns you might have. Internet number resource distribution is fair and accessible to all. Its policy development process is open and transparent. It works. Let us keep it that way. Regards, Axel Pawlik Managing Director RIPE NCC

1 0

IPv4 policy document and request forms updated
by leo vegoda 30 Oct '04

30 Oct '04

Dear Colleagues, The RIPE NCC has updated the policy document, "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region". This update documents the recent changes to the policy for allocation sizes as follows: - Minimum first allocation size is /21. - Minimum first allocation size for LIRs operating in Africa is /22. As a consequence of this update, and in order to incorporate other input, we have also updated the following documents: - Supporting Notes for the Provider Independent (PI) Assignment Request Form. - Provider Independent (PI) Assignment Request Form. - Supporting Notes for the IPv4 First Allocation Request Form. - Supporting Notes for the Autonomous System Number Request Form. - AS Number Request Form. There will be no change to the way you complete the request forms. As the updates to the forms listed above are purely textual, the version number of the forms will not change. Kind regards, -- leo vegoda Registration Services Manager RIPE NCC

9 26

Re: [address-policy-wg] IPv4 policy document and request forms updated
by Janos Zsako 29 Oct '04

29 Oct '04

> From address-policy-wg-admin(a)ripe.net Fri Oct 29 07:47:19 2004 > From: Jeff Williams <jwkckid1(a)ix.netcom.com> Dear Jeff, First of all it may be useful to clarify that we are talking about AfriNIC (i.e. the RIR for Africa, with provisional recognition of ICANN, as opposed to AFNIC, who are the TLD operator for .fr). > > >>> Thanks for your explanation. So I guess this means two different > > >>> policies because Afnic in this case "requested" such? > > >> > > >> No. RIPE members brought this to the address-policy WG that discussed > > >> this and agreed on it. > > >> > > >>> Interesting > > >>> method of policy determination.. > > >> > > >> Why? This is how all address-policy is determined. > > > > > > And there is the curx of the problem... > > > > Ah...you mean an open and transparent policy process? > > No of course not... > > > Ok fare enough. > > Most the rest of us think that is a good thing. You're ofcourse free to > > disagree. > > No I am all for it. However if a policy for one is different than > for another is that wise? Maybe so, maybe not so... If Afnic is > happy with it, great! >;) But is it reasonable to call it a "Policy". > Or would it be more accurate to say a "Policy for Afnic" and > everyone else has a different policy? > > Just trying to understand what the criterion if any for > determining "Policies" are and should be... > > But I am happy to see that not one size fits all, if you will > pardon the pun... >;) Well, I would agree it is this latter case. Most of the policies are regional policies, although there is a lot of effort invested in elaborating global policies. Best regards, Janos Zsako

2 1

ICANN and the NRO sign ICANN ASO MoU
by Paul Rendek 21 Oct '04

21 Oct '04

Dear Colleagues, I am happy to inform you that on 21 October 2004, the Number Resource Organization (NRO) and the Internet Corporation for Assigned Names and Numbers (ICANN) signed a formal Memorandum of Understanding (MoU) on the Address Supporting Organization (ASO). This MoU stipulates how the NRO will fulfil the role, responsibilities, and functions of the ASO as outlined in the ICANN Bylaws. The signing ceremony took place at the biannual Public Policy Meeting of the American Registry for Internet Numbers (ARIN). More information on the MoU is available at: http://www.nro.net/archive/press-releases/aso-mou.html The full text of the MoU is available at: http://www.nro.net/documents/aso-mou.html Regards, Paul Rendek Head of Member Services and Communications RIPE NCC

1 0

New IPv6 Address Block Allocated to RIPE NCC
by Filiz Yilmaz 18 Oct '04

18 Oct '04

Dear Colleagues, The RIPE NCC received the IPv6 address range 2001:4A00::/23 from the IANA in October 2004. 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/smallest-alloc-sizes.html> Regards, -- Filiz Yilmaz RIPE NCC

1 0

RIPE 49 Meeting Report
by Nick Hyrka 18 Oct '04

18 Oct '04

[Apologies for duplicate mails.] RIPE 49 MEETING REPORT Dear Colleagues, The RIPE 49 Meeting was held from 20 - 24 September 2004 at the Renaissance Hotel, Manchester, United Kingdom. There were 301 participants at the meeting. Attendees also included government representatives and representatives from AfriNIC, APNIC, ARIN, LACNIC and ICANN. HIGHLIGHTS Highlights of RIPE 49 included an update on the Number Resource Organization from Axel Pawlik, Managing Director, RIPE NCC; a discussion on the RIPE policy development process; a proposal to restructure RIPE Meetings into three days on operational/technical content followed by two days on policy related issues. The ASO held an election for a seat on the ASO Address Council. Hans Petter Holen was re-elected. Geoff Huston, APNIC, gave a report on the routing table status for IPv4 and IPv6. This presentation is available at: http://www.ripe.net/ripe/meetings/ripe-49/presentations/ripe49-plenary-bgp.… The European Operators Forum (EOF) featured presentations on peering and core network security. EOF presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-49/eof.html The RIPE NCC, LINX, TeleCity, Telecomplete and XChange Point Europe are thanked for the support they provided to the meeting. BT Net are thanked for the excellent provision of the meeting Internet connectivity. SUMMARY ADDRESS POLICY WORKING GROUP - It was agreed that IPv6 allocations from IANA to the RIRs had to be increased in terms of block size, and that /12 was the best allocation size to use. - RIPE Chair, Rob Blokzijl, announced that he would publish a draft of the policy development process for the RIPE region. - There was discussion on the usage of HD ratio for IPv4 and the forthcoming formal proposal regarding this. - The 200 End Users requirement for receiving an IPv6 allocation was discussed and it was agreed that a formal proposal to remove it should be sent to the community. Address Policy Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-49/presentations/index.html#ap DATABASE WORKING GROUP - It was agreed that the RIPE NCC should implement the 'abuse-c:' attribute in the 'irt', 'person', 'role' and 'inet[6]num' object classes. - It was agreed that the RIPE NCC should implement the 'poem' object in the RIPE Database. Database Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-49/presentations/index.html#db TEST TRAFFIC MEASUREMENT (TTM) WORKING GROUP - It was noted that ten test boxes, throughout the RIPE region, have been added to the RIPE NCC Test Traffic Measurements matrix in 2004. Test Traffic Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-49/presentations/index.html#tt ANTI-SPAM WORKING GROUP - A tutorial on message headers was given by Rodney Tillotson, Working Group Chair. - The group discussed the issue of improving the RIPE Database for abuse contacts. There was a majority support for a combination of 'irt' objects with some modifications, and for changes to the default Whois behaviour. Anti-Spam Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-49/presentations/index.html#anti-spam IPv6 WORKING GROUP - The RIPE NCC announced that K-root has been IPv6-enabled since August 2004. - Geoff Huston, APNIC, gave an update on multihoming in IPv6. - There was discussion about IPv6 glue for root name servers. IPv6 Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-49/presentations/index.html#ipv6 EIX WORKING GROUP - It was noted that the switching wish list is in last call and that the final review will take place at the Euro-IX meeting in Athens (October 2004). - It was noted that an Inter Providers Traffic Analyzer tool is available from the Milan Internet Exchange. EIX Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-49/presentations/index.html#eix ENUM WORKING GROUP - There was a presentation from the United Kingdom's Department of Trade and Industry (DTI) on an ENUM Consultation regarding how ENUM should be operated in the UK. - There was a presentation on ENUM deployment in Sweden. ENUM Working Group Presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-49/presentations/index.html#enum DNS WORKING GROUP - It was agreed that the DNS Working Group should take up responsibility for documenting the issues around DNS server migration. - It was noted that the DNS Working Group Chair would collect requirements for the DNS samples and statistics. - It was noted that the DNS Working Group Chair would coordinate the production of a RIPE Document based on Fernando Garcia's DNS Server Migration document. DNS Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-49/presentations/index.html#dns ROUTING WORKING GROUP - It was announced that the maintenance of the IRR Toolset has been transferred from the RIPE NCC to the Internet Systems Consortium (ISC). - There was discussion on securing the network through hiding the core. - There was an overview of the RIS project and discussion on the various uses of the myASn BGP monitoring tool. Routing Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-49/presentations/index.html#routing RIPE NCC SERVICES WORKING GROUP - It was agreed that the RIPE Chair would look at the possibilities of reworking the framework of RIPE meetings, so that operational content would come at the beginning of the meeting week and policy discussions would come at the end of the week. - It was agreed that the RIPE NCC would generate statistics on the quantity of spam on the RIPE NCC servers. RIPE NCC Services Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-49/presentations/index.html#ncc-serv… TUTORIALS The RIPE NCC Training Team presented the RIPE NCC IP Request Tutorial. It explained address space assignment and allocation procedures in the RIPE NCC region: http://www.ripe.net/ripe/meetings/ripe-49/lir-course/index.html RIPE 49 WEBCASTING AND ARCHIVES During RIPE 49, the RIPE NCC held trials in collecting feedback from participants watching the webcast. The mediums used for this were IRC and Jabber. Archives of presentations, webcasts and IRC/Jabber feedback from RIPE 49 are available at: http://www.ripe.net/ripe/meetings/ripe-49/sessions-archive.html HOSTMASTER CONSULTATION CENTRE (HCC) The RIPE NCC Hostmaster Consultation Centre was open at RIPE 49, 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 49. "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 49 REFERENCE PAGE A complete list of RIPE 49 sessions, tutorials and presentations can be found at: http://www.ripe.net/ripe/meetings/ripe-49/index.html RIPE 50 RIPE 50 will be held in Stockholm, Sweden from 2 - 6 May 2005. Information on RIPE 50 will soon be made available at: http://www.ripe.net/ripe/meetings/ripe-50/ If you have any questions about RIPE Meetings, please contact <meeting(a)ripe.net>. -- end --

1 0

Fwd: [Apnic-announce] Privacy of customer assignment records - implementation update
by leo vegoda 23 Sep '04

23 Sep '04

Hi, APNIC have announced a change in the default behaviour of their Whois server. The change will be made on 30 September. People using their Whois service from this region may be interested in the announcement. Kind regards, -- leo vegoda Registration Services Manager RIPE NCC Begin forwarded message: > From: APNIC Secretariat <secretariat(a)apnic.net> > Date: September 23, 2004 2:02:27 am BST > To: apnic-announce(a)apnic.net > Cc: Subject: [Apnic-announce] Privacy of customer assignment records - > implementation update > Reply-To: apnic-talk(a)apnic.net, secretariat(a)apnic.net > > Dear colleagues, > > This is an important announcement on the implementation of APNIC > approved proposal prop-007-v001 regarding privacy of customer > assignment records. The proposal document, presentation, minutes, and > discussion are available at: > > http://www.apnic.net/docs/policy/proposals/prop-007-v001.html > > The APNIC Secretariat will be implementing this proposal on 30 > September 2004. > > Please note that after this date, customer assignment objects will no > longer be visible in the APNIC Whois Database, unless the APNIC > account holder chooses to make public the customer records for their > allocated address range. > > A set of Frequently Asked Questions about this project is now > available at: > > http://www.apnic.net/info/faq/privacy-faq.html > > If you have any concerns or questions regarding this policy, please > contact the APNIC helpdesk at: > > E-mail: helpdesk(a)apnic.net > Phone: +617 3858 3188 > Fax: +617 3858 3199 > > Regards > > ______________________________________________________________________ > APNIC Secretariat <secretariat(a)apnic.net> > Asia Pacific Network Information Centre (APNIC) Tel: +61-7-3858-3100 > PO Box 2131 Milton, QLD 4064 Australia Fax: +61-7-3858-3199 > ______________________________________________________________________ > _______________________________________________ > Apnic-announce mailing list > Apnic-announce(a)lists.apnic.net > http://mailman.apnic.net/mailman/listinfo/apnic-announce >

2 1

draft-hain-ipv6-pi*
by Tony Hain 22 Sep '04

22 Sep '04

Per request, the pointers to the current PI drafts are: http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-07.txt http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-use-07.txt As the USE draft discusses, the exchange points are likely to have a more prominent role than they do in the PA deployment model. For the obvious discussion about how this is impacted by natural impediments, there is an example for exception prefixes at: http://www.tndh.net/~tony/ietf/GrandCanyon.htm Depending on where these prefixes aggregate, there may or may not be any need for distributing these exception prefixes beyond one exchange point. In any case the only entities that need to know the detail are the ones directly involved in sorting it out. Tony

1 0

Additional supporting document for IANA->RIR IPv6 policy proposal
by Dominic Spratley 17 Sep '04

17 Sep '04

Dear Colleagues, The following informational paper "IPv6 address space management" was posted to the APNIC sig-policy mailing list by Geoff Huston, APNIC Secretariat. We have forwarded it to the Address Policy Working Group mailing list for your information. The document can also be found at: http://www.apnic.net/mailing-lists/sig-policy/archive/2004/08/msg00066.html Best regards Dominic Spratley Registration Services Manager RIPE NCC

1 0

Re: ETNO comments on AD ratio for IPv4 addresses allocation
by Wilfried Woeber, UniVie/ACOnet 16 Sep '04

16 Sep '04

> [ ... ] >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). Up to this point it sounds reasonable and well-balanced to me, >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. but that particular reasoning in "5-": "whose existence is only justified by management overhead of large registries..." seems to be slightly off the mark? >6- No additional impact on registrations is seen in RIPE region, as >infrastructure assignments are already registered in the database. > [ ... ] Wilfried ( https://cert.aco.net/ ) _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

ETNO comments on AD ratio for IPv4 addresses allocation
by Debecker J.L. 16 Sep '04

16 Sep '04

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 Europes 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)

1 0

New IPv6 Address Block Allocated to RIPE NCC
by leo vegoda 13 Sep '04

13 Sep '04

Dear Colleagues, The RIPE NCC received the IPv6 address range 2001:5000::/20 from the IANA in September 2004. 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/smallest-alloc-sizes.html> Regards, -- leo vegoda Registration Services Manager RIPE NCC

1 0

RIPE 49 Address Policy WG Draft Agenda
by Andrea Borgato 08 Sep '04

08 Sep '04

Hi All, Please see below the RIPE Address Policy WG Draft Agenda Day 1: Tuesday, 21 September 2004, 16:00 - 17:30 Day 2: Thursday, 22 September 2004, 09:00 - 10:30 Room: Medici A. Administrative Matters - Welcome - Select a scribe - Distribute participants list - Finalise agenda - Approve minutes from RIPE 48: http://www.ripe.net/ripe/wg/address-policy/r48-minutes.html B. RIPE NCC and other Updates (Filiz Yilmaz, RIPE NCC) - RIPE NCC policy implementation & regional statistics. - Policy discussion and decisions in other RIR regions - Internet Number Resource statistics C. ICANN ASO AC Update (TBD, ICANN ASO AC) D. ICANN ASO AC - A View From Outside (A volunteer) E. Discussion Resulting From ICANN ASO Presentations F. Policy Development Process Hans Petter Holen, et al G. Policy Discussion - IPv6 (changes to the initial allocation criteria) Andy Furnell, LINX - Policy for allocation of IPv6 address space from IANA to RIRs Paul Wilson, APNIC - Whois Registration (What should be in Whois and why) Eva Ericsson Rabete, TeliaSonera --Possible topics-- - Paul Wilson's updated proposal: HD Ratio for IPv4 Allocations Y. Open Microphone Z. AOB Andrea Borgato - RIPE Address Policy WG co-chair

1 0

Re: [address-policy-wg] Re: IANA to RIR IPv6 Allocation
by Wilfried Woeber, UniVie/ACOnet 25 Aug '04

25 Aug '04

>> My proposal would be that IANA would have to perform the subsequent >> allocation within this 30 day period, even if they might not be able to >> obtain advice or an expertise (for whatever reason) from any other party >> they might have decided to ask for advice. > >sure, if we can we do the same for rir to lir No problem with that, although I don't see the need for global coordination here. To me this sounds like a RIR-Customer service-contract aspect. Wilfried.

1 0

Re: [ipv6-wg@ripe.net] RE: [address-policy-wg] Re: IANA to RIR ipv6 Allocation
by Iljitsch van Beijnum 24 Aug '04

24 Aug '04

On 24-aug-04, at 4:48, Jeff Williams wrote: > Iljitsch and all, ^^^^^ No kidding... > None of this addresses the outstanding problems with Ipv6 or ipv6 > allocation concerns and existing as well as discussed problems. > They are "at least" the following: I don't think I get what you're talking about. > 1. ) Invalid or incorrect minimal allocation. What is invalid or incorrect here? > 2.) Still existing cost increases for allocations. What cost? > 3.) Still existing security/privacy "holes" in ipv6 What holes? There is no difference with IPv4. > 4.) Routing notification for new allocation practice or method. What on Earth is a "routing notification"? > 5.) Routing table maintenance Best practices and/or policy, Well, there is some of this but since the RIRs seem to have trouble living up to their own policies this is problematic. (See http://www.bgpexpert.com/archive2003q4.php ) > and enforcement of same. Yes, we don't do this in the internet. (And go fix the IPv4 table first if you feel so inclined.) > 6.) Dealing with "Dark" existing and/or future allocated addresses. Again, I have no idea what you're talking about. Now if we could have a mechanism to determine resolving DNS servers automatically in IPv6 and have visible IPv6 addresses for the root DNS servers we'd be well on our way. And of course we still need multihoming in IPv4 and the IETF has to quit rewriting the RFCs all the time. > Iljitsch van Beijnum wrote: I know what I wrote, so P L E A S E don't repeat it in its entirety!!! I'm really getting sick and tired of people who are too lazy to quote in a decent manner.

1 0

Re: IANA to RIR IPv6 Allocation
by Wilfried Woeber, UniVie/ACOnet 20 Aug '04

20 Aug '04

I've got one comment here on section 7. paragraph 4. "Subsequent Allocation": While the wording might be sufficiently clear for a native speaker by referring to "set of administrative procedures....", I am missing clear guidance for the IANA that there should _not_ be any incentive or responsibilty to consult with other groups, entities or third parties (irrespective of their, say, credibility for e.g. protocol development or technical specifications) which would require extending that 30 day period. My proposal would be that IANA would have to perform the subsequent allocation within this 30 day period, even if they might not be able to obtain advice or an expertise (for whatever reason) from any other party they might have decided to ask for advice. Wilfried ( https://cert.aco.net/ ) _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ...there's no place like 127.0.0.1 (or ::1/128 ?) From: David Kessens <david.kessens(a)nokia.com> To: Jeroen Massar <jeroen(a)unfix.org> Date: Fri, 20 Aug 2004 01:48:52 -0700 CC: ipv6-wg(a)ripe.net Subject: Re: [ipv6-wg(a)ripe.net] FW: [arin-council] IANA to RIR IPv6 Allocation Jeroen, On Fri, Aug 20, 2004 at 09:25:59AM +0200, Jeroen Massar wrote: > For people not on the arin-council (not likely ;) or the ppml@arin > lists: All policy discussions for the RIPE region are now conducted at the RIPE policy working group maillist: address-policy-wg(a)ripe.net David Kessens --- > -----Forwarded Message----- > From: "Sweeting, John" <John.Sweeting(a)teleglobe.com> > To: 'ppml(a)arin.net' <ppml(a)arin.net> > Subject: [ppml] FW: [arin-council] IANA to RIR IPv6 Allocation > Date: Thu, 19 Aug 2004 17:36:56 -0400 > > I am submitting the following proposal IAW ARIN's Internet Resource Policy > Evaluation Process. In the interest of all I would like to disclose up front > that the information used to prepare this template was provided by ARIN > staff. > > > ############################################ > Template: ARIN-POLICY-PROPOSAL-TEMPLATE-1.0 > > 1. Policy Proposal Name: Allocation of IPv6 Address Space by the Internet > Assigned Numbers Authority (IANA) Policy to Regional Internet Registries > > 2. Author > > a. name: John Sweeting > b. email: john.sweeting(a)teleglobe.com > c. telephone: 703-766-3042 > d. organization: ARIN Advisory Council > > 3. Proposal Version: 1 > > 4. Submission Date: 8/17/04 > > 5. Proposal type: new, global > > 6. Policy term: permanent > > 7. Policy statement: > > 1. Minimum Allocation Size. > > The minimum size of any allocation of IPv6 address space from IANA to an RIR > is prefix length /12. If this address space is not sufficient to meet the > needs of an RIR for a projected 18 month period, IANA shall allocate to that > RIR the address space for which it can provide justification. > > 2. Reservation of Unicast Address space. > > 2.1 IANA. By RFC 3513 the IANA has been allocated the range of IPv6 > addresses beginning at binary value 001 (prefix length /3) for its > allocations of unicast address space. In order to support regional > aggregation of IPv6 address space IANA shall establish a reservation of a > prefix length of /6 from this space for each established RIR and for each > emerging RIR. Allocations to each RIR will be from the appropriate > reservation. > > 2.2. RIRs. Each RIR may apply its own respective chosen allocation and > reservation strategy in order to meet the needs of its community and to > ensure the efficiency and efficacy of its work. Such reservations made by > an RIR will be considered as being allocated by that RIR when that RIR > applies for an allocation of address space from the IANA. > > 3. Initial Allocation. > > 3.1. Upon implementation of this policy IANA shall allocate to each > established RIR a /12 from the reservation established for each particular > RIR. > > 3.2. Upon recognition of an RIR by ICANN that RIR shall receive a /12 from > the reservation set aside for that RIR. > > > 4. Subsequent Allocation. > > An RIR shall be eligible for an allocation of at least a minimal allocation > from the IANA when its current holdings are less than 50% of its 18 month > requirement or when it has less than 180 days of holdings available. The > IANA shall evaluate the requested allocation using a set of administrative > procedures that are mutually agreed to by the IANA and the NRO. This set of > procedures shall be enacted within 30 days of the implentation of this > policy. > > > 5. Announcement of IANA allocations to the RIRs > > When address space is allocated to a RIR, the IANA will send a detailed > announcement to the receiving RIR. The IANA will also make announcements to > all other RIRs, informing them of the recent allocation. > > The IANA will make appropriate modifications to the "Internet Protocol V6 > Address Space" page of the IANA website and may make announcements to only > its own global announcement lists. The IANA announcements will be limited > to which address ranges, the time of allocation and to which Registry they > have been allocated. > > > 8. Rationale: > > The current IANA allocation policy for IPv6 is an interim policy that was > promulgated in 1999. Operational experience has demonstrated the current > minimum allocation size is too small; that the built in reservation system > that must be followed by the RIRs does not allow for efficient and effective > management of the resource by the RIR; and does not provide for an well > known evaluation criteria. This document does not stipulate performance > requirements in the provision of services by IANA to an RIR in accordance > with the policy. Such requirements should be specified by appropriate > agreements between the NRO and ICANN. > > > 9. Timetable for implementation: Thirty days after ratification by the ICANN > Board of Directors in accordance with the global policy development process _______________________________________________

5 4

Re: [address-policy-wg] Re: Policy for allocation of IPv6 address space from IANA to RIRs
by Wilfried Woeber, UniVie/ACOnet 20 Aug '04

20 Aug '04

>Well, clearly ICANN and the U.S. watch the IANA because the IANA >an activity which the DOC subcontracts to ICANN to perform. Exactly. > The IANA is not an organization and it has no independent status. It >just happens to be the historical name for some of the functions of ICANN Exactly. >so for convenience and clarity, the name remains assigned to that set of >functions. For clarification read this contract that ICANN has signed with >the DOC on behalf of the U.S. Government. Indeed. And given the world, some governments, and ICANN as they are these days, I (personally) do not consider that structure to be the most stable and resilient setup that I'd rather have in place to control global resource distribution. Wilfried.

1 0

New IPv6 Address Block Allocated to RIPE NCC
by leo vegoda 18 Aug '04

18 Aug '04

Dear Colleagues, The RIPE NCC received the IPv6 address range 2001:4600::/23 from the IANA in August 2004. You may want 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/smallest-alloc-sizes.html> Regards, -- leo vegoda Registration Services Manager RIPE NCC

1 0

Re: Policy for allocation of IPv6 address space from IANA to RIRs
by Wilfried Woeber, UniVie/ACOnet 17 Aug '04

17 Aug '04

>> So what are your proposals to improve the system, then? > >what's broken? the rirs watch the lirs. iana watches the rirs. >icann watches the iana. Looking at the situation from my end of the stick, this statement is a bit simplistic or at least incomplete. First of all, on one end there is a cummunity of customers which does watch the RIRs, too. And on the other end: who/what watches the IANA and ICANN? This is where I do see more single points of failure, and "procedures", "double-checks" and "delays" than I see the risks with the RIRs. This is not to be taken as a support statement for giving away everything at once (whatever it is :-) - but a geographically and culturally distributed system is in my opinion much more robust than a nationally or hierarchicvally controlled setup - and being constrained by just *one* particular jurisdiction. Wilfried.

2 1

Policy for allocation of IPv6 address space from IANA to RIRs
by leo vegoda 13 Aug '04

13 Aug '04

Dear Colleagues, The Number Resource Organisation (NRO) has published a proposal for a policy for the allocation of IPv6 address space from the IANA to the RIRs. It is intended that this proposed policy should be agreed by all RIRs' open policy fora and then approved by the ASO and ICANN as a global policy. The proposal is available on our web site at: http://www.ripe.net/ripe/draft-documents/ipv6.html Comment on the proposal is sought. Kind regards, -- leo vegoda Registration Services Manager RIPE NCC

13 20

Re: [address-policy-wg] Policy for allocation of IPv6 address space from IANA to RIRs
by Doug Barton 10 Aug '04

10 Aug '04

> On Monday 09 August 2004 18:42, Randy Bush wrote: >> leo, >> >> can you explain why the rirs need a time window from the iana >> (36 months) so much larger than lirs need from the rirs? >> >> randy > > Randy, > I read it that IANA don't see RIR's needing more than a /12 in a 36 month > period - thus a /12 would at least meet the RIR's needs for the next 36 > months. > > Seems like a much better idea than faffing about handing out a /23 every few > months. > > Jon Jon, Just to be clear, the policy as proposed is coming to you direct from the NRO, IANA has had no direct input in it's creation. I first saw this draft document myself on the APNIC sig-policy list on 4 August. http://www.apnic.net/mailing-lists/sig-policy/archive/2004/08/msg00003.html That said, we're very happy that the NRO has offered this submission as a starting place for the public dialog, and we look forward to seeing how the process plays out. While it's certainly not IANA's job to _set_ policy, we are happy to offer the benefit of our experience to anyone who asks. :) Doug -- Doug Barton General Manager, The Internet Assigned Numbers Authority

2 1

Re: NCC#2004080845 IPV6 Addresses pool
by RIPE NCC 09 Aug '04

09 Aug '04

Dear Gil, The following link will give you a list of all LIRs who received an IPv6 allocation from RIPE NCC. However, it is not ordered per country. http://www.ripe.net/ripencc/mem-services/general/allocs6.html Kind regards, Monique van Troost First Line Support Operator RIPE NCC On Mon, 9 Aug 2004 09:46:37 +0200, Gil Yaacoby wrote: > Hi , > > My name is Gil Yaacoby. I am responsible for the evaluation of > new Datacom technologies in Cellcom Israel Ltd. IPv6 is one of our > current projects.I need to find out the formal procedure to purchase an > IPv6 address > pool > > we need IPV6 Addresses pool for our cellular costumers. > I think that at this point of time Cellcom Israel Ltd can't show > bussiness case for being a LIR . > > I think getting small amount like /48 from some ISP will be good enough. > Do you know about any ISP's who can provide Cellcom IPV6 adresses pool > (In ISRAEL or outside the country)? > > Many thanks, > > Gil Yaacoby > > > --------------------------------------------------------------------------------------------------------------- > This e-mail message may contain confidential, commercial and privileged information or data that constitute proprietary information of Cellcom Israel Ltd. Any review or distribution by others is strictly prohibited. If you are not the intended recipient you are hereby notified that any use of this information or data by any other person is absolutely prohibited. If you are not the intended recipient, please delete all copies. > > Thank You. > http://www.cellcom.co.il --

2 1

Re: Policy Change Request - Allow address allocations for anycast DNS operation] (fwd)
by Pekka Savola 01 Aug '04

01 Aug '04

Following up with really old email.. [Gert:] > On Tue, Jun 15, 2004 at 02:11:22PM +0300, Pekka Savola wrote: > > On Tue, 15 Jun 2004, Gert Doering wrote: > > > One comment asked for "do we really need yet another special rule here", > > > and my reply would be "the current PA and PI policy doesn't permit doing > > > this without lying to the NCC", *and* DNS is really special here due to > > > protocol constraints. > > > > If you qualify for at least /24 of v4 address space, there shouldn't > > be a problem with current v4 policy? > > There is. People don't want to use part of their PA block for the > anycast announcement (due to "allocation boundary" filters) and you > won't qualify for a /24 PI with just a single IP address used inside > the block. I don't think this really matters. First, the allocation boundary filters filters filter out a lot of stuff as well. If you put them in, you should know that you might not get some advertisements. Second, even if you filter on the boundary, you'll just go to the main office, not necessarily the closest anycasting service. So, the service you get is no worse than it's today. Last, there are also those other, non-anycasted servers, so you'll be able to reach them as well. I don't clearly see why this exception is necessary, especially if folks document the more specific block appropriately in the registry. > > If you can't qualify for that amount of addresses, do we care about > > anycasting that kind of server? > > The ccTLD's office might have 500 machines in use, but the individual > instances will all only use 1 IP (or very few). I'm not sure what you meant by 1 IP -- the DNS server or some small offices? (or offices behind a NAT?) > > Remember, nothing prevents anycasting with your existing allocated > > blocks. Hence, the policy for allocating these special PI/PA prefixes > > should be at least as strict as the policy for getting PI/PA prefixes > > in the first place .. to avoid getting around policies. > > The problem in the first place is that the PI policy doesn't permit > these prefixes in the first place, due to insufficient utilization. Ok -- then we have still the PA policy left that might be useful. > [..] > > I object to this as a whole, but even if we agreed that this is > > desirable in general, I have two strong objections: > > > > (1) there is little reason for allocating a /32 IPv6 prefix except > > for getting around the IPv6 policy. Why not use the "critical > > infrastructure" /48's for this, so we can easily filter out this junk > > in our BGP :) > > We have no "critical infrastructure" /48s in RIPE land, *and* you're > not supposed to catch this in "general-purpose more-specific filters" > - which is the whole point of this excercise. > > (If you really want to filter the prefixes, you still can, as they are > supposed to be clearly tagged in the RIPE DB). Just chunk out a couple of /48's from the block where the IX addresses have been allocated? Given the reasoning above, and the fact that the servers should always also include non-anycasted addresses, I see no reason why these should be given special status -- it's not as if it's critical that these prefixes go through the filters or aelse all else breaks. That IMHO argues for similar treatment as ARIN's "critical infrastructure" prefixes: /48's which some might and some might not filter. We certainly intend to :). > > (2) this proposal takes no stance on who can request a block of > > addresses like this for his DNS servers? > > Yes. On purpose, because it was envisioned that some organizations > that are not TLD operators but still operate a high number of DNS > servers (due to having a very large number of zones, or due to > having a world-wide network, or whatever) might still meet the > spirit of the thing. Due to reasons discussed below, I strongly believe that we need restrictions here. I don't care much about giving special golden PI blocks to TLD operators, but I care even less for giving them anyone at all that comes knocking at the door! TLD operators should at least be considered (by some measure) "semi-critical" infrastructure. Big ISPs don't need these special provisions, and the net doesn't care about the small ISPs which can't get routable PI otherwise (and this would be a nice trick to get it through a loophole). In short, let's just decide on a list, if we need this in the first place. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

1 0