- lir-wg - mailman.ripe.net

RIPE NCC Power Interruption
by RIPE NCC WebMaster 06 Mar '03

06 Mar '03

Dear Colleagues, At approximately 7 a.m. (CET) this morning, the RIPE NCC experienced a temporary power outage affecting external communications. Nuon, the RIPE NCC's electricity provider, began an immediate investigation and restored power to our facilities at approximately 11:15 am (CET). We apologise for any interruption or delay in service and communications. Should you have any concerns regarding this issue please contact <ops(a)ripe.net>. Regards, RIPE NCC Operations

1 0

RIPE NCC Ticketing System problems?
by Hank Nussbacher 06 Mar '03

06 Mar '03

Is it just me or is the Ticketing System query form hanging for others as well? http://www.ripe.net/cgi-bin/rttquery -Hank

1 0

RE: [ipv6-wg@ripe.net] Re: [lir-wg] IXP networks routing
by Michel Py 06 Mar '03

06 Mar '03

> Gert Doering wrote: > [text removed as discussion does not belong here] For the record, I actually agree with Gert's posting on this topic. Michel.

1 0

Cross posting
by David Kessens 06 Mar '03

06 Mar '03

This is request to keep the current discussions regarding ipv6 on the appropriate list and not to cross post to both the ipv6 and lir working group lists: - ipv6-wg Technical discussions regarding the deployment of ipv6 in the RIPE region - lir-wg policy discussion list including ipv6 allocation policies Thanks, David K. ipv6 working group chair person ---

2 1

IPv4 addresses update
by John L Crain 05 Mar '03

05 Mar '03

Dear Colleagues, As you may be aware the Regional Internet Registries have been active with the "Early Registrations Transfer [ERX] Project". As part of the preliminary investigations of this project and verification of the data by the IANA some /8s previously listed as "Various Registries" have now been designated as unused and as such will be listed in the IANA registries as "IANA Reserved". This update will take effect at http://www.iana.org/assignments/ipv4-address-space as of 23:59 UTC, 31 March 2003. The affected /8s will be listed as follows: 173/8 Apr 03 IANA - Reserved 174/8 Apr 03 IANA - Reserved 175/8 Apr 03 IANA - Reserved 176/8 Apr 03 IANA - Reserved 177/8 Apr 03 IANA - Reserved 178/8 Apr 03 IANA - Reserved 179/8 Apr 03 IANA - Reserved 180/8 Apr 03 IANA - Reserved 181/8 Apr 03 IANA - Reserved 182/8 Apr 03 IANA - Reserved 183/8 Apr 03 IANA - Reserved 184/8 Apr 03 IANA - Reserved 185/8 Apr 03 IANA - Reserved 186/8 Apr 03 IANA - Reserved 187/8 Apr 03 IANA - Reserved 189/8 Apr 03 IANA - Reserved 190/8 Apr 03 IANA - Reserved Comments can be sent to iana(a)iana.org. -- Best regards, John L. Crain mailto:crain@iana.org -- Best regards, John mailto:crain@iana.org

1 0

Abstract of proposed Internet Draft for Best Current Practice (please comment)
by Dr. Jeffrey Race 02 Mar '03

02 Mar '03

Interested parties are invited to provide comments to correct, elaborate or perfect my proposal, abstracted below. I'd also welcome suggestions for other fora in which to post requests for comments. I plan to offer as Internet Draft when comments are all in. Comments or objections to the effect "This is going to be burdensome on $spam_enabler" are superfluous because such is the precise intention of the proposed Practice: to move the burden from victims to polluters and their enablers. Thanks for all help. Jeffrey Race D_R_A_F_T BEST CURRENT PRACTICE FOR DUTY OF CARE OF INTERNET RESOURCES Pre-release version 1.32 Draft date: February 28, 2003 Drafted by Jeffrey Race <jrace[at]attglobal.net> Current draft version (4,000 words) available at <http://www.camblab.com/misc/univ_std.txt> ABSTRACT This document defines a Best Current Practice to minimize pollution of the Internet by various types of abuse, using the community's own measures in the absence of effective legal, regulatory and technical measures. The Internet's design and management were predicated on voluntary cooperation, self-imposed good behavior, and the non-profit motivational structure of participants extant at its inception. Current experience of constantly rising pollution invalidates these formative assumptions and demands prompt and effective curative measures. Present anti-pollution measures fall under four generic headings: (1) self-directed good behavior; (2) legal sanctions (3) passive ingress-control measures (principally filtering) and (4) active egress-control measures (principally blocklisting) intended to modify the behavior of polluters and enablers. The first three have definitively failed and will continue to fail for reasons specified in the document. The fourth is generally completely effective in warding off ingress of pollution and frequently results in reforming abuse enablers, but it has two major shortcomings: limited uptake due to fear of loss of competitive market position by early adopters, and sustained transmission outages ("collateral damage"). In view of the failure of (1), (2) and (3) and the effectiveness despite shortcomings of (4), the document proposes to apply to the Internet the same rules society applies to all other resources to deter antisocial behavior viz. proper behavior requires clear published standards, standards entail accountability, accountability entails multiple modes of enforceability, and enforceability entails traceability. The document details procedures and implementing mechanisms of behavior modification, using the only proven effective method: withdrawal of internet resources of identity and connectivity. Numerous tests have shown this sanction to work equally well against both the wilful and the negligent to halt pollution immediately, where prior efforts at polite persuasion to follow best practice were ignored with impunity. The proposal thus innovates in three respects to halt Internet pollution: (1) It makes explicit that every custodian of internet resources is responsible for preventing emission of pollution (2) Adopting a simultaneous universal practice of withdrawal of internet resources means that no provider will suffer competitive disadvantage. The Practice legitimates withdrawal of internet resources as the only method proven effective in halting abuse. (3) The burden of pollution now falls on the polluter and his enabler rather than on the victim, so conforming to the basic principle used everywhere else in society to maintain justice and good order. Well-managed, ethical members of the internet industry already conduct their businesses, successfully and profitably, according to the principles specified in the Practice. The proposed Practice simply aims to raise the entire industry to the level of today's best players. The Practice is intended to apply at every level of allocation, registration and usage of internet resources including but not limited to RIRs, LIRs, ISPs, webhosting firms, backbone connectivity providers, domain name registrars, and end-users. It defines internet resources, unsolicited bulk electronic messaging, and abuse, and specifies procedures progressively to penalize abuse after a period of public admonishment. In effect, the proposal implements the "user pays" paradigm in a completely new and clever way, without requiring any complicated metering technology all proposals for which have failed on issues of complexity, backward compatibility, absence of adequate hardware, and the need for universal adoption to be effective at all. The document embodies the only set of measures now on offer which will quickly end the spam menace internationally sans new legislation, with but small and transitory disruption, by abandoning the discredited "victim pays" model. Adoption will not only be cost-free for the Internet as a whole but will substantially reduce the current economic burden of abuse. It does this by transferring the economic burden from abuse victims to the polluters and their enablers, which is fair and feasible, and indeed the system used everywhere else in society. As such the anticipated vigorous objections to adoption from some parties may be seen in advance as self-serving attempts to perpetuate the discredited "victim pays" model by those now profiting from an Environmental Polluter business model or by their accessories and enablers. Finally, RFCs and Practices are often considered by Courts in adjudicating the existence or extent of tortious conduct. Therefore looking to the longer term, adoption of this Practice may be expected to bring a welcome rule of law to the Internet.

1 0

Re: [lir-wg] Assignment Procedures for multi-homed customers
by Kristofer Sigurdsson 26 Feb '03

26 Feb '03

Hi, Wilson Mehringer, Wed, Feb 26, 2003 at 03:09:03PM +0100 : > > Hi Kristofer, > > I thought that a customer can NOT get an AS# from Ripe without first becoming a LIR!! > Vise versa, he/she can become a LIR without necessarily getting an AS#. > Am I missing out on something?? Only LIRs can request an AS, but they can request one for someone else. The only requirements for a new AS is that a) they have some address space to announce and b) they can specify a minimum of two existing AS's that the new one will peer with. Here's a quote from "Autonomous System (AS) Number Assignment Policies and Procedures" (http://www.ripe.net/ripe/docs/asn-assignment.html) "The RIPE NCC assigns AS Numbers for Autonomous Systems located in the RIPE NCC service region and only accepts requests for AS Numbers from LIRs. LIRs may request AS Numbers on behalf of other organisations. ". You're right about the latter part, though. A LIR does not have to have an AS. It is quite common for LIRs to have their own AS, but by no means necessery. An AS is simply a technical requirement to be able to peer with other entities, in order to exchange dynamic routing tables. On the other hand, being a LIR is a far bigger thing, a Local Internet Registry. LIR's are typically providers who can request allocations from RIPE and then furthermore assign IP numbers to their customers, and well...be an Internet Registry. :-) -- Kristófer Sigurðsson Nethönnun ehf.

1 0

Re: [lir-wg] Assignment Procedures for multi-homed customers
by Wilson Mehringer 26 Feb '03

26 Feb '03

Hi Kristofer, I thought that a customer can NOT get an AS# from Ripe without first becoming a LIR!! Vise versa, he/she can become a LIR without necessarily getting an AS#. Am I missing out on something?? Wilson >>> Kristofer Sigurdsson <kristofer(a)nh.is> 02/26/03 02:15pm >>> Hi, Gernot Schwalm, Wed, Feb 26, 2003 at 01:52:25PM +0100 : > Hi, > > we have a customer who wants to be multihomed in the near future and > therefore needs/wants his own AS. Will he get his own PA-Allocation then or > do we have to request PI-Space for him? There is nothing unusual about announcing PA address space, even if it's not yours (as long as the LIR in question permits it), so your customer should simply go ahead and request for an AS (well, only LIR's can request an AS, but there is nothing wrong with a LIR requesting one for a customer). The LIR would then make the assignment origin in the customer's AS. However, you might want to make your customer sign a legal contract to clearify this point, i.e. that the address space belongs to the LIR, not the customer, in case they want to switch to another upstream provider. -- Kristófer Sigurðsson Nethönnun ehf.

3 2

Assignment Procedures for multi-homed customers
by Gernot Schwalm 26 Feb '03

26 Feb '03

Hi, we have a customer who wants to be multihomed in the near future and therefore needs/wants his own AS. Will he get his own PA-Allocation then or do we have to request PI-Space for him? Thanks in advance, Gernot Schwalm -- noris network AG / Kilianstrasse 142 \ 90425 Nuernberg Tel. 0911-9352-0 / Fax 0911-9352-100 \ info(a)noris.net ~

2 1

RIPE 44 Meeting Report
by Nick Hyrka 19 Feb '03

19 Feb '03

(Apologies for any duplicate mails.) Dear Colleagues: The RIPE 44 Meeting was held recently at the Krasnapolsky Hotel from 27 - 31 January 2003 in Amsterdam. There were a total of 360 attendees comprised of the RIPE NCC membership, the RIPE community and government representatives. Attendees also included representatives from APNIC, ARIN, LACNIC, and ICANN. Members from the U.K. had the highest number of representatives (53), followed by Germany (50), the Netherlands (37) and the U.S.A (42). Additionally, there were more representatives from Eastern European countries than ever before. Highlights of RIPE 44 included the open discussion during the Plenary on the RIPE NCC 2002 membership survey results, the first report by LACNIC after being granted official RIR status, and the first webcasting trial of the RIPE 44 sessions held in the Grand Ballroom. Version 1.0 of the RIPE NCC LIR Portal was also showcased at RIPE 44. Portal features and benefits were noted at a presentation given at the LIR and Tools Working Groups sessions. The RIPE NCC would like to thank SURFnet, Afilias, NIKHEF, KPN EuroRings, and AMSIX for the support they provided to the meeting. A summary of the RIPE 44 highlights follows: LIR === * Denesh Bhabuta (Aexiomus Limited) stepped down as co-chair of the LIR Working Group. Gert Döring (SpaceNet) and Andrea Borgato (I.Net S.p.A.) were selected as new co-chairs. * A search for a new name for the LIR Working Group was started. Rob Blokzijl (RIPE Chair) will publish a proposal for a new name. * The LIR Working Group Chairs will draft a new charter for the working group. * The sub-allocation policy document was approved. No changes were made. * A task force and mailing list was formed to investigate changes to the PI policy. * The RIPE NCC was tasked to publish a draft document on status values in inetnum objects. DATABASE ========= * IPv6 support for querying the Whois Database has been implemented. * References by name have been cleaned from the database and an organisation: object was proposed. * The RIPE NCC was tasked to: - document the mirroring protocol and its operational requirements. - add inverse lookups to all attributes that have integrity constraints. - propose and implement "reclaim:"-like functionality to the database. - add contact data to key-cert objects. IPv6 === * Enhanced IPv6 support for the new IPv6 Whois proxy has been implemented. * Test Traffic Measurement test-boxes now fully support IPv6. * Gert Döring (SpaceNet) proposed discussions to enable IPv6 access to the root servers and AAAA records for TLD in the root zone. * Bernard Tuy (RENATER) was tasked to co-ordinate an IPv6 routing guideline document. * The RIPE NCC was tasked to: - enable reverse delegation for 6bone under ip6.arpa. - investigate increasing the size of RIR allocations to rationalise routing with the IANA. ROUTING ======= * Joao Silva Damas (ISC) was announced as co-chair of the Routing Working Group. A second co-chair is being sought. * The Routing Registry Consistency Check utility implemented by the RIPE NCC was finalised. The source code is available on the RIPE NCC ftp server at: ftp://ftp.ripe.net/ripe/dbase/software/RRCC-0.2.tar.gz * A list of IP address space allocated by the RIPE NCC, useful for filtering unallocated address space on routers, was published on the RIPE NCC ftp server at: ftp://ftp.ripe.net/ripe/stats/issued/ * As a part of the RIS Beacon Project the RIPE NCC was tasked to look into the behaviour of a second BGP announcement whilst the first one has not yet converged. * The RIPE NCC was tasked to analyse RIS data to approximate how much of the Internet is seen by RIS route collectors. DNS ==== * Johan Ihren (Autonomica AB) presented a proposal for experimentally signing the root-zone. The RIPE NCC was tasked to discuss the idea with the RIRs and propose technical and political recommendations. * Andrei Robachevsky (RIPE NCC) presented a report on IPv6-related DNS issues. The RIPE NCC requests feedback on freezing delegations in the ip6.int space, reverse 6to4 delegations and support of 6bone space reverse delegations under ip6.arpa. TTM & RESEARCH =============== * A new Chair is being sought for the Test Traffic Working Group. * Test Traffic Measurement test-boxes now fully support IPv6, making TTM the first measurement product on the market to do so. * CDMA is now fully supported as an alternative clock source. * Mailing list discussions have begun on upgrading TTM to the IPv6 version as well as on new business models for TTM. TECHSEC ======== * Erik Rozendaal (NLnet Labs) presented a new project at NLnet Labs called Donkey. It intends to provide a general purpose distributed public key database. The presentation can be found at: http://www.ripe.net/ripe/meetings/archive/ripe-44/presentations/ripe44-tech… ANTI-SPAM ========= * More spam problems with proxies than open relays were reported. * Assured Path Messaging was noted as a possible alternative e-mail service. PRESENTATIONS ============== * SQL Slammer Worm Attack / Rene Wilhelm (RIPE NCC) - Analysis of data collected around the time of this attack, showing clear effects but also that most of the Internet backbone infrastructure survived: http://www.ripe.net/ripe/meetings/archive/ripe-44/presentations/ripe44-tt-s… * Improved Secure Communication System for RIPE NCC Members / Andrei Robachevsky (RIPE NCC) - An initial proposal was presented on how to improve the current system by using a X.509-based PKI model: http://www.ripe.net/ripe/meetings/archive/ripe-44/presentations/ripe44-plen… * The RIPE NCC LIR Portal v.1 / Leo Vegoda and Manuel Valente (RIPE NCC) - The new portal services features were explained in a live demonstration: http://www.ripe.net/ripe/meetings/archive/ripe-44/presentations/ripe44-lir-… TUTORIALS ========= * The RIPE NCC IP Request Tutorial, given by the RIPE NCC staff, was presented. It explained address space assignment and allocation procedures in the RIPE NCC region: http://www.ripe.net/ripe/meetings/archive/ripe-44/tutorials/ * The NetFlow Services tutorial, given by Benoit Claise (Cisco Systems), on reviewing the design, configuration, tuning and troubleshooting of NetFlow versions was presented during the EOF: http://www.ripe.net/ripe/meetings/archive/ripe-44/presentations/ripe44-eof-… * The BGP Troubleshooting tutorial, given by Philip Smith (Cisco Systems), covering common problems ISPs face when deploying BGP within their networks was also presented during the EOF: http://www.ripe.net/ripe/meetings/archive/ripe-44/presentations/ripe44-eof-… FIRST RIPE MEETING WEBCASTING ============================ The first RIPE Meeting webcast was held at RIPE 44. Recordings of sessions held in the Grand Ballroom have been archived and can be accessed at: http://www.ripe.net/ripe/meetings/archive/ripe-44/multicast.html HOSTMASTER CENTRE ================== The RIPE NCC Hostmaster Centre was open during RIPE 44. The centre continues to be a useful facility for the meeting attendees and will be provided at RIPE 45. RIPE 44 REFERENCE PAGE ====================== A complete list of RIPE 44 sessions, tutorials and presentations can be found at: http://www.ripe.net/ripe/meetings/archive/ripe-44/ RIPE 45 ====== RIPE 45 will be held in Barcelona, Spain from 12 to 16 May 2003. Information on RIPE 45 will be available at: http://www.ripe.net/ripe/meetings/ripe-45/ New LIRs please note: LIRs who signed up in 2002 are entitled to two (2) free tickets to attend RIPE 45. The tickets cover registration only and do not apply to the RIPE dinner, your travel or hotel accommodations. More information on the new LIR tickets can be found at: http://www.ripe.net/ripe/meetings/ripe-45/new-lir.html Or contact <meeting(a)ripe.net>. END

2 1