October 2001 - lir-wg - mailman.ripe.net

RE: Multihoming - Resilience or Independence
by Boyan Krosnov 11 Oct '01

11 Oct '01

> Your prefixes (let's say /24) has to be announced by two ISPs > so the packets > will come back to you. If ISP A's link failed then that /24 > with ISP A in > the > ASPATH will be withdrawn. And ISP B's /24 will become active. > So in the > global > routing table there will be TWO /24 with different ASPATH. > > If this /24 is in ISP A's PA space then it saves one but the > one from ISP > B's one > NEEDs to be in the global routing table. Either I didn't understand you right, or you were wrong. It does not save a route in the DFZ. Let's say the customer gets A/24 out of proider A's A/17 prefix. B has to announce A/24 to the internet along with it's current prefixes. A has to announce A/17 AND A/24 to the internet. If A advertises A/17 only all the traffic for A/24 will go through B (because of the longest match rule), and I think that's not what that customer wants. So Being multihomed to two ASs with NAT or two addreses on each host does not create an extra route in the DFZ. Being multihomed to a single AS does not create an extra route in the DFZ. Being multihomed to two ASs (It doesn't matter PA or PI, separate AS or anounced by the two ASs. Prefix out of PA, separate AS is generally recognised to be the better technical solution.) does create at least 1 extra prefix and 2 extra as-paths in the DFZ. These are the facts about growth of the DFZ routing table caused by multihoming as I see them. There are of course other reasons for the growth like providers advertising 14 separate /24s when they can agregate it to /20 because "We were trying to do some input channel load balacing and have left this anouncements for months because our administrator does not have the time to deal with this thing, he/she has more important work to do". Now it's time to think how we can make people prefer the first 2 possibilities over the third. We've had enough of technical discussion I think. Regards, Boyan Krosnov, CCNP Network Administrator Lirex Net phone: +359-2-91815

1 0

changed attribute proposal and not only
by Andrei Robachevsky 11 Oct '01

11 Oct '01

Dear Colleagues, Please find enclosed the proposal of modification of the changed attribute that was presented at the RIPE-40 meeting in Prague. However, another proposal (or rather idea) came up in light of recent discussions regarding timestamping and cleanup procedures in the RIPE Database. Let me present you this idea first. As was pointed by the two proposals there is a need to store and display status information about an object in the database, such as last update time, number of references, etc. At the same time in order to be reliable this information should be automatically generated by the database software and be outside users' control. Regarding "changed attribute" proposal people felt that this changes some of the basic principles of the RIPE Database. Recent Ulf's proposal makes things even worse since it requires that modification to an object may be caused by an update of another object. But in fact these attributes/facilities do not represent an object, but rather status information about the object. Extending Ulf's analogy with the Unix FS, they are part of the inode, not the data blocks. So status information (object metadata) may be stored and displayed separately from the object itself by, say, using a flag. Much like we display the contents using cat, but status using ls. And this information will be used for cleanup procedure, reliable timestamping, etc. This will not affect any object template, preserve users' data and add flexibility to the database. Something like this: $ whois -q meta RC1234-RIPE ... person: Referenced Contact nic-hdl: RC1234-RIPE ... changed: refcon(a)somedom.dom 20011005 source: RIPE %metainfo: RC1234-RIPE %update-time: 2001-10-05 16:50:07 %ref-time: 2001-10-06 09:17:33 %ref-count: 3 Regards, Andrei Robachevsky DB Group Manager RIPE NCC

1 0

40.5: RFC 2050 mailinglist
by Hans Petter Holen 10 Oct '01

10 Oct '01

Dear lir-wg, At the meeting in Praha we briefly discussed how to contribute to the global effort to revise RFC 2050. We were informed that ARIN had set up a working group for this, with a mailing list. It was suggested that we might join the mailing list hosted by ARIN to participate in this work, thus forming a truly global effort on the matter. Ray Plzak the President of ARIN invited the RIPE community to do so. After positive reactions from the participants, and no voices against, the chair declared consensus on this matter. The details of the list is: * List Address: 2050-wg(a)arin.net * Subscription is open to all interested parties * List is archived More information about the list is available at: http://www.arin.net/members/mailing.htm The charter from ARINs announcement: "The objective of the RFC 2050 Working Group is to address the issues relating to relevance of RFC 2050 to the needs of today's Internet registry system. The group will evaluate RFC 2050 and propose a method of replacing it with a new document or documents. Once consensus has emerged on the process that will be used to replace RFC 2050, the working group will cooperatively develop its replacement. The working group will work in coordination with the other Regional Internet Registries, who will conduct a similar review process in their respective regions. " Hans Petter Holen WG Chair ARIN announcement: http://www.arin.net/mailinglists/arin-announce/0121.html From: Member Services (memsvcs(a)arin.net) Date: Mon Sep 10 2001 - 11:24:00 EDT ---------------------------------------------------------------------------- ---- At the last ARIN Open Policy meeting in San Francisco concerns were raised about RFC 2050. It was noted that this document has aged and that certain portions of it no longer reflected the current state of RIR policy and operations. Similar concerns have been raised in the APNIC and RIPE NCC regions. Accordingly, ARIN is establishing a working group to further examine this issue. Mark McFadden has volunteered to chair the 2050WG. The charter for the working group follows: The objective of the RFC 2050 Working Group is to address the issues relating to relevance of RFC 2050 to the needs of today's Internet registry system. The group will evaluate RFC 2050 and propose a method of replacing it with a new document or documents. Once consensus has emerged on the process that will be used to replace RFC 2050, the working group will cooperatively develop its replacement. The working group will work in coordination with the other Regional Internet Registries, who will conduct a similar review process in their respective regions. An email list for the 2050WG has been established. Subscription information can be found at the following URL: http://www.arin.net/members/mailing.htm All interested individuals are encouraged to participate in this discussion. This will be an agenda item at the next ARIN Open Policy meeting in Miami. Ray Plzak President

1 0

RE: Multihoming - Resilience or Independence
by BLOCKI,JACEK (HP-Poland,ex1) 10 Oct '01

10 Oct '01

Hi, It seems multihoming discussion is an example of vicious circle (sp): More specific routes result in larger routing table but we want those routes and small table... Let me suggest a blasphemy: CIDR being advertised from two ASes. They say it should be only one, but why? In my opinion there is nothing wrong in advertising CIDR from two ASes as long as you can guarantee each border router advertises CIDR only if it can reach it. Imagine the following construction: AS-A--\ +(OSPF) --(CIDR) AS-B--/ Each BGP speaker advertises CIDR if and only if it learned about it from OSPF. It can be done, if you don't know how I'll forward you a working example. Each border router generates a default router and injects it into OSPF. From technical point of view I see no reasons why it should not work. What you need is: * An agreement between ISPs * Change in procedure making such a union of ASes an officially blessed solution so nobody would dare to hinder cooperation with filters. * Optionally you may need a separate CIDR, since both ASes have to advertise same prefix. You need it if each ISP wants to have private customers in addition to shared ones. The customer has "an independent connection to two ISPs" which is the quest item. I see more commercial than technical problems with such a solution. However my expertise is limited and somebody can point drawbacks I cannot see. Feel free to burn me on a stake, that's the right way of treating a blasphemy ;-) Regards, Jacek

1 0

RE: Multihoming - Resilience or Independence
by Lu, Ping 10 Oct '01

10 Oct '01

> -----Original Message----- > From: Steven Bakker [mailto:steven@icoe.att.com] > Sent: Wednesday, October 10, 2001 11:08 AM > To: Nipper, Arnold > Cc: Stephen Burley; Gert Doering; Dave Pratt; lir-wg(a)ripe.net; > routing-wg(a)ripe.net > Subject: Re: Multihoming - Resilience or Independence > > > On Wed, 2001-10-10 at 15:24, Nipper, Arnold wrote: > > Of course another prefix and another AS is added to the > routing table > > but thereby you are witdrawing at least more than two (both > prefs as well as > > AS). ==> table gets smaller. > > Your math is confusing... or maybe I'm misunderstanding the obvious. > Yes, multihoming adds another AS and (at least one) (longish) > prefix to > the routing table. But in your reasoning, which two prefixes > and one AS > are being withdrawn? If I resiliently multi-home to one ISP, > and I get > my address space from its block, I do not add any prefix or AS to the > (global) routing table. Even if I multi-home to two ISPs and > selectively NAT depending on the outgoing connection, I'll be NAT-ing > into the respective ISP's address space (which I presume is properly > aggregated), adding no prefix or AS. Your prefixes (let's say /24) has to be announced by two ISPs so the packets will come back to you. If ISP A's link failed then that /24 with ISP A in the ASPATH will be withdrawn. And ISP B's /24 will become active. So in the global routing table there will be TWO /24 with different ASPATH. If this /24 is in ISP A's PA space then it saves one but the one from ISP B's one NEEDs to be in the global routing table. The worse case: ISP A only announces aggregate block even if the link failed then the traffic will still go thru ISP A then get dropped. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net

1 0

RE: Multihoming - Resilience or Independence
by BLOCKI,JACEK (HP-Poland,ex1) 10 Oct '01

10 Oct '01

Hi, Decisions are based on both science and superstition. In my opinion requests to connect to "two independent ISPs" result mostly from superstition. BGP routing is not particularly good at servicing resilient links. If an access link to ISP fails it takes some time before routing reconfigures, we don't like route flaps do we?. In my opinion OSPF + 2 access links to 2 POPs of single ISP would do the you much better. I wonder why virtually nobody offers such a service? From my perspective an entity running LIR is responsible for both IP addressing and IP traffic shaping. An entity may wish to become a LIR for number of business reasons. RIR should not verify validity of those reasons, however RIR should verify if to-be LIR understand what he applies for. This may mean technical consultancy for free, but since RIPE is a non-profit organization raised membership fees have to be spent anyway ;-) Regards, Jacek

1 0

RE: more specific routes in today reality
by Lu, Ping 10 Oct '01

10 Oct '01

> > >> > >> Great! Now we have to collect routing policies from > thousands of small LIRs > >> while still have to deal with thousands of small prefixes. > > > So? There is no difference between thousands of PI prefixes and > > "thousands of small LIRs", except that the latter actually have to > > *pay* for what they cause. > > Right. Strong ACK on this. > So what do the small LIRs solve ? > >> And if the major ISPs stop listening to the more specfic > routes then even > >> using the address from PI space won't work (unless you are > big enough). > > > Yes. This is what it's all about. Small PI space really > hurts people. > > Yep. And therefore these "small" PI stuff should be cleaned > up. The User itself > can use it internally and could get a /24 routed from PA space. > > But it is really not the optimum solution, as it waste's ip > address space. And > we have enough RFC1918 space... > This is not enough but I am going to go with this solution. Then we will ask you to assign only aggregatable address( to a /20 of course) to your customer if they are going to use CW as a backup ISP. You will happily reassign their addresses once they got a link from CW, right ? If you don't then what ? CW will have to leak your /24 to the world but it is you causing it. On the other hand, if our customer ask you to be the backup ISP, we will ask them to change all their DNS records, all their host tables, all their static IP configs to change to the new aggregatable block. If they think this is too much hassle, we will advice them not to use your service because you don't accept /24 multi-homed customer. This sounds realistic enough ? > > Letting "the whole world" see a /16 (from the upstream) and > the direct > > peers a /24 (or whatever) means global routing will just > work fine (over > > the upstream's PA block) and and IX routing will also work just fine > > (using the more specific). > > right, but is it generally used ? > I see a lot of /24 out of the same block from a /16 announced > space globally > (AS5511 for example) > > Because it is not the solution to the real world, that's why people can only talk about it but not really to enforce it. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net

1 0

RE: more specific routes in today reality
by Lu, Ping 10 Oct '01

10 Oct '01

> > > > Great! Now we have to collect routing policies from > thousands of small LIRs > > while still have to deal with thousands of small prefixes. > > So? There is no difference between thousands of PI prefixes and > "thousands of small LIRs", except that the latter actually have to > *pay* for what they cause. To syncronize between the major RIRs is already dufficult enough, to make sure thousands of small LIRs all have correct info is not worth the problem it is trying to solve. > > > > Now more and more major ISPs are filtering out routes from > other ISPs ( > > becuase we don't have > > transit agreements) so the multi-homed customer have to > have their own AS. > > No. This is an interesting arguments, but the fact that C&W > has problems > with some of their peers doesn't mean "the whole world has to drown in > multihomed ASes". Get your contracts right. > Maybe you will carry other ISP's transit routes and they can dump about several GB of traffic for you to pass thru. And you are asking ISP to spend tons of money to carry the traffic that other ISPs are making money of ? Compared to this solution I think multihomed ASes is more acceptable. > > And if the major ISPs stop listening to the more specfic > routes then even > > using the address from PI space won't work (unless you are > big enough). > > Yes. This is what it's all about. Small PI space really > hurts people. > The thing is any ISP can decide to only accept /20 and above and claim any routes beyond those are not important. The truth is the INTERNET is bandwidth oriented and business like IX and webhosting are high bandwidth but not prefixes hungry. But they are hurting because someone think they are not wasting IP addresses enough. So the advice is if for any reason you need a backup link from different ISPs you better claim a /20 even a /24 is enough. > > All these solutions kind of imply that if you can't have > /20 prefix then you > > can't be multi-homed. What happen if a customer want to > have an OC-48 > > multi-homed link but only use prefix < /20 (that happens to > the Internet > > Exchange people a lot ) ? > > So announce it to the internet exchange. Why does it have to > be visible > in the whole world? > > Letting "the whole world" see a /16 (from the upstream) and the direct > peers a /24 (or whatever) means global routing will just work > fine (over > the upstream's PA block) and and IX routing will also work just fine > (using the more specific). > > Bad example. > So if a end-user uses one ISP's /24 from their PA space and he want to divide 50-50 traffic with a second ISP then what ? The second ISP will say no /24 allowed so can you ask the first ISP to assign a /20 ? (Don't worry CW will happily accept your /24) Even worse example. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net

1 0

RE: more specific routes in today reality
by Lu, Ping 10 Oct '01

10 Oct '01

Comments followed. > > Hi, > > On Tue, Oct 09, 2001 at 09:13:05PM +0200, Jan-Ahrent-Czmok wrote: > > Some providers are multihomed > > but cannot cover the costs, even for a small lir. > > If you want to be multihomed, the costs for routers & co. are > far higher > than for being LIR. If you can't afford being LIR, be single-homed. > Great! Now we have to collect routing policies from thousands of small LIRs while still have to deal with thousands of small prefixes. > > Nonsense. Nobody is announcing 192.0.0.0/8, or supernets of other's > networks - and what is in the RIPE database doesn't affect routing. > > To show the first few things from 192/8: > > *>i192.0.32.0 195.158.244.133 100 0 > 1755 1239 5676 226 > i > *>i192.0.34.0 195.158.244.133 100 0 > 1755 1239 5676 226 > i > * i192.0.36.0 195.206.66.61 3 100 0 > 3300 701 2914 20144 > i > *>i 195.158.244.133 100 0 > 1755 1239 2914 2014 > 4 i > * i192.1.0.0/16 195.206.66.61 3 100 0 > 3300 701 1 i > *>i 195.158.244.133 100 0 > 1755 1239 1 i > * i192.2.0.0/16 195.206.66.61 3 100 0 > 3300 701 1 i > *>i 195.158.244.133 100 0 > 1755 1239 1 i > > so if I filter those, why should the traffic go to XLink? > Why should > *any* traffic go to RIPE? It will be just blackholed (or > default-routed > to one of my upstreams, if I happen to have a default-route). > > Please do your homework about routing and BGP before selling people > consulting about multihoming. > Now more and more major ISPs are filtering out routes from other ISPs ( becuase we don't have transit agreements) so the multi-homed customer have to have their own AS. And if the major ISPs stop listening to the more specfic routes then even using the address from PI space won't work (unless you are big enough). All these solutions kind of imply that if you can't have /20 prefix then you can't be multi-homed. What happen if a customer want to have an OC-48 multi-homed link but only use prefix < /20 (that happens to the Internet Exchange people a lot ) ? Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net

3 3

automatic DB cleanup proposal
by kieber＠gatel.net 09 Oct '01

09 Oct '01

Re everybody, following up to some personal talks during the RIPE meeting I propose an automatic cleanup of orphaned person and role objects in the RIPE DB. Motivation ---------- In the light of data privacy issues raised by governmental organizations and in RIPE Database Working Group sessions during RIPE-39 and RIPE-40, as well as following the Great Dangling Person Objects Deletion after de.* ccTLD move-out I propose an automized garbage collection procedure to remove personal data that is unreferenced for a certain amount of time. Proposed Change --------------- An additional attibute ``expire:'' with two values should be added to all person and role objects. The values to this attribute would be a reference counter and a modification timestamp. The reference counter would contain the number of objects still refering to this object, and thus be analog to the link counter of an inode in a UNIX file system. The modification timestamp would be updated whenever the object is updated or the link counter changes. The analogy in the UNIX file system would be sort of a mix of ctime and mtime. Both values could be combined into a single value, but each value of it's own may be of interest to some people. Combining both values would leave the resulting value useless to human interpretation. A garbage collection process running on a periodic basis should then delete all objects with a reference counter of ``0'' and a modification timestamp of more than e.g. 8000000 seconds (approx. 3 month) ago. The expiration period is to be discussed and agreed upon in the community. An additional switch to the whois client should be added to make the otherwise invisible attribute visible, the DB should consequently not accept ``expire:'' attributes in updates. (The DB could certainly be made more forgiving about this, but since the move to v.3 tightened the syntax we should probably not weaken it again.) Database Objects affected ------------------------- An additional attribute would be added to all person and role objects. role: [mandatory] [single] [lookup key] address: [mandatory] [multiple] [ ] phone: [optional] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [mandatory] [multiple] [lookup key] trouble: [optional] [multiple] [ ] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] nic-hdl: [mandatory] [single] [primary/look-up key] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [optional] [multiple] [inverse key] expire: [generated] [single] [ ] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] person: [mandatory] [single] [lookup key] address: [mandatory] [multiple] [ ] phone: [mandatory] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [optional] [multiple] [lookup key] nic-hdl: [mandatory] [single] [primary/look-up key] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [optional] [multiple] [inverse key] expire: [generated] [single] [ ] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] Example ------- inetnum: 10.0.0.0 - 10.0.255.255 netname: XMAS descr: Santa's Workshop Inc. Christmas Toys Manufacturing Facility Northern Nowhere country: NN admin-c: SC12-RIPE tech-c: SWT95-RIPE status: ASSIGNED PA mnt-by: SANTA-SECURITY-MNT changed: jbgood(a)antarctic.nn 19960412 source: RIPE role: Santa Workshop Team address: Santa's Workshop Inc. Jingle Bell Lane 12 1224CH Christmastown Northern Nowhere phone: +12 12 122 3333 fax-no: +12 12 221 4444 e-mail: team(a)antarctic.nn admin-c: SC12-RIPE tech-c: SC12-RIPE tech-c: RD212-RIPE nic-hdl: SWT95-RIPE mnt-by: SANTA-SECURITY-MNT expire: 1 849700000 changed: jbgood(a)antarctic.nn 19960412 source: RIPE person: Santa A. Claus address: Santa's Workshop Inc. Jingle Bell Lane 12 1224CH Christmastown Northern Nowhere phone: +12 12 122 2121 +12 12 122 2211 ext. 1221 fax-no: +12 12 221 1212 e-mail: santa(a)antarctic.nn nic-hdl: SC12-RIPE mnt-by: SANTA-SECURITY-MNT expire: 3 849700000 changed: jbgood(a)antarctic.nn 19960412 source: RIPE person: Rudolf R N Reindeer address: Santa's Workshop Inc. Jingle Bell Lane 21 1224CH Christmastown Northern Nowhere phone: +12 12 122 1111 fax-no: +12 12 122 2222 nic-hdl: RD212-RIPE e-mail: rudolf(a)xmas.nn mnt-by: SANTA-SECURITY-MNT expire: 1 849700000 changed: jbgood(a)antarctic.nn 19960412 source: RIPE -- Ulf Kieber email: kieber(a)gatel.net Senior Network Engineer voice: +49-69-299896-21 Global Access Telecommunications, Inc. fax : +49-69-299896-40 internet solutions for business www : www.gatel.net The Database Toothbrush Proposal

4 4

RE: more specific routes in today reality
by Boyan Krosnov 09 Oct '01

09 Oct '01

Hi, There are other solutions for multihoming with NAT but I think we are again hitting that NAT against no NAT issue. I think that I should say it now to avoid further flamewars. NAT is not always a possible solution. It may be good to use it in some cases but it is not in others. Those other cases are the ones that this discussion is about. Or at least I think so :) CCNP Boyan Krosnov Network Administrator Lirex Net phone: +359-2-91815 > -----Original Message----- > From: Mirta Matic [mailto:mirta.matic@hinet.hr] > Sent: Tuesday, October 09, 2001 4:55 PM > To: Sascha E. Pollok > Cc: Gert Doering; Vladimir A. Jakovenko; lir-wg(a)ripe.net; > routing-wg(a)ripe.net > Subject: Re: more specific routes in today reality > > > Hello, > > have you ever heard for RADWARE solution for that problem? > Some RADWARE box can check distance to destination via both > ISP's and makes > decision from what IP address range have to get address for > NAT (of course, > customer have to have two ranges of addresses). If connection > via one ISP > failed, all traffic will be rerouted via another using IP > address from IP > address range of that ISP. > > Mirta Matic > mirta.matic(a)hinet.hr > > tel: +385 1 4914 207 > fax: +385 1 4914 222

1 0

Re: automatic DB cleanup proposal
by kieber＠gatel.net 09 Oct '01

09 Oct '01

Somebody @ RIPE NCC, speaking for himself, not for RIPE NCC, writes: > On 2001-10-08 20:02:38 +0200, Ulf Kieber wrote: > > > > The modification timestamp would be updated whenever the object is > > updated or the link counter changes. The analogy in the UNIX file > > system would be sort of a mix of ctime and mtime. > > <snip/> > > > expire: 1 849700000 > > I suggest that this look more like the timestamp in the changed > attribute: > > expire: 1 20011008 > > Human-readable == good. :) Seconded. Daily granularity is good enough, but way more readable. Make is so. > Perhaps this attribute should also be present on maintainer and irt > objects, since they contain contact information as well? Not > necessarily as important, but possible. Then we could put it onto key-cert as well. I'm sort of reluctent to have it placed onto maintainer objects which can not be recreated without interaction with the NCC. I'd at least ask for an extended expiration period. -- Ulf Kieber email: kieber(a)gatel.net Senior Network Engineer voice: +49-69-299896-21 Global Access Telecommunications, Inc. fax : +49-69-299896-40 internet solutions for business www : www.gatel.net

1 0

Re: automatic DB cleanup proposal
by Wilfried Woeber, UniVie/ACOnet 09 Oct '01

09 Oct '01

Dear George, >I am worried that there may be *external* referencees to objects, and while >we have no 'contractual' obligation it might not be nice to do this >to people without some engagement but I expect most people would welcome >losing a path to spam. without going into any detail of the proposal itself, I perceive the fact that there are external references (allowed) _without "consent" and without documentation_ a major flaw in the architecture. In fact, there are mechanisms available already (at least in the RIPE DB-SW V2.x and V3.x) that allow us to deal with that requirement: maintainer objects. >As to automatic sweeping, I think there are problems with link counting >which are similar to those we've faced in discussing cross-database linkage >and references. Too many risks of the link count getting out of whack. Fair enough, a very valid concern! But I think the proposal is trying to describe the "user view" and the "abstract behaviour". >I think you could use it as a guide to a sweep, but not as a determinant >without some review and other checks. Eg to trigger more exhaustive checks >to see if there are are references in twisty ways. I agree. >cheers > -George Cheers, and thanks for partcipating in this discussion! Wilfried.

1 0

Action list after RIPE 40
by Hans Petter Holen 05 Oct '01

05 Oct '01

35.4 NCC PGP Key exchange procedure Low prio 35.5 NCC Implement PGP for hm Low prio 36.5 Chair Assignment window applied on infrastructure New Policy 36.7 NCC Keep lir-wg updated on pre RIR address space changes Plenary presentation 38.2 NCC Implement changes to the form while taking into account the comments from the WG Pending 185 revision 38.3 WG Reopen policy discussion - do we need a major revision of RIPE 185 Ongoing 38.4 AC Consider how to coordinate Address prediction work Work launced 38.5 NCC Implement 34.6 LIR-ALLOCATED 38.6 HPH (NCC) Propose PI policy to the WG Ongoing 39.2 NCC Suggest procedure and possible policy changes DONE 39.4 Chairs Define & divide work 39.5 Chairs Beta test 6 weeks deadline for proposals Move to 2nd beta 40.1 NCC/ET RIPE 185 2nd draft 40.2 WG Further discuss MIR/SUB-LIR 40.2 NCC Implement new AW policy 40.3 WG Further discuss possible policy change for PI 40.4 RB AC Election Done 40.5 WG Join RFC2050 mailinglist to give input to revision 40.6 RIRs Produce drafts to replace 2050 for discussion by wg 40.7 RIRs Produce interim policy draft with the help of Arano-san & Mr Bush within 2 weeks 40.8 WG Further discuss final IPv6 policy 40.9 RIRs Set up global IPv6 policy list

1 0

My slides available on the WWW
by Dave Pratt 03 Oct '01

03 Oct '01

Hiya Folks, The slides for the presentation I gave this afternoon are available at: http://www.djp.net/ipv6/pr/ Cheers Dave

1 0

Revision of IPv4 policy draft document
by Nurani Nimpuno 03 Oct '01

03 Oct '01

Dear all, To facilitate the revision of the IPv4 policy draft document, the following mailing list has been set up: <ripe-185bis(a)ripe.net> is a mailing list set up for the participants of the editorial committee of this document, but is also a publicly open mailing list, archived at: http://www.ripe.net/ripe/mail-archives/ripe-185bis/index.html (Available from the LIR-WG website: http://www.ripe.net/ripe/wg/lir/index.html) If you wish to subscribe to this mailing list, please send a mail to <majordomo(a)ripe.net> with "subscribe ripe-185(a)ripe.net" (without quotation marks) in the body of the message. Additionally, a physical meeting will made possible this evening in Prague for any parties interested in participating in the editorial committee. It will take place after (during? :) the RIPE Meeting social event at the Marriott hotel in Prague. A meeting room "Bohemia" is reserved for discussing this document and to agree on the coming steps in the revision process. - All interested parties are welcome to bring their drinks from the social with them. :-) Kind regards, Nurani Nimpuno RIPE NCC

1 0

Chairing LIR-WG Wednesday 3 October
by Denesh Bhabuta 03 Oct '01

03 Oct '01

Dear members I have been informed by Mirjam that Hans Petter is unlikely to make it to the RIPE meeting this time due to things out of his control (Swiss Air, etc) In addition, James Aldridge is not here. It is thus very likely that I will be helping by chairing the meeting tomorrow. If you have any issues you wish me to be aware of, or wish to discuss anything, please do not hesitate to approach me - and in case you do not know what I look like: http://photos.jml.net/photo.php?id=37633 Regards Denesh -- Denesh Bhabuta

1 0

Updated agendas and times of the joint policy sessions
by David Kessens 02 Oct '01

02 Oct '01

Hi, The meeting schedule indicates that the joint lir/ipv6 wg session is starting at 14:00, wednesday, October 3rd. However, as mentioned earlier in the agenda itself, the joint lir/ipv6 session will start at 16:00 and the lir wg will use the the time from 14:00 - 15:30. Also, the agenda has been modified slightly. The new ipv6 draft policy document is published now and Mirjam will give an outline presentation regarding the new draft. I hope this helps, David K. --- Agenda for the IPv6/lir joint session RIPE40, Prague Wednesday October 3rd, 2001, 16:00 - 17:30 Topic: Revision of the general ipv6 allocation guidelines Materials to read: - ripe-196: http://www.ripe.net/ripe/docs/ipv6policy.html - http://www.djp.net/ipv6/proposal.html - http://www.ripe.net/ripe/meetings/archive/ripe-39/presentations/RIPE39-IPv6… A. Administrative stuff - appointment of scribe - agenda bashing B. How to proceed for the next iteration of the policy. C. Proposal for the next version of the policy http://www.djp.net/ipv6/proposal.html (Dave Pratt) D. RIR IPv6 Address Policy Proposal - Outline (Mirjam) - Results of the proposal discussion at the last APNIC meeting Takashi Arano (JPNIC/Asia Global Crossing) Gerard Ross (APNIC) E. Discussion Z. AOB ------------------------- Agenda for the IPv6/lir/eix joint session RIPE40, Prague Thursday October 4th, 2001, 11:00 - 12:30 Topic: Interim policy for allocation of ipv6 addresses for Internet Exchange Points A. Administrative stuff - appointment of scribe - agenda bashing B. How to proceed for the next iteration of the policy. C. Selection of most important issues that we want to discuss during this session: - how to proceed from the interim policy ?!? - default /64 or /48 allocation size - do we want to have this space allocated from a special block, may be even block that is used by all RIRs for this purpose - what documentation is needed to get an allocation - is there any need to document allocations in the RIPE database, and if so, how ?!? - general wording of the policy (Mirjam will present these issues) D. Discussion of the issues Z. AOB ---

1 0

New Document available: RIPE-228
by RIPE NCC Document Announcement Service 02 Oct '01

02 Oct '01

New RIPE Document Announcement -------------------------------------- A new document is available from the RIPE document store. Ref: ripe-228 Title: Supporting Notes for the RIPE NCC Autonomous System Number Request Form Author: Nurani Nimpuno, Sabrina Waschke Date: 2 October 2001 Format: PS=34002 TXT=15144 Obsoletes: ripe-147 Obsoleted by: Updates: Updated by: Short content description ------------------------- This document provides supporting notes to the Autonomous System Number Request Form. It contains instructions on how to complete the request form for AS Numbers, in the RIPE document: "RIPE NCC Autonomous System Number Request Form" Accessing the RIPE document store --------------------------------- The RIPE document store is available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs. The URLs for the new documents on the FTP-server are: ftp://ftp.ripe.net/ripe/docs/ripe-228.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-228.txt plain text version You can also access the RIPE documents in HTML format via WWW. RIPE-228 available from the WWW at the following URL: http://www.ripe.net/docs/asnsupport.html

1 0

New Document available: RIPE-227
by RIPE NCC Document Announcement Service 02 Oct '01

02 Oct '01

New RIPE Document Announcement -------------------------------------- A new document is available from the RIPE document store. Ref: ripe-227 Title: RIPE NCC Autonomous System Number Request Form Author: Nurani Nimpuno, Sabrina Waschke Date: 2 October 2001 Format: PS=13173 TXT=3140 Obsoletes: ripe-147 Obsoleted by: Updates: Updated by: Short content description ------------------------- This document contains the set of templates to be used by Local Internet Registries when requesting an Autonomous System (AS) Number from the RIPE NCC. Accessing the RIPE document store --------------------------------- The RIPE document store is available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs. The URLs for the new documents on the FTP-server are: ftp://ftp.ripe.net/ripe/docs/ripe-227.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-227.txt plain text version You can also access the RIPE documents in HTML format via WWW. RIPE-227 is available from the WWW at the following URL: http://www.ripe.net/docs/asnrequestform.html

1 0

Re: [hostmaster-staff] Re: MIR proposal / reservation revisited?
by Wilfried Woeber, UniVie/ACOnet 02 Oct '01

02 Oct '01

>PS To answer Wilfreds question, it is not reservation revisited it is >aggregation revisited ;) Stephen, in my opinion (from a technical persepctive only), there are two ways of attacking the problem: - 1) to clean up the legacy routes, you have to re-number (which I guess can be done within your address pool(s) - 2) to prevent it from happening again, someone, soemwhere, has to reserve a "big" block of addresses which would support a) additional demand by existing customers, and b) aggregation according to your network's internal structure Item 2) is where my notion of "reservation" is coming from. Do I still get it (completely) wrong? Btw, doing only one of those two is probably not going to work... Wilfried.

2 1

Mail Loop
by Mally Mclane 01 Oct '01

01 Oct '01

Colleagues, We are aware of the mail loop on lir-wg and currently working to fix it. Apologies for the inconvenience and disruption, normal service will be resumed shortly. Regards, Mally Mclane RIPE NCC Operations

1 0

Re: [hostmaster-staff] Re: MIR proposal
by Wilfried Woeber, UniVie/ACOnet 01 Oct '01

01 Oct '01

>Although both RIRs such as RIPE and LIRs such as myself are subject to 80% >rules for the acquisition of more IP space, it seems we are subject to >different 80% rules. > >For an RIR, it is 80% of their allocations, and for the LIRs it is 80% of >assigned space. Where is the big difference - both registries have given away the blocks of addresses to their down-stream entity/ies? And given the current rules forbidding reservations, any sort of "post-factum" aggregation can only be achieved by a renumbering mechanism. Btw, a more liberal way of interpreting the 80 percent rule might be looking at all the address space that is managed(*) by a particular LIR, and not only the currently "open" allocation(s). Wilfried. *) "managed" to be discussed/defined... _________________________________:_____________________________________ 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

LIR-PARTITIONED proposal (originally LIR-ALLOCATED)
by Nurani Nimpuno 01 Oct '01

01 Oct '01

LIR-PARTITIONED PROPOSAL ------------------------ Following James Aldridge's proposal below, here follows an implementation proposal by the RIPE NCC for a new status value in the RIPE Database. Background ----------- This proposal (originally named "LIR-ALLOCATED"was originally discussed at September 1999. James Aldridge later sent out a first proposal to the LIR-WG mailing list, 14 January 2000. (See: http://www.ripe.net/ripe/mail-archives/lir-wg/20000101-20000401/msg00007.ht…) The full final proposal (15 January 2001) by Aldridge can be found at: http://www.ripe.net/ripe/mail-archives/lir-wg/20010101-20010401/msg00003.ht… At the RIPE 38 meeting,(22-26 January 2001), the RIPE NCC accepted the action to implement this proposal. Motivation (as expressed by James Aldridge) -------------------------------------------- "For various reasons large registries often need to distribute their allocated address space between various parts of their organisation (for example we have separate national operations in 20 or so countries obtaining address space through the eu.eunet registry). In these situations it makes sense to document this redistribution in the RIPE database but there is currently no way to do this without throwing up errors in the RIPE NCC's auditing procedures or by removing flexibility and adding more work to the already busy NCC hostmasters by having each local operation treated as having their own allocation. Previously the RIPE database software allowed anyone to register an object with a status value of "ALLOCATED" but this was abused by people who didn't know what they were doing and so this is no longer possible and all non-NCC registered inetnum objects must now have the status of "ASSIGNED". However, having multiple levels of assignments in the RIPE database causes error reports from the NCC's auditing processes which now see anything under the higher- lever sub-allocation as being a duplicate (or overlapping) assignment which makes finding "real" problem assignments difficult or impossible. By allowing a local IR to register an inetnum object with a new status value of "LIR-ALLOCATED" it becomes possible to differentiate between a higher level sub-allocation ("status: LIR-ALLOCATED") and a final assignment by a LIR ("status: ASSIGNED"). By allowing this registration of intermediate objects it would also be possible to restrict changes to lower-level objects differently in different blocks of addresses within the LIR's allocation by setting different "mnt-lower" values without having to open the whole allocated block up for changes by anyone who might have a valid reason for updating a particular (range of) inetnum object(s)." Proposed Name ------------- RIPE NCC proposes to use the term: "LIR-PARTITIONED" ("LIR-PARTITIONED PA" and "LIR-PARTITIONED PI") rather than "LIR-ALLOCATED", to clarify the use of this added database feature. As "LIR-ALLOCATED" could be misinterpreted as a policy feature, we believe that "LIR-PARTITIONED" is a more suitable term, not involving policy terminology, but merely describing a partition of the LIR's allocation. Database Objects affected ------------------------- Only inetnum objects may have the "LIR-PARTITIONED" status value. Usage ----- The "LIR-PARTITIONED" feature allows LIRs to delegate maintenance of lower-level objects representing assignments within the address space specified by the inetnum object with the status "LIR-PARTITIONED PA" OR "LIR-PARTITIONED PI". Functionality ------------- When creating or modifying the inetnum object the database will check the value of the "status:" attribute according to the following rules: - The value of "ALLOCATED PA" or "ALLOCATED PI" is allowed if the object is maintained by the RIPE-NCC-HM-MNT mntner (this name is specified in ALLOCMNT variable of the configuration file) - The value of "LIR-PARTIONED PA" is allowed if one level less specific inetnum object contains a "status:" attribute with the value of "ALLOCATED PA". - The value of "LIR-PARTITIONED PI" is allowed if one level less specific inetnum object contains a "status:" attribute with the value of "ALLOCATED PI". Additional clarification ------------------------ This proposal addresses the added inetnum status value as proposed by James Aldridge. This is strictly a database feature, allowing LIRs to delegate maintenance within their allocations in the RIPE Database. An implementation of this proposal would not affect IP address allocation policy. It would not change the responsibility LIRs have for allocations and assignments held by them. Furthermore, it would not change the manner in which the RIPE NCC verifies allocation utilisation. Timeline -------- Before RIPE 41, January 2002. ---------------- As explained above, this implementation proposal only relates to the proposal outlined in this mail. We welcome the feedback from the LIR-WG and the DB-WG on the "LIR-PARTITIONED" proposal. However, recent comments on the lir-wg mailing list have indicated a wish among some members of the community for a more extensive change, allowing LIRs to sub-allocate IPv4 address space to subsidiaries or downstream ISPs. Such a change would be a rather significant change in current IPv4 address allocation policy, as it has an impact on the LIR's responsibility for its address space as well as the manner in which the RIPE NCC would verify utilisation. If the general feeling in the community is that the "LIR-PARTITIONED" proposal does not cover the LIRs' need, but a more significant change to current IP allocation policy is necessary, then I propose that this be discussed in detail in the LIR-WG. Kind regards, Nurani Nimpuno *--------------------------------------------------------* | Nurani Nimpuno <nurani(a)ripe.net> | | Internet Address Policy Manager | | RIPE Network Co-ordination Centre | | http://www.ripe.net | *--------------------------------------------------------*

2 1