- lir-wg - mailman.ripe.net

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