- lir-wg - mailman.ripe.net

IP addresses for the RIPE NCC
by Hans Petter Holen 09 May '02

09 May '02

Dear working Group, Now that we have a new interim policy in place, an important policy question comes up: How can the RIPE NCC get IP addresses for their services ? Either they qualify trough the Interim policy or they need to go to their upstream. Trouble is that as far as I know the RIPE NCC has no upstream provider, as they are multihomed to a substantial number of subscribers. What is the workinggroup opinion on this ? Regards, -hph

5 5

Updated New IPv6 Draft Document
by RIPE NCC WebMaster 08 May '02

08 May '02

Dear All, The following updated draft document is available for comments and suggestions until Monday 20 May 2002. Any comments should be sent to: lir-wg(a)ripe.net. The draft document has been updated to include the following paragraph: "Although it is agreed that it is undesirable to give special status to any IP (IPv4 or IPv6) address block, it was agreed that the particular need defined in this document is the only justifiable exception to that general principle." The draft document "IPv6 Addresses for Internet Root Servers in the RIPE Region" is available from: http://www.ripe.net/ripencc/mem-services/registration/ipv6/draft-documents/ Regards Jeroen Bet RIPE NCC WEBMASTER ==================

1 0

New IPv6 Draft Document
by RIPE NCC WebMaster 07 May '02

07 May '02

Dear All, The following draft document is available for comments and suggestions until Monday 20 May 2002. Any comments should be sent to: lir-wg(a)ripe.net. The draft document "IPv6 Addresses for Internet Root Servers in the RIPE Region" is available from: http://www.ripe.net/ripencc/mem-services/registration/ipv6/draft-documents/ Regards Jeroen Bet RIPE NCC WEBMASTER ==================

1 0

Requests to the RIPE DB Administration are now ticketised
by Andrei Robachevsky 03 May '02

03 May '02

Dear colleagues, [apologies for multiple messages] As was announced at the RIPE 42 meeting starting from the next week, 6 May 2002, questions and requests directed to the RIPE Database Administration (ripe-dbm(a)ripe.net) will be processed using a ticketing system. This will allow us to track your requests more efficiently and further improve the quality of support we provide to you. No automatic acknowledgements will be sent to you. In replies from the ripe-dbm the subject line will be modified by prepending a ticket number: Re: NCC#2002044160 <original subject> Please preserve this ticket number in your further correspondence with the ripe-dbm. No other changes should be visible to you. This will not affect submissions sent to the RIPE Database at auto-dbm(a)ripe.net. If you have any more questions regarding this issue please don't hesitate to contact ripe-dbm(a)ripe.net. Regards, Andrei Robachevsky DB Group Manager RIPE NCC

1 0

IPv6 assignments to DNS root servers in the RIPE region
by Joao Luis Silva Damas 29 Apr '02

29 Apr '02

Dear all, below find a proposal for a policy enabling the assignment of blocks of IPv6 addresses to Internet DNS root servers in the RIPE region. I would like to use the opportunity to request from the chairman of the LIR WG to include this point for discussion in the WG meeting next week. Of course, discussion in the mailing list is welcome. Best regards, Joao Damas RIPE NCC **************** This proposal requests the adoption of a special IPv6 assignment policy for Internet DNS root servers. It does not apply to any other infrastructure. Specifically, this is not a request for a generic "special infrastructure" IPv6 assignment policy. --- IPv6 address assignments to Internet DNS root servers in the RIPE region Internet DNS root servers are particularly critical elements of the Internet's infrastructure. They need to be operated in a neutral and professional manner which will not impose any artificial or unnecessary barriers for access to their designated services. DNS resolvers and resolving name servers need to be pre-configured with the network addresses of the root name servers. This makes these addresses special and not easy to change. Hence this special policy. Under this policy, each (current or future) Internet DNS root server (as listed in the root-servers.net zone) in the RIPE region will be assigned a block of IPv6 address space for purposes of root server operations. The size of the block shall be the same as the size of the minimum allocation to LIRs valid at the time of the root server assignment. The assigned prefix is only for root server operations and support functions related directly to the operations, such as monitoring, statistics, etc., and is bound to the root server service itself. It is not associated with the organization/s that operate the root server at a particular point in time and these organizations should not use the address space to provide any services not related to the root server. Should the operational responsibility for a DNS root server move to a new organization, the IPv6 address space associated with the server will also move to the new organization. The old and the new organizations must update the registration information with the RIPE NCC. If the new location of the root name server is outside the RIPE region, the address space must be returned to the RIPE NCC and a new assignment must be requested from the appropriate RIR. If a root server stops operating within the RIPE region, the address space will be returned to the RIPE NCC and marked as "reserved" for a suitably long period of time. *******************

11 29

Re: Transferring InterNIC space from ARIN Database to other RIR databases
by Wilfried Woeber, UniVie/ACOnet 26 Apr '02

26 Apr '02

>At 11:08 25/04/2002 +0200, Joao Luis Silva Damas wrote: >>> o After the move of the authority for the data, what information will >>> the ARIN database return when queried via whois? A pointer to the >>> RIPE NCC (as happens now for the larger RIPE address blocks), or a >>> "slave" copy of of the data from the RIPE database? >> >>A pointer seems to be the more favoured approach right now. > >A pointer would be the right thing to do, IMO. There are already several >address blocks from 192/8 which are registered in the RIPE database but are >listed as unassigned in ARIN's database. This creates the appearance of a >conflict and will probably confuse some people. > >philip >-- After (during?) the various migrations, we should aim for a system where every RIR whois server returns "the same" info about allocated and assigned addresses. The _authoritative_ whois should give the full story, all the other 3(*) should return a pointer reference. Pending an analysis of what the potential load could be, I'd even suggets to implement a referral mechanism similar to the support for domain referrals in the RIPE DB Software. I'd like to get feedback form the LIR community about the usefulness of that approach. We could then, if supported, take it to the DB-WG for review. *) this includes the LACNIC whois. Wilfried.

2 1

Transferring InterNIC space from ARIN Database to other RIR databases
by Joao Luis Silva Damas 26 Apr '02

26 Apr '02

Dear all, Sometime ago we started a thread about distributing address space issued prior to the existence of the RIRs, which is currently registered at the ARIN database (imported from the InterNIC's database), to the RIR that now operates in the region where the address space is registered as used. Doing this would simplify processes such as modifying the name servers for in-addr.arpa for those addresses, changing contact information, etc as the user will issue requests for change to the RIR in their region, the one with which they will normally be more familiar. Both ARIN and the RIPE NCC are now ready to proceed with this. There are some aspects, however, where community input is required and I would like to ask you to comment on the proposal below. Note: the examples at the bottom are just examples. We do not want to imply there is anything wrong with the objects mentioned. Best regards, Joao Damas RIPE NCC -------------------------------------------- Proposed procedure for migration of legacy objects from ARIN Database When moving data from the ARIN database into the RIPE Database the situation is not, unfortunately, always without conflicts. Some data that is in the ARIN database also has an entry in the RIPE database. While the ARIN database is the one which contains the authoritative information for the set of name servers used in in-addr.arpa resolution for the addresses in question (the in-addr.arpa zone file is generated from that data), sometimes the administrative contacts seem to be more up to date in the RIPE database. Below are a set of proposals for actions when transferring the data: I. inetnum objects 1. There are several types of conflicts with the data in the RIPE Database: 1.1 Exact matches with RIPE networks (4325) *Proposal: to override data in the RIPE Database with ARIN's. If the object in the RIPE database has a "changed" date more recent than the object in the ARIN database, contact information from the RIPE database is kept and the nameservers are the ones in the ARIN database. 1.2 ARIN network contains a RIPE network(s) (169) 1.2.1. ARIN's allocation, while multiple assignments are registered in the RIPE Database *Proposal: to keep RIPE's and ARIN's data 1.2.2. Minor Mismatch *Proposal: to override data in the RIPE Database with ARIN's 1.3 ARIN network is contained in a RIPE network (3060) *Proposal: to keep ARIN's data and delete RIPE network 1.4. Objects in the ARIN database only *Proposal: to put ARIN's data in the RIPE Database 2. Protection of the transferred inetnums *Proposal: To create a mntner object for each ARIN's 'coordinator'. Syntax could be: mntner: <coord hic hdl>-MNT mnt-by: <coord hic hdl>-MNT auth: MAIL-FROM <coord e-mail address> ... Then we protect inetnums 'owned' by the coordinator with this maintainer. Should be the same level of security as currently at ARIN. Note: it could be different if the POC is merged/replaced by existing RIPE person object (see further discussion). II. POC objects 1. Try to match POCs from ARIN DB to the existing person objects in the RIPE DB (762) The implication is that we use the person's e-mail address as authorization (see proposal above) * Proposal: to contact all affected persons in advance and have a more clear picture before the transfer. Questions to ask: - Do both records represent the same person? - Would (s)he like to merge the contact data, in what manner? After an answer to these questions is received: - Discuss protection issue (existing maintainer, coordinator's maintainer, auth). Needs human work. 2. Protection of the transferred POCs * Proposal: to add mnt-by referencing a respective coordinator's maintainer. ---------------- Examples I.1.2.1 inetnum: 130.242.0.0 - 130.243.255.255 netname: SUNETREGAB-RIPE descr: European Regional Internet Registry/RIPE NCC descr: These addresses have been further assigned descr: to European users. Contact information can descr: be found in the RIPE database at whois.ripe.net country: NL admin-c: RIPE-NCC-ARIN rev-srv: sunic.sunet.se rev-srv: falun.dns.swip.net rev-srv: ns.ripe.net status: ALLOCATION changed: hostmaster(a)arin.net 20000329 source: ARIN ... inetnum: 130.242.43.0 - 130.242.43.255 netname: SE-TEKNISKAMUSEET descr: Tekniska Museet country: SE admin-c: HALI1-RIPE tech-c: HALI1-RIPE status: ASSIGNED PA mnt-by: SUNET-MNT changed: fredrik(a)sunet.se 19981022 source: RIPE inetnum: 130.242.48.0 - 130.242.48.255 netname: SE-ARMEMUSEUM descr: Statens Forsvarshistoriska Museer country: SE admin-c: BOMI1-RIPE tech-c: LEPE1-RIPE status: ASSIGNED PA mnt-by: SUNET-MNT changed: fredrik(a)sunet.se 19981022 source: RIPE ... I.1.2.2 inetnum: 131.117.0.0 - 131.117.128.255 netname: ZUERI descr: Municipality of Zuerich descr: Wilhelmstr. 10 descr: Zurich, 8021 descr: CH country: CH admin-c: BM153-ARIN status: ASSIGNMENT changed: hostmaster(a)arin.net 19980824 source: ARIN inetnum: 131.117.0.0 - 131.117.127.255 netname: ZUERI-NET descr: Municipality of Zuerich descr: Zuerich, Switzerland country: CH admin-c: BM16-RIPE tech-c: BM16-RIPE changed: huber(a)switch.ch 19950412 source: RIPE I.1.3 inetnum: 130.138.0.0 - 130.140.255.255 netname: PHILIPS descr: Philips C&P/NBS descr: Eindhoven country: NL admin-c: HS6189-RIPE tech-c: HS6189-RIPE notify: H.Sanders(a)mpn.cp.philips.com changed: geertj(a)ripe.net 19940106 changed: H.Sanders(a)mpn.cp.philips.com 19960131 changed: ripe-dbm(a)ripe.net 19990706 changed: ripe-dbm(a)ripe.net 20000225 source: RIPE inetnum: 130.138.0.0 - 130.138.255.255 netname: PHILIPS-SERI-1 descr: Philips Components BV descr: Building BC136 descr: Hurkesestraat 9 descr: 5600 MD Eindhoven descr: THE NETHERLANDS country: NL admin-c: OK6-ARIN status: REASSIGNMENT changed: hostmaster(a)arin.net 19930413 source: ARIN II.1 person: Antonio_Blasco Bonito address: Rodinet S.a.s. address: Via Cavour 6 address: I-54033 Carrara address: Italy phone: +39 0585 779435 fax-no: +39 0585 757385 e-mail: Antonio-Blasco.Bonito(a)rodinet.com nic-hdl: ABB2 changed: blasco(a)rodinet.com 19990310 source: RIPE person: A. Blasco Bonito address: GARR-NIS address: c/o CNR-Istituto CNUCE address: via Santa Maria 36 phone: +39 50 593246 fax-no: +39 50 904052 e-mail: bonito(a)NIS.GARR.IT nic-hdl: ABB2-ARIN changed: hostmaster(a)arin.net 19931201 source: ARIN

6 6

An increase in Merger tickets
by Dominic Spratley 26 Apr '02

26 Apr '02

Dear Colleagues, In our previous email we felt it was important to notify you that specific issues had arisen that had resulted in an increase in the current response time length and that we were working to address these. We would like to take this opportunity to explain in greater detail one of these issues. When we compare the first quarter of this year with the same quarter last year we see that the number of hostmaster tickets/requests relating to Mergers and Closures has risen from nearly 5 tickets per month to over 27 tickets per month (an increase of more than 500%). Mergers, closures and takeovers of LIRs are notably complex for a variety of reasons. The process of merging, closing or taking over another LIR involves the transfer of IP addresses and AS numbers. This is necessary to ensure that Internet resources are not lost and that they get registered properly in the RIPE Database. Often, the new or remaining LIR is not aware of all the addresses involved in the process. This is specifically the case with 'old' LIRs. It can also mean that part of the address space could be returned if, through a merger or takeover, an LIR receives more address space than needed. In many cases contact persons of the LIR closing or being taken over hold all of the knowledge and are no longer reachable. This could lead to wastage of Internet resources as the addresses are very difficult to trace. All of this uses a lot of resources. We realise that those LIRs merging, closing or being taken over already have address space to add to their own and their customers' networks, whereas other LIRs that send requests to the RIPE NCC are in need of address space. We would like to give priority to the latter, but for the reasons listed above it is not always possible to have a lower response time. The process must be carried out separately for every LIR involved and having to communicate with each LIR's contacts can often add to the delay. A new draft procedure document titled "Mergers, Acquisitions, Takeovers and Closures of LIRs" has been drafted and can be found at: http://www.ripe.net/ripencc/mem-services/registration/policies/draft-docume… We hope that this will provide better guidance for the LIRs who are involved in this process. Regards, Dominic Spratley, RIPE NCC

1 0

FWD: [GLOBAL-V6] New draft available: IPv6 Address Allocation and Assignment Global Policy
by David Kessens 26 Apr '02

26 Apr '02

For your information: You might want to read the latest iteration of the 'IPv6 Address Allocation and Assignment Global Policy' draft before the actual discussion of the draft during the lir wg session at the RIPE meeting next week. David K. --- ----- Forwarded message from Thomas Narten <narten(a)us.ibm.com> ----- X-Delivered-For: <david(a)iprg.nokia.com> X-mProtect: <200204251156> Nokia Silicon Valley Messaging Protection X-Authentication-Warning: data.staff.apnic.net: majordom set sender to owner-global-v6(a)lists.apnic.net using -f To: global-v6(a)lists.apnic.net Subject: [GLOBAL-V6] New draft available: IPv6 Address Allocation and Assignment Global Policy Date: Thu, 25 Apr 2002 06:54:02 -0400 From: Thomas Narten <narten(a)us.ibm.com> X-Scanned-By: MIMEDefang 2.1 (www dot roaringpenguin dot com slash mimedefang) X-Scanned-By: MIMEDefang 2.1 (www dot roaringpenguin dot com slash mimedefang) A revised version of the IPv6 address document is now available. It incorporates feedback from the recent RIPE, APNIC and ARIN discussions, as well as many wording cleanups. It is believed that the document is consisent with the discussions held so far and the consensus calls of APNIC and ARIN. The document can be found at: IPv6 Address Allocation and Assignment Global Policy ftp://ftp.cs.duke.edu/pub/narten/ietf/global-ipv6-assign-2002-04-25.txt Thomas - - This list (global-v6) is handled by majordomo(a)lists.apnic.net ----- End forwarded message -----

3 2

Creation of Reverse Delegation Objects
by Tanja Heimes 25 Apr '02

25 Apr '02

Hi All, this ist the response of the RIPE Robot to one of our customers after he tried to create a reverse delegation object in the RIPE DB: "The RIPE NCC no longer accepts requests for creation and ammendments of reverse delegations which do not include the registry ID of an existing Local Internet Registry. If you are not a representative of an LIR, you should contact the LIR who assigned you the address space, or your upstream provider..." The customers owns his Provider Independent IP address space and is not able to create this object as he needs to state a reg-id in the request. Now this customers (and others in the past) claim that they have to apply to there upstream provider in order that this ISP creates the object. The customer certainly has is own maintainer. My question now: Should Provider Indepent IP space not be 100% Provider Indepent in concern to its administration in the RIPE DB? In my opinion the RIPE Robot should distinguish between PA and PI space and not request an reg-id for customers that own PI space and like to create a reverse delegation record. Best regards, Tanja Heimes -- Tanja Heimes / IP Engineer E-Mail Tanja.Heimes(a)de.cw.com Cable & Wireless Deutschland GmbH TEL. + 49 89 92699-0 Landsberger Strasse 155 Fax. + 49 89 92699-810 D-80687 Munich, Germany web: http://www.cw.com/de

5 6