- lir-wg - mailman.ripe.net

IPv4 and ASN Policy draft on-line
by Nurani Nimpuno 27 Sep '01

27 Sep '01

Dear all, The first draft of the IPv4 and ASN policy document is now available on-line at: http://www.ripe.net/rs/ipv4policy.html It is available as html and can also be downloaded in .txt format. This document is currently under revision as an editorial team is being assembled to provide input on this draft. If you are interested in participating in the editorial team, please contact the LIR-WG chair, Hans-Petter Holen <hph(a)online.no> or indicate your interest on this list. Kind regards, Nurani Nimpuno RIPE NCC

5 10

MIR proposal
by Stephen Burley 27 Sep '01

27 Sep '01

Hi Before i start the proposal i would like to ask a question, what ever happened to the Organisation object? Was is ever put in the DB? If not why not? as i am sure it got concensus. Ok the proposal. Background: We the evil UUNET/WorldCom in Europe have only one nework. AS702 covers all of our existing networks and is numbered out of all the LIR's we currently run - 17 in total - so AS702 is really a non contiguous AS with 120,000 routes. Back in the old days it was never invisaged that networks would ever get this large and the current concept of conservation, conservation, conservation, aggregation does not really support very large networks - i am not against conservation of IPv4 it just needs a fresh look. This proposal by definition will not appeal to all and will most certinly cause some to view this whole idea as "UUNET trying to use its muscle", believe me its not. We have to look at this proposal in the context of a very large network desperate the reduce the amount of prefixes on the routers before we hit the memory wall on routers and just the shear logistics of managing the aggreagation internal and external and assignment policies. We like to concept of Supernational Registries but all that really does is lump all of your current LIR bills into one and does not really help the aggregation issues as the growth patterns in differant registries are vast and range from near stagnent due to country specific reasons to the explosive growth, with various levels in between. This means that as a SuperNational it would be impossable to aggregate and reach 80% usage over the registries CIDR. The process of aggregation would force the planning of sub-allocation to give more than the immediate needed IPspace to allow for growth, much the same way RIPE does now when allocating to large LIR's and new LIR's. They will allocate a /20 and mark the contiguous /20 as "use last" this same pattern of sub-allocation needs to happen a level below RIR's and above LIR's - the MIR (multinational internet registry). The multinational registry (MIR) is not a means by which a large comapany with a very large network would have an advantage over LIR's. The LIR structure is still needed to provide local knowledge assignment and local aggregation, it will not replace LIR's just manage the overall aggregation of a large block of IP space and sub-allocate to them. It will not be limited by the 80% usage constraint but that by no way gives the MIR a free hand. Rather than being constrained by a fixed number (the numbers would have to be realistic) the MIR is governed by business nedds and routing requirements which the NCC would have to be informed of and understand. This does not mean the MIR ignore all of RIPE policy ie. /20 for startups etc. rather we self manage the policies (as we do now) as the NCC does but the IP blocks are allocated out of one very large block say a /11 in accordance with current assignment policy. A /11 i here you gasp, well a /11 is not an unreasonable size we have more than that now. If we knew now how big the network was to get then we probably would have created this sort of concept from day one, one thing we can be sure of its not going to shrink. Just think how much better all our routing tables would be if we could renumber into a single larger contiguous block, but we can not. This problem is not going to go away and IPV4 will be around for a while yet so rather than compounding the problem by continuing in this blinkered fashion of fragmenting large networks i think we should take this fresh look at the way the current admin structure is interfering with current network planning, with commercial impacts that brings. Looking a little into the future i think this structure would help with IPV6 too. The only differance is we know how big the networks are and what we need to create a well aggregated IPV6 network now with MIR's. Summary: Please do not look at this and close your mind because it does not affect your network it may do one day. From a purely community oriented spirit it is meant to try and improve overall aggregation, from a purely buiness point of view it makes sense to add another level of managment without complicating it but only for those who need it. RIR - Would still continue to admin the IP space for both MIR's and LIR's for the good of the community. MIR - Would manage the allocation (large ) from RIR and suballocate to LIR's aggregating the network correctly but be responsible to RIR for their actions LIR - Would assign space to infrastructure and customers as usual but would either be directly in contact with the NCC or via the MIR. I hope this does not cause too much controversie it is not my intention. Regards Stephen Burley UUNET EMEA Hostmaster SB855-RIPE

5 6

Re: new IPv6 policy framework
by Mirjam Kuehne 25 Sep '01

25 Sep '01

Niall, Niall Richard Murphy <niallm-ripe(a)enigma.ie> writes: * On Tue, Sep 25, 2001 at 09:11:17AM +0000, Mirjam Kuehne wrote: * * Hi Mir et al, * * Please below find my preliminary thoughts/comments on this document. * * [Aspirations preserved, so we can remember them later] * > - The allocation criteria should be such that it is easy to obtain * > IPv6 address space. * * > - The size of the initial allocation should be large enough to allow * > flexibility in addressing infrastructure and customer sites. * * > 1. to recognise existing infrastructure (both IPv4 and IPv6) where it * > exists and calculate IPv6 address needs based on existing networks. * * > 2. to apply the slow start mechanism only for 'IPv6 only' networks * > without existing IPv4 infrastructure * * > 3. to reduce the minimum allocation size for those IPv6 only networks * > (unless larger requirements are shown) * * > 4. to measure the utilisation rate with the HD ratio rather than * > percentages * * > 5. to make subsequent allocations when the HD ratio is reached * * > 3.1. Case 1 - Existing IPv4 services * * > Additional policies may require the return of IPv4 address space to * > the RIR or upstream ISP, in the case the existing network is * > renumbered to the new IPv6 space in future. * * Am I alone in wondering exactly what the scope of these additional policies * may be? My concern is based on the fact that although existing v4 networks * may well acquire v6 space, they are likely to need their v4 space for quite * some years to come, and hence it would be unrealistic to require the * return of all v4 address space. I agree with you that there will probably be a long transition period. The assumption however is that a network will at some stage be fully migrated to IPv6 and the IPv4 addresses will not be needed anymore. * * (Or maybe I misunderstand...) * * > 4. Size of Initial Allocation * * > For new networks without existing infrastructure, it is proposed to * > establish a minimum allocation for IPv6 address space. It is suggested * > to keep the size of the initial allocation relatively small (a /35 or * > smaller) and to determine the size of subsequent allocations based on * > the utilisation rate of the initial allocation (this is called slow * > start mechanism). This will allow easy access to IPv6 allocations for * > newcomers. At the same time possible wastage of address space and * > routing table growth will be limited. * * These v6 allocations are made from the RIR (ex TLA) space, correct? * yes. * So, are we abandoning the model where only the biggest networks go to * the RIRs for space, and everyone else goes to them? We learned that the old TLA/NLA/SLA boundaries were no technical requirements in the address format. In addition to that we know from experience that it is very difficult to define and verify what a transit ISP is. Therefore we propose to use a policy that treats all organisations equally. The RIRs cannot decide who is allowed to have a top level IPv6 allocation. The ISPs themselves have much better mechanisms to address routing table growth. Mirjam

4 3

Re: IPv4 and ASN Policy draft on-line
by Nurani Nimpuno 25 Sep '01

25 Sep '01

Hi Per, The following section describes the policy you describe in your mail. The second section (starting with "However, for services that are permanently connected...") addresses the change as described in Paula's mail from 1999: - - 5.1.9 Static assignments Due to constraints on the available free pool of IPv4 address space, the use of static IP address assignments (e.g., one address per customer) for dial-up users is strongly discouraged. Organisations considering the use of static IP address assignment are expected to investigate and implement dynamic assignment technologies whenever possible. If assignments for static assignments are indeed made, special verification procedures apply. However, for services that are permanently connected to the Internet, static one-to-one connections is considered acceptable. Verification of usage will in these cases take place when the LIR is requesting approval for additional assignments. Please contact the RIPE NCC for details on applicable verification methods. - - I hope this answered your question. However, if you feel that this text does not correctly reflect the actual policy, please join the editorial committee and we can work together on rewording it. Kind regards, Nurani Nimpuno RIPE NCC Per Lundberg <per(a)swip.net> writes: * Dear Nurani, * * Thanx for the update, though one question: * What happened to the "Permanently and Temporarily online" policy of '99 as * in Paulas mail to the list - * http://www.ripe.net/ripe/mail-archives/lir-wg/19990101-19990401/msg 00045.htm * l ? * * Seems to be missing in the new policy text. * * Kindly * Per * * On Fri, 21 Sep 2001, Nurani Nimpuno wrote: * * > Dear all, * > * > The first draft of the IPv4 and ASN policy document is now available * > on-line at: * > http://www.ripe.net/rs/ipv4policy.html * > * > It is available as html and can also be downloaded in .txt format. * > * > This document is currently under revision as an editorial team is * > being assembled to provide input on this draft. * > * > If you are interested in participating in the editorial team, please * > contact the LIR-WG chair, Hans-Petter Holen <hph(a)online.no> or * > indicate your interest on this list. * > * > Kind regards, * > * > Nurani Nimpuno * > RIPE NCC * > * > * > * > * * -- * Per * DNS/IP Registry * - - - - - - - - - Swedish IP Network - - - - - - - - - * Tele2AB/Swipnet e-mail: per(a)swip.net * Box 62 direct: +46 8 5626 4579 * 164 94 KISTA gsm: +46 704 26 4579 * Sweden fax: +46 8 5626 4210 * *

1 0

fwd: Re: IPv4 and ASN Policy draft on-line
by Wilfried Woeber, UniVie/ACOnet 25 Sep '01

25 Sep '01

Apologies, forgot to include lir-wg... ______________________________________________________________________ To: MX%"randy(a)psg.com" CC: WOEBER Subj: Re: IPv4 and ASN Policy draft on-line => there are valid cases where a (globally unique) AS# is required which => does not show up in the DFZ. = =please illustrate = =randy BGP peerings with ISP(s) _without_ (global) transit being offered by them. Only one path (the one with global connectivity/transit) would be visible. Wilfried.

1 0

Re: IPv4 and ASN Policy draft on-line
by Wilfried Woeber, UniVie/ACOnet 25 Sep '01

25 Sep '01

>> there are valid cases where a (globally unique) AS# is required which >> does not show up in the DFZ. (and, of course, there are places where a >> private AS# would do just as well). > Hmmm. I'm curious: could you name a few? The things that I could > imagine are "private peerings somewhere", which "should" work using > private AS#s just fine. BGP within _one_ administrative domain can (most probably in most cases) use private AS#s, and indeed we are using them in that situation. However when the peerings have to span policy/operations-coordination/ ISP boundaries, then private number space becomes unmanageable. Wilfried.

1 0

Re: IPv4 and ASN Policy draft on-line
by Wilfried Woeber, UniVie/ACOnet 25 Sep '01

25 Sep '01

>If I go the Oregon router server and look up their /19 and find only 1 >path to that /19 or I find that the ASN origin has disappeared and been >replaced by their upstream then there is no justification for getting an >ASN. > >> >> randy >> > >Hank Wrong. there are valid cases where a (globally unique) AS# is required which does not show up in the DFZ. (and, of course, there are places where a private AS# would do just as well). The bottom line is: how much are we (collectively) prepared to pay (in real money for RIR staff salaries, complexity, hassle and delay for *all* requests) in order to save a couple of AS numbers... -WW _________________________________:_____________________________________ 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

4 4

Where is the proposed revised IPv6 policy ?
by Dave Pratt 25 Sep '01

25 Sep '01

Hiya Folks, It is only a week now before the RIPE meeting at which it would be nice to agree on an improved policy for IPv6 allocations. Where is the proposed revised policy document ? Do the authors think that this policy should be developed without the partication of the LIR community ? I think we would all appreciate answers to the above questions as soon as possible. If the answer is "not enough time/resources", then I think we have an even stronger case for more involvement from the RIR members themselves. A cynic could argue that the proposed policy is so controversial that the authors wish to avoid debate - forcing the meeting into an accept it or leave it choice. This view is re-inforced since the authors were requested a month or so back to make the proposed revised policy available for comment. I would be keen to see which of the many positive and constructive suggestions have been incorporated in the policy. I would also expect to hear on the list *before* the meeting any reasons why specific suggestions for improvements were not included. The meeting is for agreeing the policy, not discussing the details of what should or should not be included. Cheers Dave BT Ignite GmbH

1 0

Antw: Re: Maintaining IPs in LIRs/Enterprise LIRs
by Wilson Mehringer 25 Sep '01

25 Sep '01

Hi, I share Yuval`s pedicament and would be very interested in an IP Management tool. Regards, Wilson Mehringer .............................................................. Cablecom GmbH Wilson Mehringer Zollstrasse 42 8021 Zürich Tel : 0041 1 277 91 61 Mobile : 079 238 27 68 E-mail : wilson.mehringer(a)cablecom.ch >>> David R Huberman <huberman(a)gblx.net> 09/24 11:11 pm >>> > I am currently in search for a tool which will help a LIR to maintain > its IP addresses - currently everything is listed inside an Excel file, > which is, IMHO, a very limited way of maintaining the lists. Global Crossing uses a complex but powerful home-grown IP database system which, when coupled with an interface for requesting address space, suffices for our needs. The database very cleanly aggregates and de-aggregates blocks on the fly, tracks user information and customer numbers, can prioritize and de-prioritize blocks for assignment, and can report utilization statistics on an as-requested basis. Everything is written in perl. If there is interest, we can publish these tools as freeware/open source for the RIPE LIR community to use. /david *--------------------------------* | Global Crossing API | | Manager, Global IP Addressing | | (703) 627-5800 | | huberman(a)gblx.net | *--------------------------------*

1 0

Re: Summary: Fixed Boundary (/29) Assignments
by Sabrina Waschke 24 Sep '01

24 Sep '01

Bruno Ciscato <bciscato(a)cisco.com> writes: * At 11:04 16/02/2001 +0100, Mirjam Kuehne wrote: * * >The comments showed concerns about the administrative procedures * >required for these kinds of assignments. However, it was felt that * >these addresses need to be accounted for in some way. A possible way * >forward would be to initiate discussion surrounding the set of * >information necessary to justify these assignments while providing an * >efficient way for the LIRs to provide services to their customers. * * * What is the set of information necessary to justify these assignments ? * Does a big ISP have to justify in advance and for each residential customer * (10s a day) that the customer will use one address for the PC, one for the * oven, one for the security webcam, and so on and so forth? * Is there any other way that may make the process more efficient ? * * thanks a lot * * bruno * The LIR Working Group agreed that fixed Boundary (/29) Assignments should not be assigned to every customer by default as this implies a waste of addresses. However, LIRs are free to offer fixed boundary (/29) assignment to customers who request it. These assignments have to be based on need. The LIR has to justify all addresses in these networks to RIPE NCC with a list of the devices that will use these addresses, just like any other assignment. Regarding assignments for cable/xdsl customers: Initial assignment requests for cable and xDSL are usually judged on the basis of availability of the hardware. If an LIR has the hardware necessary for the first assignment then this is considered to be sufficient justification. Later assignment requests can use the same method, although it is then also possible to justify more addresses by showing the growth in customer base (sometimes bandwidth statistics are added as well to show the latest increases). For further details please write to <hostmaster(a)ripe.net> including the ticket number of your ongoing request, or contact <lir-help(a)ripe.net>. Kind regards, Sabrina Waschke -- o------------------------------------------o | Sabrina Waschke sabrina(a)ripe.net | | Registration Services Operations Manager | | | | RIPE NCC tel +31 20 535 4444 | | www.ripe.net fax +31 20 535 4445 | o------------------------------------------o

1 0