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

Draft agenda
by Hans Petter Holen 24 Sep '02

24 Sep '02

Dear lir-wg, Thanks to help from Leo we now have the following draft agenda. Please send me suggestions and updaes as nedded to prepare a relevant agenda for our meeting: The LIR Working Group session will be held on Wednesday 11 September 2002 from 09.00 - 12.30. Draft Agenda for RIPE 43 (version 0.1) 09:00 - 12:30 Wednesday, 11 September 2002 Chair: Hans Petter Holen Co-chair: Denesh Bhabuta A. Admin: Scribe Participant List, Charter, Mailing lists B. Agenda bashing C. RIPE 42 minutes and actions D. Report from the RIPE NCC Registration Services - Presentation by leo vegoda E. Report from the Address Council - Presentation F. IPv4 Assignment and Allocation Policy F.1 "Official Sub-Allocations" Proposal by Gert Doering G. Presentation of AC candiates X. Any other business Y. Summary of actions arising from this meeting Z. Open microphone ---------------------------------------------------------------------------- ---- For current issues, please turn to the LIR Working Group mailing list archives at: http://www.ripe.net/ripe/mail-archives/lir-wg/index.html More information about this working group is located at: http://www.ripe.net/ripe/wg/lir/index.html Best regards, --- Hans Petter Holen, Technical Manager, Tiscali, Norway, phone: +47 24 11 26 44 mobile: +47 99 21 76 70 fax:+47 24 11 24 11

2 2

Draft minutes from lir-wg at RIPE 41
by Hans Petter Holen 10 Sep '02

10 Sep '02

Dear WG, The RIPE NCC have just finished the draft minutes and published them on the RIPE web site under: http://www.ripe.net/ripe/wg/lir/r41-minutes.html RIPE Meeting: 41 Working Group: LIR Status: 1st Draft Revision Number: 1 Please mail comments/suggestions on: content to the Chair of the working group. format to webmaster(a)ripe.net. ---------------------------------------------------------------------------- --- Draft Minutes of the LIR Working Group session of the RIPE 41 Meeting 14-18 January 2002, at the Krasnapolsky Hotel, Amsterdam, Netherlands. ----------------------------------- Chair: James Aldridge Vice-Chair: Denesh Bhabuta Scribe: Jeannette Decades ----------------------------------- Agenda: A. Admin - scribe, participant list, charter, mailing-lists B. Agenda bashing C. RIPE 39+40 (minutes & actions) D. Report from the RIPE NCC Hostmasters E. RIPE 185 ("European Internet Registry Policies and Procedures") F. Change of policy for Portable address space G. RFC 2050 ("European Internet Registry Policies and Procedures") revision H. Report from The Address Council Y. Any Other Business Z. Open Microphone. Denesh Bhabuta (DB): Hans Petter Holen couldn't make it. So the meeting will have to do with James Aldridge and myself, Denesh Bhabuta. We want to set a ground rule: One of the complaints from the past was that the LIR WG has been fed with too many discussions. Discussions are supposed to happen on the mailing lists and policy decisions are to be made at the meeting. James Aldridge (JA): The agenda was sent out yesterday to the mailing list. ======================== A: Scribe. ======================== DB: Could we have a non-RIPE staff scribe please? No reactions. A RIPE staff member is scribe. ======================== B: Agenda bashing ======================== JA: Are there any additional items for the agenda? No reactions. ======================== C: RIPE 39 and RIPE 40 minutes and actions. ======================== JA: The minutes are on the website since November we think. Actions as it appears on the website, few of them are very old actions from RIPE 35, 36 and 38. Most of these had something happened since the last RIPE meeting. A lot of it is ongoing work. The 38.5 LIR-Allocated, my original suggestion, is now LIR-Partitioned and some email is sent out this week. It is now in the test database and will go live real soon now. Working group chair roles is working fine since Hans Petter Holen is not here and I am. Policy action undivided address space action on the working group to participate on the RFC 2050 is in progress. ======================= D: Report from the RIPE NCC Hostmasters ======================== Presentation of Sabrina Waschke can be found at: http://www.ripe.net/ripe/meetings/archive/ripe-41/presentations/lir-rsreport /index.html Some additional comments from Sabrina on the slides: RS staffing. We have now 5 teams. Three new hostmasters are starting in January. At this point we hope to be fully staffed and can cope with the workload. And as you can see, you have probably seen it before, we also work on future growth. (Sabrina shows her big belly). Number of requests in hostmaster(a)ripe.net. In 2000, we see a peak but now the graph shows a steady growth. We introduced last year the two-day-turnaround time for ongoing tickets. That meant that when your request was picked up out of the wait queue, a hostmaster dealt with it, you replied, you had to wait for 48 hours before you got a response from us again. That means that correctly filled out requests get a faster approval. The special lir-help(a)ripe.net mailbox is not holding up normal requests anymore. We still apply the 'approve but educate' approach. Even not perfect requests got approved and we gave tips and information for improvements to get a faster approval next time. Wait queue. The last 6 months the wait queue is low. The last 2 months it is a bit higher, due to Dutch weather (sickness) and Christmas holidays. Total LIRs per region. The growth is slowing down. We don't expect too many new LIRs. IPv4 Allocation distribution. LIRs that are working all over Europe have the country code EU. Policy development. A message was sent out to the LIR WG concerning the /20 criteria. At RIPE 40 the decision about the Assignment Window (AW) for infrastructure for LIRs was decided upon and it was introduced in December 2001. Already 250 objects have been created in the database with the INFRA-AW extension. Not all of them are valid. Some LIRs have tried to use this to clean up the database. RS services are working on a document that tries to cover everything concerning mergers, take-overs and closures of LIRs. IPv6. The assignments for Exchange Points have been introduced in August 2001. E: RIPE 185 ("European Internet Registry Policies and Procedures") ======================== Nurani Nimpuno (NN): We encourage everyone to look at the document and to give comments. We're speaking about the new policy draft document for IPv4 policies. The document has been out on the web for 5 months and there was very little activity. The couple of comments that have been made have been published on the LIR WG mailing list. JA: I'm not sure how much more we can do. There hasn't been very much discussion on the mailing list about this. My opinion is this, more profitable work is done on the mailing list. Then we can come to the RIPE meetings for final decisions, rather than having long drawn-out arguments and conversations here. But are there any brief comments from anyone here? Because we're actually ahead of schedule and I'm trying to think of anything to fit in a bit of time. I encourage everyone to join the mailing list and to participate in the revision process. The email address is ripe-185bis(a)ripe.net. ======================== F: Change of policy for Portable address space ======================== JA: The question is if people are happy with the new policy? No reaction. DB: Are people aware of the policy change? It's about the requirements of a /22 immediate or the previously use of a /22 to become a new LIR. This was voted on at the last RIPE meeting. Any thoughts? Are people finding it difficult with their customers who want to be mainly multi-homed? Comments? No? We will continue this discussion on the mailing list. ======================== G: RFC 2050 ("European Internet Registry Policies and Procedures") revision ======================== JA: The agenda on the web was wrong about this one. This should be the RFC 2050, the global Internet Registries guidelines, which is being revised and prolong sides the European policy. Again joining the mailing list for participation and discussion is appreciated. Are there any comments for now? Mark Mcfadden (mcf(a)uwm.edu): I'll give a brief update. There is a mailing list available through ARIN for the global RFC 2050 discussion. Part of that working group, there are also some milestones. We're a little bit behind on those because of some things that happened at the end of last year. But we can start see there again is some movement forward. So I encourage anyone who is interested in the discussion of the revision of RFC 2050 to make sure that you're part of that mailing list. Mailing list address: rfc2050-WG(a)arin.net JA: Any questions, comments, anything? Comment from ?: I think that there are more hostmasters here are than LIRs. ======================== H: Report from The Address Council ======================== Barbara Roseman gave a report from the Address Council. Slides can be found at: ======================== Y: Any Other Business ======================== UUNET: There has been a discussion on the mailing list about PI - multihomed issues. The question raised if multi-homed is always needed or not. We have customers that need multi-homing. But not all providers will route small address blocks. JA: I don't know if there's anything that the LIR WG can do to force providers to route any particular address space. I would be inclined, rather than a policy change our of LIRs, have the Routing WG work on this issue and come up with a 'best practice or something'. DB: We can talkabout 'best practice' but there are commercial realities behind this as well. A lot of ISPs have customer requirements to fulfill. You're not the only person who has spoken about this issue with us and it has mainly come up since the last policy change. This was about the minimum requirement of a /22 before we can get address space. Are there any suggestions? UUNET: As far as I can see, the company that I work for, which is UUNET, is thinking about(at least the hostmaster is, which I am not) having a policy where you accept other provider's PA space instead of trying to go the PI route. This is current thinking, this is no decision, but the problem is we don't have a consistent policy across our AS and we'd like to implement one. Before we implement it we'd like to have consistent policy within RIPE. The problem is that whenever we get the discussion, everybody starts jumping and shouting saying: "Multi-homing". Then the discussion dies because multi-homing is the issue. But before we solve that problem we would like to have something implemented that is workable right now instead of waiting until we solve the mult-homing discussion, which seems to be without a logical solution. DB: My suggestion is that we take this up with the Routing WG as well and maybe we can make this into an action item from this meeting. UUNET: I didn't raise it in the Routing WG yesterday, thinking that was more appropriate to the LIR WG. I guess there were some initiatives in the community, but they all died. So I wonder if there's anybody else that feels like this, something we need to resolve rather sooner than later. DB: Any other comments? No reaction. UUNET: I guess there's too much RIPE NCC people here as previously discussed. DB: We'll set it as an action point. JA: This is the first new action point from this RIPE meeting. Any other questions, comments? I think this is about it for this morning. Please participate on the mailing lists. It does make it so much easier if there's been discussion before RIPE meetings. We can then reach final decisions at these WG-meetings.

2 1

Action from RIPE 42: Sub-Allocations revisited
by Gert Doering 05 Sep '02

05 Sep '02

Hi, and once again, the suballocation topic. On RIPE42 in Amsterdam, the feedback was pretty much non-existant, so nothing has been decided on this proposal. I still think it's useful. Not for all LIRs, but for the larger ones that have a multi-level reseller hierarchy, or maybe a multi-national internal hierarchy (Stephen and the MIR thing). In the last months, I've heard a few comments from different sides that "hmm, yes, this could be exactly what we need". Also, APNIC is working on a similar proposal for their community. Please read the following thoughts, and form an opinition. (It's a bit repetitive, as a couple of questions have come up again that are already answered in the draft). If you're in favour of it, please voice it. If you don't think it's useful, but don't see any harm coming from it, please voice that as well (please don't just write "this is crap!" unless you're convinced that nobody else can benefit from it either, and it will do more harm than good). If you *do* think it's complete crap and will destroy the whole RIPE structure, please by all means voice that as well :-) Gert Doering -- NetMaster ------------- snip ------------- Motivation: - Some LIRs have internal hierarchies, like "resellers that have their own end customers". - For aggregation reasons internal to the LIR network, LIRs "allocate" address space to their resellers ("hierarchical sub-LIRs"), who then "assign" addresse from that to their customers. Usually the LIR has to approve all end-user requests, but the sub-LIR is doing the actual assignment from the "allocated" space. - The current policy doesn't explicitely permit this, but acknowledges to some extent that it is done. - When the LIR goes to the RIR to get another allocation, the 80% rule does not take into account the fact that some of the "not assigned" space may be in fact "sub-allocated" to a "sub-LIR", thus it may be very hard to reach 80% (and will lead to internal fragmentation). (This is what Wilfried calls "reservation") - The sub-allocations are not documented, so an outsider cannot see who might be the best contact (the reseller!) if one of the end customers misbehaves (this part could be solved with "LIR-PARTITIONED"). Proposal: - permit LIRs to sub-allocate the address allocation they receive from a RIR to "downstream parties", from now on called sub-LIRs - the Sub-Allocations are documented as an inetnum: object with "status: SUB-ALLOCATED PA" in the RIPE database. I do not like "LIR-PARTITIONED", because it isn't partitioned ("equal parts"), and also because it doesn't go far enough. - All assignments from the Sub-Allocation are done by the Sub-LIR. The Sub-LIR is responsible to the LIR for following policies and procedures. The LIR is responsible to the RIR for making sure that the Sub-LIR follows the procedures. This is no big difference from what is being *done* now, it's just "officially documented". - When the LIR has to apply for an additional allocation, the Sub-Allocation are counted for the "80% utilization rule". So, to show an extreme example, a LIR that has sub-allocated 90% to its resellers, and they have only assigned a total of 30% of the total allocation yet, the LIR *would be* entitled to get a new allocation (under the current policy, it is not). In extreme cases, it might be necessary to show lots of good documentation to the RIR as for "why did you allocate so much". Points of Concern: - "They will just waste address space". Yes, it will waste some space, due to better aggregation. It is not expected that this will waste space due to "sloppyness" in following the policies and procedures - each hierarchy level will be fully responsible for making sure that the next-lower level will understand the rules and follow them. It is similar to what IANA and the RIRs do. The RIRs try to hand out address space in a responsible way (which does not always succeeed, which is why changes to the procedures are made, like /19 -> /20 for the initial allocation), and in this proposal, the LIRs have to hand out space to the sub-LIRs in a responsible way. If the RIRs mess up, they have a problem with IANA, if the LIRs mess up, they have a problem with their RIR. - "How big shall the sub-allocation be"? The exact numbers for the default case would have to be defined. Again, this is similar to the RIR->LIR case. A LIR by default gets a /20, but might get a bigger space in case it produces a good forecast that shows a reasonable need for a bigger space. I propose to give a Sub-LIR a /24 to start with, except in cases that they show evidence for needing more. Rationale: it's not too much, and you can delegate DNS on /24 boundaries without ugly tricks. When the Sub-Allocation is used up (= 80% of the space in there is ASSIGNED), the Sub-LIR can ask for more. If a customer asks for more space than the Sub-LIR has left, the Sub-Allocation can also be increased / a new Sub-Allocation be made. As a starting point for the discussion, I propose: - minimum size of a Sub-Allocation: /24 (because that's what's needed to be able to properly delegate the reverse DNS zone) - maximum size of a Sub-Allocation: 4x AW per year and sub-LIR (the number "4" here is of course open for discussion) - if a bigger size is required, go through NCC hostmasters alternatively one could introduce a new "Sub-Allocation-AW", but that's even more bureaucracy. - "What's the size of networks a Sub-LIR can assign to their customers"? It can not go over the AW of the LIR. This part is fixed due to the RIR/LIR relation. As for the rest, I propose that this should be a matter between the LIR and the Sub-LIR. They have a contract, and it's the LIRs job to make sure that the Sub-LIR follows the official policies and procedures, maybe introducing their own Sub-AW per Sub-LIR etc. Thoughts and Considerations from the RIPE NCC (Leo Vegoda): 1. How should the RIPE NCC act when a further allocation is requested if the existing allocation is not at "about 80%" usage (when used means valid assignments) - but "about 80%" is used in assignments and sub-allocations? Answer: see above in the "Motivation" block. The idea is that Sub-Allocations are considered "usage", so if (for example) 40% is ASSIGNED and another 40% is SUB-ALLOCATED, 80% usage is achieved. What percentage of the SUB-ALLOCATED space is actually ASSIGNED is not considered. So the answer is "if all other things are fine, a new allocation should be made". It is envisioned that the NCC hostmasters are going to ask nasty questions if the percentage of SUB-ALLOCATED is "overly" high and the percentage of end-user assignments overall is "overly" low (exact values to be defined). 2. If the RIPE NCC should count a "sub-allocation" as used then should it take account of the degree of assignment in the sub-allocations? If so, what degree should be assigned from them? Answer: I think that the number of end-user assignments made inside sub-allocations should not be a hard criterium (like the 80% rule). I do think that very low ratios should lead to nasty questions. I do also think that this should be compared to the IANA/RIR level - if a RIR comes back to IANA because all /8s have been "used up" (by allocating to LIRs), IANA doesn't consider the actual usage ratio *inside* the allocations, as long as the RIR has been following its rules for "under which circumstances is it permitted to make an allocation, and which size is OK". 3. Should there be a maximum size an LIR can sub-allocate? If so, what size? (I know you've previously proposed a /24 as a default or minimum size). Answer: see above (yes, but the exact number has to be decided upon). 4. Should holders of a sub-allocation be allowed to sub-allocate, too? This is allowed in IPv6. Should IPv4 be different? Answer: I can see arguments for both sides - sub-sub-allocations might not really make sense in IPv4 (not enough bits to do so much hierarchy), but then, it might make sense in some networks. I'd leave this one to the community for a decision. 5. LIRs are contractually obliged to follow the RIPE community's policies. Is it possible to enforce any requirement for a holder of a sub-allocation to follow those policies, too? Answer: The LIR has signed that it will obey all policies. So it would be part of those to enforce the RIPE rules onto the Sub-LIR as well (by an appropriate contract). This would have to be made very explicit in the "sub-allocation policy document". 6. If an LIR makes a sub-allocation this is presumably becasue it trusts the re-seller to administer the space responsibly and wants to delegate responsibility for the assignments. This implies that the LIR would place the re-seller's mnt-lower on the sub- allocation allowing the re-seller to assign without returning to the LIR. However, this would remove control over that portion of address space from the LIR. Would this policy require the reclaim attribute to be implemented in the Database? Answer: this is something to be worked out with the database WG, but to avoid trouble with the RIPE DB entries when a Sub-LIR "goes away" without cleaning up their entries, this is considered useful. 7. Database rules would have to be made as for what kind of "nesting" is permitted (SUB-ALLOCATED PA is only permitted inside another SUB-ALLOCATED or ALLOCATED PA, not inside "* PI", and so on). Answer: yes, of course. Other Comments (various sources) * this will generate a radical new structure (two-level RIR/LIR to multi-level) Answer: yes, this is the intention. * Considering the address wastage - it might not actually waste that much space, if it means some "Sub-LIRs" will not become full-sized LIRs (with a /20 each) but are happy with a /22 Sub-Allocation. So maybe it will even reduce the new-LIR rush in the progress. * Would this mean that the existing AWs would have to be reviewed (to make sure that these LIRs do not mis-use their AW to create lots of useless Sub-Allocations)? Answer: I don't think so. Maybe one need to do some kind of "small audit" on sub-allocated ranges after a few month, to get experience with this. -- Total number of prefixes smaller than registry allocations: 46611 (45583) SpaceNet AG Mail: netmaster(a)Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299

4 4

Action from RIPE 42: Sub-Allocations revisited
by Stephen Burley 02 Sep '02

02 Sep '02

My first comment - BTW this is a well outlined. - All assignments from the Sub-Allocation are done by the Sub-LIR. The Sub-LIR is responsible to the LIR for following policies and procedures. The LIR is responsible to the RIR for making sure that the Sub-LIR follows the procedures. This is no big difference from what is being *done* now, it's just "officially documented". I feel the Sub-LIR should still be responsible to RIPE for approvals etc. Stephen Burley WorldCom EMEA Hostmaster SB855-RIPE

3 3

Re: [lir-wg] AS1 in ripe db ?
by Matthew Robinson 30 Aug '02

30 Aug '02

> Dear Pieterjan d'Hertog, > > D'HERTOG Pieterjan wrote: > > Look what I discovered in the RIPE DB... > > > > aut-num: AS1 > > as-name: NETS-AS > > descr: NetServices Autonomous System Number > > admin-c: TBNS1-RIPE > > tech-c: MK2488-RIPE > > notify: hostmaster(a)switchworld.nl > > mnt-lower: NETS-MNT > > mnt-routes: NETS-MNT > > mnt-by: NETS-MNT > > changed: hostmaster(a)switchworld.nl 20020814 > > source: RIPE > > > > Should be bbn planet no ? Well, we're called Genuity now but yes it's our North American ASN. Around Europe we're better known as AS7176. > This ASN space is allocated to ARIN as indicated by the as-block AS1 - > AS6. Data in the RIPE Database registered within this block is not > authoritative. > > Unfortunately at the moment we cannot protect ASN space allocated to > ARIN and APNIC as this will make impossible creation of route objects > with originating AS from this space. We are working on implementation of > cross-registry authorisation in the RIPE Database, which will allow us > to lock this space. Would it be worth registering AS1 correctly in the RIPE db as well as ARIN (and RADB) or will this simply cause confusion? > This aut-num, AS1, should not be in the RIPE Database. We will contact > the owners of this object and ask them to delete it. Many thanks for this, I'll pop the lawyers back in their cage for the moment ;-) Kind regards Matthew

1 0

AS1 in ripe db ?
by D'HERTOG Pieterjan 29 Aug '02

29 Aug '02

Look what I discovered in the RIPE DB... aut-num: AS1 as-name: NETS-AS descr: NetServices Autonomous System Number admin-c: TBNS1-RIPE tech-c: MK2488-RIPE notify: hostmaster(a)switchworld.nl mnt-lower: NETS-MNT mnt-routes: NETS-MNT mnt-by: NETS-MNT changed: hostmaster(a)switchworld.nl 20020814 source: RIPE Should be bbn planet no ? whois -h rr.arin.net AS1 % ARIN Internet Routing Registry Whois Interface aut-num: AS1 as-name: ASN-GTEI descr: GTE Internetworking import: from AS3847 action pref=50; accept ANY import: from AS5646 action pref=50; accept ANY export: to AS3847 announce ANY export: to AS5646 announce ANY admin-c: BBN Planet NOC tech-c: BBN Planet NOC remarks: For Spam complaints, send mail to "abuse(a)bbnplanet.com" For network related issues, send mail to "ops(a)bbnplanet.com" or call +1 781 262 6186 notify: corp-neteng(a)bbnplanet.com mnt-by: BBNPLANET changed: smeuse(a)bbnplanet.com 19990929 source: RADB --- Pieterjan d'Hertog, Senior Network Engineer Belgacom Skynet NV/SA, 2 Rue Carli, B-1140 Brussels Phone +3227061311 Fax +3227061150 http://www.skynet.be PGP fingerprint: D9AB CD6A 2A78 73CC 68BF 0AFA 8FB3 5821 E4BB 9D2E

2 1

FW: Proposal for Transfer of 6bone Address Management Responsibilities to RIRs
by leo vegoda 26 Aug '02

26 Aug '02

Dear Colleagues, It has been proposed that the management of the 6bone 3FFE::/16 address space be transferred to the Regional Internet Registries (RIRs). More information about the 6bone can be obtained at: <http://www.6bone.net/> At a recent 6bone meeting, Bob Fink made a proposal for this management transfer. A copy of the presentation slides are available at: <http://www.6bone.net/ngtrans/minutes/default.htm> or at: <http://www.apnic.net/meetings/14/sigs/policy/index.html> These presentation slides were based on the text, "Policies for transfer of 6bone address management responsibilities to RIRs," provided below. Please send your comments about this proposal to the LIR WG mailing list <lir-wg(a)ripe.net>. The 6bone and other RIRs will be conducting similar reviews within their communities and the RIPE NCC will summarise the collective responses, issues, and concerns, made in regard to this proposal. This review process will end on December 31, 2002. Regards, -- leo vegoda RIPE NCC Registration Services ----- Forwarded message ----- ******************* Policies for transfer of 6bone address management responsibilities to RIR Version: 20 August 2002 1. Introduction 6bone was established in 1996 as a continuing IPv6 test bed with the original purpose of testing of standards and implementations, and the more current focus on testing of transition and operational procedures, as well as application conversion. It provides an opportunity for those wanting early experience and/or needing to experiment with IPv6, with a minimum of startup complexity, particularly in terms of address management policies, and at minimal cost. It also provides an open peer process for information, hookup help, and support, with strong ties to the IETF process as well as to the operational community. To date, 6bone address space has been allocated and registered in an informal process quite separate from the existing Regional Internet Registry system. The purpose of this proposal is to establish a long term model that provides for a more "official" home for 6bone address space management within the established Internet administrative structures. At the same time, the proposal recognizes that 6bone's most important functions as an accessible and informal test bed network must be maintained. This document proposes the transfer of responsibility for administration of 6bone address space (3ffe::/16) to the Regional Internet Address Registries (RIRs). It describes a set of policies and procedures for this transfer, and for the ongoing administration of 6bone address space within the RIR framework. It should be noted that the ongoing operation of the 6bone, and policies related to it, are still the purview of the 6bone community itself. For example, 6bone network compliance with the 6bone routing guidelines is a matter for the community itself to resolve, typically by mail lists. It is also important to continue the strongly volunteer efforts of the 6bone, both to make it as easy and friendly as possible for individuals, sites and networks to experiment and learn about IPv6, but also to keep the process streamlined and cost-effective. 2. Definitions a) "6bone" and "6bone community", as it appears in section 3 below, means 6bone organizations and individuals including the RIRs, "6bone members" (see below), and those participating in the 6bone mail list. b) 6bone members are defined as entities which are approved for address space allocation by the 6bone community in accordance with 6bone policies, and who agree to be bound by those policies and the policies stated below. c) 6bone allocations are allocations of 6bone address space which are held by 6bone members, or made to 6bone members in accordance with these policies. d) 6bone address space is defined as IPv6 address space within the 3ffe::/16 address block. 3. Policies 3.1 General a) In consultation with 6bone, RIRs will implement a common set of policies applying specifically to 6bone allocations. This will follow the current RFC2772, "6Bone Backbone Routing Guidelines" and/or successor documents resulting as an evolution of conversations in the 6bone community and the RIRs.; b) 6bone members will be served by respective RIR in their region, for "6bone Address Services" including 6bone address allocation, database registration and maintenance, and ip6.arpa registration (as described below); c) In order to receive 6bone address services from an RIR as described here, each 6bone member must "join" that RIR, that is, enter into the appropriate membership or services agreement with the RIR. d) RIR fees will be waived for 6bone address services provided by RIRs to 6bone members (but not for other services 6bone members may require), until 1 year after this agreement starts. After this time each RIR may charge an administration fee to cover each allocation made. This fee simply covers registration and maintenance, rather than the full allocation process for standard RIR members. This administration fee should be as low as possible as these requests do not have to undergo the same evaluation process as those requested in the normal policy environment. e) Organizations may receive 6bone address services from the RIR only on approval by 6bone, and in accordance with these policies; f) 6bone members will have the option to receive other services from an RIR (including allocation of production IPv6 address space), by following the policy, process and procedures in place at the time of application for those services. g) Continuing compliance with 6bone policies, and with the policies defined here, will be verified by 6bone at least every 2 years; 3.2 6bone Address Services a) 6bone Address Services include allocation of 6bone address space, registration and maintenance of database records relating to that address space, and registration of ip6.arpa records; b) 6bone address space allocations will be made from 3ffe::/16 and only /32 prefixes will be allocated. There will be exceptions for unusual and new proposals per joint RIR and 6bone review and approval. A relevant example of this is one or more new strategies such as geographic or metro addressing; c) No additional 6-bone address space will be allocated to any 6bone member (therefore no provision will be made for aggregation of multiple allocations, reservations etc); d) 6bone address services will be provided strictly for experimental, non-commercial use; e) Allocations will be made on the clear and stated understanding that the prefix 3ffe::/16 has a limited lifetime. The dates for the termination of allocation from the prefix and the expiration of the prefix will be determined at a future date. The RIRs will not participate in these determinations. f) 6bone address space will be returned to the RIR when no longer in use, when reclaimed due to non-compliance with 6bone or RIR policies, or when 3ffe: space is finally withdrawn; g) Registration of 6bone address space within the ip6.int zone is not covered by this policy, and is at option of 6bone member; h) Registration of 6bone sites, maintainers, persons and address space within the existing consolidated 6bone registry is not covered by this policy, and is at option of 6bone and its current policies. 3.3 Transfer of existing 6bone members a) Responsibility for existing 6bone members in respect of services described here will be transferred from 6bone to the respective RIR, at the option of those members individually, on entering into the appropriate agreement with the RIR; b) On joining the RIR, 6bone address registration records for the member concerned will be transferred from 6bone registry to the respective RIR database; c) On joining the RIR, 6bone members may establish ip6.arpa delegation records in accordance with applicable RIR procedures; d) Legacy holders will use RIR administrative procedures for management of their records; e) There will be a sunset (2 years?) on existing 6bone members not transferring to RIR administrative procedures, after which their address allocation will be revoked. ----- End forwarded message -----

1 0

by Cathy 22 Aug '02

22 Aug '02

Hi all Who knows how can i Register the assigment in Database ?

2 1

Early Registration Transfer Project
by Joao Luis Silva Damas 21 Aug '02

21 Aug '02

Dear Colleagues, Prior to the formation of the RIPE NCC, all Internet resources were issued by the InterNIC and its predecessors, based in the USA. The RIPE community has decided to transfer registrations of resources used in the RIPE NCC Service Region to the RIPE Whois Database. Initially we will transfer Autonomous System Number registrations. The work will start on 21 August 2002, with the transfer of ASN records. Contacts for all registrations to be transferred will be notified by a separate e-mail detailing the process. A brief report on the results of the transfer process will be made at RIPE 43 in Rhodes. During and after the RIPE 43 meeting there will be the opportunity to discuss any issues that may arise from the transfer of IPv4 registrations. A complete list of ASN registrations being transferred and details of the transfer process are available from our web site at: <http://www.ripe.net/ripencc/pub-services/db/erx.html> In the meantime should you have any further questions please contact us at: <er-transfer(a)ripe.net> Kind regards, Joao Damas RIPE NCC

2 2

"The process is not working." ??
by Jim Fleming 20 Aug '02

20 Aug '02

From: "Hank Nussbacher" <hank(a)att.net.il> "The process is not working." ===== There are many things on the "toy" 32-bit Internet which do not work properly. It is a good place to sort things out before moving to the serious 128-bit DNS run by commercial companies that provide flawless service. Jim Fleming 2002:[IPv4]:000X:03DB:...IPv8 is closer than you think... http://www.ican.org/what's_new!!!.htm http://www.iana.org/assignments/ipv4-address-space http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt ----- Original Message ----- From: "Hank Nussbacher" <hank(a)att.net.il> To: "Joao Luis Silva Damas" <joao(a)ripe.net> Cc: <lir-wg(a)ripe.net>; <db-wg(a)ripe.net> Sent: Monday, August 19, 2002 2:24 PM Subject: Re: [lir-wg] Early Registration Transfer Project > On Mon, 19 Aug 2002, Joao Luis Silva Damas wrote: > > The process is not working. Based on: > http://www.arin.net/registration/erx/index.html > I should have been notified Aug 15 about AS378. I wasn't. So I checked > another Israeli "early" ASN. AS1680 also didn't get any notification > email. ARIN can say they are notifying those listed in their whois, but I > can only assume they have a bug in their software and proper email > notifications are *not* going out to all early ASNs. > > -Hank > > > Dear Colleagues, > > > > Prior to the formation of the RIPE NCC, all Internet resources > > were issued by the InterNIC and its predecessors, based in the > > USA. The RIPE community has decided to transfer registrations > > of resources used in the RIPE NCC Service Region to the RIPE > > Whois Database. > > > > Initially we will transfer Autonomous System Number registrations. > > The work will start on 21 August 2002, with the transfer of ASN > > records. Contacts for all registrations to be transferred will > > be notified by a separate e-mail detailing the process. > > > > A brief report on the results of the transfer process will be made > > at RIPE 43 in Rhodes. During and after the RIPE 43 meeting there > > will be the opportunity to discuss any issues that may arise > > from the transfer ofIPv4 registrations. > > > > A complete list of ASN registrations being transferred and details > > of the transfer process are available from our web site at: > > > > <http://www.ripe.net/ripencc/pub-services/db/erx.html> > > > > In the meantime should you have any further questions please > > contact us at: <er-transfer(a)ripe.net> > > > > Kind regards, > > > > Joao Damas > > RIPE NCC > > > >

1 0

AS policy discussion - summary
by leo vegoda 19 Aug '02

19 Aug '02

Dear Colleagues, Please find below a brief summary of the discussion on AS Numbers. This summary should provide input for further discussions at RIPE 43: In order to conserve AS numbers and routing table space, current policy only allows the assignment of an AS Number if a network is multi-homed. It is difficult if not impossible to reliably verify if a network is multi-homed soley by looking at the routing tables. Nonetheless, it was proposed that where a reciprocal routing policy is published in the Routing Registry it is very likely that multi-homing is in place. While reclamation of unused AS numbers was not a point of contention, no definition of "usage" was achieved. No conclusion was reached although varying proposals were brought forward. Therefore we suggest that each month the RIPE NCC publish a list of assigned AS numbers and their status. The information will be drawn from the IRR and the RIS project. Best regards, -- leo vegoda RIPE NCC Registration Services

1 0

Re: [lir-wg] DNSSEC training WHY?
by Wilfried Woeber, UniVie/ACOnet 19 Aug '02

19 Aug '02

Hi Stephen! > [ ... ] >If you are going to start training this kind of thing is should be at >the very least on a subscription basis. I for one do not want to fund >the education of the entire ripe community. I feel this is wrong, it is >not part of our service agreement which is what we pay for, much the same >as the test traffic white elephant we funded for years. I am fully aware that some organisations now and then go through phases where any and all expenses are more tightly checked than in the past ;-) While the Annual Activity Plan issue has already been taken care of, there is another aspect which cannot (for the benfit of those who joined the community at a later date or who didn't follow the project in detail) be left standing without a comment: your "white elefant" claim, implying that the community funds a pet project for a minority: I have just today approved payment for the TTM Service invoice for ACOnet's testbox, amounting to 6K+ EUR. We have actually _bought_ the hardware, and we pay an _annual service_ fee. So it definitely IS a self-sufficient, _subscription based_ service offered by the NCC! Best regards, _________________________________:_____________________________________ 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

Re: Transferring InterNIC space from ARIN Database to other RIR databases
by Joao Luis Silva Damas 16 Aug '02

16 Aug '02

Dear Gabriella, we have been working on this process, not as fast as we would have liked to, I must admit. We will start by transferring ASNs. There are fewer and simpler cases when compared with IP address blocks and it will allow everyone to get a better understanding of the real amount of work involved, rather than just having an estimate, as good as it may be. As a matter of fact, we were going to send an announcement earlier today explaining the process, which is meant to start next week, but some internal problems have prevented this from happening. A message will be posted on Monday. It would be good to have some time during the lir-wg session at RIPE 43 to present the results of the first, relatively easy, step and close any issues people may have with the more complex transfer of the IP addresses. We could then proceed with the rest of the resources soon after the discussions at the RIPE meeting and in these lists. Best regards, Joao Damas RIPE NCC At 17:02 +0200 8/8/02, Gabriella Paolini wrote: >"Transferring InterNIC space from ARIN Database to other RIR databases". > >Any news about that? > >Regards, > >Gabriella Paolini >------------------------------------------------- >GARR - The Italian Academic and Research Network >http://www.garr.it >m@il: gabriella.paolini(a)garr.it >-------------------------------------------------

2 1

E-mail address masquerading for archived mail messages
by RIPE NCC WebMaster 16 Aug '02

16 Aug '02

Dear Colleagues, [Apologies for duplicate mails] Beginning today, 16 August, the RIPE NCC will implement "e-mail address masquerading" for messages displayed on the web site in the RIPE and the RIPE NCC mailing list archives. E-mail masquerading makes it more difficult for spammers to harvest e-mail addresses from the mailing list archives. When masquerading is applied, the e-mail address of the sender will be hidden in the mail archived messages. Those reading archived mail will see a return e-mail address that appears as "<somebody@localhost>". When clicking on this e-mail address, the address of the original sender will be loaded in your mail program, enabling you to send a message to the author. The RIPE NCC has chosen to implement this security measure as there have been various complaints from members of the RIPE community that e-mail addresses were being abused by spammers for Unsolicited Bulk E-mail (UBE). By implementing this security measure we anticipate there will be a sharp reduction to address harvesting of archived e-mail addresses. We will be checking for harvesters who manage to overcome this measure and will take further steps if necessary. E-mail masquerading will be applied to all mailing lists found in the following directories: http://www.ripe.net/ripencc/mail-archives/ http://www.ripe.net/ripe/mail-archives/ We appreciate your understanding on this matter. Regards Jeroen Bet RIPE NCC WEBMASTER ==================

1 0

DNSSEC training WHY?
by Stephen Burley 15 Aug '02

15 Aug '02

Hi Could someone please tell me WHY we are running free training courses for DNS? Training how to interact with the NCC and DB i understand, but dns i do not. Who made the descision to implement this training and what grounds are there for doing this? Regards, Stephen Burley WorldCom EMEA Hostmaster SB855-RIPE

12 20

Webcasting Meetings
by Stephen Burley 15 Aug '02

15 Aug '02

Hi I am formaly asking that if not RIPE 43 then all future meetings will be webcast so that all memebers who want to attend can attend the meeting. Otherwise this is by no means an equal opportunity meeing to attend and is only open to those who can get their expenses justified for holiday destinations with the express intention of going to the meeting, which lets face it in the current climate is nigh impossible. Its not that i do not appreciate the venues or that the meetings are not the place to go, its just getting harder to get to them. I wish to see a broader section of the community contributing to the RIPE process which is unique and a fine foundation for the RIPE community to come together, its just that the coming together is much harder for most now. Otherwise the only views expressed and heard are those of the people who can attend physicaly which is not the majority so limiting the scope and participation of the community at large. Regards, Stephen Burley WorldCom EMEA Hostmaster SB855-RIPE

11 15

Fwd: ARIN to allocate from 69.0.0.0/8
by leo vegoda 08 Aug '02

08 Aug '02

----- Forwarded message ----- From: "Leslie Nobile" <leslien(a)arin.net> To: <nanog(a)nanog.org> Subject: ARIN to allocate from 69.0.0.0/8 Date: 8 August 2002 14:23:58 GMT In the near future, ARIN will begin making allocations from 69.0.0.0/8. This will include allocations of /20 and shorter prefixes, according to ARIN's minimum allocation policy. For informational purposes, a list of ARIN's currently administered blocks can be found at http://www.arin.net/statistics/index.html Regards, Leslie Nobile Director, Registration Services American Registry for Internet Numbers (ARIN) ----- End forwarded message ----- Regards, -- leo vegoda RIPE NCC Registration Services

1 0

Re: [lir-wg] AS Number Policy - continued
by Wilfried Woeber, UniVie/ACOnet 07 Aug '02

07 Aug '02

Not really important, but just to avoid being counted as agreeing :-) >Anyway, I think that everyone have suggested to do both with a OR in >between. ...no objection against the OR, but the result of the OR should not be the _only_ input to a decision process. It would be an efficient mechanism to be used _in support_ of continued AS# holdership, though. >Basically just claiming that "yes I do peer at backwater-IX with >Farm-IP and Countryside Networks and I don't get transit from anywhere" >should not be enouhg. I disagree. >RIPE should be able to verify that this is true. Some nit-picking... RIPE (the community): I don't think so - other than having access to some publicly accessible documentation, e.g. in the Routing Registry. The NCC: maybe, if and when we can agree on the criteria, and the cost for verification vs. the result. >- kurtis - Wilfried.

9 18

Re: [lir-wg] Webcasting Meetings
by Janos Zsako 07 Aug '02

07 Aug '02

> From owner-lir-wg(a)ripe.net Wed Aug 7 14:48:37 2002 > From: "Stephen Burley" <stephenb(a)uk.uu.net> Dear Stephen, > > For a definitive response on whether we actually get to do this at > > the RIPE meetings however, the RIPE chair (Rob) has the last word. > > Since it is our money and our community why does one person hold the keys on > this desicion? I think this question could be appropriate if there was _consensus_ in the community that this is something we _must_ have, and Rob would oppose it. At present I think it is not the case. Janos

1 0

Updating inet6num objects with a legacy status attribute
by leo vegoda 06 Aug '02

06 Aug '02

Dear Colleagues, The RIPE Database server, whois.ripe.net, has been updated to allow the new status attributes specified in the document: "New Values of the 'status:' Attribute for inet6num Objects" <http://www.ripe.net/docs/new-value-status.html> The status values of all inet6num objects maintained by the RIPE NCC have been updated as appropriate. We would be grateful if everyone maintaining inet6num objects would update them to use the new status attribute values. The RIPE NCC will use the "ASSIGNED" status value to determine the HD ratio when it receives a request for an additional IPv6 allocation. A request form for additional IPv6 allocations will be published in the near future. Best regards, -- leo vegoda RIPE NCC Registration Services

1 0

Re: [lir-wg] Webcasting Meetings
by Wilfried Woeber, UniVie/ACOnet 06 Aug '02

06 Aug '02

>Hi, > >I do also second Stephen's proposal, it's a good idea. Before I throw in my (historical :-) 2 Groschen, is this the right place to discuss remote participation? Looking at the goal (supporting the open policy process), it is - looking at technology and implementation issues, I'm not so sure? Wilfried.

1 0

RE: [lir-wg] AS Number Policy - continued
by Lu, Ping 05 Aug '02

05 Aug '02

Look like those singlehomed ASs need to shutdown their primary link and activate their backup link so RIPE NCC could verify their LEGAL use of ASes :( For the unused ASs, I think an annual renewal fee is a whole lot easier to verify their intent to use then go thru INCOMPLETE global routing table and non-distribute whois db :) Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net > -----Original Message----- > From: Oliver Bartels [mailto:oliver@bartels.de] > Sent: Monday, August 05, 2002 9:31 AM > To: lir-wg(a)ripe.net > Subject: Re: [lir-wg] AS Number Policy - continued > > > Hello, > On Mon, 5 Aug 2002 14:52:13 +0200 (CEST), Sebastian Willing wrote: > >ASs allocated to RIPE: 6016 > >ASs unassigned: 616 > >ASs singlehomed: 224 > >ASs unused: 1526 > Good peace of work, interesting ... > > This statistics shows that the typical problem case isn't a > singlehomed > ASn, it's just an *unused at all* ASn. > > Thus it seems it isn't necessary to establish a big buerocracy > with forms to be signed etc. (like we German tend to do ;-|, its > just sufficient to validate their use in the global table and/or view > peer/upstream AS references (listing in as-set or aut-num object > of partner) corresponding to the ASn in the RIPE database. > > IMHO this should give a large yield (1500+x) with little effort > and covers most "I am $BIGCOMPANY and need a ASn because > its rare and for free" cases. > > Best Regards > Oliver Bartels > > > > Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany > oliver(a)bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0 > >

1 0

New Document available: RIPE-256
by RIPE NCC Document Announcement Service 05 Aug '02

05 Aug '02

New/Revised RIPE Document Announcement -------------------------------------- A revised/new document is available from the RIPE document store: "IPv6 Address Space Policy for Internet Exchange Points" Short content description ------------------------- Internet Exchange Points (IXPs) are used to exchange Internet traffic between different Internet Service Providers (ISPs). Many Exchange Point operators require address space for the peering mesh that is independent from any of the address space in use by member networks. Accessing the RIPE document store --------------------------------- You can access the RIPE documents in HTML format via WWW. "IPv6 Address Space Policy for Internet Exchange Points" is available at the following URL: http://www.ripe.net/docs/ripe-256.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-256.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-256.txt plain text version Kind Reagrds, Jeroen Bet Webmaster RIPE NCC

1 0

New Document available: RIPE-243
by RIPE NCC Document Announcement Service 05 Aug '02

05 Aug '02

New/Revised RIPE Document Announcement -------------------------------------- A revised/new document is available from the RIPE document store: "New Values of the "status:" Attribute for inet6num Objects". Short content description ------------------------- This document describes the new values of the "status:" attribute for inet6num objects and their impact on database operation. Accessing the RIPE document store --------------------------------- You can access the RIPE documents in HTML format via WWW. "New Values of the "status:" Attribute for inet6num Objects" is available from the WWW at the following URL: http://www.ripe.net/docs/new-value-status.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-243.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-243.txt plain text version Kind Regards, Jeroen Bet Webmaster RIPE NCC

1 0

Antw: Re: [lir-wg] Webcasting Meetings
by Wilson Mehringer 05 Aug '02

05 Aug '02

Hi, I would also like to support this proposal. It sounds like a call for democracy..on-site or online. It goes without saying that there is a business element to these meetings and a good number of attendees/companies will opt for the webcasts. Nothing against business....as long as it is ethical. Wilson >>> Matthew J Robinson <mjrobinson(a)genuity.net> 05.08.2002 13:34 >>> Hi all, I'd like to lend my support to this proposal. At it's simplest this is a few people with a few web cams and a bit of multicast support from a couple of networks. I'm fairly sure I can get some support from the multicast people on our network. Any one definately going that has a webcam and would be prepared to run a trial? I'll offer what help I can. I admit to knowing little about webcam software but I can route packets ;-) Matthew > Hi > I am formaly asking that if not RIPE 43 then all future meetings will be > webcast so that all memebers who want to attend can attend the meeting. > Otherwise this is by no means an equal opportunity meeing to attend and is > only open to those who can get their expenses justified for holiday > destinations with the express intention of going to the meeting, which lets > face it in the current climate is nigh impossible. Its not that i do not > appreciate the venues or that the meetings are not the place to go, its just > getting harder to get to them. > I wish to see a broader section of the community contributing to the > RIPE process which is unique and a fine foundation for the RIPE community to > come together, its just that the coming together is much harder for most > now. Otherwise the only views expressed and heard are those of the people > who can attend physicaly which is not the majority so limiting the scope and > participation of the community at large. > > Regards, > > > Stephen Burley > WorldCom EMEA Hostmaster > SB855-RIPE > >

1 0