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

New Draft in-addr.arpa Policy Document for Review
by Paul Rendek 10 Jun '02

10 Jun '02

Dear LIRs, We are pleased to announce the availability of the new draft "Reverse Address Delegation Under 'in-addr.arpa' in the RIPE NCC Service Region" document. The draft document can be found in the text to follow and is also available on the RIPE NCC website at: http://www.ripe.net/ripencc/mem-services/registration/policies/draft-docume… The deadline for comments and suggestions is Monday, 24 June 2002. After incorporating any suggested changes to the document the final document will be published as a RIPE Document. All comments and suggestions should be sent to <lir-wg(a)ripe.net>. Regards, Paul Rendek RIPE NCC === Draft: Policy for reverse address delegation under in-addr.arpa in the RIPE NCC service region Author(s): Document ID: TBA Date: June 2002 Obsoletes: [insert doc #] Abstract This document describes the policy for reverse delegation of IPv4 assignments and allocations in the RIPE NCC service region. Table of Contents 1.0 Introduction 2.0 Obtaining Delegation of an in-addr.arpa Sub-zone 3.0 Reverse Delegation for Provider Aggregatable (PA) Address Space 4.0 Reverse Delegation for Provider Independent (PI) Address Space 5.0 Duration of the Reverse Delegation 1 Introduction The RIPE NCC provides, as part of its services, the necessary support to enable the reverse resolution of IPv4 addresses into domain names. This service is implemented under the in-addr subdomain described in the "Management Guidelines & Operational Requirements for the Address and Routing Parameter Area Domain ("arpa")"[RFC3172] document. Delegations for IPv4 addresses contained in allocations made by the RIPE NCC (reverse delegations) are made by the RIPE NCC to the Local Internet Registries (LIRs) and further by the LIRs to ISPs or end users. 2 Obtaining delegation of an in-addr.arpa sub-zone The RIPE NCC will only accept requests for reverse delegation under in-addr.arpa from LIRs. End users must send their requests to the LIR from which they obtained the addresses, or in the case of Provider Independent addresses, to any of the LIRs of their choice.A list of LIRs can be found at: http://www.ripe.net/ripencc/mem-services/general/indices/index.html The procedure for requesting the delegation of zones under in-addr.arpa is published at: http://www.ripe.net/reverse Advice on configuring name servers is available in "Common DNS operational and Configuration Errors" [RFC1912] 3 Reverse delegation for Provider Aggregatable (PA) address space The RIPE NCC accepts requests for reverse delegation solely for address space that has been registered by the LIR as assigned to end users in the RIPE Whois Database. The RIPE NCC will only make delegations on 8-bit boundaries (/16 or /24), though multiple delegations may be requested to cover CIDR blocks bigger than a /24. LIRs should maintain DNS resource records for address space assigned to end users from their own address space, even if the user obtains connectivity from a different LIR. 4 Reverse delegation for Provider Independent (PI) address space The RIPE NCC will reverse delegate a zone of in-addr.arpa to an end user that has been assigned PI space. However, the request must be sent to the RIPE NCC via an LIR, as described above. For delegations of address blocks smaller than a /24 the method described in "Classless IN-ADDR.ARPA delegation"[RFC2317] will be used. 5 Duration of the reverse delegation Provision of reverse delegation services by the RIPE NCC is a membership service. As such, the RIPE NCC will only accept requests for delegation and modifications of delegations from LIRs that are up-to-date with regard to their membership duties. LIRs should provide reverse delegation corresponding to an assignment during the complete validity period of the assignment. -- END

1 0

Re: updating route object
by RIPE NCC Staff 10 Jun '02

10 Jun '02

Dear Arif, The authentication mechanism for routes in RPSL specification is quite different than that of v2 software which we used prior to April 23, 2001. In the new authentication scheme, also the authorisation from aut-num object mentioned in 'origin' attribute of the route must be satisfied. If the authorisation from that aut-num object fails or the aut-num object does not exist, than the creation of the route object is rejected. Please see a graphical representation of this at http://www.ripe.net/ripencc/faq/database/qa4.html#5 Also please see RFC2725, page 36 for this (ftp://ftp.ripe.net/rfc/rfc2725.txt). RIPE Database Reference Manual is available at http://www.ripe.net/ripe/docs/databaseref-manual.html Please contact us at ripe-dbm(a)ripe.net with more details and we will help you to find the solution. Regards, Katie Petrusha _____________________________ RIPE Database Administration. Original message follows: ------------------------ > X-Recipient: <dbint(a)ripe.net> > Delivered-To: lists-lir-wg-out(a)lists.ripe.net > X-Sender: arif.oktay(a)mail.telekom.gov.tr > X-Mailer: QUALCOMM Windows Eudora Version 5.1 > Date: Mon, 10 Jun 2002 11:48:54 +0300 > To: lir-wg(a)ripe.net > From: Arif OKTAY <arif.oktay(a)telekom.gov.tr> > Subject: updating route object > Precedence: bulk > X-Loop-Detect: RIPE NCC > > > Hi, > > I receive following error from db when I try to update a route object. I > provide > proper authorization schema. Can anybody help me about this problem ? > > Regards, > arif > > > Hierarchical authorisation failed, request forwarded to maintainer. > > > > ------------------------ > Arif OKTAY > Tel:+90 312 5551922 > Fax:+90 312 5551959 > ------------------------ > ... > TYLER > And, now it's gone. > JACK > All gone. > --------------------------------------- Fight Club --- -- Shane Kerr RIPE NCC

1 0

updating route object
by Arif OKTAY 10 Jun '02

10 Jun '02

Hi, I receive following error from db when I try to update a route object. I provide proper authorization schema. Can anybody help me about this problem ? Regards, arif Hierarchical authorisation failed, request forwarded to maintainer. ------------------------ Arif OKTAY Tel:+90 312 5551922 Fax:+90 312 5551959 ------------------------ ... TYLER And, now it's gone. JACK All gone. --------------------------------------- Fight Club ---

2 1

Re: KPNQwest ns.eu.net server.
by Steven M. Bellovin 07 Jun '02

07 Jun '02

In message <200206061624.40230.dani(a)intelideas.com>, Daniel Concepcion writes: > >Yes Neil, > >It should be interesting to know the 'official' requirements/recommendations >for ccTLD's hosting >For example: diversity geographical, network needs, security needs, building >environment., etc > I don't know of any official requirements. But RFCs 2182 and 2870 offer good guidance. (Some of 2870 is root zone-specific, but most of it would apply to a ccTLD server.) --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com ("Firewalls" book)

5 8

Re: Re: Re: KPNQwest ns.eu.net server.
by Sabine Dolderer/Denic 07 Jun '02

07 Jun '02

Hello Arnold, On 06.06.2002 16:55 Arnold Nipper <arnold(a)nipper.de> wrote: > > On Thu, Jun 06, 2002 at 04:31:21PM +0200, Daniel Concepcion wrote: > > > > > > Yes, but there is problem about the transit for the network of the IXP > > In my experience, some big providers only have the commercial view of > > internet. > > If an IXP decides to offer infrastructural services then you have to buy > upstream of course. > > > Really, if all the IXP members give some transit to the IXP for essential > > services, internet will be more robust. > > > > At least each IXP member would have direct connectivity to such > infrastructural services (DNS, NTP, WHOIS, NNTP??) and thereby their > customers would benefit from it. I agree that IXPs would be very gould locations as they offer network diversity, but there is one question still open and that is who will be the one running the and monitoring the server. And we at DENIC have seen in the last years an increasing demand in running the servics by ourself as only then we have the complete control and information about statistics, network attacks, performance ... There is a project within CENTR where we try to share secondary services on one host with the advantage for all geting these informations. (And yes we are still working to connect to DECIX ;-) ) Sabine > > And an IXP should be in a good position to get upstream :-)) And for > the commercials: these services are not for free of course. So bills > for IXP members will drop not raise. > > > -- Arnold > > -- Sabine Dolderer DENIC eG Wiesenhüttenplatz 26 D-60329 Frankfurt eMail: Sabine.Dolderer(a)denic.de Fon: +49 69 27235 0 Fax: +49 69 27235 235

2 1

Re: Re: KPNQwest ns.eu.net server.
by Sabine Dolderer/Denic 07 Jun '02

07 Jun '02

Hello, DENIC runs currently several secondarys (not only DE but also for some other TLDs) in different places worldwide. We are willing to offer secondary service for other ccTLDs. But there will be because of security/stability reasons a limit on the number of ccTLDs we want to run on a single machine. Sabine -- Sabine Dolderer DENIC eG Wiesenhüttenplatz 26 D-60329 Frankfurt eMail: Sabine.Dolderer(a)denic.de Fon: +49 69 27235 0 Fax: +49 69 27235 235 Jan-Ahrent Czmok An: Joao Luis Silva Damas <joao(a)ripe.net> <czmok@gatel. Kopie: randy(a)psg.com, ddiaz(a)ripe.net, routing-wg(a)ripe.net, net> lir-wg(a)ripe.net, tech-l(a)ams-ix.net, apops(a)lists.apnic.net, Gesendet von: nanog(a)merit.edu, apnic-talk(a)lists.apnic.net owner-lir-wg@ Thema: Re: KPNQwest ns.eu.net server. ripe.net 06.06.2002 01:29 PostedDate: 06.06.2002 01:29:37 $MessageID: <20020606012937.2c476312.czmok(a)gatel.net> From: owner-lir-wg(a)ripe.net SendTo: Joao Luis Silva Damas <joao(a)ripe.net> CopyTo: randy@psg.com;ddiaz@ripe.net;routing-wg@ripe.net;lir-wg@ripe.net;tech-l@ams-ix.net;apops@lists.apnic.net;nanog@merit.edu;apnic-talk@lists.apnic.net Subject: Re: KPNQwest ns.eu.net server. Received: from smtp.denic.de ([194.246.96.22]) by notes.denic.de (Lotus Domino Release 5.0.8) with ESMTP id 2002060601283597:15602 ; Thu, 6 Jun 2002 01:28:35 +0200 Received: from postman.ripe.net (postman.ripe.net [193.0.0.199]) by smtp.denic.de with smtp id 17FkCg-0004uX-00; Thu, 6 Jun 2002 01:28:34 +0200 Received: (qmail 11455 invoked by alias); 5 Jun 2002 23:28:15 -0000 Received: (qmail 11452 invoked by uid 66); 5 Jun 2002 23:28:15 -0000 Delivered_To: lists-lir-wg-out(a)lists.ripe.net PRINCIPAL: Jan-Ahrent Czmok <czmok(a)gatel.net> In_Reply_To: <p05111700b92449b9ddee(a)[193.0.1.81]> References: <200206051725.g55HPlA05396(a)birch.ripe.net> <E17Ff8f-0003So-00(a)roam.psg.com> <p05111700b92449b9ddee(a)[193.0.1.81]> Organization: Global Access Telecommunications Inc. $Mailer: Sylpheed version 0.7.6claws16 (GTK+ 1.2.10; i386-debian-linux-gnu) X_Ncc_RegID: de.gatel MIME_Version: 1.0 Precedence: bulk X_Loop_Detect: RIPE NCC SMTPOriginator: owner-lir-wg(a)ripe.net RouteServers: CN=notes/O=Denic RouteTimes: 06.06.2002 01:28:36-06.06.2002 01:28:38 DeliveredDate: 06.06.2002 01:28:38 DENICDOCOPENCOUNT: 1 $MIMETrack: Itemize by SMTP Server on notes/Denic(Release 5.0.8 |June 18, 2001) at 06.06.2002 01:28:36;MIME-CD by Notes Client on Sabine Dolderer/Denic(Release 5.0.6a |January 17, 2001) at 06.06.2002 09:32:28;MIME-CD complete at 06.06.2002 09:32:28 BlindCopyTo: WebSubject: Re: KPNQwest ns.eu.net server. On Thu, 6 Jun 2002 01:08:46 +0200 Joao Luis Silva Damas <joao(a)ripe.net> wrote: > > At 11:04 -0700 5/6/02, Randy Bush wrote: > > > Given the current situation of KPNQwest and the possibility > >> of its services going offline sometime soon, the RIPE NCC in > >> agreement with KPNQwest will be temporally hosting this > >> server (ns.eu.net) in its premises. > > > >nice emergency hack and sorry to whine. but i used them both > >to get diversity. > > Hi Randy, > > there are 16 ccTLDs for which ns.ripe.net and ns.eu.net are both > secondary. So we will definitely request those ccTLDs to look for a > new host as soon as possible. Hi Randy, hi Joao, dear routing-wg, probably my Company (GATEL, AS13129) is able to host a secondary server for the ccTLDs. The question is rather what are the hardware "requirements" for the secondary server. We have sufficient bandwidth capacity available and rack space as well. > The rest can take bit more time to think what they want to do since > ns.eu.net will keep running. Well done ! Congrats for the good ideas and coordination work. > > We are offering secondary service on ns.ripe.net for any ccTLD that > we weren't sencodaring for, as are other people. > > The idea is not to have ns.eu.net running for ever, just to enable > people to have time to take rational decisions, without the fear of > having the server going away because of some unexpected turn of > events. > > > > >when in less of a panic, please move it to moscow or something. > > Panic? what panic? this is just common sense > right. it's not panic. --jan -- Jan Ahrent Czmok - Senior Network Engineer - Access Networks Global Access Telecommunications, Inc. - Stephanstr. 3 - 60313 Frankfurt voice: +49 69 299896-35 - fax: +49 69 299896-66 - email: czmok(a)gatel.de

11 10

ASO AC - Call for Nominations 2002 - RIPE NCC Service Region
by Paul Rendek 06 Jun '02

06 Jun '02

Dear colleagues, We are pleased to announce a Call for Nominations to serve on the ASO Address Council(see below). In our effort to reach as many interested parties as possible you may receive multiple copies of this message. Please accept our apologies for this. The Call for Nominations for the ASO Address Council can also be found on our website at: http://www.ripe.net/ripencc/about/regional/icann.html Regards, Paul Rendek RIPE NCC Call for Nominations for Representatives to the ASO Address Council - RIPE NCC Service Region ---------------------------------------------------------- This is a call for nominations of individuals from the RIPE NCC service region to serve on the ASO Address Council. On 31 December 2002 one RIPE NCC service region Address Council seat will become vacant and will be filled for the next three years by an individual nominated through this open call. This document describes the functions of the ASO and the Address Council, as well as the nomination and selection process. If you are interested in nominating an individual, or if you are interested in submitting a self-nomination, please read this document carefully. 1. The Address Supporting Organisation --------------------------------------- The ASO was formed in August 1999 as a consensus-based advisory body within the ICANN framework through a Memorandum of Understanding (MoU) signed by the current Regional Internet Registries and ICANN. The ICANN Bylaws (http://www.icann.org/general/bylaws.htm#VI-A) assign to the ASO the responsibility for the development of global policies relating to the distribution and registration of Internet address space, inter-domain routing identifiers and that part of the DNS name space that is used to name these addresses and identifiers. More information about the ASO is available at: http://www.aso.icann.org 2. The Address Council - ---------------------- The ASO Address Council co-ordinates the process of policy development in areas within the responsibility of the ASO, according to procedures defined within the MoU and by the Address Council itself. Specifically, these include the hosting of an annual open General Assembly meeting and attending regular meetings either by teleconference or face-to-face, at which policy issues and submissions may be considered. The other major responsibility of the Address Council is the appointment of individuals to fill ASO seats on the ICANN Board of Directors, according to procedures defined within the MoU. More information on the Address Council is available at: http://www.aso.icann.org/ac/ 3. The Role of Members of the Address Council - --------------------------------------------- Each member of the Address Council is expected to serve for a period of 3 years. No member of the Address Council is entitled to any compensation from the ASO. No member of the Address Council can be indemnified by the ASO, nor can the ASO obtain insurance coverage relating to the liability of the actions of members of the Address Council. AC members do not represent any RIR, nor do they act as representatives of any other body. They are appointed in their individual capacity, and their membership cannot be proxied by any other individual or organisation. 4. Address Council Nominations Process - -------------------------------------- The term of Wilfried Woeber who has served as an Address Council member for the past three years will expire. One individual from the RIPE NCC service region will be selected to serve on the Address Council for a term of three years. The selection will be made through an open election process from the set of individuals who have been nominated within this process. Any individual may be nominated, with the exception of staff members of any Regional Internet Registry. Self-nominations are permitted. Nominations should be sent by email to <nominations(a)ripe.net> by midnight CET on 9 August 2002. The information included with a nomination is to be submitted in English and should include: Name of Nominee: Country of residence: Organisation: Email Address: Postal Address: Biographical information: Motivation for nomination: Name of nominating individual: Organisation: Email Address: All nominees will be contacted via email to confirm their willingness to serve on the Address Council. If a nominee cannot be contacted via email, or does not respond, their nomination will not be confirmed and they will not be eligible for election to the Address Council. All confirmed nominations will be listed on the RIPE NCC web site after they are confirmed. All nominees will have the opportunity to submit a written statement in support of their nomination for publication on the web site. In addition, others may express support for nominated individuals simply by completing and submitting the nomination form provided above. 5. Address Council Selection Process - ------------------------------------ The process for the selection of a nominee to serve on the Address Council will involve an open election. The election process will be held during the plenary session of the RIPE 43 Meeting, 9-13 September 2002, in Rhodes, Greece. See the following URL for details about the selection procedure: http://www.ripe.net/ripe/wg/lir/adress_council-election.html More information about RIPE 43 is available at: http://www.ripe.net/ripe/meetings/current/ripe-43/ Important Dates: 9 August 2002 - deadline for Address Council nominations 26 August 2002 - deadline to post list of nominees on the RIPE NCC website 9-13 September 2002 - RIPE 43 Meeting, Rhodes, Greece

2 1

KPNQwest ns.eu.net server.
by Daniel Diaz 06 Jun '02

06 Jun '02

Dear all, Given the current situation of KPNQwest and the possibility of its services going offline sometime soon, the RIPE NCC in agreement with KPNQwest will be temporally hosting this server (ns.eu.net) in its premises. This is to avoid major problems in the Internet as this server is secondary for a large number of ccTLD's zones, and thousand other zones. We (AS3333) will be soon announcing the 192.16.202.0/24 prefix. Trusting that this is welcome news. Best regards. -- RIPE NCC -- Daniel.Diaz Operations Manager RIPE NCC

13 16

Re: new swamp ?
by James Aldridge 05 Jun '02

05 Jun '02

Andre Stiphout wrote: > But in the case the pullups go, signifying the end of a network, and > there is no clear RIPE policy behind this, I suspect not many providers > will care about getting these customers renumbered if these customers > feel they retain sufficient global connectivity. The net result is an > increase of the size of the routing table. > > Is this detailed in the LIR contract or something and what is the value > of that contract if the LIR disappears, but the customers find > connectivity elsewhere? I think that ripe-185 is pretty clear on registry colsures: | If the registry is closing as a Local IR, but will continue to provide | Internet connectivity to its customers as an ISP, the customers can continue | to use the address space already assigned to them. Assignments made by a | registry that is closed remain valid for as long as the original criteria | under which they were assigned remains valid. | | If the registry will no longer provide Internet connectivity to customers with | assigned address space, the assigned address space should be retrieved from | the users as they renumber. It is the Local IR's responsibility to help its | customers with renumbering. and | In general a period of 3 months should be allowed for the end user to complete | the transition to the new addresses. RFC 2008 "Implications of Various Address | Allocation Policies for Internet Routing" [Rekhter96a] recommends a grace | period of at least 30 days, and no longer than six months. For exceptional | cases, where the end user requests to keep both assignments for more than 6 | months, approval should be obtained for the proposed time frame from the RIPE | NCC. James (Co-chair RIPE LIR-WG)

3 2

Re: new swamp ?
by James Aldridge 05 Jun '02

05 Jun '02

Pekka Savola wrote: > On Tue, 4 Jun 2002, Hank Nussbacher wrote: > > since they no longer exist. So I can imagine that KPNQwest space will > > languish in RIPE for a while (there are 4 KPNQwest entries listed at: > > http://www.ripe.net/ripencc/mem-services/general/allocs4.html countries: > > .at, .eu, .ee, and .it) > > Please also look for 'Eunet'. Which adds cz, fi, and fr as parts of KPNQwest, other "eunet" registries only have historical connections. There's also xlink and about 11 ebone/gts registries. James

1 0