August 2001 - lir-wg - mailman.ripe.net

Summary: Fixed Boundary (/29) Assignments
by Mirjam Kuehne 19 Sep '01

19 Sep '01

Dear LIR-WG, Here is an attempt to summarise the recent discussions on this mailing list regarding possible fixed size assignments. Following a review of the comments, it looks like the majority does not believe that a special assignment policy is needed. Most contributors agreed that there is no need to make a distinction in policy relating to different access methods. All assignments should be made on actual needs and according to the current IP address policies. The comments showed concerns about the administrative procedures required for these kinds of assignments. However, it was felt that these addresses need to be accounted for in some way. A possible way forward would be to initiate discussion surrounding the set of information necessary to justify these assignments while providing an efficient way for the LIRs to provide services to their customers. I realise that I did not touch on every aspect of the discussion but I hope that this is a fair summary in order for you to move forward Looking forward to a continuation of this debate. Best Regards, Mirjam Kuehne RIPE NCC

3 2

a Proposal to replacing RIPE 185
by Hans Petter Holen 07 Sep '01

07 Sep '01

Dear Working Group. Last year we set up the 17th of May task force to help the RIPE NCC identify potential improvements to the handeling of requests sent to hostmaster(a)ripe.net. May of theese have been implemented with success. The continuing growth of the number of LIRs does however call for other meassures to be taken. One of the suggestions by the task force and by the RIPE NCC hostmasters was to improve the IP address request form. A fruther analysis of the underlying problems seems to indicate that the shortcomings of the form is merely a symptom. There are clear indications that the whole policy and procedure document, RIPE 185, would benefit from an overhaul. After studying this document which was created when CIRD was still young and unknow to large parts of our community, we have found that it cotains a lot of usefull information, which is strictly speaking not Policies or Procedures. Rewriten in a clearer and more concise way we may archive a much better common understanding between the individual LIRs and the RIPE NCCC hostmasters. Our hypothesis is therefore that by creating a new strucure for documenting policy and procedures with better examples, and work on clearifying the language in the policy statements the work load of the RIPE NCC hostmasters may be reduced drasticaly. This is due to the fact that for a large propotion of the requests handeled by the RNH's there is lacking information the NRH's. By making it clear to the LIRs that it is the LIRs responsibility to request from the customer and make sure all relevant information is in the application before it is submittet to the RNH, we belive the total time spent, both by RNH's, and by LIR staff will be significantly reduced. We have therefor proposed the following structure for a replacement of RIPE 185: "Addressing Policies and Procedures for the RIPE NCC service region" (Abstract, Introduction, Scope) Internet Address Space and the Internet Registry System Policy framework Policies Glossary References Appendices (bitboundary chart, examples etc) Remove the following sections: All instructions on how to fill out an IP or ASN request form (in separate "supporting notes" ripe docs) PA vs PI (Is described in ripe-127) RIPE NCC RS (mailboxes, ticketing system, robot etc) (Instructions on website) Inaddr procedures (policy to be left in) (separate ripe doc will be created) Routing considerations Our proposal is that the RIPE NCC will present a first draft by doing the ground work on the document, re-writing some sections in a more clear and concise manner. This will then be presented to the lir-wg and the editorial committe for comments and input. We also belive that there is a strong need to publish all policy changes as RIPE document. If there is a need to reduce the administrative overhead of changing the procedures and policies document for every policy document, the changes and amenedments could be made in a single (not more than one at a time !) "Amendments to Policies and procedures. I have spent some days with Nurani and Sabrina at the RIPE NCC and discussed various ways to do this, and our proposal is to form a RIPE-185bis editorial team to facilitate discussion on the lir-wg mailing list and working group meetings and summarise the community consensus. ----- Hans Petter Holen, http://hph.home.online.no Phone: +47 40 20 39 16, Stalsberggt 28 B, 2010 Strømmen, Norway

1 2

Interim Policy proposal for IPv6 Address Assignment Policy for Internet Exchange Points
by Fearghas McKay 03 Sep '01

03 Sep '01

Following discussion between the WG-Chairs and the NCC we have the following proposed draft. To enable allocations to be made as soon as possible we are soliciting comments over the next few days but unless there are any issues we would like to start making allocations by the end of next week, ie 7th September 2001. Please send any comments to the LIR-WG list <lir-wg(a)ripe.net> We propose a joint session to be held at RIPE40 where we can discuss the initial size allocations, information required in the forms and other issues raised by the community after which we will formalise the proposal. Thanks Fearghas EIX-WG Chair -- IPv6 Address Assignment Policy for Internet Exchange Points =========================================================== 1. Abstract ----------- This document describes a policy for Internet Exchange Points (IXPs) under which unique IPv6 address space to be used for the infrastructure of the Internet Exchange Point can be obtained from a Regional Internet Registry (RIR). 2. Background ------------- It has been recognised that there are scenarios in which it is not desirable for IXPs to obtain address space from one of the Internet Service Providers (ISPs) connecting at the IXP. In these cases it is viable to have unique IPv6 address space assigned directly from an RIR. This address space is needed to adress the Exchange fabric. This issue has been brought forward to the RIPE community in May 2000 and has subsequently been discussed at RIPE Meetings and on public RIPE mailing lists. The conclusions of these discussions are described in this document. It is expected that the same policy will be accepted in the ARIN and the APNIC region at which point it will be incorporated in the Global IPv6 Policy document. 3. Definition ------------- An Internet Exchange Point is defined as a physical network infrastructure (layer 2) operated by a single entity with the purpose to facilitate the exchange of Internet traffic between Internet service providers. The number of Internet Service providers connected should at least be three and there must be a clear and open policy for others to join. Addresses needed for other purposes (e.g. additional services provided to the members) should be aquired through other appropriate means ( e.g. an upstream ISP). 4. Policy --------- An IXP that seeks to obtain an IPv6 address assignment by the RIR in its region, needs to submit a request to that RIR. IXPs operating in the RIPE NCC service region should use the 'IPv6 Request Form for Internet Exchange Points' (http://www.ripe.net/ripe/docs/ipv6request-exchangepoint.html). After approval of the request, the RIR will make the assignment. Since the address space does not need to be routable globally and an IXP is expected to only have one subnet, a /64 (64 bits of address space) will be assigned in most cases. In the case the IXP is using multiple fabrics (e.g. unicast separated for multicast), multiple /64s can be assigned to the IXP. IP Address requests can only be handled if the requestor is a Local Internet Registry (LIR) or if the request made through an existing LIR. 5. Other Considerations ----------------------- It should be noted that ISPs usually do not announce address space used on the IXP mesh itself to their peers. That means the address space assigned under this policy is likely not to be routable globally.

10 15

Interim Policy discussion
by David Kessens 31 Aug '01

31 Aug '01

This is a request to keep our discussion focused: - let's try to keep the discussion on lir-wg. - the proposed policy is an interim policy, that means further changes can be and will made to the policy after it has been approved. we don't have to discuss all those changes right now, *unless* you cannot live with the interim policy at all without such changes. - the policy is not intended to solve all problems to everybody. I hope this helps, David K. ---

1 0

policy changes since ripe-185
by Nurani Nimpuno 30 Aug '01

30 Aug '01

Dear all, As requested by the lir-wg chair, I have below composed a list of the policy discussions taking place since the publication of the RIPE Document ripe-185 (European Internet Registry Policies and Procedures). I have listed the discussions that have resulted in policy changes and that should be incorporated in the new version of the policy document. Kind regards, Nurani Nimpuno RIPE NCC Policy Changes since the publication of ripe-185 --------------------------------------------------- - Removal of the Maximum Allocation Size "Proposal to raise the maximum allocation to a single LIR", Guy Davies (02 Feb 1999) http://www.ripe.net/ripe/mail-archives/lir-wg/19990101-19990401/msg00010.ht… - Removal of the Maximum assignment window "Lowering maximum assignment window", Paula Caslav (10 Feb 1999) http://www.ripe.net/ripe/mail-archives/lir-wg/19990101-19990401/msg00019.ht… - Changes in Static Assignment policy ("Always-on connections") "static verification methods", Paula Caslav (23 Feb 1999) http://www.ripe.net/ripe/mail-archives/lir-wg/19990101-19990401/msg00018.ht… - Admin-c not mandatory on-site "admin-c in inetnum", Paula Caslav (15 Jun 1999) http://www.ripe.net/ripe/mail-archives/lir-wg/19990401-19990701/msg00011.ht… - IP-based webhosting strongly discouraged "IP assignment for virtual webhosting", Nurani Nimpuno (17 Nov 1999) http://www.ripe.int/ripe/mail-archives/lir-wg/19991001-20000101/msg00020.ht… IP assignment for virtual webhosting, Nurani Nimpuno (RIPE36 Budapest) - Lowering of Minimal allocation from /19 to /20 "Minimal allocation /20", Nurani Nimpuno (RIPE 36 Budapest) http://www.ripe.net/ripe/mail-archives/lir-wg/20000401-20000701/msg00187.ht… - PA Allocation Criteria "PA Allocation Criteria", Nurani Nimpuno (RIPE 39, Bologna) Presentation at RIPE 39: http://www.ripe.net/ripe/meetings/archive/ripe-39/index.html Conclusion by lir-wg chair: http://www.ripe.net/ripe/mail-archives/lir-wg/current/msg00004.html

2 2

Fwd: a Proposal to replacing RIPE 185
by Nurani Nimpuno 30 Aug '01

30 Aug '01

Dear all, As you all know, the RIPE NCC was actioned to review the current IP& ASN policy document, ripe-185 (European Internet Registry Policy and Procedures) and to present a raw first draft to the lir-wg August 29, 2001. Please find this draft attached. As outlined in Hans Petter's mail below, the task was to update the current policy document with policy changes implemented since the publication of ripe-185. Based on feedback from the membership, the objective was also to create a more condensed, clear and concise policy document that would make it easier for new LIRs and End Users to learn relevant IPv4 and ASN policies and procedures. Experience with the previous policy document clearly showed that new members found ripe-185 very complex. There was a clearly expressed need for a simpler and clearer document that could be used on a daily basis as a reference document for the LIRs. I have followed the structure in Hans Petter's mail below and have produced a first draft for the lir-wg to revise. The changes between this document and ripe-185 are the following: - Structure The structure has been completely revised in order to improve readability and making the information easy to find. - Update of policy The policy changes that have taken place since the last published version of the policy document have been incorporated in this draft. In addition to this, the document has been shortened to make it easier for readers to find the relevant information. Some sections have been completely removed as they are either covered elsewhere and/or not within the scope of a concise policy document. The sections that have been removed are: - Reverse Delegation procedures - Separate RIPE Document will be published (Reverse Delegation Policy distilled and kept) - Mergers, transfers & Closures - Separate RIPE Document will be published - RIPE NCC Registration Services - information available on the web (not policy nor procedure) - Request documentation - Available in the Supporting notes document (Currently ripe-220) (Sections pertaining to policy kept) - Obtaining an AS Number - Available in ASN request form and supporting notes (currently ripe-147) (ASN Policy kept however) - Routing considerations - (not policy nor procedure) As explained, this is a first draft produced by the RIPE NCC to facilitate the writing of this document as requested by the lir-wg. We are now welcoming the feedback on the community and the work of the editorial commitee to finalise this policy document. Kind regards, Nurani *--------------------------------------------------------* | Nurani Nimpuno <nurani(a)ripe.net> | | Internet Address Policy Manager | | RIPE Network Co-ordination Centre | | http://www.ripe.net | *--------------------------------------------------------* ------- Forwarded Message >From: "Hans Petter Holen" <hph(a)online.no> >To: lir-wg(a)ripe.net >Subject: a Proposal to replacing RIPE 185 >Date: Wed, 22 Aug 2001 22:17:43 +0200 > >Dear Working Group. >Last year we set up the 17th of May task force to help the RIPE NCC identify >potential improvements to the handeling of requests sent to >hostmaster(a)ripe.net. May of theese have been implemented with success. The >continuing growth of the number of LIRs does however call for other >meassures to be taken. > >One of the suggestions by the task force and by the RIPE NCC hostmasters was >to improve the IP address request form. A fruther analysis of the >underlying problems seems to indicate that the shortcomings of the form is >merely a symptom. There are clear indications that the whole policy and >procedure document, RIPE 185, would benefit from an overhaul. > >After studying this document which was created when CIRD was still >young and unknow to large parts of our community, we have found that it >cotains a lot of usefull information, which is strictly speaking not >Policies or Procedures. Rewriten in a clearer and more concise way we may >archive a much better common understanding between the individual LIRs and >the RIPE NCCC hostmasters. > >Our hypothesis is therefore that by creating a new strucure for documenting >policy and procedures with better examples, and work on clearifying the >language in the policy statements the work load of the RIPE NCC hostmasters >may be reduced drasticaly. This is due to the fact that for a large >propotion of the requests handeled by the RNH's there is lacking information >the NRH's. By making it clear to the LIRs that it is the LIRs responsibility >to request from the customer and make sure all relevant information is in >the application before it is submittet to the RNH, we belive the total time >spent, both by RNH's, and by LIR staff will be significantly reduced. > >We have therefor proposed the following structure for a replacement of RIPE >185: "Addressing Policies and Procedures for the RIPE NCC service region" > >(Abstract, Introduction, Scope) >Internet Address Space and the Internet Registry System >Policy framework >Policies >Glossary >References >Appendices (bitboundary chart, examples etc) > >Remove the following sections: >All instructions on how to fill out an IP or ASN request form > (in separate "supporting notes" ripe docs) >PA vs PI > (Is described in ripe-127) >RIPE NCC RS (mailboxes, ticketing system, robot etc) > (Instructions on website) >Inaddr procedures (policy to be left in) > (separate ripe doc will be created) >Routing considerations > >Our proposal is that the RIPE NCC will present a first draft by doing >the ground work on the document, re-writing some sections >in a more clear and concise manner. This will then be presented to the >lir-wg and the editorial committe for comments and input. > >We also belive that there is a strong need to publish all policy changes as >RIPE document. If there is a need to reduce the administrative overhead of >changing the procedures and policies document for every policy document, the >changes and amenedments could be made in a single (not more than one at a >time !) "Amendments to Policies and procedures. > >I have spent some days with Nurani and Sabrina at the RIPE NCC and discussed >various ways to do this, and our proposal is to form a RIPE-185bis editorial >team to facilitate discussion on the lir-wg mailing list and working group >meetings and summarise the community consensus. > >----- >Hans Petter Holen, http://hph.home.online.no >Phone: +47 40 20 39 16, Stalsberggt 28 B, 2010 Strxmmen, Norway

1 0

IPv6 request form for Internet Exchange Points
by Nurani Nimpuno 29 Aug '01

29 Aug '01

Dear all, Following the consensus reached in the community on assigning IPv6 address space to Internet Exchange Points, the RIPE NCC is now starting to make IPv6 assignments to requesting Internet Exchange Points. A specific request form has been created for this purpose, "IPv6 Request Form for Internet Exchange Points" which can be obtained at the RIPE document store at: http://www.ripe.net/ripe/docs/ipv6request-exchangepoint.html Pending requestors will be asked to complete this form in order to receive an IPv6 assignment from the RIPE NCC. We wish to thank all participants of this discussion for the constructive input in this matter. Kind regards, Nurani Nimpuno *--------------------------------------------------------* | Nurani Nimpuno <nurani(a)ripe.net> | | Internet Address Policy Manager | | RIPE Network Co-ordination Centre | | http://www.ripe.net | *--------------------------------------------------------*

7 9

Re: IPv6 request form for Internet Exchange Points
by Nurani Nimpuno 23 Aug '01

23 Aug '01

All, When concluding the discussion on IPv6 addresses for IXPs, the RIPE NCC were under the impression that participants in the discussion felt that they had had ample time to discuss the final proposed policy. Mirjam sent out a summary on the lists 28 June 2001 after the intense discussion both at the last RIPE meeting and on the mailing lists. (http://www.ripe.net/ripe/mail-archives/lir-wg/20010401-20010701/msg00 228.html) There were a few comments on actual wording that Mirjam took into account, but no further discussion. No objections were raised to the proposed definition. The RIPE NCC has several pending requests for IPv6 address space from IXPs that have been waiting since April. After such lengthy discussion and no further input from the community, we therefore felt that it would be appropriate to move forward and implement the concluded policy in order to meet the need of these LIRs. We do of course recognise the great importance of ensuring that the policy that the RIPE NCC implements is the one agreed upon by the community. This is essential. We also recognise the need for improving the co-ordination between the working group chairs and the RIPE NCC. We hope to discuss this further with the chairs. Some comments have been made on the list suggesting the RIPE NCC to not further postpone the evaluation of the currently pending IXP requests. If this reflects the general feeling in the community, then the RIPE NCC is ready to move forward and do so. If however, there is a need for further discussion, then we wish to encourage everyone to actively contribute with their comments. I hope that there is no need to postpone this discussion until the RIPE 40 meeting in October. I trust the working group chairs to propose a way forward that will ensure a fair and correct conclusion of this discussion. Kind regards, Nurani *--------------------------------------------------------* | Nurani Nimpuno <nurani(a)ripe.net> | | Internet Address Policy Manager | | RIPE Network Co-ordination Centre | | http://www.ripe.net | *--------------------------------------------------------* "Hans Petter Holen" <hph(a)online.no> writes: * | Agreed!!! I understand the need to ensure complete consensus regarding * | allocation, but *please* can we aim for a temporary work around to allow * | us to get an allocation using the existing document. * | * | We could review the interim allocations once the consensus is finally * | reached, and supply any new information then _if_ needed. But as Robert * | says, this has gone on far too long already! * * Would this be a way to proceede; * introduce the procedure proposed by Nurani as an interim procedure * in order to get this thing rolling ? * * Nothing is worse than technology and customers waiting for politicians * to make up their mind... * * * -hph *

1 0

Re: New RIPE-147 needed!
by Sabrina Waschke 23 Aug '01

23 Aug '01

Berislav, Thank you for your comments regarding the AS Number request form. You are correct in that the RIPE-147 document needs updating due to the new RPSL syntax. Over the last couple of months the RIPE NCC has been working hard on writing new documentation, developing training material and updating current documents to adjust to the new database software. RIPE-147 is on our to-do list and you should be able to expect a new version in the near future. Kind regards, Sabrina Waschke -- o------------------------------------------o | Sabrina Waschke sabrina(a)ripe.net | | Registration Services Operations Manager | | | | RIPE NCC tel +31 20 535 4444 | | www.ripe.net fax +31 20 535 4445 | o------------------------------------------o Berislav Todorovic <beri(a)kpnqwest.net> writes: * Maybe this will sound like a hassle, but ... * * ... Everytime I receive a ripe-147 form from teh customer I have to "patch" * it myself, to make it compliant with the new RPSL syntax. * * Any chance to get the new, RPSL-capable form in place (but as a NEW RIPE * document, please!)? Here's what should be changed: * * * Add "as-name:" attribute. * * Replace "as-in:" with "import:" and "as-out:" with "export:". * * Check to see if RPSL syntax is honored. * * Check the examples and make them compliant with RPSL syntax. * * Regards, * Beri * * --------- Berislav Todorovic, Network Engineer --------- * ------- KPNQwest N.V. - IP NOC (formerly EUnet NOC) ------- * ---- Wilhelmina van Pruisenweg 78, 2595 AN Den Haag, NL ---- * --- Phone: +31-70-379-3990; Mobile: +31-651-333-641 --- * -- Email: beri(a)kpnqwest.net <=> beri(a)EU.net -- * --- _ _ ____ _ .--. ____ ____ __/_ --- * ----- /__/ /___/ /\ / / / | / /___/ /___ / ------ * ------ _/ \_ / _/ \/ (__.\ |/\/ /___ ____/ (__. ----- *

1 0

Call for Nominations for Representatives to the ASO Address Council - RIPE region
by Hans Petter Holen 22 Aug '01

22 Aug '01

Dear colleagues, This is a call for nominations of individuals from the RIPE region to serve on the ASO Address Council. During October 2001, one RIPE region Address Council seat will become vacant and will be filled for the next three years by an individual nominated through this open call. This document describes the functions of the ASO and the Address Council, as well as the nomination and selection processes. If you are interested in nominating an individual, or if you are interested in being nominated as a member of the Address Council, please read this document carefully. 1. The Address Supporting Organisation - -------------------------------------- The ASO was formed in August 1999 as a consensus-based advisory body within the ICANN Framework, though a Memorandum of Understanding (MoU) signed by the current Regional Internet Registries and ICANN. The ICANN Bylaws (http://www.icann.org/general/bylaws.htm#VI-A) assign to the ASO the responsibility for the development of global policies relating to the distribution and registration of Internet address space, inter-domain routing identifiers and that part of the DNS name space that is used to name these addresses and identifiers. More information about the ASO is available at: http://www.aso.icann.org 2. The Address Council - ---------------------- The ASO Address Council co-ordinates the process of policy development in areas within the responsibility of the ASO, according to procedures defined within the MoU and by the AC itself. Specifically, these include the hosting of an annual open General Assembly meeting, and attending regular meetings by teleconference or in person at which policy issues and submissions may be considered. The other major responsibility of the Address Council is the appointment of individuals to fill ASO seats on the ICANN Board of Directors, according to procedures defined within the MoU. More information on the Address Council is available at: http://www.aso.icann.org/ac 3. The Role of Members of the Address Council - --------------------------------------------- Members of the Address Council do not represent any RIR, nor do they act as representatives of any other body. They are appointed in their individual capacity, and their membership cannot be proxied by any other individual or organisation. No member of the Address Council is entitled to any compensation from the ASO. No member can be indemnified by the ASO, nor can the ASO obtain insurance coverage relating to the liability of the actions of members of the Address Council. 4. Address Council Nominations Process - -------------------------------------- Through this nomination process, one individual from the RIPE region will be selected to serve on the Address Council for three years, replacing Hans Petter Holen who has served as an initial AC member for the past 2 years. The selection will be made though an open election from the set of individuals who have been nominated within this process. Any individual may be nominated, with the exception of any staff member of any Regional Internet Registry. Self-nominations are permitted. Nominations should be sent by email to <nominations(a)ripe.net>, by midnight UTC on 5 September 2001. The information included with the nomination is to be in English and should include: Name of Nominee: Country of residence: Organisation: Email Address: Postal Address: Biographical information: Motivation for nomination: Name of nominating individual: Organisation: Email Address: All nominees will be contacted via email to confirm their willingness to serve on the Address Council. If a nominee is not contactable via email, or does not respond, then their nomination will not be confirmed and they will not be eligible for election to the Address Council. All confirmed nominations will be listed on the RIPE web site after they are confirmed. All nominees will have the opportunity to submit a written statement in support of their nomination, for publication on the web site. In addition, others may express support for nominated individuals simply by completing and submitting the nomination form provided above. 5. Address Council Selection Process - ------------------------------------ The process for selection of the nominee to serve on the Address Council will involve an open election to be held during the plenary session of the RIPE 40 Meeting, in Prague, Czech Republic, on 5 October 2001. See the following URL for details about the selection procedure: http://www.ripe.net/ripe/wg/lir/adress_council-election.html More information about RIPE 40 will be available shortly at: http://www.ripe.net/ripe/meetings http://www.ripe.net/ripe/meetings/current/ripe-40/ Important Dates: 5 September 2001 - deadline for Address Council nominations Regards, Hans Petter Holen Local IR WG chair

1 1