From Klaus.Kinder at telekom.de Thu Oct 2 08:58:17 2003 From: Klaus.Kinder at telekom.de (Kinder, Klaus) Date: Thu, 2 Oct 2003 08:58:17 +0200 Subject: [address-policy-wg] Re: [ncc-services-wg] Request Forms: upda ted and available on LIR Portal Message-ID: Hi, Ludger Bornhorst is on vacation but we have discussed this matter before he send this mail. Here two notes from my point of view: you wrote: The RIR->LIR level has the AW to express a given level of trust. I quite agree with you: You could use policies in a narrow interpretation or in a scope of interpretation in addition with your know how in cases of ip-address management, both is possible and essential. But you couldn't find this scope in ripe-283 e.g. #[EQUIPMENT DESCRIPTION]#, I think that's the problem. Or is this scope in addition to your AW an unwritten policy? you wrote: please don't feed the buerocracy. I can assure you that's not our target. From our point of view policies should give all parties, here the LIR's, a general Framework and not a straitjacket. mit freundlichen Gr??en/with best regards Klaus Kinder _________________________________________ Deutsche Telekom T-Com Headquarters Network Information Center Local Internet Registry Ammerl?nder Heerstr. 138, D-26129 Oldenburg +49 441 234 - 4530 (phone) +49 441 234 - 4589 (fax) E-Mail: Klaus.Kinder at telekom.de From ncc at ripe.net Thu Oct 2 16:08:10 2003 From: ncc at ripe.net (Nick Hyrka) Date: Thu, 02 Oct 2003 16:08:10 +0200 Subject: [address-policy-wg] RIPE 46 Meeting Report Message-ID: <5.2.1.1.2.20031002154321.03b1bec0@mailhost.ripe.net> (Apologies for duplicate mails.) RIPE 46 Meeting Report Dear Colleagues: The RIPE 46 Meeting was held from 1 - 5 September 2003 at the Grand Hotel Krasnapolsky, Amsterdam, the Netherlands. There were a total of 307 attendees comprised of the RIPE NCC membership, the RIPE community and government representatives. Attendees also included representatives from APNIC, ARIN, AfriNIC, LACNIC and ICANN. HIGHLIGHTS ========== Highlights of RIPE 46 included the open discussion on the services of the RIPE NCC during the first session of the RIPE NCC Services Working Group; a presentation on current RIPE NCC services and plans for 2004 by Axel Pawlik, Managing Director, RIPE NCC; an AfriNIC update; and an update on the changes to Test Traffic Measurement. The European Operators Forum (EOF) featured a full-day tutorial on Voice over Internet Protocol (VoIP) and ENUM that included an overview of current technologies and a focus on practical deployment aspects such as gateways, security, provisioning and use of the new ENUM standards. Geoff Huston, Telstra, gave a presentation on IPv4 Address Lifetime Expectancy. The RIPE NCC would like to thank SURFnet, BIT, FLAG Telecom and KPN EuroRings for the support they provided to the meeting. SUMMARY ======== ADDRESS POLICY ============== - Hans Petter Holen, Chair, requested community involvement to help revise ripe-152 ("Charging by Local Internet Registries") if necessary. - The RIPE NCC will resubmit the IPv4 policy document for community review. - There was a discussion on PI/PA issues and whether the distinction is still valid. - It was agreed that a more formal process was needed for the policy development process. Address Policy Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-46/presentations/#ap DATABASE ======== - Wilfried Woeber, Chair, will co-ordinate with the RIPE NCC to prepare a document summarising the basic assumptions about the use of the RIPE Database. - "status:" attribute values will change. Current efforts aim at consistency between the RIRs and having easy to understand values. - The organisation object proposal received positive feedback from the working group, with suggestions for other features. - The RIPE NCC will implement X.509 authentication before the next RIPE Meeting. Database Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-46/presentations/#db TEST TRAFFIC MEASUREMENTS (TTM) ========================= - As of 1/1/2004 changes will be made to the TTM service contract: Fees will be lowered, all data will be made public with lightweight Acceptable Use Policy (AUP). - Bandwidth measurements: tests showed that results are not conclusive enough so the TTM service will wait before delivering this new product. TTM Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-46/presentations/#tt ANTI-SPAM ========= - Rodney Tillotson, Chair, will post a proposal to the Anti-Spam mailing list regarding methods to improve finding abuse contacts in the RIPE Database. Anti-Spam Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-46/presentations/#anti-spam IPv6 === - The 6BONE phase-out was discussed. The next milestone will be 01/01/2004 when new allocations stop. - Discussion on the separation of the identifier and locater functions of IP addresses in regards to IPv6 multihoming. IPv6 Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-46/presentations/#ipv6 TECHSEC ======== - Community feedback was requested on the requirements needed to secure large scale IP infrastructure especially around CLI interface requirements. - The RIPE NCC presented a report on DNSSec status, DISI achievements since RIPE 45 and the impact of signing on zone size. - George Jones, Mitre, gave a presentation on operational security requirements including the history and current status of the requirements, related work, next steps and milestones. - Baiba Kaskina, TERENA, gave a presentation on Euro CSIRT developments that included details on the CSIRT Task Force, the countries involved, the projects and deliverables. - NLNetLab presented an update on Fonkey and PKI-related developments in IETF. TechSec Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-46/presentations/#techsec EIX == - Support was expressed for aligning and harmonising IPv6 address space policy regarding IXPs with other RIRs and existing IPv4 policies. - Reports were presented by 11 European IXPs in Europe that showed a trend of steady growth, use of GE instead of FE and wide deployment of IPv6. - Discussion of the Inter-Provider Traffic Analyzer that uses past data and statistical calculations to detect anomalies in traffic patterns. - EIX presentations were given on the anycast deployments of the "F" and "K" root servers by ISC and the RIPE NCC. EIX Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-46/presentations/#eix DN* === - From the merging of the former DNS Working Group and DNR Forum it was concluded that one working group is sufficient to deal with everything related to Domain Names. A new name/charter will be discussed on the mailing list. - Jaap Akkerhuis, DN* Co-Chair, will organise a "DNS Related Issues" document. - Peter Koch, DN* Co-Chair, talked about how firewall vendors could make mistakes handling DNS communication issues. DN* Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-46/presentations/#dn RIPE NCC SERVICES ================ - Axel Pawlik noted that the RIPE NCC will present more details in next year's RIPE NCC budget. - There were comments on the current RIPE NCC services, whether they benefit the entire community and whether a 'pay per service' system could be an option. - There was discussion about the need for a more transparent evaluation of RIPE NCC activities and how they benefit the community. RIPE NCC Services Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-46/presentations/#ncc TUTORIALS ========= - The RIPE NCC staff 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-46/tutorials/ip-request/ - A full-day tutorial on VoIP and ENUM was presented during the European Operators Forum (EOF). For more information about the EOF at RIPE 46 see: http://www.ripe.net/ripe/meetings/ripe-46/eof.html RIPE MEETING WEBCASTING ======================= - The third phase of RIPE Meeting webcasting trials was held at RIPE 46. Recordings of certain sessions from RIPE 46, including the Plenary, have been archived and can be accessed at: http://www.ripe.net/ripe/meetings/ripe-46/webcast.html HOSTMASTER CONSULTATION CENTRE (HCC) ==================================== - The RIPE NCC Hostmaster Consultation Centre was open at RIPE 46, allowing RIPE NCC Members to discuss issues relating to their business directly with RIPE NCC Hostmasters. Later consultation hours, as introduced at RIPE 44, were continued. "MEET & GREET" =============== - The RIPE NCC's "Meet & Greet" was available for first-time RIPE Meeting attendees at RIPE 46. "Meet & Greet" introduces newcomers to the meetings, to key attendees of the RIPE community and to social events throughout the week. More information can be obtained by contacting the RIPE NCC's Pepa Tejedor Carnicero at . RIPE 46 REFERENCE PAGE ====================== - A complete list of RIPE 46 sessions, tutorials and presentations can be found at: http://www.ripe.net/ripe/meetings/ripe-46/index.html RIPE NCC GENERAL MEETING ======================= - The RIPE NCC General Meeting 2003 was held Friday, 5 September 2003, adjacent to the RIPE 46 Meeting, at the Hotel Krasnapolsky in Amsterdam. For the highlights from the RIPE NCC General Meeting 2003, please see: http://www.ripe.net/ripencc/about/gm/gm2003/highlights.html RIPE 47 ====== - RIPE 47 will be held in Amsterdam, the Netherlands, from 26 - 30 January 2004. Information on RIPE 47 will soon be made available at: http://www.ripe.net/ripe/meetings/ripe-47/ NEW LOCAL INTERNET REGISTRIES (LlRs) - PLEASE NOTE LIRs who signed up after 1 January 2002 are entitled to two (2) free tickets to attend the next RIPE Meeting. The tickets cover the meeting fee only and do not apply to the RIPE dinner, travel or hotel accommodation. More information on the new LIR tickets can be found at: http://www.ripe.net/ripe/meetings/new-lir.html For more information, contact . END From hpholen at tiscali.no Sun Oct 5 23:14:18 2003 From: hpholen at tiscali.no (Hans Petter Holen) Date: Sun, 5 Oct 2003 23:14:18 +0200 (CEST) Subject: [address-policy-wg] Revised Draft Document for review: "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" In-Reply-To: <5.2.1.1.2.20030929083537.024258e0@mailhost.ripe.net> Message-ID: Dear Working Group, As indicated at the last working group meeting, I would very much like to se POSITIVE feedback from the WG before we make final policy: > Feedback on this document should be sent to the address-policy-wg at localhost > mailing list for a period of two weeks. > > This review period will end on TWO WEEKS FROM ANNOUNCEMENT. Who can committ to read and send their comments within this timeline ? (I'll chase some of you one2one too...) Hans Petter From zsako at banknet.net Mon Oct 6 12:58:15 2003 From: zsako at banknet.net (Janos Zsako) Date: Mon, 6 Oct 2003 11:58:15 +0100 (MET) Subject: [address-policy-wg] Revised Draft Document for review: "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" Message-ID: <200310061058.h96AwFx0024900@banknet.banknet.net> > From address-policy-wg-admin at ripe.net Sun Oct 5 22:15:17 2003 Dear all, > As indicated at the last working group meeting, I would very much like to > se POSITIVE feedback from the WG before we make final policy: > > > Feedback on this document should be sent to the address-policy-wg at localhost > > mailing list for a period of two weeks. > > > > This review period will end on TWO WEEKS FROM ANNOUNCEMENT. > > Who can committ to read and send their comments within this timeline ? At RIPE 46 I was one of those who raised their hands when Hans Petter asked whether anybody volunteers to comment the document if it is circulated again on the list. Please find below my comments. First of all I would like to congratulate those who made the effort of re-writing the policies document. I think they did a very good job. The restructuring seems good to me. I have some specific comments, questions, and sugestions respectively: 1. In paragraph 2.0 I suggest mentioning RFC3330 too. (It gives further details about the address space usage than RFC1918 and RFC1112.) 2. Also in paragraph 2.0, point 2 I suggest adding a new sentence, which in my view makes it easier to understand the reference to RFC2993 (I included in the quoted text my sentence using underscores instead of spaces for easier identification): "...Hosts using these addresses cannot directly be reached from the Internet. _Such_connectivity_is_enabled_by_using_the_technique_known_as_ Network_Address_Translation_(NAT)_. Private addresses restrict a network so that its hosts only have partial Internet connectivity..." (of course, the exact wording itself can be changed). 3. In paragraph 4.0, at the end of second paragraph I suggest adding: "...Registration data (range, contact information, status etc.) must be correct _at_all_times_(i.e._they_have_to_be_maintained)." 4. In paragraph 6.1. I have a question and a suggestion related to the statement: "If a request needs to be approved by the RIPE NCC or if information is required in the event of an audit, the information must be submitted on a current version of the request form found at:" It is clear that in case of a new request that needs to be approved, information must be submitted on the current form. The question I have is related to the audit of a prior assignment: does the LIR have to produce the documentation in the _current_ version of the form? I would think that producing the documentation on the form used _at_the_time_of the assignment would be acceptable. If so, it may be good to slightly rephrase the above to reflect this. 5. I have the impression that the AW applied to an End User network (paragraph 7.0) is not clear enough, so I suggest adding a couple of new words: "An AW can be applied to an End User network once per 12-month period. This means an LIR can make more than one assignment to an End User _in_any_such_12_months'_period, but the total amount of address space cannot be larger than the LIR's AW. An LIR's AW is considered unused on the anniversary of the first (?!? I would think _last_) assignment to the End User._After_the_exhaustion_of_the_AW, the LIR may only assign additional addresses to the same End User after approval from the RIPE NCC. (In one of the sentences above I have the impression that first should be changed to last - did I misunderstood something?) 6. In the first paragraph of 9.0 I suggest repeating "or sub-allocated" in order to avoid any possible mis-interpretation (i.e. that sub-allocations do not necessarily have to be returned): "LIRs are allocated PA address space. They sub-allocate and assign this to downstream networks. If a downstream network or End User changes its service provider, the address space assigned _or_sub-allocated_ by the previous service provider will have to be returned and the network renumbered." 7. I have a question regarding the value "NOT-SET" of the status attribute (paragraph 9.0). The document states that _new_ objects cannot be created with this attribute. I would expect the database to also reject updates that have such an attribute. Is this the way the database behaves? If yes, it may be useful to mention this here ( I suggest something like: "Objects cannot be created or updated with this value".) That is all for now. I hope you will find these useful. Best regards, Janos From axel.pawlik at ripe.net Mon Oct 6 15:11:25 2003 From: axel.pawlik at ripe.net (Axel Pawlik) Date: Mon, 06 Oct 2003 15:11:25 +0200 Subject: [address-policy-wg] IANA Policies for Allocation of IPv4 Blocks to RIRs Message-ID: <5.2.0.9.2.20031006150942.05794c10@localhost> Dear Colleagues, The Regional Internet Registries (RIRs) have been working together with the Internet Assigned Numbers Authority (IANA) on a policy for the allocation of IPv4 address space to the RIRs. The proposed policy was presented to the RIPE Address Policy Working Group at RIPE 46 in September. The presentation can be found at: http://www.ripe.net/ripe/meetings/ripe-46/presentations/ripe46-ap-iana-rir/ Following discussion in all four RIR regions, this policy proposal and discussion results will be forwarded to the ICANN ASO Address Council for review and submission to the ICANN Board. It is considered a global policy proposal. Please review the document "Internet Assigned Numbers Authority (IANA) Policies for Allocation of IPv4 Blocks to Regional Internet Registries". The document can be found at: http://www.ripe.net/ripe/draft-documents/iana-rir-allocation-policies.html Comments on this proposal should be sent to this list. The review period is six weeks and will end on 16 November. A webcast recording of the entire RIPE Address Policy Working Group session can be found at: mms://webcast.ripe.net/ripe46/ap-1a.wmv mms://webcast.ripe.net/ripe46/ap-2a.wmv Kind regards, Axel From emma.apted at psineteurope.com Tue Oct 7 17:14:06 2003 From: emma.apted at psineteurope.com (Emma Apted) Date: Tue, 07 Oct 2003 16:14:06 +0100 Subject: [address-policy-wg] Revised Draft Document for review: "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" In-Reply-To: <200310061058.h96AwFx0024900@banknet.banknet.net> Message-ID: <5.2.0.9.0.20031007152842.02cfcda0@mail.psineteurope.com> Hi, > > Feedback on this document should be sent to the address-policy-wg at localhost > > mailing list for a period of two weeks. In paragraph 3 of section 5.0, we have " If an LIR is planning to exchange or transfer address space it needs to contact the RIPE NCC so that the changes can be properly registered. Please note that the LIR always remains responsible for the entire allocation it receives from the RIPE NCC. " Should the second sentence have at the end "until the allocation has been officially transferred to another LIR with the authorisation of the RIPE NCC" ? Since I would have thought that after an LIR has transferred an allocation to another LIR, then it no longer needs to remain responsible for it. Section 5.4 ends with "LIRs not wishing to lose address space in this way should ensure that the status of the sub-allocation is clear in any contracts between the LIR and the downstream network operator." I recommend that it be emphasised that it is the LIR's responsibility to do this, not RIPE NCC's. By the time we reach section 7.0, the Assignment Window has been mentioned many times; I recommend we move this section to somewhere earlier in the document. Near the end of section 7.0, training is mentioned. RIPE NCC's own training courses, with associated URL, could also be mentioned here. In the last paragraph of section 9.0 we have "If an LIR has an End User that requires PI address space they should refer the End User to an appropriate registry. " Does this mean that if an ISP, who is an LIR, is approached by a customer who says they require PI space, that the LIR should simply give the RIPE NCC URLs and email addresses to the customer, so they can send the request themselves to RIPE NCC? Or can the LIR send the request, on behalf of the customer, to the RIPE NCC? Otherwise, the document looks good to me! :-) Best regards, Emma From contact at ripe.net Wed Oct 8 16:07:07 2003 From: contact at ripe.net (Membership Liason Officer) Date: Wed, 8 Oct 2003 16:07:07 +0200 Subject: [address-policy-wg] RIPE NCC Regional Meeting, Middle East, Dubai, 7-9 December 2003 Message-ID: <20031008160707.609ec6d5.contact@ripe.net> Dear Colleagues, The RIPE NCC is pleased to announce the RIPE NCC Regional Meeting, Middle East, to be held 7-9 December 2003 at the Metropolitan Palace Hotel, Dubai, U.A.E. Registration for the Regional Meeting opens 8 October 2003. Attendance to the RIPE NCC Regional Meeting is open and free of charge. However, attendees are responsible to cover their own travel and accommodation costs. To register, please see: http://www.ripe.net/cgi-bin/dubai-reg The RIPE NCC Regional Meeting will focus on Internet resource allocation and Internet management issues including: - How to participate in and influence IP address management policy-making; - The industry self-regulatory open structures and processes used by the RIPE NCC and the global Internet community; - Are we running out of IPv4 address space? - Root name server operations: who is involved? - Domain Name management on the Internet; - The internationalisation of Domain Names. The Regional Meeting draft agenda can be found at: http://www.ripe.net/ripencc/regional-meetings/dubai-2003/plan.html RIPE and the RIPE NCC will explain their roles in the administration of the Internet infrastructure as well as specific aspects in managing and operating the Internet infrastructure. The discussions will be directly related to the particular needs and concerns surrounding these issues in the Middle East region. The current meeting agenda reflects our intentions. However, it requires active participation from the local community to discuss specific issues of the region. The RIPE NCC has reserved several presentation opportunities for those with local knowledge of Internet management and operational issues affecting the Middle East. If your organisation wishes to provide a presentation or suggest a relevant topic, please send your proposal by e-mail to: The RIPE NCC is one of four Regional Internet Registries (RIRs) that provide Internet resource allocation, registration services and co-ordination activities that support the operation of the Internet globally. The RIPE NCC is an independent, not-for-profit membership organisation that provides services to members in its service region currently covering Europe, the Middle East, Central Asia and African countries located north of the equator. Any further questions about the RIPE NCC Regional Meeting, Middle East can be sent directly to: . Regards, Sabrina Wilmot Membership Liaison Officer RIPE NCC From hpholen at tiscali.no Mon Oct 13 01:13:08 2003 From: hpholen at tiscali.no (Hans Petter Holen) Date: Mon, 13 Oct 2003 01:13:08 +0200 Subject: [address-policy-wg] Some questions regarding the NRO proposal Message-ID: <006b01c39116$672f0a70$366eead5@no.tiscali.com> Dear all, First of all I would like to congratulate the RIRs with a constructive and solid proposal to move forward. I think the formalization of an organization to help the RIRs act in a coordinated manner is lomg overdue. As a general comment I think the detailed specification of the global policy making process is a step forward. Under the current MOU this is not well defined and clarification of the process should be much welcomed to all involved. In reading the proposal I have some questions, first to the NRO Agreement: 6. NRO Executive council Is there a clear enough division between legislative and executive roles? One of its roles is to ratify and reject global IP number policies. (Legislative), at the same time the Executive council is empowered to sign documents and contracts (executive). Maybe it needs some clarification in the language to make it clearer that the EC simply ratifies that polices has been formed according to process. 7 NRO Number Council ii Composition What is the reason for the proposed composition? The Board of the RIRs are elected by the members of the RIR and the current procedures for electing ASO AC members are that mostly the members elect the council members. The proposal is in reality a combination between a direct and indirect election. What is the advantage of this? Why not revert to just one approach direct or indirect election? a) Election by RIR members b) Election by RIR boards The Council shall under the agreement elect a chair. It may also be necessary to elect co-chairs and a secretary for the Council to maximize its ability to conduct its tasks. Regarding the composition of the two councils: what conflicts of interests exists between the two and the bodies of the RIRs? Are there global conflicts of interests or should this be left to the individual RIRs to decide? Then to the ASO MOU Attachment A: Global Policy Development Process: 4. For some RIRs (RIPE NCC) this introduces a new role to the Board in ratif ying policy proposals. While this may be a good idea - it does require some changes to the regional policy process to be aligned. Best Regards, Hans Petter Holen From hpholen at tiscali.no Mon Oct 13 07:21:10 2003 From: hpholen at tiscali.no (Hans Petter Holen) Date: Mon, 13 Oct 2003 07:21:10 +0200 Subject: [address-policy-wg] Proposed Open Letter to ICANN and Related Documents References: <5.2.0.9.2.20030923104551.034192d8@localhost> Message-ID: <012501c3914a$26409540$366eead5@no.tiscali.com> Dear All, I have not seen to many coments to this proposal from the communicty yet. As this may be an important step forward for the Addressing community in formalizing the relationship with ICANN I would really urge all of you to spend some time reading the proposals. My very brief exec overview is: 1) The RIRs set up a comtting copperation trough the Numbering Resource Organisation so that they can enter into agreements witth 3rd parties. 2) An executive council is formed to have such authority 3) and to ratify global addressing policy 4) a Number Council with 3 representatives from each RIR is set up to give the Exec Board advice on global addressing policy 5) In the Number Council 1 representative is appointed by the RIR boards - the orther trough an open process 6) In the ICANN relationship the Number council acts as the Address council 7) There is a definition of Global Policy process It would be interesting to se community comments on theese issues - please read http://www.ripe.net/ripencc/about/regional/draft-public-comment.html ! and http://www.apnic.net/nro-comments ! Best Regards Hans Petter Holen Address Policy Chair ----- Original Message ----- From: "Axel Pawlik" To: ; ; Sent: Tuesday, September 23, 2003 11:12 AM Subject: [address-policy-wg] Proposed Open Letter to ICANN and Related Documents | | Dear Colleagues, | | | The Regional Internet Registries (RIR) have published | three (3) documents: | | a. Proposed Open Letter to ICANN from the Regional | Internet Registries | b. Proposed Agreement between the RIRs to create the | Number Resource Organization | c. Proposed Agreement between the RIRs (acting through | the NRO) and ICANN concerning the Address Supporting | Organization | | These documents are available on a single web page at: | | http://www.ripe.net/ripencc/about/regional/draft-public-comment.html | | In order to ensure that RIR members and address communities in every | region have the opportunity to comment, the Board of the RIRs have | requested that RIRs post the documents for a period of 30 days. The | comment period closes at midnight (UTC) on the 22nd October 2003. | | Each of the RIR Boards will consider the comments as they are | received, and each RIR Board intends to make a decision whether to | adopt these documents following this comment period. If these | documents are adopted by all the RIR Boards, it is the present | intention to formally pass the following open letter to ICANN on the | 24th of October. On the same date the Boards of the RIRs currently | intend to direct their CEOs to sign the MoU concerning the | establishment of the Number Resource Organization. | | All comments should be addressed to: nro-comments at apnic.net. The | comments will be passed to all the Boards of the RIRs, and will also | be published on the web site http://www.apnic.net/nro-comments. Any | dialogue that arises from such comments will also be published on this | site. | | Subscription information for the nro-comments mailing list is | available at: | | http://mailman.apnic.net/mailman/listinfo/nro-comments | | All postings to this mail address (nro-comments at apnic.net) are | public, and will be published at the following URL: | | http://www.apnic.net/nro-comments | | kind regards, | | Axel Pawlik | Managing Director | RIPE NCC | From leo at ripe.net Mon Oct 13 10:17:25 2003 From: leo at ripe.net (leo vegoda) Date: Mon, 13 Oct 2003 10:17:25 +0200 Subject: [address-policy-wg] Call for volunteers: editorial group to revise "Charging by Local Internet Registries" document Message-ID: Dear Colleagues, Last month at RIPE 46 the RIPE Address Policy Working Group (AP WG) discussed the RIPE document "Charging by Local Internet Registries" (ripe-152). The document was published in 1996 and describes "charging for services by Internet registries and indicates acceptable practice for such charging". It can be found at: Particular attention was given to the statement that "registries may charge for their administrative and technical services, they may not charge for name space or address space as such; no unit cost or price tag can be attached to a domain name or to an IP address, public or private." It was agreed that an editorial group of volunteers from the community should be formed discuss the document and suggest changes to its text and content. A mailing list has been created for this discussion. The list is open to anyone wishing to participate. If you want to subscribe to the list you can do so via the web interface at: Additionally, a web archive of the discussion can be found at: Kind regards, -- leo vegoda RIPE NCC Registration Services Manager From leo at ripe.net Tue Oct 14 16:53:36 2003 From: leo at ripe.net (leo vegoda) Date: Tue, 14 Oct 2003 16:53:36 +0200 Subject: [address-policy-wg] Draft minutes: RIPE 46 Address Policy WG session Message-ID: <8QZes9mw3Aj$Ew60@ripe.net> Dear Colleagues, Draft minutes from the Address Policy Working Group session at RIPE 46 can be found at: http://www.ripe.net/ripe/wg/address-policy/r46-minutes.html Please check the minutes for errors or omissions. Comments and corrections can be sent directly to this list or to one of the WG chairs personally. Additionally, draft minutes from the LIR Working Group at RIPE 45 are can be found at: http://www.ripe.net/ripe/wg/lir/r45-minutes.html These have not yet been approved and can still be corrected if appropriate. Kind regards, -- leo vegoda RIPE NCC Registration Services Manager From frode at greisen.net Wed Oct 15 12:20:39 2003 From: frode at greisen.net (Frode Greisen) Date: Wed, 15 Oct 2003 12:20:39 +0200 Subject: [address-policy-wg] Re: [Nro-comments] Some questions regarding the NRO proposal In-Reply-To: <006b01c39116$672f0a70$366eead5@no.tiscali.com> Message-ID: Dear Hans Petter, > On 13/10/03 1:13, "Hans Petter Holen" wrote: > Dear all, > > First of all I would like to congratulate the RIRs with a constructive and > solid proposal to move forward. I think the formalization of an organization > to help the RIRs act in a coordinated manner is lomg overdue. > > As a general comment I think the detailed specification of the global policy > making process is a step forward. Under the current MOU this is not well > defined and clarification of the process should be much welcomed to all > involved. > > In reading the proposal I have some questions, first to the NRO Agreement: > > 6. NRO Executive council > > Is there a clear enough division between legislative and executive roles? > > One of its roles is to ratify and reject global IP number policies. > (Legislative), > at the same time the Executive council is empowered to sign documents and > contracts (executive). Maybe it needs some clarification in the language to > make it clearer that the EC simply ratifies that polices has been formed > according to process. > > The formal ratification/rejection by the Executive Council would only take place in the (probably unlikely) scenario where ICANN fails and sombody else would have to steward the policy formation process. And both in this scenario and in the scenario where an MoU with ICANN is in force the work with developing policy would be undertaken by the Numbers Council, not by the Executive Council. > 7 NRO Number Council > > ii Composition > What is the reason for the proposed composition? > The Board of the RIRs are elected by the members of the RIR and the current > procedures for electing ASO AC members are that mostly the members elect the > council members. > The proposal is in reality a combination between a direct > and indirect election. What is the advantage of this? > > Why not revert to just one approach direct or indirect election? > a) Election by RIR members > b) Election by RIR boards > The proposal is that two thirds of the Numbers Council members are elected directly by the regional policy fora the same way that Advisory Council members are elected today. Since the policies which are developed by the regional fora and will eventually be administered by the RIRs the proposal a minority of RIR board selected members (who might possibly be RIR staff) in the Numbers Council are intended to help secure the practical feasibility of such policies. > The Council shall under the agreement elect a chair. It may also be > necessary to elect co-chairs and a secretary for the Council to maximize its > ability to conduct its tasks. The intention was that the NRO secretariat would support the Numbers Council. But your suggestion is useful and we will take it into consideration. > > Regarding the composition of the two councils: what conflicts of interests > exists between the two and the bodies of the RIRs? Are there global > conflicts of interests or should this be left to the individual RIRs to > decide? > As far as the Executive Council is concerned their role in the NRO is administrative so there does not seem to be any conflict of interest. As for the Numbers Council, the idea is to let the Regional fora and the RIR boards handle any conflicts of interest at the time of election or selection. > > Then to the ASO MOU Attachment A: > Global Policy Development Process: > 4. For some RIRs (RIPE NCC) this introduces a new role to the Board in ratif > ying policy proposals. > While this may be a good idea - it does require some changes to the regional > policy process to be aligned. > I think you refer to points 3. and 4. in Attachment A? I'm not sure that there is at present a policy formulated for working out a common policy based on similar but still different policies developed by the the different RIRs? The proposal is that RIR staff would do technical and clerical work in this area and that the boards would ratify the outcome. Obviously, if there is major policy work involved in getting a common proposal the issue would go back to the regional policy fora. best regards, Frode Greisen RIPE NCC Executive Board Member > > Best Regards, > Hans Petter Holen > > > > > > > > > _______________________________________________ > Nro-comments mailing list > Nro-comments at apnic.net > http://mailman.apnic.net/mailman/listinfo/nro-comments > > From leo at ripe.net Wed Oct 15 16:04:06 2003 From: leo at ripe.net (leo vegoda) Date: Wed, 15 Oct 2003 16:04:06 +0200 Subject: [address-policy-wg] RIPE NCC allocations to African LIRs Message-ID: Dear Colleagues, The RIPE NCC received the IPv4 address range 196.200.0.0/13 from ARIN in October 2003. This range will be used to make allocations and assignments to organisations based in African countries served by the RIPE NCC. This block is part of a /8 also used by ARIN. In order to reduce confusion the RIPE NCC will not assign prefixes longer than a /24 from it. 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: Kind regards, -- leo vegoda RIPE NCC Registration Services Manager From hpholen at tiscali.no Thu Oct 16 21:09:10 2003 From: hpholen at tiscali.no (Hans Petter Holen) Date: Thu, 16 Oct 2003 21:09:10 +0200 (CEST) Subject: [address-policy-wg] Re: [Nro-comments] Some comments on the text (fwd) Message-ID: FYI: Some further clearifications on the NRO proposal -hph ---------- Forwarded message ---------- Date: Wed, 15 Oct 2003 22:59:51 +0200 From: Frode Greisen To: sabine jaume , nro-comments at apnic.net Cc: Hans Petter Holen , "Wilfried Woeber, UniVie/ACOnet" Subject: Re: [Nro-comments] Some comments on the text Dear Sabine, > On 14/10/03 8:39, "sabine jaume" wrote: > Dear all, > > After reading the NRO proposal and the ASO MoU, here are some comments > on the text, which to my opinion need clarification for better > understanding and/or to avoid misunderstanding. > > > NRO Proposal > > Chapter 1 : > The creation of the NRO doesn't need ICANN's acceptance : as far as RIR > sign the agreement it is considered in force. Did I understand it correctly? yes, this is correct. > > The signature includes RIRs who are signatories : what about any new > possible RIR? I would add here a reference to chapter 3 in case a new > RIR wants to sign the agreement later on. As you say, the intention is that new RIRs can join with equal rights. As the text stands, Chapter 3 provides for the inclusion of new RIRs. Just as the situation exists today, the new RIR must meet objective criteria and must sign the MoU. > > Chapter 2 : > This description is fully in line with the operationnal business of RIRs. > > Chapter 4 : > Here I find an inconsistency with chapter 2 : indeed if the NRO has an > operationnal role, how can it also intervene in policy making processes. > This is how I interpret the fact that the NRO Number Council is under > the responsability of the NRO Exec Council (see chapter 6). see comment below. > > Incorporation : under which law? We felt no need to define law and location before a decision to incorporate. This will be agreed by the RIR signatories at that time. > > Chapter 6 : > Here is where policy-making process- and day to day busines of > RIRs are mixed. > What happens if the Number Council makes proposals > following bottom up process which are rejected by the NRO (see comment > on ASO MoU text)? The Executive Council is responsible for external communication but in the (probably most likely) scenario policy ratification is done by ICANN as defined in the ASO MoU and the Executive Council will not make policy. It is only in the stand-alond scenario after and ICANN failure that the Executive council would in reality ratify or reject. The sense of the document is that the Executive council would then act in the role of the ICANN board as far as address policy ratification is concerned and would only base its decision on whether due processes were followed or not. In order to avoid duplication, all the relevant procedures defined in the ASO MoU and its attachment are not also spelled out in the NRO document. In the case of rejection, any dissatisfied party could resort to the appeals process. > > Chapter 7 : > Here the bottom up process should be described. > You may be right. In the scenario where the global policy process is defined in an ASO MoU with ICANN that MoU defines the bottom up process. > > Aren't the ICANN board directors election the Number Council's duties > any more? The Address Council will select ICANN Board members as provided for in the ICANN by-laws and the ASO MoU. When the ASO MoU is agreed to between the RIRs and ICANN, the Numbers Council will become the ASO Address Council and will function under the provisions of the ASO MoU. > > What are the lenghts of each person's term? Can they be renewed? > Can the 2 selected persons be RIR staffed persons? > Good questions. Since there would probably be a transition from the present Address Council to the Numbers Council a staggering would need to be defined but we felt it would be better to have a basic agreement with ICANN and also seeking advice from the present Address Council before getting into defining a system for this. A reasonable assumption would be to get to three year terms like now. RIR staff members may not be elected to either of the two elected seats. An RIR staff member may be appointed by theappropriate RIR Board to the one RIR appointed positon from each region. > > Chapter 9 : > How long will people seat on the Appeals Panel? > Experience from the RIPE NCC arbitration panel shows that the arbiters have not been very busy. My personal preference would be to let the NRO ping the selected representatives about annually, and keep them as long as they are willing and and able and have the desired knowledge. > > Chapter 10 : > In case of an abitration that takes long time : what will happen? Is > there a kind of provision that says that during the time there is no > decision, policies will be applied as they were before the dispute started? > Good point. As usual, the appeals process is institued to seek agreement before a part resorts to a lawsuit. The pressure to avoid suits should be an incentive for the appeals panel to act quickly, however, the circumstances of each situation will dictate deadlines. Therefore, a one size fits all time is not suitable. It may be worth considering, but perhaps difficult to decide in advance for all cases, whether initiation of appeal should have holding effect on the process in question. > > Chapter 11 : > How is an RIR member defined? This is an RIR signatory. Should probably be clarified in the text. > > What is the clause 12b? > Thanks for spotting this! This should say 1.2. > > Chapter 12 : > What are those technical activities : could be a lots of things... > Yes, and as such they must be agreed by the Executive Council. Examples could be mutual data-base backup between RIRs or global whois services. > > Chapter 13 : > Will the RIR members (again to be defined) pay a fee directly to the > NRO, or will this be done via the RIRs existing fundings? > Like above, RIR member in this chapter means NRO signatory. Since the NRO will not have a budget there will be no fees paid to the NRO. All expenditures will be agreed to by the Executive Council. The Secretariat will track the costs and invoice each RIR as appropriate. Just as is the situation today with regards to funds for the ICANN budget and funds to support ASO and ASO AC activities, the RIRs include these expenditures in their individual budgets. In regard to the NRO and the new ASO and and ASO AC we expect the same method of operation. It is expected that these expenditures will be similar to today's situation. > > What is paragraph "a" refering to? > Thanks! As above, letters were changed to numbers in bullet points, so this should be paragraph 13.1. > > ASO MoU > > From the NRO document statements, the Address Council is under the > responsablity of the NRO Exec council, and has RIR appointed members. So > what does "in conjunction with the RIRs" means? > > Again the split between policy making process and operations is > confused, because of the ASO AC being under the responsibility of the > NRO. Indeed point 4 stresses that the RIRs Board do have a policy making > role. > "In conjunction with the RIRs" means that both the Address Council and the RIRs will work together. While it is anticipated that most questions and concerns of the RIRs can be dealt with by the RIR appointed members of the Adress Council, there always exits the possibiliy that additional information may have to be gathered by RIR staffs or the RIR Boards may need to comment. Thanks for your thoughtful questions and comments. For further discussion you may also want to check http://www.ripe.net/ripencc/about/regional/nro-faq.html Frode Greisen RIPE NCC Executive Board Member > > Looking forward to any clarification you can provide, > > Thanks! > > Best regards, From hpholen at tiscali.no Thu Oct 16 21:09:53 2003 From: hpholen at tiscali.no (Hans Petter Holen) Date: Thu, 16 Oct 2003 21:09:53 +0200 (CEST) Subject: [address-policy-wg] [Nro-comments] Revised FAQ (fwd) Message-ID: ---------- Forwarded message ---------- Date: Wed, 15 Oct 2003 04:42:10 -0400 From: Ray Plzak To: nro-comments at apnic.net Subject: [Nro-comments] Revised FAQ Below is a revised list of FAQ concerning the NRO MoU and the ASO MoU. Thwy will be posted on the RIR websites. Ray ************************************************************ Frequently Asked Questions about the NRO MoU and ASO MoU 1. Why can't the RIRs and ICANN sit down and discuss their differences? The RIRs and ICANN have been very actively engaged in discussions and both parties have taken every opportunity to keep the dialogue open and continuous. These discussions have been constructive and productive and have included face-to-face meetings as well as teleconferences. 2. Why are the RIRs trying to replace ICANN? The RIRs are firmly committed to ICANN and to its viability. Within the ICANN framework, the RIRs have two objectives which they see as of paramount importance to the addressing community. a. Protection of the unallocated number resource pool (IPv4, IPv6, and ASN). Access to the unallocated number resources pool by the RIRs is controlled by global policy. b. Protection of the policy development process so that policies cannot be imposed top down on the community. Neither the ICANN Board nor any of the RIR Boards can impose policy. 3. Does the NRO replace ICANN? No. One of the functions that the NRO is intended to provide is to undertake if necessary those IANA functions that pertain to the management of number resources. The NRO is not being structured as a potential 'complete' ICANN replacement in the event of failure of ICANN. The consideration here was that in such an event it was considered probable that the various IANA functions would be undertaken by those with a direct interest in each particular functional area. 4. Does the NRO replace the ASO? No. The NRO is a stand alone body that will negotiate the ASO MoU with ICANN. Upon implementation certain aspects of the NRO will become part of the ASO. For example, the NRO Numbers Council will become the ASO Address Council. Other aspects, such as the Executive Council will not become part of the ASO but will continue to represent the RIRs acting in concert. 5. Why do we need another layer of bureaucracy? We don't! The NRO is not another layer of bureaucracy. Within this proposed framework the essential elements of interaction between the RIRs and ICANN remain unaltered. ICANN continues to operate the unallocated Internet number resource registries. The Board of ICANN has the continued ability to ratify proposed global number resource policies. An Address Council continues to undertake a role as a source of advice to the Board of ICANN on Number Resource matters, as well as shepherding proposed global address policies through ICANN for ratification. 6. If the NRO doesn't replace ICANN or the ASO or change anything in the current structure, what does it do? How does it change the relationship between ICANN and the RIRs? The NRO is an interface for organizations outside of the RIRs to interface directly with them at a single point instead of dealing with each RIR separately. For example this allows ICANN to interact directly on non policy items such as the ICANN budget and service contracts. Currently, ICANN must deal with each individual RIR on such matters. The NRO provides a similar single interface to the RIRs for other organizations, such as the IETF, on Internet number resource administration issues. The NRO also provides a visible framework for existing cooperative joint activities in which the RIRs are already engaged. Such activities include the administration of upper level reverse DNS domains. Future activities of this nature will also be undertaken within the framework of the NRO, such as a common whois interface to RIR data. 7. Are open and accessible processes being used in the development of the NRO MoU and the ASO MoU? In both cases an open and accessible policy process is being used. The RIR Boards, exercising their policy process and fiduciary responsibilities, have drafted two documents and have placed them in the public domain for comment. The RIRs are undertaking to organize the NRO for the purpose of providing an organizational structure to support the various inter-RIR cooperative arrangements that have evolved over the last three years as the RIRs have worked in concert in both technical and policy areas. The comment period is to elicit any comments that the regional communities may have in regard to this formalization of already existing practices. It is currently proposed that the NRO MoU will be signed at the end of the comment period, with this proposed action being dependant on an assessment of comments received in this period. In the case of the ASO MoU, after the regional community comment period it will be presented to ICANN as a draft document for their consideration. It is expected that there will be some negotiation between ICANN and the NRO after which time the negotiated draft will again be placed in the public domain. Of course anytime during this period any one is more than welcome to comment. 8. Will this proposal dramatically change the relationship between ICANN and the RIRs? Neither the NRO MoU nor the ASO MoU will dramatically change the relationship between ICANN and the RIRs. In the case of the NRO, it is intended to improve the relationship, as ICANN will have a single consistent point of contact for such matters as budget and service contracts. In the case of the ASO MoU the biggest change is additional protections for the bottom up policy process, as the proposed policy development process will prevent the ICANN board from exercising a veto by direct action or by non-action on any policy proposal. It further protects the process by preventing the ICANN board from making policy and directing it down to the addressing community. 9. Will the NRO MoU and the ASO MoU have any wide-ranging impacts on technical coordination, planning, and administration of addressing and numbering policy? The NRO MoU and the ASO MoU will have impact in some areas, but it will be only to strengthen the protection of the unallocated number resource pool and the bottom up policy process. Areas not changed: a. The bottom up policy process from the addressing community to the RIR fora will not change. b. The bottom up policy process for global policy from the addressing community to the ASO AC will not change. c. The administration of policy between the RIRs and the community in their respective service regions will not change. d. The administration of addressing policy between the IANA and the RIRs will not change. Areas that will change under these proposals: a. The ICANN board will not be able to make and direct top down addressing policy. b. The ICANN board will not be able to veto a global policy proposal by direct or indirect means. c. Activities where the RIRs act in concert will be strengthened by the formalizing of an already existing relationship. This will occur in such areas as policy harmonization, technical coordination, and planning. d. Activities such as technical coordination and administration of policy where the IANA must interact jointly with the RIRs will be simplified as the IANA will now have a single interface point. 10. How transparent are the activities of the NRO Executive Council going to be? Every meeting of the NRO Executive Council will be transparent as the agenda and minutes of each meeting will be published. 11. How will the appeals process work? The appeals process is an advisory process., designed to provide advice in regards to the operation of policy process. It is not designed to decide the merits of a policy, but rather, to examine the policy process in regards to any global policy for which a constituency of the addressing community is aggrieved. The Advisory Appeals Panel (AAP) may hear complaints regarding the activities of any or several RIRs, the NRO or and NRO sub-organization such as the Numbers Council. The AAP may dismiss frivolous, repetitive or nuisance complaints with without further review. The AAP decision is intended to serve as a persuasive advisory opinion and therefore it will not provide any basis for legal action in any jurisdiction. The appeals process does not alter the appeals process in any way within the responsibility of any RIR, and no appeals prerogatives or options are being ceded by the RIRs to the NRO under this proposal. 12. How is the Advisory Appeals Panel formed? The Advisory Appeals Panel (AAP) will consist on one (1) member from each RIR service region. They will be selected by the NRO Executive Council. Members of the AAP cannot be an employee of an RIR nor a member of any RIR Board. They will be selected based upon their knowledge of the Internet community in general and the addressing community in particular. The AAP will adopt such policies and procedures that are necessary to make it an accessible, open, transparent, and documented. These policies and procedures will include such things as voluntary or requested recusal of panel members, procedures for reporting to the NRO Executive Council, and procedures to address any allegation of fraudulent or dishonest conduct by panel members. 13. Can the Advisory Appeals Panel be effective? Yes. It is intended that the members of the Advisory Appeals Panel (AAP) will be well known and respected members of the Internet community. Although their decisions will carry no basis for legal action, it is anticipated that their advice will be the product of a thorough and stringent process of investigation and review and that any advice that the panel may provide will be well grounded. 14. These documents will have long-lasting effects. It is hoped that this is indeed the case. It is the intent of these documents to put into place provisions that will protect the unallocated number resource pool and the bottom up policy process thus contributing directly to the security and stability of the Internet for years to come. It is expected that as the Internet environment changes over time that these documents may have to be revised, thus it is expected that they will be reviewed from time to time. _______________________________________________ Nro-comments mailing list Nro-comments at apnic.net http://mailman.apnic.net/mailman/listinfo/nro-comments From Thomas.Levy at alcatel.fr Fri Oct 17 10:56:51 2003 From: Thomas.Levy at alcatel.fr (Thomas.Levy at alcatel.fr) Date: Fri, 17 Oct 2003 10:56:51 +0200 Subject: [address-policy-wg] Questions on Provider Independent IPv4 addresses, Message-ID: <3F8FAED3.2020203@alcatel.fr> Hello, I read with interest the ripe-234 document on IPv4 address allocation. It raised me the following questions on PI addresses: 1) Usage of PI addresses is not recommended by RIPE. I don't want to raise a debate on this point. However, I would be interested in knowing the reasons for this. Is it for routing purpose? 2) How could I find statistics on PI allocated addresses (by RIPE or globally)? Please apologise, if it is not the best appropriate place, where to ask such questions. I looked for the answer on the RIPE web site. But, I couldn't find the information. Regards, Thomas Levy From leo at ripe.net Fri Oct 17 15:37:39 2003 From: leo at ripe.net (leo vegoda) Date: Fri, 17 Oct 2003 15:37:39 +0200 Subject: [address-policy-wg] Questions on Provider Independent IPv4 addresses, In-Reply-To: <3F8FAED3.2020203@alcatel.fr> References: <3F8FAED3.2020203@alcatel.fr> Message-ID: Hi Thomas, Thomas.Levy at alcatel.fr wrote: >Hello, > >I read with interest the ripe-234 document on IPv4 address allocation. >It raised me the following questions on PI addresses: >1) Usage of PI addresses is not recommended by RIPE. I don't want to raise a debate on this >point. However, I would be interested in knowing the reasons for this. Is it for routing >purpose? >2) How could I find statistics on PI allocated addresses (by RIPE or globally)? The why of PI assignments is an ongoing discussion. There has been some discussion on the list which was followed up on this list. The list archives can be found at: http://www.ripe.net/ripe/mail-archives/pi-tf/ I prepared some statistics on PI assignments in a summary of the PI TF discussions. You can find them at: http://www.ripe.net/ripe/mail-archives/address-policy-wg/2003/msg00030.html I hope this is helpful for you. Best regards, -- leo vegoda RIPE NCC Registration Services Manager From leo at ripe.net Fri Oct 17 16:36:18 2003 From: leo at ripe.net (leo vegoda) Date: Fri, 17 Oct 2003 16:36:18 +0200 Subject: [address-policy-wg] Revised Draft Document for review: "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" In-Reply-To: <200310061058.h96AwFx0024900@banknet.banknet.net> References: <200310061058.h96AwFx0024900@banknet.banknet.net> Message-ID: Hi, Thanks for contributing to the review of the document. I think the suggested text can help improve the clarity of the document. I have a couple of comments on specific questions, too, though. Janos Zsako wrote: [...] >4. In paragraph 6.1. I have a question and a suggestion related to the >statement: > >"If a request needs to be approved by the RIPE NCC or if information is >required in the event of an audit, the information must be submitted on a >current version of the request form found at:" > >It is clear that in case of a new request that needs to be approved, >information must be submitted on the current form. The question I have >is related to the audit of a prior assignment: does the LIR have to >produce the documentation in the _current_ version of the form? I would >think that producing the documentation on the form used _at_the_time_of >the assignment would be acceptable. If so, it may be good to slightly >rephrase the above to reflect this. You're right. We'll update the phrasing. >5. I have the impression that the AW applied to an End User network >(paragraph 7.0) is not clear enough, so I suggest adding a couple of new >words: > >"An AW can be applied to an End User network once per 12-month period. >This means an LIR can make more than one assignment to an End User >_in_any_such_12_months'_period, but the total amount of address space I think this should be added to improve clarity but... >cannot be larger than the LIR's AW. An LIR's AW is considered unused on >the anniversary of the first (?!? I would think _last_) assignment to >the End User._After_the_exhaustion_of_the_AW, the LIR may only assign >additional addresses to the same End User after approval from the RIPE >NCC. > >(In one of the sentences above I have the impression that first should >be changed to last - did I misunderstood something?) ... I think the ambiguity in the wording here reflects the ambiguity in the policy. We could update the wording to use the word "last" but that would make the policy more strict than it is at the moment. At some point it would be useful to review and rationalise the current AW policy. It is fairly complicated to document and so fairly documented to use. It would be good (after publishing this updated document, I hope) to take a new look at this part of the policy. [...] >7. I have a question regarding the value "NOT-SET" of the status attribute >(paragraph 9.0). The document states that _new_ objects cannot be created >with this attribute. I would expect the database to also reject updates that >have such an attribute. Is this the way the database behaves? If yes, it >may be useful to mention this here ( I suggest something like: >"Objects cannot be created or updated with this value".) I think I ought to give a little explanation of a problem we were had noticed and why we suggested introducing this new status attribute value. When the status attribute was introduced it wasn't automatically added to all objects. At a later date it was made mandatory for inetnum objects. This meant that it was not possible to update an inetnum object without adding a status attribute. The result of this is that people that wanted to update contact information and didn't know (or care) about the status attribute were unable to do so. Net result: poorer quality information. For this reason, we would explicitly prefer to allow objects with this value to be updated on the principle that half a loaf is better than no bread. Emma Apted wrote: [good stuff] >In the last paragraph of section 9.0 we have "If an LIR has an End User >that requires PI address space they should refer the End User to an >appropriate registry. " Does this mean that if an ISP, who is an LIR, >is approached by a customer who says they require PI space, that the >LIR should simply give the RIPE NCC URLs and email addresses to the >customer, so they can send the request themselves to RIPE NCC? Or can >the LIR send the request, on behalf of the customer, to the RIPE NCC? In cases like this LIRs can send us requests for PI assignments for their customers. Currently, the RIPE NCC doesn't provide registration services directly to End Users. Best regards, -- leo vegoda RIPE NCC Registration Services Manager From gert at space.net Fri Oct 17 19:44:13 2003 From: gert at space.net (Gert Doering) Date: Fri, 17 Oct 2003 19:44:13 +0200 Subject: [address-policy-wg] Questions on Provider Independent IPv4 addresses, In-Reply-To: <3F8FAED3.2020203@alcatel.fr>; from Thomas.Levy@alcatel.fr on Fri, Oct 17, 2003 at 10:56:51AM +0200 References: <3F8FAED3.2020203@alcatel.fr> Message-ID: <20031017194413.M67740@Space.Net> Hi, On Fri, Oct 17, 2003 at 10:56:51AM +0200, Thomas.Levy at alcatel.fr wrote: > 1) Usage of PI addresses is not recommended by RIPE. I don't want to > raise a debate on this point. However, I would be interested in knowing > the reasons for this. Is it for routing purpose? One of the major disadvantages of PI space to achieve global internet connectivity is "impact on global routing". Especially for networks needing only fairly few addresses, using addresses from their ISP's PA network blocks means that their route can be aggregated into the ISP's PA route, so the individual network doesn't have an impact on all routers world-wide that carry the full IPv4 routing table. A PI network will always be visible as an individual route, with no way to aggregate it. Of course PI has advantages (it's much more convenient for the enterprise in question) and in some cases there is no way around PI (enterprise-local networks that are not connected to any ISP but need unique address space for VPN partner connections etc.). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 57785 (56883) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From zsako at banknet.net Sat Oct 18 09:55:10 2003 From: zsako at banknet.net (Janos Zsako) Date: Sat, 18 Oct 2003 09:55:10 +0200 Subject: [address-policy-wg] Revised Draft Document for review: "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" References: <200310061058.h96AwFx0024900@banknet.banknet.net> Message-ID: <3F90F1DE.9020807@banknet.net> Dear Leo, Thank you for your reply and for your explanations. I am afraid I still do not understand something about the AW (and I have a comment below). >> 5. I have the impression that the AW applied to an End User network >> (paragraph 7.0) is not clear enough, so I suggest adding a couple of new >> words: >> >> "An AW can be applied to an End User network once per 12-month period. >> This means an LIR can make more than one assignment to an End User >> _in_any_such_12_months'_period, but the total amount of address space > > > I think this should be added to improve clarity but... > >> cannot be larger than the LIR's AW. An LIR's AW is considered unused on >> the anniversary of the first (?!? I would think _last_) assignment to >> the End User._After_the_exhaustion_of_the_AW, the LIR may only assign >> additional addresses to the same End User after approval from the RIPE >> NCC. >> >> (In one of the sentences above I have the impression that first should >> be changed to last - did I misunderstood something?) > > > ... I think the ambiguity in the wording here reflects the ambiguity in > the policy. We could update the wording to use the word "last" but that > would make the policy more strict than it is at the moment. At some > point it would be useful to review and rationalise the current AW > policy. It is fairly complicated to document and so fairly documented to > use. It would be good (after publishing this updated document, I hope) > to take a new look at this part of the policy. I quote below the relevant part of RIPE-234: " 5.2.5.2 Assignment Window for End User Assignments An LIR can apply their Assignment Window to an End User network only once in any 12-month period. This means that if an LIR makes more than one assignment to an organisation, the total amount of address space assigned with their AW in any twelve month period may not exceed the LIR's AW size. The LIR may only assign additional addresses to the same organisation after approval from the RIPE NCC. " In my view, this means that I may for example assign an AW worth of address space to the End User on 1 January of every year (assuming that I make no further assignments during the year). I also understand that the AW is unused at a moment in time, if at that moment I am allowed to assign an AW worth of address space (to that particular End User). In the above example, let's assume that I started assigning address space to the End User on 1 January 2000. The last time I have therefore assigned to them was 1 January 2003. If I read the text of the Draft, this means that my AW (with respect to that End User) is UNUSED, as it has to be considered unused starting 1 January 2001 (the anniversary of the FIRST assignement). My undertsanding is that it should read "LAST", therefore the AW would have to be considered unused starting 1 January 2004. Did I misunderstand something? > Emma Apted wrote: ... > In cases like this LIRs can send us requests for PI assignments for > their customers. Currently, the RIPE NCC doesn't provide registration > services directly to End Users. My understanding so far was that there are LIRs that have PI allocations, so they can assign PI space to there customers, and there are LIRs who do not have such an allocation. These latter are, however, able to support End Users in getting PI address space by sending these requests to the RIPE NCC (on behalf of the End User, i.e. the End User would not have to, and should not contact the RIPE NCC directly). I agree with Emma that what you state above (and what I hope I have detailed further correctly) is not obvious form the document. It may be a good idea to add some text that clarifies this... Thanks and regards, Janos From leo at ripe.net Sat Oct 18 22:40:10 2003 From: leo at ripe.net (leo vegoda) Date: Sat, 18 Oct 2003 22:40:10 +0200 Subject: [address-policy-wg] Revised Draft Document for review: "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" In-Reply-To: <3F90F1DE.9020807@banknet.net> References: <200310061058.h96AwFx0024900@banknet.banknet.net> <3F90F1DE.9020807@banknet.net> Message-ID: Hi, Janos Zsako wrote: [...] >>> "An AW can be applied to an End User network once per 12-month period. >>> This means an LIR can make more than one assignment to an End User >>> _in_any_such_12_months'_period, but the total amount of address space >> I think this should be added to improve clarity but... >> >>> cannot be larger than the LIR's AW. An LIR's AW is considered unused >>>on >>> the anniversary of the first (?!? I would think _last_) assignment to >>> the End User._After_the_exhaustion_of_the_AW, the LIR may only assign >>> additional addresses to the same End User after approval from the RIPE >>> NCC. >>> >>> (In one of the sentences above I have the impression that first should >>> be changed to last - did I misunderstood something?) >> ... I think the ambiguity in the wording here reflects the >>ambiguity in the policy. We could update the wording to use the word >>"last" but that would make the policy more strict than it is at the >>moment. At some point it would be useful to review and rationalise >>the current AW policy. It is fairly complicated to document and so >>fairly documented to use. It would be good (after publishing this >>updated document, I hope) to take a new look at this part of the policy. > >I quote below the relevant part of RIPE-234: > >" >5.2.5.2 Assignment Window for End User Assignments > >An LIR can apply their Assignment Window to an End User network only once in >any 12-month period. This means that if an LIR makes more than one assignment >to an organisation, the total amount of address space assigned with their AW >in any twelve month period may not exceed the LIR's AW size. The LIR may only >assign additional addresses to the same organisation after approval from the >RIPE NCC. >" > >In my view, this means that I may for example assign an AW worth of >address space to the End User on 1 January of every year (assuming >that I make no further assignments during the year). > >I also understand that the AW is unused at a moment in time, if at that >moment I am allowed to assign an AW worth of address space (to that >particular End User). > >In the above example, let's assume that I started assigning address space >to the End User on 1 January 2000. The last time I have therefore assigned >to them was 1 January 2003. If I read the text of the Draft, this >means that my AW (with respect to that End User) is UNUSED, as it has >to be considered unused starting 1 January 2001 (the anniversary of >the FIRST assignement). My undertsanding is that it should read "LAST", >therefore the AW would have to be considered unused starting 1 January >2004. > >Did I misunderstand something? I think we may have been saying the same thing in different ways. The AW is refreshed on the anniversary of the first assignment. However, the way we look at it is that assignments following the first assignment are subtracted from the 'refreshing' and they have their own anniversaries. For example, if I had a /21 AW and made a /23 assignment to a customer on 1 January 2003 I would have a /22 and a /23 left from my AW for that customer for the rest of the year. If I assigned the same customer another /23 on 1 April, 1 July and 1 October my AW (for that organisation) would return to /23 on 1 January 2004. It would not return to /21 because there were three subsequent assignments each of which has an anniversary. If there's agreement that this is correct then we can update the text for the policy document to something clearer. [...] >My understanding so far was that there are LIRs that have PI allocations, >so they can assign PI space to there customers, and there are LIRs who >do not have such an allocation. These latter are, however, able to >support End Users in getting PI address space by sending these requests >to the RIPE NCC (on behalf of the End User, i.e. the End User would not >have to, and should not contact the RIPE NCC directly). > >I agree with Emma that what you state above (and what I hope I have >detailed further correctly) is not obvious form the document. It may be >a good idea to add some text that clarifies this... Your text here is probably clearer than what was originally written. I think we should use it for the new policy document. Regards, -- leo vegoda RIPE NCC Registration Services Manager From zsako at banknet.net Sun Oct 19 19:25:52 2003 From: zsako at banknet.net (Janos Zsako) Date: Sun, 19 Oct 2003 18:25:52 +0100 (MET) Subject: [address-policy-wg] Revised Draft Document for review: "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" Message-ID: <200310191725.h9JHPq1N018494@banknet.banknet.net> > From leo at ripe.net Sat Oct 18 21:41:55 2003 Dear Leo, > >>> "An AW can be applied to an End User network once per 12-month period. > >>> This means an LIR can make more than one assignment to an End User > >>> _in_any_such_12_months'_period, but the total amount of address space > >> I think this should be added to improve clarity but... > >> > >>> cannot be larger than the LIR's AW. An LIR's AW is considered unused > >>>on > >>> the anniversary of the first (?!? I would think _last_) assignment to > >>> the End User._After_the_exhaustion_of_the_AW, the LIR may only assign > >>> additional addresses to the same End User after approval from the RIPE > >>> NCC. > >>> > >>> (In one of the sentences above I have the impression that first should > >>> be changed to last - did I misunderstood something?) > >> ... I think the ambiguity in the wording here reflects the > >>ambiguity in the policy. We could update the wording to use the word > >>"last" but that would make the policy more strict than it is at the > >>moment. At some point it would be useful to review and rationalise > >>the current AW policy. It is fairly complicated to document and so > >>fairly documented to use. It would be good (after publishing this > >>updated document, I hope) to take a new look at this part of the policy. > > > >I quote below the relevant part of RIPE-234: > > > >" > >5.2.5.2 Assignment Window for End User Assignments > > > >An LIR can apply their Assignment Window to an End User network only once in > >any 12-month period. This means that if an LIR makes more than one assignment > >to an organisation, the total amount of address space assigned with their AW > >in any twelve month period may not exceed the LIR's AW size. The LIR may only > >assign additional addresses to the same organisation after approval from the > >RIPE NCC. > >" > > > >In my view, this means that I may for example assign an AW worth of > >address space to the End User on 1 January of every year (assuming > >that I make no further assignments during the year). > > > >I also understand that the AW is unused at a moment in time, if at that > >moment I am allowed to assign an AW worth of address space (to that > >particular End User). > > > >In the above example, let's assume that I started assigning address space > >to the End User on 1 January 2000. The last time I have therefore assigned > >to them was 1 January 2003. If I read the text of the Draft, this > >means that my AW (with respect to that End User) is UNUSED, as it has > >to be considered unused starting 1 January 2001 (the anniversary of > >the FIRST assignement). My undertsanding is that it should read "LAST", > >therefore the AW would have to be considered unused starting 1 January > >2004. > > > >Did I misunderstand something? > > I think we may have been saying the same thing in different ways. Correct. This is what happened. > The AW > is refreshed on the anniversary of the first assignment. However, the > way we look at it is that assignments following the first assignment are > subtracted from the 'refreshing' and they have their own anniversaries. > > For example, if I had a /21 AW and made a /23 assignment to a customer > on 1 January 2003 I would have a /22 and a /23 left from my AW for that > customer for the rest of the year. If I assigned the same customer > another /23 on 1 April, 1 July and 1 October my AW (for that > organisation) would return to /23 on 1 January 2004. It would not return > to /21 because there were three subsequent assignments each of which has > an anniversary. > > If there's agreement that this is correct then we can update the text > for the policy document to something clearer. I agree with what you detailed in your reply. Yes, please do make the document more clear, as I for one misunderstood it. Thanks and regards, Janos From contact at ripe.net Mon Oct 20 17:12:47 2003 From: contact at ripe.net (Membership Liason Officer) Date: Mon, 20 Oct 2003 17:12:47 +0200 Subject: [address-policy-wg] RIPE NCC Dubai Meeting, Dec. 2003 - Reminder: Hotel Reservations Message-ID: <20031020171247.4dac9312.contact@ripe.net> Dear Colleagues, The RIPE NCC Regional Meeting, Middle East, will be held 7 - 9 December 2003 at the Metropolitan Palace Hotel, Dubai, U.A.E. The meeting will focus on Internet Resource management issues specific to the Middle East. HOTEL RESERVATIONS: The RIPE NCC has arranged for a block of rooms to be held for meeting attendees at the Metropolitan Palace Hotel and the Metropolitan Hotel Sheikh Zayed Road, Dubai. There are a limited number of rooms available, so we strongly suggest you book early to avoid disappointment. For more information about these hotels, and to reserve a room, please see: http://www.ripe.net/ripencc/regional-meetings/dubai-2003/hotel-information.html In addition to your hotel accommodation please remember to register for the RIPE NCC Regional Meeting, Middle East, at: http://www.ripe.net/cgi-bin/dubai-reg Attendance to the RIPE NCC Regional Meeting is open and free of charge. However, attendees are responsible for covering their own travel and accommodation costs. Any further questions about the RIPE NCC Regional Meeting, Middle East, can be sent directly to: . Regards, Sabrina Wilmot Membership Liaison Officer RIPE NCC From gert at Space.Net Fri Oct 24 14:31:27 2003 From: gert at Space.Net (Gert Doering) Date: Fri, 24 Oct 2003 14:31:27 +0200 Subject: [address-policy-wg] FORMAL PROPOSAL: change of initial PA allocation size Message-ID: <20031024123127.GA16484@Space.Net> Hi, this was discussed on the list before the last RIPE meeting, and we had it on the address policy working group meeting (presented by me). I think we mostly have consensus on this issue, but I want to present it as a formal proposal, before it's incorporated into the policy. PROPOSAL: * the minimum initial allocation size (for new LIRs) is reduced from a /20, as of today, to a /21. (If a new LIR can demonstrate need for a bigger initial allocation, they can get a larger address block. This will not be changed). * the requirement to show an immediate need for 25% of the allocated address space is removed for the "minimum initial allocation" The motivation for that is that under the current policy, startup LIRs that do not already hold address space cannot get an initial PA allocation (which would be a /20 as of today, or bigger), because in many cases, they cannot demonstrate immediate need, or prior utilization of sufficient address space. To work around this, many startup LIRs use PI address space as a start, and when they have filled enough of this, apply for their own PA again. The problem with this is that in the end, it's very likely that more than one route will end up in the global BGP table (where one PA route would be sufficient), and also it encourages lying to the RIRs (PI space must not be distributed to third parties, i.e., LIR customers). The drawback of the changes are that it's potentially wasting address space for "very small LIRs" (that would be happy with a /23 PI space and will now get a "huge" /21). The wastage would only happen for very small LIRs that will never grow to fill the initial /21. A rough calculation shows that "1000 new LIR /21 allocations" would need a /11, which is not an unbearable strain on the conservation side, judging from the total number of LIRs in RIPE land today. A second drawback of this is that people may need to adapt their BGP filters to permit /21s from the network block(s) where these allocations are made from. So the RIPE NCC needs to document this accordingly, and ideally, well in advance. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 57785 (56883) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From NTitley at flagtelecom.com Fri Oct 24 15:20:07 2003 From: NTitley at flagtelecom.com (Titley, Nigel) Date: Fri, 24 Oct 2003 14:20:07 +0100 Subject: [address-policy-wg] FORMAL PROPOSAL: change of initial PA all ocation size Message-ID: Gert Doering wrote: > Hi, > > this was discussed on the list before the last RIPE meeting, and we > had it on the address policy working group meeting (presented by me). > > I think we mostly have consensus on this issue, but I want to present > it as a formal proposal, before it's incorporated into the policy. I am strongly in favour of this, it helps to solve the bootstrapping problem that many small LIRs suffer from, and which many have to lie about to get around. > > PROPOSAL: > > * the minimum initial allocation size (for new LIRs) is reduced from > a /20, as of today, to a /21. > (If a new LIR can demonstrate need for a bigger initial > allocation, they can get a larger address block. This will not > be changed). > > * the requirement to show an immediate need for 25% of the allocated > address space is removed for the "minimum initial allocation" > > > The motivation for that is that under the current policy, startup LIRs > that do not already hold address space cannot get an initial > PA allocation > (which would be a /20 as of today, or bigger), because in > many cases, they > cannot demonstrate immediate need, or prior utilization of sufficient > address space. > > To work around this, many startup LIRs use PI address space > as a start, > and when they have filled enough of this, apply for their own > PA again. > The problem with this is that in the end, it's very likely that more > than one route will end up in the global BGP table (where one PA route > would be sufficient), and also it encourages lying to the > RIRs (PI space > must not be distributed to third parties, i.e., LIR customers). > > > The drawback of the changes are that it's potentially wasting address > space for "very small LIRs" (that would be happy with a /23 PI space > and will now get a "huge" /21). The wastage would only happen for > very small LIRs that will never grow to fill the initial /21. > A rough calculation shows that "1000 new LIR /21 allocations" would > need a /11, which is not an unbearable strain on the conservation > side, judging from the total number of LIRs in RIPE land today. > > A second drawback of this is that people may need to adapt their BGP > filters to permit /21s from the network block(s) where these > allocations are made from. So the RIPE NCC needs to document this > accordingly, and ideally, well in advance. > > Gert Doering > -- NetMaster ********************************************************************** This e-mail message is confidential and is intended only for the use of the individual or entity named above and contains information which is or may be confidential, non-public or legally privileged. Any dissemination or distribution of this message other than to its intended recipient is strictly prohibited. If you have received this message in error, please notify us by email to postmaster at flagtelecom.com immediately and delete the original message and all copies from all locations in your computer systems. This e-mail has been swept by Mailsweeper TM for viruses. However, FLAG Telecom cannot accept liability for any damage which you may sustain as a result of software viruses. ********************************************************************** From slz at baycix.de Fri Oct 24 16:49:03 2003 From: slz at baycix.de (Sascha Lenz) Date: Fri, 24 Oct 2003 16:49:03 +0200 Subject: [address-policy-wg] FORMAL PROPOSAL: change of initial PA allocation size In-Reply-To: <20031024123127.GA16484@Space.Net> References: <20031024123127.GA16484@Space.Net> Message-ID: <3F993BDF.8050505@baycix.de> Hay, Gert Doering wrote: > Hi, > > this was discussed on the list before the last RIPE meeting, and we > had it on the address policy working group meeting (presented by me). > > I think we mostly have consensus on this issue, but I want to present > it as a formal proposal, before it's incorporated into the policy. > > > PROPOSAL: > > * the minimum initial allocation size (for new LIRs) is reduced from > a /20, as of today, to a /21. > (If a new LIR can demonstrate need for a bigger initial allocation, > they can get a larger address block. This will not be changed). > > * the requirement to show an immediate need for 25% of the allocated > address space is removed for the "minimum initial allocation" whereas I do support this for the given reasons which already have been discussed on the list(s) and during the RIPE Meeting, i - again - want to raise some side-effect this might have together with another proposal that goes with this one: no more (newly assigned) PI space. Reducing the minimum allocation size + Very-Small RIPE membership is a nice thing for small/start-up companies, but still a problem for very-very-very-small non-commercial organisations or very-very-very-small not-so-commercial companies. I still fear this might lead into the situation that those can't get any independant IP-Space anymore at all. This might also be a negligible issue for most people here, but at least i want to raise it again. I wouldn't like to see than an organisation isn't able to get independant IP-space for monetary reasons, as long as they can show good reasons why they need it. So, there should be some exceptions here, for example (even more) reduced LIR fee for non-commercial organisations or possibility to get some addresses out of the swamp-space in those cases but no PI space in general anymore - or whatever. I don't nescessarily want to complicate the policy again, so i don't give details of how this might be implemented now, but one should keep this in mind for later discussions. Probably this really should be discussed seperately though, so please if you want to reply on this one - use a different Subject. Back to the proposal we have right here: [...] > The drawback of the changes are that it's potentially wasting address > space for "very small LIRs" (that would be happy with a /23 PI space > and will now get a "huge" /21). The wastage would only happen for > very small LIRs that will never grow to fill the initial /21. > A rough calculation shows that "1000 new LIR /21 allocations" would > need a /11, which is not an unbearable strain on the conservation > side, judging from the total number of LIRs in RIPE land today. I do not see any wastage here, at least no important one. Reason: I don't see any need for conservation of IPv4-space anymore. There is IPv6 now, it works, people can implement it. The sooner IPv4 space runs out, the better actually. AND - you all heard the prediction about IPv4 space lasting some more decades during the RIPE meeting (nice presentation :) ==> This "drawback" is none for me. > A second drawback of this is that people may need to adapt their BGP > filters to permit /21s from the network block(s) where these allocations > are made from. So the RIPE NCC needs to document this accordingly, > and ideally, well in advance. That's a bigger problem. I'd say RIPE shouldn't start allocating smaller Prefixes from the existing /8-blocks, but rather get a new one from IANA and start _there_ You all know it's probably not possible to reach all Network Administrators in time to change their filters, some don't even care. This has happend often enough during the last years, one shouldn't even think about it :-( ...my 0.02EUR -- ======================================================================== = Sascha 'master' Lenz SLZ-RIPE slz at baycix.de = = NOC BayCIX GmbH = = http://www.noc.baycix.de/ * PGP public Key on demand * = ======================================================================== From leo at ripe.net Fri Oct 24 19:51:48 2003 From: leo at ripe.net (leo vegoda) Date: Fri, 24 Oct 2003 19:51:48 +0200 Subject: [address-policy-wg] FORMAL PROPOSAL: change of initial PA allocation size In-Reply-To: <3F993BDF.8050505@baycix.de> References: <20031024123127.GA16484@Space.Net> <3F993BDF.8050505@baycix.de> Message-ID: <20031024175148.GA16311@ripe.net> Hi Sascha, On Fri, Oct 24, 2003 at 04:49:03PM +0200, Sascha Lenz wrote: [...] > whereas I do support this for the given reasons which already have been > discussed on the list(s) and during the RIPE Meeting, i - again - want > to raise some side-effect this might have together with another proposal > that goes with this one: no more (newly assigned) PI space. > > Reducing the minimum allocation size + Very-Small RIPE membership is a > nice thing for small/start-up companies, but still a problem for > very-very-very-small non-commercial organisations or > very-very-very-small not-so-commercial companies. > > I still fear this might lead into the situation that those can't get any > independant IP-Space anymore at all. > This might also be a negligible issue for most people here, but at least > i want to raise it again. The proposal being discussed makes no change to the policy for PI assignments. > I wouldn't like to see than an organisation isn't able to get > independant IP-space for monetary reasons, as long as they can show good > reasons why they need it. > > So, there should be some exceptions here, for example (even more) > reduced LIR fee for non-commercial organisations or possibility to get > some addresses out of the swamp-space in those cases but no PI space in > general anymore - or whatever. I think that changes to the fee schedule can only be agreed by the General Meeting. [...] > >A second drawback of this is that people may need to adapt their BGP > >filters to permit /21s from the network block(s) where these allocations > >are made from. So the RIPE NCC needs to document this accordingly, > >and ideally, well in advance. > > That's a bigger problem. I'd say RIPE shouldn't start allocating > smaller Prefixes from the existing /8-blocks, but rather get a new > one from IANA and start _there_ We publish a document detailing our minimum allocation and assignment sizes. The latest version can always be found at: Updates to the document are always announced on a number of mailing lists. If you can suggest a more appropriate set of lists to announce updates then we can update our procedure. Should this proposal be accepted we would not lower the minimum allocation size for any existing /8 to /21. The minimum would be applied to a new /8. This might be an appropriate place to remind people that the draft global policy for allocations from the IANA to RIRs is currently under review. The review period ends on 16 November. The document can be found at: Best regards, -- leo vegoda RIPE NCC Registration Services Manager From slz at baycix.de Fri Oct 24 21:02:15 2003 From: slz at baycix.de (Sascha Lenz) Date: Fri, 24 Oct 2003 21:02:15 +0200 Subject: [address-policy-wg] FORMAL PROPOSAL: change of initial PA allocation size In-Reply-To: <20031024175148.GA16311@ripe.net> References: <20031024123127.GA16484@Space.Net> <3F993BDF.8050505@baycix.de> <20031024175148.GA16311@ripe.net> Message-ID: <3F997737.70608@baycix.de> Hay, leo vegoda wrote: [...] >>I still fear this might lead into the situation that those can't get any >>independant IP-Space anymore at all. >>This might also be a negligible issue for most people here, but at least >>i want to raise it again. > > > The proposal being discussed makes no change to the policy for > PI assignments. right, that's why i wrote that this should be discussed seperately, probably by the time when someone raises the "no PI assignments anymore" policy suggestion again - which also was discussed at various ocassions. But the reasons given for the policy change suggested here are the first steps towards the scenario i described. "No more PI assigments" was always discussed together with the changes suggested here. Due to this circumstances i felt the urge to drop in here already so noone can say "most people in the RIPE community bark after they are hit only instead of joining the discussions early" again. Those annotations in the first paragraphs of my reply was only meant as a reminder for later discussion which i thought was clear enough. Sorry if this was misunderstood. Of course it's nothing directly affecting the change of the First-Allocation Policy... > >>I wouldn't like to see than an organisation isn't able to get >>independant IP-space for monetary reasons, as long as they can show good >>reasons why they need it. >> >>So, there should be some exceptions here, for example (even more) >>reduced LIR fee for non-commercial organisations or possibility to get >>some addresses out of the swamp-space in those cases but no PI space in >>general anymore - or whatever. > > > I think that changes to the fee schedule can only be agreed by the > General Meeting. > > [...] No doubts about that. As i said, i didn't make any concrete suggestions. I just was a bit dissapointed that the newly introduced Extra-Small Membership is still ~2kEUR/year. But there are other possibilities to ensure that every organisation can get address space they want. There are PI assignments now, which i personally do like the way it is handled by RIPE right now. Though as mentioned above lowering the crieria for new LIRs and no need to show an initial use of a /22 is the first step towards shutting down PI assignments because noone (ISP, company..) would need PI space than anymore in first place. They just can get LIR now regardless of how small they are. Most seem to agree, that anyone who "own's" or manages address space should get a LIR in the future. I can only agree to this as long as the financal hurdle here is not set too high, otherwise i think we should keep going with PI/swamp assignments like now, at least for special circumstances. >>>A second drawback of this is that people may need to adapt their BGP >>>filters to permit /21s from the network block(s) where these allocations >>>are made from. So the RIPE NCC needs to document this accordingly, >>>and ideally, well in advance. >> >>That's a bigger problem. I'd say RIPE shouldn't start allocating >>smaller Prefixes from the existing /8-blocks, but rather get a new >>one from IANA and start _there_ > > > We publish a document detailing our minimum allocation and > assignment sizes. The latest version can always be found at: > > > > Updates to the document are always announced on a number of > mailing lists. If you can suggest a more appropriate set > of lists to announce updates then we can update our procedure. > > Should this proposal be accepted we would not lower the minimum > allocation size for any existing /8 to /21. The minimum would be > applied to a new /8. correct, every descent network operator does know the well known places where the RIRs do announce their minimum allocations ect. This just didn't help that often because there are also many not-so-decent network operators who only copy some bogon-filters from some book or article and never update them :-( Better ways of handling this are already being discussed on various other mailinglists, but with not very much consensus yet AFAICS. I can't help much about this, i'm no developer :-) I'd really suggest to start with /21 allocations from a new block and only use the old /8-blocks with their current minimum allocation size of /20 or /19 when a LIR requests Allocations of this size or bigger. In my eyes this would be the least painful and quickest way of introducing /21 Allocations. Anyways, to make it clear in the end: Please go for it! In general i certainly vote in favour for this policy change! -- ======================================================================== = Sascha 'master' Lenz SLZ-RIPE slz at baycix.de = = NOC BayCIX GmbH = = http://www.noc.baycix.de/ * PGP public Key on demand * = ======================================================================== From axel.pawlik at ripe.net Mon Oct 27 09:54:59 2003 From: axel.pawlik at ripe.net (Axel Pawlik) Date: Mon, 27 Oct 2003 09:54:59 +0100 Subject: [address-policy-wg] NRO MoU document revised and signed 24 Oct 2003 Message-ID: <5.2.0.9.2.20031027095031.055a7320@localhost> Dear Colleagues, After considering all comments received, the RIR Boards have developed a further revision of the proposed NRO MoU, as attached here. This document has been signed by the RIR CEOs during the ARIN members meeting in Chicago, USA, at 0900 24 October 2003 (local time). "The Number Resource Organization" document can be found on the RIPE NCC at: http://www.ripe.net/ripencc/about/regional/nro-2003-09-241-1.html The RIR Boards would like to stress that they will continue working together with the community to refine the NRO's functioning. I would like to thank the community for their support in this process. Regards, Axel Pawlik Managing Director RIPE NCC From Mark.Hands at ntl.com Mon Oct 27 14:07:17 2003 From: Mark.Hands at ntl.com (Mark Hands) Date: Mon, 27 Oct 2003 13:07:17 -0000 Subject: [address-policy-wg] IPv4 Exhaustion Message-ID: <6BD051C9C8D4D311A1F000508B5EDBBD02A22260@mast-hk0-se04.private.ntl.com> Hello all, I am trying to get hold of accurate, up-top-date figures showing me how much IPv4 space there is left, and how long that is predicted to last. I cannot find any up-to-date presentations, charts or reports on RIPE, ARIN, ICANN or IANA. Perhaps I am looking in the wrong place....can someone help me please. Thanks very much, Mark Hands ntl: Senior Data Planning Engineer The contents of this email and any attachments are sent for the personal attention of the addressee(s) only and may be confidential. If you are not the intended addressee, any use, disclosure or copying of this email and any attachments is unauthorised - please notify the sender by return and delete the message. Any representations or commitments expressed in this email are subject to contract. ntl Group Limited From hank at att.net.il Mon Oct 27 14:09:28 2003 From: hank at att.net.il (Hank Nussbacher) Date: Mon, 27 Oct 2003 15:09:28 +0200 Subject: [address-policy-wg] IPv4 Exhaustion In-Reply-To: <6BD051C9C8D4D311A1F000508B5EDBBD02A22260@mast-hk0-se04.pri vate.ntl.com> Message-ID: <5.1.0.14.2.20031027150802.00ad4d90@max.att.net.il> At 01:07 PM 27-10-03 +0000, Mark Hands wrote: Geoff Huston gave an excellent plenary presentation at RIPE46: http://www.ripe.net/ripe/meetings/ripe-46/plenary.html but unfortunately the presentation is not available on the RIPE meeting site. -Hank >Hello all, > >I am trying to get hold of accurate, up-top-date figures showing me how much >IPv4 space there is left, and how long that is predicted to last. >I cannot find any up-to-date presentations, charts or reports on RIPE, ARIN, >ICANN or IANA. >Perhaps I am looking in the wrong place....can someone help me please. > >Thanks very much, >Mark Hands >ntl: >Senior Data Planning Engineer > > >The contents of this email and any attachments are sent for the personal >attention >of the addressee(s) only and may be confidential. If you are not the intended >addressee, any use, disclosure or copying of this email and any attachments is >unauthorised - please notify the sender by return and delete the message. Any >representations or commitments expressed in this email are subject to >contract. > >ntl Group Limited From axel.pawlik at ripe.net Mon Oct 27 14:20:09 2003 From: axel.pawlik at ripe.net (Axel Pawlik) Date: Mon, 27 Oct 2003 14:20:09 +0100 Subject: [address-policy-wg] IPv4 Exhaustion In-Reply-To: <5.1.0.14.2.20031027150802.00ad4d90@max.att.net.il> References: <6BD051C9C8D4D311A1F000508B5EDBBD02A22260@mast-hk0-se04.pri vate.ntl.com> Message-ID: <5.2.0.9.2.20031027141850.0268c570@localhost> At 27/10/2003 15:09 +0200, Hank Nussbacher wrote: >Geoff Huston gave an excellent plenary presentation at RIPE46: >http://www.ripe.net/ripe/meetings/ripe-46/plenary.html >but unfortunately the presentation is not available on the RIPE meeting site. Hank, all, our web people have just laid their hand upon it, it will go up now. cheers, Axel From axel.pawlik at ripe.net Mon Oct 27 14:24:19 2003 From: axel.pawlik at ripe.net (Axel Pawlik) Date: Mon, 27 Oct 2003 14:24:19 +0100 Subject: [address-policy-wg] IPv4 Exhaustion Message-ID: <5.2.0.9.2.20031027142323.03459180@localhost> At 27/10/2003 15:09 +0200, Hank Nussbacher wrote: >Geoff Huston gave an excellent plenary presentation at RIPE46: >http://www.ripe.net/ripe/meetings/ripe-46/plenary.html >but unfortunately the presentation is not available on the RIPE meeting site. A good article by Geoff has appeared in ARIN today, see http://www.arin.net/newsletter/2003_Third_Qtr.pdf regards, Axel From Michael.Dillon at radianz.com Mon Oct 27 14:34:40 2003 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Mon, 27 Oct 2003 13:34:40 +0000 Subject: [address-policy-wg] IPv4 Exhaustion Message-ID: >I am trying to get hold of accurate, up-top-date figures showing me how much >IPv4 space there is left, and how long that is predicted to last. >I cannot find any up-to-date presentations, charts or reports on RIPE, ARIN, >ICANN or IANA. >Perhaps I am looking in the wrong place....can someone help me please. Check the latest ARIN newsletter here http://www.arin.net/announcements/20031008.html available in PDF format. The article on exhaustion is by Geoff Huston who periodically posts article on the topic here http://www.potaroo.net/ispcolumn/ and here http://www.potaroo.net/papers.html Note the reference to RIPE 46 at that last URL. In general RIPE, ARIN and APNIC meetings are a good way to keep up to date on this and other addressing issues. In the ARIN region the trend of IP address consumption continues its slow downward slide and the policy trend continues towards making it easier for smaller entities to receive blocks of IP addresses direct from the RIR. In general, I think RIPE members on this list would find it useful to keep track of the ARIN meetings and their outcomes. There was a meeting last week in Chicago http://www.arin.net/ARIN-XII/index.html and the agenda page has links to most of the presentations. The minutes should be up on the site in a week or so. Policy outcomes take a while to be announced because of the need for Board of Trustees ratification. Note that I am *NOT* suggesting that RIPE policy should be synchronised in any way with ARIN policy. I believe that regions need to make policy that works in their own political, economic and social climates. However, it is useful to be aware of the context in other regions when making policy because sometimes good ideas pop up elsewhere first. --Michael Dillon located in London but getting addresses from ARIN From Mark.Hands at ntl.com Mon Oct 27 14:42:00 2003 From: Mark.Hands at ntl.com (Mark Hands) Date: Mon, 27 Oct 2003 13:42:00 -0000 Subject: [address-policy-wg] IPv4 Exhaustion Message-ID: <6BD051C9C8D4D311A1F000508B5EDBBD02A22264@mast-hk0-se04.private.ntl.com> Magic :-) Thanks everyone..... Mark Hands ntl: Hook Senior Data Planning Engineer t: 01256 752624 m: 07866 572314 e: mark.hands at ntl.com -----Original Message----- From: Michael.Dillon at radianz.com [mailto:Michael.Dillon at radianz.com] Sent: 27 October 2003 13:35 To: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] IPv4 Exhaustion >I am trying to get hold of accurate, up-top-date figures showing me how much >IPv4 space there is left, and how long that is predicted to last. >I cannot find any up-to-date presentations, charts or reports on RIPE, ARIN, >ICANN or IANA. >Perhaps I am looking in the wrong place....can someone help me please. Check the latest ARIN newsletter here http://www.arin.net/announcements/20031008.html available in PDF format. The article on exhaustion is by Geoff Huston who periodically posts article on the topic here http://www.potaroo.net/ispcolumn/ and here http://www.potaroo.net/papers.html Note the reference to RIPE 46 at that last URL. In general RIPE, ARIN and APNIC meetings are a good way to keep up to date on this and other addressing issues. In the ARIN region the trend of IP address consumption continues its slow downward slide and the policy trend continues towards making it easier for smaller entities to receive blocks of IP addresses direct from the RIR. In general, I think RIPE members on this list would find it useful to keep track of the ARIN meetings and their outcomes. There was a meeting last week in Chicago http://www.arin.net/ARIN-XII/index.html and the agenda page has links to most of the presentations. The minutes should be up on the site in a week or so. Policy outcomes take a while to be announced because of the need for Board of Trustees ratification. Note that I am *NOT* suggesting that RIPE policy should be synchronised in any way with ARIN policy. I believe that regions need to make policy that works in their own political, economic and social climates. However, it is useful to be aware of the context in other regions when making policy because sometimes good ideas pop up elsewhere first. --Michael Dillon located in London but getting addresses from ARIN The contents of this email and any attachments are sent for the personal attention of the addressee(s) only and may be confidential. If you are not the intended addressee, any use, disclosure or copying of this email and any attachments is unauthorised - please notify the sender by return and delete the message. Any representations or commitments expressed in this email are subject to contract. ntl Group Limited From Michael.Dillon at radianz.com Mon Oct 27 14:54:45 2003 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Mon, 27 Oct 2003 13:54:45 +0000 Subject: [address-policy-wg] Is the time for conservation over? Message-ID: One area of address policy that is fairly consistent world-wide is the view that IPv4 address space is scarce and that the policy must be conservative, i.e. the policy must make conservation of IPv4 addresses a high priority. I don't think that's true anymore. On the one hand, we have IPv6 deployed commercially in 3 of the 4 policy regions (Europe, AsiaPac, America) which indicates a continuing trend toward a future time where IPv6 service will be almost as easy to find as IPv4 service. On the other hand, the worst possible outcomes discussed when CIDR was first deployed are not going to happen. For instance there was a fear that the People's Republic of China might want 1/4 of the IPv4 space because they have 1/4 of the planet's population. This has not happened and is now quite unlikely to happen. Therefore, I believe that all the RIRs should jointly do some research to establish a prudent date at which IPv6 will be considered to have reached critical mass so that there will be a significant migration of users from IPv4 to IPv6. Once we set our sights on this date we should set aside a certain amount of buffer in the IPv4 space, and then design our policy to consume the rest of the IPv4 space, not to preserve it. At the same time, this policy shift should be presented as part of a global IPv6 migration strategy because that is what it is. In addition, I don't see any good reason to wait until LIRs come and ask for IPv6 space. It's not scarce and the vast majority of IPv4 LIRs will be deploying IPv6 sometime. So why don't we just give every single one of them an IPv6 /32 today. Instead of creating barriers to the adoption of dual v4/v6 networks as we are today, we should be facilitating the operation of dual v4/v6 networks. We need to create an environment in which the end user can choose whether to use v4 or v6 rather than constraining the end users with our v4-centric regulatory bureaucracy. --Michael Dillon From oppermann at pipeline.ch Mon Oct 27 15:27:17 2003 From: oppermann at pipeline.ch (Andre Oppermann) Date: Mon, 27 Oct 2003 15:27:17 +0100 Subject: [address-policy-wg] Is the time for conservation over? References: Message-ID: <3F9D2B45.DE4CDBA2@pipeline.ch> Michael.Dillon at radianz.com wrote: > > One area of address policy that is fairly consistent world-wide is the > view that IPv4 address space is scarce and that the policy must > be conservative, i.e. the policy must make conservation of IPv4 > addresses a high priority. > > I don't think that's true anymore. -snip- > Therefore, I believe that all the RIRs should jointly do some research > to establish a prudent date at which IPv6 will be considered to have > reached critical mass so that there will be a significant migration of > users from IPv4 to IPv6. Once we set our sights on this date we should > set aside a certain amount of buffer in the IPv4 space, and then design > our policy to consume the rest of the IPv4 space, not to preserve it. > At the same time, this policy shift should be presented as part of > a global IPv6 migration strategy because that is what it is. It sounds a little bit contradictory to give away IPv4 addresses when you want people to migrate to IPv6, doesn't it? One of the supposed advantage of IPv6 is the as-much-as-you-can-eat approach to addresses (at least on your local end). So I think your proposal is seriously flawed and contradicts your desired goal. > In addition, I don't see any good reason to wait until LIRs come and ask > for IPv6 space. It's not scarce and the vast majority of IPv4 LIRs will > be deploying IPv6 sometime. So why don't we just give every single > one of them an IPv6 /32 today. Instead of creating barriers to the > adoption The problem with IPv6 is that it doesn't fix any problems. When IPv6 was engineered it was done with (from today's perspective) wrong assumptions about the goals to achieve. Think about multihoming for IPv6 which is currently not possible (except for ISPs). And much more stuff on the operational side. > of dual v4/v6 networks as we are today, we should be facilitating the > operation of dual v4/v6 networks. We need to create an environment > in which the end user can choose whether to use v4 or v6 rather than > constraining the end users with our v4-centric regulatory bureaucracy. The end-user has no choice because the end-user is not able to make any choice since he lacks sufficient knowlege to trade off the (dis-)advantages of his choice. The choice is usually made by the ISP and the applications the user wants to use. For them it's just the Internet and not an IPv4 or IPv6 based transport network. -- Andre From Michael.Dillon at radianz.com Mon Oct 27 16:31:21 2003 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Mon, 27 Oct 2003 15:31:21 +0000 Subject: [address-policy-wg] Is the time for conservation over? Message-ID: >It sounds a little bit contradictory to give away IPv4 addresses when >you want people to migrate to IPv6, doesn't it? One of the supposed >advantage of IPv6 is the as-much-as-you-can-eat approach to addresses >So I think your proposal is seriously flawed and contradicts your >desired goal. You forgot this next bit. Think it through... >> In addition, I don't see any good reason to wait until LIRs come and ask >> for IPv6 space. It's not scarce and the vast majority of IPv4 LIRs will >> be deploying IPv6 sometime. So why don't we just give every single >> one of them an IPv6 /32 today. Instead of creating barriers to the >> adoption We give out free IPv6 addresses to everyone using IPv4. And we make it easier for new organizations to receive blocks of globally unique registered IPv4 addresses, i.e. not hijacked addresses and not RFC 1918 addresses. In any case, this is just lowering a barrier. It doesn't solve every IPv6 issue but it does remove an unecessary barrier. --Michael Dillon From slz at baycix.de Mon Oct 27 16:36:01 2003 From: slz at baycix.de (Sascha Lenz) Date: Mon, 27 Oct 2003 16:36:01 +0100 Subject: [address-policy-wg] Is the time for conservation over? In-Reply-To: References: Message-ID: <3F9D3B61.6070003@baycix.de> Hay, Michael.Dillon at radianz.com wrote: > One area of address policy that is fairly consistent world-wide is the > view that IPv4 address space is scarce and that the policy must > be conservative, i.e. the policy must make conservation of IPv4 > addresses a high priority. > > I don't think that's true anymore. Right, i share this point of view for quite a while now, and also recently made some side-notes on this in some mails to the address-policy-wg list, too. My main motivation to change my opinion on this from "conserve!" to "waste!" was, that there is IPv6 now, and obviously noone found _any_ killer-application for IPv6 yet. So not many ISP managers see any reason to invest any time or money in IPv6, and almost no End-User does even know about IPv6. The only real "killer reason" for IPv6 is, that it's just needed if there is no more IPv4 space left. So, it's a bit populistic, but "waste IPv4 space, now!" is in general what should be done :-) Secondly, I also always thought that this whole "there is no more IPv4 left soon!" thing couldn't be true based on the very slow development nowerdays and the huge reserves. But i never mentioned it since i didn't really do any research about that and had no facts. If i look at the recent documents and talks about this (like the one during RIPE meeting mentioned earlier http://www.potaroo.net/ispcolumn/2003-07-v4-address-lifetime/ale.html for example), i'm quite sure now that this is a second reason why we should rethink the conservation policy. But some more annotations on your opinion: > On the one hand, we have IPv6 deployed commercially in 3 of the > 4 policy regions (Europe, AsiaPac, America) which indicates a continuing > trend toward a future time where IPv6 service will be almost as > easy to find as IPv4 service. On the other hand, the worst possible > outcomes discussed when CIDR was first deployed are not going > to happen. For instance there was a fear that the People's Republic > of China might want 1/4 of the IPv4 space because they have 1/4 > of the planet's population. This has not happened and is now quite > unlikely to happen. There's the main problem, I'm in .de - quite many LIRs with IPv6 Allocations here... but, can i get native IPv6 conenctivity anywhere? As End-User almost not at all, as ISP for some Uplink? Same. (Yes, i know there are some ISPs, but it's far from "as easy to find as IPv4 Uplinks" yet). So i don't really see this coming anytime soon. As long as there is IPv4 space left, i really doubt that descent IPv6 deployment will happen. > Therefore, I believe that all the RIRs should jointly do some research > to establish a prudent date at which IPv6 will be considered to have > reached critical mass so that there will be a significant migration of > users from IPv4 to IPv6. Once we set our sights on this date we should > set aside a certain amount of buffer in the IPv4 space, and then design > our policy to consume the rest of the IPv4 space, not to preserve it. > At the same time, this policy shift should be presented as part of > a global IPv6 migration strategy because that is what it is. I don't really get what you want this for. Don't make things more complicated - make them easier! I.e. there is some special verificaton policy on static dialin IPs ect. in the RIPE Assigment documents. Or the "no reserverations allowed" paragraph is also a bit outdated since there are some new things like Sub-Allocations introduced now. ==> I only know the RIPE Policys in detail, but when talking about re-thinking the convervation policy, i mainly talk about re-thinking all the special-policies, just strike them out probably. > In addition, I don't see any good reason to wait until LIRs come and ask > for IPv6 space. It's not scarce and the vast majority of IPv4 LIRs will > be deploying IPv6 sometime. So why don't we just give every single > one of them an IPv6 /32 today. Instead of creating barriers to the > adoption > of dual v4/v6 networks as we are today, we should be facilitating the > operation of dual v4/v6 networks. We need to create an environment > in which the end user can choose whether to use v4 or v6 rather than > constraining the end users with our v4-centric regulatory bureaucracy. Whereas i strongly support a change of the IPv6 Allocation Policy to "give it to any LIR who wants it; strike out any requirements" for the reasons you gave here, the problem still remains - most IPv6 projects are more or less "private fun" of some network operators, very few ISPs do support it officially or have any plans for supporting IPv6 natively in their whole network any time soon (yes, there are positive exceptions of course). And there should be a formal request of course, no need to waste any IPv6 block if some LIR doesn't really want to have one for whatever reason. But just kick out the requirements we have as "slow start" mechanism up to now. I also had some nice discussions with some RIPE hostmasters and on the mailinglists about why the hell they require a network diagram in the IPv6 (Allocation) request form... probably someone remembers my rants (btw, i won) :-) -- ======================================================================== = Sascha Lenz SLZ-RIPE slz at baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ======================================================================== From slz at baycix.de Mon Oct 27 16:48:38 2003 From: slz at baycix.de (Sascha Lenz) Date: Mon, 27 Oct 2003 16:48:38 +0100 Subject: [address-policy-wg] Is the time for conservation over? In-Reply-To: <3F9D2B45.DE4CDBA2@pipeline.ch> References: <3F9D2B45.DE4CDBA2@pipeline.ch> Message-ID: <3F9D3E56.5020909@baycix.de> Haym Andre Oppermann wrote: > Michael.Dillon at radianz.com wrote: [...] > It sounds a little bit contradictory to give away IPv4 addresses when > you want people to migrate to IPv6, doesn't it? One of the supposed > advantage of IPv6 is the as-much-as-you-can-eat approach to addresses > (at least on your local end). > > So I think your proposal is seriously flawed and contradicts your > desired goal. Don't look at it that way, see my first reply on the original mail from Michael. I don't think the community would support any artificial shortage of (IPv4-)Address space as soon as they realize that there is "enough left for some decades". The only way I see is to trick them by letting them waste IPv4 space until there really is none left :-) I'm sorry if that sounds like a strange suggestion, but anyone got a better idea? > >>In addition, I don't see any good reason to wait until LIRs come and ask >>for IPv6 space. It's not scarce and the vast majority of IPv4 LIRs will >>be deploying IPv6 sometime. So why don't we just give every single >>one of them an IPv6 /32 today. Instead of creating barriers to the >>adoption > > > The problem with IPv6 is that it doesn't fix any problems. When IPv6 > was engineered it was done with (from today's perspective) wrong > assumptions about the goals to achieve. Think about multihoming for > IPv6 which is currently not possible (except for ISPs). And much more > stuff on the operational side. Well the multi-homing problem is rather a policy issue again by some of the network operators which don't want any /48's or some even nothing but /32's being allowed in the global routing table because they fear about the RAM usage and other scaling problems of of big routing tables. It actually has nothing to do with IPv6 itself. Those people just need to be kicked back into reality :-) But the problem with IPv6 just is, that almost noone really needs it. > >>of dual v4/v6 networks as we are today, we should be facilitating the >>operation of dual v4/v6 networks. We need to create an environment >>in which the end user can choose whether to use v4 or v6 rather than >>constraining the end users with our v4-centric regulatory bureaucracy. > > > The end-user has no choice because the end-user is not able to make > any choice since he lacks sufficient knowlege to trade off the > (dis-)advantages of his choice. The choice is usually made by the > ISP and the applications the user wants to use. For them it's just > the Internet and not an IPv4 or IPv6 based transport network. > ACK. But how to make ISPs will switch to IPv6 if there's enough IPv4 space left? As i said, i don't think it's possible to get an agreement within the community that no IPv4 space will be issued anymore from some date on or so. But i might be wrong. I just got very pessimistic about IPv6 throughout the last years since it's like talking against windmills (managers) if you don't have any busisinees-critical reasons for a change like towards IPv6. -- ======================================================================== = Sascha Lenz SLZ-RIPE slz at baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ======================================================================== From michel at arneill-py.sacramento.ca.us Mon Oct 27 18:13:29 2003 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Mon, 27 Oct 2003 09:13:29 -0800 Subject: [address-policy-wg] Is the time for conservation over? Message-ID: > Andre Oppermann wrote: > The problem with IPv6 is that it doesn't fix any problems. When > IPv6 was engineered it was done with (from today's perspective) > wrong assumptions about the goals to achieve. Think about > multihoming for IPv6 which is currently not possible (except > for ISPs). And much more stuff on the operational side. Much agree with this. Michel. From Bart.Jan.Menkveld at pqr.nl Tue Oct 28 12:34:50 2003 From: Bart.Jan.Menkveld at pqr.nl (Bart.Jan.Menkveld at pqr.nl) Date: Tue, 28 Oct 2003 12:34:50 +0100 Subject: [address-policy-wg] re: Is the time for conservation over? Message-ID: An HTML attachment was scrubbed... URL: From bicknell at ufp.org Mon Oct 27 15:15:58 2003 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 27 Oct 2003 09:15:58 -0500 Subject: [address-policy-wg] Re: [ppml] Is the time for conservation over? In-Reply-To: References: Message-ID: <20031027141558.GB27711@ussenterprise.ufp.org> In a message written on Mon, Oct 27, 2003 at 01:54:45PM +0000, Michael.Dillon at radianz.com wrote: > Therefore, I believe that all the RIRs should jointly do some research > to establish a prudent date at which IPv6 will be considered to have > reached critical mass so that there will be a significant migration of > users from IPv4 to IPv6. Once we set our sights on this date we should I am going to strongly disagree on this point at this time. We don't know that there will /ever/ be a strong migration of users to IPv6. IPv6 may yet flop completely, be replaced by IPv8 or something before it ever reaches full deployment, or even always live side by side with IPv4. Even if we assume everything migrates to IPv6, I see no reason why we should change IPv4 policy at all. First, if people are migrating IPv4 policy becomes irrevelant anyway. Second, if the IPv4 policy is hinderng things we should fix it in IPv6 policy to more quickly encourage cut over. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From david.conrad at nominum.com Mon Oct 27 16:58:10 2003 From: david.conrad at nominum.com (David Conrad) Date: Mon, 27 Oct 2003 07:58:10 -0800 Subject: [ppml] Re: [address-policy-wg] Is the time for conservation over? In-Reply-To: Message-ID: Hi, >>> It's not scarce and the vast majority of IPv4 LIRs will >>> be deploying IPv6 sometime. So why don't we just give every single >>> one of them an IPv6 /32 today. Instead of creating barriers to the >>> adoption The obvious implication of this is that it pretty much guarantees the creation of a new and potentially much bigger swamp. I'll leave it to others to determine if that is a serious concern. Rgds, -drc From Michael.Dillon at radianz.com Tue Oct 28 15:18:32 2003 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Tue, 28 Oct 2003 14:18:32 +0000 Subject: [address-policy-wg] re: Is the time for conservation over? Message-ID: >>In addition, I don't see any good reason to wait until LIRs come and ask >>for IPv6 space. It's not scarce and the vast majority of IPv4 LIRs will >>be deploying IPv6 sometime. So why don't we just give every single >>one of them an IPv6 /32 today. Instead of creating barriers to the >>adoption >This was the opinion in the first days op IPv4, please don't make the same mistakes again with IPv6.. We can't look into the future, but we can look at the past!! I don't want to make the same mistakes as IPv4. That is why I want to give an IPv6 /32 to every IPv4 LIR. With IPv4 we made a mistake by trying to be too careful with class C address blocks and again with small CIDR blocks. Instead of giving out large blocks of class C space, we created the swamp. When CIDR came along we continued to give out blocks for one year or less of growth and we bloated the global routing table. With IPv6 we do not have to worry about waste. Every LIR gets a /32 from a reserved /29. When addresses are issued to customers, everybody gets a /48 except in special circumstances where a /64 or a /128 would be assigned. I don't think there will be very many special situation that justify a /64 assignment today. This means that we have a very simple straightforward system that allows LIRs to grow 8 times before we even begin to create anything that is similar to past history. The key to avoiding the mistakes of history is to forget about conserving address space. It is not a scarce resource; we have lots of it. --Michael Dillon From webmaster at ripe.net Tue Oct 28 17:02:33 2003 From: webmaster at ripe.net (RIPE NCC Document Announcement Service) Date: Tue, 28 Oct 2003 17:02:33 +0100 Subject: [address-policy-wg] New Document available: RIPE-288 Message-ID: <200310281602.h9SG2XHl021126@birch.ripe.net> [Apologies for duplicate mails] New RIPE Document Announcement -------------------------------------- A new document is available from the RIPE document store. Ref: ripe-288 Title: IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region Author: Mirjam Kuehne, Paul Rendek, Sabrina Wilmot, Leo Vegoda Date: 14 June 2002 Format: PDF=90203 TXT=34659 Obsoletes: ripe-104, ripe-105, ripe-136, ripe-140, ripe-159, ripe-185, ripe-234 Obsoleted by: Updates: Updated by: Short content description ------------------------- The RIPE NCC is pleased to announce the publication of the updated RIPE IPv4 policy document, IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region (ripe-288). The revised document includes the following major updates: - Recent policy changes have been incorporated, including the policy allowing assignments for Internet experiments and the sub-allocation policy. - The explanation of how to use the database has been removed as a separate "RIPE Database User Manual: Getting Started" (ripe-253) was published in September 2002. - The document now incorporates the text from "Provider Independent vs Provider Aggregatable Address Space" (ripe-127). - The document now specifies database registration requirements. Following comments from the community, the wording of the document has also been improved to clarify the policy. Accessing the RIPE document store --------------------------------- You can access the RIPE documents in HTML format via our website at the following URL:. http://www.ripe.net/docs/ipv4-policies.html The RIPE Document Store is also available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs. The URLs for the new documents on the FTP-server are: ftp://ftp.ripe.net/ripe/docs/ripe-288.pdf PDF version ftp://ftp.ripe.net/ripe/docs/ripe-288.txt plain text version From webmaster at ripe.net Tue Oct 28 17:13:26 2003 From: webmaster at ripe.net (RIPE NCC WebMaster) Date: Tue, 28 Oct 2003 17:13:26 +0100 Subject: [address-policy-wg] RIPE-288, Publishing date correction Message-ID: <200310281613.h9SGDQHl024778@birch.ripe.net> Dear colleagues, The correct publishing date for the new "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" (ripe-288) is 28 October 2003, not 14 June 2002 as previously stated. Apologies for the inconvenience, Jeroen Bet RIPE NCC WEBMASTER ================== From jwkckid1 at ix.netcom.com Tue Oct 28 21:50:10 2003 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Tue, 28 Oct 2003 12:50:10 -0800 Subject: [address-policy-wg] Re: [ppml] Is the time for conservation over? References: <20031027141558.GB27711@ussenterprise.ufp.org> Message-ID: <3F9ED682.C58BEE5A@ix.netcom.com> Leo and all, I also am in agreement with Leo on this point as well. IPv8 is already in significant deployment asia and elsewhere and is in some folks opinion, though I am sure not Michael's, a superior IP Protocol to IPv6, which has known Privacy problems. Leo Bicknell wrote: > In a message written on Mon, Oct 27, 2003 at 01:54:45PM +0000, Michael.Dillon at radianz.com wrote: > > Therefore, I believe that all the RIRs should jointly do some research > > to establish a prudent date at which IPv6 will be considered to have > > reached critical mass so that there will be a significant migration of > > users from IPv4 to IPv6. Once we set our sights on this date we should > > I am going to strongly disagree on this point at this time. We > don't know that there will /ever/ be a strong migration of users > to IPv6. IPv6 may yet flop completely, be replaced by IPv8 or > something before it ever reaches full deployment, or even always > live side by side with IPv4. > > Even if we assume everything migrates to IPv6, I see no reason why > we should change IPv4 policy at all. First, if people are migrating > IPv4 policy becomes irrevelant anyway. Second, if the IPv4 policy > is hinderng things we should fix it in IPv6 policy to more quickly > encourage cut over. > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org > > ------------------------------------------------------------------------ > > Part 1.2 Type: application/pgp-signature Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard =============================================================== CEO/DIR. Internet Network Eng. SR. Eng. Network data security Information Network Eng. Group. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Contact Number: 214-244-4827 or 214-244-3801 From jwkckid1 at ix.netcom.com Tue Oct 28 21:51:49 2003 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Tue, 28 Oct 2003 12:51:49 -0800 Subject: [ppml] Re: [address-policy-wg] Is the time for conservation over? References: Message-ID: <3F9ED6E5.12F0308C@ix.netcom.com> David and all, David Conrad wrote: > Hi, > > >>> It's not scarce and the vast majority of IPv4 LIRs will > >>> be deploying IPv6 sometime. So why don't we just give every single > >>> one of them an IPv6 /32 today. Instead of creating barriers to the > >>> adoption > > The obvious implication of this is that it pretty much guarantees the > creation of a new and potentially much bigger swamp. Hi David! I agree here. > > > I'll leave it to others to determine if that is a serious concern. > > Rgds, > -drc Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard =============================================================== CEO/DIR. Internet Network Eng. SR. Eng. Network data security Information Network Eng. Group. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Contact Number: 214-244-4827 or 214-244-3801 From bortzmeyer at gitoyen.net Wed Oct 29 10:06:54 2003 From: bortzmeyer at gitoyen.net (Stephane Bortzmeyer) Date: Wed, 29 Oct 2003 10:06:54 +0100 Subject: [address-policy-wg] Re: Is the time for conservation over? In-Reply-To: <3F9ED682.C58BEE5A@ix.netcom.com> References: <20031027141558.GB27711@ussenterprise.ufp.org> <3F9ED682.C58BEE5A@ix.netcom.com> Message-ID: <20031029090654.GA18093@nic.fr> On Tue, Oct 28, 2003 at 12:50:10PM -0800, Jeff Williams wrote a message of 49 lines which said: > IPv8 is already in significant deployment asia and elsewhere and is > in some folks opinion, though I am sure not Michael's, a superior IP > Protocol to IPv6, For those who do not (yet) know him, be assured you can safely ignore all messages coming from Jeff Williams, known troll in the Internet governance issues. (And, as we know, IPv8 does not exist.) From bicknell at ufp.org Tue Oct 28 20:04:52 2003 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 28 Oct 2003 14:04:52 -0500 Subject: [address-policy-wg] Re: [ppml] Is the time for conservation over? In-Reply-To: <3F9ED682.C58BEE5A@ix.netcom.com> References: <20031027141558.GB27711@ussenterprise.ufp.org> <3F9ED682.C58BEE5A@ix.netcom.com> Message-ID: <20031028190452.GA4009@ussenterprise.ufp.org> In a message written on Tue, Oct 28, 2003 at 12:50:10PM -0800, Jeff Williams wrote: > I also am in agreement with Leo on this point as well. IPv8 is already > in significant deployment asia and elsewhere and is in some folks > opinion, though I am sure not Michael's, a superior IP Protocol to > IPv6, which has known Privacy problems. This was already brought up on PPML, but since another list is copied here I'll say it again. I had _NO_ idea there was an IPv8 proposal out there. I know nothing about it, don't support it, and don't care. s/IPv8/IPvFuture/ in my message please, that was my only intention. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From contact at ripe.net Wed Oct 29 15:37:45 2003 From: contact at ripe.net (Membership Liason Officer) Date: Wed, 29 Oct 2003 15:37:45 +0100 Subject: [address-policy-wg] RIPE NCC Dubai Meeting, Dec. 2003 - Updated Agenda Message-ID: <20031029153745.488620e0.contact@ripe.net> [Apologies for duplicate mails] Dear Colleagues, The RIPE NCC Regional Meeting, Middle East, will be held 7 - 9 December 2003 at the Metropolitan Palace Hotel, Dubai, U.A.E. The meeting will focus on Internet Resource management issues. Attendance to the RIPE NCC Regional Meeting is open and free of charge. However, attendees are responsible for covering their own travel and accommodation costs. UPDATED AGENDA The agenda has been updated with more information about speakers and presentations. The preliminary list of speakers includes: - Rob Blokzijl (RIPE Chair) - Tim Mertens (CENTR) - Keith Mitchell (XchangePoint) - Axel Pawlik (RIPE NCC) - Phillip Smith (Cisco Systems) The Director General of APNIC, Paul Wilson, will also give a presentation on IPv4 address lifetime expectancy. For the full agenda, please see: http://www.ripe.net/ripencc/regional-meetings/dubai-2003/plan.html The RIPE NCC has reserved several presentation opportunities for those with local knowledge of Internet management and operational issues affecting the Middle East. If your organisation wishes to provide a presentation or suggest a relevant topic, please send your proposal by e-mail to: . ATTENDEE LIST The attendee list is regularly updated with new registrations and is now available online at: http://www.ripe.net/ripencc/regional-meetings/dubai-2003/attendees.html HOTEL RESERVATIONS: The RIPE NCC has arranged for a block of rooms to be held for meeting attendees at the Metropolitan Palace Hotel and the Metropolitan Hotel Sheikh Zayed Road, Dubai. There are a limited number of rooms available, so we strongly suggest you book early to avoid disappointment. For more information about these hotels, and to reserve a room, please see: http://www.ripe.net/ripencc/regional-meetings/dubai-2003/hotel-information.html REGISTRATION To register for the RIPE NCC Regional Meeting, Middle East, please see: http://www.ripe.net/cgi-bin/dubai-reg Any further questions about the RIPE NCC Regional Meeting, Middle East, can be sent directly to: . Regards, Sabrina Wilmot Membership Liaison Officer RIPE NCC From ncc at ripe.net Wed Oct 29 17:34:54 2003 From: ncc at ripe.net (Paul Rendek) Date: Wed, 29 Oct 2003 17:34:54 +0100 Subject: [address-policy-wg] IPv4 Address Space Message-ID: <5.2.1.1.2.20031029172736.04590e90@mailhost.ripe.net> [Apologies for duplicate mailings] Dear Colleagues, There have been press articles posted over the past year that make statements about the remaining pool of IPv4 address space. A recent article states there is a shortage and that Internet Protocol Numbers will run out some time in the year 2005. The Regional Internet Registries (RIRs) do not themselves make predictions about when the remaining IPv4 address space will be depleted. They do, however, report on the rates of RIR allocation of IPv4 address space and on the state of the remaining pool of IPv4 address space. The information provided in these RIR reports makes it apparent that many of the recent claims regarding IPv4 address space shortage are speculative and are not based on authoritative, publicly available statistics. IPv4 Address Space: Current Statistics ============================ The global pool of IPv4 addresses is administered by the Internet Assigned Numbers Authority (IANA), which allocates address blocks to Regional Internet Registries (RIRs) as they are required. The IPv4 allocation unit in this case is the "/8 block", equivalent to approximately 16 million addresses. It should be noted that as of 30 June 2003 the global pool of IPv4 address space contained 91 of these blocks for this purpose. The RIRs report on statistics regarding IPv4 allocation on their respective web sites and present a "Joint Statistics" report at each of the RIR meetings and at other Internet industry meetings several times yearly. This information is publicly available and provides the most up-to-date statistics on rates of IPv4 allocation. The most recent presentation on this subject can be found at: http://www.ripe.net/rs/statistics/resource-status-200310.pdf This report states that the RIRs have collectively allocated 19.59 /8 equivalents in the four and a half years between January 1999 and June 2003. It also identifies that there are 91 /8 equivalents held by the IANA in reserve for future allocation by the RIRs. Based on today's total global allocation rate of approximately 4.25 blocks per year in 2002, or 5.5 blocks in 2001, and the remaining pool of 91 blocks held by IANA, it is unrealistic to assume that there is an imminent shortage in the IPv4 address space. Even allowing for a dramatic increase in address consumption rates, it is highly probable that IPv4 address space will last well beyond the two years predicted by some. IPv4 Address Space: Allocated Globally According to Regional Needs ================================================== The RIRs are not-for-profit membership organisations dedicated to providing neutral and fair Internet resource distribution to their members, while ensuring the conservation and aggregation of IPv4 address space. The IANA policies for allocation of IPv4 address blocks to the RIRs are applied fairly and are based purely on the documented need for address space. When IPv4 address space finally "runs out" this will occur at the global level, leaving each region with a relatively small pool of addresses remaining to be allocated. It has been suggested that Asia will experience an IPv4 address shortage before other regions. This is simply not true. This is because addresses are distributed in a co-ordinated fashion from a single global pool, and there is no system whereby that pool is exclusively divided among, or pre-allocated to, different countries or regions. Through the current system of address administration, IP addresses are allocated according to immediate need wherever that need is demonstrated and it is simply not possible for isolated "shortages" to exist. As has been done in the past, the RIRs will continue to report regularly on the registration and allocation rates of Internet Protocol Numbers, and will work closely with the IANA to ensure the efficient management of the remaining IPv4 address space. RIR Statistics: ========== APNIC http://www.apnic.net/info/reports/index.html ARIN http://www.arin.net/statistics/index.html LACNIC http://www.lacnic.net/en/est.html RIPE NCC http://www.ripe.net/ripencc/mem-services/registration/statistics/ Raw Data/Historical RIR Allocations: ========================== http://www.aso.icann.org/stats/index.html http://www.iana.org/assignments/ipv4-address-space The Internet Number Resource Status Report, prepared jointly by the four RIRs, provides up-to-date statistics on rates of IPv4 allocation. This presentation is available at: http://www.ripe.net/rs/statistics/resource-status-200310.pdf Cheers, Paul Rendek Head of Member Services and Communications RIPE NCC From michel at arneill-py.sacramento.ca.us Wed Oct 29 19:28:25 2003 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Wed, 29 Oct 2003 10:28:25 -0800 Subject: [address-policy-wg] Re: Is the time for conservation over? Message-ID: > Stephane Bortzmeyer wrote: > For those who do not (yet) know him, be assured you can safely > ignore all messages coming from Jeff Williams, known troll in > the Internet governance issues. Indeed. I have heard some rumors that Jeff Williams and Jim Fleming are the same person. Or maybe there is a brotherhood of trolls. > (And, as we know, IPv8 does not exist.) I actually read it a while ago. I will not go as far as recommending reading it, but I found it both hilarious and a somehow extensive list of exactly what not to do :-) Michel. From michel at arneill-py.sacramento.ca.us Wed Oct 29 19:28:25 2003 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Wed, 29 Oct 2003 10:28:25 -0800 Subject: [ppml] RE: [address-policy-wg] Re: Is the time for conservation over? Message-ID: > Stephane Bortzmeyer wrote: > For those who do not (yet) know him, be assured you can safely > ignore all messages coming from Jeff Williams, known troll in > the Internet governance issues. Indeed. I have heard some rumors that Jeff Williams and Jim Fleming are the same person. Or maybe there is a brotherhood of trolls. > (And, as we know, IPv8 does not exist.) I actually read it a while ago. I will not go as far as recommending reading it, but I found it both hilarious and a somehow extensive list of exactly what not to do :-) Michel. From jwkckid1 at ix.netcom.com Thu Oct 30 04:00:13 2003 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Wed, 29 Oct 2003 19:00:13 -0800 Subject: [address-policy-wg] Re: Is the time for conservation over? References: <20031027141558.GB27711@ussenterprise.ufp.org> <3F9ED682.C58BEE5A@ix.netcom.com> <20031029090654.GA18093@nic.fr> Message-ID: <3FA07EBC.A09DB97E@ix.netcom.com> Stephane and all, See: http://www.ipv8.info/ I am sorry to see that the moderator allowed this retort of dubious quality to be allowed to post to this forum. I hope that such name calling antics would of course be below the standard of the participants of this forum and such perpetrators be requested to discontinue such unproductive discourse... Stephane Bortzmeyer wrote: > On Tue, Oct 28, 2003 at 12:50:10PM -0800, > Jeff Williams wrote > a message of 49 lines which said: > > > IPv8 is already in significant deployment asia and elsewhere and is > > in some folks opinion, though I am sure not Michael's, a superior IP > > Protocol to IPv6, > > For those who do not (yet) know him, be assured you can safely ignore > all messages coming from Jeff Williams, known troll in the Internet > governance issues. > > (And, as we know, IPv8 does not exist.) Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard =============================================================== CEO/DIR. Internet Network Eng. SR. Eng. Network data security Information Network Eng. Group. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Contact Number: 214-244-4827 or 214-244-3801 From hank at att.net.il Thu Oct 30 06:28:53 2003 From: hank at att.net.il (Hank Nussbacher) Date: Thu, 30 Oct 2003 07:28:53 +0200 (IST) Subject: [address-policy-wg] Re: Is the time for conservation over? In-Reply-To: <3FA07EBC.A09DB97E@ix.netcom.com> Message-ID: On Wed, 29 Oct 2003, Jeff Williams wrote: Stephane, Allow me to join you in the name calling. RIPE moderator, Jeff is a noted "net-kook" and should be filtered from all RIPE mailing lists. -Hank > Stephane and all, > > See: http://www.ipv8.info/ > > I am sorry to see that the moderator allowed this retort of dubious > quality to be allowed to post to this forum.I hope that such name > calling antics would of course be below the standard of the > participants of this forum and such perpetrators be requested > to discontinue such unproductive discourse... > > Stephane Bortzmeyer wrote: > > > On Tue, Oct 28, 2003 at 12:50:10PM -0800, > >Jeff Williams wrote > >a message of 49 lines which said: > > > > > IPv8 is already in significant deployment asia and elsewhere and is > > > in some folks opinion, though I am sure not Michael's, a superior IP > > > Protocol to IPv6, > > > > For those who do not (yet) know him, be assured you can safely ignore > > all messages coming from Jeff Williams, known troll in the Internet > > governance issues. > > > > (And, as we know, IPv8 does not exist.) > > Regards, > -- > Jeffrey A. Williams > Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) > "Be precise in the use of words and expect precision from others" - > Pierre Abelard > =============================================================== > CEO/DIR. Internet Network Eng. SR. Eng. Network data security > Information Network Eng. Group. INEG. INC. > E-Mail jwkckid1 at ix.netcom.com > Contact Number: 214-244-4827 or 214-244-3801 > > Hank Nussbacher From bortzmeyer at gitoyen.net Thu Oct 30 06:58:21 2003 From: bortzmeyer at gitoyen.net (Stephane Bortzmeyer) Date: Thu, 30 Oct 2003 06:58:21 +0100 Subject: [address-policy-wg] Re: Is the time for conservation over? In-Reply-To: (Hank Nussbacher 's message of Thu, 30 Oct 2003 07:28:53 +0200) Message-ID: <200310300558.h9U5wLIf012188@ludwigV.sources.org> On Thursday 30 October 2003, at 7 h 28, Hank Nussbacher wrote: > Jeff is a noted "net-kook" and should be filtered from all RIPE mailing > lists. Unless we want some unproductive discourse from time-to-time. After all, work is hard and a good laugh is always a welcomed distraction. From peter.galbavy at knowtion.net Thu Oct 30 11:38:42 2003 From: peter.galbavy at knowtion.net (Peter Galbavy) Date: Thu, 30 Oct 2003 10:38:42 -0000 Subject: [address-policy-wg] Re: Is the time for conservation over? References: <200310300558.h9U5wLIf012188@ludwigV.sources.org> Message-ID: <005e01c39ed1$ffb7e0a0$28e0a8c0@peteryw45760tp> Stephane Bortzmeyer wrote: > Unless we want some unproductive discourse from time-to-time. After > all, work is hard and a good laugh is always a welcomed distraction. No, that's *my* job :-) Peter From ncc at ripe.net Wed Oct 29 17:34:54 2003 From: ncc at ripe.net (Paul Rendek) Date: Wed, 29 Oct 2003 17:34:54 +0100 Subject: [address-policy-wg] [local-ir@ripe.net]IPv4 Address Space Message-ID: <5.2.1.1.2.20031029172736.04590e90@mailhost.ripe.net> [Apologies for duplicate mailings] Dear Colleagues, There have been press articles posted over the past year that make statements about the remaining pool of IPv4 address space. A recent article states there is a shortage and that Internet Protocol Numbers will run out some time in the year 2005. The Regional Internet Registries (RIRs) do not themselves make predictions about when the remaining IPv4 address space will be depleted. They do, however, report on the rates of RIR allocation of IPv4 address space and on the state of the remaining pool of IPv4 address space. The information provided in these RIR reports makes it apparent that many of the recent claims regarding IPv4 address space shortage are speculative and are not based on authoritative, publicly available statistics. IPv4 Address Space: Current Statistics ============================ The global pool of IPv4 addresses is administered by the Internet Assigned Numbers Authority (IANA), which allocates address blocks to Regional Internet Registries (RIRs) as they are required. The IPv4 allocation unit in this case is the "/8 block", equivalent to approximately 16 million addresses. It should be noted that as of 30 June 2003 the global pool of IPv4 address space contained 91 of these blocks for this purpose. The RIRs report on statistics regarding IPv4 allocation on their respective web sites and present a "Joint Statistics" report at each of the RIR meetings and at other Internet industry meetings several times yearly. This information is publicly available and provides the most up-to-date statistics on rates of IPv4 allocation. The most recent presentation on this subject can be found at: http://www.ripe.net/rs/statistics/resource-status-200310.pdf This report states that the RIRs have collectively allocated 19.59 /8 equivalents in the four and a half years between January 1999 and June 2003. It also identifies that there are 91 /8 equivalents held by the IANA in reserve for future allocation by the RIRs. Based on today's total global allocation rate of approximately 4.25 blocks per year in 2002, or 5.5 blocks in 2001, and the remaining pool of 91 blocks held by IANA, it is unrealistic to assume that there is an imminent shortage in the IPv4 address space. Even allowing for a dramatic increase in address consumption rates, it is highly probable that IPv4 address space will last well beyond the two years predicted by some. IPv4 Address Space: Allocated Globally According to Regional Needs ================================================== The RIRs are not-for-profit membership organisations dedicated to providing neutral and fair Internet resource distribution to their members, while ensuring the conservation and aggregation of IPv4 address space. The IANA policies for allocation of IPv4 address blocks to the RIRs are applied fairly and are based purely on the documented need for address space. When IPv4 address space finally "runs out" this will occur at the global level, leaving each region with a relatively small pool of addresses remaining to be allocated. It has been suggested that Asia will experience an IPv4 address shortage before other regions. This is simply not true. This is because addresses are distributed in a co-ordinated fashion from a single global pool, and there is no system whereby that pool is exclusively divided among, or pre-allocated to, different countries or regions. Through the current system of address administration, IP addresses are allocated according to immediate need wherever that need is demonstrated and it is simply not possible for isolated "shortages" to exist. As has been done in the past, the RIRs will continue to report regularly on the registration and allocation rates of Internet Protocol Numbers, and will work closely with the IANA to ensure the efficient management of the remaining IPv4 address space. RIR Statistics: ========== APNIC http://www.apnic.net/info/reports/index.html ARIN http://www.arin.net/statistics/index.html LACNIC http://www.lacnic.net/en/est.html RIPE NCC http://www.ripe.net/ripencc/mem-services/registration/statistics/ Raw Data/Historical RIR Allocations: ========================== http://www.aso.icann.org/stats/index.html http://www.iana.org/assignments/ipv4-address-space The Internet Number Resource Status Report, prepared jointly by the four RIRs, provides up-to-date statistics on rates of IPv4 allocation. This presentation is available at: http://www.ripe.net/rs/statistics/resource-status-200310.pdf Cheers, Paul Rendek Head of Member Services and Communications RIPE NCC . From ncc at ripe.net Wed Oct 29 17:34:54 2003 From: ncc at ripe.net (Paul Rendek) Date: Wed, 29 Oct 2003 17:34:54 +0100 Subject: [address-policy-wg] [ncc-co@ripe.net] IPv4 Address Space Message-ID: <5.2.1.1.2.20031029172736.04590e90@mailhost.ripe.net> [Apologies for duplicate mailings] Dear Colleagues, There have been press articles posted over the past year that make statements about the remaining pool of IPv4 address space. A recent article states there is a shortage and that Internet Protocol Numbers will run out some time in the year 2005. The Regional Internet Registries (RIRs) do not themselves make predictions about when the remaining IPv4 address space will be depleted. They do, however, report on the rates of RIR allocation of IPv4 address space and on the state of the remaining pool of IPv4 address space. The information provided in these RIR reports makes it apparent that many of the recent claims regarding IPv4 address space shortage are speculative and are not based on authoritative, publicly available statistics. IPv4 Address Space: Current Statistics ============================ The global pool of IPv4 addresses is administered by the Internet Assigned Numbers Authority (IANA), which allocates address blocks to Regional Internet Registries (RIRs) as they are required. The IPv4 allocation unit in this case is the "/8 block", equivalent to approximately 16 million addresses. It should be noted that as of 30 June 2003 the global pool of IPv4 address space contained 91 of these blocks for this purpose. The RIRs report on statistics regarding IPv4 allocation on their respective web sites and present a "Joint Statistics" report at each of the RIR meetings and at other Internet industry meetings several times yearly. This information is publicly available and provides the most up-to-date statistics on rates of IPv4 allocation. The most recent presentation on this subject can be found at: http://www.ripe.net/rs/statistics/resource-status-200310.pdf This report states that the RIRs have collectively allocated 19.59 /8 equivalents in the four and a half years between January 1999 and June 2003. It also identifies that there are 91 /8 equivalents held by the IANA in reserve for future allocation by the RIRs. Based on today's total global allocation rate of approximately 4.25 blocks per year in 2002, or 5.5 blocks in 2001, and the remaining pool of 91 blocks held by IANA, it is unrealistic to assume that there is an imminent shortage in the IPv4 address space. Even allowing for a dramatic increase in address consumption rates, it is highly probable that IPv4 address space will last well beyond the two years predicted by some. IPv4 Address Space: Allocated Globally According to Regional Needs ================================================== The RIRs are not-for-profit membership organisations dedicated to providing neutral and fair Internet resource distribution to their members, while ensuring the conservation and aggregation of IPv4 address space. The IANA policies for allocation of IPv4 address blocks to the RIRs are applied fairly and are based purely on the documented need for address space. When IPv4 address space finally "runs out" this will occur at the global level, leaving each region with a relatively small pool of addresses remaining to be allocated. It has been suggested that Asia will experience an IPv4 address shortage before other regions. This is simply not true. This is because addresses are distributed in a co-ordinated fashion from a single global pool, and there is no system whereby that pool is exclusively divided among, or pre-allocated to, different countries or regions. Through the current system of address administration, IP addresses are allocated according to immediate need wherever that need is demonstrated and it is simply not possible for isolated "shortages" to exist. As has been done in the past, the RIRs will continue to report regularly on the registration and allocation rates of Internet Protocol Numbers, and will work closely with the IANA to ensure the efficient management of the remaining IPv4 address space. RIR Statistics: ========== APNIC http://www.apnic.net/info/reports/index.html ARIN http://www.arin.net/statistics/index.html LACNIC http://www.lacnic.net/en/est.html RIPE NCC http://www.ripe.net/ripencc/mem-services/registration/statistics/ Raw Data/Historical RIR Allocations: ========================== http://www.aso.icann.org/stats/index.html http://www.iana.org/assignments/ipv4-address-space The Internet Number Resource Status Report, prepared jointly by the four RIRs, provides up-to-date statistics on rates of IPv4 allocation. This presentation is available at: http://www.ripe.net/rs/statistics/resource-status-200310.pdf Cheers, Paul Rendek Head of Member Services and Communications RIPE NCC . From ncc at ripe.net Wed Oct 29 17:34:54 2003 From: ncc at ripe.net (Paul Rendek) Date: Wed, 29 Oct 2003 17:34:54 +0100 Subject: [address-policy-wg] [local-ir@ripe.net]IPv4 Address Space Message-ID: <5.2.1.1.2.20031029172736.04590e90@mailhost.ripe.net> [Apologies for duplicate mailings] Dear Colleagues, There have been press articles posted over the past year that make statements about the remaining pool of IPv4 address space. A recent article states there is a shortage and that Internet Protocol Numbers will run out some time in the year 2005. The Regional Internet Registries (RIRs) do not themselves make predictions about when the remaining IPv4 address space will be depleted. They do, however, report on the rates of RIR allocation of IPv4 address space and on the state of the remaining pool of IPv4 address space. The information provided in these RIR reports makes it apparent that many of the recent claims regarding IPv4 address space shortage are speculative and are not based on authoritative, publicly available statistics. IPv4 Address Space: Current Statistics ============================ The global pool of IPv4 addresses is administered by the Internet Assigned Numbers Authority (IANA), which allocates address blocks to Regional Internet Registries (RIRs) as they are required. The IPv4 allocation unit in this case is the "/8 block", equivalent to approximately 16 million addresses. It should be noted that as of 30 June 2003 the global pool of IPv4 address space contained 91 of these blocks for this purpose. The RIRs report on statistics regarding IPv4 allocation on their respective web sites and present a "Joint Statistics" report at each of the RIR meetings and at other Internet industry meetings several times yearly. This information is publicly available and provides the most up-to-date statistics on rates of IPv4 allocation. The most recent presentation on this subject can be found at: http://www.ripe.net/rs/statistics/resource-status-200310.pdf This report states that the RIRs have collectively allocated 19.59 /8 equivalents in the four and a half years between January 1999 and June 2003. It also identifies that there are 91 /8 equivalents held by the IANA in reserve for future allocation by the RIRs. Based on today's total global allocation rate of approximately 4.25 blocks per year in 2002, or 5.5 blocks in 2001, and the remaining pool of 91 blocks held by IANA, it is unrealistic to assume that there is an imminent shortage in the IPv4 address space. Even allowing for a dramatic increase in address consumption rates, it is highly probable that IPv4 address space will last well beyond the two years predicted by some. IPv4 Address Space: Allocated Globally According to Regional Needs ================================================== The RIRs are not-for-profit membership organisations dedicated to providing neutral and fair Internet resource distribution to their members, while ensuring the conservation and aggregation of IPv4 address space. The IANA policies for allocation of IPv4 address blocks to the RIRs are applied fairly and are based purely on the documented need for address space. When IPv4 address space finally "runs out" this will occur at the global level, leaving each region with a relatively small pool of addresses remaining to be allocated. It has been suggested that Asia will experience an IPv4 address shortage before other regions. This is simply not true. This is because addresses are distributed in a co-ordinated fashion from a single global pool, and there is no system whereby that pool is exclusively divided among, or pre-allocated to, different countries or regions. Through the current system of address administration, IP addresses are allocated according to immediate need wherever that need is demonstrated and it is simply not possible for isolated "shortages" to exist. As has been done in the past, the RIRs will continue to report regularly on the registration and allocation rates of Internet Protocol Numbers, and will work closely with the IANA to ensure the efficient management of the remaining IPv4 address space. RIR Statistics: ========== APNIC http://www.apnic.net/info/reports/index.html ARIN http://www.arin.net/statistics/index.html LACNIC http://www.lacnic.net/en/est.html RIPE NCC http://www.ripe.net/ripencc/mem-services/registration/statistics/ Raw Data/Historical RIR Allocations: ========================== http://www.aso.icann.org/stats/index.html http://www.iana.org/assignments/ipv4-address-space The Internet Number Resource Status Report, prepared jointly by the four RIRs, provides up-to-date statistics on rates of IPv4 allocation. This presentation is available at: http://www.ripe.net/rs/statistics/resource-status-200310.pdf Cheers, Paul Rendek Head of Member Services and Communications RIPE NCC . From ncc at ripe.net Wed Oct 29 17:34:54 2003 From: ncc at ripe.net (Paul Rendek) Date: Wed, 29 Oct 2003 17:34:54 +0100 Subject: [address-policy-wg] [ncc-co@ripe.net] IPv4 Address Space Message-ID: <5.2.1.1.2.20031029172736.04590e90@mailhost.ripe.net> [Apologies for duplicate mailings] Dear Colleagues, There have been press articles posted over the past year that make statements about the remaining pool of IPv4 address space. A recent article states there is a shortage and that Internet Protocol Numbers will run out some time in the year 2005. The Regional Internet Registries (RIRs) do not themselves make predictions about when the remaining IPv4 address space will be depleted. They do, however, report on the rates of RIR allocation of IPv4 address space and on the state of the remaining pool of IPv4 address space. The information provided in these RIR reports makes it apparent that many of the recent claims regarding IPv4 address space shortage are speculative and are not based on authoritative, publicly available statistics. IPv4 Address Space: Current Statistics ============================ The global pool of IPv4 addresses is administered by the Internet Assigned Numbers Authority (IANA), which allocates address blocks to Regional Internet Registries (RIRs) as they are required. The IPv4 allocation unit in this case is the "/8 block", equivalent to approximately 16 million addresses. It should be noted that as of 30 June 2003 the global pool of IPv4 address space contained 91 of these blocks for this purpose. The RIRs report on statistics regarding IPv4 allocation on their respective web sites and present a "Joint Statistics" report at each of the RIR meetings and at other Internet industry meetings several times yearly. This information is publicly available and provides the most up-to-date statistics on rates of IPv4 allocation. The most recent presentation on this subject can be found at: http://www.ripe.net/rs/statistics/resource-status-200310.pdf This report states that the RIRs have collectively allocated 19.59 /8 equivalents in the four and a half years between January 1999 and June 2003. It also identifies that there are 91 /8 equivalents held by the IANA in reserve for future allocation by the RIRs. Based on today's total global allocation rate of approximately 4.25 blocks per year in 2002, or 5.5 blocks in 2001, and the remaining pool of 91 blocks held by IANA, it is unrealistic to assume that there is an imminent shortage in the IPv4 address space. Even allowing for a dramatic increase in address consumption rates, it is highly probable that IPv4 address space will last well beyond the two years predicted by some. IPv4 Address Space: Allocated Globally According to Regional Needs ================================================== The RIRs are not-for-profit membership organisations dedicated to providing neutral and fair Internet resource distribution to their members, while ensuring the conservation and aggregation of IPv4 address space. The IANA policies for allocation of IPv4 address blocks to the RIRs are applied fairly and are based purely on the documented need for address space. When IPv4 address space finally "runs out" this will occur at the global level, leaving each region with a relatively small pool of addresses remaining to be allocated. It has been suggested that Asia will experience an IPv4 address shortage before other regions. This is simply not true. This is because addresses are distributed in a co-ordinated fashion from a single global pool, and there is no system whereby that pool is exclusively divided among, or pre-allocated to, different countries or regions. Through the current system of address administration, IP addresses are allocated according to immediate need wherever that need is demonstrated and it is simply not possible for isolated "shortages" to exist. As has been done in the past, the RIRs will continue to report regularly on the registration and allocation rates of Internet Protocol Numbers, and will work closely with the IANA to ensure the efficient management of the remaining IPv4 address space. RIR Statistics: ========== APNIC http://www.apnic.net/info/reports/index.html ARIN http://www.arin.net/statistics/index.html LACNIC http://www.lacnic.net/en/est.html RIPE NCC http://www.ripe.net/ripencc/mem-services/registration/statistics/ Raw Data/Historical RIR Allocations: ========================== http://www.aso.icann.org/stats/index.html http://www.iana.org/assignments/ipv4-address-space The Internet Number Resource Status Report, prepared jointly by the four RIRs, provides up-to-date statistics on rates of IPv4 allocation. This presentation is available at: http://www.ripe.net/rs/statistics/resource-status-200310.pdf Cheers, Paul Rendek Head of Member Services and Communications RIPE NCC .