- lir-wg - mailman.ripe.net

Draft: IPv4 Sub-allocations - revisited
by Sascha Lenz 24 Jan '03

24 Jan '03

Hay, even though i hope that everyone already noticed it, i didn't see any comments about it on any list yet: in "3.0 Database registration" the draft states: [...] 3.1 Status attribute for inetnums representing sub-allocations Registration of a sub-allocation in the RIPE Database requires the creation of an inetnum object with an appropriate status value. 3.2 Restriction on creation of inetnums with an .ASSIGNED. status The creation of an inetnum object with a status of .ASSIGNED PA. or .ASSIGNED PI. will not be allowed if there is either a less specific or more specific inetnum object with an .ASSIGNED. status. The assigned status inetnum is the most specific registration allowed. [...] ...just that it seems to lack the information _what_ status value is appropriate for a sub-allocation then. One might guess that "LIR-PARTITIONED [PA|PI]" could be meant, but it also might be something completely different or even some new value since the current ripe-239 doesn't really cover the usage the sub-allocation draft suggest (5.0 in ripe-239 "IP Address Policy Implications"). ...just my 0.02EUR -- ========================================================================== = Sascha 'master' Lenz SLZ-RIPE slz(a)baycix.de = = NOC BayCIX GmbH = = http://www.noc.baycix.de/ * PGP public Key on demand * = ==========================================================================

3 5

draft-documents: sub-allocations.html
by Christoph Mohr 23 Jan '03

23 Jan '03

Dear Colleagues! Referring to http://www.ripe.net/ripe/draft-documents/sub-allocations.html, I found a problem which maybe will arise after publishing the document. In 3.2 Restriction on creation of inetnums with an "ASSIGNED" status I read: The creation of an inetnum object with a status of "ASSIGNED PA" or "ASSIGNED PI" will not be allowed if there is either a less specific or more specific inetnum object with an "ASSIGNED" status. The assigned status inetnum is the most specific registration allowed. Now the question I have is if this will apply to all inetnum objects which are already in the database. We, the Academic Network of the Federal State of Baden-Wuerttemberg (BELWUE), manage the internet not only for the universities in Baden-Wuerttemberg, but as well for many public schools. To provide public schools with internet addresses, we are allowed by the universities to use some of the addresses in their own class B network they don't need. (I think there won't be one university which currently uses all their IPv4 addresses in its B block.) So we are able to economise IPv4 resources by using IP addresses which wouldn't be used otherwise. That's why there are overlapping inetnum objects which are both "ASSIGNED PI", which will be forbidden in the future if I understand well the new document. Example: Within 132.230/16 which is FDN (Freiburg University) one can find 132.230.194.0 - 132.230.196.255 (BELWUE-SCHULEN) which are IP addresses of public schools in the Freiburg region. We prefer to have this inetnum object because we don't want the university to deal with abuse mails which may occur because there isn't always specialised staff in the schools to manage firewalls, mailservers etc. correctly. When there is an abuse incident we are able to react quickly by contacting the respective school. We made yet the experience that these entries in the database were very useful. Well, perhaps I misunderstood the draft document and there won't be any problems like the one I mentioned. Anyway, there should be some clarification about the objects the database won't allow to create in the future. Best regards, Christoph Mohr -- -- Christoph Mohr, BelWue Coordination ---------- mailto:mohr@belwue.de ----- Computing Center University of Stuttgart (RUS) Phone: +49 711 685-2079 Allmandring 30, D-70550 Stuttgart Fax: +49 711 678-8363 ------------------------------------------------- http://www.belwue.de/ -----

4 7

New Documents available: RIPE-263, RIPE-267
by RIPE NCC Document Announcement Service 22 Jan '03

22 Jan '03

New RIPE Documents Announcement -------------------------------------- Two new documents are available from the RIPE document store. Ref: ripe-263 Title: Autonomous System (AS) Number Assignment Policies and Procedures Author: Mirjam Kuehne, Nurani Nimpuno, Sabrina Wilmot Date: 22 January 2003 Format: PS=16292 TXT=6248 Obsoletes: ripe-185, ripe-245 Obsoleted by: Updates: Updated by: Ref: ripe-267 Title: IPv6 Address Allocation and Assignment Policy Author: ARIN, APNIC, RIPE NCC Date: 22 January 2003 Format: PS=816883 TXT=34295 Obsoletes: ripe-196, ripe-246 Obsoleted by: Updates: Updated by: Short content description ------------------------- The "Autonomous System (AS) Number Assignment Policies and Procedures" provides a description of Autonomous System Numbers, their assignment procedures and guidelines on how to obtain them in RIPE NCC service region. "Assignments for Internet Experiments" has been included in this latest version. The "IPv6 Address Allocation and Assignment Policy" defines registry policies for the assignment and allocation of globally unique IPv6 addresses to Internet Service Providers (ISPs) and other organisations. "Assignments for Internet Experiments" has been included in this latest version. Accessing the RIPE document store --------------------------------- You can access the RIPE documents in HTML format via our website at the following URLs:. http://www.ripe.net/ripe/docs/asn-assignment.html http://www.ripe.net/ripe/docs/ipv6policy.html The RIPE Document Store is also available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs. The URLs for the new documents on the FTP-server are: ftp://ftp.ripe.net/ripe/docs/ripe-263.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-263.txt plain text version ftp://ftp.ripe.net/ripe/docs/ripe-267.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-267.txt plain text version

1 0

Registration Services: Summary 2002
by leo vegoda 20 Jan '03

20 Jan '03

Dear Colleagues, Over 2002 the RIPE NCC has worked to improve the quality of Registration Services. Notable improvements, additions and changes include: - Response times to new tickets have improved dramatically, being answered within one working day. Since September the time taken to a first response has never risen above two working days. This is despite a record high number of tickets being received in October 2002. - The LIR WG approved new policy documents. The new structure makes documents easier to read and maintain. We will continue efforts to make policy documents clearer. - The common IPv6 policy has been implemented and we have made 76 new allocations under it. - The LIR WG reviewed the ASN assignment policy immediately before and during RIPE 43 in Rhodes. No major changes were made. - The RIPE NCC worked with Gert Döring to analyse issues that need to be addressed in a proposal for a sub-allocation policy. Gert's proposal was accepted and a draft document is now under review by the LIR WG. <http://www.ripe.net/ripe/draft-documents/sub-allocations.html> - New LIRs can now take up membership much faster than in the past. The procedure has been streamlined and better documented. - Attendees at RIPE 43 in Rhodes have tested a new way to access RIPE NCC services. The "LIR Portal" was launched today as an official service and is accessible to all members. - A policy allowing temporary assignments of Internet resources for Internet experiments has been implemented. The policy wording will be incorporated into the IPv4, IPv6 and ASN policy documents. This is in addition to the existing procedure for temporary assignments to conferences and trade fairs. - We have completed the transfer of ASN registrations from the ARIN Database to the RIPE Database and have run a trial for the transfer of IPv4 registrations. In addition to this work we have plans to improve the quality of the RIPE NCC's Registration Services over 2003: - The "Hostmaster Robot" will be replaced with a new system that will handle a revised set of simpler forms. - We are reviewing the status attribute values for inetnum objects in the RIPE Database. - An improved tool to replace "asused_public" will be released soon. - A formal explanation of the system used to determine Assignment Windows will be published. - Customer service will be improved by having Hostmasters call customers to resolve difficult or complex requests more quickly. Kind regards, -- leo vegoda RIPE NCC Registration Services

2 1

Results of RIPE NCC 2002 Membership Survey
by Axel Pawlik 20 Jan '03

20 Jan '03

Dear Colleagues, As you are aware, the RIPE NCC commissioned KPMG to carry out a members and stakeholders survey on its behalf from 29 August to 31 October 2002. The focus of the survey was to give the membership and stakeholders a formal opportunity to voice opinions on the services provided by the RIPE NCC, and to give constructive input needed to plan services for the future. The survey included e-mailed responses and face-to-face meetings. There were a total of 285 respondents. The results of the survey, in full and abridged versions, are now available and can be found at: http://ripe.net/survey2002/results/ I wish to thank the members of the community who provided valuable feedback. I look forward to discussing the survey and results at the upcoming RIPE Meeting here in Amsterdam next week during Thursday's plenary session. I also wish to thank KPMG for conducting a professional and insightful analysis of our membership. Regards, Axel Pawlik RIPE NCC

1 0

New service: The RIPE NCC LIR Portal
by Axel Pawlik 20 Jan '03

20 Jan '03

Dear Colleagues, The RIPE NCC announces the release of the RIPE NCC LIR Portal. This new service will help reduce delays by providing LIRs increased access to the RIPE NCC via a web interface. The beta testing of this service started at RIPE 43 in September 2002. In addition to managing registry data, LIRs will be able to make other queries and updates without going through the RIPE NCC staff. Once the user is authenticated to the system, they will be able to access LIR specific resources and all information exchanged will be encrypted to ensure security. Features of the RIPE NCC LIR Portal include: - viewing and editing of LIR contact and address information - viewing of billing information - viewing of IP and AS resources - viewing status of open tickets - news and events To activate your account, please follow the procedure found at: https://lirportal.ripe.net/lirportal/activation/activation_request.html Or you can activate your account at the Hostmaster Centre at RIPE 44 with a photo ID. Any problems or suggestions can also be shared at the Hostmaster Centre. New features of the portal will be added based on response from the community. We welcome feedback on this new service. Comments can be sent to <lirportal-feedback(a)ripe.net>. Regards, Axel Pawlik RIPE NCC

1 0

Updated proposal for clean-up of references by name
by Engin Gunduz 16 Jan '03

16 Jan '03

[Apologies for duplicate messages] Dear Colleagues, I'm attaching the updated proposal for automatically cleaning up the references by name in RIPE Whois Database. We have incorporated Janos's suggestions to the proposal. If no more comments come, we plan to apply the procedure described in the proposal in the first half of January, 2003. The operation should not take more than a day. We will notify the community about the actual date of the operation. Regards, Engin Gunduz ____________________________ RIPE NCC Database Group -------------- Proposed solution for cleaning up references by name and other invalid references in RIPE Whois Database Motivation: References by name and invalid references cause two main problems: 1. One reference by name in a single object locks all person and role objects with that name, that is, they cannot be deleted, because of referential integrity checks. 2. Having anything other than a NIC handle as a reference makes the implementation of whois database software considerably more complex, since the software needs to deal with these exceptions. This increases the coding time, maintenance time and testing time of the software. Classification of the inconsistencies we need to solve and proposed solutions: 1. Objects that refer to a person or role object by name. a. There is only one object with this name. 1. The referring inconsistent object is not maintained, or the maintainers of referring inconsistent object and the person/role object with this name are the same. Solution: Update the referring inconsistent object so that it will contain the NIC handle instead of the name. Add appropriate remarks and changed attributes to the object to explain the reason for update. 2. The referring object is maintained, and the maintainers are different from the maintainers of the object with the referred name (If the latter object is not maintained, then the maintainers are by definition different.) Solution: Create a role object with this name. It will list the role or person object with this name in its admin-c and tech-c attributes. Update the inconsistent object to refer to the NIC handle of this new role object. Add appropriate remarks and changed attributes to the object to explain the reason for update. b. There is no person or role object with this name: Solution: Create a person object with this name. Clearly mark this new object putting appropriate remarks attributes so that users will see it is actually a dummy object. Update the inconsistent object to refer to the NIC handle of this new person object. Add appropriate remarks and changed attributes to the object to explain the reason for update. Protect it with the inconsistent object's maintainer(s). c. There are multiple person and role objects with this name. Solution: Create a role object with this name. It will list all the other role and person objects with the same name in its admin-c and tech-c attributes. Update the inconsistent object to refer to the NIC handle of this new role object. Add appropriate remarks and changed attributes to the object to explain the reason for update. 2. Objects that refer to a non-existent NIC handle. Solution: Create a person object with that NIC handle. Clearly mark this new object so that users will see it is actually a dummy object. Name it "person: Place Holder Object". Protect it with the inconsistent object's maintainer(s). Note that there is no need to update the inconsistent object itself. 3. Objects that refer to a string which is neither a name, nor a NIC handle. For example, it might be a phone number in admin-c attribute, or it might be 'Gunduz', a string that can't be a NIC handle, as it's longer than 4 letters, nor can it be a name as it has only one word. Another example could be "Mr. Gunduz", which enters this category because "Mr" can't appear in a name of person/role object. Solution: Create a person object for each such reference. Name the object "person: Place Holder Object" and list the object that refers to it in its remarks attribute. Protect it with inconsistent object's maintainer(s). Then update the inconsistent object to refer to the NIC handle of this new place holder person object. In each case an object is updated, or created, send appropriate notifications (determined by "mnt-by" and "notify" attributes, as with all other updates). Please note that this proposal does not actually solve the problem of invalid contact information-- rather, it makes the data set more uniform, thus decreases the administration and development time of the whois database.

1 2

RE: [lir-wg] IPv6 assignments to RIPE itself
by matthew.ford＠bt.com 15 Jan '03

15 Jan '03

Hi, See below... -----Original Message----- From: Gert Doering [mailto:gert@space.net] Sent: Wed 15/01/2003 12:56 To: Ford,M,Mat,DEN5 FORDM5 R Cc: gall(a)switch.ch; gert(a)space.net; bortzmeyer(a)gitoyen.net; jeroen(a)unfix.org; woeber(a)cc.univie.ac.at; lir-wg(a)ripe.net Subject: Re: [lir-wg] IPv6 assignments to RIPE itself Hi, On Wed, Jan 15, 2003 at 11:25:12AM -0000, matthew.ford(a)bt.com wrote: > Allocate /48s, exhaust existing RIR allocation, get more addresses from RIR. > > I don't see the problem. The current way that the RIRs and IANA allocates space *is* a problem, because it leads to "multiple prefixes per LIR", which is bad bad bad bad. => which is why ripe-261 is being developed. Mat.

2 1

80.x.x.x cannot resolve .zw addresses
by Chris Ransley 15 Jan '03

15 Jan '03

Hi guys, We are having an issue when trying to resolve Zimbabwe address eg: cfs.co.zw, zol.co.zw. I tried on two 80.x.x.x networks. 80.71.96.0 255.255.240.0 & 80.77.192.0 255.255.240.0 Can anyone help? Best Regards, Christian Ransley B.Sc. Web & Technical Services Manager Keyworld Ltd. UB42, Industrial Zone San Gwann SGN 09 Tel: (+356) 2540 2540 Fax: (+356) 2540 9999 Email: webmaster(a)keyworld.net Website: http://www.keyworld.net

2 1

IPv6 assignments to RIPE itself
by Robert Kiessling 15 Jan '03

15 Jan '03

Hello, RIPE uses addresses which are unassigned: > host -t aaaa ns.ripe.net. ns.ripe.net IPv6 address 2001:610:240:0:193::193 > whois 2001:610:240:0:193::193 inet6num: 2001:0610:0240::/42 netname: RIPE-NCC-IPv6 descr: RIPE NCC status: ALLOCATED-BY-LIR In my understanding, this is not an allowed usage sice RIPE must assign a /48 to themselves before the use the address space. However, I rose this issue with them, and they claim there is not need for this. Could someone please explain to me where my understanding of the allocation and assignment rules is flawed? Thank you, Robert

5 10