From bs at eunet.ch Fri Sep 7 17:28:29 2001 From: bs at eunet.ch (Bernard Steiner) Date: Fri, 07 Sep 2001 17:28:29 +0200 Subject: Index of lir-wg on Altavista Message-ID: <200109071528.RAA05897@eunet.ch> Folks, considering the fact that I have started receiving UCEs to my e-mail address at work, would anybody out there point out to me the advantages of having altavista index the lir-wg archive (amongst other things) ? Fed up with UCEs for today, Bernard From bernard.steiner at eunet.ch Mon Sep 17 08:20:52 2001 From: bernard.steiner at eunet.ch (bernard.steiner at eunet.ch) Date: Mon, 17 Sep 2001 08:20:52 +0200 Subject: New RIPE NCC reverse delegation procedure In-Reply-To: Your message of "Thu, 16 Sep 1999 18:35:35 +0700." <009DE3FA.BA85AFF2.19@cc.univie.ac.at> Message-ID: <200109170620.IAA00533@eunet.ch> x-noarchive: no Folks, > - between the lines, also, this states that users of address space > obtained from LIRs which have been closed for one reason or another > cannot get RevDNS services set up and/or changed - unless you provide > some loopholes. > I don't have an opinion about good/bad, it's just an observation. Exactly. In that light, it was probably a bad idea for EUnet/CH to give the authority for reverse delegations of varios ch-zz /16 blocks back to RIPE :-( Bernard Hereby I deny the right to index this message for the purpose of presentation in WWW search engines (for what it's worth). From bernard.steiner at eunet.ch Mon Sep 17 08:28:15 2001 From: bernard.steiner at eunet.ch (bernard.steiner at eunet.ch) Date: Mon, 17 Sep 2001 08:28:15 +0200 Subject: RIPE 34 LIR WG Draft Agenda In-Reply-To: Your message of "Thu, 16 Sep 1999 21:26:26 +0200." <199909161926.VAA14169@aegir.EU.net> Message-ID: <200109170628.IAA00545@eunet.ch> x-noarchive: no > Any comments? I support the proposal :-) Bernard I strongly disagree with this message to be indexed by WWW search engines. From mike at linx.net Mon Sep 3 12:19:02 2001 From: mike at linx.net (Mike Hughes) Date: Mon, 3 Sep 2001 11:19:02 +0100 (BST) Subject: Interim Policy proposal for IPv6 Address Assignment Policy for Internet Exchange Points In-Reply-To: Message-ID: On Fri, 31 Aug 2001, Dave Pratt wrote: > Unfortunately, I must respond against the proposal as it stands with use of a > /64 allocation. If the proposal for the /64 allocation for the IXP mesh is "it" - i.e. this will be the only address space allocated to an IX, period - then I find it hard to be in full agreement with this proposal. The LINX is currently an RIR in it's own right, with a /19 of PA space delegated to it. This is diced up to provide addresses for the IXP meshes at LINX (both Unicast and Multicast), for LINX's own public-facing and member services, and some space is delegated for essential services LINX hosts (such as nic.uk). LINX peers with all it's members, and announces this /19 to them - this means that members have direct, independant connectivity to the LINX services. We also have a handful of transit ISPs (a small subset of members, but over independant media) to fill in the gaps, and make sure we're still online if there is an exchange problem. If v6 addresses for an IXP's member services have to be delegated from an upstream provider, this makes the exchange dependant on that provider. If that provider has problems, or ceases trading, that could have serious impacts on the business continuity of the exchange, for it's member/participant community, and possibly other members of the RIPE community. Please don't say IPv6 address-based multihoming to me. It's not ready for primetime IMHO. What I believe is needed is an allocation for IXP service networks as well as for the IX mesh, which is globally routable. I'd like to propose this alongside the existing proposal we have on the table. Comments? Mike -- Mike Hughes Network Architect London Internet Exchange mike at linx.net http://www.linx.net/ "Only one thing in life is certain: init is Process #1" From Henk.Steenman at icoe.att.com Mon Sep 3 15:32:05 2001 From: Henk.Steenman at icoe.att.com (Henk Steenman) Date: Mon, 03 Sep 2001 15:32:05 +0200 Subject: Interim Policy proposal for IPv6 Address Assignment Policy for Internet Exchange Points In-Reply-To: References: Message-ID: <5.1.0.14.2.20010903152815.029d4cd8@135.76.170.11> >What I believe is needed is an allocation for IXP service networks as well >as for the IX mesh, which is globally routable. I'd like to propose this >alongside the existing proposal we have on the table. > >Comments? I agree with you Mike, I think this is the only way an IXP can show its independence from any one of its members (connected ISPs, carriers or whatever) - Henk From paul.mylotte at bt.com Mon Sep 3 17:33:40 2001 From: paul.mylotte at bt.com (paul.mylotte at bt.com) Date: Mon, 3 Sep 2001 16:33:40 +0100 Subject: Interim Policy proposal for IPv6 Address Assignment Policy fo r Internet Exchange Points Message-ID: I totally agree with Mike in his comments below, and those from Dave Pratt in a previous email. Some time ago I sent the following proposal to the list, and I would like to point out, again, that address space is already allocated for this and is clearly specified in RFCs. The proposal was: At the RIPE 39 joint meeting it was clarified that we should cater for the support of both types of IPv6 exchanges, viz: (i) allocate addresses for IPv6 exchange infrastructure only (no onwards allocation in the manner of a backbone ISP). (ii) allocate a sub TLA to the IPv6 exchange which will then act in the manner of an ISP and allocate downstream. In order to progress this, I would like to propose: 1 IPv6 exchanges that need addresses for the purpose of internal addressing can apply for the addresses already set aside for this purpose and held by IANA, as per RFC2928 (Initial IPv6 Sub-TLA ID Assignments) and RFC2450 (Proposed TLA and NLA Assignment Rules). In this case a /48 allocation will be sufficient. (How IPv6 exchanges should apply for these addresses is out of scope - either direct to IANA, or IANA allocates down to RIRs first). extract from RFC2928 Section3 Initial IPv6 Sub-TLA ID Assignments ... ..The block of Sub-TLA IDs assigned to the IANA (i.e., 2001:0000::/29 - 2001:01F8::/29) is for assignment for testing and experimental usage to support activities such as the 6bone, and for new approaches like exchanges. 2 IPv6 exchanges that plan to onward allocate addresses in the manner of an ISP should apply via the existing mechanism. The existing mechanism is currently being reviewed and this review should take account of any changes necessary to include IPv6 exchanges explicitly desiring addresses for onward allocation as being acceptable candidates for address space. Could we please add this proposal to what is already on the table. Regards, Paul P. S. Mylotte IP Addressing & Naming BTexact Technologies Adastral Park 01473 606333 / + 44 1473 606333 paul.mylotte at bt.com BTexact Technologies is a trademark of British Telecommunications plc Registered office 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000 This electronic message contains information from British Telecommunications plc which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the number or address above) immediately. > -----Original Message----- > From: Mike Hughes [SMTP:mike at linx.net] > Sent: 03 September 2001 11:19 > To: lir-wg at ripe.net > Cc: eix-wg at ripe.net; ipv6-wg at ripe.net > Subject: Re: Interim Policy proposal for IPv6 Address Assignment > Policy for Internet Exchange Points > > On Fri, 31 Aug 2001, Dave Pratt wrote: > > > Unfortunately, I must respond against the proposal as it stands with use > of a > > /64 allocation. > > If the proposal for the /64 allocation for the IXP mesh is "it" - i.e. > this will be the only address space allocated to an IX, period - then I > find it hard to be in full agreement with this proposal. > > The LINX is currently an RIR in it's own right, with a /19 of PA space > delegated to it. This is diced up to provide addresses for the IXP meshes > at LINX (both Unicast and Multicast), for LINX's own public-facing and > member services, and some space is delegated for essential services LINX > hosts (such as nic.uk). > > LINX peers with all it's members, and announces this /19 to them - this > means that members have direct, independant connectivity to the LINX > services. We also have a handful of transit ISPs (a small subset of > members, but over independant media) to fill in the gaps, and make sure > we're still online if there is an exchange problem. > > If v6 addresses for an IXP's member services have to be delegated from an > upstream provider, this makes the exchange dependant on that provider. If > that provider has problems, or ceases trading, that could have serious > impacts on the business continuity of the exchange, for it's > member/participant community, and possibly other members of the RIPE > community. > > Please don't say IPv6 address-based multihoming to me. It's not ready > for primetime IMHO. > > What I believe is needed is an allocation for IXP service networks as well > as for the IX mesh, which is globally routable. I'd like to propose this > alongside the existing proposal we have on the table. > > Comments? > > Mike > -- > Mike Hughes Network Architect London Internet Exchange > mike at linx.net http://www.linx.net/ > "Only one thing in life is certain: init is Process #1" > From huberman at gblx.net Mon Sep 3 18:51:53 2001 From: huberman at gblx.net (David R Huberman) Date: Mon, 3 Sep 2001 09:51:53 -0700 (MST) Subject: Interim Policy proposal for IPv6 Address Assignment Policy fo r Internet Exchange Points In-Reply-To: Message-ID: As I recall from Prague, we discussed that exchange point operators who need v6 space for their member services can request a sub-TLA just like any other network operator. Outside the scope of actually providing physical points of inter-operator exchange, exchange points are no different than any other service provider and should not be treated differently. I am still in favor of this approach and fail to identify operational difficulties with it. /david From randy at psg.com Mon Sep 3 19:14:00 2001 From: randy at psg.com (Randy Bush) Date: Mon, 03 Sep 2001 10:14:00 -0700 Subject: Interim Policy proposal for IPv6 Address Assignment Policy for Internet Exchange Points References: Message-ID: > If the proposal for the /64 allocation for the IXP mesh is "it" - i.e. > this will be the only address space allocated to an IX, period - then I > find it hard to be in full agreement with this proposal. it is not. to my knowledge, no one is proposing prohibiting any current allocation policies, merely adding a new one, giving a /64 to peering meshes. > What I believe is needed is an allocation for IXP service networks as well > as for the IX mesh, which is globally routable. there is such a policy, and it applies to anyone, not just ixs. after all, when it comes to the non-ix portion of your business, why should you get special treatment that others do not? what is unusual about an ix is the peering mesh. that warrants special allocation. otherwise, i am sure we all think we have special needs and deserve special treatment. randy From randy at psg.com Mon Sep 3 19:19:50 2001 From: randy at psg.com (Randy Bush) Date: Mon, 03 Sep 2001 10:19:50 -0700 Subject: Interim Policy proposal for IPv6 Address Assignment Policy for Internet Exchange Points References: <5.1.0.14.2.20010903152815.029d4cd8@135.76.170.11> Message-ID: >> What I believe is needed is an allocation for IXP service networks as well >> as for the IX mesh, which is globally routable. I'd like to propose this >> alongside the existing proposal we have on the table. > I agree with you Mike, I think this is the only way an IXP can show its > independence from any one of its members (connected ISPs, carriers or > whatever) s/ixp/small isp/ i.e. the small isps want to appear independed from their upstream(s). the discussion over this has been going on nigh a decade. so what makes an ixp's business so special they warrant special treatment? randy From mike at linx.net Mon Sep 3 16:44:28 2001 From: mike at linx.net (Mike Hughes) Date: Mon, 3 Sep 2001 15:44:28 +0100 (BST) Subject: Interim Policy proposal for IPv6 Address Assignment Policy for Internet Exchange Points In-Reply-To: Message-ID: On Mon, 3 Sep 2001, Mike Hughes wrote: > The LINX is currently an RIR in it's own right, with a /19 of PA space Eek! I did, of course, mean LIR :-). Mike -- Mike Hughes Network Architect London Internet Exchange mike at linx.net http://www.linx.net/ "Only one thing in life is certain: init is Process #1" From randy at psg.com Tue Sep 4 09:18:52 2001 From: randy at psg.com (Randy Bush) Date: Tue, 04 Sep 2001 00:18:52 -0700 Subject: Interim Policy proposal for IPv6 Address Assignment Policy for Internet Exchange Points References: <5.1.0.14.2.20010904091036.02920da8@135.76.170.11> Message-ID: >>>> What I believe is needed is an allocation for IXP service networks as >>>> well as for the IX mesh, which is globally routable. I'd like to >>>> propose this alongside the existing proposal we have on the table. >>> I agree with you Mike, I think this is the only way an IXP can show its >>> independence from any one of its members (connected ISPs, carriers or >>> whatever) >> s/ixp/small isp/ >> i.e. the small isps want to appear independed from their upstream(s). >> the discussion over this has been going on nigh a decade. so what makes >> an ixp's business so special they warrant special treatment? > I believe there is a difference, > An IXP is a facilitating infrastructure delivering services to all > ISPs connected or to be connected. Linkage in any way to one or > more of its members might harm the neutrality of the exchange towards > its other members. we all think we're special. but we're all just funny monkeys. an ix has a perfectly normal way to get infrastructure space now. the exchanges you mention have such (v4) space now. i am not aware of anyone suggesting to remove those policies. what we're trying to do here is to let those ixs who are now throwing up v6 peering meshes get the address space for those meshes. we are not trying to change the world, annoint ixs over isps, web hosters, ... life can be simple if we let it. randy From Henk.Steenman at icoe.att.com Tue Sep 4 09:11:08 2001 From: Henk.Steenman at icoe.att.com (Henk Steenman) Date: Tue, 04 Sep 2001 09:11:08 +0200 Subject: Interim Policy proposal for IPv6 Address Assignment Policy for Internet Exchange Points Message-ID: <5.1.0.14.2.20010904091036.02920da8@135.76.170.11> At 07:19 PM 9/3/2001, Randy Bush wrote: > >> What I believe is needed is an allocation for IXP service networks as well > >> as for the IX mesh, which is globally routable. I'd like to propose this > >> alongside the existing proposal we have on the table. > > I agree with you Mike, I think this is the only way an IXP can show its > > independence from any one of its members (connected ISPs, carriers or > > whatever) > >s/ixp/small isp/ > >i.e. the small isps want to appear independed from their upstream(s). >the discussion over this has been going on nigh a decade. so what makes >an ixp's business so special they warrant special treatment? I believe there is a difference, An IXP is a facilitating infrastructure delivering services to all ISPs connected or to be connected. Linkage in any way to one or more of its members might harm the neutrality of the exchange towards its other members. For AMS-IX: > AMS-IX is a non-profit, neutral and independent association, meaning > that it has no bias as to who connects For LINX > A neutral, not-for-profit partnership between Internet Service Providers > globally, LINX provides a physical interconnection for its members to > exchange Internet traffic through co-operative peering agreements I believe that in both cases "neutral" and "no bias to.." will be harmed if IXP address space (in any way, for the exchange infrastructure as well as for the services infrastructure like web server, e-mail etc) is related to a limited set of its customers. - Henk From aid at vianw.net Tue Sep 4 10:42:58 2001 From: aid at vianw.net (Adrian Bool) Date: Tue, 4 Sep 2001 09:42:58 +0100 Subject: Interim Policy proposal for IPv6 Address Assignment Policy for Internet Exchange Points In-Reply-To: <5.1.0.14.2.20010904091036.02920da8@135.76.170.11> References: <5.1.0.14.2.20010904091036.02920da8@135.76.170.11> Message-ID: <01090409425800.03704@ewe.noc.u-net.net> Hi. On Tuesday 04 September 2001 08:11, Henk Steenman wrote: > At 07:19 PM 9/3/2001, Randy Bush wrote: > > >> What I believe is needed is an allocation for IXP service networks as > > >> well as for the IX mesh, which is globally routable. I'd like to > > >> propose this alongside the existing proposal we have on the table. > > > > > > I agree with you Mike, I think this is the only way an IXP can show its > > > independence from any one of its members (connected ISPs, carriers or > > > whatever) > I believe that in both cases "neutral" and "no bias to.." will be harmed > if IXP address space (in any way, for the exchange infrastructure as > well as for the services infrastructure like web server, e-mail etc) is > related to a limited set of its customers. Whereas I agree with Mike that one of these /64 blocks is not appropriate for exchanges such as the LINX - among others - if such exchanges are able to aquire the size of block that would make sense for their organisation, then this proposal has no bearing on them - and will just be handy for small exchanges probably run in-house by co-lo facilities. So, the real question is: If LINX (as an example of a more 'managed' IXP) were to apply for a larger, routable block, would that request be accepted by their RIR? I'd guess this is a question that only RIPE could answer authoritively... over to you RIPE ;-) Regards, aid -- Adrian Bool | http://noc.vianetworks.net/ Director, Global Network | tel://+44.1925.484061/ VIA NET.WORKS Inc. | noc://+49.203.3093.1111/ From stephenb at uk.uu.net Tue Sep 4 11:08:39 2001 From: stephenb at uk.uu.net (Stephen Burley) Date: Tue, 4 Sep 2001 10:08:39 +0100 Subject: Interim Policy proposal for IPv6 Address Assignment Policy for Internet Exchange Points References: <5.1.0.14.2.20010904091036.02920da8@135.76.170.11> <01090409425800.03704@ewe.noc.u-net.net> Message-ID: <565d01c13521$2fc88d70$2e04bf3e@eu.frd.uu.net> ----- Original Message ----- From: "Adrian Bool" To: "Henk Steenman" ; "Randy Bush" Cc: "Mike Hughes" ; ; ; Sent: Tuesday, September 04, 2001 9:42 AM Subject: Re: Interim Policy proposal for IPv6 Address Assignment Policy for Internet Exchange Points > > > Hi. > > On Tuesday 04 September 2001 08:11, Henk Steenman wrote: > > At 07:19 PM 9/3/2001, Randy Bush wrote: > > > >> What I believe is needed is an allocation for IXP service networks as > > > >> well as for the IX mesh, which is globally routable. I'd like to > > > >> propose this alongside the existing proposal we have on the table. > > > > > > > > I agree with you Mike, I think this is the only way an IXP can show its > > > > independence from any one of its members (connected ISPs, carriers or > > > > whatever) > > > I believe that in both cases "neutral" and "no bias to.." will be harmed > > if IXP address space (in any way, for the exchange infrastructure as > > well as for the services infrastructure like web server, e-mail etc) is > > related to a limited set of its customers. > > Whereas I agree with Mike that one of these /64 blocks is not appropriate for > exchanges such as the LINX - among others - if such exchanges are able to > aquire the size of block that would make sense for their organisation, then > this proposal has no bearing on them - and will just be handy for small > exchanges probably run in-house by co-lo facilities. > > So, the real question is: > > If LINX (as an example of a more 'managed' IXP) were to apply for a larger, > routable block, would that request be accepted by their RIR? I'd guess this > is a question that only RIPE could answer authoritively... over to you RIPE > ;-) > How many IXP's will there be? For goddness sake why are we trying to hold on to all this space. Lets treat them like an ISP and give them an equivalent amount of space, its hardly going to push us over the edge if we give every IXP in the world an ISP equivalent block which will last them forever and ever and ever and ever and they can live happily ever after. > Regards, > > aid > > -- > Adrian Bool | http://noc.vianetworks.net/ > Director, Global Network | tel://+44.1925.484061/ > VIA NET.WORKS Inc. | noc://+49.203.3093.1111/ > From djp-ripe-lists at djp.net Tue Sep 4 11:30:44 2001 From: djp-ripe-lists at djp.net (Dave Pratt) Date: Tue, 4 Sep 2001 11:30:44 +0200 (CEST) Subject: Interim Policy proposal for IPv6 Address Assignment Policy for Internet Exchange Points In-Reply-To: Message-ID: Hiya Randy, All, On Tue, 4 Sep 2001, Randy Bush wrote: -> ->an ix has a perfectly normal way to get infrastructure space now. the ->exchanges you mention have such (v4) space now. i am not aware of anyone ->suggesting to remove those policies. -> ->what we're trying to do here is to let those ixs who are now throwing up ->v6 peering meshes get the address space for those meshes. we are not ->trying to change the world, annoint ixs over isps, web hosters, ... -> ->life can be simple if we let it. -> ->randy This is not true and/or irrelevant, at least in Europe. We are also talking about non-peering-mesh infrastructure. In order to presently get IPv6 TLA space during the bootstrap phase, an applicant must meet RIPE-196's 4.2.2c or 4.2.2d (40 customers/6 months Mbone) criteria which presently are not met by IXPs. This is I believe why IXPs applications have been rejected/frozen. After the bootstrap phase things might get worst, since according to 4.2.1a ALL applicants must have 3 IPv6 peerings - which is practically impossible as they have not yet got the addresses with which to peer ( chicken and egg :-) Confusing the issue by comparing IXPs with small ISPs does not help at all and could initiate all sorts of complex side discussions such as IXPs issuing addresses to customers. ***The purpose of this discussion is to fix this and loosen up the allocation policy for ISPs. We need a quick perhaps temporary policy to fix this now. As a comment, it might save work for the RIPE NCC if the IXPs were to receive a standard sub-TLA. A separate discussion (apparently secret and certainly going on behind closed doors) might permanently improve the allocation policy for the rest of us. Cheers Dave ps. In IPv4 until very recently just about anyone could get an allocation by joining RIPE. IPv6 is *much* stricter - a reason for sticking with IPv4 ? From jdd at vbc.net Tue Sep 4 11:41:08 2001 From: jdd at vbc.net (Jim Dixon) Date: Tue, 4 Sep 2001 10:41:08 +0100 (BST) Subject: Interim Policy proposal for IPv6 Address Assignment Policy for Internet Exchange Points In-Reply-To: Message-ID: On Tue, 4 Sep 2001, Dave Pratt wrote: > ps. In IPv4 until very recently just about anyone could get an allocation by > joining RIPE. IPv6 is *much* stricter - a reason for sticking with IPv4 ? It's very odd indeed, given that there is so much IPv6 address space and correspondingly little justification for tight management of that address space. -- Jim Dixon VBCnet GB Ltd http://www.vbc.net tel +44 117 929 1316 fax +44 117 927 2015 From pekkas at netcore.fi Tue Sep 4 13:36:58 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 4 Sep 2001 14:36:58 +0300 (EEST) Subject: Interim Policy proposal for IPv6 Address Assignment Policy for Internet Exchange Points In-Reply-To: Message-ID: On Tue, 4 Sep 2001, Jim Dixon wrote: > On Tue, 4 Sep 2001, Dave Pratt wrote: > > > ps. In IPv4 until very recently just about anyone could get an allocation by > > joining RIPE. IPv6 is *much* stricter - a reason for sticking with IPv4 ? > > It's very odd indeed, given that there is so much IPv6 address space > and correspondingly little justification for tight management of that > address space. Please keep in mind that I for one don't want Joe Random's Own Little ISP, for example, get a sTLA. The whole point of tightly aggregated DFZ is pointless if that would be the case. Getting IPv6 address space, subTLA-level address space, should be way more difficult than getting an IPv4 /29 delegation. Let's not lose the meaning of sTLA; it's not (in my book at least) meant for small ISP's. Another question entirely is whether IXP's are "significant enough" in this sense, and would this encourage small ISP's, which wouldn't normally be allowed anywhere near a subTLA, found an _"_IXP_"_. So.. Don't be stingy with address space with those that actually do peering (other than tunnels!), but otherwise... -- 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 From chris at linx.net Tue Sep 4 12:52:41 2001 From: chris at linx.net (Chris Fletcher) Date: Tue, 4 Sep 2001 11:52:41 +0100 Subject: Interim Policy proposal for IPv6 Address Assignment Policy for Internet Exchange Points Message-ID: <15252456895868323600120552387@localhost.localdomain> One of the points that has been raised a couple of times is... There is a lot of IPv6 address space - why not just give IXP's a sub TLA. The argument against this seems to be - if IXP's are treated as a special case then there is a precedent for every other 'special case' to justify their case. ... but there is still *lots* [1] of address space so why not give everyone who wants one a sub TLA? AIUI the reason for restricting who gets sub TLAs is... In the current IPv4 world (multiprovider) multihomed customers have their own address space and AS number this fills the default-free routing table and won't scale. In IPv6, addressing is hierarchical and multihomed customers have multiple addresses, this keeps the default-free routing table small and scalable. If everyone (multihomed customers) gets a sub TLA then the default-free routing table fills up with multihomed customer sub TLAs and IPv6 routing tables are as cluttered and unscalable as IPv4. Is this the issue? If not, why not give out sub TLAs to all who want them? Chris - LINX [1] There are 2^32 (~ 4,000,000,000) /35s available... +--+-----+-----+---+-----+------+------------------+ |-3|--13-|--13-|-6-|--13-|--16--|------64 bits-----| +--+-----+-----+---+-----+------+------------------+ |FP|-TLA-|-sub-|Res|-NLA-|--SLA-|---Interface ID---| |--|-ID--|-TLA-|---|--ID-|--ID--|------------------| +--+-----+-----+---+-----+------+------------------+ From peter.galbavy at knowtion.net Tue Sep 4 14:12:19 2001 From: peter.galbavy at knowtion.net (Peter Galbavy) Date: Tue, 4 Sep 2001 13:12:19 +0100 Subject: Interim Policy proposal for IPv6 Address Assignment Policy for Internet Exchange Points References: Message-ID: <001e01c1353a$db975d70$4000a8c0@interhouse.redbus.com> > Please keep in mind that I for one don't want Joe Random's Own Little ISP, > for example, get a sTLA. The whole point of tightly aggregated DFZ is > pointless if that would be the case. > > Getting IPv6 address space, subTLA-level address space, should be way more > difficult than getting an IPv4 /29 delegation. > > Let's not lose the meaning of sTLA; it's not (in my book at least) meant > for small ISP's. While the technical discussion is very important, please also do not loose site of the fact that it is not RIPEs role to act as a regulator. You cannot restrict a companies (or individuals) ability to carry out normal business because you think they are 'too small'. Be careful with what a policy says or a nice committee from an EU competition commision will want to talk to you. Peter From peter.galbavy at knowtion.net Tue Sep 4 14:18:21 2001 From: peter.galbavy at knowtion.net (Peter Galbavy) Date: Tue, 4 Sep 2001 13:18:21 +0100 Subject: Interim Policy proposal for IPv6 Address Assignment Policy for Internet Exchange Points References: Message-ID: <004c01c1353b$b38a1c40$4000a8c0@interhouse.redbus.com> > It's very odd indeed, given that there is so much IPv6 address space > and correspondingly little justification for tight management of that > address space. Apart from the feeling of power it grants those who are responsible for allocating it. That's my cynicism kicking in - again. Peter From peter.galbavy at knowtion.net Tue Sep 4 14:20:21 2001 From: peter.galbavy at knowtion.net (Peter Galbavy) Date: Tue, 4 Sep 2001 13:20:21 +0100 Subject: Interim Policy proposal for IPv6 Address Assignment Policy for Internet Exchange Points References: <001e01c1353a$db975d70$4000a8c0@interhouse.redbus.com> Message-ID: <006001c1353b$fad0e020$4000a8c0@interhouse.redbus.com> > While the technical discussion is very important, please also do not loose site ... my apologies for my appalling spelling and grammar at the end of that line. I have no excuse as a native English speaker. Please blame the lack of coffee and the lack of a working network this morning. Peter From asp at partan.com Tue Sep 4 16:07:06 2001 From: asp at partan.com (Andrew Partan) Date: Tue, 4 Sep 2001 10:07:06 -0400 Subject: Interim Policy proposal for IPv6 Address Assignment Policy for Internet Exchange Points In-Reply-To: <15252456895868323600120552387@localhost.localdomain>; from chris@linx.net on Tue, Sep 04, 2001 at 11:52:41AM +0100 References: <15252456895868323600120552387@localhost.localdomain> Message-ID: <20010904100706.A2622@partan.com> On Tue, Sep 04, 2001 at 11:52:41AM +0100, Chris Fletcher wrote: > AIUI the reason for restricting who gets sub TLAs is... > If everyone (multihomed customers) gets a sub TLA then the > default-free routing table fills up with multihomed customer sub > TLAs and IPv6 routing tables are as cluttered and unscalable as IPv4. Bingo! Thats the real reason. The only known way of keeping routing working is keeping the tables small. There is no known technical means of doing this at the moment, so we are forced into the administrative realm. Thus you see all sorts of rules & regulations about addreses and how to get them and use them. [See ptomaine, multi6, and some of the IRTF work for more about this.] --asp at partan.com (Andrew Partan) From keith at xchangepoint.net Tue Sep 4 16:31:20 2001 From: keith at xchangepoint.net (Keith Mitchell) Date: Tue, 04 Sep 2001 15:31:20 +0100 Subject: Interim Policy proposal for IPv6 Address Assignment Policy forInternet Exchange Points References: Message-ID: <3B94E5B8.42DBA09F@xchangepoint.net> I don't see any huge conflict between what Randy and Dave are arguing here: Dave Pratt wrote: > ->an ix has a perfectly normal way to get infrastructure space now. the > ->exchanges you mention have such (v4) space now. i am not aware of anyone > ->suggesting to remove those policies. > This is not true and/or irrelevant, at least in Europe. We are also talking > about non-peering-mesh infrastructure. So long as the same policies for "PI" IPv6 space remain open to IXPs to use for their non-peering-mesh requirements in the same way some use their own LIR IPv4 space, then I am satisfied the proposed policy is a reasonable approach. Since our multi-IXP plans mean we will need to apply for our own sub-TLA in due course, that's what we'll do (and giving IXPs who meet the existing criteria is not going to break the bank anyway, as there are maybe two orders of magnitude less IXPs than ISPs). But we can only do this if we have some way of achieving the criteria for this, and that requires ISP-neutral IPv6 space for our peering mesh so we do the peerings needed to meet these criteria. And that is the hurdle we have been struggling to overcome for about 8 months now: > ->what we're trying to do here is to let those ixs who are now throwing up > ->v6 peering meshes get the address space for those meshes. we are not > In order to presently get IPv6 TLA space during the bootstrap phase, an > applicant must meet RIPE-196's 4.2.2c or 4.2.2d (40 customers/6 months Mbone) > criteria which presently are not met by IXPs. > This is I believe why IXPs applications have been rejected/frozen. Correct. And the proposal put forward by the RIPE NCC a couple of weeks ago solves this. It IMHO has the dual merits of not solving any other problems, and not creating any other problems, as the limited scope does not generate exceptional precedents that can be exploited by non-IXPs wanting special allocations. > After the bootstrap phase things might get worst, since according to 4.2.1a > ALL applicants must have 3 IPv6 peerings - which is practically impossible as > they have not yet got the addresses with which to peer ( chicken and egg :-) > ***The purpose of this discussion is to fix this and loosen up the allocation > policy for ISPs. We need a quick perhaps temporary policy to fix this now. So please can we go with the existing proposals, which provide a way around this, ASAP, so we have as much time as possible to prepare for the end of the bootstrap phase. > it might save work for the RIPE NCC if the IXPs were to receive > a standard sub-TLA. Not really, as the RIPE NCC have already done most of this work, on the basis of several months' of the silent appearance of consensus from previous discussion of this issue. I have not yet seen anyone in this most recent discussion raise any major reasons not to go with the proposal as it stands that have not been addressed in previous incantations of the debate. We do have a need for this address space for our business now, and my patience is getting pretty stretched. Please can we proceed with at least interim allocations under the proposed policy now. Frustrated of Pimlico, Keith Mitchell CTO, XchangePoint http://www.xchangepoint.net/contact/keith/ From randy at psg.com Tue Sep 4 18:27:09 2001 From: randy at psg.com (Randy Bush) Date: Tue, 04 Sep 2001 09:27:09 -0700 Subject: Interim Policy proposal for IPv6 Address Assignment Policy for Internet Exchange Points References: <001e01c1353a$db975d70$4000a8c0@interhouse.redbus.com> Message-ID: > While the technical discussion is very important, please also do not loose > site of the fact that it is not RIPEs role to act as a regulator. You > cannot restrict a companies (or individuals) ability to carry out normal > business because you think they are 'too small'. what are you people smoking? what is proposed is a NEW way of getting space in a specific case, not a restriction, but a very specific liberalization. can we lower the hystrionics please? randy From randy at psg.com Tue Sep 4 18:28:55 2001 From: randy at psg.com (Randy Bush) Date: Tue, 04 Sep 2001 09:28:55 -0700 Subject: Interim Policy proposal for IPv6 Address Assignment Policy for Internet Exchange Points References: <004c01c1353b$b38a1c40$4000a8c0@interhouse.redbus.com> Message-ID: > Apart from the feeling of power it grants those who are responsible for > allocating it. while waiting for a big make, for some reason i decided i wanted to know if usenet was still there, having left it over a decade ago. so i go to google to try and find it. lo and behold, google itself has some massive archive of usenet. so i decide to look at the old news.groups, to see what life is like these days. the very first article had the Subject: Re: Corrupt totalitarian usenet "rulers" and their tricks i left with the warm happy feeling that usenet is still very much alive and has probably not changed much in some years. randy From huberman at gblx.net Tue Sep 4 18:47:39 2001 From: huberman at gblx.net (David R Huberman) Date: Tue, 4 Sep 2001 09:47:39 -0700 (MST) Subject: Interim Policy proposal for IPv6 Address Assignment Policy forInternet Exchange Points In-Reply-To: <3B94E5B8.42DBA09F@xchangepoint.net> Message-ID: So picking up on Keith's point: Here's where we seem to be at. The joint working group chairs have put forth a proposal making obtaining a /64 for a peering mesh doable for any bona fide exchange point operator. The chairs put forth this interim policy proposal to these lists hoping to garner consensus or judge that consensus does not exist. The ensuing discussion, while not unuseful, does not appear (to me) to be helping the chairs and the wg membership from gauging the extent to which there is consensus for this interim policy proposal. So I ask: In lieu of any other policy changes, are you, as a RIPE member and participant in the LIR, EIX, and IPv6 WGs, in favor of the interim policy proposal for IPv6 address assignment policy for internet exchange points? /david From pekkas at netcore.fi Tue Sep 4 19:11:22 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 4 Sep 2001 20:11:22 +0300 (EEST) Subject: Interim Policy proposal for IPv6 Address Assignment Policy for Internet Exchange Points In-Reply-To: Message-ID: On Tue, 4 Sep 2001, Randy Bush wrote: > > While the technical discussion is very important, please also do not loose > > site of the fact that it is not RIPEs role to act as a regulator. You > > cannot restrict a companies (or individuals) ability to carry out normal > > business because you think they are 'too small'. > > what are you people smoking? > > what is proposed is a NEW way of getting space in a specific case, not a > restriction, but a very specific liberalization. IMO, it should be noted more clearly in the draft (as pointed out before) what the target group is. If there is no prior policy, people will automatically consider something new as _the_ policy, and start to forget that there might be other options.. That is, so that 2 years down the road if you as an IX have address space needs that can't be met with the proposed solution, won't (necessarily/always) be met with "Sorry, this is how we allocate addresses to IX's. Have a good day." because people forgot it was only supposed to be _a_ way. I'm not saying that that would happen, but opinions on what the policy was all about might change in 6, 12, 18 or whatever months unless some kind of "applicability statement" is added. The last RIPE IPv6 allocation policy is from 1999. Who thought it would last this long? Who knows how long the interim policy would be active? It's better not to take chances. -- 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 From huberman at gblx.net Tue Sep 4 18:56:32 2001 From: huberman at gblx.net (David R Huberman) Date: Tue, 4 Sep 2001 09:56:32 -0700 (MST) Subject: Interim Policy proposal for IPv6 Address Assignment Policy forInternet Exchange Points In-Reply-To: Message-ID: > So I ask: > > In lieu of any other policy changes, are you, as a RIPE member and > participant in the LIR, EIX, and IPv6 WGs, in favor of the interim policy > proposal for IPv6 address assignment policy for internet exchange points? To answer my own question, I support the interim policy proposal and hope it is ratified by the WGs as soon as possible. /david From randy at psg.com Tue Sep 4 19:35:41 2001 From: randy at psg.com (Randy Bush) Date: Tue, 04 Sep 2001 10:35:41 -0700 Subject: v6 allocation policy fo rLIRs References: Message-ID: [ note change of subject ] > If there is no prior policy, people will automatically consider something > new as _the_ policy, and start to forget that there might be other > options.. > > That is, so that 2 years down the road if you as an IX have address space > needs that can't be met with the proposed solution, won't > (necessarily/always) be met with "Sorry, this is how we allocate addresses > to IX's. Have a good day." because people forgot it was only supposed to > be _a_ way. > > I'm not saying that that would happen, but opinions on what the policy was > all about might change in 6, 12, 18 or whatever months unless some kind of > "applicability statement" is added. > > The last RIPE IPv6 allocation policy is from 1999. Who thought it would > last this long? Who knows how long the interim policy would be active? > It's better not to take chances. it is all i can do to get my job done dealing with reality. worrying about black helicopters, martian landings, etc. requires more time and paranoia than i can manage. yup, we need a new v6 lir allocation policy. yup, we saw proposals for a new global v6 allocation policy at apnic. there may be a gap between the apnic view and others, they prefer a /29 starting allocation, which even steve deering thinks is too large. imiho, a /35 or a /36 is more in scale and sellable in the west. but i may be full of it. we'll be discussing the issues in prague and miami next month. in the meantime, check out randy From randy at psg.com Tue Sep 4 19:40:02 2001 From: randy at psg.com (Randy Bush) Date: Tue, 04 Sep 2001 10:40:02 -0700 Subject: Interim Policy proposal for IPv6 Address Assignment Policy forInternet Exchange Points References: <3B94E5B8.42DBA09F@xchangepoint.net> Message-ID: > In lieu of any other policy changes, are you, as a RIPE member and > participant in the LIR, EIX, and IPv6 WGs, in favor of the interim policy > proposal for IPv6 address assignment policy for internet exchange points? yes From gert at space.net Tue Sep 4 20:49:24 2001 From: gert at space.net (Gert Doering) Date: Tue, 4 Sep 2001 20:49:24 +0200 Subject: Interim Policy proposal for IPv6 Address Assignment Policy forInternet Exchange Points In-Reply-To: ; from huberman@gblx.net on Tue, Sep 04, 2001 at 09:47:39AM -0700 References: <3B94E5B8.42DBA09F@xchangepoint.net> Message-ID: <20010904204924.Y11979@Space.Net> Hi, On Tue, Sep 04, 2001 at 09:47:39AM -0700, David R Huberman wrote: > In lieu of any other policy changes, are you, as a RIPE member and > participant in the LIR, EIX, and IPv6 WGs, in favor of the interim policy > proposal for IPv6 address assignment policy for internet exchange points? Yes. Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From randy at psg.com Tue Sep 4 21:18:20 2001 From: randy at psg.com (Randy Bush) Date: Tue, 04 Sep 2001 12:18:20 -0700 Subject: OPS-NM interim meeting before RIPE-40 Message-ID: Howdy, At the last two IETF OPS Area Open meetings, we had some good discussion between the OPS NM folk and some operators. We also have had a so called OPS-NM Interim in the USA that was co-located with NANOG in May of this year. We also called it something like: Net Management Protocol Folk & Net Operators - Reality Check #2 We will have another IETF Interim Meeting for the OPS-AREA Network Management people, this time in Europe, co-located with the next RIPE-NCC meeting. The idea is to meet with another set of operators to try and understand their needs and to explain to them how we think that our NM related work in the IETF can help them to manage their networks. In other words: Net Management Protocol Folk & Net Operators - Reality Check #3 We probably will have similar sessions in the future to meet with people who operate enterprise networks, because their requirements may be different. We are still working on the agenda, however below you will find a prelimenary agenda proposal. Any suggestions should be sent to Randy (randy at psg.com) and Bert (bwijnen at lucent.com) We have limited space for this meeting. Those who plan to attend, pls send a short email to Bert Wijnen to let us know. Pls add a few lines as to why you want to participate. Discussion has been occurring since May on the mailing list ops-nm at ops.ietf.org, which is normal internet-style. And a web-based archive is at . Bert and Ern^H^H^HRandy -------------- OPS-NM Interim Meeting details ------------------ The plan is to have this meeting co-located with the next RIPE NCC meeting, namely RIPE 40. That means: Oct 1st OPS-NM Interim from 2-5pm Oct 2nd OPS-NM Interim from 9am-noon Oct 2-5 RIPE 40. Starts at 2pm on oct 2nd. RIPE 40 and OPS-NM Interim will be in the Prague Congress Centre in Prague, Czech Republic. For RIPE 40 and hotel registration, pls visit: http://www.ripe.net/ripe/meetings/current/ripe-40/ There is a whole range of hotels to choose from, but it is very hard to book, so do it now. Those only participating in the OPS-NM meeting are not required to pay the RIPE meeting fee. Of course, if you want to take the opportunity to participate in the RIPE-NCC meeting, then you should register for that meeting via the web page listed above. Those who plan to attend the OPS-NM Interim should send an email to Bert Wijnen because we only have limited room, and if too many people want to show up we may have to tell some that there is no more space. Prelimenary Agenda ------------------ - Agenda bashing and intro - Summary of the current set of OPS requirements draft-ops-operator-req-mgmt-00.txt Please read this document to prepare for the meeting. If this one no longer exists, then pls check for a possible revision 01.txt. It is important to try and figure out if this also represents needs of European operators, or do they have different/new/additional requirements? - Discussion of the above. - Discussion of SNMP, MIBs, COPS, POLICY and such - how do the developers of these protocols/specs think that they can address operator NM requirments. - what do operators think about that - what kind of positive or negative expoerience do operators have - Operator requirements - what are the real hot issues to be solved this year - what are the constraints within which the tools have to work - Next steps - Wrapup/Summary -30- From david at IPRG.nokia.com Tue Sep 4 23:27:57 2001 From: david at IPRG.nokia.com (David Kessens) Date: Tue, 4 Sep 2001 14:27:57 -0700 Subject: v6 allocation policy fo rLIRs In-Reply-To: ; from Randy Bush on Tue, Sep 04, 2001 at 10:35:41AM -0700 References: Message-ID: <20010904142757.A15240@iprg.nokia.com> Randy, On Tue, Sep 04, 2001 at 10:35:41AM -0700, Randy Bush wrote: > > yup, we need a new v6 lir allocation policy. yup, we saw proposals for a > new global v6 allocation policy at apnic. there may be a gap between the > apnic view and others, they prefer a /29 starting allocation, which even > steve deering thinks is too large. imiho, a /35 or a /36 is more in scale > and sellable in the west. but i may be full of it. we'll be discussing the > issues in prague and miami next month. in the meantime, check out > > Judging the mails and proposals regarding ipv6 allocation policies that I have seen so far, and the discussions we have had at previous RIPE meetings, it seems that the gap between the apnic view and ripe community view on this matter is minimal. David K. --- From david at iprg.nokia.com Wed Sep 5 00:09:12 2001 From: david at iprg.nokia.com (David Kessens) Date: Tue, 4 Sep 2001 15:09:12 -0700 Subject: Interim summary of current discussions Message-ID: <20010904150912.A7344@iprg.nokia.com> Hi, The proposed interim policy was proposed to go into effect on the 7th september 2001. Since this date is getting closer, we would like to summarize the discussion so far. - comments from exchange point operators: In order to be neutral, they need independant address space for the services that they offer besides the addresses used for setting up peering relationships. - many comments that they can apply for regular address space, just like anybody else - many comments that it is too hard to get regular address space - we didn't see too many comments about the policy itself, until David Huberman asked the community: In lieu of any other policy changes, are you, as a RIPE member and participant in the LIR, EIX, and IPv6 WGs, in favor of the interim policy proposal for IPv6 address assignment policy for internet exchange points? - quite some people reacted and responded with a 'yes' - few comments were send earlier to the list that a policy might not be needed at all - several different proposals were sent to make it easier to get sTLA address space (which can be used by exchange points too) - most want to relax the current rules in some way or the other - people are worried about easier rules for special interest groups (eg. IXPs, small or big providers) - one completely different proposal was submitted that proposed to allocate a sTLA to exchange point operators which can be used to assign address space to customers - worry was expressed that the interim policy will not be as interim as suggested At this point, it looks like that the community is supportive of the interim policy but that there are still issues regarding address space needs other than for the exchange points customer peering sessions. These issues are not really part of the discussion regarding the interim policy but seems part of a grander discussion regarding the revision of allocation guidelines for ipv6 address space. We should be able to get progress on this topic on the next RIPE meeting (and on the mailing list before that). We appreciate all the input that we have had so far and we continue to encourage you to let your opinion known. Thanks, Fearghas McKay David Kessens EIX-WG Chair IPv6 wg Chair --- From peter.galbavy at knowtion.net Wed Sep 5 08:41:02 2001 From: peter.galbavy at knowtion.net (Peter Galbavy) Date: Wed, 5 Sep 2001 07:41:02 +0100 Subject: Interim Policy proposal for IPv6 Address Assignment Policy for Internet Exchange Points References: <001e01c1353a$db975d70$4000a8c0@interhouse.redbus.com> Message-ID: <00ba01c135d5$be8ad400$0abc10ac@interhouse.redbus.com> > > While the technical discussion is very important, please also do not loose > > site of the fact that it is not RIPEs role to act as a regulator. You > > cannot restrict a companies (or individuals) ability to carry out normal > > business because you think they are 'too small'. > > what are you people smoking? > > what is proposed is a NEW way of getting space in a specific case, not a > restriction, but a very specific liberalization. > > can we lower the hystrionics please? Randy, Cartels may be the norm where you operate, but in the EU they are not so tolerated - except for oil and car companies of course ;-) Regardless of the current straight-jacket allocation policies at the moment, they are non-discriminatory in the sense that they do not talk about the applicants legal / commercial shape. Some people are proposing the allocation guidelines discriminate based on the applicant and not their technical requirements / qualifications. Peter From jdd at vbc.net Tue Sep 4 17:00:31 2001 From: jdd at vbc.net (Jim Dixon) Date: Tue, 4 Sep 2001 16:00:31 +0100 (BST) Subject: Interim Policy proposal for IPv6 Address Assignment Policy for Internet Exchange Points In-Reply-To: <20010904100706.A2622@partan.com> Message-ID: On Tue, 4 Sep 2001, Andrew Partan wrote: > > AIUI the reason for restricting who gets sub TLAs is... > > If everyone (multihomed customers) gets a sub TLA then the > > default-free routing table fills up with multihomed customer sub > > TLAs and IPv6 routing tables are as cluttered and unscalable as IPv4. > > Bingo! Thats the real reason. The only known way of keeping > routing working is keeping the tables small. There is no known > technical means of doing this at the moment, so we are forced into > the administrative realm. Thus you see all sorts of rules & > regulations about addreses and how to get them and use them. This comes close to making sense - until you realise that RIPE's rules for allocating IPv6 address space are MORE stringent than those used for allocating IPv4 address space. If the rule was that the fact that RIPE had allocated IPv4 address space automatically qualified an ISP for an allocation of IPv6 addresses, then its obvious that the IPv6 routing tables would grow no faster than the IPv4 tables [1]. But in fact what we have are much more restrictive rules for allocations from a very much larger address space. This is not easily explained as the consequence of rational policies on the allocation of address space. But it is an obvious consequence of one might call the Galbavy Rule: the urge to regulate is independent of any practical need for regulation. [2] NOTE: [1] Of course RIPE assignment policies mean that most ISPs will come to have multiple IPv4 address blocks, whereas they would have only one IPv6 block, so the IPv6 routing table should grow much more slowly than the IPv4 routing table. [2] And one should not forget that once you get your IPv6 prefix, you should never have to go back to RIPE again, depriving the regulators of anything to do. -- Jim Dixon VBCnet GB Ltd http://www.vbc.net tel +44 117 929 1316 fax +44 117 927 2015 From keith at xchangepoint.net Tue Sep 4 17:19:46 2001 From: keith at xchangepoint.net (Keith Mitchell) Date: Tue, 04 Sep 2001 16:19:46 +0100 Subject: Interim Policy proposal for IPv6 Address Assignment Policy forInternet Exchange Points References: <3B94E5B8.42DBA09F@xchangepoint.net> Message-ID: <3B94F112.6489530F@xchangepoint.net> Keith Mitchell wrote: > So long as the same policies for "PI" IPv6 space remain open to IXPs > to use for their non-peering-mesh requirements in the same way some > use their own LIR IPv4 space, then I am satisfied the proposed policy > is a reasonable approac Sorry - to clarify, I meant that I was happy provided IXPs were not prevented from applying for sub-TLA IPv6 space on the basis of the same criteria as anyone else. Keith From djp-ripe-lists at djp.net Wed Sep 5 10:16:07 2001 From: djp-ripe-lists at djp.net (Dave Pratt) Date: Wed, 5 Sep 2001 10:16:07 +0200 (CEST) Subject: Interim Policy proposal for IPv6 Address Assignment Policy forInternet Exchange Points In-Reply-To: Message-ID: Hiya, On Tue, 4 Sep 2001, David R Huberman wrote: ->So I ask: -> ->In lieu of any other policy changes, are you, as a RIPE member and ->participant in the LIR, EIX, and IPv6 WGs, in favor of the interim policy ->proposal for IPv6 address assignment policy for internet exchange points? -> ->/david Sorry, I cannot agree with the proposed policy as it stands since: 1. The idea of issuing a single/multiple /64 is totally unnecessary. 2. As stated many times by many, the IXP need globally routed space, which they cannot get under present normal sTLA allocation rules. Allocate a /48 (or larger), and remove the comments about not being "globally routable" and I would be happy. Cheers Dave From kurtis at kpnqwest.net Wed Sep 5 09:51:03 2001 From: kurtis at kpnqwest.net (Kurt Erik Lindqvist KPNQwest Sweden) Date: Wed, 5 Sep 2001 09:51:03 +0200 (MEST) Subject: Interim Policy proposal for IPv6 Address Assignment Policy for Internet Exchange Points In-Reply-To: <15252456895868323600120552387@localhost.localdomain> Message-ID: > Is this the issue? If not, why not give out sub TLAs to all who want them? Becuase we don't want a PTOMAINng? - kurtis - From stevew at xchangepoint.net Wed Sep 5 10:34:25 2001 From: stevew at xchangepoint.net (Steve Walker) Date: Wed, 05 Sep 2001 09:34:25 +0100 Subject: Interim Policy proposal for IPv6 Address Assignment Policy forInternet Exchange Points References: Message-ID: <3B95E391.3C698FCC@xchangepoint.net> Dave, Dave Pratt wrote: > > Sorry, I cannot agree with the proposed policy as it stands since: > > 1. The idea of issuing a single/multiple /64 is totally unnecessary. > 2. As stated many times by many, the IXP need globally routed space, which > they cannot get under present normal sTLA allocation rules. > > Allocate a /48 (or larger), and remove the comments about not being "globally > routable" and I would be happy. While I understand you don`t agree with the policy as its stands, it is an *interim* proposal to facilitate v6 take-up within the ixp community. No doubt if we shift the policy to fit your wishes, someone else will disagree. In the interests of pragmatic progression, lets debate these issues from the perspective of a working model and get this policy approved. Regards, Steve. From jdd at vbc.net Wed Sep 5 10:51:42 2001 From: jdd at vbc.net (Jim Dixon) Date: Wed, 5 Sep 2001 09:51:42 +0100 (BST) Subject: Interim summary of current discussions In-Reply-To: <20010904150912.A7344@iprg.nokia.com> Message-ID: On Tue, 4 Sep 2001, David Kessens wrote: > In lieu of any other policy changes, are you, as a RIPE member and > participant in the LIR, EIX, and IPv6 WGs, in favor of the interim > policy proposal for IPv6 address assignment policy for internet > exchange points? > > - quite some people reacted and responded with a 'yes' Correct me if I am wrong: * there were 3 responses * RIPE has more than 1000 members * 1 of the 3 respondents does not represent a RIPE member > - few comments were send earlier to the list that a policy might > not be needed at all -- Jim Dixon VBCnet GB Ltd http://www.vbc.net tel +44 117 929 1316 fax +44 117 927 2015 From pjw at ip-engineering.bt.com Wed Sep 5 11:50:26 2001 From: pjw at ip-engineering.bt.com (Peter Willis) Date: Wed, 05 Sep 2001 10:50:26 +0100 Subject: Interim Policy proposal for IPv6 Address Assignment Policy for Internet Exchange Points In-Reply-To: Your message of "Tue, 04 Sep 2001 16:00:31 BST." Message-ID: <200109050950.KAA03584@celiborn.ip-engineering.bt.com> Colleagues, Why don't we give every LIR an IPv6 TLA without any further qualification? There's only 2859 LIRs in RIPE! How many in the World? Somewhere between 8000 and 16000? I've seen figures suggesting there's only 15K ISPs in the World. 16K routes is a lot less than 100K+. Of course we have to fix the multihoming problem to keep the number of routes down. But even if we only give TLAs to the few global tier 1 transit providers if we don't fix the multihoming problem we will end up with a huge number of routes. So the problem is to fix multihoming with a technical solution and not to manage the problem through regulation. Peter Willis. BTexact Technologies. From jdd at vbc.net Wed Sep 5 13:51:19 2001 From: jdd at vbc.net (Jim Dixon) Date: Wed, 5 Sep 2001 12:51:19 +0100 (BST) Subject: Interim Policy proposal for IPv6 Address Assignment Policy for Internet Exchange Points In-Reply-To: <200109050950.KAA03584@celiborn.ip-engineering.bt.com> Message-ID: On Wed, 5 Sep 2001, Peter Willis wrote: > Colleagues, > > Why don't we give every LIR an IPv6 TLA without any further qualification? > There's only 2859 LIRs in RIPE! How many in the World? Somewhere between > 8000 and 16000? I've seen figures suggesting there's only 15K ISPs in the > World. 16K routes is a lot less than 100K+. Indeed. In fact, if the policy was simply to give an IPv6 TLA to any LIR who asked for one, it's likely that perhaps 10% would apply. So a negligible 300 or so additional IPv6 routes and a negligible amount of paperwork -- in fact this could just be handled by a robot hanging off www.ripe.net. The only work involved is writing the script. > Of course we have to fix the multihoming problem to keep the number of routes > down. But even if we only give TLAs to the few global tier 1 transit providers > if we don't fix the multihoming problem we will end up with a huge number of > routes. So the problem is to fix multihoming with a technical solution and not > to manage the problem through regulation. Precisely. > Peter Willis. > BTexact Technologies. -- Jim Dixon VBCnet GB Ltd http://www.vbc.net tel +44 117 929 1316 fax +44 117 927 2015 From stephenb at uk.uu.net Wed Sep 5 16:03:08 2001 From: stephenb at uk.uu.net (Stephen Burley) Date: Wed, 5 Sep 2001 15:03:08 +0100 Subject: Interim Policy proposal for IPv6 Address Assignment Policy forInternet Exchange Points References: <3B95E391.3C698FCC@xchangepoint.net> Message-ID: <004001c13613$7e080d60$2e04bf3e@eu.frd.uu.net> > Dave, > > Dave Pratt wrote: > > > > Sorry, I cannot agree with the proposed policy as it stands since: > > > > 1. The idea of issuing a single/multiple /64 is totally unnecessary. > > 2. As stated many times by many, the IXP need globally routed space, which > > they cannot get under present normal sTLA allocation rules. > > > > Allocate a /48 (or larger), and remove the comments about not being "globally > > routable" and I would be happy. > > While I understand you don`t agree with the policy as its stands, it is > an *interim* proposal to facilitate v6 take-up within the ixp > community. The trouble with *interim* policies is once they are in place they never change or are very difficult to change. > > No doubt if we shift the policy to fit your wishes, someone else will > disagree. In the interests of pragmatic progression, lets debate these > issues from the perspective of a working model and get this policy > approved. > > Regards, Steve. From randy at psg.com Wed Sep 5 16:15:38 2001 From: randy at psg.com (Randy Bush) Date: Wed, 05 Sep 2001 07:15:38 -0700 Subject: Interim Policy proposal for IPv6 Address Assignment Policy forInternet Exchange Points References: Message-ID: > 1. The idea of issuing a single/multiple /64 is totally unnecessary. > 2. As stated many times by many, the IXP need globally routed space, which > they cannot get under present normal sTLA allocation rules. both above statements are patently false. 1. there are ixs who need/want it and are actively waiting for the /64 to open their mesh 2. the ix can get globally routable sTLA just like everybody else can. randy From pekkas at netcore.fi Wed Sep 5 16:17:33 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 5 Sep 2001 17:17:33 +0300 (EEST) Subject: Interim Policy proposal for IPv6 Address Assignment Policy forInternet Exchange Points In-Reply-To: Message-ID: On Wed, 5 Sep 2001, Dave Pratt wrote: > Sorry, I cannot agree with the proposed policy as it stands since: > > 1. The idea of issuing a single/multiple /64 is totally unnecessary. > 2. As stated many times by many, the IXP need globally routed space, which > they cannot get under present normal sTLA allocation rules. > > Allocate a /48 (or larger), and remove the comments about not being "globally > routable" and I would be happy. The comments should not be removed, as RIPE cannot stipulate what people will put in their DFZ filters. Currently the filters are what they are, and if you start advertising your /64 hoping it'll get globally routable, I fear you'd be in for a long, long wait. -- 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 From david at IPRG.nokia.com Wed Sep 5 20:55:00 2001 From: david at IPRG.nokia.com (David Kessens) Date: Wed, 5 Sep 2001 11:55:00 -0700 Subject: Interim summary of current discussions In-Reply-To: ; from Jim Dixon on Wed, Sep 05, 2001 at 09:51:42AM +0100 References: <20010904150912.A7344@iprg.nokia.com> Message-ID: <20010905115500.D19879@iprg.nokia.com> Jim, On Wed, Sep 05, 2001 at 09:51:42AM +0100, Jim Dixon wrote: > On Tue, 4 Sep 2001, David Kessens wrote: > > > In lieu of any other policy changes, are you, as a RIPE member and > > participant in the LIR, EIX, and IPv6 WGs, in favor of the interim > > policy proposal for IPv6 address assignment policy for internet > > exchange points? > > > > - quite some people reacted and responded with a 'yes' > > Correct me if I am wrong: > > * there were 3 responses > * RIPE has more than 1000 members > * 1 of the 3 respondents does not represent a RIPE member > > > - few comments were send earlier to the list that a policy might > > not be needed at all The purpose of this discussion is to reach 'rough consensus' on this new policy in the RIPE community - not necessarily just the RIPE NCC members. There is no need for everybody to react on the proposal. The goal is to give everybody a chance to participate in this discussion in the public and the assumption is that if people are not participating that they are not unhappy about the direction of the discussion as it is developing. For this reason, we posted an interim summary to the list in order to make sure that everybody is on the same page on the direction that the discussion is taking right now as perceived by the chairpeople. The summary is a very good chance for people who don't agree with the current direction of the discussion to voice their concerns and so far we have seen that indeed some objections have been raised. What's your opinion on the proposed policy ?!? Do you have strong objections why this policy should not go through, but you have suggestions with improvements that could make the policy reasonable in your eyes, or can you live with it as it is right now - but you might still have suggestions for improvement that we can use for the next version of the policy. Thanks, David K. --- From david at IPRG.nokia.com Wed Sep 5 21:24:01 2001 From: david at IPRG.nokia.com (David Kessens) Date: Wed, 5 Sep 2001 12:24:01 -0700 Subject: Interim Policy proposal for IPv6 Address Assignment Policy forInternet Exchange Points In-Reply-To: ; from Randy Bush on Wed, Sep 05, 2001 at 07:15:38AM -0700 References: Message-ID: <20010905122401.E19879@iprg.nokia.com> Randy, On Wed, Sep 05, 2001 at 07:15:38AM -0700, Randy Bush wrote: > > 1. The idea of issuing a single/multiple /64 is totally unnecessary. > > 2. As stated many times by many, the IXP need globally routed space, which > > they cannot get under present normal sTLA allocation rules. > > both above statements are patently false. > > 1. there are ixs who need/want it and are actively waiting for the /64 > to open their mesh > > 2. the ix can get globally routable sTLA just like everybody else can. As pointed out earlier, there are alternative ways of getting a /64 for an exchange point. Therefore, Dave's first statement is not in any way a 'patently false' statement as you claim. The ixs that you are talking about decided that those alternative solutions are not good enough for them - while for example Palo Alto Internet Exchange apparently decided that the alternative solution served their business needs just fine. And then there is yet-another-solution that doesn't even need a /64 but that results in ugly traceroutes. As for your second point, I don't think it is as easy as you claim it is. Yes, exchange point operators can ask for a sTLA, but at the same time, the requirements to get them according to the current allocation policy make it very hard to get one without bending the guidelines or without interpreting the guidelines in a way that only the us supreme court can understand. Luckily enough, the guidelines are up for revision so we will have a chance to fix that :-). David K. --- From djp-ripe-lists at djp.net Thu Sep 6 10:24:55 2001 From: djp-ripe-lists at djp.net (Dave Pratt) Date: Thu, 6 Sep 2001 10:24:55 +0200 (CEST) Subject: Interim Policy proposal for IPv6 Address Assignment Policy forInternet Exchange Points In-Reply-To: <20010905122401.E19879@iprg.nokia.com> Message-ID: Hiya all, I wrote: ->> > 1. The idea of issuing a single/multiple /64 is totally unnecessary. This point was poorly expressed and could be mis-interpreted. As hinted at later in the same email, allocating a /48 makes much more sense to me if we want to save work for the NCC and the IXPs. Cheers Dave From fm at st-kilda.org Thu Sep 6 11:27:30 2001 From: fm at st-kilda.org (Fearghas McKay) Date: Thu, 6 Sep 2001 10:27:30 +0100 Subject: Interim Policy proposal for IPv6 Address Assignment Policy forInternet Exchange Points In-Reply-To: References: Message-ID: Hi Dave At 10:24 am +0200 6/9/01, Dave Pratt wrote: >I wrote: >->> > 1. The idea of issuing a single/multiple /64 is totally unnecessary. > >This point was poorly expressed and could be mis-interpreted. As hinted at >later in the same email, allocating a /48 makes much more sense to me if we >want to save work for the NCC and the IXPs. The current proposed allocations are being made with /48 boundaries so that we can make the change following discussion in Prague if that is the consensus about the interim policy. We, as in the WG-Chairs and the NCC, have tried to make the interim policy extensible to allow it to be easily modified as we get more feedback on areas that were causing some people concern but that there was no consensus of what was the right way forward. f From stephenb at uk.uu.net Thu Sep 6 16:13:03 2001 From: stephenb at uk.uu.net (Stephen Burley) Date: Thu, 6 Sep 2001 15:13:03 +0100 Subject: MIR proposal Message-ID: <01e001c136de$0ac9ee10$2e04bf3e@eu.frd.uu.net> 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 From gert at space.net Thu Sep 6 16:39:18 2001 From: gert at space.net (Gert Doering) Date: Thu, 6 Sep 2001 16:39:18 +0200 Subject: MIR proposal In-Reply-To: <01e001c136de$0ac9ee10$2e04bf3e@eu.frd.uu.net>; from stephenb@uk.uu.net on Thu, Sep 06, 2001 at 03:13:03PM +0100 References: <01e001c136de$0ac9ee10$2e04bf3e@eu.frd.uu.net> Message-ID: <20010906163918.C11979@Space.Net> Hi, On Thu, Sep 06, 2001 at 03:13:03PM +0100, Stephen Burley wrote: > Ok the proposal. [..] I can understand your needs, and your proposal is a way to tackle it. The problems do not only arise on "multinational scale", though. We're a small-to-medium ISP/LIR (with only about 1.5 /16's), and we're also facing the fact that we'd like to do better hierarchical routing, facing a structure of independent re-sellers that again have their own re-sellers, all of them getting their IP addresses from us. So what I could imagine is a less formal organization structure without a "MIR" - but permit LIRs, under certain circumstances, to do sub-allocations, like "*allocate* a /22 to this reseller and /21 to that one". Maybe a combination of both. A MIR + LIR structure for the Really Huge networks, and LIR + sub-allocations for smaller networks with a need (or the desire) for hierarchical structure. And yes, this is also very much needed for IPv6. Getting a /35 and having to hand out individual /48's to customers of customers of ours isn't going to build proper hierarchical routing. Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From crain at icann.org Thu Sep 6 17:03:51 2001 From: crain at icann.org (John L Crain) Date: Thu, 6 Sep 2001 08:03:51 -0700 (PDT) Subject: MIR proposal In-Reply-To: <20010906163918.C11979@Space.Net> References: <20010906163918.C11979@Space.Net> Message-ID: <2062.200.40.200.65.999788631.squirrel@plata.icann.org> Hi Gert, > > And yes, this is also very much needed for IPv6. Getting a /35 and > having to hand out individual /48's to customers of customers of ours > isn't going to build proper hierarchical routing. The concepts for IPv6 that are under discussion do already cover this. An allocation goes to a large ISP who can then assign /48's directly to networks connecting to them or shorter prefixes to resellers/downstreams. I'm not sure if this works in IPv4 because of the limited amount of room we have to play with. I'm also not sure what the criteria would be in the proposal that defines who is and isn't allowed to become a MIR. It's certainly a differnet concept to the present one in the RIPE region where LIR's don't "officially" sub- allocate. I can certainly see why a large ISP would want to do this. I'm not sure how it changes the dynamics for smaller ISP's as to how they would get their IP addresses. Becoming an LIR with an upstream rather than a regional registry I assume means renumbering if you change the upstream. John Crain From stephenb at uk.uu.net Thu Sep 6 17:10:18 2001 From: stephenb at uk.uu.net (Stephen Burley) Date: Thu, 6 Sep 2001 16:10:18 +0100 Subject: MIR proposal References: <20010906163918.C11979@Space.Net> <2062.200.40.200.65.999788631.squirrel@plata.icann.org> Message-ID: <01fa01c136e6$0a477e00$2e04bf3e@eu.frd.uu.net> ----- Original Message ----- From: "John L Crain" To: Sent: Thursday, September 06, 2001 4:03 PM Subject: Re: MIR proposal > > > Hi Gert, > > > > > And yes, this is also very much needed for IPv6. Getting a /35 and > > having to hand out individual /48's to customers of customers of ours > > isn't going to build proper hierarchical routing. > > The concepts for IPv6 that are under discussion do already cover this. > An allocation goes to a large ISP who can then assign /48's directly to > networks connecting to them or shorter prefixes to resellers/downstreams. > > I'm not sure if this works in IPv4 because of the limited amount of room we > have to play with. We are only limited because of teh current thinking and structure. > > I'm also not sure what the criteria would be in the proposal that defines > who is and isn't allowed to become a MIR. It's certainly a differnet concept > to the present one in the RIPE region where LIR's don't "officially" sub- > allocate. > Its not so different from the RIR model. > I can certainly see why a large ISP would want to do this. I'm not sure how > it changes the dynamics for smaller ISP's as to how they would get their IP > addresses. Becoming an LIR with an upstream rather than a regional registry > I assume means renumbering if you change the upstream. > MIR's are only to be created within a network (AS if you like) they would not suballocate to customers only LIR's withing their network (usualy country specific). Other LIR's not needing a MIR would deal direct with the NCC. UUNET has 17 LIR's currently the MIR would suballocate to these not to other ISP's or customers direct. BTW Nice to hear from you. > John Crain > > > > > > From nurani at ripe.net Thu Sep 6 18:27:34 2001 From: nurani at ripe.net (Nurani Nimpuno) Date: Thu, 06 Sep 2001 18:27:34 +0200 Subject: 101 IPv6 allocations made globally Message-ID: <200109061627.SAA26830@office.ripe.net> Dear all, This is to inform you that in the last days, the RIRs last week reached a total of 101 /35 (SubTLA) allocations globally. According to the global "Provisional IPv6 Assignment and Allocation Policy Document" [1], the bootstrap phase with interim criteria apply until 100 allocations have been made globally or 60 allocations in one RIR region (4.2.2.1. Duration of Bootstrap Phase). However, at last RIPE meeting (RIPE 39, May, Bologna), it was agreed to further extend the bootstrap phase. The end of the extended bootstrap phase will be discussed and defined at the upcoming RIPE 40 meeting in October. Per region, the following amount of allocations have been made: APNIC: 38 ARIN: 20 RIPE NCC: 43 A list of all IPv6 allocations made globally can be found at: http://www.ripe.net/cgi-bin/ipv6allocs Kind regards, Nurani Nimpuno *--------------------------------------------------------* | Nurani Nimpuno | | Internet Address Policy Manager | | RIPE Network Co-ordination Centre | | http://www.ripe.net | *--------------------------------------------------------* [1] http://www.ripe.net/ripe/docs/ipv6policy.html From woeber at cc.univie.ac.at Thu Sep 6 21:54:22 2001 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Thu, 06 Sep 2001 21:54:22 +0200 Subject: Interim Policy proposal for IPv6 Address Assignment Policy forInternet Exchange Points Message-ID: <00A01AA6.F36E5032.1@cc.univie.ac.at> >The chairs put forth this interim policy proposal to these lists hoping to >garner consensus or judge that consensus does not exist. > >The ensuing discussion, while not unuseful, does not appear (to me) to be >helping the chairs and the wg membership from gauging the extent to which >there is consensus for this interim policy proposal. > >So I ask: I think it was your intent to separate discussion/improvement from "tallying" pro.s and com.s - so I?ll summarize my comments in a separate message... >In lieu of any other policy changes, are you, as a RIPE member and >participant in the LIR, EIX, and IPv6 WGs, in favor of the interim policy >proposal for IPv6 address assignment policy for internet exchange points? YES. >/david Wilfried. _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber at 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From woeber at cc.univie.ac.at Thu Sep 6 22:48:25 2001 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Thu, 06 Sep 2001 22:48:25 +0200 Subject: Interim Policy proposal for IPv6 Address Assignment Policy for Internet Exchange Points Message-ID: <00A01AAE.807003A2.8@cc.univie.ac.at> IPv6 Address Assignment Policy for Internet Exchange Points =========================================================== 1. Abstract ----------- This document describes a policy for Internet Exchange Points (IXPs) under which unique IPv6 address space to be used for the infrastructure of the Internet Exchange Point can be obtained from a Regional Internet Registry (RIR). 2. Background ------------- It has been recognised that there are scenarios in which it is not desirable for IXPs to obtain address space from one of the Internet editorial: the term "desirable" is much too weak. This can set a precedent for other (presumably) special cases/groups/applications to request similar treatment. I?d propose something like feasable or acceptable. Service Providers (ISPs) connecting at the IXP. In these cases it is viable to have unique IPv6 address space assigned directly from an RIR. This address space is needed to adress the Exchange fabric. This issue has been brought forward to the RIPE community in May 2000 and has subsequently been discussed at RIPE Meetings and on public RIPE mailing lists. The conclusions of these discussions are described in this document. It is expected that the same policy will be accepted in the ARIN and the APNIC region at which point it will be incorporated in the Global IPv6 Policy document. editorial: as suggested by others, the additional paragraph explaining the "regular" paths (RFC/6Bone or regular ISP application) might go in here. 3. Definition ------------- An Internet Exchange Point is defined as a physical network infrastructure (layer 2) operated by a single entity with the purpose to facilitate the exchange of Internet traffic between Internet service providers. The number of Internet Service providers connected should at least be three and there must be a clear and open policy for others to join. Addresses needed for other purposes (e.g. additional services provided to the members) should be aquired through other appropriate means ( e.g. an upstream ISP). This is both too restrictive (from a technology point of view), as well as too blurry: - there might be cases for an IPv6 exchange point which starts on or operates on an existing (layer2 or 3) fabric. Tunnels in v4 or a multicast-enabled v4 net used as a layer 2 tech for v6 spring to my mind. - the use of "Should" seemms to be odd in a policy definition - I would not be able to judge what an "open policy for others to join" would look like as a minimum 4. Policy --------- I think 3. and 4. should be swapped. An IXP that seeks to obtain an IPv6 address assignment by the RIR in its region, needs to submit a request to that RIR. IXPs operating in the RIPE NCC service region should use the 'IPv6 Request Form for Internet Exchange Points' (http://www.ripe.net/ripe/docs/ipv6request-exchangepoint.html). After approval of the request, the RIR will make the assignment. Since the address space does not need to be routable globally and an IXP is expected to only have one subnet, a /64 (64 bits of address space) will be assigned in most cases. In the case the IXP is using multiple fabrics (e.g. unicast separated for multicast), multiple /64s can be assigned to the IXP. IP Address requests can only be handled if the requestor is a Local Internet Registry (LIR) or if the request made through an existing LIR. 5. Other Considerations ----------------------- It should be noted that ISPs usually do not announce address space used on the IXP mesh itself to their peers. That means the address space assigned under this policy is likely not to be routable globally. From paul.mylotte at bt.com Fri Sep 7 18:05:20 2001 From: paul.mylotte at bt.com (paul.mylotte at bt.com) Date: Fri, 7 Sep 2001 17:05:20 +0100 Subject: Interim Policy proposal for IPv6 Address Assignment Policy fo rInternet Exchange Points Message-ID: All, YES - and I am hoping that the WGs will reach consensus at the Prague meeting that the interim policy-based allocations will permit extension to a /48 allocation. Paul P. S. Mylotte IP Addressing & Naming BTexact Technologies Adastral Park 01473 606333 / + 44 1473 606333 paul.mylotte at bt.com BTexact Technologies is a trademark of British Telecommunications plc Registered office 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000 This electronic message contains information from British Telecommunications plc which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the number or address above) immediately. > -----Original Message----- > From: David R Huberman [SMTP:huberman at gblx.net] > Sent: 04 September 2001 17:57 > To: lir-wg at ripe.net; eix-wg at ripe.net; ipv6-wg at ripe.net > Subject: Re: Interim Policy proposal for IPv6 Address Assignment > Policy forInternet Exchange Points > > > So I ask: > > > > In lieu of any other policy changes, are you, as a RIPE member and > > participant in the LIR, EIX, and IPv6 WGs, in favor of the interim > policy > > proposal for IPv6 address assignment policy for internet exchange > points? > > To answer my own question, I support the interim policy proposal and hope > it is ratified by the WGs as soon as possible. > > /david From randy at psg.com Fri Sep 7 18:08:27 2001 From: randy at psg.com (Randy Bush) Date: Fri, 07 Sep 2001 09:08:27 -0700 Subject: Interim Policy proposal for IPv6 Address Assignment Policy fo rInternet Exchange Points References: Message-ID: you have sent a message to me which seems to contain a legal warning on who can read it, or how it may be distributed, or whether it may be archived, etc. i do not accept such email, and have therefore deleted it. do not expect further response. randy From peter.galbavy at knowtion.net Fri Sep 7 20:10:08 2001 From: peter.galbavy at knowtion.net (Peter Galbavy) Date: Fri, 7 Sep 2001 19:10:08 +0100 Subject: Interim Policy proposal for IPv6 Address Assignment Policy forInternet Exchange Points References: Message-ID: <005e01c137c8$57072f00$79cb87d4@peterdesktop> This is one of the few things that I >wholly< agree with Randy on. Do NOT post on public mailing lists if your company policies do not let you, or you expect that any random legal crap will be relevant. rgds, -- Peter Galbavy Knowtion Ltd. http://www.knowtion.net/ ----- Original Message ----- From: "Randy Bush" To: Cc: ; ; ; Sent: Friday, September 07, 2001 5:08 PM Subject: RE: Interim Policy proposal for IPv6 Address Assignment Policy forInternet Exchange Points > you have sent a message to me which seems to contain a legal warning > on who can read it, or how it may be distributed, or whether it may be > archived, etc. > > i do not accept such email, and have therefore deleted it. do not > expect further response. > > randy > From hph at online.no Fri Sep 7 23:55:50 2001 From: hph at online.no (Hans Petter Holen) Date: Fri, 7 Sep 2001 23:55:50 +0200 Subject: Draft: Charter & Call for paticipation RIPE-185bis References: <00f801c12b47$802279e0$0300000a@hph> <011b01c12b48$9850db00$0300000a@hph> Message-ID: <00e901c137e7$dbc0c020$0400000a@hholkvza> | Please indicate your interest to participate in this editorial team to me or | to the list. Up to date I have had the following voulenteers: Wilfried Woeber Gert Doering Azucena Hernandez Stephen Bruey and Myself. | Please suggest improvements to the mandate to the list. | | Proposed mandate: | | Facilitate discussion on the lir-wg mailing list and working group meetings | and summarise the community consensus. | Ensure that the community consensus on what IP addressing policies is to be | in the RIPE NCC service region is documented in a concise and simple | language. I have had one suggestion to extend the mandate: - Try to achieve allignemet between the IP addressing policies in the RIPE NCC region and in the other regions to the maximum extent possible. | Proposed Timeline: | | 2208 Call for participation | 2908 First draft to be published based on RIPE 185 discussion at mailinglist | 0509 Formation of the group, freeze mandate | | 1002 1st workshop | 1003 discussion at lir-wg meeting | 1004 2nd workshop | | 1015 Second draft to be published | | Note that this timeline is quite agressive, and that it suggests that we do | quite a bit of work at the upcoming RIPE meeting. I do however belive that | this timeline is relatively realistic. In my oppinion it is better to revise | this timeline. We are slightly behind the schedule, but there should still be ample time to read and comment on the draft recently posted by Nurani. --- Hans Petter Holen, Technical Manager Tiscali, Norway, +47 24 11 26 44 mobile: +47 99 21 76 70 fax:+47 24 11 24 11 From woeber at cc.univie.ac.at Sun Sep 9 00:04:15 2001 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Sun, 09 Sep 2001 00:04:15 +0200 Subject: MIR proposal Message-ID: <00A01C4B.6D717242.16@cc.univie.ac.at> Stephen, >Ok the proposal. 2 brief questions, the 2nd one might be pretty stupid, actually: 1) do I correctly read (between the lines) that you would be prepared to renumber into a properly sized new block? 2) would your IGP-problem, at least in theory, be solvable by braking the AS into a number of smaller ASs, say roughly along the lines of your address blocks per registry? Thanks, Wilfried From alipour at mail.dci.co.ir Sun Sep 9 11:29:30 2001 From: alipour at mail.dci.co.ir (Hamid Alipour) Date: Sun, 9 Sep 2001 13:59:30 +0430 Subject: MIR proposal References: <20010906163918.C11979@Space.Net> <2062.200.40.200.65.999788631.squirrel@plata.icann.org> <01fa01c136e6$0a477e00$2e04bf3e@eu.frd.uu.net> Message-ID: <006001c13911$edbe8d40$fa3b92c3@itc.ir> Stephen seems just wants to solve UUNET problem with proposing MIR. However I am agree basically with the Idea. APNIC has added NIR ( National Internet Registry ) to the hierarchy. I think RIPE must let the NIRs as well. ----- Original Message ----- From: "Stephen Burley" To: ; Sent: 06/09/2001 7:40 ?.? Subject: Re: MIR proposal > > ----- Original Message ----- > From: "John L Crain" > To: > Sent: Thursday, September 06, 2001 4:03 PM > Subject: Re: MIR proposal > > > > > > > > Hi Gert, > > > > > > > > And yes, this is also very much needed for IPv6. Getting a /35 and > > > having to hand out individual /48's to customers of customers of ours > > > isn't going to build proper hierarchical routing. > > > > The concepts for IPv6 that are under discussion do already cover this. > > An allocation goes to a large ISP who can then assign /48's directly to > > networks connecting to them or shorter prefixes to resellers/downstreams. > > > > I'm not sure if this works in IPv4 because of the limited amount of room > we > > have to play with. > > We are only limited because of teh current thinking and structure. > > > > > > I'm also not sure what the criteria would be in the proposal that defines > > who is and isn't allowed to become a MIR. It's certainly a differnet > concept > > to the present one in the RIPE region where LIR's don't "officially" sub- > > allocate. > > > > Its not so different from the RIR model. > > > I can certainly see why a large ISP would want to do this. I'm not sure > how > > it changes the dynamics for smaller ISP's as to how they would get their > IP > > addresses. Becoming an LIR with an upstream rather than a regional > registry > > I assume means renumbering if you change the upstream. > > > > MIR's are only to be created within a network (AS if you like) they would > not suballocate to customers only LIR's withing their network (usualy > country specific). Other LIR's not needing a MIR would deal direct with the > NCC. UUNET has 17 LIR's currently the MIR would suballocate to these not to > other ISP's or customers direct. > BTW Nice to hear from you. > > > > John Crain > > > > > > > > > > > > From david at iprg.nokia.com Mon Sep 10 07:22:31 2001 From: david at iprg.nokia.com (David Kessens) Date: Sun, 9 Sep 2001 22:22:31 -0700 Subject: Exchange point interim policy Message-ID: <20010909222231.A300@iprg.nokia.com> The final date for comments on the proposed interim policy for ipv6 address allocations for Internet exchange points has passed. Since posting the interim conclusions, the direction of the discussion has not fundamentally changed. Therefore, we believe that we can ask the RIPE NCC to publish the proposed policy now, to clearly mark it as an interim policy and to start making the first allocations (with /64 allocations made out of fully reserved /48's and all allocations made out of one common block of address space). We would like to emphasize that this is the first version of the policy. It's pretty clear from the discussions on the list that though the policy is approved, there are still some issues that need more discussion. It looks like that many people felt that it was more important to get a policy in place rather sooner than later despite that they might not agree with all details in the policy. We have asked the RIPE NCC to reserve a slot at the next RIPE meeting to discuss the remaining issues and make recommendations to the RIPE NCC for improvements to the interim policy. Issues that we currently have on our list include: - 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 Don't hesitate to contact us if you want to have other issues discussed as well. For discussions on the maillist, we suggest that you post your mail only to the lir-wg list. Thanks, Fearghas McKay David Kessens EIX-WG Chair IPv6 wg Chair --- From stephenb at uk.uu.net Mon Sep 10 10:59:38 2001 From: stephenb at uk.uu.net (Stephen Burley) Date: Mon, 10 Sep 2001 09:59:38 +0100 Subject: MIR proposal References: <00A01C4B.6D717242.16@cc.univie.ac.at> Message-ID: <029b01c139d6$ebfdade0$2e04bf3e@eu.frd.uu.net> ----- Original Message ----- From: "Wilfried Woeber, UniVie/ACOnet" To: Cc: ; Sent: Saturday, September 08, 2001 11:04 PM Subject: RE: MIR proposal > Stephen, > > >Ok the proposal. > > 2 brief questions, the 2nd one might be pretty stupid, actually: > > 1) do I correctly read (between the lines) that you would be prepared to > renumber into a properly sized new block? This is a major undertaking but looking at AS701 it may be the only solution in the long run, the new registries would not be too bad but the older ones would be a nightmare. > > 2) would your IGP-problem, at least in theory, be solvable by braking the > AS into a number of smaller ASs, say roughly along the lines of your > address blocks per registry? > No we have moved from multiple AS to a single AS to solve some of this problem and others too. > Thanks, > Wilfried From david at iprg.nokia.com Tue Sep 11 02:14:59 2001 From: david at iprg.nokia.com (David Kessens) Date: Mon, 10 Sep 2001 17:14:59 -0700 Subject: draft agendas (v1) for IPv6/lir/eix joint sessions RIPE40 Message-ID: <20010910171459.A23587@iprg.nokia.com> Hi, Below follow the first drafts of the agendas for the joint sessions regarding ipv6 allocation policies. We have asked to schedule two seperate sessions, one for discussions regarding the new interim policy for exchange points, and one for discussions regarding the revision of the general allocation guidelines. We would like to limit discussion to the lir-wg maillist to minimize the amount of duplicate mails. Please let me know if you have any other topics that you want to have discussed and we will try to accomodate them in the agenda. Thanks, David K. --- Agenda for the IPv6/lir joint session RIPE40, Prague Topic: Revision of the general ipv6 allocation guidelines Materials to read: - ripe-196: http://www.ripe.net/ripe/docs/ipv6policy.html - http://www.ripe.net/ripe/meetings/archive/ripe-39/presentations/ipv6develop/index.html - http://www.djp.net/ipv6/proposal.html - http://www.ripe.net/ripe/meetings/archive/ripe-39/presentations/RIPE39-IPv6-policy/index.html A. Administrative stuff - appointment of scribe - agenda bashing B. How to proceed for the next iteration of the policy. C. Status of the draft currently being discussed between the RIRs (Presentations from RIRs) D. Proposal for the next version of the policy http://www.djp.net/ipv6/proposal.html (Dave Pratt) E. Discussion Z. AOB ------------------------- Agenda for the IPv6/lir/eix joint session RIPE40, Prague 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 D. Discussion of the issues Z. AOB --- From paul.mylotte at bt.com Tue Sep 11 16:24:06 2001 From: paul.mylotte at bt.com (paul.mylotte at bt.com) Date: Tue, 11 Sep 2001 15:24:06 +0100 Subject: Draft: Charter & Call for paticipation RIPE-185bis Message-ID: Hans Petter I would be very happy to contribute and participate in the editorial team as soon as possible. Regards, Paul p.s I find it a bit difficult to follow the dates you give below P. S. Mylotte BTexact Technologies Adastral Park 01473 606333 / + 44 1473 606333 paul.mylotte at bt.com > -----Original Message----- > From: Hans Petter Holen [SMTP:hph at online.no] > Sent: 07 September 2001 22:56 > To: Hans Petter Holen; lir-wg > Cc: woeber; Gert Doering; azucena.hernandez; stephenb > Subject: Re: Draft: Charter & Call for paticipation RIPE-185bis > > | Please indicate your interest to participate in this editorial team to > me > or > | to the list. > > Up to date I have had the following voulenteers: > Wilfried Woeber > Gert Doering > Azucena Hernandez > Stephen Bruey > and Myself. > > | Please suggest improvements to the mandate to the list. > | > | Proposed mandate: > | > | Facilitate discussion on the lir-wg mailing list and working group > meetings > | and summarise the community consensus. > | Ensure that the community consensus on what IP addressing policies is to > be > | in the RIPE NCC service region is documented in a concise and simple > | language. > > I have had one suggestion to extend the mandate: > - Try to achieve allignemet between the IP addressing policies in the RIPE > NCC region and in the other regions to the maximum extent possible. > > | Proposed Timeline: > | > | 2208 Call for participation > | 2908 First draft to be published based on RIPE 185 discussion at > mailinglist > | 0509 Formation of the group, freeze mandate > | > | 1002 1st workshop > | 1003 discussion at lir-wg meeting > | 1004 2nd workshop > | > | 1015 Second draft to be published > | > | Note that this timeline is quite agressive, and that it suggests that we > do > | quite a bit of work at the upcoming RIPE meeting. I do however belive > that > | this timeline is relatively realistic. In my oppinion it is better to > revise > | this timeline. > > We are slightly behind the schedule, but there should still be ample time > to > read and comment on the draft recently posted by Nurani. > > --- > Hans Petter Holen, Technical Manager > Tiscali, Norway, +47 24 11 26 44 mobile: +47 99 21 76 70 fax:+47 24 11 24 > 11 > From hph at online.no Tue Sep 11 22:09:16 2001 From: hph at online.no (Hans Petter Holen) Date: Tue, 11 Sep 2001 22:09:16 +0200 Subject: Draft: Charter & Call for paticipation RIPE-185bis References: Message-ID: <001301c13afd$a267e7e0$0400000a@hholkvza> | p.s I find it a bit difficult to follow the dates you give below Sorry about that, I hope this makes it a bit clearer: I would urge people to start to read the document and suggest changes. Status MMDD Activity Done 0822 Call for participation Done 0829 First draft to be published based on RIPE 185 discussion at mailinglist Done 0905 Formation of the group, freeze mandate 1002 1st workshop 1003 discussion at lir-wg meeting 1004 2nd workshop 1015 Second draft to be published From kevin.bates at bt.com Fri Sep 14 12:18:00 2001 From: kevin.bates at bt.com (kevin.bates at bt.com) Date: Fri, 14 Sep 2001 11:18:00 +0100 Subject: FW: NCC#2001039519 expecting reply X-NCC RegID: nl.ignite Message-ID: Greetings All Apologies to the large number of people who will receive this email unnecessarily. But I have a problem getting a response from the Ripe hostmaster re an ongoing address approval. I tried writing to lir-help at ripe.net but also with no response, see the mail attached. The ticketing system shows I am expecting a reply. Is there anything else I can do to speed up the process (apart from getting on a plane to Amsterdam) as this is now getting to the critical stage? Is anybody else having this problem? any advice gratefully received thanks kevin bates > -----Original Message----- > From: Bates,KR,Kevin,IWO24 BATESKR R > Sent: Tuesday, August 28, 2001 3:14 PM > To: 'lir-help at ripe.net' > Subject: NCC#2001039519 expecting reply X-NCC RegID: nl.ignite > > Greetings help > > On 31 July a hostmaster (Leo Vegoda) wrote to me re NCC#2001039519. > ". > . > Thanks for providing all that detail. I've had a look at it does seem > fine. Can you confirm which netname you want an approval for? I'll send > you an approval straight away, then > . > ." > > > I provided the netname the same day > ". > . > network BT-ICH-AMS-UTR > . > ." > > On 14 August not having received a response, i mailed hostmaster asking > what was happening. Got an acknowledgement but still no approval. > > > As of today the i still haven't had any further communication from the > hostmaster. > Can you let me know what is happening and if i still need to supply more > information and what information is required. > > thanks > kevin > > > > > > > From lance at uklinux.net Fri Sep 14 12:26:39 2001 From: lance at uklinux.net (lance) Date: Fri, 14 Sep 2001 11:26:39 +0100 (BST) Subject: FW: NCC#2001039519 expecting reply X-NCC RegID: nl.ignite In-Reply-To: Message-ID: On Fri, 14 Sep 2001 kevin.bates at bt.com wrote: > Greetings All > > Apologies to the large number of people who will receive this email > unnecessarily. But I have a problem getting a response from the Ripe > hostmaster re an ongoing address approval. > > I tried writing to lir-help at ripe.net but also with no response, see the mail > attached. > The ticketing system shows I am expecting a reply. > > Is there anything else I can do to speed up the process (apart from getting > on a plane to Amsterdam) as this is now getting to the critical stage? > > Is anybody else having this problem? I was surprised yesterday when a request for an AS number appears to be sat in the in queue , the oldest member of which had been there for 6 days without being assigned to a hostmaster ?? It now says 4 days :- http://www.ripe.net/cgi-bin/rttquery?ticnum=NCC%232001090025 Although maybe that is normal ?? Lance From lance at uklinux.net Fri Sep 14 12:26:39 2001 From: lance at uklinux.net (lance) Date: Fri, 14 Sep 2001 11:26:39 +0100 (BST) Subject: FW: NCC#2001039519 expecting reply X-NCC RegID: nl.ignite In-Reply-To: Message-ID: On Fri, 14 Sep 2001 kevin.bates at bt.com wrote: > Greetings All > > Apologies to the large number of people who will receive this email > unnecessarily. But I have a problem getting a response from the Ripe > hostmaster re an ongoing address approval. > > I tried writing to lir-help at ripe.net but also with no response, see the mail > attached. > The ticketing system shows I am expecting a reply. > > Is there anything else I can do to speed up the process (apart from getting > on a plane to Amsterdam) as this is now getting to the critical stage? > > Is anybody else having this problem? I was surprised yesterday when a request for an AS number appears to be sat in the in queue , the oldest member of which had been there for 6 days without being assigned to a hostmaster ?? It now says 4 days :- http://www.ripe.net/cgi-bin/rttquery?ticnum=NCC%232001090025 Although maybe that is normal ?? Lance From kevin.bates at bt.com Fri Sep 14 12:58:33 2001 From: kevin.bates at bt.com (kevin.bates at bt.com) Date: Fri, 14 Sep 2001 11:58:33 +0100 Subject: NCC#2001039519 expecting reply X-NCC RegID: nl.ignite Message-ID: Thanks to all for the advice, comments, suggestions. I've got the approval kevin > -----Original Message----- > > Greetings All > > Apologies to the large number of people who will receive this email > unnecessarily. But I have a problem getting a response from the Ripe > hostmaster re an ongoing address approval. > > I tried writing to lir-help at ripe.net but also with no response, see the > mail > attached. > The ticketing system shows I am expecting a reply. > > Is there anything else I can do to speed up the process (apart from > getting > on a plane to Amsterdam) as this is now getting to the critical stage? > > Is anybody else having this problem? > > any advice gratefully received > > thanks > > kevin bates > > > > -----Original Message----- > > From: Bates,KR,Kevin,IWO24 BATESKR R > > Sent: Tuesday, August 28, 2001 3:14 PM > > To: 'lir-help at ripe.net' > > Subject: NCC#2001039519 expecting reply X-NCC RegID: nl.ignite > > > > Greetings help > > > > On 31 July a hostmaster (Leo Vegoda) wrote to me re NCC#2001039519. > > ". > > . > > Thanks for providing all that detail. I've had a look at it does seem > > fine. Can you confirm which netname you want an approval for? I'll send > > you an approval straight away, then > > . > > ." > > > > > > I provided the netname the same day > > ". > > . > > network BT-ICH-AMS-UTR > > . > > ." > > > > On 14 August not having received a response, i mailed hostmaster asking > > what was happening. Got an acknowledgement but still no approval. > > > > > > As of today the i still haven't had any further communication from the > > hostmaster. > > Can you let me know what is happening and if i still need to supply more > > information and what information is required. > > > > thanks > > kevin > > > > > > > > > > > > > > From sabrina at ripe.net Fri Sep 14 13:29:14 2001 From: sabrina at ripe.net (Sabrina Waschke) Date: Fri, 14 Sep 2001 13:29:14 +0200 Subject: NCC#2001039519 expecting reply X-NCC RegID: nl.ignite In-Reply-To: Your message of Fri, 14 Sep 2001 11:58:33 BST. References: Message-ID: <200109141129.f8EBTEG29659@birch.ripe.net> Dear Kevin, Apologies for the delay in handling your request. Unfortunately, this was due to a human mistake. Mails to both mailboxes and are being handled as normal. Kind regards, Sabrina Waschke ---- o------------------------------------------o | Sabrina Waschke sabrina at ripe.net | | Registration Services Operations Manager | | | | RIPE NCC tel +31 20 535 4444 | | www.ripe.net fax +31 20 535 4445 | o------------------------------------------o kevin.bates at bt.com writes: * Thanks to all for the advice, comments, suggestions. * * I've got the approval * * kevin * * > -----Original Message----- * > * > Greetings All * > * > Apologies to the large number of people who will receive this email * > unnecessarily. But I have a problem getting a response from the Ripe * > hostmaster re an ongoing address approval. * > * > I tried writing to lir-help at ripe.net but also with no response, see the * > mail * > attached. * > The ticketing system shows I am expecting a reply. * > * > Is there anything else I can do to speed up the process (apart from * > getting * > on a plane to Amsterdam) as this is now getting to the critical stage? * > * > Is anybody else having this problem? * > * > any advice gratefully received * > * > thanks * > * > kevin bates * > * > * > > -----Original Message----- * > > From: Bates,KR,Kevin,IWO24 BATESKR R * > > Sent: Tuesday, August 28, 2001 3:14 PM * > > To: 'lir-help at ripe.net' * > > Subject: NCC#2001039519 expecting reply X-NCC RegID: nl.ignite * > > * > > Greetings help * > > * > > On 31 July a hostmaster (Leo Vegoda) wrote to me re NCC#2001039519. * > > ". * > > . * > > Thanks for providing all that detail. I've had a look at it does seem * > > fine. Can you confirm which netname you want an approval for? I'll send * > > you an approval straight away, then * > > . * > > ." * > > * > > * > > I provided the netname the same day * > > ". * > > . * > > network BT-ICH-AMS-UTR * > > . * > > ." * > > * > > On 14 August not having received a response, i mailed hostmaster asking * > > what was happening. Got an acknowledgement but still no approval. * > > * > > * > > As of today the i still haven't had any further communication from the * > > hostmaster. * > > Can you let me know what is happening and if i still need to supply more * > > information and what information is required. * > > * > > thanks * > > kevin * > > * > > * > > * > > * > > * > > * > > * From daniel at karrenberg.net Mon Sep 17 09:10:31 2001 From: daniel at karrenberg.net (Daniel Karrenberg) Date: Mon, 17 Sep 2001 09:10:31 +0200 Subject: on the question of 'right to maintainership' In-Reply-To: <20010913190742.A14315@kpnqwest.de> Message-ID: <4.3.2.7.2.20010917085958.01cdcda0@localhost.ripe.net> [personal opinion, since I saw no replies yet and I think this deserves one] A LIR is responsible for the registration of address space assignments from address space allocations it receives from the RIPE NCC. From this alone it follows that a LIR may reserve the right to make changes to these registrations. Of course the LIR should be responsive to requests for changes. This does not mean that it has to make any change requested. Changes should be goverened by a local policy. Daniel PS: Technically speaking you can have multiple maintainers on an object that all have equal rights. So if you trust someone you can let them make their own changes while keeping the possibility to make changes yourself. The right notify options will make sure you know abut changes. Beware: Technically speaking one of these maintainers can remove the other, albeit not without the other noticing if notifications are configured right. From randy at psg.com Mon Sep 17 15:44:23 2001 From: randy at psg.com (Randy Bush) Date: Mon, 17 Sep 2001 06:44:23 -0700 Subject: OPS-NM interim meeting before RIPE-40 Message-ID: [ bert has asked me to repost ] Howdy, At the last two IETF OPS Area Open meetings, we had some good discussion between the OPS NM folk and some operators. We also have had a so called OPS-NM Interim in the USA that was co-located with NANOG in May of this year. We also called it something like: Net Management Protocol Folk & Net Operators - Reality Check #2 We will have another IETF Interim Meeting for the OPS-AREA Network Management people, this time in Europe, co-located with the next RIPE-NCC meeting. The idea is to meet with another set of operators to try and understand their needs and to explain to them how we think that our NM related work in the IETF can help them to manage their networks. In other words: Net Management Protocol Folk & Net Operators - Reality Check #3 We probably will have similar sessions in the future to meet with people who operate enterprise networks, because their requirements may be different. We are still working on the agenda, however below you will find a prelimenary agenda proposal. Any suggestions should be sent to Randy (randy at psg.com) and Bert (bwijnen at lucent.com) We have limited space for this meeting. Those who plan to attend, pls send a short email to Bert Wijnen to let us know. Pls add a few lines as to why you want to participate. Discussion has been occurring since May on the mailing list ops-nm at ops.ietf.org, which is normal internet-style. And a web-based archive is at . Bert and Randy -------------- OPS-NM Interim Meeting details ------------------ The plan is to have this meeting co-located with the next RIPE NCC meeting, namely RIPE 40. That means: Oct 1st OPS-NM Interim from 2-5pm Oct 2nd OPS-NM Interim from 9am-noon Oct 2-5 RIPE 40. Starts at 2pm on oct 2nd. RIPE 40 and OPS-NM Interim will be in the Prague Congress Centre in Prague, Czech Republic. For RIPE 40 and hotel registration, pls visit: http://www.ripe.net/ripe/meetings/current/ripe-40/ There is a whole range of hotels to choose from, but it is very hard to book, so do it now. Those only participating in the OPS-NM meeting are not required to pay the RIPE meeting fee. Of course, if you want to take the opportunity to participate in the RIPE-NCC meeting, then you should register for that meeting via the web page listed above. Those who plan to attend the OPS-NM Interim should send an email to Bert Wijnen because we only have limited room, and if too many people want to show up we may have to tell some that there is no more space. Prelimenary Agenda ------------------ - Agenda bashing and intro - Summary of the current set of OPS requirements draft-ops-operator-req-mgmt-00.txt Please read this document to prepare for the meeting. If this one no longer exists, then pls check for a possible revision 01.txt. It is important to try and figure out if this also represents needs of European operators, or do they have different/new/additional requirements? - Discussion of the above. - Discussion of SNMP, MIBs, COPS, POLICY and such - how do the developers of these protocols/specs think that they can address operator NM requirments. - what do operators think about that - what kind of positive or negative expoerience do operators have - Operator requirements - what are the real hot issues to be solved this year - what are the constraints within which the tools have to work - Next steps - Wrapup/Summary -30- From bciscato at cisco.com Wed Sep 19 13:48:22 2001 From: bciscato at cisco.com (Bruno Ciscato) Date: Wed, 19 Sep 2001 13:48:22 +0200 Subject: Summary: Fixed Boundary (/29) Assignments In-Reply-To: <200102161004.LAA18004@x30.ripe.net> Message-ID: <4.3.2.7.2.20010919115652.01754ff8@mail.flashnet.it> 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 From nurani at ripe.net Fri Sep 21 11:21:34 2001 From: nurani at ripe.net (Nurani Nimpuno) Date: Fri, 21 Sep 2001 11:21:34 +0200 Subject: IPv4 and ASN Policy draft on-line Message-ID: <200109210921.f8L9LYG04538@birch.ripe.net> 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 or indicate your interest on this list. Kind regards, Nurani Nimpuno RIPE NCC From kevin.bates at bt.com Fri Sep 21 16:43:02 2001 From: kevin.bates at bt.com (kevin.bates at bt.com) Date: Fri, 21 Sep 2001 15:43:02 +0100 Subject: IPv4 and ASN Policy draft on-line Enterprise & full IR policy doc Message-ID: All, I would like to ask for advice and comment, and suggest it Is probably time for a discussion about the differences in operations of the two types LIR's, i.e. with the status of "enterprise" and "full". The current RIPE NCC documentation offers conflicting or no advice - I cannot find any specific enterprise registry instructions / guidance, except for the line "....large international Enterprises can also operate Local IRs". I would expect to see something in either Ripe 212 (Guidelines for Setting up a Local Internet Registry) or Ripe 185 (European Internet Registry Policies and Procedures). Given that IPv4 and ASN policy document is now under review I think that this is a good time to raise this issue again, and hopefully get something agreed in writing. Therefore I am specifically looking for "Enterprise Registry Assignment Policy instructions". I'll try briefly to give the background and a flavour of the issues. As a large company we operate several LIR's: 1. A public Internet Service with a large allocation (many /16) 2. Several small LIR's - product / site / country / subsidiary specific. 3. A large enterprise Registry (several Ripe /16 with both PI and PA ranges and historic UK address space originally assigned by ARIN) These registries are not all necessarily managed by the same teams nor do they all necessarily have specific interfaces with each other. The internet connectivity for them all is not via the same ISP, but the enterprise registry (3) does route via the Public Internet Service ISP (1). For an enterprise registry, assignment window size is irrelevant because all address space used will be assigned within the company "owning" the registry. Therefore a RIPE 141/219 is required for every assignment (this is policy for normal registries using addresses for their own infrastructure). Consider the scenario where an enterprise registry is allocated a block of addresses that it will only ever assign to its own company, and that the enterprise registry advertises & routes the whole block and assigns subnets from it to departments within the company where required. For all practical purposes all of these addresses are used by and assigned to the same place. In our case, problems involving the daily recovery/reassignment of subnets was overcome by agreeing a large corporate assignment window with the hostmaster and by keeping the number of addresses assigned to departments / groups / projects within that number -and then asking for an assignment increase where necessary. But what can an enterprise registry's addresses be used for? * its own company infrastructure * server farms and web hosting ( thus being used indirectly by customers of the registry's company), and * various other uses - but not onward assignment to "paying" customers. Following several previous discussions between myself, my colleagues and with various RIPE NCC hostmasters it has been agreed that RIPE NCC will now allow us to transfer "experimental" addresses (obtained from our enterprise Registry), which are used by a department within the company, into "commercial" status - when the service offering changes from experimental to commercial. This means that systems using these addresses do not have to renumber to the range assigned by the public ISP. Therefore I would like to see this policy formalised within RIPE NCC documentation. And my next question is: If this department splits from the original company and becomes a separate entity, what happens to the addresses space it uses? There are several possibilities: 1. Migrate from the enterprise registry to the public ISP or another ISP (over a reasonable time period - but this could involve considerable pain/cost), or 2. Continue to use the enterprise registry address space, and then the "enterprise" registry converts to a "full" registry, but what are the implications? or 3. Split the enterprise registry into 2 (not contiguous ranges) and create another LIR. regards kevin From hank at att.net.il Mon Sep 24 08:11:23 2001 From: hank at att.net.il (Hank Nussbacher) Date: Mon, 24 Sep 2001 08:11:23 +0200 Subject: IPv4 and ASN Policy draft on-line In-Reply-To: <200109210921.f8L9LYG04538@birch.ripe.net> Message-ID: <4.3.2.7.2.20010924080417.00aa0500@max.att.net.il> At 11:21 21/09/01 +0200, Nurani Nimpuno wrote: I would like to discuss section 5.5 AS numbers. 1) No mention is made if an organization ceases to be multihomed. I think any organization that ceases to be multihomed has to return the ASN after a certain period of time - say 2 months. 2) I think it needs to be specifically stated that the two upstream ISPs must announce the ASN via BGP and must make that announcement to either the global Internet or to a well recognized exchange point. 3) The organization receiving the ASN is responsible for maintaining an up to date aut-num object in RIPE as well as creating route objects for all assigning prefixes with the stated ASN origin. -Hank >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 or >indicate your interest on this list. > >Kind regards, > >Nurani Nimpuno >RIPE NCC From randy at psg.com Mon Sep 24 16:40:14 2001 From: randy at psg.com (Randy Bush) Date: Mon, 24 Sep 2001 07:40:14 -0700 Subject: IPv4 and ASN Policy draft on-line References: <200109210921.f8L9LYG04538@birch.ripe.net> <4.3.2.7.2.20010924080417.00aa0500@max.att.net.il> Message-ID: > 2) I think it needs to be specifically stated that the two upstream ISPs > must announce the ASN via BGP and must make that announcement to either > the global Internet or to a well recognized exchange point. does mean that one can not be multi-homed to two tier >=twos, neither of which is at an ix? well, reading differently, i guess i don't know what the global internet is when it needs to be differentiated from being at an ix. what are you getting at? i am misunderstanding the criteria. randy From randy at psg.com Mon Sep 24 18:28:08 2001 From: randy at psg.com (Randy Bush) Date: Mon, 24 Sep 2001 09:28:08 -0700 Subject: IPv4 and ASN Policy draft on-line References: Message-ID: > I'll try to explain what I am getting at. Very often a newbie ISP doesn't > quite understand what this is all about. They get an ASN cuz everyone > else has one. Their upstream does static routing to them so rather than > having their /19 show up as AS34567, it shows up as origin=AS11111 (their > upstream). > > 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. understood the motivation. did not understand the mechanism. in arin-land, i think they actually ask to see proof of dual-homing before issuing the asn. but you want to TEST that it is actually deployed. what is not clear to me is HOW to do that. please take into account the problem of bgp best-path-only propagation. randy From sabrina at ripe.net Mon Sep 24 18:38:29 2001 From: sabrina at ripe.net (Sabrina Waschke) Date: Mon, 24 Sep 2001 18:38:29 +0200 Subject: Summary: Fixed Boundary (/29) Assignments Message-ID: <200109241638.f8OGcTG09340@birch.ripe.net> Bruno Ciscato 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 including the ticket number of your ongoing request, or contact . Kind regards, Sabrina Waschke -- o------------------------------------------o | Sabrina Waschke sabrina at ripe.net | | Registration Services Operations Manager | | | | RIPE NCC tel +31 20 535 4444 | | www.ripe.net fax +31 20 535 4445 | o------------------------------------------o From randy at psg.com Mon Sep 24 18:51:34 2001 From: randy at psg.com (Randy Bush) Date: Mon, 24 Sep 2001 09:51:34 -0700 Subject: IPv4 and ASN Policy draft on-line References: Message-ID: >> in arin-land, i think they actually ask to see proof of dual-homing before >> issuing the asn.but you want to TEST that it is actually deployed.what >> is not clear to me is HOW to do that.please take into account the problem >> of bgp best-path-only propagation. > I do the same in RIPEland as well. BGP best-path-only does put a crimp in > the works which is why one needs to check a few public route servers. I > cycle thru all multihomers (that I have allocated) every few months and > check 3-4 large route servers or LGs and see who doesn't show up at all > (went bellyup) or has only 1 path (dropped the 2nd due to economic > downturn). expecting an ec-style bureaucracy () to do something like that seems unreasonable. what if one link is down for a day or a week (should a metric week have ten days?:-)? i suspect this is among the reasons the rirs use more administrative tests. all in all, it's a pain. randy From yuval at spiderservices.com Mon Sep 24 14:16:00 2001 From: yuval at spiderservices.com (Yuval Shchory) Date: Mon, 24 Sep 2001 14:16:00 +0200 Subject: Maintaining IPs in LIRs/Enterprise LIRs Message-ID: Hi all, 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. I was wondering what tools people in other LIRs in Europe use. I'll be more than happy for any advice (and links? :-). Thanks, --- Yuval Shchory VP Communications and Service Providers Spider Solutions Ltd. 6 HaChilazon St. Ramat-Gan 52522 Tel: +972-3-576-6980 From huberman at gblx.net Mon Sep 24 23:11:02 2001 From: huberman at gblx.net (David R Huberman) Date: Mon, 24 Sep 2001 14:11:02 -0700 (MST) Subject: Maintaining IPs in LIRs/Enterprise LIRs In-Reply-To: Message-ID: > 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 at gblx.net | *--------------------------------* From wilson.mehringer at cablecom.ch Tue Sep 25 09:10:04 2001 From: wilson.mehringer at cablecom.ch (Wilson Mehringer) Date: Tue, 25 Sep 2001 09:10:04 +0200 Subject: Antw: Re: Maintaining IPs in LIRs/Enterprise LIRs Message-ID: 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 at cablecom.ch >>> David R Huberman 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 at gblx.net | *--------------------------------* -------------- next part -------------- An HTML attachment was scrubbed... URL: From ripe-ml at cyberstrider.net Tue Sep 25 09:49:47 2001 From: ripe-ml at cyberstrider.net (Denesh Bhabuta) Date: Tue, 25 Sep 2001 08:49:47 +0100 Subject: Maintaining IPs in LIRs/Enterprise LIRs In-Reply-To: <20010924221732.F16728@cyberstrider.net>; from denesh@cyberstrider.net on Mon, Sep 24, 2001 at 10:17:32PM +0100 References: <20010924221732.F16728@cyberstrider.net> Message-ID: <20010925084947.A27830@cyberstrider.net> > 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. > I was wondering what tools people in other LIRs in Europe use. I'll be > more than happy for any advice (and links :-). You may want to give RoboBijal a go... it was discussed on the Tools working group. Get it from www.robobijal.org Regards Denesh -- Denesh Bhabuta Cyberstrider Limited - www.cyberstrider.net Aexiomus Limited - www.aexiomus.net From djp-ripe-lists at djp.net Tue Sep 25 11:04:28 2001 From: djp-ripe-lists at djp.net (Dave Pratt) Date: Tue, 25 Sep 2001 11:04:28 +0200 (CEST) Subject: Where is the proposed revised IPv6 policy ? Message-ID: 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 From mir at ripe.net Tue Sep 25 11:11:17 2001 From: mir at ripe.net (Mirjam Kuehne) Date: Tue, 25 Sep 2001 09:11:17 +0000 Subject: new IPv6 policy framework Message-ID: <200109250911.f8P9BHG25724@birch.ripe.net> Dear LIRs, Following the discussions at the RIPE 39 meeting and on the mailing lists in all the RIR communities, please find below the latest developments concerning IPv6 address allocation policies. This proposal is based on requirements expressed by the RIPE community as well as those of the other RIR communities. Please note that the text below is not a replacement of the current policy document, but rather a summary of the new IPv6 address allocation framework. Therefore this proposal is intended as input for further discussion in the RIPE community. When formulating this framework, we were specifically taking the following feedback into account: - 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. This results in the following changes to previously discussed IPv6 allocation criteria: 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 Kind Regards, Mirjam Kuehne RIPE NCC ---------------- 1. Abstract This document provides a set of proposed policies for the management of IPv6 address space, specifically concerning the allocation of address space allocated by Regional Internet Registries (RIRs) to organisations operating IPv6 networks. 2. Overview Under the current system of management of global IP address space, Regional Internet Registries (RIRs) are responsible for allocation of address space to organisations within their respective geographic regions. In 1999, the RIRs APNIC, ARIN and RIPE NCC published a provisional policy document for IPv6, which has been in operation since then. Since 2000, this document has been under review and discussion, and through this process many issues have been raised. It is the aim of this document to propose a new policy framework for IPv6 address space management which takes into account the operational experience of the past 3 years, and addresses most if not all of the major issues raised through the open review process. This document does not attempt to provide details of policy implementation, procedures or documentation; nor does it document requirements for management of address space which is allocated. These policies can be established globally or regionally as appropriate, based on global consensus regarding the fundamental principles described here. 3. Address Space Requirement for Initial Allocation It is proposed to recognise existing network infrastructure and address utilisation (both IPv4 and IPv6). New IPv6 address needs are then based on these existing networks. In assessing a request for an initial allocation, there are 3 possible cases to consider: 3.1. the requesting organisation has an existing IPv4 network which will be addressed by the new IPv6 allocation 3.2. the requesting organisation has an existing IPv6 network 3.3. the requesting organisation has no network at all 3.1. Case 1 - Existing IPv4 services Where IPv6 address space is requested for addressing an existing IPv4 network, the address requirement is determined according to the structure and customer base of the existing IPv4 network. This only relates to the part of the network that will be migrated to IPv6. 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. 3.2. Case 2 - Existing IPv6 services Where an IPv6 allocation is requested by an organisation to address infrastructure which is already addressed by IPv6 addresses from an upstream provider (or from the 6BONE), the address requirement is determined from the number of site addresses assigned by the organisation (as registered in the appropriate whois database). Where existing address space is no longer used, it must be returned. 3.3. Case 3 - No existing IPv4 or IPv6 services Where IPv6 address space is required by an organisation which has no existing infrastructure, the address requirement will be assessed according to network architecture plans and other documentation provided to the RIR within the request process. Such documentation be thorough enough to satisfy the RIR that the network deployment is genuine, however the specific details of documentation requirements will be defined separately. 4. Size of Initial Allocation The amount of addresses allocated to an existing network, will be determined based on the existing infrastructure and address utilisation of that network. 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. 5. Qualification for Subsequent Allocation An organisation which has already received address space from an RIR may receive a subsequent allocation providing that its existing address space is utilised in accordance with these policies. As explained below, the HD-Ratio will be used to measure utilisation of the existing address space. An organisation which is deploying substantial new network infrastructure may receive a subsequent allocation before it has reached the required utilisation threshold, providing that the address requirement would immediate cause the organisation to exceed the utilisation threshold. In such cases, the new network infrastructure will be examined by the RIR as if it is a request for a new network, and the RIR may require the same level of documentation detail, in order to approve the allocation. 6. Address Space Requirement for Subsequent Allocation For subsequent allocations, the RIR should assess the address requirement according to the organisation's history of IP address usage, as well as its stated requirements for future development. In general, the RIR should provide address space for a fixed time period of 2 years. The above recommendation should be followed in cases where the organisation concerned has complied with all relevant address management policies. In other cases, the RIR may allocate for a shorter future timeframe, and require that identified problems be rectified before larger allocations are made. 7. IPv6 Utilisation Metric: the HD-Ratio In IPv4, currently, a "utilisation threshold" of 80% is applied consistently in determining whether an IPv4 address pool is to be considered utilised, regardless of the size of that block. Consequently, an organisation which holds IP address space may not receive additional addresses until it has utilised at least 80% of the address space held. For IPv6 is it proposed to assess utilisation according to the "HD-Ratio" rather than by a simple percentage. The HD-Ratio was proposed by Durand in "draft-durand-huitema-h-density-ratio-01.txt" (an adaptation of the original H-Ratio defined by Huitema in RFC-1715). Using the HD-ratio we can establish a utilisation metric which allows percentage utilisation to decrease as the address space grows large. This is appropriate for management of the much larger blocks of address space under IPv6, and the likelihood of complex routing and allocation hierarchies within those address blocks. More details about the HD ratio can be found in Appendix A. Appendix A: In the general case, where individual objects are allocated out of an arbitrary address space, the HD-Ratio is calculated as follows: log(number of allocated objects) HD = -------------------------------------------- log(maximum number of allocatable objects) Where the objects being allocated are IPv6 site addresses (/48s) assigned from an IPv6 prefix of length P, we can restate this formula as follows (where A is the number of /48 prefixes actually assigned): log(A) log(A) In other words, the utilisation threshold T, expressed as a number of individual /48 prefixes to be allocated from IPv6 prefix P, can be calculated as: ((48-P)*HD) T = 2 In accordance with the recommendations of draft-durand-huitema-h-density-ratio-01.txt, it is proposed in this draft to adopt an HD-Ratio of 0.8 as the utilisation threshold for IPv6 address space allocations. The following table provides equivalent absolute and percentage address utilisation figures for IPv6 prefixes, corresponding to an HD-Ratio of 0.8 P 48-P Total /48s Threshold Util% 48 0 1 1 100.0% 47 1 2 2 87.1% 46 2 4 3 75.8% 45 3 8 5 66.0% 44 4 16 9 57.4% 43 5 32 16 50.0% 42 6 64 28 43.5% 41 7 128 49 37.9% 40 8 256 84 33.0% 39 9 512 147 28.7% 38 10 1024 256 25.0% 37 11 2048 446 21.8% 36 12 4096 776 18.9% 35 13 8192 1351 16.5% 34 14 16384 2353 14.4% 33 15 32768 4096 12.5% 32 16 65536 7132 10.9% 31 17 131072 12417 9.5% 30 18 262144 21619 8.2% 29 19 524288 37641 7.2% 28 20 1048576 65536 6.3% 27 21 2097152 114105 5.4% 26 22 4194304 198668 4.7% 25 23 8388608 345901 4.1% 24 24 16777216 602249 3.6% 23 25 33554432 1048576 3.1% 22 26 67108864 1825677 2.7% 21 27 134217728 3178688 2.4% 20 28 268435456 5534417 2.1% 19 29 536870912 9635980 1.8% 18 30 1073741824 16777216 1.6% 17 31 2147483648 29210830 1.4% 16 32 4294967296 50859008 1.2% 15 33 8589934592 88550677 1.0% 14 34 17179869184 154175683 0.9% 13 35 34359738368 268435456 0.8% 12 36 68719476736 467373275 0.7% 11 37 137438953472 813744135 0.6% 10 38 274877906944 1416810831 0.5% 9 39 549755813888 2466810934 0.4% 8 40 1099511627776 4294967296 0.4% 7 41 2199023255552 7477972398 0.3% 6 42 4398046511104 13019906166 0.3% 5 43 8796093022208 22668973294 0.3% 4 44 17592186044416 39468974941 0.2% 3 45 35184372088832 68719476736 0.2% 2 46 70368744177664 119647558364 0.2% 1 47 140737488355328 208318498661 0.1% 0 48 281474976710656 362703572709 0.1% From hank at att.net.il Mon Sep 24 19:21:11 2001 From: hank at att.net.il (Hank Nussbacher) Date: Mon, 24 Sep 2001 18:21:11 +0100 (IST) Subject: IPv4 and ASN Policy draft on-line In-Reply-To: Message-ID: On Mon, 24 Sep 2001, Randy Bush wrote: > > 2) I think it needs to be specifically stated that the two upstream ISPs > > must announce the ASN via BGP and must make that announcement to either > > the global Internet or to a well recognized exchange point. > > does mean that one can not be multi-homed to two tier >=twos, neither of > which is at an ix? > > well, reading differently, i guess i don't know what the global internet is > when it needs to be differentiated from being at an ix. > > what are you getting at?i am misunderstanding the criteria. I'll try to explain what I am getting at. Very often a newbie ISP doesn't quite understand what this is all about. They get an ASN cuz everyone else has one. Their upstream does static routing to them so rather than having their /19 show up as AS34567, it shows up as origin=AS11111 (their upstream). 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 From hank at att.net.il Mon Sep 24 19:39:51 2001 From: hank at att.net.il (Hank Nussbacher) Date: Mon, 24 Sep 2001 18:39:51 +0100 (IST) Subject: IPv4 and ASN Policy draft on-line In-Reply-To: Message-ID: On Mon, 24 Sep 2001, Randy Bush wrote: > > I'll try to explain what I am getting at.Very often a newbie ISP doesn't > > quite understand what this is all about.They get an ASN cuz everyone > > else has one.Their upstream does static routing to them so rather than > > having their /19 show upas AS34567, it shows up as origin=AS11111 (their > > upstream). > > > > 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. > > understood the motivation.did not understand the mechanism. > > in arin-land, i think they actually ask to see proof of dual-homing before > issuing the asn.but you want to TEST that it is actually deployed.what > is not clear to me is HOW to do that.please take into account the problem > of bgp best-path-only propagation. I do the same in RIPEland as well. BGP best-path-only does put a crimp in the works which is why one needs to check a few public route servers. I cycle thru all multihomers (that I have allocated) every few months and check 3-4 large route servers or LGs and see who doesn't show up at all (went bellyup) or has only 1 path (dropped the 2nd due to economic downturn). > > randy > Hank Nussbacher From denesh at cyberstrider.net Mon Sep 24 23:17:32 2001 From: denesh at cyberstrider.net (Denesh Bhabuta) Date: Mon, 24 Sep 2001 22:17:32 +0100 Subject: Maintaining IPs in LIRs/Enterprise LIRs In-Reply-To: ; from yuval@spiderservices.com on Mon, Sep 24, 2001 at 02:16:00PM +0200 References: Message-ID: <20010924221732.F16728@cyberstrider.net> On Mon, Sep 24, 2001 at 02:16:00PM +0200, in message , Yuval Shchory (yuval at spiderservices.com) is reputed to have pronounced: Re: Maintaining IPs in LIRs/Enterprise LIRs > 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. > I was wondering what tools people in other LIRs in Europe use. I'll be > more than happy for any advice (and links :-). You may want to give RoboBijal a go... it was discussed on the Tools working group. Get it from www.robobijal.org Regards Denesh -- Denesh Bhabuta Cyberstrider Limited - www.cyberstrider.net Aexiomus Limited - www.aexiomus.net From vovik at lucky.net Tue Sep 25 00:20:18 2001 From: vovik at lucky.net (Vladimir A. Jakovenko) Date: Tue, 25 Sep 2001 01:20:18 +0300 Subject: Maintaining IPs in LIRs/Enterprise LIRs In-Reply-To: ; from huberman@gblx.net on Mon, Sep 24, 2001 at 02:11:02PM -0700 References: Message-ID: <20010925012018.Q53425@lucky.net> On Mon, Sep 24, 2001 at 02:11:02PM -0700, David R Huberman wrote: > >> 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. Were I can vote? :-) AFAIK there were some discussions about such public tool but it never raised to something real. -- Regards, Vladimir. From hank at att.net.il Tue Sep 25 07:39:26 2001 From: hank at att.net.il (Hank Nussbacher) Date: Tue, 25 Sep 2001 07:39:26 +0200 Subject: IPv4 and ASN Policy draft on-line In-Reply-To: References: Message-ID: <4.3.2.7.2.20010925073241.00aef840@max.att.net.il> At 09:51 24/09/01 -0700, Randy Bush wrote: > >> in arin-land, i think they actually ask to see proof of dual-homing before > >> issuing the asn.but you want to TEST that it is actually deployed.what > >> is not clear to me is HOW to do that.please take into account the problem > >> of bgp best-path-only propagation. > > I do the same in RIPEland as well. BGP best-path-only does put a crimp in > > the works which is why one needs to check a few public route servers. I > > cycle thru all multihomers (that I have allocated) every few months and > > check 3-4 large route servers or LGs and see who doesn't show up at all > > (went bellyup) or has only 1 path (dropped the 2nd due to economic > > downturn). > >expecting an ec-style bureaucracy () to do something like that seems >unreasonable. what if one link is down for a day or a week (should a metric >week have ten days?:-)? i suspect this is among the reasons the rirs use >more administrative tests. all in all, it's a pain. One can't be too strict. I give them 2 months to fix. Then they get another email. Still not fixed - then they a registered postal letter. Of the 70 ASNs I have allocated since 1996, I have revoked 10 (and returned to the RIPE pool), 5 of which were this year. Its a pain, but unless ear LIR does it, then we will end up with the same problem we have with IPv4 address space. -Hank >randy From neil at ednet.co.uk Tue Sep 25 10:28:08 2001 From: neil at ednet.co.uk (Neil Anderson Saunders) Date: Tue, 25 Sep 2001 09:28:08 +0100 (BST) Subject: Maintaining IPs in LIRs/Enterprise LIRs In-Reply-To: Message-ID: Hi, We would be very interested to see an IP management tool like this. I think there is a large interest in the community for this. Kind regards, Neil -- Hostmaster edNET t: +44 131 625 5560 (direct) t: +44 131 466 7003 (office) On Mon, 24 Sep 2001, David R Huberman wrote: > > > 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 at gblx.net | > *--------------------------------* From stephenb at uk.uu.net Tue Sep 25 12:27:39 2001 From: stephenb at uk.uu.net (Stephen Burley) Date: Tue, 25 Sep 2001 11:27:39 +0100 Subject: new IPv6 policy framework References: <200109250911.f8P9BHG25724@birch.ripe.net> Message-ID: <00f101c145ac$b3ec16d0$2e04bf3e@eu.frd.uu.net> Though this is a good document it does not cater for the needs of Multinational Registries, i specifily asked for the MIR proposal to be included in this discussion. This document caters for the single LIR not mutiple LIR's in one very large pan EMEA network, which is still growing. I would like to see this included in the draft, or reasons why the community (not the NCC) are opposed to the MIR proposal for IPV6 (and ipv4 also). To date there has been no negative comments on the porposal which is why i am puzzled it is not included. Regards, Stephen Burley UUNET EMEA Hostmaster SB855-RIPE > > Dear LIRs, > > Following the discussions at the RIPE 39 meeting and on the mailing > lists in all the RIR communities, please find below the latest > developments concerning IPv6 address allocation policies. This > proposal is based on requirements expressed by the RIPE community as > well as those of the other RIR communities. > > Please note that the text below is not a replacement of the current > policy document, but rather a summary of the new IPv6 address > allocation framework. Therefore this proposal is intended as input for > further discussion in the RIPE community. > > When formulating this framework, we were specifically taking the > following feedback into account: > > - 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. > > This results in the following changes to previously discussed > IPv6 allocation criteria: > > 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 > > > Kind Regards, > Mirjam Kuehne > RIPE NCC > ---------------- > > > 1. Abstract > > This document provides a set of proposed policies for the management > of IPv6 address space, specifically concerning the allocation of > address space allocated by Regional Internet Registries (RIRs) to > organisations operating IPv6 networks. > > > 2. Overview > > Under the current system of management of global IP address space, Regional > Internet Registries (RIRs) are responsible for allocation of > address space to organisations within their respective geographic > regions. > > In 1999, the RIRs APNIC, ARIN and RIPE NCC published a provisional policy > document for IPv6, which has been in operation since then. Since 2000, > this document has been under review and discussion, and through this > process many issues have been raised. > > It is the aim of this document to propose a new policy framework for > IPv6 address space management which takes into account the operational > experience of the past 3 years, and addresses most if not all of the > major issues raised through the open review process. > > This document does not attempt to provide details of policy implementation, > procedures or documentation; nor does it document requirements for > management of address space which is allocated. These policies can be > established globally or regionally as appropriate, based on global > consensus regarding the fundamental principles described here. > > > 3. Address Space Requirement for Initial Allocation > > It is proposed to recognise existing network infrastructure and > address utilisation (both IPv4 and IPv6). New IPv6 address needs are > then based on these existing networks. > > In assessing a request for an initial allocation, there are 3 possible > cases to consider: > > 3.1. the requesting organisation has an existing IPv4 network which > will be addressed by the new IPv6 allocation > > 3.2. the requesting organisation has an existing IPv6 network > > 3.3. the requesting organisation has no network at all > > > 3.1. Case 1 - Existing IPv4 services > > Where IPv6 address space is requested for addressing an existing IPv4 > network, the address requirement is determined according to the > structure and customer base of the existing IPv4 network. This only > relates to the part of the network that will be migrated to IPv6. > > 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. > > 3.2. Case 2 - Existing IPv6 services > > Where an IPv6 allocation is requested by an organisation to address > infrastructure which is already addressed by IPv6 addresses from an > upstream provider (or from the 6BONE), the address requirement is > determined from the number of site addresses assigned by the > organisation (as registered in the appropriate whois database). > > Where existing address space is no longer used, it must be returned. > > 3.3. Case 3 - No existing IPv4 or IPv6 services > > Where IPv6 address space is required by an organisation which has no > existing infrastructure, the address requirement will be assessed > according to network architecture plans and other documentation > provided to the RIR within the request process. Such documentation be > thorough enough to satisfy the RIR that the network deployment is > genuine, however the specific details of documentation requirements > will be defined separately. > > > 4. Size of Initial Allocation > > The amount of addresses allocated to an existing network, will be > determined based on the existing infrastructure and address > utilisation of that network. > > 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. > > > 5. Qualification for Subsequent Allocation > > An organisation which has already received address space from an RIR may > receive a subsequent allocation providing that its existing address space > is utilised in accordance with these policies. As explained below, the > HD-Ratio will be used to measure utilisation of the existing address space. > > An organisation which is deploying substantial new network infrastructure > may receive a subsequent allocation before it has reached the required > utilisation threshold, providing that the address requirement would > immediate cause the organisation to exceed the utilisation threshold. In > such cases, the new network infrastructure will be examined by the RIR as > if it is a request for a new network, and the RIR may require the same > level of documentation detail, in order to approve the allocation. > > > 6. Address Space Requirement for Subsequent Allocation > > For subsequent allocations, the RIR should assess the address requirement > according to the organisation's history of IP address usage, as well as its > stated requirements for future development. > > In general, the RIR should provide address space for a fixed time > period of 2 years. > > The above recommendation should be followed in cases where the organisation > concerned has complied with all relevant address management policies. In > other cases, the RIR may allocate for a shorter future timeframe, and > require that identified problems be rectified before larger allocations are > made. > > > 7. IPv6 Utilisation Metric: the HD-Ratio > > > In IPv4, currently, a "utilisation threshold" of 80% is applied > consistently in determining whether an IPv4 address pool is to be > considered utilised, regardless of the size of that block. > Consequently, an organisation which holds IP address space may > not receive additional addresses until it has utilised at least 80% of > the address space held. > > For IPv6 is it proposed to assess utilisation according to the "HD-Ratio" > rather than by a simple percentage. The HD-Ratio was proposed by Durand in > "draft-durand-huitema-h-density-ratio-01.txt" (an adaptation of the > original H-Ratio defined by Huitema in RFC-1715). > > Using the HD-ratio we can establish a utilisation metric which allows > percentage utilisation to decrease as the address space grows large. This > is appropriate for management of the much larger blocks of address space > under IPv6, and the likelihood of complex routing and allocation > hierarchies within those address blocks. > > More details about the HD ratio can be found in Appendix A. > > > Appendix A: > > In the general case, where individual objects are allocated out of an > arbitrary address space, the HD-Ratio is calculated as follows: > > log(number of allocated objects) > HD = -------------------------------------------- > log(maximum number of allocatable objects) > > > Where the objects being allocated are IPv6 site addresses (/48s) assigned > from an IPv6 prefix of length P, we can restate this formula as follows > (where A is the number of /48 prefixes actually assigned): > > log(A) log(A) > > In other words, the utilisation threshold T, expressed as a number of > individual /48 prefixes to be allocated from IPv6 prefix P, can be > calculated as: > > > ((48-P)*HD) > T = 2 > > > In accordance with the recommendations of > draft-durand-huitema-h-density-ratio-01.txt, it is proposed in this draft > to adopt an HD-Ratio of 0.8 as the utilisation threshold for IPv6 address > space allocations. > > The following table provides equivalent absolute and percentage > address utilisation figures for IPv6 prefixes, corresponding to an > HD-Ratio of 0.8 > > > > > P 48-P Total /48s Threshold Util% > > 48 0 1 1 100.0% > 47 1 2 2 87.1% > 46 2 4 3 75.8% > 45 3 8 5 66.0% > 44 4 16 9 57.4% > 43 5 32 16 50.0% > 42 6 64 28 43.5% > 41 7 128 49 37.9% > 40 8 256 84 33.0% > 39 9 512 147 28.7% > 38 10 1024 256 25.0% > 37 11 2048 446 21.8% > 36 12 4096 776 18.9% > 35 13 8192 1351 16.5% > 34 14 16384 2353 14.4% > 33 15 32768 4096 12.5% > 32 16 65536 7132 10.9% > 31 17 131072 12417 9.5% > 30 18 262144 21619 8.2% > 29 19 524288 37641 7.2% > 28 20 1048576 65536 6.3% > 27 21 2097152 114105 5.4% > 26 22 4194304 198668 4.7% > 25 23 8388608 345901 4.1% > 24 24 16777216 602249 3.6% > 23 25 33554432 1048576 3.1% > 22 26 67108864 1825677 2.7% > 21 27 134217728 3178688 2.4% > 20 28 268435456 5534417 2.1% > 19 29 536870912 9635980 1.8% > 18 30 1073741824 16777216 1.6% > 17 31 2147483648 29210830 1.4% > 16 32 4294967296 50859008 1.2% > 15 33 8589934592 88550677 1.0% > 14 34 17179869184 154175683 0.9% > 13 35 34359738368 268435456 0.8% > 12 36 68719476736 467373275 0.7% > 11 37 137438953472 813744135 0.6% > 10 38 274877906944 1416810831 0.5% > 9 39 549755813888 2466810934 0.4% > 8 40 1099511627776 4294967296 0.4% > 7 41 2199023255552 7477972398 0.3% > 6 42 4398046511104 13019906166 0.3% > 5 43 8796093022208 22668973294 0.3% > 4 44 17592186044416 39468974941 0.2% > 3 45 35184372088832 68719476736 0.2% > 2 46 70368744177664 119647558364 0.2% > 1 47 140737488355328 208318498661 0.1% > 0 48 281474976710656 362703572709 0.1% > > > > > From woeber at cc.univie.ac.at Tue Sep 25 12:58:44 2001 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Tue, 25 Sep 2001 12:58:44 +0200 Subject: IPv4 and ASN Policy draft on-line Message-ID: <00A0294A.456242F2.3@cc.univie.ac.at> >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 at 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From gert at space.net Tue Sep 25 13:13:17 2001 From: gert at space.net (Gert Doering) Date: Tue, 25 Sep 2001 13:13:17 +0200 Subject: IPv4 and ASN Policy draft on-line In-Reply-To: <00A0294A.456242F2.3@cc.univie.ac.at>; from woeber@cc.univie.ac.at on Tue, Sep 25, 2001 at 12:58:44PM +0200 References: <00A0294A.456242F2.3@cc.univie.ac.at> Message-ID: <20010925131317.P31448@Space.Net> Hi, On Tue, Sep 25, 2001 at 12:58:44PM +0200, Wilfried Woeber, UniVie/ACOnet wrote: > 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). 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. > 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... Or to phrase it differently: will it be more expensive than to upgrade all routers world-wide to be able to handle 32bit AS#s? While there *is* the option to never reclaim AS#s and just go to 32bits, I, for one, do not really want to handle 32-bit-long AS#s in daily operation, and do not really want to see all the new and exciting bugs that they would bring with them... Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From randy at psg.com Tue Sep 25 14:38:04 2001 From: randy at psg.com (Randy Bush) Date: Tue, 25 Sep 2001 05:38:04 -0700 Subject: IPv4 and ASN Policy draft on-line References: <4.3.2.7.2.20010925073241.00aef840@max.att.net.il> Message-ID: >> expecting an ec-style bureaucracy () to do something like that seems >> unreasonable. what if one link is down for a day or a week (should a >> metric week have ten days?:-)? i suspect this is among the reasons the >> rirs use more administrative tests. all in all, it's a pain. > One can't be too strict. I give them 2 months to fix. Then they get > another email. Still not fixed - then they a registered postal letter. > Of the 70 ASNs I have allocated since 1996, I have revoked 10 (and > returned to the RIPE pool), 5 of which were this year. Its a pain, but > unless ear LIR does it, then we will end up with the same problem we have > with IPv4 address space. i applaud your efforts and the results. randy From mir at ripe.net Tue Sep 25 14:49:46 2001 From: mir at ripe.net (Mirjam Kuehne) Date: Tue, 25 Sep 2001 12:49:46 +0000 Subject: new IPv6 policy framework In-Reply-To: Your message of Tue, 25 Sep 2001 12:00:47 +0100. <20010925120047.B43281@enigma.ie> Message-ID: <200109251249.f8PCnkG21651@birch.ripe.net> Niall, Niall Richard Murphy 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 From randy at psg.com Tue Sep 25 15:04:25 2001 From: randy at psg.com (Randy Bush) Date: Tue, 25 Sep 2001 06:04:25 -0700 Subject: IPv4 and ASN Policy draft on-line References: <00A0294A.456242F2.3@cc.univie.ac.at> Message-ID: > there are valid cases where a (globally unique) AS# is required which > does not show up in the DFZ. please illustrate randy From randy at psg.com Tue Sep 25 15:06:46 2001 From: randy at psg.com (Randy Bush) Date: Tue, 25 Sep 2001 06:06:46 -0700 Subject: IPv4 and ASN Policy draft on-line References: <00A0294A.456242F2.3@cc.univie.ac.at> <20010925131317.P31448@Space.Net> Message-ID: >> 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. private peering, in the sense i to which i am used, folk who use a p2p circuit as opposed to an l2 mesh, have the exact same routing needs as folk who peer publicly. randy From randy at psg.com Tue Sep 25 15:06:46 2001 From: randy at psg.com (Randy Bush) Date: Tue, 25 Sep 2001 06:06:46 -0700 Subject: IPv4 and ASN Policy draft on-line References: <00A0294A.456242F2.3@cc.univie.ac.at> <20010925131317.P31448@Space.Net> Message-ID: To: lists-lir-wg-out at lists.ripe.net To: Gert Doering >> 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. private peering, in the sense i to which i am used, folk who use a p2p circuit as opposed to an l2 mesh, have the exact same routing needs as folk who peer publicly. randy From randy at psg.com Tue Sep 25 15:06:46 2001 From: randy at psg.com (Randy Bush) Date: Tue, 25 Sep 2001 06:06:46 -0700 Subject: IPv4 and ASN Policy draft on-line References: <00A0294A.456242F2.3@cc.univie.ac.at> <20010925131317.P31448@Space.Net> Message-ID: To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: Gert Doering >> 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. private peering, in the sense i to which i am used, folk who use a p2p circuit as opposed to an l2 mesh, have the exact same routing needs as folk who peer publicly. randy From randy at psg.com Tue Sep 25 15:06:46 2001 From: randy at psg.com (Randy Bush) Date: Tue, 25 Sep 2001 06:06:46 -0700 Subject: IPv4 and ASN Policy draft on-line References: <00A0294A.456242F2.3@cc.univie.ac.at> <20010925131317.P31448@Space.Net> Message-ID: To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: Gert Doering >> 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. private peering, in the sense i to which i am used, folk who use a p2p circuit as opposed to an l2 mesh, have the exact same routing needs as folk who peer publicly. randy From randy at psg.com Tue Sep 25 15:06:46 2001 From: randy at psg.com (Randy Bush) Date: Tue, 25 Sep 2001 06:06:46 -0700 Subject: IPv4 and ASN Policy draft on-line References: <00A0294A.456242F2.3@cc.univie.ac.at> <20010925131317.P31448@Space.Net> Message-ID: To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: Gert Doering >> 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. private peering, in the sense i to which i am used, folk who use a p2p circuit as opposed to an l2 mesh, have the exact same routing needs as folk who peer publicly. randy From woeber at cc.univie.ac.at Tue Sep 25 15:18:35 2001 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Tue, 25 Sep 2001 15:18:35 +0200 Subject: IPv4 and ASN Policy draft on-line Message-ID: <00A0295D.CEE56082.17@cc.univie.ac.at> >> 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. From woeber at cc.univie.ac.at Tue Sep 25 15:19:37 2001 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Tue, 25 Sep 2001 15:19:37 +0200 Subject: fwd: Re: IPv4 and ASN Policy draft on-line Message-ID: <00A0295D.F4096F02.39@cc.univie.ac.at> Apologies, forgot to include lir-wg... ______________________________________________________________________ To: MX%"randy at 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. From per at swip.net Tue Sep 25 16:05:58 2001 From: per at swip.net (Per Lundberg) Date: Tue, 25 Sep 2001 16:05:58 +0200 (MET DST) Subject: IPv4 and ASN Policy draft on-line In-Reply-To: <200109210921.f8L9LYG04538@birch.ripe.net> Message-ID: 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/msg00045.html ? 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 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 at swip.net Box 62 direct: +46 8 5626 4579 164 94 KISTA gsm: +46 704 26 4579 Sweden fax: +46 8 5626 4210 From joao at ripe.net Tue Sep 25 15:22:39 2001 From: joao at ripe.net (Joao Luis Silva Damas) Date: Tue, 25 Sep 2001 15:22:39 +0200 Subject: new IPv6 policy framework In-Reply-To: References: Message-ID: Hi, I don't see anyone asking anyone else to hand back IPv4 space. What is said is that since, eventually, one day, the Internet will be IPv6, taking the current user base of an ISP as a clear needed head count for IPv6 addresses is something useful. In other words, an IPv4 ISP should get at least their current user base worth of /48s if they ask for IPv6 addresses. Hope this adds clarity Joao Damas RIPE NCC At 13:57 +0100 25/9/01, Tim Chown wrote: >On Tue, 25 Sep 2001, Mirjam Kuehne wrote: > >> 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. > >An ISP is quite likely to continue offering IPv4 services for many, many >years to come even after launching an IPv6 service. Unless IPv4-only >customers are getting renumbered as the ISP's IPv4 space is compacted >to enable chunks to be handed back, this won't happen. And renumbering >is of course problematic. The most natural course is to not have any >precondition on handing back IPv4 space, but of course to allow it if the >ISP chooses. There seems to be little need to make such declarations now? > >tim -- From tjc at ecs.soton.ac.uk Tue Sep 25 14:57:39 2001 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Tue, 25 Sep 2001 13:57:39 +0100 (BST) Subject: new IPv6 policy framework In-Reply-To: <200109251249.f8PCnkG21651@birch.ripe.net> Message-ID: On Tue, 25 Sep 2001, Mirjam Kuehne wrote: > 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. An ISP is quite likely to continue offering IPv4 services for many, many years to come even after launching an IPv6 service. Unless IPv4-only customers are getting renumbered as the ISP's IPv4 space is compacted to enable chunks to be handed back, this won't happen. And renumbering is of course problematic. The most natural course is to not have any precondition on handing back IPv4 space, but of course to allow it if the ISP chooses. There seems to be little need to make such declarations now? tim From hank at att.net.il Tue Sep 25 14:41:46 2001 From: hank at att.net.il (Hank Nussbacher) Date: Tue, 25 Sep 2001 14:41:46 +0200 Subject: IPv4 and ASN Policy draft on-line In-Reply-To: <00A0294A.456242F2.3@cc.univie.ac.at> Message-ID: <4.3.2.7.2.20010925144054.00ad6e00@max.att.net.il> At 12:58 25/09/01 +0200, Wilfried Woeber, UniVie/ACOnet wrote: > >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... Based on my estimates, 15-20% fall into the now defunct or now single homed category. Totally not insignificant. -Hank > > -WW > _________________________________:_____________________________________ > Wilfried Woeber : e-mail: Woeber at 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 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From niallm-ripe at enigma.ie Tue Sep 25 17:16:08 2001 From: niallm-ripe at enigma.ie (Niall Richard Murphy) Date: Tue, 25 Sep 2001 16:16:08 +0100 Subject: new IPv6 policy framework In-Reply-To: <200109251249.f8PCnkG21651@birch.ripe.net>; from mir@ripe.net on Tue, Sep 25, 2001 at 12:49:46PM +0000 References: <20010925120047.B43281@enigma.ie> <200109251249.f8PCnkG21651@birch.ripe.net> Message-ID: <20010925161608.A44936@enigma.ie> On Tue, Sep 25, 2001 at 12:49:46PM +0000, Mirjam Kuehne wrote: Hey Mir, > 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. Sure. No-one disputes this. I suspect that it was only the lack of a timeframe which had me worried. (But that is what community discussion will provide, hopefully...) > 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. Ok. Sounds good to me! Niall -- Enigma Consulting Limited: Security, UNIX and telecommunications consultants. Address: Floor 2, 45 Dawson Street, Dublin 2, Ireland. http://www.enigma.ie/ From nurani at ripe.net Tue Sep 25 17:15:48 2001 From: nurani at ripe.net (Nurani Nimpuno) Date: Tue, 25 Sep 2001 17:15:48 +0200 Subject: IPv4 and ASN Policy draft on-line In-Reply-To: Message from Per Lundberg of "Tue, 25 Sep 2001 16:05:58 +0200." Message-ID: <200109251515.f8PFFmv02104@birch.ripe.net> 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 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 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 at swip.net * Box 62 direct: +46 8 5626 4579 * 164 94 KISTA gsm: +46 704 26 4579 * Sweden fax: +46 8 5626 4210 * * From gpan at apnic.net Wed Sep 26 01:23:51 2001 From: gpan at apnic.net (Guangliang Pan) Date: Wed, 26 Sep 2001 09:23:51 +1000 (EST) Subject: [hostmaster-staff] Re: Maintaining IPs in LIRs/Enterprise LIRs In-Reply-To: Message-ID: Thanks David I think APNIC's members would also be very happy to see this IP management tool. Regards, ____________________________________________________________________ Guangliang Pan, Internet Resource Analyst Asia Pacific Network Information Centre ph: +61 7 3367 0490 http://www.apnic.net fx: +61 7 3367 0482 Please send Internet Resource Requests to _____________________________________________________________________ On Tue, 25 Sep 2001, Neil Anderson Saunders wrote: > > > Hi, > > We would be very interested to see an IP management tool like this. I > think there is a large interest in the community for this. > > Kind regards, > > Neil > > -- > Hostmaster > edNET > t: +44 131 625 5560 (direct) > t: +44 131 466 7003 (office) > > > > On Mon, 24 Sep 2001, David R Huberman wrote: > > > > > > 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 at gblx.net | > > *--------------------------------* > > * Mailing List: hostmaster-staff * > * Handled by majordomo at staff.apnic.net * > From anne at apnic.net Thu Sep 27 09:36:17 2001 From: anne at apnic.net (Anne Lord) Date: Thu, 27 Sep 2001 17:36:17 +1000 (EST) Subject: [hostmaster-staff] Re: MIR proposal In-Reply-To: <006001c13911$edbe8d40$fa3b92c3@itc.ir> Message-ID: hi, > Stephen seems just wants to solve UUNET problem > with proposing MIR. However I am agree basically > with the Idea. APNIC has added NIR > ( National Internet Registry ) to the hierarchy. > I think RIPE must let the NIRs as well. Just a note about this. The membership category of NIR actually does not relate in any way to the specific problem that Stephen is trying to address which is that of large multinational organisations routed under one AS, having discontiguous IP address allocations through the establishment of many LIRs. In fact, the NIR model actually does nothing for aggregation - as NIRs receive a block which they further allocate to their members who run businesses within a particular country. The members in those countries served by NIRs are more likely to receive discontiguous blocks (simply because the NIRs have a smaller pool), thus not contributing to aggregation of routing information at all. We are working with the NIRs to solve this with a referral process for allocations directly from APNIC for the very large members of NIRs. Of course, having access to a local language service is very much on the plus side of having NIRs. For the record though, the NIRs exist under the confederation membership category. This also includes ISP confederations as well as NIRs. The two are *very* different entities, so the confederation category has been suspended until we work out a better solution. While I agree totally with Stephens objective and understand the motivation, the proposal needs detail. How would it work exactly? APNIC's ISP confederation model which tried to address the same thing, did not work, and gave unfair advantages to the ISP confederations. (Part of the reason the 'confederation' category has been suspended). It is definately a laudable challenge to try to produce a model and procedures such that the policies are fairly applied to all. regards Anne _____________________________________________________________________ Anne Lord, Manager, Policy Liaison Asia Pacific Network Information Centre phone: +61 7 3367 0490 http://www.apnic.net fax: +61 7 3367 0482 _____________________________________________________________________ > > > ----- Original Message ----- > From: "Stephen Burley" > To: ; > Sent: 06/09/2001 7:40 ?.? > Subject: Re: MIR proposal > > > > > > ----- Original Message ----- > > From: "John L Crain" > > To: > > Sent: Thursday, September 06, 2001 4:03 PM > > Subject: Re: MIR proposal > > > > > > > > > > > > > Hi Gert, > > > > > > > > > > > And yes, this is also very much needed for IPv6. Getting a /35 and > > > > having to hand out individual /48's to customers of customers of ours > > > > isn't going to build proper hierarchical routing. > > > > > > The concepts for IPv6 that are under discussion do already cover this. > > > An allocation goes to a large ISP who can then assign /48's directly to > > > networks connecting to them or shorter prefixes to > resellers/downstreams. > > > > > > I'm not sure if this works in IPv4 because of the limited amount of room > > we > > > have to play with. > > > > We are only limited because of teh current thinking and structure. > > > > > > > > > > I'm also not sure what the criteria would be in the proposal that > defines > > > who is and isn't allowed to become a MIR. It's certainly a differnet > > concept > > > to the present one in the RIPE region where LIR's don't "officially" > sub- > > > allocate. > > > > > > > Its not so different from the RIR model. > > > > > I can certainly see why a large ISP would want to do this. I'm not sure > > how > > > it changes the dynamics for smaller ISP's as to how they would get their > > IP > > > addresses. Becoming an LIR with an upstream rather than a regional > > registry > > > I assume means renumbering if you change the upstream. > > > > > > > MIR's are only to be created within a network (AS if you like) they would > > not suballocate to customers only LIR's withing their network (usualy > > country specific). Other LIR's not needing a MIR would deal direct with > the > > NCC. UUNET has 17 LIR's currently the MIR would suballocate to these not > to > > other ISP's or customers direct. > > BTW Nice to hear from you. > > > > > > > John Crain > > > > > > > > > > > > > > > > > > > > * Mailing List: hostmaster-staff * > * Handled by majordomo at staff.apnic.net * > From rcragg at atlantic-isp.co.uk Thu Sep 27 09:43:24 2001 From: rcragg at atlantic-isp.co.uk (Robin Cragg) Date: Thu, 27 Sep 2001 08:43:24 +0100 Subject: RFC1918 in public networks Message-ID: <5.1.0.14.2.20010927083706.00ab9ae0@mailhost.cerbernet.co.uk> Hi, We are a medium sized ISP, and as such we have a publicly visible network using non-private IP space. I am looking to renumber our entire network to private IP space, and was wondering if any other members have done this. The only problem I can see is that traceroutes from outside our AS will fail at our border routers, which will make troubleshooting harder. Has anyone done this and would they recommend it? Robin From gert at space.net Thu Sep 27 09:57:59 2001 From: gert at space.net (Gert Doering) Date: Thu, 27 Sep 2001 09:57:59 +0200 Subject: RFC1918 in public networks In-Reply-To: <5.1.0.14.2.20010927083706.00ab9ae0@mailhost.cerbernet.co.uk>; from rcragg@atlantic-isp.co.uk on Thu, Sep 27, 2001 at 08:43:24AM +0100 References: <5.1.0.14.2.20010927083706.00ab9ae0@mailhost.cerbernet.co.uk> Message-ID: <20010927095759.Y60109@Space.Net> Hi, On Thu, Sep 27, 2001 at 08:43:24AM +0100, Robin Cragg wrote: > We are a medium sized ISP, and as such we have a publicly visible network > using non-private IP space. I am looking to renumber our entire network to > private IP space, and was wondering if any other members have done this. > The only problem I can see is that traceroutes from outside our AS will > fail at our border routers, which will make troubleshooting harder. Has > anyone done this and would they recommend it? Don't do this. If you use private addresses behind your firewall and use NAT, that's your decision, but DO NOT USE rfc1918 space for publically visible infrastructure (think ICMP packets like host unreachable, fragmentation required, etc.). You MUST NOT send packets with RFC1918 source addresses into the world, and simply denying those packets will break things. Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From nurani at ripe.net Thu Sep 27 10:57:20 2001 From: nurani at ripe.net (Nurani Nimpuno) Date: Thu, 27 Sep 2001 10:57:20 +0200 Subject: IPv4 and ASN Policy draft on-line Enterprise & full IR policy doc In-Reply-To: Your message of Fri, 21 Sep 2001 15:43:02 BST. References: Message-ID: <200109270857.KAA25290@office.ripe.net> Dear Kevin, Enterprise LIRs are treated the same way as any other LIRs. There are no special policies or procedures that only apply to Enterprise LIRs. There are also no specific guidelines for Enterprise LIRs for this reason. The issue you raise about Assignment Windows for organisations that only assign to their own infrastructure has been raised in the past in the lir-wg. As you point out, this does not only affect Enterprise LIRs but any LIR that makes assignments to its own infrastructure (cable providers are an example of this). We have discussed this issue together with the lir-wg chair (Hans Petter Holen) and we are looking to find a solution that would meet this need. I believe this will be discussed at the upcoming RIPE 40 meeting. In the scenario that you describe where part of your organisation is assigning address space to another entity, you are more or less free to choose for any of the options that you describe. There are no guidelines or policies on this, but depends on your needs and future plans. To further discuss a solution that suits your needs, and for any other unresolved issues in your particular case, please write to . Kind regards, Nurani Nimpuno *--------------------------------------------------------* | Nurani Nimpuno | | Internet Address Policy Manager | | RIPE Network Co-ordination Centre | | http://www.ripe.net | *--------------------------------------------------------* kevin.bates at bt.com writes: * All, * * I would like to ask for advice and comment, and suggest it Is probably time * for a discussion about the differences in operations of the two types LIR's, * i.e. with the status of "enterprise" and "full". * * The current RIPE NCC documentation offers conflicting or no advice - I * cannot find any specific enterprise registry instructions / guidance, except * for the line "....large international Enterprises can also operate Local * IRs". * * I would expect to see something in either Ripe 212 (Guidelines for Setting * up a Local Internet Registry) or Ripe 185 (European Internet Registry * Policies and Procedures). * * Given that IPv4 and ASN policy document is now under review I think that * this is a good time to raise this issue again, and hopefully get something * agreed in writing. * * Therefore I am specifically looking for "Enterprise Registry Assignment * Policy instructions". * * I'll try briefly to give the background and a flavour of the issues. * * As a large company we operate several LIR's: * 1. A public Internet Service with a large allocation (many /16) * 2. Several small LIR's - product / site / country / subsidiary * specific. * 3. A large enterprise Registry (several Ripe /16 with both PI and PA * ranges and historic UK address space originally assigned by ARIN) * * These registries are not all necessarily managed by the same teams nor do * they all necessarily have specific interfaces with each other. The internet * connectivity for them all is not via the same ISP, but the enterprise * registry (3) does route via the Public Internet Service ISP (1). * * For an enterprise registry, assignment window size is irrelevant because all * address space used will be assigned within the company "owning" the * registry. Therefore a RIPE 141/219 is required for every assignment (this is * policy for normal registries using addresses for their own infrastructure). * Consider the scenario where an enterprise registry is allocated a block of * addresses that it will only ever assign to its own company, and that the * enterprise registry advertises & routes the whole block and assigns subnets * from it to departments within the company where required. For all practical * purposes all of these addresses are used by and assigned to the same place. * * In our case, problems involving the daily recovery/reassignment of subnets * was overcome by agreeing a large corporate assignment window with the * hostmaster and by keeping the number of addresses assigned to departments / * groups / projects within that number -and then asking for an assignment * increase where necessary. * * But what can an enterprise registry's addresses be used for? * * its own company infrastructure * * server farms and web hosting ( thus being used indirectly by * customers of the registry's company), and * * various other uses - but not onward assignment to "paying" * customers. * * Following several previous discussions between myself, my colleagues and * with various RIPE NCC hostmasters it has been agreed that * RIPE NCC will now allow us to transfer "experimental" addresses (obtained * from our enterprise Registry), which are used by a department within the * company, into "commercial" status - when the service offering changes from * experimental to commercial. This means that systems using these addresses do * not have to renumber to the range assigned by the public ISP. * Therefore I would like to see this policy formalised within RIPE NCC * documentation. * * And my next question is: * * If this department splits from the original company and becomes a separate * entity, what happens to the addresses space it uses? * There are several possibilities: * 1. Migrate from the enterprise registry to the public ISP or another * ISP (over a reasonable time period - but this could involve considerable * pain/cost), or * 2. Continue to use the enterprise registry address space, and then the * "enterprise" registry converts to a "full" registry, but what are the * implications? or * 3. Split the enterprise registry into 2 (not contiguous ranges) and * create another LIR. * * * regards * kevin * * From stephenb at uk.uu.net Thu Sep 27 12:45:08 2001 From: stephenb at uk.uu.net (Stephen Burley) Date: Thu, 27 Sep 2001 11:45:08 +0100 Subject: [hostmaster-staff] Re: MIR proposal References: Message-ID: <027301c14741$79d2f7c0$2e04bf3e@eu.frd.uu.net> A question to the NCC or any other registry managers: What is the criteria by which the RIR's request space from IANA, is it an 80% usage rule? ----- Original Message ----- From: "Anne Lord" To: "Hamid Alipour" Cc: ; "Mirjam Kuehne" Sent: Thursday, September 27, 2001 8:36 AM Subject: Re: [hostmaster-staff] Re: MIR proposal hi, > Stephen seems just wants to solve UUNET problem > with proposing MIR. However I am agree basically > with the Idea. APNIC has added NIR > ( National Internet Registry ) to the hierarchy. > I think RIPE must let the NIRs as well. Just a note about this. The membership category of NIR actually does not relate in any way to the specific problem that Stephen is trying to address which is that of large multinational organisations routed under one AS, having discontiguous IP address allocations through the establishment of many LIRs. In fact, the NIR model actually does nothing for aggregation - as NIRs receive a block which they further allocate to their members who run businesses within a particular country. The members in those countries served by NIRs are more likely to receive discontiguous blocks (simply because the NIRs have a smaller pool), thus not contributing to aggregation of routing information at all. We are working with the NIRs to solve this with a referral process for allocations directly from APNIC for the very large members of NIRs. Of course, having access to a local language service is very much on the plus side of having NIRs. For the record though, the NIRs exist under the confederation membership category. This also includes ISP confederations as well as NIRs. The two are *very* different entities, so the confederation category has been suspended until we work out a better solution. While I agree totally with Stephens objective and understand the motivation, the proposal needs detail. How would it work exactly? APNIC's ISP confederation model which tried to address the same thing, did not work, and gave unfair advantages to the ISP confederations. (Part of the reason the 'confederation' category has been suspended). It is definately a laudable challenge to try to produce a model and procedures such that the policies are fairly applied to all. regards Anne _____________________________________________________________________ Anne Lord, Manager, Policy Liaison Asia Pacific Network Information Centre phone: +61 7 3367 0490 http://www.apnic.net fax: +61 7 3367 0482 _____________________________________________________________________ > > > ----- Original Message ----- > From: "Stephen Burley" > To: ; > Sent: 06/09/2001 7:40 ?.? > Subject: Re: MIR proposal > > > > > > ----- Original Message ----- > > From: "John L Crain" > > To: > > Sent: Thursday, September 06, 2001 4:03 PM > > Subject: Re: MIR proposal > > > > > > > > > > > > > Hi Gert, > > > > > > > > > > > And yes, this is also very much needed for IPv6. Getting a /35 and > > > > having to hand out individual /48's to customers of customers of ours > > > > isn't going to build proper hierarchical routing. > > > > > > The concepts for IPv6 that are under discussion do already cover this. > > > An allocation goes to a large ISP who can then assign /48's directly to > > > networks connecting to them or shorter prefixes to > resellers/downstreams. > > > > > > I'm not sure if this works in IPv4 because of the limited amount of room > > we > > > have to play with. > > > > We are only limited because of teh current thinking and structure. > > > > > > > > > > I'm also not sure what the criteria would be in the proposal that > defines > > > who is and isn't allowed to become a MIR. It's certainly a differnet > > concept > > > to the present one in the RIPE region where LIR's don't "officially" > sub- > > > allocate. > > > > > > > Its not so different from the RIR model. > > > > > I can certainly see why a large ISP would want to do this. I'm not sure > > how > > > it changes the dynamics for smaller ISP's as to how they would get their > > IP > > > addresses. Becoming an LIR with an upstream rather than a regional > > registry > > > I assume means renumbering if you change the upstream. > > > > > > > MIR's are only to be created within a network (AS if you like) they would > > not suballocate to customers only LIR's withing their network (usualy > > country specific). Other LIR's not needing a MIR would deal direct with > the > > NCC. UUNET has 17 LIR's currently the MIR would suballocate to these not > to > > other ISP's or customers direct. > > BTW Nice to hear from you. > > > > > > > John Crain > > > > > > > > > > > > > > > > > > > > * Mailing List: hostmaster-staff * > * Handled by majordomo at staff.apnic.net * > From randy at psg.com Thu Sep 27 13:23:07 2001 From: randy at psg.com (Randy Bush) Date: Thu, 27 Sep 2001 04:23:07 -0700 Subject: RFC1918 in public networks References: <5.1.0.14.2.20010927083706.00ab9ae0@mailhost.cerbernet.co.uk> Message-ID: > We are a medium sized ISP, and as such we have a publicly visible network > using non-private IP space. that is specifically against rfc 1918. don't do it. randy From anne at apnic.net Thu Sep 27 09:36:17 2001 From: anne at apnic.net (Anne Lord) Date: Thu, 27 Sep 2001 17:36:17 +1000 (EST) Subject: [hostmaster-staff] Re: MIR proposal In-Reply-To: <006001c13911$edbe8d40$fa3b92c3@itc.ir> Message-ID: hi, > Stephen seems just wants to solve UUNET problem > with proposing MIR. However I am agree basically > with the Idea. APNIC has added NIR > ( National Internet Registry ) to the hierarchy. > I think RIPE must let the NIRs as well. Just a note about this. The membership category of NIR actually does not relate in any way to the specific problem that Stephen is trying to address which is that of large multinational organisations routed under one AS, having discontiguous IP address allocations through the establishment of many LIRs. In fact, the NIR model actually does nothing for aggregation - as NIRs receive a block which they further allocate to their members who run businesses within a particular country. The members in those countries served by NIRs are more likely to receive discontiguous blocks (simply because the NIRs have a smaller pool), thus not contributing to aggregation of routing information at all. We are working with the NIRs to solve this with a referral process for allocations directly from APNIC for the very large members of NIRs. Of course, having access to a local language service is very much on the plus side of having NIRs. For the record though, the NIRs exist under the confederation membership category. This also includes ISP confederations as well as NIRs. The two are *very* different entities, so the confederation category has been suspended until we work out a better solution. While I agree totally with Stephens objective and understand the motivation, the proposal needs detail. How would it work exactly? APNIC's ISP confederation model which tried to address the same thing, did not work, and gave unfair advantages to the ISP confederations. (Part of the reason the 'confederation' category has been suspended). It is definately a laudable challenge to try to produce a model and procedures such that the policies are fairly applied to all. regards Anne _____________________________________________________________________ Anne Lord, Manager, Policy Liaison Asia Pacific Network Information Centre phone: +61 7 3367 0490 http://www.apnic.net fax: +61 7 3367 0482 _____________________________________________________________________ > > > ----- Original Message ----- > From: "Stephen Burley" > To: ; > Sent: 06/09/2001 7:40 ?.? > Subject: Re: MIR proposal > > > > > > ----- Original Message ----- > > From: "John L Crain" > > To: > > Sent: Thursday, September 06, 2001 4:03 PM > > Subject: Re: MIR proposal > > > > > > > > > > > > > Hi Gert, > > > > > > > > > > > And yes, this is also very much needed for IPv6. Getting a /35 and > > > > having to hand out individual /48's to customers of customers of ours > > > > isn't going to build proper hierarchical routing. > > > > > > The concepts for IPv6 that are under discussion do already cover this. > > > An allocation goes to a large ISP who can then assign /48's directly to > > > networks connecting to them or shorter prefixes to > resellers/downstreams. > > > > > > I'm not sure if this works in IPv4 because of the limited amount of room > > we > > > have to play with. > > > > We are only limited because of teh current thinking and structure. > > > > > > > > > > I'm also not sure what the criteria would be in the proposal that > defines > > > who is and isn't allowed to become a MIR. It's certainly a differnet > > concept > > > to the present one in the RIPE region where LIR's don't "officially" > sub- > > > allocate. > > > > > > > Its not so different from the RIR model. > > > > > I can certainly see why a large ISP would want to do this. I'm not sure > > how > > > it changes the dynamics for smaller ISP's as to how they would get their > > IP > > > addresses. Becoming an LIR with an upstream rather than a regional > > registry > > > I assume means renumbering if you change the upstream. > > > > > > > MIR's are only to be created within a network (AS if you like) they would > > not suballocate to customers only LIR's withing their network (usualy > > country specific). Other LIR's not needing a MIR would deal direct with > the > > NCC. UUNET has 17 LIR's currently the MIR would suballocate to these not > to > > other ISP's or customers direct. > > BTW Nice to hear from you. > > > > > > > John Crain > > > > > > > > > > > > > > > > > > > > * Mailing List: hostmaster-staff * > * Handled by majordomo at staff.apnic.net * > From rico at noris.net Thu Sep 27 13:45:04 2001 From: rico at noris.net (Rico Gloeckner) Date: Thu, 27 Sep 2001 13:45:04 +0200 Subject: RFC1918 in public networks In-Reply-To: ; from randy@psg.com on Thu, Sep 27, 2001 at 04:23:07AM -0700 References: <5.1.0.14.2.20010927083706.00ab9ae0@mailhost.cerbernet.co.uk> Message-ID: <20010927134504.A15933@noris.de> On Thu, Sep 27, 2001 at 04:23:07AM -0700, Randy Bush wrote: > > We are a medium sized ISP, and as such we have a publicly visible network > > using non-private IP space. > > that is specifically against rfc 1918. don't do it. He said "non-private", what he intends seems to be against RFC1918; the current Structure seems however fine. Although, even when reading the mail a third time i dont really understand what he is intending to do, so basically i might be wrong. -rg From keith.a.johnson at wcom.com Thu Sep 27 14:14:23 2001 From: keith.a.johnson at wcom.com (Keith Johnson) Date: Thu, 27 Sep 2001 08:14:23 -0400 Subject: IPv4 and ASN Policy draft on-line In-Reply-To: <200109210921.f8L9LYG04538@birch.ripe.net>; from nurani@ripe.net on Fri, Sep 21, 2001 at 11:21:34AM +0200 References: <200109210921.f8L9LYG04538@birch.ripe.net> Message-ID: <20010927081423.D21217@uu.net> In the past I was confused about RIPEs standpoint on assignment of PA space to users that are going to be running BGP and be dual homed. I think it would be good to include something in the document that I read on the list before if this is a acceptable assignment practice. Below is part of an email from Nurani Nimpuno on 03 Aug 2001. "However, it is also possible to multi-home by having a PA address range announced through two providers. If the PA addresses come from ISP A's allocation, the customer would have to agree with ISP B to announce that range separately. ISP A would also have to announce the range as a more specific route together with their aggregate." Thanks, Keith Johnson Network Engineer WorldCom Joan Muyskenweg 22 1096CJ Amsterdam, NL Fri, Sep 21, 2001 at 11:21:34AM +0200, Quoting Nurani Nimpuno (nurani at ripe.net): > 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 or > indicate your interest on this list. > > Kind regards, > > Nurani Nimpuno > RIPE NCC > From stuart.prevost at btinternet.com Thu Sep 27 16:11:11 2001 From: stuart.prevost at btinternet.com (Stuart Prevost) Date: Thu, 27 Sep 2001 15:11:11 +0100 Subject: new IPv6 policy framework References: <200109250911.f8P9BHG25724@birch.ripe.net> Message-ID: <004f01c1475e$436e13f0$fa709284@ps1> > Dear LIRs, > snip > > > Kind Regards, > Mirjam Kuehne > RIPE NCC > ---------------- > snip > > 2. Overview > snip > > > This document does not attempt to provide details of policy implementation, > procedures or documentation; nor does it document requirements for > management of address space which is allocated. These policies can be > established globally or regionally as appropriate, based on global > consensus regarding the fundamental principles described here. > > As stated above it says that this document does not attempt to document requirements for management of address space which is allocated. I feel that the community needs to understand how the RIR will manage the address space, for the following reasons. 1. If a initial allocation of /35 or smaller is allocated as described in section 4. Is it still the case that the /29 will be reserved? 2. If a IPv6 allocation is made say based on existing IPv4 services, and later the provider asks for a addition allocation because they have reached the threshold for their initial allocation. will the additional allocation be contiguous or not? What I'm basically saying is under the old policy if you where allocated a /35 you knew that the /29 was reserved for you so when you required additional address their would be from the say IPv6 prefix e.g 2001:618::/35 run out of address space and need more Ripe would change the allocation to 2001:618::/29 and no additional routes would be created in the DFZ. Under the new policy I do not understand how the RIR are going to manage the address space, and this document clearly states it does not document it. I know the above section does say that "These policies can be established globally or regionally as appropriate, based on global consensus regarding the fundamental principles described here." So I might be jumping ahead here, but I think these issues also need discussing in addition to the new policy. So my question to the RIR's is do they have an idea of how they propose to managed the address space based on this new policy? I think the new policy is great in clearing up who can apply and what you can apply for. However if we don't know how the RIR's are going to manage the address space we won't understand how this policy will affect the DFZ, and for providers to understand what their next allocation is going to be? Best Regards, Stuart From randy at psg.com Thu Sep 27 14:34:52 2001 From: randy at psg.com (Randy Bush) Date: Thu, 27 Sep 2001 05:34:52 -0700 Subject: RFC1918 in public networks References: <5.1.0.14.2.20010927083706.00ab9ae0@mailhost.cerbernet.co.uk> <20010927134504.A15933@noris.de> Message-ID: >>> We are a medium sized ISP, and as such we have a publicly visible network >>> using non-private IP space. >> that is specifically against rfc 1918. don't do it. > He said "non-private" oops! sorry. before coffee. randy From sabrina at ripe.net Thu Sep 27 19:11:25 2001 From: sabrina at ripe.net (Sabrina Waschke) Date: Thu, 27 Sep 2001 19:11:25 +0200 Subject: [hostmaster-staff] Re: MIR proposal In-Reply-To: Message from "Stephen Burley" of "Thu, 27 Sep 2001 11:45:08 BST." <027301c14741$79d2f7c0$2e04bf3e@eu.frd.uu.net> Message-ID: <200109271711.f8RHBPv12670@birch.ripe.net> "Stephen Burley" writes: * A question to the NCC or any other registry managers: * * What is the criteria by which the RIR's request space from IANA, is it an * 80% usage rule? Yes, it is. Regards, Sabrina Waschke -- o------------------------------------------o | Sabrina Waschke sabrina at ripe.net | | Registration Services Operations Manager | | | | RIPE NCC tel +31 20 535 4444 | | www.ripe.net fax +31 20 535 4445 | o------------------------------------------o * ----- Original Message ----- * From: "Anne Lord" * To: "Hamid Alipour" * Cc: ; "Mirjam Kuehne" * Sent: Thursday, September 27, 2001 8:36 AM * Subject: Re: [hostmaster-staff] Re: MIR proposal * * * * hi, * * > Stephen seems just wants to solve UUNET problem * > with proposing MIR. However I am agree basically * > with the Idea. APNIC has added NIR * > ( National Internet Registry ) to the hierarchy. * > I think RIPE must let the NIRs as well. * * Just a note about this. The membership category of NIR actually * does not relate in any way to the specific problem that Stephen is trying * to address which is that of large multinational organisations routed * under one AS, having discontiguous IP address allocations through the * establishment of many LIRs. In fact, the NIR model actually does nothing * for aggregation - as NIRs receive a block which they further allocate * to their members who run businesses within a particular country. The * members in those countries served by NIRs are more likely to receive * discontiguous blocks (simply because the NIRs have a smaller pool), thus * not contributing to aggregation of routing information at all. * We are working with the NIRs to solve this with a referral process for * allocations directly from APNIC for the very large members of NIRs. * * Of course, having access to a local language service is very much on the * plus side of having NIRs. * * For the record though, the NIRs exist under the confederation membership * category. This also includes ISP confederations as well as NIRs. The * two are *very* different entities, so the confederation category has * been suspended until we work out a better solution. * * While I agree totally with Stephens objective and understand the motivation, * the proposal needs detail. How would it work exactly? APNIC's ISP * confederation * model which tried to address the same thing, did not work, and gave unfair * advantages to the ISP confederations. (Part of the reason the * 'confederation' * category has been suspended). * * It is definately a laudable challenge to try to produce a model and * procedures such that the policies are fairly applied to all. * * regards * * Anne * _____________________________________________________________________ * Anne Lord, Manager, Policy Liaison * Asia Pacific Network Information Centre phone: +61 7 3367 0490 * http://www.apnic.net fax: +61 7 3367 0482 * _____________________________________________________________________ * * * * * > * > * > ----- Original Message ----- * > From: "Stephen Burley" * > To: ; * > Sent: 06/09/2001 7:40 ?.? * > Subject: Re: MIR proposal * > * > * > > * > > ----- Original Message ----- * > > From: "John L Crain" * > > To: * > > Sent: Thursday, September 06, 2001 4:03 PM * > > Subject: Re: MIR proposal * > > * > > * > > > * > > > * > > > Hi Gert, * > > > * > > > > * > > > > And yes, this is also very much needed for IPv6. Getting a /35 and * > > > > having to hand out individual /48's to customers of customers of * ours * > > > > isn't going to build proper hierarchical routing. * > > > * > > > The concepts for IPv6 that are under discussion do already cover this. * > > > An allocation goes to a large ISP who can then assign /48's directly * to * > > > networks connecting to them or shorter prefixes to * > resellers/downstreams. * > > > * > > > I'm not sure if this works in IPv4 because of the limited amount of * room * > > we * > > > have to play with. * > > * > > We are only limited because of teh current thinking and structure. * > > * > > * > > > * > > > I'm also not sure what the criteria would be in the proposal that * > defines * > > > who is and isn't allowed to become a MIR. It's certainly a differnet * > > concept * > > > to the present one in the RIPE region where LIR's don't "officially" * > sub- * > > > allocate. * > > > * > > * > > Its not so different from the RIR model. * > > * > > > I can certainly see why a large ISP would want to do this. I'm not * sure * > > how * > > > it changes the dynamics for smaller ISP's as to how they would get * their * > > IP * > > > addresses. Becoming an LIR with an upstream rather than a regional * > > registry * > > > I assume means renumbering if you change the upstream. * > > > * > > * > > MIR's are only to be created within a network (AS if you like) they * would * > > not suballocate to customers only LIR's withing their network (usualy * > > country specific). Other LIR's not needing a MIR would deal direct with * > the * > > NCC. UUNET has 17 LIR's currently the MIR would suballocate to these not * > to * > > other ISP's or customers direct. * > > BTW Nice to hear from you. * > > * > > * > > > John Crain * > > > * > > > * > > > * > > > * > > > * > > > * > * > * Mailing List: hostmaster-staff * * > * Handled by majordomo at staff.apnic.net * * > * * * From huberman at gblx.net Thu Sep 27 19:18:58 2001 From: huberman at gblx.net (David R Huberman) Date: Thu, 27 Sep 2001 10:18:58 -0700 (MST) Subject: AW for infrastructure In-Reply-To: <200109270857.KAA25290@office.ripe.net> Message-ID: > The issue you raise about Assignment Windows for organisations that > only assign to their own infrastructure has been raised in the past in > the lir-wg. As you point out, this does not only affect Enterprise > LIRs but any LIR that makes assignments to its own infrastructure > (cable providers are an example of this). We have discussed this issue > together with the lir-wg chair (Hans Petter Holen) and we are looking > to find a solution that would meet this need. I believe this will be > discussed at the upcoming RIPE 40 meeting. It was my understanding that the RIPE NCC was tasked at RIPE-39 with preparing and posting a policy proposal for the incorporation of AWs for infrastructure assignments. Can we please see this proposal? This issue has been discussed at every RIPE meeting over the past year. To my recollection, there has never been any vocal dissent by the LIR-WG constituency over this issue. /david *--------------------------------* | Global Crossing API | | Manager, Global IP Addressing | | (703) 627-5800 | | huberman at gblx.net | *--------------------------------* From gert at space.net Thu Sep 27 21:52:36 2001 From: gert at space.net (Gert Doering) Date: Thu, 27 Sep 2001 21:52:36 +0200 Subject: APNIC and RIPE IPv6 policies [Re: Agendas for IPv6/lir/eix joint sessions RIPE40] In-Reply-To: ; from pekkas@netcore.fi on Thu, Sep 27, 2001 at 09:01:49PM +0300 References: <20010927195049.E60109@Space.Net> Message-ID: <20010927215236.H60109@Space.Net> Hi, On Thu, Sep 27, 2001 at 09:01:49PM +0300, Pekka Savola wrote: > Sure, but this requires significant additional assignments from IANA; > 2001::/16 will not be nearly enough. For example, 21xx::/8 might be > enough for a while. Yes. And IANA is part of the picture, concerning IPv6 assignment / allocation policies. So that should not hinder us doing the right thing (if we decide this is it). Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From hph at online.no Fri Sep 28 00:36:39 2001 From: hph at online.no (Hans Petter Holen) Date: Fri, 28 Sep 2001 00:36:39 +0200 Subject: AW for infrastructure References: Message-ID: <004301c147a4$dfbabb50$0300000a@hholkvza> Dear David & lir-wg, My appologies for not posting this earlier, but I have been busy changing jobs. Here is the status on this action from my slides at RIPE 39: 36.5 Assignment window applied on infrastructure An LIR may request a separate assignment window for assignments to its own infrastructure (IIAW Incremental Infrastructure Assignment window). Such an assignment window should apply to the incremental assignment. Do we want the IIAW to be reviewed annualy ? Or should we keep it as it is because LIRs realy can't be trusted in assigning addresses to themselves and we should always have a second opinion. TO be further discussed on lir-wg: .2-4 week discussion .Call for consensus .Forward to RIPE NCC for implementation So far there have been no concrete proposals on how to do this. Some background: RIPE 185 3.7 reads: http://www.ripe.net/ripe/docs/ir-policies-procedures.html#toc39 (...) To assure the conservation, aggregation, and registration goals are met, we must be sure the assignment criteria and procedures are properly applied. In general, this means that Local IRs with little or no experience should receive maximal support in the assignment process, whereas Local IRs with more experience should be allowed to make most assignments without consulting the RIPE NCC. Large assignments always require prior approval because of their impact on the available address space. (...) The assignment window is not only applied to individual assignments, but to multiple assignments to the same end user in a 12 month period If a Local IR makes more than one assignment to an organisation in any 12 month period, the total amount of address space assigned may not exceed the Local IR's assignment window. This also applies to address space used by the Registry for their internal network. Additional address space can only be assigned to that organisation after approval by the RIPE NCC. Problem: Since this applies to address space used by the registry for their internal network, a registry that mainly assignes addresses to its own infrastructure will never qualify for an assignment window. Proposed solution: Change the wording to: This does not apply to address space used by the registry for their internal netowork. On the registrys internal network the asssignment window applies to the individual assignment. In this way the registry can make assignments to its own infrastructure when needed. When the registry has convinced the RIPE NCC that the "assignment criteria and procedures are properly applied. " The registry will get an assignment window, and since the assignment window applies to individual assignment the registry can grow its own network in a timely fashion. If the RIPE NCC feels that a registry is misusing this mechanism the RIPE NCC already have the mechanism of an audit in place, and should be able to uncover improper interpretation of the policy. Sincerely, --- Hans Petter Holen, Technical Manager Tiscali, Norway, +47 24 11 26 44 mobile: +47 99 21 76 70 fax:+47 24 11 24 11 From kevin.bates at bt.com Fri Sep 28 11:23:02 2001 From: kevin.bates at bt.com (kevin.bates at bt.com) Date: Fri, 28 Sep 2001 10:23:02 +0100 Subject: How Change route object origin entry Message-ID: Hi A question I need to change the "Origin" entry on a /20 route object. This route is to be advertised via a different upstream provider, from a different AS number. The upstream provider will not advertise the route "until RIPE have been informed". I cannot change the route object entry. I get the following "Error: Hierarchical authorisation failed, request forwarded to maintainer" and I get the request forwarded to me. The mnt-by on the route object is not the problem - I can update other objects with that mnt-by object and I can change the "notify" entry on my route object. Therefore the error must be because of the mnt-by entry within the "receiving" AS number. (which I am not authorised to update) but I don't understand how. Is this the correct diagnosis? and is there something else I should be doing? I could ask RIPE hostmaster to make the changes but the ticketing system could take a couple of weeks. I could ask the new upstream AS owner to add me to their mnt-by entry but I am nothing to do with them. All suggestions gratefully received. kevin From dvella at melitacable.com Fri Sep 28 11:35:00 2001 From: dvella at melitacable.com (Duncan Vella) Date: Fri, 28 Sep 2001 11:35:00 +0200 Subject: How Change route object origin entry In-Reply-To: Message-ID: Kevin, This just happened to me! My problem was that mnt-by of the /20 inetnum object was RIPE-NCC-HM-MNT. For you to be able to change the /20 route object, you need to tell RIPE to add mnt-routes: YOUR_MNT into the /20 inetnum object. It took me 2/3 weeks to do this with the hostmaster's help. Regards, Duncan > -----Original Message----- > From: owner-lir-wg at ripe.net [mailto:owner-lir-wg at ripe.net]On Behalf Of > kevin.bates at bt.com > Sent: Friday, September 28, 2001 11:23 AM > To: lir-wg at ripe.net > Subject: How Change route object origin entry > > > Hi > > A question > > I need to change the "Origin" entry on a /20 route object. This > route is to > be advertised via a different upstream provider, from a different > AS number. > > The upstream provider will not advertise the route "until RIPE have been > informed". > > I cannot change the route object entry. I get the following "Error: > Hierarchical authorisation failed, request forwarded to maintainer" and I > get the request forwarded to me. > The mnt-by on the route object is not the problem - I can update other > objects with that mnt-by object and I can change the "notify" entry on my > route object. > > Therefore the error must be because of the mnt-by entry within the > "receiving" AS number. (which I am not authorised to update) but I don't > understand how. > > Is this the correct diagnosis? and is there something else I should be > doing? > > I could ask RIPE hostmaster to make the changes but the ticketing system > could take a couple of weeks. > > I could ask the new upstream AS owner to add me to their mnt-by > entry but I > am nothing to do with them. > > All suggestions gratefully received. > > kevin > > > > > > > > From andrei at ripe.net Fri Sep 28 11:43:56 2001 From: andrei at ripe.net (Andrei Robachevsky) Date: Fri, 28 Sep 2001 11:43:56 +0200 Subject: How Change route object origin entry References: Message-ID: <3BB4465C.D4B89992@ripe.net> Dear Kevin, kevin.bates at bt.com wrote: > > Hi > > A question > > I need to change the "Origin" entry on a /20 route object. This route is to > be advertised via a different upstream provider, from a different AS number. > > The upstream provider will not advertise the route "until RIPE have been > informed". > > I cannot change the route object entry. I get the following "Error: > Hierarchical authorisation failed, request forwarded to maintainer" and I > get the request forwarded to me. > The mnt-by on the route object is not the problem - I can update other > objects with that mnt-by object and I can change the "notify" entry on my > route object. The problem here is that "origin:" is part of the primary key for the route object. So in fact you are creating a new route object, not updating the existing one. In this case the authorisation procedure is more complex and is defined in the RFC2725 (Routing Policy System Security). To be able to create a route object the request should pass authorisation from - the aut-num which is referenced from the "origin:" attribute - the exact match route object (or one level less specific one if the exact match does not exist), or the inetnum object (exact or one level less specific) if route objects don't exist. When checking authorisation from aut-num and route (inetnum) "mnt-routes:" attribute is considered (or mnt-lower, mnt-by if mnt-routes doesn't exist). I may be more specific if you could send us the actual object you would like to create. > > Therefore the error must be because of the mnt-by entry within the > "receiving" AS number. (which I am not authorised to update) but I don't > understand how. > > Is this the correct diagnosis? and is there something else I should be > doing? > > I could ask RIPE hostmaster to make the changes but the ticketing system > could take a couple of weeks. > > I could ask the new upstream AS owner to add me to their mnt-by entry but I > am nothing to do with them. > > All suggestions gratefully received. > > kevin Regards, Andrei Robachevsky RIPE NCC From aid at vianw.net Fri Sep 28 10:39:42 2001 From: aid at vianw.net (Adrian Bool) Date: Fri, 28 Sep 2001 09:39:42 +0100 Subject: [hostmaster-staff] Re: MIR proposal In-Reply-To: <200109271711.f8RHBPv12670@birch.ripe.net> References: <200109271711.f8RHBPv12670@birch.ripe.net> Message-ID: <01092809394201.16602@ewe.noc.u-net.net> On Thursday 27 September 2001 18:11, you wrote: > "Stephen Burley" writes: > * A question to the NCC or any other registry managers: > * > * What is the criteria by which the RIR's request space from IANA, is it > an * 80% usage rule? Is this your request for new space when 80% of your current space has been declared used or when you have allocated 80% of your space? Regards, aid -- Adrian Bool | http://noc.vianetworks.net/ Director, Global Network | tel://+44.1925.484061/ VIA NET.WORKS Inc. | noc://+49.203.3093.1111/ From cschiefner at iprimustel.de Thu Sep 27 23:35:07 2001 From: cschiefner at iprimustel.de (Carsten Schiefner) Date: Thu, 27 Sep 2001 23:35:07 +0200 Subject: Maintaining IPs in LIRs/Enterprise LIRs References: <20010924221732.F16728@cyberstrider.net> Message-ID: <3BB39B8A.9849E630@iprimustel.de> Denesh, Denesh Bhabuta wrote: > [THE tool!] > > You may want to give RoboBijal a go... it was discussed on the Tools > working group. > > Get it from www.robobijal.org did I miss some announcement on the list here? I was following the discussions about the specs very quietly, but nevertheless very interested. Besides that I haven't read anything more so far... Cheers, Carsten From aid at vianw.net Fri Sep 28 12:18:19 2001 From: aid at vianw.net (Adrian Bool) Date: Fri, 28 Sep 2001 11:18:19 +0100 Subject: [hostmaster-staff] Re: MIR proposal In-Reply-To: <01092809394201.16602@ewe.noc.u-net.net> References: <200109271711.f8RHBPv12670@birch.ripe.net> <01092809394201.16602@ewe.noc.u-net.net> Message-ID: <01092811181907.16602@ewe.noc.u-net.net> On Friday 28 September 2001 09:39, you wrote: > On Thursday 27 September 2001 18:11, you wrote: > > "Stephen Burley" writes: > > * A question to the NCC or any other registry managers: > > * > > * What is the criteria by which the RIR's request space from IANA, is it > > an * 80% usage rule? > > Is this your request for new space when 80% of your current space has been > declared used or when you have allocated 80% of your space? Woops - I cut too much, this was meant to be in reply to Sabrina's "Yes, it is". Sorry for any confusion. aid -- Adrian Bool | http://noc.vianetworks.net/ Director, Global Network | tel://+44.1925.484061/ VIA NET.WORKS Inc. | noc://+49.203.3093.1111/ From nurani at ripe.net Fri Sep 28 12:42:32 2001 From: nurani at ripe.net (Nurani Nimpuno) Date: Fri, 28 Sep 2001 12:42:32 +0200 Subject: [hostmaster-staff] Re: MIR proposal In-Reply-To: <01092811181907.16602@ewe.noc.u-net.net> References: <01092809394201.16602@ewe.noc.u-net.net> <200109271711.f8RHBPv12670@birch.ripe.net> <01092809394201.16602@ewe.noc.u-net.net> Message-ID: <5.1.0.14.2.20010928124009.0406c0f0@imap.ripe.net> Dear Adrian, At 11:18 28/09/01 +0100, Adrian Bool wrote: >On Friday 28 September 2001 09:39, you wrote: > > On Thursday 27 September 2001 18:11, you wrote: > > > "Stephen Burley" writes: > > > * A question to the NCC or any other registry managers: > > > * > > > * What is the criteria by which the RIR's request space from IANA, is it > > > an * 80% usage rule? > > > > Is this your request for new space when 80% of your current space has been > > declared used or when you have allocated 80% of your space? > >Woops - I cut too much, this was meant to be in reply to Sabrina's "Yes, it >is". When 80% is currently *allocated* out of the RIPE NCC address blocks, we request additional addresses from IANA. It is unclear about what you mean with "declared used" , however, we do not wait until all LIRs have *assigned* all addresses from their allocations before we request additional address space. In other words, when we have less than 20% free address space to allocate from, a request is sent to IANA. Hope this answered your question. Kind regards, Nurani Nimpuno *--------------------------------------------------------* | Nurani Nimpuno | | Internet Address Policy Manager | | RIPE Network Co-ordination Centre | | http://www.ripe.net | *--------------------------------------------------------* >Sorry for any confusion. > >aid > >-- >Adrian Bool | http://noc.vianetworks.net/ >Director, Global Network | tel://+44.1925.484061/ >VIA NET.WORKS Inc. | noc://+49.203.3093.1111/ From sabrina at ripe.net Fri Sep 28 12:38:57 2001 From: sabrina at ripe.net (Sabrina Waschke) Date: Fri, 28 Sep 2001 12:38:57 +0200 Subject: How Change route object origin entry In-Reply-To: Message from kevin.bates@bt.com of "Fri, 28 Sep 2001 10:23:02 BST." Message-ID: <200109281038.f8SAcvv18963@birch.ripe.net> For a change to your allocation object (maintained by the RIPE-NCC-HM-MNT) you can send a message to the ticket in which the allocation was approved. You could also open a new ticket by sending a message to . BTW, the RIPE NCC Hostmaster wait queue is currently between 2-3 working days. Regards, Sabrina -- o------------------------------------------o | Sabrina Waschke sabrina at ripe.net | | Registration Services Operations Manager | | | | RIPE NCC tel +31 20 535 4444 | | www.ripe.net fax +31 20 535 4445 | o------------------------------------------o kevin.bates at bt.com writes: * Hi * * A question * * I need to change the "Origin" entry on a /20 route object. This route is to * be advertised via a different upstream provider, from a different AS number. * * The upstream provider will not advertise the route "until RIPE have been * informed". * * I cannot change the route object entry. I get the following "Error: * Hierarchical authorisation failed, request forwarded to maintainer" and I * get the request forwarded to me. * The mnt-by on the route object is not the problem - I can update other * objects with that mnt-by object and I can change the "notify" entry on my * route object. * * Therefore the error must be because of the mnt-by entry within the * "receiving" AS number. (which I am not authorised to update) but I don't * understand how. * * Is this the correct diagnosis? and is there something else I should be * doing? * * I could ask RIPE hostmaster to make the changes but the ticketing system * could take a couple of weeks. * * I could ask the new upstream AS owner to add me to their mnt-by entry but I * am nothing to do with them. * * All suggestions gratefully received. * * kevin * * * * * * * From aid at vianw.net Fri Sep 28 13:05:41 2001 From: aid at vianw.net (Adrian Bool) Date: Fri, 28 Sep 2001 12:05:41 +0100 Subject: [hostmaster-staff] Re: MIR proposal In-Reply-To: <5.1.0.14.2.20010928124009.0406c0f0@imap.ripe.net> References: <01092809394201.16602@ewe.noc.u-net.net> <5.1.0.14.2.20010928124009.0406c0f0@imap.ripe.net> Message-ID: <0109281205410A.16602@ewe.noc.u-net.net> Hi Nurani, On Friday 28 September 2001 11:42, Nurani Nimpuno wrote: > At 11:18 28/09/01 +0100, Adrian Bool wrote: > >On Friday 28 September 2001 09:39, you wrote: > > > On Thursday 27 September 2001 18:11, you wrote: > > > > "Stephen Burley" writes: > > > > * A question to the NCC or any other registry managers: > > > > * > > > > * What is the criteria by which the RIR's request space from IANA, > > > > is it an * 80% usage rule? > > > > > > Is this your request for new space when 80% of your current space has > > > been declared used or when you have allocated 80% of your space? > > > >Woops - I cut too much, this was meant to be in reply to Sabrina's "Yes, > > it is". > > When 80% is currently *allocated* out of the RIPE NCC address blocks, we > request additional addresses from IANA. > It is unclear about what you mean with "declared used" , however, we do not > wait until all LIRs have *assigned* all addresses from their allocations > before we request additional address space. > In other words, when we have less than 20% free address space to allocate > from, a request is sent to IANA. > > Hope this answered your question. Yes, that was very useful. I think this is the whole crux of the situation. Stephen (as fas I can tell), undoubtedly like many others (myself included), would like to act as a registry to the in-country operations of our respective networks. 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. This makes a huge difference, as assignees of an RIR are orthogonal - the usage of one does not effect the allocation of another. With the assignees of an LIR this is not the case, as the actual usage of one assignee within the LIR effects the abilty of another assignee to aquire more space when it is right and proper for them to do so. I feel that international networks require the ability to operate according to the same rules as RIPE - just working on a smaller scale - as another level down in the hierarchy. i.e We should should be able to apply for more IP space once we have sub-allocated 80% of our allocation to our in-country networks - natuarally in a responsible manner, according to the same rules that an RIR would allocate space to these in-country networks. Regards, aid -- Adrian Bool | http://noc.vianetworks.net/ Director, Global Network | tel://+44.1925.484061/ VIA NET.WORKS Inc. | noc://+49.203.3093.1111/ From gert at space.net Fri Sep 28 13:58:24 2001 From: gert at space.net (Gert Doering) Date: Fri, 28 Sep 2001 13:58:24 +0200 Subject: [hostmaster-staff] Re: MIR proposal In-Reply-To: <0109281205410A.16602@ewe.noc.u-net.net>; from aid@vianw.net on Fri, Sep 28, 2001 at 12:05:41PM +0100 References: <01092809394201.16602@ewe.noc.u-net.net> <5.1.0.14.2.20010928124009.0406c0f0@imap.ripe.net> <0109281205410A.16602@ewe.noc.u-net.net> Message-ID: <20010928135824.C16960@Space.Net> Hi, On Fri, Sep 28, 2001 at 12:05:41PM +0100, Adrian Bool wrote: > I feel that international networks require the ability to operate according > to the same rules as RIPE - just working on a smaller scale - as another > level down in the hierarchy. Not only "international networks", but also national ones that have a hierarchical structure of re-sellers. > i.e We should should be able to apply for more IP space once we have > sub-allocated 80% of our allocation to our in-country networks - natuarally > in a responsible manner, according to the same rules that an RIR would > allocate space to these in-country networks. Sure. Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From beri at kpnqwest.net Fri Sep 28 14:21:05 2001 From: beri at kpnqwest.net (Berislav Todorovic) Date: Fri, 28 Sep 2001 14:21:05 +0200 (CEST) Subject: [hostmaster-staff] Re: MIR proposal In-Reply-To: <0109281205410A.16602@ewe.noc.u-net.net> Message-ID: On Fri, 28 Sep 2001, Adrian Bool wrote: >> i.e We should should be able to apply for more IP space once we have >> sub-allocated 80% of our allocation to our in-country networks - natuarally >> in a responsible manner, according to the same rules that an RIR would >> allocate space to these in-country networks. Actually, there was a proopsal for introducing "status: LIR-ALLOCATED", that should allow such a thing. It's under implementation. Any news on the progress of that? Regards, Beri --------- Berislav Todorovic, Senior NOC Specialist -------- ------- KPNQwest N.V. - IP NOC (formerly EUnet NOC) ------ ---- Wilhelmina van Pruisenweg 78, 2595 AN Den Haag, NL ---- --- Phone: +31-70-379-3990; Mobile: +31-651-333-641 --- -- Email: beri at kpnqwest.net <=> beri at EU.net -- --- _ _ ____ _ .--. ____ ____ __/_ --- ----- /__/ /___/ /\ / / / | / /___/ /___ / ------ ------ _/ \_ / _/ \/ (__.\ |/\/ /___ ____/ (__. ----- From nurani at ripe.net Fri Sep 28 15:05:13 2001 From: nurani at ripe.net (Nurani Nimpuno) Date: Fri, 28 Sep 2001 15:05:13 +0200 Subject: [hostmaster-staff] Re: MIR proposal In-Reply-To: References: <0109281205410A.16602@ewe.noc.u-net.net> Message-ID: <5.1.0.14.2.20010928150257.03329bf0@imap.ripe.net> Yes indeed. We will send out a mail later today with the details of this proposal. Kind regards, Nurani Nimpuno RIPE NCC At 14:21 28/09/01 +0200, Berislav Todorovic wrote: >On Fri, 28 Sep 2001, Adrian Bool wrote: > > >> i.e We should should be able to apply for more IP space once we have > >> sub-allocated 80% of our allocation to our in-country networks - > natuarally > >> in a responsible manner, according to the same rules that an RIR would > >> allocate space to these in-country networks. > >Actually, there was a proopsal for introducing "status: LIR-ALLOCATED", that >should allow such a thing. It's under implementation. > >Any news on the progress of that? > >Regards, >Beri > >--------- Berislav Todorovic, Senior NOC Specialist -------- >------- KPNQwest N.V. - IP NOC (formerly EUnet NOC) ------ >---- Wilhelmina van Pruisenweg 78, 2595 AN Den Haag, NL ---- >--- Phone: +31-70-379-3990; Mobile: +31-651-333-641 --- >-- Email: beri at kpnqwest.net <=> beri at EU.net -- >--- _ _ ____ _ .--. ____ ____ __/_ --- >----- /__/ /___/ /\ / / / | / /___/ /___ / ------ >------ _/ \_ / _/ \/ (__.\ |/\/ /___ ____/ (__. ----- From stephenb at uk.uu.net Fri Sep 28 15:22:15 2001 From: stephenb at uk.uu.net (Stephen Burley) Date: Fri, 28 Sep 2001 14:22:15 +0100 Subject: [hostmaster-staff] Re: MIR proposal References: <0109281205410A.16602@ewe.noc.u-net.net> <5.1.0.14.2.20010928150257.03329bf0@imap.ripe.net> Message-ID: <034501c14820$970d9e50$2e04bf3e@eu.frd.uu.net> Thanks for your reply Adrian, beginning to think i was the only one really needing this structure. I hope the details of this proposal are taking into consideration the need for bigger contiguous space allocations and not just the ability to sub allocate. Look forward to the details of the proposal. Regards Stephen Burley UUNET EMEA Hostmaster SB855-RIPE ----- Original Message ----- From: "Nurani Nimpuno" To: ; "Adrian Bool" Cc: Sent: Friday, September 28, 2001 2:05 PM Subject: Re: [hostmaster-staff] Re: MIR proposal > Yes indeed. > We will send out a mail later today with the details of this proposal. > > Kind regards, > > Nurani Nimpuno > RIPE NCC > > At 14:21 28/09/01 +0200, Berislav Todorovic wrote: > >On Fri, 28 Sep 2001, Adrian Bool wrote: > > > > >> i.e We should should be able to apply for more IP space once we have > > >> sub-allocated 80% of our allocation to our in-country networks - > > natuarally > > >> in a responsible manner, according to the same rules that an RIR would > > >> allocate space to these in-country networks. > > > >Actually, there was a proopsal for introducing "status: LIR-ALLOCATED", that > >should allow such a thing. It's under implementation. > > > >Any news on the progress of that? > > > >Regards, > >Beri > > > >--------- Berislav Todorovic, Senior NOC Specialist -------- > >------- KPNQwest N.V. - IP NOC (formerly EUnet NOC) ------ > >---- Wilhelmina van Pruisenweg 78, 2595 AN Den Haag, NL ---- > >--- Phone: +31-70-379-3990; Mobile: +31-651-333-641 --- > >-- Email: beri at kpnqwest.net <=> beri at EU.net -- > >--- _ _ ____ _ .--. ____ ____ __/_ --- > >----- /__/ /___/ /\ / / / | / /___/ /___ / ------ > >------ _/ \_ / _/ \/ (__.\ |/\/ /___ ____/ (__. ----- > From nurani at ripe.net Fri Sep 28 19:48:41 2001 From: nurani at ripe.net (Nurani Nimpuno) Date: Fri, 28 Sep 2001 19:48:41 +0200 (CEST) Subject: LIR-PARTITIONED proposal (originally LIR-ALLOCATED) Message-ID: 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.html) 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.html 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 | | Internet Address Policy Manager | | RIPE Network Co-ordination Centre | | http://www.ripe.net | *--------------------------------------------------------* From sabrina at ripe.net Sat Sep 29 16:55:14 2001 From: sabrina at ripe.net (Sabrina Waschke) Date: Sat, 29 Sep 2001 16:55:14 +0200 Subject: Initial PA Allocation Criteria In-Reply-To: Message from "Hans Petter Holen" of "Wed, 11 Jul 2001 17:00:27 +0200." <127701c10a1a$38c53400$b90000c1@hph> Message-ID: <200109291455.f8TEtFv23037@birch.ripe.net> Dear all, The RIPE NCC is going to implement the new policy "Criteria for Initial /20 PA Allocation" on November, 1st, 2001. (The consultation of our lawyers resulted in a delay for this implementation, apologies for that.) Regards, Sabrina Waschke -- o------------------------------------------o | Sabrina Waschke sabrina at ripe.net | | Registration Services Operations Manager | | | | RIPE NCC tel +31 20 535 4444 | | www.ripe.net fax +31 20 535 4445 | o------------------------------------------o "Hans Petter Holen" writes: * Dear all, * At the last lir-wg meeting there was a clear consensus that a criteria * for setting up an LIR and receiving the initial allocation was needed. * After a good discussion on the mailinglist there aconclusion has been * proposed. * * With the limited feedback received on the last attempt to call for closure, * I would like to look back to the principle in RFC 2050 and RIPE-185 * stating 25% immediate usage and 50% usage within a year, which * is in line with the proposal of requiring a new LIR to demonstrate previous * usage of a /22 (25% of a /20) or demonstrate immediate need for a * /22 (25% of a /20). * * I hereby propose to this wg that we declare rough consensus on this * proposal, and that we adapt this new criteria as new policy to be * effective from some future date to be suggested by the RIPE NCC. * * My observation is that while we still have some disagreement on the effect * this will have on start up on new LIRs I think the community needs to * balance the negative effect possible renumbering will have on a new LIR * to be, vs. the positive effect slowing down the growth of new LIRs will * have on the service level from the RIPE NCC and the global routing table. * * Sincerely, * Hans Petter * * ----- Original Message ----- * From: "RIPE NCC Staff" * To: * Sent: Friday, June 15, 2001 5:06 PM * Subject: Initial PA Allocation Criteria * * * | Dear all, * | * | Further to my mail on PA Allocation criteria (see below), here follows * | a concrete proposal, including details of the actual criteria to be * | determined. Very little feedback was received on the last mail asking * | for input on the actual details of such criteria. Therefore, in order * | to move forward and establish the details of these criteria, please * | find below a clear proposal of criteria for the initial PA Allocation * | received by a newly established Local IR. * | * | Proposed Criteria for Initial /20 PA Allocation * | ----------------------------------------------- * | The Local IR is required to: * | * | - Demonstrate previous efficient utilisation of a /22 (1024 * | addresses). * | * | Or * | * | - Demonstrate immediate need for a /22 * | * | Renumbering: * | If current address space held by the Local IR amounts to a /22 or * | less, the Local IR is required to renumber that address space into the * | PA Allocation it will receive from the RIPE NCC. * | * | * | Can the lir-wg agree with the above proposed criteria? * | If no further objections are raised I would like to suggest that the * | RIPE NCC moves forward and implements this policy. * | * | Please let us know if you are not in agreement with the above. * | * | Kind regards, * | * | Nurani Nimpuno * | * | +------------------------------------+ * | | Nurani Nimpuno | * | | Internet Address Policy Manager | * | | RIPE Network Co-ordination Centre | * | | http://www.ripe.net | * | +------------------------------------+ * | * | * | * | ------- Forwarded Message * | * | Date: Fri, 01 Jun 2001 18:23:48 +0200 * | From: RIPE NCC Staff * | Resent-From: Nurani Nimpuno * | Sender: owner-lir-wg at ripe.net * | To: lir-wg at ripe.net * | Resent-To: ncc at ripe.net * | Subject: Summary: PA Allocation criteria discussion * | * | Dear all, * | * | Thank you for you input thus far in the discussion on portable address * | space. Many useful points have been raised on the matter of PI address * | space and PA Allocations. * | * | (The complete discussion can be read at: * | http://www.ripe.net/ripe/mail-archives/lir-wg/current/msg00130.html) * | * | Below is an attempt to summarise the discussion so far: * | * | The concept of smaller allocations (than current /20) was initially * | brought but the majority felt that this was not a realistic * | option. The comments showed concern about the exponential growth in * | the routing table and it was believed that smaller allocations would * | further contribute to this growth. There was consequently further * | discussion on how the RIR policies can prevent/reduce this through * | sensible address allocation/assignment criteria. * | * | On the subject of PI assignments, related to the current growth in the * | routing table, it was agreed that PI assignments should (as current * | policy states) be based on need and not routability. It was further * | stated that end users should be discouraged from multi-homing with * | globally visible address space. Some participants of the discussion * | argued for a complete discontinuation of PI. * | * | Most contributors agreed that /20 PA Allocations should be given to * | organisations who wish to further assign addresses to customers / * | end-users from their PA block. PA Allocations should not be made to * | organisations to satisfy pure multi-homing / independence needs. A set * | of criteria should therefore be determined to clarify this. * | * | Lastly, the majority agreed that the PA Allocation criteria should be * | based on previous efficient utilisation. There was further discussion * | with regards to the size of the efficiently utilised address space the * | requestor needs to demonstrate. The prefix sizes /22 and /21 were * | briefly discussed. * | * | If the community believes that this is a just summary of the * | discussion, I wish to move forward and determine the details of such * | criteria, through presenting a few very concrete discussion points. * | * | I would like your opinion on the following: * | * | 1. Do you agree on the following criteria to be set: * | * | The requesting organisation need to show * | - Demonstrated efficient utilisation of a /xx * | or * | - Immediate need for a /xx ? * | * | 2. If qualifying through the criterion of demonstrated efficient * | utilisation of address space, should the requestor need to * | demonstrate efficient utilisation of * | A. /22 * | or * | B. /21 ? * | * | 3. If qualifying through the criterion of demonstrated immediate * | need, should the requestor need to demonstrate an immediate * | need of a * | A. /22 * | or * | B. /21? * | * | 4. Should the requesting organisation be required to renumber * | depending on the sizes of its current aggregates? * | * | 4A. If so, what is a reasonable size of the smallest aggregate * | that an organisation would be required to renumber? * | * | * | I am looking forward to your input on these concrete points. * | * | Kind regards, * | * | Nurani Nimpuno * | RIPE NCC * | * | * | * | * | * | * | * | * | * | ------- End of Forwarded Message * | * | * *