- lir-wg - mailman.ripe.net

RIPE 45 Meeting Report
by Nick Hyrka 05 Jun '03

05 Jun '03

(Apologies for any duplicate mails.) RIPE 45 Meeting Report Dear Colleagues: The RIPE 45 Meeting was held at the Hotel Fira Palace from 12 - 16 May 2003 in Barcelona, Spain. There were a total of 322 attendees comprised of the RIPE NCC membership, the RIPE community and government representatives. Attendees also included representatives from APNIC, ARIN, LACNIC and ICANN. HIGHLIGHTS ========== Highlights of RIPE 45 included the open discussion during the Plenary on the services of the RIPE NCC; an ICANN update by Paul Twomey, President and CEO of ICANN; the proposal to split and rename the LIR Working Group into the RIPE NCC Services Working Group and the Address Policy Working Group; the deactivation of the Tools and NetNews Working Groups; and the second phase of RIPE Meeting webcast trials. Paul Wilson, APNIC Director General, provided a presentation on RIPE 261 that proposes reorganising the distribution of IPv6 allocations "from the root" to LIRs. RIPE 261, "IPv6 Address Space Management", can be found at: ftp://ftp.ripe.net/ripe/docs/ripe-261.txt Daniel Karrenberg, Chief Scientist, RIPE NCC, spoke on the measurement activities and statistics performed by the RIPE NCC, referencing RIPE 271, "RIPE NCC Hostcount in the 21st Century". He noted the benefits and necessity of these activities and requesting support from the community. RIPE 271 can be found at: http://www.ripe.net/ripe/docs/hostcount.html "ROSIE", the RIPE On-site Information Exchange, was also launched at the meeting. ROSIE provided up-to-date meeting information and resources to RIPE Meeting attendees and will be featured again at RIPE 46. The RIPE NCC would like to thank RedIRIS, CESCA, SATEC, FocusPoint, MFN, SURFnet and NRN for the support they provided to the meeting. SUMMARY ========= LIR === - The LIR Working Group will split into two groups. The policy-making function will move to the new "Address Policy Working Group" and the RIPE NCC services reviewing function will be moved to the "RIPE NCC Services Working Group". Kurt Erik Lindqvist, Netnod CEO, has agreed to chair the new "RIPE NCC Services Working Group". The LIR WG mailing list will remain active during the transition phase. - The RIPE NCC presented its plans for improved secure communication (via X.509 PKI) with RIPE NCC members: http://www.ripe.net/ripe/meetings/ripe-45/presentations/ripe45-lir-pki/ A discussion document has been published at: http://www.ripe.net/ripe/draft-documents/pki-20030429.html DATABASE ========= - Wilfred Woeber, UniVie-ACOnet and DB WG Chair, requested feedback from the community on changes to the "status:" attribute and their impact on scripts. - The RIPE NCC will look into the possibility of dbupdate accepting updates with the usual indentation inserted by most mail clients. - The RIPE NCC will also review a request on allowing users more access to its code. - Wilfred Woeber proposed a discussion for the DB mailing list on revising the charter for the DB Working Group. IPv6 ==== - Gert Doering, SpaceNet AG, provided a global v6 routing update noting fewer undesired prefixes leaking into the global routing tables; a decline in 6bone prefixes being routed; and a corresponding increase in RIR v6 space being routed. - John Crain, ICANN, spoke on the RIR/ICANN discussion to replace the current /23 prefix delegation procedure to facilitate automatic filtering of addresses per RIR. (See RIPE 261.) - ICANN is testing implementation of "AAAA" records in the root server system to start this summer and will produce a document in co-operation with RSSAC. Production use is pending approval by the U.S. Department of Commerce. - It was noted that the cut off date for allocating 6bone pTLAs is 1/01/2004. The phase out date of 6bone address space is 6/06/2006. - The RIPE NCC was tasked to enable IPv6 for future RIPE Meeting webcasts. ROUTING ======== - Two approaches to secure BGP were presented and discussed. Stephen Kent, Chief Scientist - Information Security at BBN Technologies, provided a presentation on how RIRs put secure BGP implementation into production: http://www.ripe.net/ripe/meetings/ripe-45/presentations/ripe45-routing-sbgp/ And David Cook, CISCO, provided a presentation on soBGP: http://www.ripe.net/ripe/meetings/ripe-45/presentations/ripe45-routing-sobg… DNR FORUM =========== - After a proposal by Rob Blokzijl, RIPE Chair, the RIPE Working Group Chairs agreed to combine future DNS WG and the DNR Forum sessions into the "DN*" Working Group, beginning at RIPE 46. DNS ==== - Presentations regarding lameness followed by a panel discussion on technical and policy issues were provided. It was noted that lameness checks, on the reverse tree in particular, might become a working group item. The discussion was moved to the DNS mailing list. TTM ==== - Daniel Karrenberg, Chief Scientist, RIPE NCC, spoke on re-focusing the measurement activities performed, and the statistics presented, by the RIPE NCC. Referencing RIPE 271, he noted the benefits of these activities and the importance for the community of access to unbiased and credible data about the overall operation of the Internet. He requested community support for this new approach to RIPE NCC measurement activities. RIPE 271 can be found at: http://www.ripe.net/ripe/docs/hostcount.html - Florian Frotzler, RIPE NCC intern, presented his thesis on the effects of IPv6. This was of special interest to those attempting to build native v6 networks: http://www.ripe.net/ttm/Documents/Various/ffrotzler.pdf TECHSEC ======== - A discussion on draft-ietf-dnsop-interim-signed-root-01.txt was held. Comments are to be posted to the DNSEXT mailing list. - A status update on DISI (Deployment of Internet Security Infrastructures) was provided: http://www.ripe.net/ripe/meetings/ripe-45/presentations/ripe45-techsec-disi/ ANTI-SPAM ========== - Unsolicited Broadcast E-mail (UBE) volume greatly increased in the last three months with ISPs expecting the UBE load to become a serious technical problem for them by the end of 2003. - The working group was tasked to develop a "best practice advice" on defensive measures against UBE. EIX === - It was noted that the EIX Working Group session at RIPE 46 will be in two parts: The first session will be orientated towards ISPs with a series of presentations from IXPs discussing recent trends and statistics in a regular format. The second session will focus on IXPs with presentations on technical, operational and commercial issues that affect IXPs in the RIPE community. EOF ==== - The European Operators Forum convened Monday and Tuesday at RIPE 45. Emphasis was on inter-domain routing and BGP security. A discussion on how to develop the EOF from its current state at future RIPE Meetings was also held. TUTORIALS ========= - The RIPE NCC staff presented the RIPE NCC IP Request Tutorial. It explained address space assignment and allocation procedures in the RIPE NCC region: http://www.ripe.net/ripe/meetings/ripe-45/tutorials/ip-tutorial/ - A tutorial on the "myAS" system, which allows users to devise a control/notification system for BGP route propagation in real-time, was provided at RIPE 45: http://www.ripe.net/ripe/meetings/ripe-45/presentations/ripe45-tt-myas/ RIPE MEETING WEBCASTING ======================= - The second phase of RIPE Meeting webcasting trials was held at RIPE 45. Recordings of sessions have been archived and can be accessed at: http://www.ripe.net/ripe/meetings/ripe-45/webcast-archive.html HOSTMASTER CONSULTATION CENTRE (HCC) ==================================== - The RIPE NCC Hostmaster Centre was open during RIPE 45. The centre continues to be a useful facility for the meeting attendees and will be provided at RIPE 46. Later consultation hours were successfully introduced at RIPE 45 and will be repeated at RIPE 46. "MEET & GREET" ============== - The RIPE NCC's "Meet & Greet" desk was available for first time RIPE Meeting attendees at RIPE 45. "Meet & Greet" was introduced at RIPE 44 and introduces newcomers to the meetings, to key attendees of the RIPE community and to social events throughout the week. RIPE 45 REFERENCE PAGE ====================== - A complete list of RIPE 45 sessions, tutorials and presentations can be found at: http://www.ripe.net/ripe/meetings/ripe-45/index.html RIPE 46 ====== - RIPE 46 will be held in Amsterdam, the Netherlands from 1 to 5 September 2003. Information on RIPE 46 will be made available later this month at: http://www.ripe.net/ripe/meetings/ripe-46/ RIPE NCC GENERAL MEETING ======================== - The RIPE NCC Executive Board has announced that the 2003 annual General Meeting will be held adjacent to the RIPE 46 Meeting in Amsterdam from 14.00 to 17.00 on Friday, 5 September 2003. For more information about RIPE NCC annual General Meetings, please see: http://www.ripe.net/ripencc/about/gm/ New Local Internet Registries (LIRs) please note: - LIRs who signed up in 2002 are entitled to two (2) free tickets to attend RIPE 46. 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

1 0

RE: [lir-wg] Discussion about RIPE-261
by Michel Py 05 Jun '03

05 Jun '03

> Kurt Erik Lindqvist wrote: > Agreed. The flaws of IPv6 comes down to not solving the > multihomign/routing scaling/world starvation problem. > That is an IETF problem, and there is a WG for it. For the record, and the following are verifiable _facts_: the IRTF and the IETF have been working on this problem for the last ten years. One of the Area Directors responsible for the multi6 WG has called it the "Titanic". By Kurtis' own account it is going to be 5 to 10 more years before they find a solution, if they do. The WG that Kurtis co-chairs has not even agreed to _requirements_ that were due two years ago; they are calling it recommendations now with zero proposals on the table. Anyone that wants to have a glimpse of what the IETF is going to do for them is encouraged to read Kurtis' own draft: http://www.ietf.org/internet-drafts/draft-kurtis-multihoming-longprefix- 00.txt Which basically says that we should allow /48 prefixes punched from PA space in the Global Routing Table. I am sure the educated reader that subscribes to this list will appreciate, especially smaller LIRs that can't afford a c12416 or M160 to hold a huge routing table. Michel.

6 17

Re: Improvements to database update software
by DB-News 04 Jun '03

04 Jun '03

Dear Colleagues, [apologies for duplicate messages] This is to announce that the transition period for the introduction of new database update software is over. This means that the mail boxes auto-dbm-old(a)ripe.net and auto-dbm-new(a)ripe.net are not available any more and all update messages to auto-dbm(a)ripe.net will be processed by the new database update software. Best regards, -- Engin Gunduz RIPE NCC Database Group -- DB News wrote 23 Apr 2003: > > [apologies for duplicate messages] > > Dear Colleagues, > > The Database Group at the RIPE NCC has been working on restructuring > the dbupdate program. This is the part of the RIPE Whois server that > processes update requests from users. > > The main goal has been to improve the acknowledgement messages that > users receive from the RIPE Whois Database and provide clearer error > reporting and authorisation information. We have also been able to > make the software easier to maintain and modify. This will reduce the > time spent fixing bugs and adding new features. > > Details may be found here: > > http://www.ripe.net/db/dbupdate/ > > A page further explaining the new acknowledgements can be found here: > > http://www.ripe.net/db/dbupdate/acknowledgments.html > > The new dbupdate messages have a different format. Therefore a phased > approach to introducing the new server has been taken. For a period we > will use the new dbupdate in parallel with the old one. This will > allow people using automated tools time to update their software. > > PRE-MIGRATION > Before the new dbupdate was available. > > auto-dbm-old(a)ripe.net DOES NOT EXIST > auto-dbm(a)ripe.net --> old dbupdate > auto-dbm-new(a)ripe.net DOES NOT EXIST > > DAY-X, Wednesday, 23 April, 2003 > The new dbupdate is available but must be requested specifically. > > auto-dbm-old(a)ripe.net --> old dbupdate > auto-dbm(a)ripe.net --> old dbupdate > auto-dbm-new(a)ripe.net --> new dbupdate > > DAY-Y, Wednesday, 7 May, 2003 > The new dbupdate is the default but the old dbupdate may be requested > specifically. > > auto-dbm-old(a)ripe.net --> old dbupdate > auto-dbm(a)ripe.net --> new dbupdate > auto-dbm-new(a)ripe.net --> new dbupdate > > DAY-Z (POST-MIGRATION), Wednesday, 4 June, 2003 > The old dbupdate is no longer available. > > auto-dbm-old(a)ripe.net DOES NOT EXIST > auto-dbm(a)ripe.net --> new dbupdate > auto-dbm-new(a)ripe.net DOES NOT EXIST > > > Best regards, > > -- > Shane Kerr > Database Group > RIPE NCC

1 0

RE: [lir-wg] Discussion about RIPE-261
by Michel Py 02 Jun '03

02 Jun '03

Pekka, >> [ ] go for a full multi-level regional distribution, down to >> "one /32 per LIR per country" (as detailed by Michael Py) > Pekka Savola wrote: > This seems to have issues e.g. for multinational LIR's I was hoping someone from the very large LIRs to comment on this. > as well as when new countries are born and die. > But maybe the issues could be worked out.. There is slack space in each zone for this very purpose; some issues could not be worked out though. If China or India were to split into two equal-size countries, we would have a problem. However, short of this kind of radical change, the rest could be handled. I have inventoried the following situations: New country: ------------ Example: East Timor. What we have here is a smaller part of a larger country that splits. Should something similar happen, the way to handle it is very simple: The larger part keeps their block, we allocate a block from the slack to the newly created country; pick a RIR to have stewardship of the new country. It is obvious that renumbering will occur in the newly created country although I will point out that the kind of event that leads to this is a civil war and it is likely that the new country will want to cut ties anyway. So if Kurdistan or Cashmere were to become countries we would not have a problem. Merge: ------ Example: Germany. Countries do not die, they become part of another country or merge and yes this does happen. When it does, a choice will have to be made between the following solutions: a) A new block is allocated to the new country and the two old blocks are returned to the free pool when everyone has renumbered. b) The new country keeps the two existing blocks. The only issue doing this is that instead of a single route to the new country there needs to be two routes, which is not a big deal. c) We were clever enough to put merge candidates consecutively so we just have to extend the prefix. IMHO, a) is not going to happen so we are looking at b) and possibly c). Which means that as an enhancement we need to pair merge candidates. For example, it would be a good idea to allocate space to North and South Korea in an aggregatable fashion should they merge later (I picked this example because it has similarities with Germany). Michel.

2 1

RE: [lir-wg] Discussion about RIPE-261
by Michel Py 02 Jun '03

02 Jun '03

> Kurt Erik Lindqvist wrote: > Personally I believe more on a solution based on > location/identifier separation. For the record, that's what MHAP is. Michel.

3 3

RE: [lir-wg] Discussion about RIPE-261
by Michel Py 01 Jun '03

01 Jun '03

Gert, > Gert Doering wrote: > The *benefit* of "/48 multihoming" is that you can filter those > routes if you don't want to see them - then your routers will > send packets down the /32 road, and eventually hit a router > that knows about the /48 (which is why I consider this approach > superior to "everybody gets a independent prefix", which I can't > properly aggregate). This does _not_ work in at least two cases: - If someone implements RPF checks and someone else filters. - If the primary ISP (the one that announces the /32) dies. The site is dead as well. This is the #1 reason why organizations do multihome: they want to be up even if their primary ISP tanks. Please look at the following (4 slides, very short) http://arneill-py.sacramento.ca.us/ipv6mh/pa_holes.ppt Then come back to me and tell me that PA holes and filtering work together. The slides should be self-explanatory but they were designed for live presentation. I do welcome questions. Michel.

4 5

Correction of previous Notice
by Paul Rendek 30 May '03

30 May '03

CORRECTION TO PREVIOUS NOTICE Call for Nominations: RIPE Representative to the ASO Address Council Dear Colleagues, On 30 May 2003, an announcement from our office regarding the ASO Address Council elections incorrectly stated that the deadline for nominations was 3 June 2003. Please note that the deadline for nominations is 2 August 2003. * Deadline for nominations: 2 August 2003 * Election scheduled for: 4 September 2003 The selection process will involve an open election to be held during the RIPE 46 Meeting in Amsterdam, the Netherlands, being held from 1 - 5 September 2003. For full details on the position and how to make a nomination, please refer to: http://www.ripe.net/ripencc/about/regional/aso2003/ and http://www.ripe.net/ripe/wg/lir/adress_council-election.html We appreciate your understanding and apologise for any confusion caused by the previous notice. Best regards, Paul Rendek RIPE NCC

1 0

ASO AC - Call for Nominations 2003 - RIPE Region
by Paul Rendek 30 May '03

30 May '03

Call for Nominations: RIPE Representative to the ASO Address Council ___________________________________________________________ This is a call for nominations of individuals from the RIPE region to serve on the ASO Address Council. On 31 December 2003, one RIPE Address Council seat will become vacant and will be filled for the next three years by an individual nominated through this open call. The selection process will involve an open election to be held during the RIPE 46 Meeting in Amsterdam, the Netherlands, being held from 1 - 5 September 2003. * Deadline for nominations: 3 June 2003 * Election scheduled for: 4 September 2003 For full details on the position and how to make a nomination, please refer to: http://www.ripe.net/ripencc/about/regional/aso2003/ and http://www.ripe.net/ripe/wg/lir/adress_council-election.html Best regards, Paul Rendek RIPE NCC

1 0

Re: [hm-staff] Re: [lir-wg] Discussion about RIPE-261
by Kurt Erik Lindqvist 29 May '03

29 May '03

> Hi! >>>> I guess this would only work with RIPE who have the >>>> concepts of LIRs but anyway. >>> >>> I don't know how to parse this? All RIRs have the concept of LIR? >> >> Well in one way or the other - yes. But every-time I use the term LIR >> in Asia or the US people get confused and I get told that there is no >> such thing as a LIR in APNIC/LACNIC/ARIN. > > Just for the record... > > The term LIR is used in the APNIC region and is documented in the > APNIC IPv4 policy document in Section 4.1.3. I have actually never checked this, but people have repeatedly told me that they didn't know the terminology so I just assumed this. I guess I should have checked. Thanks for telling me though! Best regards, - kurtis -

1 0

RE: [lir-wg] Discussion about RIPE-261
by Michel Py 29 May '03

29 May '03

Carlos, > Carlos Morgado wrote: > Other people have already mentioned on the list memory/cpu isn't > an issue on this day and age. You definitly don't need a c12k to > carry a full routing table today. This is not what vendors are saying. I presented just after Jeff Doyle from Juniper 3 weeks ago and he was very specific about this. I extracted that one slide here: http://arneill-py.sacramento.ca.us/ipv6mh/j.ppt Let's face it: I'm sure that Juniper would love to keep selling big routers. They are telling us they can't guarantee they will keep up increasing memory and CPU, so we do have an issue with memory/cpu. Michel.

4 4