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

LIR-PARTITIONED proposal (originally LIR-ALLOCATED)
by Nurani Nimpuno 01 Oct '01

01 Oct '01

LIR-PARTITIONED PROPOSAL ------------------------ Following James Aldridge's proposal below, here follows an implementation proposal by the RIPE NCC for a new status value in the RIPE Database. Background ----------- This proposal (originally named "LIR-ALLOCATED"was originally discussed at September 1999. James Aldridge later sent out a first proposal to the LIR-WG mailing list, 14 January 2000. (See: http://www.ripe.net/ripe/mail-archives/lir-wg/20000101-20000401/msg00007.ht…) The full final proposal (15 January 2001) by Aldridge can be found at: http://www.ripe.net/ripe/mail-archives/lir-wg/20010101-20010401/msg00003.ht… At the RIPE 38 meeting,(22-26 January 2001), the RIPE NCC accepted the action to implement this proposal. Motivation (as expressed by James Aldridge) -------------------------------------------- "For various reasons large registries often need to distribute their allocated address space between various parts of their organisation (for example we have separate national operations in 20 or so countries obtaining address space through the eu.eunet registry). In these situations it makes sense to document this redistribution in the RIPE database but there is currently no way to do this without throwing up errors in the RIPE NCC's auditing procedures or by removing flexibility and adding more work to the already busy NCC hostmasters by having each local operation treated as having their own allocation. Previously the RIPE database software allowed anyone to register an object with a status value of "ALLOCATED" but this was abused by people who didn't know what they were doing and so this is no longer possible and all non-NCC registered inetnum objects must now have the status of "ASSIGNED". However, having multiple levels of assignments in the RIPE database causes error reports from the NCC's auditing processes which now see anything under the higher- lever sub-allocation as being a duplicate (or overlapping) assignment which makes finding "real" problem assignments difficult or impossible. By allowing a local IR to register an inetnum object with a new status value of "LIR-ALLOCATED" it becomes possible to differentiate between a higher level sub-allocation ("status: LIR-ALLOCATED") and a final assignment by a LIR ("status: ASSIGNED"). By allowing this registration of intermediate objects it would also be possible to restrict changes to lower-level objects differently in different blocks of addresses within the LIR's allocation by setting different "mnt-lower" values without having to open the whole allocated block up for changes by anyone who might have a valid reason for updating a particular (range of) inetnum object(s)." Proposed Name ------------- RIPE NCC proposes to use the term: "LIR-PARTITIONED" ("LIR-PARTITIONED PA" and "LIR-PARTITIONED PI") rather than "LIR-ALLOCATED", to clarify the use of this added database feature. As "LIR-ALLOCATED" could be misinterpreted as a policy feature, we believe that "LIR-PARTITIONED" is a more suitable term, not involving policy terminology, but merely describing a partition of the LIR's allocation. Database Objects affected ------------------------- Only inetnum objects may have the "LIR-PARTITIONED" status value. Usage ----- The "LIR-PARTITIONED" feature allows LIRs to delegate maintenance of lower-level objects representing assignments within the address space specified by the inetnum object with the status "LIR-PARTITIONED PA" OR "LIR-PARTITIONED PI". Functionality ------------- When creating or modifying the inetnum object the database will check the value of the "status:" attribute according to the following rules: - The value of "ALLOCATED PA" or "ALLOCATED PI" is allowed if the object is maintained by the RIPE-NCC-HM-MNT mntner (this name is specified in ALLOCMNT variable of the configuration file) - The value of "LIR-PARTIONED PA" is allowed if one level less specific inetnum object contains a "status:" attribute with the value of "ALLOCATED PA". - The value of "LIR-PARTITIONED PI" is allowed if one level less specific inetnum object contains a "status:" attribute with the value of "ALLOCATED PI". Additional clarification ------------------------ This proposal addresses the added inetnum status value as proposed by James Aldridge. This is strictly a database feature, allowing LIRs to delegate maintenance within their allocations in the RIPE Database. An implementation of this proposal would not affect IP address allocation policy. It would not change the responsibility LIRs have for allocations and assignments held by them. Furthermore, it would not change the manner in which the RIPE NCC verifies allocation utilisation. Timeline -------- Before RIPE 41, January 2002. ---------------- As explained above, this implementation proposal only relates to the proposal outlined in this mail. We welcome the feedback from the LIR-WG and the DB-WG on the "LIR-PARTITIONED" proposal. However, recent comments on the lir-wg mailing list have indicated a wish among some members of the community for a more extensive change, allowing LIRs to sub-allocate IPv4 address space to subsidiaries or downstream ISPs. Such a change would be a rather significant change in current IPv4 address allocation policy, as it has an impact on the LIR's responsibility for its address space as well as the manner in which the RIPE NCC would verify utilisation. If the general feeling in the community is that the "LIR-PARTITIONED" proposal does not cover the LIRs' need, but a more significant change to current IP allocation policy is necessary, then I propose that this be discussed in detail in the LIR-WG. Kind regards, Nurani Nimpuno *--------------------------------------------------------* | Nurani Nimpuno <nurani(a)ripe.net> | | Internet Address Policy Manager | | RIPE Network Co-ordination Centre | | http://www.ripe.net | *--------------------------------------------------------*

2 1

Re: Initial PA Allocation Criteria
by Sabrina Waschke 29 Sep '01

29 Sep '01

Dear all, The RIPE NCC is going to implement the new policy "Criteria for Initial /20 PA Allocation" on November, 1st, 2001. (The consultation of our lawyers resulted in a delay for this implementation, apologies for that.) 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 "Hans Petter Holen" <hph(a)online.no> writes: * Dear all, * At the last lir-wg meeting there was a clear consensus that a criteria * for setting up an LIR and receiving the initial allocation was needed. * After a good discussion on the mailinglist there aconclusion has been * proposed. * * With the limited feedback received on the last attempt to call for closure, * I would like to look back to the principle in RFC 2050 and RIPE-185 * stating 25% immediate usage and 50% usage within a year, which * is in line with the proposal of requiring a new LIR to demonstrate previous * usage of a /22 (25% of a /20) or demonstrate immediate need for a * /22 (25% of a /20). * * I hereby propose to this wg that we declare rough consensus on this * proposal, and that we adapt this new criteria as new policy to be * effective from some future date to be suggested by the RIPE NCC. * * My observation is that while we still have some disagreement on the effect * this will have on start up on new LIRs I think the community needs to * balance the negative effect possible renumbering will have on a new LIR * to be, vs. the positive effect slowing down the growth of new LIRs will * have on the service level from the RIPE NCC and the global routing table. * * Sincerely, * Hans Petter * * ----- Original Message ----- * From: "RIPE NCC Staff" <ncc(a)ripe.net> * To: <lir-wg(a)ripe.net> * Sent: Friday, June 15, 2001 5:06 PM * Subject: Initial PA Allocation Criteria * * * | 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 * | * | * *

1 0

Re: [hostmaster-staff] Re: MIR proposal
by Sabrina Waschke 28 Sep '01

28 Sep '01

"Stephen Burley" <stephenb(a)uk.uu.net> writes: * A question to the NCC or any other registry managers: * * What is the criteria by which the RIR's request space from IANA, is it an * 80% usage rule? Yes, it is. 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 * ----- Original Message ----- * From: "Anne Lord" <anne(a)apnic.net> * To: "Hamid Alipour" <alipour(a)mail.dci.co.ir> * Cc: <lir-wg(a)ripe.net>; "Mirjam Kuehne" <mir(a)ripe.net> * Sent: Thursday, September 27, 2001 8:36 AM * Subject: Re: [hostmaster-staff] Re: MIR proposal * * * * hi, * * > Stephen seems just wants to solve UUNET problem * > with proposing MIR. However I am agree basically * > with the Idea. APNIC has added NIR * > ( National Internet Registry ) to the hierarchy. * > I think RIPE must let the NIRs as well. * * Just a note about this. The membership category of NIR actually * does not relate in any way to the specific problem that Stephen is trying * to address which is that of large multinational organisations routed * under one AS, having discontiguous IP address allocations through the * establishment of many LIRs. In fact, the NIR model actually does nothing * for aggregation - as NIRs receive a block which they further allocate * to their members who run businesses within a particular country. The * members in those countries served by NIRs are more likely to receive * discontiguous blocks (simply because the NIRs have a smaller pool), thus * not contributing to aggregation of routing information at all. * We are working with the NIRs to solve this with a referral process for * allocations directly from APNIC for the very large members of NIRs. * * Of course, having access to a local language service is very much on the * plus side of having NIRs. * * For the record though, the NIRs exist under the confederation membership * category. This also includes ISP confederations as well as NIRs. The * two are *very* different entities, so the confederation category has * been suspended until we work out a better solution. * * While I agree totally with Stephens objective and understand the motivation, * the proposal needs detail. How would it work exactly? APNIC's ISP * confederation * model which tried to address the same thing, did not work, and gave unfair * advantages to the ISP confederations. (Part of the reason the * 'confederation' * category has been suspended). * * It is definately a laudable challenge to try to produce a model and * procedures such that the policies are fairly applied to all. * * regards * * Anne * _____________________________________________________________________ * Anne Lord, Manager, Policy Liaison <anne(a)apnic.net> * Asia Pacific Network Information Centre phone: +61 7 3367 0490 * http://www.apnic.net fax: +61 7 3367 0482 * _____________________________________________________________________ * * * * * > * > * > ----- Original Message ----- * > From: "Stephen Burley" <stephenb(a)uk.uu.net> * > To: <crain(a)icann.org>; <lir-wg(a)ripe.net> * > Sent: 06/09/2001 7:40 È.Ù * > Subject: Re: MIR proposal * > * > * > > * > > ----- Original Message ----- * > > From: "John L Crain" <crain(a)icann.org> * > > To: <lir-wg(a)ripe.net> * > > Sent: Thursday, September 06, 2001 4:03 PM * > > Subject: Re: MIR proposal * > > * > > * > > > <CUT> * > > > * > > > Hi Gert, * > > > * > > > > * > > > > And yes, this is also very much needed for IPv6. Getting a /35 and * > > > > having to hand out individual /48's to customers of customers of * ours * > > > > isn't going to build proper hierarchical routing. * > > > * > > > The concepts for IPv6 that are under discussion do already cover this. * > > > An allocation goes to a large ISP who can then assign /48's directly * to * > > > networks connecting to them or shorter prefixes to * > resellers/downstreams. * > > > * > > > I'm not sure if this works in IPv4 because of the limited amount of * room * > > we * > > > have to play with. * > > * > > We are only limited because of teh current thinking and structure. * > > * > > * > > > * > > > I'm also not sure what the criteria would be in the proposal that * > defines * > > > who is and isn't allowed to become a MIR. It's certainly a differnet * > > concept * > > > to the present one in the RIPE region where LIR's don't "officially" * > sub- * > > > allocate. * > > > * > > * > > Its not so different from the RIR model. * > > * > > > I can certainly see why a large ISP would want to do this. I'm not * sure * > > how * > > > it changes the dynamics for smaller ISP's as to how they would get * their * > > IP * > > > addresses. Becoming an LIR with an upstream rather than a regional * > > registry * > > > I assume means renumbering if you change the upstream. * > > > * > > * > > MIR's are only to be created within a network (AS if you like) they * would * > > not suballocate to customers only LIR's withing their network (usualy * > > country specific). Other LIR's not needing a MIR would deal direct with * > the * > > NCC. UUNET has 17 LIR's currently the MIR would suballocate to these not * > to * > > other ISP's or customers direct. * > > BTW Nice to hear from you. * > > * > > * > > > John Crain * > > > * > > > * > > > * > > > * > > > * > > > * > * > * Mailing List: hostmaster-staff * * > * Handled by majordomo(a)staff.apnic.net * * > * * *

6 8

How Change route object origin entry
by kevin.bates＠bt.com 28 Sep '01

28 Sep '01

Hi A question I need to change the "Origin" entry on a /20 route object. This route is to be advertised via a different upstream provider, from a different AS number. The upstream provider will not advertise the route "until RIPE have been informed". I cannot change the route object entry. I get the following "Error: Hierarchical authorisation failed, request forwarded to maintainer" and I get the request forwarded to me. The mnt-by on the route object is not the problem - I can update other objects with that mnt-by object and I can change the "notify" entry on my route object. Therefore the error must be because of the mnt-by entry within the "receiving" AS number. (which I am not authorised to update) but I don't understand how. Is this the correct diagnosis? and is there something else I should be doing? I could ask RIPE hostmaster to make the changes but the ticketing system could take a couple of weeks. I could ask the new upstream AS owner to add me to their mnt-by entry but I am nothing to do with them. All suggestions gratefully received. kevin

4 3

IPv4 and ASN Policy draft on-line Enterprise & full IR policy doc
by kevin.bates＠bt.com 28 Sep '01

28 Sep '01

All, I would like to ask for advice and comment, and suggest it Is probably time for a discussion about the differences in operations of the two types LIR's, i.e. with the status of "enterprise" and "full". The current RIPE NCC documentation offers conflicting or no advice - I cannot find any specific enterprise registry instructions / guidance, except for the line "....large international Enterprises can also operate Local IRs". I would expect to see something in either Ripe 212 (Guidelines for Setting up a Local Internet Registry) or Ripe 185 (European Internet Registry Policies and Procedures). Given that IPv4 and ASN policy document is now under review I think that this is a good time to raise this issue again, and hopefully get something agreed in writing. Therefore I am specifically looking for "Enterprise Registry Assignment Policy instructions". I'll try briefly to give the background and a flavour of the issues. As a large company we operate several LIR's: 1. A public Internet Service with a large allocation (many /16) 2. Several small LIR's - product / site / country / subsidiary specific. 3. A large enterprise Registry (several Ripe /16 with both PI and PA ranges and historic UK address space originally assigned by ARIN) These registries are not all necessarily managed by the same teams nor do they all necessarily have specific interfaces with each other. The internet connectivity for them all is not via the same ISP, but the enterprise registry (3) does route via the Public Internet Service ISP (1). For an enterprise registry, assignment window size is irrelevant because all address space used will be assigned within the company "owning" the registry. Therefore a RIPE 141/219 is required for every assignment (this is policy for normal registries using addresses for their own infrastructure). Consider the scenario where an enterprise registry is allocated a block of addresses that it will only ever assign to its own company, and that the enterprise registry advertises & routes the whole block and assigns subnets from it to departments within the company where required. For all practical purposes all of these addresses are used by and assigned to the same place. In our case, problems involving the daily recovery/reassignment of subnets was overcome by agreeing a large corporate assignment window with the hostmaster and by keeping the number of addresses assigned to departments / groups / projects within that number -and then asking for an assignment increase where necessary. But what can an enterprise registry's addresses be used for? * its own company infrastructure * server farms and web hosting ( thus being used indirectly by customers of the registry's company), and * various other uses - but not onward assignment to "paying" customers. Following several previous discussions between myself, my colleagues and with various RIPE NCC hostmasters it has been agreed that RIPE NCC will now allow us to transfer "experimental" addresses (obtained from our enterprise Registry), which are used by a department within the company, into "commercial" status - when the service offering changes from experimental to commercial. This means that systems using these addresses do not have to renumber to the range assigned by the public ISP. Therefore I would like to see this policy formalised within RIPE NCC documentation. And my next question is: If this department splits from the original company and becomes a separate entity, what happens to the addresses space it uses? There are several possibilities: 1. Migrate from the enterprise registry to the public ISP or another ISP (over a reasonable time period - but this could involve considerable pain/cost), or 2. Continue to use the enterprise registry address space, and then the "enterprise" registry converts to a "full" registry, but what are the implications? or 3. Split the enterprise registry into 2 (not contiguous ranges) and create another LIR. regards kevin

4 3

Maintaining IPs in LIRs/Enterprise LIRs
by Yuval Shchory 27 Sep '01

27 Sep '01

Hi all, I am currently in search for a tool which will help a LIR to maintain its IP addresses - currently everything is listed inside an Excel file, which is, IMHO, a very limited way of maintaining the lists. I was wondering what tools people in other LIRs in Europe use. I'll be more than happy for any advice (and links… :-). Thanks, --- Yuval Shchory VP Communications and Service Providers Spider Solutions Ltd. 6 HaChilazon St. Ramat-Gan 52522 Tel: +972-3-576-6980

8 7

Re: APNIC and RIPE IPv6 policies [Re: Agendas for IPv6/lir/eix joint sessions RIPE40]
by Gert Doering 27 Sep '01

27 Sep '01

Hi, On Thu, Sep 27, 2001 at 09:01:49PM +0300, Pekka Savola wrote: > Sure, but this requires significant additional assignments from IANA; > 2001::/16 will not be nearly enough. For example, 21xx::/8 might be > enough for a while. Yes. And IANA is part of the picture, concerning IPv6 assignment / allocation policies. So that should not hinder us doing the right thing (if we decide this is it). Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster(a)Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299

1 0

new IPv6 policy framework
by Mirjam Kuehne 27 Sep '01

27 Sep '01

Dear LIRs, Following the discussions at the RIPE 39 meeting and on the mailing lists in all the RIR communities, please find below the latest developments concerning IPv6 address allocation policies. This proposal is based on requirements expressed by the RIPE community as well as those of the other RIR communities. Please note that the text below is not a replacement of the current policy document, but rather a summary of the new IPv6 address allocation framework. Therefore this proposal is intended as input for further discussion in the RIPE community. When formulating this framework, we were specifically taking the following feedback into account: - The allocation criteria should be such that it is easy to obtain IPv6 address space. - The size of the initial allocation should be large enough to allow flexibility in addressing infrastructure and customer sites. This results in the following changes to previously discussed IPv6 allocation criteria: 1. to recognise existing infrastructure (both IPv4 and IPv6) where it exists and calculate IPv6 address needs based on existing networks. 2. to apply the slow start mechanism only for 'IPv6 only' networks without existing IPv4 infrastructure 3. to reduce the minimum allocation size for those IPv6 only networks (unless larger requirements are shown) 4. to measure the utilisation rate with the HD ratio rather than percentages 5. to make subsequent allocations when the HD ratio is reached Kind Regards, Mirjam Kuehne RIPE NCC ---------------- 1. Abstract This document provides a set of proposed policies for the management of IPv6 address space, specifically concerning the allocation of address space allocated by Regional Internet Registries (RIRs) to organisations operating IPv6 networks. 2. Overview Under the current system of management of global IP address space, Regional Internet Registries (RIRs) are responsible for allocation of address space to organisations within their respective geographic regions. In 1999, the RIRs APNIC, ARIN and RIPE NCC published a provisional policy document for IPv6, which has been in operation since then. Since 2000, this document has been under review and discussion, and through this process many issues have been raised. It is the aim of this document to propose a new policy framework for IPv6 address space management which takes into account the operational experience of the past 3 years, and addresses most if not all of the major issues raised through the open review process. This document does not attempt to provide details of policy implementation, procedures or documentation; nor does it document requirements for management of address space which is allocated. These policies can be established globally or regionally as appropriate, based on global consensus regarding the fundamental principles described here. 3. Address Space Requirement for Initial Allocation It is proposed to recognise existing network infrastructure and address utilisation (both IPv4 and IPv6). New IPv6 address needs are then based on these existing networks. In assessing a request for an initial allocation, there are 3 possible cases to consider: 3.1. the requesting organisation has an existing IPv4 network which will be addressed by the new IPv6 allocation 3.2. the requesting organisation has an existing IPv6 network 3.3. the requesting organisation has no network at all 3.1. Case 1 - Existing IPv4 services Where IPv6 address space is requested for addressing an existing IPv4 network, the address requirement is determined according to the structure and customer base of the existing IPv4 network. This only relates to the part of the network that will be migrated to IPv6. Additional policies may require the return of IPv4 address space to the RIR or upstream ISP, in the case the existing network is renumbered to the new IPv6 space in future. 3.2. Case 2 - Existing IPv6 services Where an IPv6 allocation is requested by an organisation to address infrastructure which is already addressed by IPv6 addresses from an upstream provider (or from the 6BONE), the address requirement is determined from the number of site addresses assigned by the organisation (as registered in the appropriate whois database). Where existing address space is no longer used, it must be returned. 3.3. Case 3 - No existing IPv4 or IPv6 services Where IPv6 address space is required by an organisation which has no existing infrastructure, the address requirement will be assessed according to network architecture plans and other documentation provided to the RIR within the request process. Such documentation be thorough enough to satisfy the RIR that the network deployment is genuine, however the specific details of documentation requirements will be defined separately. 4. Size of Initial Allocation The amount of addresses allocated to an existing network, will be determined based on the existing infrastructure and address utilisation of that network. For new networks without existing infrastructure, it is proposed to establish a minimum allocation for IPv6 address space. It is suggested to keep the size of the initial allocation relatively small (a /35 or smaller) and to determine the size of subsequent allocations based on the utilisation rate of the initial allocation (this is called slow start mechanism). This will allow easy access to IPv6 allocations for newcomers. At the same time possible wastage of address space and routing table growth will be limited. 5. Qualification for Subsequent Allocation An organisation which has already received address space from an RIR may receive a subsequent allocation providing that its existing address space is utilised in accordance with these policies. As explained below, the HD-Ratio will be used to measure utilisation of the existing address space. An organisation which is deploying substantial new network infrastructure may receive a subsequent allocation before it has reached the required utilisation threshold, providing that the address requirement would immediate cause the organisation to exceed the utilisation threshold. In such cases, the new network infrastructure will be examined by the RIR as if it is a request for a new network, and the RIR may require the same level of documentation detail, in order to approve the allocation. 6. Address Space Requirement for Subsequent Allocation For subsequent allocations, the RIR should assess the address requirement according to the organisation's history of IP address usage, as well as its stated requirements for future development. In general, the RIR should provide address space for a fixed time period of 2 years. The above recommendation should be followed in cases where the organisation concerned has complied with all relevant address management policies. In other cases, the RIR may allocate for a shorter future timeframe, and require that identified problems be rectified before larger allocations are made. 7. IPv6 Utilisation Metric: the HD-Ratio In IPv4, currently, a "utilisation threshold" of 80% is applied consistently in determining whether an IPv4 address pool is to be considered utilised, regardless of the size of that block. Consequently, an organisation which holds IP address space may not receive additional addresses until it has utilised at least 80% of the address space held. For IPv6 is it proposed to assess utilisation according to the "HD-Ratio" rather than by a simple percentage. The HD-Ratio was proposed by Durand in "draft-durand-huitema-h-density-ratio-01.txt" (an adaptation of the original H-Ratio defined by Huitema in RFC-1715). Using the HD-ratio we can establish a utilisation metric which allows percentage utilisation to decrease as the address space grows large. This is appropriate for management of the much larger blocks of address space under IPv6, and the likelihood of complex routing and allocation hierarchies within those address blocks. More details about the HD ratio can be found in Appendix A. Appendix A: In the general case, where individual objects are allocated out of an arbitrary address space, the HD-Ratio is calculated as follows: log(number of allocated objects) HD = -------------------------------------------- log(maximum number of allocatable objects) Where the objects being allocated are IPv6 site addresses (/48s) assigned from an IPv6 prefix of length P, we can restate this formula as follows (where A is the number of /48 prefixes actually assigned): log(A) log(A) In other words, the utilisation threshold T, expressed as a number of individual /48 prefixes to be allocated from IPv6 prefix P, can be calculated as: ((48-P)*HD) T = 2 In accordance with the recommendations of draft-durand-huitema-h-density-ratio-01.txt, it is proposed in this draft to adopt an HD-Ratio of 0.8 as the utilisation threshold for IPv6 address space allocations. The following table provides equivalent absolute and percentage address utilisation figures for IPv6 prefixes, corresponding to an HD-Ratio of 0.8 P 48-P Total /48s Threshold Util% 48 0 1 1 100.0% 47 1 2 2 87.1% 46 2 4 3 75.8% 45 3 8 5 66.0% 44 4 16 9 57.4% 43 5 32 16 50.0% 42 6 64 28 43.5% 41 7 128 49 37.9% 40 8 256 84 33.0% 39 9 512 147 28.7% 38 10 1024 256 25.0% 37 11 2048 446 21.8% 36 12 4096 776 18.9% 35 13 8192 1351 16.5% 34 14 16384 2353 14.4% 33 15 32768 4096 12.5% 32 16 65536 7132 10.9% 31 17 131072 12417 9.5% 30 18 262144 21619 8.2% 29 19 524288 37641 7.2% 28 20 1048576 65536 6.3% 27 21 2097152 114105 5.4% 26 22 4194304 198668 4.7% 25 23 8388608 345901 4.1% 24 24 16777216 602249 3.6% 23 25 33554432 1048576 3.1% 22 26 67108864 1825677 2.7% 21 27 134217728 3178688 2.4% 20 28 268435456 5534417 2.1% 19 29 536870912 9635980 1.8% 18 30 1073741824 16777216 1.6% 17 31 2147483648 29210830 1.4% 16 32 4294967296 50859008 1.2% 15 33 8589934592 88550677 1.0% 14 34 17179869184 154175683 0.9% 13 35 34359738368 268435456 0.8% 12 36 68719476736 467373275 0.7% 11 37 137438953472 813744135 0.6% 10 38 274877906944 1416810831 0.5% 9 39 549755813888 2466810934 0.4% 8 40 1099511627776 4294967296 0.4% 7 41 2199023255552 7477972398 0.3% 6 42 4398046511104 13019906166 0.3% 5 43 8796093022208 22668973294 0.3% 4 44 17592186044416 39468974941 0.2% 3 45 35184372088832 68719476736 0.2% 2 46 70368744177664 119647558364 0.2% 1 47 140737488355328 208318498661 0.1% 0 48 281474976710656 362703572709 0.1%

3 2

RFC1918 in public networks
by Robin Cragg 27 Sep '01

27 Sep '01

Hi, We are a medium sized ISP, and as such we have a publicly visible network using non-private IP space. I am looking to renumber our entire network to private IP space, and was wondering if any other members have done this. The only problem I can see is that traceroutes from outside our AS will fail at our border routers, which will make troubleshooting harder. Has anyone done this and would they recommend it? Robin

4 4

IPv4 and ASN Policy draft on-line
by Nurani Nimpuno 27 Sep '01

27 Sep '01

Dear all, The first draft of the IPv4 and ASN policy document is now available on-line at: http://www.ripe.net/rs/ipv4policy.html It is available as html and can also be downloaded in .txt format. This document is currently under revision as an editorial team is being assembled to provide input on this draft. If you are interested in participating in the editorial team, please contact the LIR-WG chair, Hans-Petter Holen <hph(a)online.no> or indicate your interest on this list. Kind regards, Nurani Nimpuno RIPE NCC

5 10

MIR proposal
by Stephen Burley 27 Sep '01

27 Sep '01

Hi Before i start the proposal i would like to ask a question, what ever happened to the Organisation object? Was is ever put in the DB? If not why not? as i am sure it got concensus. Ok the proposal. Background: We the evil UUNET/WorldCom in Europe have only one nework. AS702 covers all of our existing networks and is numbered out of all the LIR's we currently run - 17 in total - so AS702 is really a non contiguous AS with 120,000 routes. Back in the old days it was never invisaged that networks would ever get this large and the current concept of conservation, conservation, conservation, aggregation does not really support very large networks - i am not against conservation of IPv4 it just needs a fresh look. This proposal by definition will not appeal to all and will most certinly cause some to view this whole idea as "UUNET trying to use its muscle", believe me its not. We have to look at this proposal in the context of a very large network desperate the reduce the amount of prefixes on the routers before we hit the memory wall on routers and just the shear logistics of managing the aggreagation internal and external and assignment policies. We like to concept of Supernational Registries but all that really does is lump all of your current LIR bills into one and does not really help the aggregation issues as the growth patterns in differant registries are vast and range from near stagnent due to country specific reasons to the explosive growth, with various levels in between. This means that as a SuperNational it would be impossable to aggregate and reach 80% usage over the registries CIDR. The process of aggregation would force the planning of sub-allocation to give more than the immediate needed IPspace to allow for growth, much the same way RIPE does now when allocating to large LIR's and new LIR's. They will allocate a /20 and mark the contiguous /20 as "use last" this same pattern of sub-allocation needs to happen a level below RIR's and above LIR's - the MIR (multinational internet registry). The multinational registry (MIR) is not a means by which a large comapany with a very large network would have an advantage over LIR's. The LIR structure is still needed to provide local knowledge assignment and local aggregation, it will not replace LIR's just manage the overall aggregation of a large block of IP space and sub-allocate to them. It will not be limited by the 80% usage constraint but that by no way gives the MIR a free hand. Rather than being constrained by a fixed number (the numbers would have to be realistic) the MIR is governed by business nedds and routing requirements which the NCC would have to be informed of and understand. This does not mean the MIR ignore all of RIPE policy ie. /20 for startups etc. rather we self manage the policies (as we do now) as the NCC does but the IP blocks are allocated out of one very large block say a /11 in accordance with current assignment policy. A /11 i here you gasp, well a /11 is not an unreasonable size we have more than that now. If we knew now how big the network was to get then we probably would have created this sort of concept from day one, one thing we can be sure of its not going to shrink. Just think how much better all our routing tables would be if we could renumber into a single larger contiguous block, but we can not. This problem is not going to go away and IPV4 will be around for a while yet so rather than compounding the problem by continuing in this blinkered fashion of fragmenting large networks i think we should take this fresh look at the way the current admin structure is interfering with current network planning, with commercial impacts that brings. Looking a little into the future i think this structure would help with IPV6 too. The only differance is we know how big the networks are and what we need to create a well aggregated IPV6 network now with MIR's. Summary: Please do not look at this and close your mind because it does not affect your network it may do one day. From a purely community oriented spirit it is meant to try and improve overall aggregation, from a purely buiness point of view it makes sense to add another level of managment without complicating it but only for those who need it. RIR - Would still continue to admin the IP space for both MIR's and LIR's for the good of the community. MIR - Would manage the allocation (large ) from RIR and suballocate to LIR's aggregating the network correctly but be responsible to RIR for their actions LIR - Would assign space to infrastructure and customers as usual but would either be directly in contact with the NCC or via the MIR. I hope this does not cause too much controversie it is not my intention. Regards Stephen Burley UUNET EMEA Hostmaster SB855-RIPE

5 6

Re: new IPv6 policy framework
by Mirjam Kuehne 25 Sep '01

25 Sep '01

Niall, Niall Richard Murphy <niallm-ripe(a)enigma.ie> writes: * On Tue, Sep 25, 2001 at 09:11:17AM +0000, Mirjam Kuehne wrote: * * Hi Mir et al, * * Please below find my preliminary thoughts/comments on this document. * * [Aspirations preserved, so we can remember them later] * > - The allocation criteria should be such that it is easy to obtain * > IPv6 address space. * * > - The size of the initial allocation should be large enough to allow * > flexibility in addressing infrastructure and customer sites. * * > 1. to recognise existing infrastructure (both IPv4 and IPv6) where it * > exists and calculate IPv6 address needs based on existing networks. * * > 2. to apply the slow start mechanism only for 'IPv6 only' networks * > without existing IPv4 infrastructure * * > 3. to reduce the minimum allocation size for those IPv6 only networks * > (unless larger requirements are shown) * * > 4. to measure the utilisation rate with the HD ratio rather than * > percentages * * > 5. to make subsequent allocations when the HD ratio is reached * * > 3.1. Case 1 - Existing IPv4 services * * > Additional policies may require the return of IPv4 address space to * > the RIR or upstream ISP, in the case the existing network is * > renumbered to the new IPv6 space in future. * * Am I alone in wondering exactly what the scope of these additional policies * may be? My concern is based on the fact that although existing v4 networks * may well acquire v6 space, they are likely to need their v4 space for quite * some years to come, and hence it would be unrealistic to require the * return of all v4 address space. I agree with you that there will probably be a long transition period. The assumption however is that a network will at some stage be fully migrated to IPv6 and the IPv4 addresses will not be needed anymore. * * (Or maybe I misunderstand...) * * > 4. Size of Initial Allocation * * > For new networks without existing infrastructure, it is proposed to * > establish a minimum allocation for IPv6 address space. It is suggested * > to keep the size of the initial allocation relatively small (a /35 or * > smaller) and to determine the size of subsequent allocations based on * > the utilisation rate of the initial allocation (this is called slow * > start mechanism). This will allow easy access to IPv6 allocations for * > newcomers. At the same time possible wastage of address space and * > routing table growth will be limited. * * These v6 allocations are made from the RIR (ex TLA) space, correct? * yes. * So, are we abandoning the model where only the biggest networks go to * the RIRs for space, and everyone else goes to them? We learned that the old TLA/NLA/SLA boundaries were no technical requirements in the address format. In addition to that we know from experience that it is very difficult to define and verify what a transit ISP is. Therefore we propose to use a policy that treats all organisations equally. The RIRs cannot decide who is allowed to have a top level IPv6 allocation. The ISPs themselves have much better mechanisms to address routing table growth. Mirjam

4 3

Re: IPv4 and ASN Policy draft on-line
by Nurani Nimpuno 25 Sep '01

25 Sep '01

Hi Per, The following section describes the policy you describe in your mail. The second section (starting with "However, for services that are permanently connected...") addresses the change as described in Paula's mail from 1999: - - 5.1.9 Static assignments Due to constraints on the available free pool of IPv4 address space, the use of static IP address assignments (e.g., one address per customer) for dial-up users is strongly discouraged. Organisations considering the use of static IP address assignment are expected to investigate and implement dynamic assignment technologies whenever possible. If assignments for static assignments are indeed made, special verification procedures apply. However, for services that are permanently connected to the Internet, static one-to-one connections is considered acceptable. Verification of usage will in these cases take place when the LIR is requesting approval for additional assignments. Please contact the RIPE NCC for details on applicable verification methods. - - I hope this answered your question. However, if you feel that this text does not correctly reflect the actual policy, please join the editorial committee and we can work together on rewording it. Kind regards, Nurani Nimpuno RIPE NCC Per Lundberg <per(a)swip.net> writes: * Dear Nurani, * * Thanx for the update, though one question: * What happened to the "Permanently and Temporarily online" policy of '99 as * in Paulas mail to the list - * http://www.ripe.net/ripe/mail-archives/lir-wg/19990101-19990401/msg 00045.htm * l ? * * Seems to be missing in the new policy text. * * Kindly * Per * * On Fri, 21 Sep 2001, Nurani Nimpuno wrote: * * > Dear all, * > * > The first draft of the IPv4 and ASN policy document is now available * > on-line at: * > http://www.ripe.net/rs/ipv4policy.html * > * > It is available as html and can also be downloaded in .txt format. * > * > This document is currently under revision as an editorial team is * > being assembled to provide input on this draft. * > * > If you are interested in participating in the editorial team, please * > contact the LIR-WG chair, Hans-Petter Holen <hph(a)online.no> or * > indicate your interest on this list. * > * > Kind regards, * > * > Nurani Nimpuno * > RIPE NCC * > * > * > * > * * -- * Per * DNS/IP Registry * - - - - - - - - - Swedish IP Network - - - - - - - - - * Tele2AB/Swipnet e-mail: per(a)swip.net * Box 62 direct: +46 8 5626 4579 * 164 94 KISTA gsm: +46 704 26 4579 * Sweden fax: +46 8 5626 4210 * *

1 0

fwd: Re: IPv4 and ASN Policy draft on-line
by Wilfried Woeber, UniVie/ACOnet 25 Sep '01

25 Sep '01

Apologies, forgot to include lir-wg... ______________________________________________________________________ To: MX%"randy(a)psg.com" CC: WOEBER Subj: Re: IPv4 and ASN Policy draft on-line => there are valid cases where a (globally unique) AS# is required which => does not show up in the DFZ. = =please illustrate = =randy BGP peerings with ISP(s) _without_ (global) transit being offered by them. Only one path (the one with global connectivity/transit) would be visible. Wilfried.

1 0

Re: IPv4 and ASN Policy draft on-line
by Wilfried Woeber, UniVie/ACOnet 25 Sep '01

25 Sep '01

>> there are valid cases where a (globally unique) AS# is required which >> does not show up in the DFZ. (and, of course, there are places where a >> private AS# would do just as well). > Hmmm. I'm curious: could you name a few? The things that I could > imagine are "private peerings somewhere", which "should" work using > private AS#s just fine. BGP within _one_ administrative domain can (most probably in most cases) use private AS#s, and indeed we are using them in that situation. However when the peerings have to span policy/operations-coordination/ ISP boundaries, then private number space becomes unmanageable. Wilfried.

1 0

Re: IPv4 and ASN Policy draft on-line
by Wilfried Woeber, UniVie/ACOnet 25 Sep '01

25 Sep '01

>If I go the Oregon router server and look up their /19 and find only 1 >path to that /19 or I find that the ASN origin has disappeared and been >replaced by their upstream then there is no justification for getting an >ASN. > >> >> randy >> > >Hank Wrong. there are valid cases where a (globally unique) AS# is required which does not show up in the DFZ. (and, of course, there are places where a private AS# would do just as well). The bottom line is: how much are we (collectively) prepared to pay (in real money for RIR staff salaries, complexity, hassle and delay for *all* requests) in order to save a couple of AS numbers... -WW _________________________________:_____________________________________ 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

4 4

Where is the proposed revised IPv6 policy ?
by Dave Pratt 25 Sep '01

25 Sep '01

Hiya Folks, It is only a week now before the RIPE meeting at which it would be nice to agree on an improved policy for IPv6 allocations. Where is the proposed revised policy document ? Do the authors think that this policy should be developed without the partication of the LIR community ? I think we would all appreciate answers to the above questions as soon as possible. If the answer is "not enough time/resources", then I think we have an even stronger case for more involvement from the RIR members themselves. A cynic could argue that the proposed policy is so controversial that the authors wish to avoid debate - forcing the meeting into an accept it or leave it choice. This view is re-inforced since the authors were requested a month or so back to make the proposed revised policy available for comment. I would be keen to see which of the many positive and constructive suggestions have been incorporated in the policy. I would also expect to hear on the list *before* the meeting any reasons why specific suggestions for improvements were not included. The meeting is for agreeing the policy, not discussing the details of what should or should not be included. Cheers Dave BT Ignite GmbH

1 0

Antw: Re: Maintaining IPs in LIRs/Enterprise LIRs
by Wilson Mehringer 25 Sep '01

25 Sep '01

Hi, I share Yuval`s pedicament and would be very interested in an IP Management tool. Regards, Wilson Mehringer .............................................................. Cablecom GmbH Wilson Mehringer Zollstrasse 42 8021 Zürich Tel : 0041 1 277 91 61 Mobile : 079 238 27 68 E-mail : wilson.mehringer(a)cablecom.ch >>> David R Huberman <huberman(a)gblx.net> 09/24 11:11 pm >>> > I am currently in search for a tool which will help a LIR to maintain > its IP addresses - currently everything is listed inside an Excel file, > which is, IMHO, a very limited way of maintaining the lists. Global Crossing uses a complex but powerful home-grown IP database system which, when coupled with an interface for requesting address space, suffices for our needs. The database very cleanly aggregates and de-aggregates blocks on the fly, tracks user information and customer numbers, can prioritize and de-prioritize blocks for assignment, and can report utilization statistics on an as-requested basis. Everything is written in perl. If there is interest, we can publish these tools as freeware/open source for the RIPE LIR community to use. /david *--------------------------------* | Global Crossing API | | Manager, Global IP Addressing | | (703) 627-5800 | | huberman(a)gblx.net | *--------------------------------*

1 0

Re: Summary: Fixed Boundary (/29) Assignments
by Sabrina Waschke 24 Sep '01

24 Sep '01

Bruno Ciscato <bciscato(a)cisco.com> writes: * At 11:04 16/02/2001 +0100, Mirjam Kuehne wrote: * * >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. * * * What is the set of information necessary to justify these assignments ? * Does a big ISP have to justify in advance and for each residential customer * (10s a day) that the customer will use one address for the PC, one for the * oven, one for the security webcam, and so on and so forth? * Is there any other way that may make the process more efficient ? * * thanks a lot * * bruno * The LIR Working Group agreed that fixed Boundary (/29) Assignments should not be assigned to every customer by default as this implies a waste of addresses. However, LIRs are free to offer fixed boundary (/29) assignment to customers who request it. These assignments have to be based on need. The LIR has to justify all addresses in these networks to RIPE NCC with a list of the devices that will use these addresses, just like any other assignment. Regarding assignments for cable/xdsl customers: Initial assignment requests for cable and xDSL are usually judged on the basis of availability of the hardware. If an LIR has the hardware necessary for the first assignment then this is considered to be sufficient justification. Later assignment requests can use the same method, although it is then also possible to justify more addresses by showing the growth in customer base (sometimes bandwidth statistics are added as well to show the latest increases). For further details please write to <hostmaster(a)ripe.net> including the ticket number of your ongoing request, or contact <lir-help(a)ripe.net>. 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

1 0

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

OPS-NM interim meeting before RIPE-40
by Randy Bush 17 Sep '01

17 Sep '01

[ bert has asked me to repost ] Howdy, At the last two IETF OPS Area Open meetings, we had some good discussion between the OPS NM folk and some operators. We also have had a so called OPS-NM Interim in the USA that was co-located with NANOG in May of this year. We also called it something like: Net Management Protocol Folk & Net Operators - Reality Check #2 We will have another IETF Interim Meeting for the OPS-AREA Network Management people, this time in Europe, co-located with the next RIPE-NCC meeting. The idea is to meet with another set of operators to try and understand their needs and to explain to them how we think that our NM related work in the IETF can help them to manage their networks. In other words: Net Management Protocol Folk & Net Operators - Reality Check #3 We probably will have similar sessions in the future to meet with people who operate enterprise networks, because their requirements may be different. We are still working on the agenda, however below you will find a prelimenary agenda proposal. Any suggestions should be sent to Randy (randy(a)psg.com) and Bert (bwijnen(a)lucent.com) We have limited space for this meeting. Those who plan to attend, pls send a short email to Bert Wijnen <bwijnen(a)lucent.com> to let us know. Pls add a few lines as to why you want to participate. Discussion has been occurring since May on the mailing list ops-nm(a)ops.ietf.org, which is normal internet-style. And a web-based archive is at <http://ops.ietf.org/lists/ops-nm/>. Bert and Randy -------------- OPS-NM Interim Meeting details ------------------ The plan is to have this meeting co-located with the next RIPE NCC meeting, namely RIPE 40. That means: Oct 1st OPS-NM Interim from 2-5pm Oct 2nd OPS-NM Interim from 9am-noon Oct 2-5 RIPE 40. Starts at 2pm on oct 2nd. RIPE 40 and OPS-NM Interim will be in the Prague Congress Centre in Prague, Czech Republic. For RIPE 40 and hotel registration, pls visit: http://www.ripe.net/ripe/meetings/current/ripe-40/ There is a whole range of hotels to choose from, but it is very hard to book, so do it now. Those only participating in the OPS-NM meeting are not required to pay the RIPE meeting fee. Of course, if you want to take the opportunity to participate in the RIPE-NCC meeting, then you should register for that meeting via the web page listed above. Those who plan to attend the OPS-NM Interim should send an email to Bert Wijnen <bwijnen(a)lucent.com> because we only have limited room, and if too many people want to show up we may have to tell some that there is no more space. Prelimenary Agenda ------------------ - Agenda bashing and intro - Summary of the current set of OPS requirements draft-ops-operator-req-mgmt-00.txt Please read this document to prepare for the meeting. If this one no longer exists, then pls check for a possible revision 01.txt. It is important to try and figure out if this also represents needs of European operators, or do they have different/new/additional requirements? - Discussion of the above. - Discussion of SNMP, MIBs, COPS, POLICY and such - how do the developers of these protocols/specs think that they can address operator NM requirments. - what do operators think about that - what kind of positive or negative expoerience do operators have - Operator requirements - what are the real hot issues to be solved this year - what are the constraints within which the tools have to work - Next steps - Wrapup/Summary -30-

1 0

Re: on the question of 'right to maintainership'
by Daniel Karrenberg 17 Sep '01

17 Sep '01

[personal opinion, since I saw no replies yet and I think this deserves one] A LIR is responsible for the registration of address space assignments from address space allocations it receives from the RIPE NCC. From this alone it follows that a LIR may reserve the right to make changes to these registrations. Of course the LIR should be responsive to requests for changes. This does not mean that it has to make any change requested. Changes should be goverened by a local policy. Daniel PS: Technically speaking you can have multiple maintainers on an object that all have equal rights. So if you trust someone you can let them make their own changes while keeping the possibility to make changes yourself. The right notify options will make sure you know abut changes. Beware: Technically speaking one of these maintainers can remove the other, albeit not without the other noticing if notifications are configured right.

1 0

RE: NCC#2001039519 expecting reply X-NCC RegID: nl.ignite
by kevin.bates＠bt.com 14 Sep '01

14 Sep '01

Thanks to all for the advice, comments, suggestions. I've got the approval kevin > -----Original Message----- > > Greetings All > > Apologies to the large number of people who will receive this email > unnecessarily. But I have a problem getting a response from the Ripe > hostmaster re an ongoing address approval. > > I tried writing to lir-help(a)ripe.net but also with no response, see the > mail > attached. > The ticketing system shows I am expecting a reply. > > Is there anything else I can do to speed up the process (apart from > getting > on a plane to Amsterdam) as this is now getting to the critical stage? > > Is anybody else having this problem? > > any advice gratefully received > > thanks > > kevin bates > > > > -----Original Message----- > > From: Bates,KR,Kevin,IWO24 BATESKR R > > Sent: Tuesday, August 28, 2001 3:14 PM > > To: 'lir-help(a)ripe.net' > > Subject: NCC#2001039519 expecting reply X-NCC RegID: nl.ignite > > > > Greetings help > > > > On 31 July a hostmaster (Leo Vegoda) wrote to me re NCC#2001039519. > > ". > > . > > Thanks for providing all that detail. I've had a look at it does seem > > fine. Can you confirm which netname you want an approval for? I'll send > > you an approval straight away, then > > . > > ." > > > > > > I provided the netname the same day > > ". > > . > > network BT-ICH-AMS-UTR > > . > > ." > > > > On 14 August not having received a response, i mailed hostmaster asking > > what was happening. Got an acknowledgement but still no approval. > > > > > > As of today the i still haven't had any further communication from the > > hostmaster. > > Can you let me know what is happening and if i still need to supply more > > information and what information is required. > > > > thanks > > kevin > > > > > > > > > > > > > >

2 1

FW: NCC#2001039519 expecting reply X-NCC RegID: nl.ignite
by kevin.bates＠bt.com 14 Sep '01

14 Sep '01

Greetings All Apologies to the large number of people who will receive this email unnecessarily. But I have a problem getting a response from the Ripe hostmaster re an ongoing address approval. I tried writing to lir-help(a)ripe.net but also with no response, see the mail attached. The ticketing system shows I am expecting a reply. Is there anything else I can do to speed up the process (apart from getting on a plane to Amsterdam) as this is now getting to the critical stage? Is anybody else having this problem? any advice gratefully received thanks kevin bates > -----Original Message----- > From: Bates,KR,Kevin,IWO24 BATESKR R > Sent: Tuesday, August 28, 2001 3:14 PM > To: 'lir-help(a)ripe.net' > Subject: NCC#2001039519 expecting reply X-NCC RegID: nl.ignite > > Greetings help > > On 31 July a hostmaster (Leo Vegoda) wrote to me re NCC#2001039519. > ". > . > Thanks for providing all that detail. I've had a look at it does seem > fine. Can you confirm which netname you want an approval for? I'll send > you an approval straight away, then > . > ." > > > I provided the netname the same day > ". > . > network BT-ICH-AMS-UTR > . > ." > > On 14 August not having received a response, i mailed hostmaster asking > what was happening. Got an acknowledgement but still no approval. > > > As of today the i still haven't had any further communication from the > hostmaster. > Can you let me know what is happening and if i still need to supply more > information and what information is required. > > thanks > kevin > > > > > > >

2 1

RE: Draft: Charter & Call for paticipation RIPE-185bis
by paul.mylotte＠bt.com 11 Sep '01

11 Sep '01

Hans Petter I would be very happy to contribute and participate in the editorial team as soon as possible. Regards, Paul p.s I find it a bit difficult to follow the dates you give below P. S. Mylotte BTexact Technologies Adastral Park 01473 606333 / + 44 1473 606333 paul.mylotte(a)bt.com > -----Original Message----- > From: Hans Petter Holen [SMTP:hph@online.no] > Sent: 07 September 2001 22:56 > To: Hans Petter Holen; lir-wg > Cc: woeber; Gert Doering; azucena.hernandez; stephenb > Subject: Re: Draft: Charter & Call for paticipation RIPE-185bis > > | Please indicate your interest to participate in this editorial team to > me > or > | to the list. > > Up to date I have had the following voulenteers: > Wilfried Woeber > Gert Doering > Azucena Hernandez > Stephen Bruey > and Myself. > > | Please suggest improvements to the mandate to the list. > | > | Proposed mandate: > | > | Facilitate discussion on the lir-wg mailing list and working group > meetings > | and summarise the community consensus. > | Ensure that the community consensus on what IP addressing policies is to > be > | in the RIPE NCC service region is documented in a concise and simple > | language. > > I have had one suggestion to extend the mandate: > - Try to achieve allignemet between the IP addressing policies in the RIPE > NCC region and in the other regions to the maximum extent possible. > > | Proposed Timeline: > | > | 2208 Call for participation > | 2908 First draft to be published based on RIPE 185 discussion at > mailinglist > | 0509 Formation of the group, freeze mandate > | > | 1002 1st workshop > | 1003 discussion at lir-wg meeting > | 1004 2nd workshop > | > | 1015 Second draft to be published > | > | Note that this timeline is quite agressive, and that it suggests that we > do > | quite a bit of work at the upcoming RIPE meeting. I do however belive > that > | this timeline is relatively realistic. In my oppinion it is better to > revise > | this timeline. > > We are slightly behind the schedule, but there should still be ample time > to > read and comment on the draft recently posted by Nurani. > > --- > Hans Petter Holen, Technical Manager > Tiscali, Norway, +47 24 11 26 44 mobile: +47 99 21 76 70 fax:+47 24 11 24 > 11 >

2 1

draft agendas (v1) for IPv6/lir/eix joint sessions RIPE40
by David Kessens 11 Sep '01

11 Sep '01

Hi, Below follow the first drafts of the agendas for the joint sessions regarding ipv6 allocation policies. We have asked to schedule two seperate sessions, one for discussions regarding the new interim policy for exchange points, and one for discussions regarding the revision of the general allocation guidelines. We would like to limit discussion to the lir-wg maillist to minimize the amount of duplicate mails. Please let me know if you have any other topics that you want to have discussed and we will try to accomodate them in the agenda. Thanks, David K. --- Agenda for the IPv6/lir joint session RIPE40, Prague Topic: Revision of the general ipv6 allocation guidelines Materials to read: - ripe-196: http://www.ripe.net/ripe/docs/ipv6policy.html - http://www.ripe.net/ripe/meetings/archive/ripe-39/presentations/ipv6develop… - http://www.djp.net/ipv6/proposal.html - http://www.ripe.net/ripe/meetings/archive/ripe-39/presentations/RIPE39-IPv6… A. Administrative stuff - appointment of scribe - agenda bashing B. How to proceed for the next iteration of the policy. C. Status of the draft currently being discussed between the RIRs (Presentations from RIRs) D. Proposal for the next version of the policy http://www.djp.net/ipv6/proposal.html (Dave Pratt) E. Discussion Z. AOB ------------------------- Agenda for the IPv6/lir/eix joint session RIPE40, Prague Topic: Interim policy for allocation of ipv6 addresses for Internet Exchange Points A. Administrative stuff - appointment of scribe - agenda bashing B. How to proceed for the next iteration of the policy. C. Selection of most important issues that we want to discuss during this session: - how to proceed from the interim policy ?!? - default /64 or /48 allocation size - do we want to have this space allocated from a special block, may be even block that is used by all RIRs for this purpose - what documentation is needed to get an allocation - is there any need to document allocations in the RIPE database, and if so, how ?!? - general wording of the policy D. Discussion of the issues Z. AOB ---

1 0

RE: MIR proposal
by Wilfried Woeber, UniVie/ACOnet 10 Sep '01

10 Sep '01

Stephen, >Ok the proposal. 2 brief questions, the 2nd one might be pretty stupid, actually: 1) do I correctly read (between the lines) that you would be prepared to renumber into a properly sized new block? 2) would your IGP-problem, at least in theory, be solvable by braking the AS into a number of smaller ASs, say roughly along the lines of your address blocks per registry? Thanks, Wilfried

2 1

Exchange point interim policy
by David Kessens 10 Sep '01

10 Sep '01

The final date for comments on the proposed interim policy for ipv6 address allocations for Internet exchange points has passed. Since posting the interim conclusions, the direction of the discussion has not fundamentally changed. Therefore, we believe that we can ask the RIPE NCC to publish the proposed policy now, to clearly mark it as an interim policy and to start making the first allocations (with /64 allocations made out of fully reserved /48's and all allocations made out of one common block of address space). We would like to emphasize that this is the first version of the policy. It's pretty clear from the discussions on the list that though the policy is approved, there are still some issues that need more discussion. It looks like that many people felt that it was more important to get a policy in place rather sooner than later despite that they might not agree with all details in the policy. We have asked the RIPE NCC to reserve a slot at the next RIPE meeting to discuss the remaining issues and make recommendations to the RIPE NCC for improvements to the interim policy. Issues that we currently have on our list include: - how to proceed from the interim policy ?!? - default /64 or /48 allocation size - do we want to have this space allocated from a special block, may be even block that is used by all RIRs for this purpose - what documentation is needed to get an allocation - is there any need to document allocations in the RIPE database, and if so, how ?!? - general wording of the policy Don't hesitate to contact us if you want to have other issues discussed as well. For discussions on the maillist, we suggest that you post your mail only to the lir-wg list. Thanks, Fearghas McKay David Kessens EIX-WG Chair IPv6 wg Chair ---

1 0

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

RE: Interim Policy proposal for IPv6 Address Assignment Policy fo rInternet Exchange Points
by paul.mylotte＠bt.com 07 Sep '01

07 Sep '01

All, YES - and I am hoping that the WGs will reach consensus at the Prague meeting that the interim policy-based allocations will permit extension to a /48 allocation. Paul P. S. Mylotte IP Addressing & Naming 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 privileged 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. > -----Original Message----- > From: David R Huberman [SMTP:huberman@gblx.net] > Sent: 04 September 2001 17:57 > To: lir-wg(a)ripe.net; eix-wg(a)ripe.net; ipv6-wg(a)ripe.net > Subject: Re: Interim Policy proposal for IPv6 Address Assignment > Policy forInternet Exchange Points > > > So I ask: > > > > In lieu of any other policy changes, are you, as a RIPE member and > > participant in the LIR, EIX, and IPv6 WGs, in favor of the interim > policy > > proposal for IPv6 address assignment policy for internet exchange > points? > > To answer my own question, I support the interim policy proposal and hope > it is ratified by the WGs as soon as possible. > > /david

3 2

Index of lir-wg on Altavista
by Bernard Steiner 07 Sep '01

07 Sep '01

Folks, considering the fact that I have started receiving UCEs to my e-mail address at work, would anybody out there point out to me the advantages of having altavista index the lir-wg archive (amongst other things) ? Fed up with UCEs for today, Bernard

1 0

Re: Interim Policy proposal for IPv6 Address Assignment Policy for Internet Exchange Points
by Wilfried Woeber, UniVie/ACOnet 06 Sep '01

06 Sep '01

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 editorial: the term "desirable" is much too weak. This can set a precedent for other (presumably) special cases/groups/applications to request similar treatment. IŽd propose something like feasable or acceptable. 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. editorial: as suggested by others, the additional paragraph explaining the "regular" paths (RFC/6Bone or regular ISP application) might go in here. 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). This is both too restrictive (from a technology point of view), as well as too blurry: - there might be cases for an IPv6 exchange point which starts on or operates on an existing (layer2 or 3) fabric. Tunnels in v4 or a multicast-enabled v4 net used as a layer 2 tech for v6 spring to my mind. - the use of "Should" seemms to be odd in a policy definition - I would not be able to judge what an "open policy for others to join" would look like as a minimum 4. Policy --------- I think 3. and 4. should be swapped. 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.

1 0

Re: Interim Policy proposal for IPv6 Address Assignment Policy forInternet Exchange Points
by Wilfried Woeber, UniVie/ACOnet 06 Sep '01

06 Sep '01

>The chairs put forth this interim policy proposal to these lists hoping to >garner consensus or judge that consensus does not exist. > >The ensuing discussion, while not unuseful, does not appear (to me) to be >helping the chairs and the wg membership from gauging the extent to which >there is consensus for this interim policy proposal. > >So I ask: I think it was your intent to separate discussion/improvement from "tallying" pro.s and com.s - so IŽll summarize my comments in a separate message... >In lieu of any other policy changes, are you, as a RIPE member and >participant in the LIR, EIX, and IPv6 WGs, in favor of the interim policy >proposal for IPv6 address assignment policy for internet exchange points? YES. >/david 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

101 IPv6 allocations made globally
by Nurani Nimpuno 06 Sep '01

06 Sep '01

Dear all, This is to inform you that in the last days, the RIRs last week reached a total of 101 /35 (SubTLA) allocations globally. According to the global "Provisional IPv6 Assignment and Allocation Policy Document" [1], the bootstrap phase with interim criteria apply until 100 allocations have been made globally or 60 allocations in one RIR region (4.2.2.1. Duration of Bootstrap Phase). However, at last RIPE meeting (RIPE 39, May, Bologna), it was agreed to further extend the bootstrap phase. The end of the extended bootstrap phase will be discussed and defined at the upcoming RIPE 40 meeting in October. Per region, the following amount of allocations have been made: APNIC: 38 ARIN: 20 RIPE NCC: 43 A list of all IPv6 allocations made globally can be found at: http://www.ripe.net/cgi-bin/ipv6allocs Kind regards, Nurani Nimpuno *--------------------------------------------------------* | Nurani Nimpuno <nurani(a)ripe.net> | | Internet Address Policy Manager | | RIPE Network Co-ordination Centre | | http://www.ripe.net | *--------------------------------------------------------* [1] http://www.ripe.net/ripe/docs/ipv6policy.html

1 0

Re: Interim Policy proposal for IPv6 Address Assignment Policy for Internet Exchange Points
by Henk Steenman 06 Sep '01

06 Sep '01

At 07:19 PM 9/3/2001, Randy Bush wrote: > >> What I believe is needed is an allocation for IXP service networks as well > >> as for the IX mesh, which is globally routable. I'd like to propose this > >> alongside the existing proposal we have on the table. > > I agree with you Mike, I think this is the only way an IXP can show its > > independence from any one of its members (connected ISPs, carriers or > > whatever) > >s/ixp/small isp/ > >i.e. the small isps want to appear independed from their upstream(s). >the discussion over this has been going on nigh a decade. so what makes >an ixp's business so special they warrant special treatment? I believe there is a difference, An IXP is a facilitating infrastructure delivering services to all ISPs connected or to be connected. Linkage in any way to one or more of its members might harm the neutrality of the exchange towards its other members. For AMS-IX: > AMS-IX is a non-profit, neutral and independent association, meaning > that it has no bias as to who connects For LINX > A neutral, not-for-profit partnership between Internet Service Providers > globally, LINX provides a physical interconnection for its members to > exchange Internet traffic through co-operative peering agreements I believe that in both cases "neutral" and "no bias to.." will be harmed if IXP address space (in any way, for the exchange infrastructure as well as for the services infrastructure like web server, e-mail etc) is related to a limited set of its customers. - Henk

14 29

Interim summary of current discussions
by David Kessens 05 Sep '01

05 Sep '01

Hi, The proposed interim policy was proposed to go into effect on the 7th september 2001. Since this date is getting closer, we would like to summarize the discussion so far. - comments from exchange point operators: In order to be neutral, they need independant address space for the services that they offer besides the addresses used for setting up peering relationships. - many comments that they can apply for regular address space, just like anybody else - many comments that it is too hard to get regular address space - we didn't see too many comments about the policy itself, until David Huberman asked the community: In lieu of any other policy changes, are you, as a RIPE member and participant in the LIR, EIX, and IPv6 WGs, in favor of the interim policy proposal for IPv6 address assignment policy for internet exchange points? - quite some people reacted and responded with a 'yes' - few comments were send earlier to the list that a policy might not be needed at all - several different proposals were sent to make it easier to get sTLA address space (which can be used by exchange points too) - most want to relax the current rules in some way or the other - people are worried about easier rules for special interest groups (eg. IXPs, small or big providers) - one completely different proposal was submitted that proposed to allocate a sTLA to exchange point operators which can be used to assign address space to customers - worry was expressed that the interim policy will not be as interim as suggested At this point, it looks like that the community is supportive of the interim policy but that there are still issues regarding address space needs other than for the exchange points customer peering sessions. These issues are not really part of the discussion regarding the interim policy but seems part of a grander discussion regarding the revision of allocation guidelines for ipv6 address space. We should be able to get progress on this topic on the next RIPE meeting (and on the mailing list before that). We appreciate all the input that we have had so far and we continue to encourage you to let your opinion known. Thanks, Fearghas McKay David Kessens EIX-WG Chair IPv6 wg Chair ---

3 2

Re: Interim Policy proposal for IPv6 Address Assignment Policy for Internet Exchange Points
by Chris Fletcher 05 Sep '01

05 Sep '01

One of the points that has been raised a couple of times is... There is a lot of IPv6 address space - why not just give IXP's a sub TLA. The argument against this seems to be - if IXP's are treated as a special case then there is a precedent for every other 'special case' to justify their case. ... but there is still *lots* [1] of address space so why not give everyone who wants one a sub TLA? AIUI the reason for restricting who gets sub TLAs is... In the current IPv4 world (multiprovider) multihomed customers have their own address space and AS number this fills the default-free routing table and won't scale. In IPv6, addressing is hierarchical and multihomed customers have multiple addresses, this keeps the default-free routing table small and scalable. If everyone (multihomed customers) gets a sub TLA then the default-free routing table fills up with multihomed customer sub TLAs and IPv6 routing tables are as cluttered and unscalable as IPv4. Is this the issue? If not, why not give out sub TLAs to all who want them? Chris - LINX [1] There are 2^32 (~ 4,000,000,000) /35s available... +--+-----+-----+---+-----+------+------------------+ |-3|--13-|--13-|-6-|--13-|--16--|------64 bits-----| +--+-----+-----+---+-----+------+------------------+ |FP|-TLA-|-sub-|Res|-NLA-|--SLA-|---Interface ID---| |--|-ID--|-TLA-|---|--ID-|--ID--|------------------| +--+-----+-----+---+-----+------+------------------+

5 5

OPS-NM interim meeting before RIPE-40
by Randy Bush 04 Sep '01

04 Sep '01

Howdy, At the last two IETF OPS Area Open meetings, we had some good discussion between the OPS NM folk and some operators. We also have had a so called OPS-NM Interim in the USA that was co-located with NANOG in May of this year. We also called it something like: Net Management Protocol Folk & Net Operators - Reality Check #2 We will have another IETF Interim Meeting for the OPS-AREA Network Management people, this time in Europe, co-located with the next RIPE-NCC meeting. The idea is to meet with another set of operators to try and understand their needs and to explain to them how we think that our NM related work in the IETF can help them to manage their networks. In other words: Net Management Protocol Folk & Net Operators - Reality Check #3 We probably will have similar sessions in the future to meet with people who operate enterprise networks, because their requirements may be different. We are still working on the agenda, however below you will find a prelimenary agenda proposal. Any suggestions should be sent to Randy (randy(a)psg.com) and Bert (bwijnen(a)lucent.com) We have limited space for this meeting. Those who plan to attend, pls send a short email to Bert Wijnen <bwijnen(a)lucent.com> to let us know. Pls add a few lines as to why you want to participate. Discussion has been occurring since May on the mailing list ops-nm(a)ops.ietf.org, which is normal internet-style. And a web-based archive is at <http://ops.ietf.org/lists/ops-nm/>. Bert and Ern^H^H^HRandy -------------- OPS-NM Interim Meeting details ------------------ The plan is to have this meeting co-located with the next RIPE NCC meeting, namely RIPE 40. That means: Oct 1st OPS-NM Interim from 2-5pm Oct 2nd OPS-NM Interim from 9am-noon Oct 2-5 RIPE 40. Starts at 2pm on oct 2nd. RIPE 40 and OPS-NM Interim will be in the Prague Congress Centre in Prague, Czech Republic. For RIPE 40 and hotel registration, pls visit: http://www.ripe.net/ripe/meetings/current/ripe-40/ There is a whole range of hotels to choose from, but it is very hard to book, so do it now. Those only participating in the OPS-NM meeting are not required to pay the RIPE meeting fee. Of course, if you want to take the opportunity to participate in the RIPE-NCC meeting, then you should register for that meeting via the web page listed above. Those who plan to attend the OPS-NM Interim should send an email to Bert Wijnen <bwijnen(a)lucent.com> because we only have limited room, and if too many people want to show up we may have to tell some that there is no more space. Prelimenary Agenda ------------------ - Agenda bashing and intro - Summary of the current set of OPS requirements draft-ops-operator-req-mgmt-00.txt Please read this document to prepare for the meeting. If this one no longer exists, then pls check for a possible revision 01.txt. It is important to try and figure out if this also represents needs of European operators, or do they have different/new/additional requirements? - Discussion of the above. - Discussion of SNMP, MIBs, COPS, POLICY and such - how do the developers of these protocols/specs think that they can address operator NM requirments. - what do operators think about that - what kind of positive or negative expoerience do operators have - Operator requirements - what are the real hot issues to be solved this year - what are the constraints within which the tools have to work - Next steps - Wrapup/Summary -30-

1 0

RE: Interim Policy proposal for IPv6 Address Assignment Policy fo r Internet Exchange Points
by paul.mylotte＠bt.com 03 Sep '01

03 Sep '01

I totally agree with Mike in his comments below, and those from Dave Pratt in a previous email. Some time ago I sent the following proposal to the list, and I would like to point out, again, that address space is already allocated for this and is clearly specified in RFCs. The proposal was: At the RIPE 39 joint meeting it was clarified that we should cater for the support of both types of IPv6 exchanges, viz: (i) allocate addresses for IPv6 exchange infrastructure only (no onwards allocation in the manner of a backbone ISP). (ii) 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). extract from RFC2928 Section3 Initial IPv6 Sub-TLA ID Assignments ... ..The block of Sub-TLA IDs assigned to the IANA (i.e., 2001:0000::/29 - 2001:01F8::/29) is for assignment for testing and experimental usage to support activities such as the 6bone, and for new approaches like exchanges. 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. Could we please add this proposal to what is already on the table. Regards, Paul P. S. Mylotte IP Addressing & Naming 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 privileged 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. > -----Original Message----- > From: Mike Hughes [SMTP:mike@linx.net] > Sent: 03 September 2001 11:19 > To: lir-wg(a)ripe.net > Cc: eix-wg(a)ripe.net; ipv6-wg(a)ripe.net > Subject: Re: Interim Policy proposal for IPv6 Address Assignment > Policy for Internet Exchange Points > > On Fri, 31 Aug 2001, Dave Pratt wrote: > > > Unfortunately, I must respond against the proposal as it stands with use > of a > > /64 allocation. > > If the proposal for the /64 allocation for the IXP mesh is "it" - i.e. > this will be the only address space allocated to an IX, period - then I > find it hard to be in full agreement with this proposal. > > The LINX is currently an RIR in it's own right, with a /19 of PA space > delegated to it. This is diced up to provide addresses for the IXP meshes > at LINX (both Unicast and Multicast), for LINX's own public-facing and > member services, and some space is delegated for essential services LINX > hosts (such as nic.uk). > > LINX peers with all it's members, and announces this /19 to them - this > means that members have direct, independant connectivity to the LINX > services. We also have a handful of transit ISPs (a small subset of > members, but over independant media) to fill in the gaps, and make sure > we're still online if there is an exchange problem. > > If v6 addresses for an IXP's member services have to be delegated from an > upstream provider, this makes the exchange dependant on that provider. If > that provider has problems, or ceases trading, that could have serious > impacts on the business continuity of the exchange, for it's > member/participant community, and possibly other members of the RIPE > community. > > Please don't say IPv6 address-based multihoming to me. It's not ready > for primetime IMHO. > > What I believe is needed is an allocation for IXP service networks as well > as for the IX mesh, which is globally routable. I'd like to propose this > alongside the existing proposal we have on the table. > > Comments? > > Mike > -- > Mike Hughes Network Architect London Internet Exchange > mike(a)linx.net http://www.linx.net/ > "Only one thing in life is certain: init is Process #1" >

2 1

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