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

Revision of IPv4 policy draft document
by Nurani Nimpuno 03 Oct '01

03 Oct '01

Dear all, To facilitate the revision of the IPv4 policy draft document, the following mailing list has been set up: <ripe-185bis(a)ripe.net> is a mailing list set up for the participants of the editorial committee of this document, but is also a publicly open mailing list, archived at: http://www.ripe.net/ripe/mail-archives/ripe-185bis/index.html (Available from the LIR-WG website: http://www.ripe.net/ripe/wg/lir/index.html) If you wish to subscribe to this mailing list, please send a mail to <majordomo(a)ripe.net> with "subscribe ripe-185(a)ripe.net" (without quotation marks) in the body of the message. Additionally, a physical meeting will made possible this evening in Prague for any parties interested in participating in the editorial committee. It will take place after (during? :) the RIPE Meeting social event at the Marriott hotel in Prague. A meeting room "Bohemia" is reserved for discussing this document and to agree on the coming steps in the revision process. - All interested parties are welcome to bring their drinks from the social with them. :-) Kind regards, Nurani Nimpuno RIPE NCC

1 0

Chairing LIR-WG Wednesday 3 October
by Denesh Bhabuta 03 Oct '01

03 Oct '01

Dear members I have been informed by Mirjam that Hans Petter is unlikely to make it to the RIPE meeting this time due to things out of his control (Swiss Air, etc) In addition, James Aldridge is not here. It is thus very likely that I will be helping by chairing the meeting tomorrow. If you have any issues you wish me to be aware of, or wish to discuss anything, please do not hesitate to approach me - and in case you do not know what I look like: http://photos.jml.net/photo.php?id=37633 Regards Denesh -- Denesh Bhabuta

1 0

Updated agendas and times of the joint policy sessions
by David Kessens 02 Oct '01

02 Oct '01

Hi, The meeting schedule indicates that the joint lir/ipv6 wg session is starting at 14:00, wednesday, October 3rd. However, as mentioned earlier in the agenda itself, the joint lir/ipv6 session will start at 16:00 and the lir wg will use the the time from 14:00 - 15:30. Also, the agenda has been modified slightly. The new ipv6 draft policy document is published now and Mirjam will give an outline presentation regarding the new draft. I hope this helps, David K. --- Agenda for the IPv6/lir joint session RIPE40, Prague Wednesday October 3rd, 2001, 16:00 - 17:30 Topic: Revision of the general ipv6 allocation guidelines Materials to read: - ripe-196: http://www.ripe.net/ripe/docs/ipv6policy.html - 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. Proposal for the next version of the policy http://www.djp.net/ipv6/proposal.html (Dave Pratt) D. RIR IPv6 Address Policy Proposal - Outline (Mirjam) - Results of the proposal discussion at the last APNIC meeting Takashi Arano (JPNIC/Asia Global Crossing) Gerard Ross (APNIC) E. Discussion Z. AOB ------------------------- Agenda for the IPv6/lir/eix joint session RIPE40, Prague Thursday October 4th, 2001, 11:00 - 12:30 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 (Mirjam will present these issues) D. Discussion of the issues Z. AOB ---

1 0

New Document available: RIPE-228
by RIPE NCC Document Announcement Service 02 Oct '01

02 Oct '01

New RIPE Document Announcement -------------------------------------- A new document is available from the RIPE document store. Ref: ripe-228 Title: Supporting Notes for the RIPE NCC Autonomous System Number Request Form Author: Nurani Nimpuno, Sabrina Waschke Date: 2 October 2001 Format: PS=34002 TXT=15144 Obsoletes: ripe-147 Obsoleted by: Updates: Updated by: Short content description ------------------------- This document provides supporting notes to the Autonomous System Number Request Form. It contains instructions on how to complete the request form for AS Numbers, in the RIPE document: "RIPE NCC Autonomous System Number Request Form" Accessing the RIPE document store --------------------------------- The RIPE document store is available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs. The URLs for the new documents on the FTP-server are: ftp://ftp.ripe.net/ripe/docs/ripe-228.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-228.txt plain text version You can also access the RIPE documents in HTML format via WWW. RIPE-228 available from the WWW at the following URL: http://www.ripe.net/docs/asnsupport.html

1 0

New Document available: RIPE-227
by RIPE NCC Document Announcement Service 02 Oct '01

02 Oct '01

New RIPE Document Announcement -------------------------------------- A new document is available from the RIPE document store. Ref: ripe-227 Title: RIPE NCC Autonomous System Number Request Form Author: Nurani Nimpuno, Sabrina Waschke Date: 2 October 2001 Format: PS=13173 TXT=3140 Obsoletes: ripe-147 Obsoleted by: Updates: Updated by: Short content description ------------------------- This document contains the set of templates to be used by Local Internet Registries when requesting an Autonomous System (AS) Number from the RIPE NCC. Accessing the RIPE document store --------------------------------- The RIPE document store is available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs. The URLs for the new documents on the FTP-server are: ftp://ftp.ripe.net/ripe/docs/ripe-227.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-227.txt plain text version You can also access the RIPE documents in HTML format via WWW. RIPE-227 is available from the WWW at the following URL: http://www.ripe.net/docs/asnrequestform.html

1 0

Re: [hostmaster-staff] Re: MIR proposal / reservation revisited?
by Wilfried Woeber, UniVie/ACOnet 02 Oct '01

02 Oct '01

>PS To answer Wilfreds question, it is not reservation revisited it is >aggregation revisited ;) Stephen, in my opinion (from a technical persepctive only), there are two ways of attacking the problem: - 1) to clean up the legacy routes, you have to re-number (which I guess can be done within your address pool(s) - 2) to prevent it from happening again, someone, soemwhere, has to reserve a "big" block of addresses which would support a) additional demand by existing customers, and b) aggregation according to your network's internal structure Item 2) is where my notion of "reservation" is coming from. Do I still get it (completely) wrong? Btw, doing only one of those two is probably not going to work... Wilfried.

2 1

Mail Loop
by Mally Mclane 01 Oct '01

01 Oct '01

Colleagues, We are aware of the mail loop on lir-wg and currently working to fix it. Apologies for the inconvenience and disruption, normal service will be resumed shortly. Regards, Mally Mclane RIPE NCC Operations

1 0

Re: [hostmaster-staff] Re: MIR proposal
by Wilfried Woeber, UniVie/ACOnet 01 Oct '01

01 Oct '01

>Although both RIRs such as RIPE and LIRs such as myself are subject to 80% >rules for the acquisition of more IP space, it seems we are subject to >different 80% rules. > >For an RIR, it is 80% of their allocations, and for the LIRs it is 80% of >assigned space. Where is the big difference - both registries have given away the blocks of addresses to their down-stream entity/ies? And given the current rules forbidding reservations, any sort of "post-factum" aggregation can only be achieved by a renumbering mechanism. Btw, a more liberal way of interpreting the 80 percent rule might be looking at all the address space that is managed(*) by a particular LIR, and not only the currently "open" allocation(s). Wilfried. *) "managed" to be discussed/defined... _________________________________:_____________________________________ 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

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