June 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

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

Initial PA Allocation Criteria
by RIPE NCC Staff 11 Jul '01

11 Jul '01

Dear all, Further to my mail on PA Allocation criteria (see below), here follows a concrete proposal, including details of the actual criteria to be determined. Very little feedback was received on the last mail asking for input on the actual details of such criteria. Therefore, in order to move forward and establish the details of these criteria, please find below a clear proposal of criteria for the initial PA Allocation received by a newly established Local IR. Proposed Criteria for Initial /20 PA Allocation ----------------------------------------------- The Local IR is required to: - Demonstrate previous efficient utilisation of a /22 (1024 addresses). Or - Demonstrate immediate need for a /22 Renumbering: If current address space held by the Local IR amounts to a /22 or less, the Local IR is required to renumber that address space into the PA Allocation it will receive from the RIPE NCC. Can the lir-wg agree with the above proposed criteria? If no further objections are raised I would like to suggest that the RIPE NCC moves forward and implements this policy. Please let us know if you are not in agreement with the above. Kind regards, Nurani Nimpuno +------------------------------------+ | Nurani Nimpuno | | Internet Address Policy Manager | | RIPE Network Co-ordination Centre | | http://www.ripe.net | +------------------------------------+ ------- Forwarded Message Date: Fri, 01 Jun 2001 18:23:48 +0200 From: RIPE NCC Staff <ncc(a)ripe.net> Resent-From: Nurani Nimpuno <nurani(a)ripe.net> Sender: owner-lir-wg(a)ripe.net To: lir-wg(a)ripe.net Resent-To: ncc(a)ripe.net Subject: Summary: PA Allocation criteria discussion Dear all, Thank you for you input thus far in the discussion on portable address space. Many useful points have been raised on the matter of PI address space and PA Allocations. (The complete discussion can be read at: http://www.ripe.net/ripe/mail-archives/lir-wg/current/msg00130.html) Below is an attempt to summarise the discussion so far: The concept of smaller allocations (than current /20) was initially brought but the majority felt that this was not a realistic option. The comments showed concern about the exponential growth in the routing table and it was believed that smaller allocations would further contribute to this growth. There was consequently further discussion on how the RIR policies can prevent/reduce this through sensible address allocation/assignment criteria. On the subject of PI assignments, related to the current growth in the routing table, it was agreed that PI assignments should (as current policy states) be based on need and not routability. It was further stated that end users should be discouraged from multi-homing with globally visible address space. Some participants of the discussion argued for a complete discontinuation of PI. Most contributors agreed that /20 PA Allocations should be given to organisations who wish to further assign addresses to customers / end-users from their PA block. PA Allocations should not be made to organisations to satisfy pure multi-homing / independence needs. A set of criteria should therefore be determined to clarify this. Lastly, the majority agreed that the PA Allocation criteria should be based on previous efficient utilisation. There was further discussion with regards to the size of the efficiently utilised address space the requestor needs to demonstrate. The prefix sizes /22 and /21 were briefly discussed. If the community believes that this is a just summary of the discussion, I wish to move forward and determine the details of such criteria, through presenting a few very concrete discussion points. I would like your opinion on the following: 1. Do you agree on the following criteria to be set: The requesting organisation need to show - Demonstrated efficient utilisation of a /xx or - Immediate need for a /xx ? 2. If qualifying through the criterion of demonstrated efficient utilisation of address space, should the requestor need to demonstrate efficient utilisation of A. /22 or B. /21 ? 3. If qualifying through the criterion of demonstrated immediate need, should the requestor need to demonstrate an immediate need of a A. /22 or B. /21? 4. Should the requesting organisation be required to renumber depending on the sizes of its current aggregates? 4A. If so, what is a reasonable size of the smallest aggregate that an organisation would be required to renumber? I am looking forward to your input on these concrete points. Kind regards, Nurani Nimpuno RIPE NCC ------- End of Forwarded Message

2 1

Call for agenda items & draft agenda
by Hans Petter Holen 11 Jul '01

11 Jul '01

Dear WG, I would like to bring to your attention the upcoming working group meeting in Bologna, likely to be on Wed May 2nd. Please suggest agenda items that needs to be discussed to the mailinglist. Draft Agenda 1.Admin - scribe, participant list, charter, mailing-lists 2.Agenda 3.RIPE 38 minutes & actions 4.Report from the RIPE NCC Hostmasters by Nurani Nimpuno 5. 17th of May Task force - goal reached or what to do next ? 6. Report from The ASO: AC happenings and GA 7.Closure of the ICANN ad Hoc Group on numbering 8.Election of WG Chair and co-chair Actions from last meeting: 35.4 NCC PGP Key exchange procedure 35.5 NCC Implement PGP for hm 36.5 Chair Assignment window applied on infrastructure 36.6 AP Collect arbitrators 36.7 NCC Keep lir-wg updated on pre RIR address space changes 37.1 WG Further discuss restoring the transparency 37.2 NCC Incorporate IESG/IAB proposal into IPv6 policy 37.3 M17 Work with the RIPE NCC to implement suggestions

1 4

IPv6 for IXPs
by Mirjam Kuehne 02 Jul '01

02 Jul '01

Dear all, how about this (thanks to Henk): Definition: 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 assigned by upstream ISPs. Assignment size: - a /48 in most cases - a /64 if it is known that there will only be one subnet (basically following the IAB recommendation) Additional warning: The RIRs should warn the IXP that it is strongly discouraged to announce the addresses and that they will likely not to be globally routable. If this is agreeable the RIPE NCC will implement this policy and co-ordinate it with the other Regional Internet Registries. Mirjam Kuehne RIPE NCC

6 7

IPv6 addresses for IXPs
by paul.mylotte＠bt.com 29 Jun '01

29 Jun '01

In the RIPE Policy Statement under development I think we should state explicitely the support for both types of IPv6 exchanges, viz: 1 allocate addresses for IPv6 exchange infrastructure only (no > onwards allocation in the manner of a backbone ISP). > 2 allocate a sub TLA to the IPv6 exchange which will then act > in the manner of an ISP and allocate downstream. > > In order to progress this, I would like to propose: > 1 IPv6 exchanges that need addresses for the purpose of internal > addressing can apply for the addresses already set aside for this > purpose and held by IANA, as per RFC2928 (Initial IPv6 Sub-TLA ID Assignments) and RFC2450 (Proposed TLA and NLA Assignment Rules). In this case a /48 allocation will be sufficient. (How IPv6 > exchanges should apply for these addresses is out of scope > - either direct to IANA, or IANA allocates down to RIRs first). > 2 IPv6 exchanges that plan to onward allocate addresses in the > manner of an ISP should apply via the existing mechanism. The > existing mechanism is currently being reviewed and this review > should take account of any changes necessary to include IPv6 > exchanges explicitly desiring addresses for onward allocation as > being acceptable candidates for address space. > > > > Regards, > > Paul > > P. S. Mylotte > BTexact Technologies > Adastral Park > 01473 606333 / + 44 1473 606333 > paul.mylotte(a)bt.com > > BTexact Technologies is a trademark of British Telecommunications plc > Registered office 81 Newgate Street London EC1A 7AJ > Registered in England no. 1800000 > > This electronic message contains information from British > Telecommunications plc which may be priveleged or confidential. The > information is intended to be for the use of the individual(s) or entity > named above. If you are not the intended recipient be aware that any > disclosure, copying, distribution or use of the contents of this > information is prohibited. If you have received this electronic message in > error, please notify us by telephone or email (to the number or address > above) immediately. >

1 0

IPv6 for IXPs
by Mirjam Kuehne 27 Jun '01

27 Jun '01

Dear all, After the active discussion regarding IPv6 address for Internet Exchange Points (IXPs), we now need to come to a conclusion. I have reviewed the discussion again and will try to summarise it (quite a challenge :-). Many issues were raised, but so far no clear consensus was reached. Please bare with me if I have not included all opinions and comments or if some submissions are not summarised accurately. However, I hope that this summary will spark some further discussions and hopefully a conslusion at the end. I cc the eix-wg mailing list here and would like to explicitely encourage IXP operators to actively participate in this discussion. Kind Regards, Mirjam Kuehne RIPE NCC ---------- The following questions were raised during the discussion: 1. Is a special policy needed for IXPS (and following from this possibly also for other 'special purposes'? 2. What is the intended use of the addresses at the IXPs? 3. How is an IXP defined? 4. What size should be assigned? 1. special policy needed? ------------------------- Many participants believed that a policy for IXPs is needed, because they usually do not have an upstream provider and also do not want to use addresses from one of their members (for political rather than technical reasons). Some participants however felt that no special policy is needed for IXPs. They should either be treated as an end-user network or should be able to get a 'normal' (currently a /35) IPv6 allocation from the RIRs. 2. intended use of the addresses? ---------------------------------- Special policy would only be needed for addresses needed for the Exchange Point medium itself (usually a layer-2 network). Addresses needed for other purposes (e.g. additional services provided to the members) should be assigned by upstream ISPs. It was also discussed if the addresses should actually be announced. It was felt that this is not really necessary, but that some IXPs do it anyway. There was no conclusion if this should be part of the policy (e.g. the micro-allocation policy implemented in the ARIN region does require that the prefix is not announced). One option would be to warn the IXP that these addresses are likely not to be globally routable. 3. definition of an IXP ----------------------- It was generally felt that it is difficult to define an IXP, but that the following refined definition could be used as a starting point: Three or more ASes and thee or more separate entities attached to a LAN (a common layer 2 infrastructure) for the purpose of peering and more are welcome to join. 4. assignment size? ------------------- Some participants felt that a /64 would be appropriate if the IXP would consist of only one subnet. In all other cases a /48 should be assigned (this would be consistent with the IESG/IAB recommendation). Others felt that the address size should not be pre-defined, but should be based on need and discussed on a case-by-case basis between the requestor and the RIR. 5. Other issues raised ---------------------- Requests should only be sent by established LIRs or via an existing LIR. Reverse delegation would have to be done by the RIR (requested also via an existing LIR)

5 4

RE: IPv6 for IXPs
by Wilfried Woeber, UniVie/ACOnet 26 Jun '01

26 Jun '01

>To: lir-wg(a)ripe.net >CC: eix-wg(a)ripe.net >Subject: IPv6 for IXPs >Date: Tue, 26 Jun 2001 12:22:51 +0200 >From: Mirjam Kuehne <mir(a)ripe.net> > >Dear all, > >After the active discussion regarding IPv6 address for Internet >Exchange Points (IXPs), we now need to come to a conclusion. I have >reviewed the discussion again and will try to summarise it (quite a >challenge :-). Many issues were raised, but so far no clear consensus >was reached. > >Please bare with me if I have not included all opinions and comments >or if some submissions are not summarised accurately. > >However, I hope that this summary will spark some further discussions >and hopefully a conslusion at the end. > >I cc the eix-wg mailing list here and would like to explicitely >encourage IXP operators to actively participate in this discussion. > >Kind Regards, > >Mirjam Kuehne >RIPE NCC >---------- > >The following questions were raised during the discussion: > >1. Is a special policy needed for IXPS (and following from this > possibly also for other 'special purposes'? >2. What is the intended use of the addresses at the IXPs? >3. How is an IXP defined? >4. What size should be assigned? > > >1. special policy needed? >------------------------- > >Many participants believed that a policy for IXPs is needed, because >they usually do not have an upstream provider and also do not want to >use addresses from one of their members (for political rather than >technical reasons). I strongly feel that leaving the term "political reasons" in here (and maybe even allow that to creep into some archive procedural description is setting off a time bomb! The "weakest" term I would accept (instead of requiring _technical_ reasons from the beginning) is "for reasons of stable operations"). >Some participants however felt that no special policy is needed for >IXPs. They should either be treated as an end-user network or should >be able to get a 'normal' (currently a /35) IPv6 allocation from the >RIRs. > > >2. intended use of the addresses? >---------------------------------- > >Special policy would only be needed for addresses needed for the >Exchange Point medium itself (usually a layer-2 network). Addresses >needed for other purposes (e.g. additional services provided to the >members) should be assigned by upstream ISPs. I fully agree with that, but at the same time this requiremet weakens the overall reasoning. Just as an observation. >It was also discussed if the addresses should actually be >announced. It was felt that this is not really necessary, but that >some IXPs do it anyway. There was no conclusion if this should be part >of the policy (e.g. the micro-allocation policy implemented in the >ARIN region does require that the prefix is not announced). > >One option would be to warn the IXP that these addresses are likely >not to be globally routable. I really like the proposal by Robert.Kiessling: "strongly discouraged to announce the addresses and likely not to be globally routable"? >3. definition of an IXP >----------------------- > >It was generally felt that it is difficult to define an IXP, but that >the following refined definition could be used as a starting point: What do you intend by saying "as a starting point"? >Three or more ASes and thee or more separate entities attached to a >LAN (a common layer 2 infrastructure) for the purpose of peering and >more are welcome to join. For the moment this seems to take care of the situations mentioned during the meeting. However, it might be too fuzzy in general - and too specific as regards the transport mechanism for the packets being exchanged according to the peering agreement. E.g. I might agree with 2 of my students to build an exchange point for IPv6 packets, but we would prefer to use the existing IPv4-based internet as a transport mechanism. Would that be compatible with "(a common layer 2 infrastructure)"? I don't have a better proposal for the moment, unfortunately, but I would like to see (hear :-) people think about those aspects. >4. assignment size? >------------------- > >Some participants felt that a /64 would be appropriate if the IXP >would consist of only one subnet. In all other cases a /48 should be >assigned (this would be consistent with the IESG/IAB recommendation). > >Others felt that the address size should not be pre-defined, but >should be based on need and discussed on a case-by-case basis between >the requestor and the RIR. Go for the provisions as outlined in the IAB/IESG Recommendation, and if in doubt, assign the bigger block. >5. Other issues raised >---------------------- > >Requests should only be sent by established LIRs or via an existing >LIR. Please s/should/must/ !! >Reverse delegation would have to be done by the RIR (requested also >via an existing LIR) Agreed. Wilfried. _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

2 1

IPv6 addresses for Exchange Points
by Robert Kiessling 25 Jun '01

25 Jun '01

The discussion on the issue of IPv6 allocations for exchange points seems to stagnate, and to me it looks like an agreement might be close. Could we expect a new suggestion from RIPE incorporating the previous discussion, together with remaining open questions? Exchanges have been waiting for many months, so a solution is overdue. Robert

2 1

Unprocessed update mails to RIPE Whois Database
by RIPE Database Administration 25 Jun '01

25 Jun '01

Dear Colleagues, [apologies for duplicate messages] Between Thu Jun 14 16:19:15 2001 CEST and Fri Jun 15 10:34:29 2001 CEST, due to a failure in our systems which processes updates to RIPE Whois Database, the update message have not been processed, instead they were only stored. Most of the users who sent those messages noticed that they didn't get any acknowledgement from our system, and re-sent their updates. Realizing the failure on Friday Jun 22, we tried to find out those messages which were _not_ re-sent by the user, and we processed them. Thus, please don't be confused if you've got a late acknowledgement message. If you have any questions about the incident, please contact <ripe-dbm(a)ripe.net>. We are sorry about the inconvenience this caused. Best Regards, Engin Gunduz RIPE NCC Database Group

1 0