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

Draft minutes from lir-wg at RIPE 41
by Hans Petter Holen 10 Sep '02

10 Sep '02

Dear WG, The RIPE NCC have just finished the draft minutes and published them on the RIPE web site under: http://www.ripe.net/ripe/wg/lir/r41-minutes.html RIPE Meeting: 41 Working Group: LIR Status: 1st Draft Revision Number: 1 Please mail comments/suggestions on: content to the Chair of the working group. format to webmaster(a)ripe.net. ---------------------------------------------------------------------------- --- Draft Minutes of the LIR Working Group session of the RIPE 41 Meeting 14-18 January 2002, at the Krasnapolsky Hotel, Amsterdam, Netherlands. ----------------------------------- Chair: James Aldridge Vice-Chair: Denesh Bhabuta Scribe: Jeannette Decades ----------------------------------- Agenda: A. Admin - scribe, participant list, charter, mailing-lists B. Agenda bashing C. RIPE 39+40 (minutes & actions) D. Report from the RIPE NCC Hostmasters E. RIPE 185 ("European Internet Registry Policies and Procedures") F. Change of policy for Portable address space G. RFC 2050 ("European Internet Registry Policies and Procedures") revision H. Report from The Address Council Y. Any Other Business Z. Open Microphone. Denesh Bhabuta (DB): Hans Petter Holen couldn't make it. So the meeting will have to do with James Aldridge and myself, Denesh Bhabuta. We want to set a ground rule: One of the complaints from the past was that the LIR WG has been fed with too many discussions. Discussions are supposed to happen on the mailing lists and policy decisions are to be made at the meeting. James Aldridge (JA): The agenda was sent out yesterday to the mailing list. ======================== A: Scribe. ======================== DB: Could we have a non-RIPE staff scribe please? No reactions. A RIPE staff member is scribe. ======================== B: Agenda bashing ======================== JA: Are there any additional items for the agenda? No reactions. ======================== C: RIPE 39 and RIPE 40 minutes and actions. ======================== JA: The minutes are on the website since November we think. Actions as it appears on the website, few of them are very old actions from RIPE 35, 36 and 38. Most of these had something happened since the last RIPE meeting. A lot of it is ongoing work. The 38.5 LIR-Allocated, my original suggestion, is now LIR-Partitioned and some email is sent out this week. It is now in the test database and will go live real soon now. Working group chair roles is working fine since Hans Petter Holen is not here and I am. Policy action undivided address space action on the working group to participate on the RFC 2050 is in progress. ======================= D: Report from the RIPE NCC Hostmasters ======================== Presentation of Sabrina Waschke can be found at: http://www.ripe.net/ripe/meetings/archive/ripe-41/presentations/lir-rsreport /index.html Some additional comments from Sabrina on the slides: RS staffing. We have now 5 teams. Three new hostmasters are starting in January. At this point we hope to be fully staffed and can cope with the workload. And as you can see, you have probably seen it before, we also work on future growth. (Sabrina shows her big belly). Number of requests in hostmaster(a)ripe.net. In 2000, we see a peak but now the graph shows a steady growth. We introduced last year the two-day-turnaround time for ongoing tickets. That meant that when your request was picked up out of the wait queue, a hostmaster dealt with it, you replied, you had to wait for 48 hours before you got a response from us again. That means that correctly filled out requests get a faster approval. The special lir-help(a)ripe.net mailbox is not holding up normal requests anymore. We still apply the 'approve but educate' approach. Even not perfect requests got approved and we gave tips and information for improvements to get a faster approval next time. Wait queue. The last 6 months the wait queue is low. The last 2 months it is a bit higher, due to Dutch weather (sickness) and Christmas holidays. Total LIRs per region. The growth is slowing down. We don't expect too many new LIRs. IPv4 Allocation distribution. LIRs that are working all over Europe have the country code EU. Policy development. A message was sent out to the LIR WG concerning the /20 criteria. At RIPE 40 the decision about the Assignment Window (AW) for infrastructure for LIRs was decided upon and it was introduced in December 2001. Already 250 objects have been created in the database with the INFRA-AW extension. Not all of them are valid. Some LIRs have tried to use this to clean up the database. RS services are working on a document that tries to cover everything concerning mergers, take-overs and closures of LIRs. IPv6. The assignments for Exchange Points have been introduced in August 2001. E: RIPE 185 ("European Internet Registry Policies and Procedures") ======================== Nurani Nimpuno (NN): We encourage everyone to look at the document and to give comments. We're speaking about the new policy draft document for IPv4 policies. The document has been out on the web for 5 months and there was very little activity. The couple of comments that have been made have been published on the LIR WG mailing list. JA: I'm not sure how much more we can do. There hasn't been very much discussion on the mailing list about this. My opinion is this, more profitable work is done on the mailing list. Then we can come to the RIPE meetings for final decisions, rather than having long drawn-out arguments and conversations here. But are there any brief comments from anyone here? Because we're actually ahead of schedule and I'm trying to think of anything to fit in a bit of time. I encourage everyone to join the mailing list and to participate in the revision process. The email address is ripe-185bis(a)ripe.net. ======================== F: Change of policy for Portable address space ======================== JA: The question is if people are happy with the new policy? No reaction. DB: Are people aware of the policy change? It's about the requirements of a /22 immediate or the previously use of a /22 to become a new LIR. This was voted on at the last RIPE meeting. Any thoughts? Are people finding it difficult with their customers who want to be mainly multi-homed? Comments? No? We will continue this discussion on the mailing list. ======================== G: RFC 2050 ("European Internet Registry Policies and Procedures") revision ======================== JA: The agenda on the web was wrong about this one. This should be the RFC 2050, the global Internet Registries guidelines, which is being revised and prolong sides the European policy. Again joining the mailing list for participation and discussion is appreciated. Are there any comments for now? Mark Mcfadden (mcf(a)uwm.edu): I'll give a brief update. There is a mailing list available through ARIN for the global RFC 2050 discussion. Part of that working group, there are also some milestones. We're a little bit behind on those because of some things that happened at the end of last year. But we can start see there again is some movement forward. So I encourage anyone who is interested in the discussion of the revision of RFC 2050 to make sure that you're part of that mailing list. Mailing list address: rfc2050-WG(a)arin.net JA: Any questions, comments, anything? Comment from ?: I think that there are more hostmasters here are than LIRs. ======================== H: Report from The Address Council ======================== Barbara Roseman gave a report from the Address Council. Slides can be found at: ======================== Y: Any Other Business ======================== UUNET: There has been a discussion on the mailing list about PI - multihomed issues. The question raised if multi-homed is always needed or not. We have customers that need multi-homing. But not all providers will route small address blocks. JA: I don't know if there's anything that the LIR WG can do to force providers to route any particular address space. I would be inclined, rather than a policy change our of LIRs, have the Routing WG work on this issue and come up with a 'best practice or something'. DB: We can talkabout 'best practice' but there are commercial realities behind this as well. A lot of ISPs have customer requirements to fulfill. You're not the only person who has spoken about this issue with us and it has mainly come up since the last policy change. This was about the minimum requirement of a /22 before we can get address space. Are there any suggestions? UUNET: As far as I can see, the company that I work for, which is UUNET, is thinking about(at least the hostmaster is, which I am not) having a policy where you accept other provider's PA space instead of trying to go the PI route. This is current thinking, this is no decision, but the problem is we don't have a consistent policy across our AS and we'd like to implement one. Before we implement it we'd like to have consistent policy within RIPE. The problem is that whenever we get the discussion, everybody starts jumping and shouting saying: "Multi-homing". Then the discussion dies because multi-homing is the issue. But before we solve that problem we would like to have something implemented that is workable right now instead of waiting until we solve the mult-homing discussion, which seems to be without a logical solution. DB: My suggestion is that we take this up with the Routing WG as well and maybe we can make this into an action item from this meeting. UUNET: I didn't raise it in the Routing WG yesterday, thinking that was more appropriate to the LIR WG. I guess there were some initiatives in the community, but they all died. So I wonder if there's anybody else that feels like this, something we need to resolve rather sooner than later. DB: Any other comments? No reaction. UUNET: I guess there's too much RIPE NCC people here as previously discussed. DB: We'll set it as an action point. JA: This is the first new action point from this RIPE meeting. Any other questions, comments? I think this is about it for this morning. Please participate on the mailing lists. It does make it so much easier if there's been discussion before RIPE meetings. We can then reach final decisions at these WG-meetings.

2 1

Status field for inet6num objects
by Joao Luis Silva Damas 08 Jul '02

08 Jul '02

[** Mail posted to both APNIC and RIPE lists in the hopes of trying to find a solution suitable for all users of RIPE or RIPE-derived software **] Dear all, the inet6num, like the inetnum object, has a field named "status" which stores some information about the nature or position of a block of addresses in the delegation chain, from the RIR through to the end user. Currently, the status field for inet6num object is generated by the Database software based on the size of the address block and its possible values are: o TLA o SubTLA o NLA o SLA This notation has been deprecated and it is time to adapt the database. Discussions on this matter have identified the usefulness of having the capability to distinguish between allocations made by the RIR, allocations made by an LIR or their customers and assignments to end users. As such, we propose to modify the "status" attribute of the inet6num object to be: a) not-generated. This means users must assign a value to the status attribute when creating the object, just as in the inetnum object b) have the following possible values: RIR-allocated LIR-allocated Assigned to be used according to the following set of rules: The RIR-allocated status can only be used in objects representing allocations created directly by the RIR. The LIR-allocated status can be used by LIRs and their customers to represent blocks of addresses that are not assigned to specific end users. There can be several levels of objects with this status. The Assigned status must be used in objects representing assignments to end users (households, companies, enterprises, etc) We hope that with this modification the information in the Database will more accurately describe the registration of IPv6 address space. A possible transition to the new values could be: 1) RIRs modify status fields for allocations 2) Any new objects and modifications to existing ones must have a value for the status field corresponding to the ones described above. Otherwise the update will fail. 3) RIRs contact LIRs to have the status of assignments and sub-allocations updated. Best regards, Joao Damas RIPE NCC

6 8

IPv6 policy and Supernational-LIRs
by Kurt Erik Lindqvist KPNQwest 31 May '02

31 May '02

Now that we have the new IPv6 policy in place, and we have try and start using it, I have a small problem. We have been allocated a IPv6 block for the Supernational-LIR. However, the actual LIR consits of several ASes, each present at it's own IX and with it's own routing policy. To me, a Supernational-LIR consists of several sub-LIRs. My problem is that RIPE will only allocate on /35 block to us, saying that is the allocation for our LIR. This means that we will end up having to break that block into smaller announcements, one per each sub-LIR. Could someone elaborate on the thinking behind this policy. To me it would routingwise make more sense to allocate a block per sub-LIR. Best regards, - kurtis -

8 14

Re: IPv6 policy and Supernational-LIRs
by James Aldridge 30 May '02

30 May '02

Kurt Erik Lindqvist KPNQwest wrote: > Now that we have the new IPv6 policy in place, and we have try and start > using it, I have a small problem. We have been allocated a IPv6 block for > the Supernational-LIR. However, the actual LIR consits of several ASes, > each present at it's own IX and with it's own routing policy. > > To me, a Supernational-LIR consists of several sub-LIRs. My problem is > that RIPE will only allocate on /35 block to us, saying that is the > allocation for our LIR. This means that we will end up having to break > that block into smaller announcements, one per each sub-LIR. There is a definite change between the IPv4 and IPv6 allocation policies for supernational LIRs as far as the RIPE NCC is concerned. For IPv4, supernational registries (contributing as, for example, as KPNQwest does for the eu.eunet registry, the equivalent of 6 large LIRs) would receive up to 1.5 times the number of allocations from the NCC that a single large registry would get. For IPv6, on the other hand, a supernational registry can only get a single allocation, irrespective of its size and contributions to the NCC. I don't recall this policy change being discussed in the RIPE policy making forum (the LIR WG) being being put in place by the NCC for the then interim IPv6 policy. I am aware that there are few supernational registries and that they are a pain for the RIPE NCC but this policyy change seems to work against the aggregation principles we need to follow if we're not going to have the routing table growth rate we've seen with IPv4. James

3 2

RE: New Document available: RIPE-233
by Michel Py 30 May '02

30 May '02

Havard, > Havard Eidnes wrote: > I have to ask a rhetorical question here, what is a "block" in > this context? > Is it a single routing announcement? Surely, it cannot be, > because the different root name servers are placed at different > points in the topology. The very purpose of placing them at different points is to have redundancy; so yes, for the same reason they must have different blocks. > I'll claim that the actual numeric sequence (or non-sequence) of > the IPv6 address blocks allocated to the root name servers do not > matter; the identity of the blocks will be well-known anyway, so > there is no robustness gain to be had from picking "obscure" or > "scattered" numbers. There is an advantage to scattered numbers, IMHO. Since they are scattered, nobody will try to aggregate them and suppress the specific announcements. Martian configs do happen; not often but they do. > I do however agree with those which have said that a root name server > should not have its address changed when it moves between RIR regions; > the whole point of this "special" assignment to the root name servers > is to avoid *any* renumbering because the DNS bootstrap data is > (currently) distributed in a static configuration file. There are (at least) two ways to achieve this: 1. Two-space systems (the servers would have a unique identifier and multiple changeable locators). 2. "special assignement" otherwise called PI. I think the RIRs have acted responsibly so far in not showing the bad example of allocating themselves a PI block. A short-term fix to this would be a two-space system where the locator initially assigned could be transformed into the identifier later. Michel.

1 0

New Document available: RIPE-233
by RIPE NCC Document Announcement Service 30 May '02

30 May '02

New RIPE Document Announcement -------------------------------------- A new document is available from the RIPE document store. Ref: ripe-233 Title: IPv6 Addresses for Internet Root Servers in the RIPE Region Author: Joao Luis Silva Damas Date: 24 May 2002 Format: PS=9362 TXT=2362 Obsoletes: Obsoleted by: Updates: Updated by: Short content description ------------------------- The "IPv6 Addresses for Internet Root Servers in the RIPE Region" document describes the special case assignment policy for Internet DNS root servers in the RIPE region. Accessing the RIPE document store --------------------------------- The RIPE document store is available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs. The document will be available shortly on the FTP-server at: ftp://ftp.ripe.net/ripe/docs/ripe-233.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-233.txt plain text version You can already access the RIPE document in HTML format via WWW at: http://www.ripe.net/docs/ipv6-rootservers.html Kind Regards, Jeroen Bet RIPE NCC Webmaster

9 12

Re: IPv6 policy and Supernational-LIRs
by James Aldridge 29 May '02

29 May '02

Gert Doering wrote: > Hi, > > On Wed, May 29, 2002 at 09:29:33AM +0000, James Aldridge wrote: > > For IPv6, on the other hand, a supernational registry can only get a single > > allocation, irrespective of its size and contributions to the NCC. I don't > > recall this policy change being discussed in the RIPE policy making forum (the > > LIR WG) being being put in place by the NCC for the then interim IPv6 policy. > > > > I am aware that there are few supernational registries and that they are a > > pain for the RIPE NCC but this policyy change seems to work against the > > aggregation principles we need to follow if we're not going to have the > > routing table growth rate we've seen with IPv4. > > I don't understand why "not giving out multiple IPv6 blocks" is > "against the aggregation principles". > > Could you elaborate on this? The old IPv6 policy gave a single /35 to a supernational registry. This meant that each "sub-LIR" would have to put up with, say, a /40 (enough for a mere 256 /48 assignments) and once this was used it would be unlikely that the next /40 available from the LIR's allocation would form an aggregatable block with the earlier "sub-allocation". With different "sub-LIRs" having different (national) routing policies, these multiple non-aggregatable blocks would have to be announced to peers. This doesn't sound like following aggregation principles to me ;-) However, that was the old IPv6 policy... > Being a bit more relaxed in judging whether a multinational LIR really > needs a "/22" (to be a bit extreme) would mimic the "IPv4 approach" > (give out more space than usual) fairly well. ... yes, I'm sure this would help. The supernational LIR adds a few extra levels of hierarchy here: - RIR - Supernational LIR - "sub-LIR" - sub-LIR's ISP customers (who are either not LIRs or LIRs who don't meet current IPv6 criteria) - end-user assignments If a hierarchy such as this could be used to justify a larger-than-/32 allocation then I don't think that big supernational registries would have any particular problems. James

2 1

Re: New Document available: RIPE-233
by Pekka Savola 25 May '02

25 May '02

On Fri, 24 May 2002, Robert Martin-Legène wrote: > On Fri, May 24, 2002 at 05:01:15PM +0200, RIPE NCC Document Announcement Service wrote: > > Ref: ripe-233 > > Title: IPv6 Addresses for Internet Root Servers in the RIPE Region > > I heard someone suggest that all allocations should be done from > the same superblock. Although it's not in the document, I think > it makes sense. We all hate our martian filters, so putting the > "exception to the rule" in the same superblock will make your name > go over in history. This is assigning /32's to root servers. There are no need for "exceptions to the rule", unless you're thinking of e.g. special rules for BGP flap dampening for root servers or such. Btw, I agree with Matthew Ford that 'should' was too mild a word. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords

1 0

RE: New Document available: RIPE-233
by matthew.ford＠bt.com 24 May '02

24 May '02

" It is not associated with the organisation(s) that operate the root server at a particular point in time and these organisations should not use the address space to provide any services not related to the root server." s/should/must/ Mat. > -----Original Message----- > From: RIPE NCC Document Announcement Service [mailto:ncc@ripe.net] > Sent: 24 May 2002 16:01 > To: ipv6-wg(a)ripe.net > Cc: lir-wg(a)ripe.net > Subject: New Document available: RIPE-233 >

1 0

Implementation of Global IPv6 Policy
by Mirjam Kuehne 24 May '02

24 May '02

Dear Colleagues, We are pleased to announce that the RIPE NCC will implement the new Global IPv6 Policy on 1 July 2002. This policy has been agreed by the communities of all the Regional Internet Registries (RIRs). Before 1 July 2002 we will publish and announce the following as RIPE Documents: - Global IPv6 Policy Document - Initial IPv6 Allocation Request Form in the RIPE NCC Service Region - IPv6 End User Site Assignment Request Form in the RIPE NCC Service Region (for prefixes shorter than a /48) Regards, -- Mirjam Kuehne RIPE NCC

7 6