From michael.dillon at bt.com Sun Jul 1 13:38:34 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Sun, 1 Jul 2007 12:38:34 +0100 Subject: [address-policy-wg] RE: [ppml] [GLOBAL-V6] How to get a IPv6 /32 the cheap way: go to AFRINIC In-Reply-To: <467BEC67.5080307@spaghetti.zurich.ibm.com> References: <467BDA31.4030607@spaghetti.zurich.ibm.com><200706221526.46024.aalain@trstech.net> <467BEC67.5080307@spaghetti.zurich.ibm.com> Message-ID: > I've sent it to all the RIR lists as it affects global policy > decisions: that a single RIR is acting in their own good > without even having asked their own membership about this situation. In general, when there are no explicit rules for appealing decisions of some group, the accepted appeal process is to begin by appealing directly to the group which made the disputed decision. The next step is to appeal to whichever body oversees that group. And so on. In this case, has an appeal been made to the AfriNIC hostmasters who made the allocation? Has an appeal already been made to the AfriNIC board of directors? Has an appeal been made to the AfriNIC membership? Has an appeal been made to the NRO directly? If not, then I don't see that this issue is relevant to ARIN or RIPE. Until the groups listed above have been given the opportunity to deal with the issue, ARIN and RIPE have no role in this. In addition, the appeal must be done sequentially, i.e. the person appealing the issue must allow a reasonable time for the issue to be considered before escalating the appeal to the next level. My sense is that none of this was done, and the appeal is being broadcast everywhere at once in an attempt to sling mud. This is not acceptable. And yes, Africa is a special case. It is a very large area in which the telecommunications structure is very complex, unlike Europe where the complainant lives. Wars and political disputes as well as hostile environments mean that all levels of the network from physical upwards, will have so-called "waste" which does not exist in Europe. That includes IP addressing. In this case AfriNIC is not conveniently located in one large well-connected city as in Europe or North America. Instead it is in 3 widely separated locations where you simply cannot connect by running three private lines. --Michael Dillon From michael.dillon at bt.com Tue Jul 3 08:01:36 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 3 Jul 2007 07:01:36 +0100 Subject: [address-policy-wg] 2006-02 Last Call for Comments (IPv6 Address Allocation and Assignment Policy) In-Reply-To: <3579DE61-A788-4FD0-854C-3EEFEFBE9931@icann.org> References: <3579DE61-A788-4FD0-854C-3EEFEFBE9931@icann.org> Message-ID: > So if an organisation planned to connect eight internal sites > through a single external connection they should receive a > /32 and not a /45 or /44? I believe that they should receive 8 /48s from their ISP. I also think that it would be beneficial to both ISP and customer to assign an aggregatable block of 8. In future, those eight sites could end up with separate Internet connections either through an architecture change or through divestment. When a company sells a site, it is like a slow motion version of mobile Internet. But, since an organization with a single external connection is not an ISP, they should not receive a /32. In general, /32s should be for organizations with steadily growing networks and also a few critical infrastructure types of organization which needs the operational characteristics of an ISP allocation. --Michael Dillon From Woeber at CC.UniVie.ac.at Wed Jul 4 19:56:07 2007 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 04 Jul 2007 17:56:07 +0000 Subject: [address-policy-wg] 2006-02 Last Call for Comments (IPv6 Address Allocation and Assignment Policy) In-Reply-To: References: <3579DE61-A788-4FD0-854C-3EEFEFBE9931@icann.org> Message-ID: <468BDF37.7030404@CC.UniVie.ac.at> michael.dillon at bt.com wrote: [...] > > But, since an organization with a single external connection is not an > ISP How, why and when did you arrive at that conclusion? And for which definition of ISP? And for which definition of external? > they should not receive a /32. In general, /32s should be for > organizations with steadily growing networks and also a few critical > infrastructure types of organization which needs the operational > characteristics of an ISP allocation. > > --Michael Dillon Wilfried From ernest at afrinic.net Thu Jul 12 15:24:02 2007 From: ernest at afrinic.net (Ernest Byaruhanga (AfriNIC)) Date: Thu, 12 Jul 2007 17:24:02 +0400 Subject: [address-policy-wg] IPv6 PI policy implemented Message-ID: <46962B72.8040703@afrinic.net> Dear Colleagues, Please note that AfriNC has implemented the following policy: "IPv6 Provider Independent (PI) Assignment for End-Sites" http://www.afrinic.net/docs/policies/afpol-v6200701.htm We have consequently as of today started making /48 PI assignments from the following block: 2001:43f8::/29 You may need to adjust any filters in place accordingly. For more information, please see: http://www.afrinic.net/Registration/afsup-ipv6pi-assignments.htm Regards, Ernest AfriNIC From filiz at ripe.net Thu Jul 12 17:10:29 2007 From: filiz at ripe.net (Filiz Yilmaz) Date: Thu, 12 Jul 2007 17:10:29 +0200 Subject: [address-policy-wg] 2006-02 Proposal Accepted (IPv6 Address Allocation and Assignment Policy) Message-ID: <20070712151029.AE53F2F583@herring.ripe.net> PDP Number: 2006-02 IPv6 Address Allocation and Assignment Policy Dear Colleagues, Consensus has been reached on the proposal described in 2006-02 and it is accepted by the RIPE community. This proposal is to change the IPv6 Initial Allocation criteria and the End Site definition in the "IPv6 Address Allocation and Assignment Policy". You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2006-02.html We will implement this new policy in approximately three weeks and notify you when it becomes effective. Thank you for your input. Regards, Filiz Yilmaz RIPE NCC Policy Development Officer From filiz at ripe.net Mon Jul 16 14:08:44 2007 From: filiz at ripe.net (Filiz Yilmaz) Date: Mon, 16 Jul 2007 14:08:44 +0200 Subject: [address-policy-wg] 2007-05 Discussion Period extended until 13 August 2007 (IPv6 ULA-Central) Message-ID: <20070716120844.5F1C52F5A6@herring.ripe.net> PDP Number: 2007-05 IPv6 ULA-Central Dear Colleagues The Discussion Period for the proposal described in 2007-05 has been extended until 13 August 2007. This policy is intended to allow the assignment of IPv6 blocks within the so-called 'Centrally Assigned Unique Local IPv6 Unicast Addresses' to organisations or individuals requiring it. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2007-05.html We encourage you to review this policy proposal and send your comments to . Regards Filiz Yilmaz RIPE NCC Policy Development Officer From rogerj at jorgensen.no Mon Jul 16 14:20:36 2007 From: rogerj at jorgensen.no (Roger Jorgensen) Date: Mon, 16 Jul 2007 14:20:36 +0200 (CEST) Subject: [address-policy-wg] 2007-05 Discussion Period extended until 13 August 2007 (IPv6 ULA-Central) In-Reply-To: <20070716120844.5F1C52F5A6@herring.ripe.net> References: <20070716120844.5F1C52F5A6@herring.ripe.net> Message-ID: Hi, this entire proposal should have been terminated until the ipv6-wg @ ietf have finished their work. On Mon, 16 Jul 2007, Filiz Yilmaz wrote: > > PDP Number: 2007-05 > IPv6 ULA-Central > > Dear Colleagues > > The Discussion Period for the proposal described in 2007-05 has been > extended until 13 August 2007. > > This policy is intended to allow the assignment of IPv6 blocks > within the so-called 'Centrally Assigned Unique Local IPv6 Unicast > Addresses' to organisations or individuals requiring it. > > You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2007-05.html > > We encourage you to review this policy proposal and send your comments > to . > > Regards > > Filiz Yilmaz > RIPE NCC > Policy Development Officer > > -- ------------------------------ Roger Jorgensen | - ROJO9-RIPE - RJ85P-NORID roger at jorgensen.no | - IPv6 is The Key! ------------------------------------------------------- From michael.dillon at bt.com Mon Jul 16 14:31:48 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 16 Jul 2007 13:31:48 +0100 Subject: [address-policy-wg] 2007-05 Discussion Period extended until 13 August 2007 (IPv6 ULA-Central) In-Reply-To: <20070716120844.5F1C52F5A6@herring.ripe.net> References: <20070716120844.5F1C52F5A6@herring.ripe.net> Message-ID: > The Discussion Period for the proposal described in 2007-05 > has been extended until 13 August 2007. > > This policy is intended to allow the assignment of IPv6 > blocks within the so-called 'Centrally Assigned Unique Local > IPv6 Unicast Addresses' to organisations or individuals requiring it. > > You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2007-05.html This proposal should be rejected, not discussed. In fact, there are two different proposals being discussed in the IETF for some form of centrally-registered ULA addressing. Both proposals are in draft form and there is no way to predict which one will eventually be accepted or what kinds of changes will be made to the drafts before they become RFCs. This is important, because some of the changes have to do with how RIRs receive blocks of ULA addresses to register, and if that is not yet decided by the IETF, then there is no way for RIPE to register such addresses because RIPE won't have any such addresses to register. In addition, RIPE is part of a political system in which different responsibilities are placed on RIPE, IANA, ICANN, NRO and the IETF. This proposal goes beyond RIPE's responsibilities and attempts to usurp the responsibilities of IANA and the IETF. This is a BAD BAD thing to do, because if RIPE no longer adheres to the social contract, then there is no reason for the other organizations to continue working with RIPE. The whole system depends on cooperation, and this proposal does not demonstrate cooperation. --Michael Dillon From md at Linux.IT Mon Jul 16 20:35:05 2007 From: md at Linux.IT (Marco d'Itri) Date: Mon, 16 Jul 2007 20:35:05 +0200 Subject: [address-policy-wg] 2007-05 Discussion Period extended until 13 August 2007 (IPv6 ULA-Central) In-Reply-To: References: <20070716120844.5F1C52F5A6@herring.ripe.net> Message-ID: <20070716183505.GA3251@bongo.bofh.it> On Jul 16, Roger Jorgensen wrote: > this entire proposal should have been terminated until the ipv6-wg @ ietf > have finished their work. I agree. -- ciao, Marco -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From gert at space.net Mon Jul 16 21:27:22 2007 From: gert at space.net (Gert Doering) Date: Mon, 16 Jul 2007 21:27:22 +0200 Subject: [address-policy-wg] 2007-05 Discussion Period extended until 13 August 2007 (IPv6 ULA-Central) In-Reply-To: References: <20070716120844.5F1C52F5A6@herring.ripe.net> Message-ID: <20070716192722.GL69215@Space.Net> Hi, On Mon, Jul 16, 2007 at 01:31:48PM +0100, michael.dillon at bt.com wrote: > > The Discussion Period for the proposal described in 2007-05 > > has been extended until 13 August 2007. [..] > In addition, RIPE is part of a political system in which different > responsibilities are placed on RIPE, IANA, ICANN, NRO and the IETF. This > proposal goes beyond RIPE's responsibilities and attempts to usurp the > responsibilities of IANA and the IETF. This is a BAD BAD thing to do, > because if RIPE no longer adheres to the social contract, then there is > no reason for the other organizations to continue working with RIPE. The > whole system depends on cooperation, and this proposal does not > demonstrate cooperation. Please come down from your soap box again. The whole thing behind the proposal was "get the process going again", and it isn't unheard of to do work in parallel in the RIRs and in the IETF (see the 32 bit AS# policy). The reason for extending the discussion period is *specifically* to see what will happen in the IETF, and then decide how to go ahead with this proposal. If the IETF goes for "yes, ULA-C is a good thing", then we can adapt this proposal accordingly - if they go for "ULA-C is not going to happen! never ever!" Jordi can withdraw the proposal, and it will be history. Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 113403 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From rogerj at jorgensen.no Mon Jul 16 23:09:12 2007 From: rogerj at jorgensen.no (Roger Jorgensen) Date: Mon, 16 Jul 2007 23:09:12 +0200 (CEST) Subject: [address-policy-wg] 2007-05 Discussion Period extended until 13 August 2007 (IPv6 ULA-Central) In-Reply-To: <20070716192722.GL69215@Space.Net> References: <20070716120844.5F1C52F5A6@herring.ripe.net> <20070716192722.GL69215@Space.Net> Message-ID: On Mon, 16 Jul 2007, Gert Doering wrote: > > The reason for extending the discussion period is *specifically* to > see what will happen in the IETF, and then decide how to go ahead with > this proposal. If the IETF goes for "yes, ULA-C is a good thing", then > we can adapt this proposal accordingly - if they go for "ULA-C is not > going to happen! never ever!" Jordi can withdraw the proposal, and it > will be history. The point is that what are being discussed are quite different from what the current probposal ( http://www.ripe.net/ripe/policies/proposals/2007-05.html ) says. It is probably that both the name, size and usage will probably be different. It is in short a quite different scenario. It will probably also outline a different assignment regime from the ULA-block too. -- ------------------------------ Roger Jorgensen | - ROJO9-RIPE - RJ85P-NORID roger at jorgensen.no | - IPv6 is The Key! ------------------------------------------------------- From jordi.palet at consulintel.es Mon Jul 16 23:46:58 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Mon, 16 Jul 2007 23:46:58 +0200 Subject: [address-policy-wg] 2007-05 Discussion Period extended until 13 August 2007 (IPv6 ULA-Central) In-Reply-To: Message-ID: Nobody knows what will be the result of the IETF process, and this is why I can't provide a new version of the proposal at this stage or decide if need to be withdrawn or whatever, so I need to put it "on-hold". If you read the PDP, you will realize that it doesn't allow a proposal to be put "on-hold", once the discussion phase is over, you either go for a new version, the review phase, or extend the discussion period. This discussion period extension works as a kind of "on-hold", especially if the author and/or other folks avoid discussing it, and that's what I'm doing being silent :-) Regards, Jordi > De: Roger Jorgensen > Responder a: > Fecha: Mon, 16 Jul 2007 23:09:12 +0200 (CEST) > Para: Gert Doering > CC: , > Asunto: Re: [address-policy-wg] 2007-05 Discussion Period extended until 13 > August 2007 (IPv6 ULA-Central) > > On Mon, 16 Jul 2007, Gert Doering wrote: > >> >> The reason for extending the discussion period is *specifically* to >> see what will happen in the IETF, and then decide how to go ahead with >> this proposal. If the IETF goes for "yes, ULA-C is a good thing", then >> we can adapt this proposal accordingly - if they go for "ULA-C is not >> going to happen! never ever!" Jordi can withdraw the proposal, and it >> will be history. > > The point is that what are being discussed are quite different from what > the current probposal ( > http://www.ripe.net/ripe/policies/proposals/2007-05.html ) says. It is > probably that both the name, size and usage will probably be different. It > is in short a quite different scenario. > > It will probably also outline a different assignment regime from the > ULA-block too. > > > > -- > > ------------------------------ > Roger Jorgensen | - ROJO9-RIPE - RJ85P-NORID > roger at jorgensen.no | - IPv6 is The Key! > ------------------------------------------------------- > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From filiz at ripe.net Tue Jul 17 16:06:45 2007 From: filiz at ripe.net (Filiz Yilmaz) Date: Tue, 17 Jul 2007 16:06:45 +0200 Subject: [address-policy-wg] 2007-04 Last Call for Comments (IANA Policy for Allocation of ASN Blocks to RIRs) Message-ID: <20070717140645.575912F583@herring.ripe.net> PDP Number: 2007-04 IANA Policy for Allocation of ASN Blocks to RIRs Dear Colleagues The proposal described in 2007-04 is now at its Concluding Phase. This proposal is to have a global policy for the Regional Internet Registries (RIRs) to receive blocks of Autonomous System Numbers (ASNs) from the Internet Assigned Numbers Authority (IANA). You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2007-04.html Please e-mail any final comments about this proposal to address-policy-wg at ripe.net before 14 August 2007. Regards Filiz Yilmaz RIPE NCC Policy Development Officer From policy-announce at ripe.net Tue Jul 17 16:07:16 2007 From: policy-announce at ripe.net (policy-announce at ripe.net) Date: Tue, 17 Jul 2007 16:07:16 +0200 (CEST) Subject: [address-policy-wg] 2007-04 Last Call for Comments (IANA Policy for Allocation of ASN Blocks to RIRs) In-Reply-To: <20070717140645.575912F583@herring.ripe.net> References: <20070717140645.575912F583@herring.ripe.net> Message-ID: <20070717140716.573425083E@mail-maint.ode.cdnet.dk> English version further down. Modtageren til mailadressen: policy-announce at ripe.net er flyttet. Du skal i fremtiden sende mail til (Husk at opdatere din kontaktliste): Mvh. Postmaster Canal Digital Danmark IT A/S ----------------------------- English version The recipient: policy-announce at ripe.net has moved. You can reach the recipient by this mailadress instead (Remember to update your contacts): Regards, Postmaster Canal Digital Danmark IT A/S From marc.van.selm at nc3a.nato.int Thu Jul 19 08:17:05 2007 From: marc.van.selm at nc3a.nato.int (Marc van Selm) Date: Thu, 19 Jul 2007 08:17:05 +0200 Subject: [address-policy-wg] IPv6 PI policy implemented In-Reply-To: <46962B72.8040703@afrinic.net> References: <46962B72.8040703@afrinic.net> Message-ID: <200707190817.06055.marc.van.selm@nc3a.nato.int> I'm wondering. ARIN and AfriNIC assign PI space for end-sites. They both do /48 (ARIN also does a /48 as I remember correctly). Isn't the discussion in the RIPE area not getting a bit too long and taken over by events. As an example, NATO can also just as easily apply for space from ARIN (although RIPE covers more of NATO's area of operation as it seems). Something similar would be true for many International customers interested in PI. Just wondering... Shouldn't we just give up our strong feelings and face the fact that other bits of the world have already acted, just do it and coordinate a global route filter policy etc so that things actually work? Marc van Selm On Thursday 12 July 2007 15:24, Ernest Byaruhanga (AfriNIC) wrote: > Dear Colleagues, > > Please note that AfriNC has implemented the following policy: > > "IPv6 Provider Independent (PI) Assignment for End-Sites" > http://www.afrinic.net/docs/policies/afpol-v6200701.htm > > We have consequently as of today started making /48 PI assignments > from the following block: > > 2001:43f8::/29 > > You may need to adjust any filters in place accordingly. > > For more information, please see: > > http://www.afrinic.net/Registration/afsup-ipv6pi-assignments.htm > > Regards, > > Ernest > AfriNIC -- -- This mail is personal -- All statements in this mail are made from my own personal perspective and do not necessarily reflect my employer's opinions or policies. From randy at psg.com Thu Jul 19 08:40:53 2007 From: randy at psg.com (Randy Bush) Date: Wed, 18 Jul 2007 20:40:53 -1000 Subject: [address-policy-wg] IPv6 PI policy implemented In-Reply-To: <200707190817.06055.marc.van.selm@nc3a.nato.int> References: <46962B72.8040703@afrinic.net> <200707190817.06055.marc.van.selm@nc3a.nato.int> Message-ID: <469F0775.9050501@psg.com> > As an example, NATO can also just as easily apply for space from ARIN do you think nato wants a /48? they want a /32 and will then chop it up and pollute the routing table. randy From slz at baycix.de Thu Jul 19 09:04:25 2007 From: slz at baycix.de (Sascha Lenz) Date: Thu, 19 Jul 2007 09:04:25 +0200 Subject: [address-policy-wg] IPv6 PI policy implemented In-Reply-To: <200707190817.06055.marc.van.selm@nc3a.nato.int> References: <46962B72.8040703@afrinic.net> <200707190817.06055.marc.van.selm@nc3a.nato.int> Message-ID: <469F0CF9.4070500@baycix.de> Hi, Marc van Selm schrieb: > I'm wondering. ARIN and AfriNIC assign PI space for end-sites. They both > do /48 (ARIN also does a /48 as I remember correctly). Isn't the discussion > in the RIPE area not getting a bit too long and taken over by events. > > As an example, NATO can also just as easily apply for space from ARIN > (although RIPE covers more of NATO's area of operation as it seems). > Something similar would be true for many International customers interested > in PI. > > Just wondering... Shouldn't we just give up our strong feelings and face the > fact that other bits of the world have already acted, just do it and > coordinate a global route filter policy etc so that things actually work? [...] yes, "we" should do that, please send some troops to repacify the enemy dorkheads, thank you :-) A while ago, i made a rather simple suggestion as a reaction to Jordi's latest incarnation of his PI-policy proposal (which is - sorry- stupid). The only concerns i've seen about it so far was that one might be a bit more precise about the wording. Since then i haven't seen much activitiy about the proposal anymore. I feel the urge to move on here. The PDP is getting really stupid at this point (>1,5 years?). If nothing positively happens with 2006-01 soon, i tend to hand in my own proposal and call for NATO air support :-) -- ======================================================================== = Sascha Lenz SLZ-RIPE slz at baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ======================================================================== From marc.van.selm at nc3a.nato.int Thu Jul 19 09:44:40 2007 From: marc.van.selm at nc3a.nato.int (Marc van Selm) Date: Thu, 19 Jul 2007 09:44:40 +0200 Subject: [address-policy-wg] IPv6 PI policy implemented In-Reply-To: <469F0775.9050501@psg.com> References: <46962B72.8040703@afrinic.net> <200707190817.06055.marc.van.selm@nc3a.nato.int> <469F0775.9050501@psg.com> Message-ID: <200707190944.40630.marc.van.selm@nc3a.nato.int> On Thursday 19 July 2007 08:40, Randy Bush wrote: > > As an example, NATO can also just as easily apply for space from ARIN > > do you think nato wants a /48? > they want a /32 and will then chop it up and pollute the routing table. Yes I guess they would and I doubt that NATO would go that way (note I'm not speaking for NATO today but on personal title here). The LIR way is probably the way to go. But on the other hand, how many sub-networks does NATO have? (A question that I won't answer but I guess one can assume that no potential PI customer has more than 65536 subnets (etc) today.) On Thursday 19 July 2007 09:04, Sascha Lenz wrote: > yes, "we" should do that, please send some troops to repacify the enemy > dorkheads, thank you That approach is just what I question. Not to be cinical but the point I'm making is: If the RIPE region is against PI but PI is available from other sources without too much hassle. Do we expect that those that want it will not go for PI just because RIPE NCC does not offer it? Personally, if I'm internationally oriented, I'd go to ARIN or AfriNIC (depending where I have offices) and just get what I want. This makes that the RIPE community decides on PI less relevant. My point is, aren't we running the risk of being bypassed left and right just because we don't like it? If we do aren't we running the risk that being bypassed means that we can't influence it because other parts of the world already have decided for us. I'm not trying to defend PI because I like it (I think it is unavoidable but that's not why I write this). I'm trying to say that the world seems to be moving on while we are discussing. IPv6 is a global commodity that can be procured anywhere for this scale of user. So if we don't provide it people buy it from our neighbor and we still have the "enemy" on the net without the posibility to have a say in it. Best regards, Marc PS can we keep the discussion a bit professional and leave words like the "enemy dorkheads" out of this? -- Marc van Selm NATO C3 Agency CIS Division E-mail: marc.van.selm at nc3a.nato.int (PGP capable) From randy at psg.com Thu Jul 19 09:48:55 2007 From: randy at psg.com (Randy Bush) Date: Wed, 18 Jul 2007 21:48:55 -1000 Subject: [address-policy-wg] IPv6 PI policy implemented In-Reply-To: <200707190944.40630.marc.van.selm@nc3a.nato.int> References: <46962B72.8040703@afrinic.net> <200707190817.06055.marc.van.selm@nc3a.nato.int> <469F0775.9050501@psg.com> <200707190944.40630.marc.van.selm@nc3a.nato.int> Message-ID: <469F1767.5020502@psg.com> > That approach is just what I question. Not to be cinical but the point I'm > making is: If the RIPE region is against PI but PI is available from other > sources without too much hassle. the lowest common denominator argument leads to heat death of universe. alcoholics seek friends who are further down than they are so they don't see how far down they have gone. i suggest coming up with a good policy for ripe region, not seeing how low we can all go. randy From gert at space.net Thu Jul 19 10:24:00 2007 From: gert at space.net (Gert Doering) Date: Thu, 19 Jul 2007 10:24:00 +0200 Subject: [address-policy-wg] IPv6 PI policy implemented In-Reply-To: <469F0CF9.4070500@baycix.de> References: <46962B72.8040703@afrinic.net> <200707190817.06055.marc.van.selm@nc3a.nato.int> <469F0CF9.4070500@baycix.de> Message-ID: <20070719082400.GY69215@Space.Net> Hi, On Thu, Jul 19, 2007 at 09:04:25AM +0200, Sascha Lenz wrote: > Since then i haven't seen much activitiy about the proposal anymore. Well, one of the things that's delaying the "PI activities" (IPv4 and IPv6) is the dependency on the 2007-01 proposal (contractual relationship with PI/AS holders). Unless we get *that* one sorted out, it's hard to make meaningful progress with the individual proposals that all depend on "but we want the number holder to have a contract with RIPE!". I'm confident that we can see some progress on 2007-01 before the next RIPE meeting, and maybe structure the next APWG meeting a bit differently - not spending all the time discussing individual proposals in depth, but using some of the time to get a more "global" discussion on which direction the journey should take, and then break that down to specific proposals. Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 113403 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From marc.van.selm at nc3a.nato.int Thu Jul 19 10:42:51 2007 From: marc.van.selm at nc3a.nato.int (Marc van Selm) Date: Thu, 19 Jul 2007 10:42:51 +0200 Subject: [address-policy-wg] IPv6 PI policy implemented In-Reply-To: <20070719082400.GY69215@Space.Net> References: <46962B72.8040703@afrinic.net> <469F0CF9.4070500@baycix.de> <20070719082400.GY69215@Space.Net> Message-ID: <200707191042.51808.marc.van.selm@nc3a.nato.int> On Thursday 19 July 2007 10:24, Gert Doering wrote: > Hi, > > On Thu, Jul 19, 2007 at 09:04:25AM +0200, Sascha Lenz wrote: > > Since then i haven't seen much activitiy about the proposal anymore. > > Well, one of the things that's delaying the "PI activities" (IPv4 and > IPv6) is the dependency on the 2007-01 proposal (contractual relationship > with PI/AS holders). > > Unless we get *that* one sorted out, it's hard to make meaningful progress > with the individual proposals that all depend on "but we want the number > holder to have a contract with RIPE!". That makes perfect sense Gert. Regards, Marc van Selm -- -- This mail is personal -- All statements in this mail are made from my own personal perspective and do not necessarily reflect my employer's opinions or policies. From jordi.palet at consulintel.es Thu Jul 19 10:53:30 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Thu, 19 Jul 2007 10:53:30 +0200 Subject: [address-policy-wg] IPv6 PI policy implemented In-Reply-To: <469F0CF9.4070500@baycix.de> Message-ID: Hi Sascha, I replied to your comments with some new questions, but never saw your response, not sure if I missed something. I'm trying to submit a new version during the next couple of days, so any new inputs are always welcome ! Regards, Jordi > De: Sascha Lenz > Organizaci?n: BayCIX GmbH > Responder a: > Fecha: Thu, 19 Jul 2007 09:04:25 +0200 > Para: Marc van Selm > CC: > Asunto: Re: [address-policy-wg] IPv6 PI policy implemented > > Hi, > > Marc van Selm schrieb: >> I'm wondering. ARIN and AfriNIC assign PI space for end-sites. They both >> do /48 (ARIN also does a /48 as I remember correctly). Isn't the discussion >> in the RIPE area not getting a bit too long and taken over by events. >> >> As an example, NATO can also just as easily apply for space from ARIN >> (although RIPE covers more of NATO's area of operation as it seems). >> Something similar would be true for many International customers interested >> in PI. >> >> Just wondering... Shouldn't we just give up our strong feelings and face the >> fact that other bits of the world have already acted, just do it and >> coordinate a global route filter policy etc so that things actually work? > [...] > > yes, "we" should do that, please send some troops to repacify the enemy > dorkheads, thank you :-) > > > > A while ago, i made a rather simple suggestion as a reaction to Jordi's > latest incarnation of his PI-policy proposal (which is - sorry- stupid). > The only concerns i've seen about it so far was that one might be a bit > more precise about the wording. > > Since then i haven't seen much activitiy about the proposal anymore. > > I feel the urge to move on here. The PDP is getting really stupid at > this point (>1,5 years?). > If nothing positively happens with 2006-01 soon, i tend to hand in my > own proposal and call for NATO air support :-) > > -- > ======================================================================== > = Sascha Lenz SLZ-RIPE slz at baycix.de = > = Network Operations = > = BayCIX GmbH, Landshut * PGP public Key on demand * = > ======================================================================== > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From jordi.palet at consulintel.es Thu Jul 19 11:08:13 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Thu, 19 Jul 2007 11:08:13 +0200 Subject: [address-policy-wg] IPv6 PI policy implemented In-Reply-To: <200707190944.40630.marc.van.selm@nc3a.nato.int> Message-ID: I guess in the case of NATO the new modifications to the existing policy, that removes the 200 customers and allows organizations being "ISPs" internally to the organization, is the right now for the NATO case. I recall indeed someone from NATO indicated that to me some months ago. Regards, Jordi > De: Marc van Selm > Responder a: > Fecha: Thu, 19 Jul 2007 09:44:40 +0200 > Para: > Asunto: Re: [address-policy-wg] IPv6 PI policy implemented > > On Thursday 19 July 2007 08:40, Randy Bush wrote: >>> As an example, NATO can also just as easily apply for space from ARIN >> >> do you think nato wants a /48? >> they want a /32 and will then chop it up and pollute the routing table. > > Yes I guess they would and I doubt that NATO would go that way (note I'm not > speaking for NATO today but on personal title here). The LIR way is probably > the way to go. But on the other hand, how many sub-networks does NATO have? > (A question that I won't answer but I guess one can assume that no potential > PI customer has more than 65536 subnets (etc) today.) > > > On Thursday 19 July 2007 09:04, Sascha Lenz wrote: >> yes, "we" should do that, please send some troops to repacify the enemy >> dorkheads, thank you > > That approach is just what I question. Not to be cinical but the point I'm > making is: If the RIPE region is against PI but PI is available from other > sources without too much hassle. Do we expect that those that want it will > not go for PI just because RIPE NCC does not offer it? Personally, if I'm > internationally oriented, I'd go to ARIN or AfriNIC (depending where I have > offices) and just get what I want. This makes that the RIPE community decides > on PI less relevant. My point is, aren't we running the risk of being > bypassed left and right just because we don't like it? If we do aren't we > running the risk that being bypassed means that we can't influence it because > other parts of the world already have decided for us. > > I'm not trying to defend PI because I like it (I think it is unavoidable but > that's not why I write this). I'm trying to say that the world seems to be > moving on while we are discussing. IPv6 is a global commodity that can be > procured anywhere for this scale of user. So if we don't provide it people > buy it from our neighbor and we still have the "enemy" on the net without the > posibility to have a say in it. > > Best regards, Marc > > PS can we keep the discussion a bit professional and leave words like the > "enemy dorkheads" out of this? > -- > Marc van Selm > NATO C3 Agency > CIS Division > E-mail: marc.van.selm at nc3a.nato.int (PGP capable) > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From marc.van.selm at nc3a.nato.int Thu Jul 19 11:46:04 2007 From: marc.van.selm at nc3a.nato.int (Marc van Selm) Date: Thu, 19 Jul 2007 11:46:04 +0200 Subject: [address-policy-wg] IPv6 PI policy implemented In-Reply-To: References: Message-ID: <200707191146.04923.marc.van.selm@nc3a.nato.int> On Thursday 19 July 2007 11:08, JORDI PALET MARTINEZ wrote: > I guess in the case of NATO the new modifications to the existing policy, > that removes the 200 customers and allows organizations being "ISPs" > internally to the organization, is the right now for the NATO case. I > recall indeed someone from NATO indicated that to me some months ago. > > Regards, > Jordi Yes Jordi, I'm Guilty as charged (I was that someone. I'm involved in IPv6 transition planning for NATO from a network architectural perspective.)! Yes I've talking about the "200 customer rule" before. It is all in the definition of a customer. To summarise, NATO has a service provisioning agency which could become a LIR. It serves to NATO Agencies and NATO operations. 200 customers requires creativity in defining what a customer is but it can be done. And I've tested that concept with Leo Vegoda at the time by submitting a proforma initial allocation request. Leo felt happy enough about it at the time. So that gave me a warm feeling that this bit of the IPv6 transition plan will fly (or can be made to fly). Indeed NATO's service provisioning agency would fit best into a LIR role but it could also work with PI space if it was provisioned in a *useful* way. (I won't go into the details of the NATO networks and potential links via or to the Internet but I do not foresee routing issues there). Best regards, Marc van Selm -- -- This mail is personal -- All statements in this mail are made from my own personal perspective and do not necessarily reflect my employer's opinions or policies. From alexlh at ripe.net Mon Jul 30 13:09:40 2007 From: alexlh at ripe.net (Alex Le Heux) Date: Mon, 30 Jul 2007 13:09:40 +0200 Subject: [address-policy-wg] 2007-06: New Policy Proposal (Global Policy for the Allocationof the Remaining IPv4 Address Space) Message-ID: PDP Number: 2007-06 Global Policy for the Allocation of the Remaining IPv4 Address Space Dear Colleagues, A new RIPE Policy has been proposed and is now available for discussion. This policy describes the process for the allocation of the remaining IPv4 space from IANA to the RIRs. When a minimum amount of available space is reached, an identical number of IPv4 allocation units (/8s) will be allocated from IANA to each RIR, replacing the current IPv4 allocation policy. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2007-06.html We encourage you to review this proposal and send your comments to before 27 August 2007. Best regards, Alex Le Heux RIPE NCC Policy Implementation Co-ordinator From alexlh at ripe.net Mon Jul 30 14:49:40 2007 From: alexlh at ripe.net (Alex Le Heux) Date: Mon, 30 Jul 2007 14:49:40 +0200 Subject: [address-policy-wg] 2006-02 Implementation: IPv6 Address Allocation and Assignment Policy Message-ID: <1F7A7961-30B5-4AF8-ACC3-618B7B29D745@ripe.net> [Apologies for duplicate emails] Dear Colleagues, We are pleased to announce that the policy proposed in 2006-02 "IPv6 Address Allocation and Assignment Policy" has been implemented. The RIPE NCC is now ready to accept requests for IPv6 address space under the new policy. The archived proposal can be found at: http://www.ripe.net/ripe/policies/proposals/2006-02.html The updated "IPv6 Address Allocation and Assignment Policy" is available at: http://www.ripe.net/ripe/docs/ripe-412.html The following RIPE documents have also been updated to reflect this policy implementation: Supporting Notes for the IPv6 First Allocation Request Form http://ripe.net/ripe/docs/ripe-413.html IPv6 First Allocation Request Form http://ripe.net/ripe/docs/ripe-414.html Best regards, Alex Le Heux RIPE NCC Policy Implementation Co-ordinator From alexlh at ripe.net Mon Jul 30 14:49:40 2007 From: alexlh at ripe.net (Alex Le Heux) Date: Mon, 30 Jul 2007 14:49:40 +0200 Subject: [address-policy-wg] [ncc-announce] 2006-02 Implementation: IPv6 Address Allocation and Assignment Policy Message-ID: <1F7A7961-30B5-4AF8-ACC3-618B7B29D745@ripe.net> [Apologies for duplicate emails] Dear Colleagues, We are pleased to announce that the policy proposed in 2006-02 "IPv6 Address Allocation and Assignment Policy" has been implemented. The RIPE NCC is now ready to accept requests for IPv6 address space under the new policy. The archived proposal can be found at: http://www.ripe.net/ripe/policies/proposals/2006-02.html The updated "IPv6 Address Allocation and Assignment Policy" is available at: http://www.ripe.net/ripe/docs/ripe-412.html The following RIPE documents have also been updated to reflect this policy implementation: Supporting Notes for the IPv6 First Allocation Request Form http://ripe.net/ripe/docs/ripe-413.html IPv6 First Allocation Request Form http://ripe.net/ripe/docs/ripe-414.html Best regards, Alex Le Heux RIPE NCC Policy Implementation Co-ordinator From rw at firstpr.com.au Mon Jul 30 15:30:37 2007 From: rw at firstpr.com.au (Robin Whittle) Date: Mon, 30 Jul 2007 23:30:37 +1000 Subject: [address-policy-wg] 2007-06: New Policy Proposal (Global Policy for the Allocationof the Remaining IPv4 Address Space) In-Reply-To: References: Message-ID: <46ADE7FD.5080303@firstpr.com.au> I believe that a substantial amount of the remaining IPv4 space should be put aside to be used with whichever new architecture is developed to deal with the routing and addressing problems discussed last year in the IAB RAWS workshop. That new architecture will be able to apply address space much more efficiently in terms of number of end-users, the proportion of IP addresses actually used, and the usefulness of the address space in terms of multihoming and portability without burdening the BGP routing system. This reservation - and perhaps operation of the new system - might best be done by the RIRs. I want to suggest this as part of a debate about how to make best use of the remaining fresh IPv4 space. The RAWS workshop report is: http://tools.ietf.org/html/draft-iab-raws-report http://www.iab.org/about/workshops/routingandaddressing/ Discussions are on the RAM list: http://www1.ietf.org/mail-archive/web/ram/current/ http://www1.ietf.org/mailman/listinfo/ram the IRTF Routing Research Group List: http://psg.com/lists/rrg/2007/ http://www.irtf.org/charter?gtype=rg&group=rrg and a small closed RADIR list with public archives: http://www1.ietf.org/mail-archive/web/radir/current/ http://www3.tools.ietf.org/group/radir/ The central Problem is most frequently summarised as something like: "There needs to be a way many more end-users can do multihoming, traffic engineering and have portable address space without requiring conventional PI space and without adding more advertisements and churn to the global BGP routing table." The urgency now is about IPv4, but IPv6 will have the same troubles whenever it is widely adopted. The solution is most likely to be in two forms, which are quite independent of each other. Firstly some moderate improvements to BGP's scalability and stability are likely to be made. Secondly there is likely to be some IP-level system involving a global network of Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs). These will enable multihoming and portability without involving BGP. The IP-level tunneling proposals to date are LISP-NERD, LISP-CONS, eFIT-APT and my own: Ivip. http://tools.ietf.org/html/draft-farinacci-lisp-01 http://tools.ietf.org/html/draft-lear-lisp-nerd-01 http://tools.ietf.org/html/draft-meyer-lisp-cons-01 http://tools.ietf.org/html/draft-jen-apt-00 http://www.cs.ucla.edu/~lixia/papers/07SIG_IP6WS.pdf http://www.firstpr.com.au/ip/ivip/ These proposals are all intended to apply both to IPv4 and IPv6, not require changes in hosts, and retain reachability from non-upgraded networks. While most of the people in this field are focused on the "multihoming etc. without BGP" problem, I make a direct causal linkage from the limitations of the BGP routing system to the clunky restrictions it places on address allocation (256 address granularity and "Maximise route aggregation!!!"), the consequent low proportion of advertised IPv4 addresses which are actually used and therefore leading to the rapid, premature "exhaustion" of IPv4 space. Each one of these four proposals listed above, if it could be made to work as intended, would enable much finer allocation of address space to end-users, down to single IP addresses (/64s for IPv6 probably). So once one of these systems is operational, IPv4 space will be able to be allocated to end-users in any size, from /32, /31 etc. through /24 etc. with portability, multihoming and no concern whatsoever for "route aggregation". BGP can only do it in /24 granularity - chunks of 256 addresses. Since something like this needs to be built in the next few years, I propose that a substantial amount of the remaining unallocated space be kept for the new system, which can then put it to work, in terms of numbers of end-users and in terms of actual utilisation of IP addresses, *far* more efficiently than BGP can use it. I think many people have become accustomed to the very low rates of utilisation of currently advertised portions of the 3.7 billion address IPv4 space, which is the direct cause of us running out of fresh space well before there are two or three billion IP addresses in use. I don't know how many are used now, but I think it is probably around 200 or maybe 300 million. I found about 108 million respond to ping, which I know has its limitations: http://www.firstpr.com.au/ip/host-density-per-prefix/ Here is my message which proposes some changes to the draft "Problem Statement" from RADIR: http://www1.ietf.org/mail-archive/web/ram/current/msg01773.html along these lines. It considers the IPv4 address shortage as part of the Problem - just as amenable to solution as the "multihoming without BGP" problem. I also think that a new ITR and fast mapping database architecture could provide a tremendous boost to mobile IP, for IPv4 and IPv6, with near optimal path lengths and without requiring changes in correspondent hosts. Of the current proposals, only Ivip could do this. Lack of mobility is not currently a "problem", but I think that since a global ITR network (as all the four IP-level proposals involve) could be used to drastically enhance mobility, that any new architecture should either do this from the start, or at least not preclude extensions in the future which do this. - Robin http://www.firstpr.com.au/ip/ivip/ From gert at space.net Mon Jul 30 17:43:02 2007 From: gert at space.net (Gert Doering) Date: Mon, 30 Jul 2007 17:43:02 +0200 Subject: [address-policy-wg] new policy proposal (reserve IPv4 space for new architecture) In-Reply-To: <46ADE7FD.5080303@firstpr.com.au> References: <46ADE7FD.5080303@firstpr.com.au> Message-ID: <20070730154301.GR69215@Space.Net> Hi, (I have changed the subject, as this is a different proposal from 2007-06!) On Mon, Jul 30, 2007 at 11:30:37PM +1000, Robin Whittle wrote: > I believe that a substantial amount of the remaining IPv4 space > should be put aside to be used with whichever new architecture is > developed to deal with the routing and addressing problems > discussed last year in the IAB RAWS workshop. This is going to be a tough one, for various reasons. - as this is a global change in the way all RIRs are supposed to operate, it needs to be made a global policy - which, in turn, means that all RIR constituencies need to agree to this proposal - which, in turn, means for the RIPE region that you need to submit a formal proposal to the PDP process (http://www.ripe.net/ripe/policies/proposals/index.html) and get consensus that this is the right way to proceed. Adding to this that the "new BGP" is likely not going to happen before the current IPv4 pool has run out, I'm pessimistic whether this proposal will find much support in the communities, or will be seen as "taking away the last remains of IPv4 from those who need/want it". Fortunately, I'm not to judge this, but just to steer the process... Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 113403 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From rgaglian at antel.net.uy Mon Jul 30 18:35:07 2007 From: rgaglian at antel.net.uy (Roque Gagliano) Date: Mon, 30 Jul 2007 13:35:07 -0300 Subject: [address-policy-wg] new policy proposal (reserve IPv4 space for new architecture) In-Reply-To: <20070730154301.GR69215@Space.Net> References: <46ADE7FD.5080303@firstpr.com.au> <20070730154301.GR69215@Space.Net> Message-ID: <1185813307.14995.37.camel@jessy.antel.net.uy> What about using the Class E for this use? Roque On Mon, 2007-07-30 at 17:43 +0200, Gert Doering wrote: > Hi, > > (I have changed the subject, as this is a different proposal from 2007-06!) > > > On Mon, Jul 30, 2007 at 11:30:37PM +1000, Robin Whittle wrote: > > I believe that a substantial amount of the remaining IPv4 space > > should be put aside to be used with whichever new architecture is > > developed to deal with the routing and addressing problems > > discussed last year in the IAB RAWS workshop. > > This is going to be a tough one, for various reasons. > > - as this is a global change in the way all RIRs are supposed to operate, > it needs to be made a global policy > > - which, in turn, means that all RIR constituencies need to agree to > this proposal > > - which, in turn, means for the RIPE region that you need to submit > a formal proposal to the PDP process > (http://www.ripe.net/ripe/policies/proposals/index.html) > and get consensus that this is the right way to proceed. > > > Adding to this that the "new BGP" is likely not going to happen before > the current IPv4 pool has run out, I'm pessimistic whether this proposal > will find much support in the communities, or will be seen as "taking > away the last remains of IPv4 from those who need/want it". > > Fortunately, I'm not to judge this, but just to steer the process... > > Gert Doering > -- APWG chair -- ------------------------------------------------------------- Roque Gagliano ANTEL - URUGUAY rgaglian at antel.net.uy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From randy at psg.com Mon Jul 30 19:42:22 2007 From: randy at psg.com (Randy Bush) Date: Mon, 30 Jul 2007 07:42:22 -1000 Subject: [address-policy-wg] 2007-06: New Policy Proposal (Global Policy for the Allocationof the Remaining IPv4 Address Space) In-Reply-To: <46ADE7FD.5080303@firstpr.com.au> References: <46ADE7FD.5080303@firstpr.com.au> Message-ID: <46AE22FE.20909@psg.com> > I believe that a substantial amount of the remaining IPv4 space > should be put aside to be used with whichever new architecture is > developed to deal with the routing and addressing problems discussed > last year in the IAB RAWS workshop. sure. in a lead-lined concrete vault for our grandchildren. the routing architecture issues the usual suspects are churning have been the same for decades, yes plural. i find the least optimism that they will be resolved by these same folk in my lifetime amusing at best. until the map and encap and other hackers give way to good math folk, we will get nowhere. and there has been zero motion in this direction. randy -- see B. Fortz and M. Thorup. Internet traffic engineering by optimizing OSPF weights. In IEEE INFOCOM, March 2000 for what happens when serious math folk get interested for a few months. From heldal at eml.cc Mon Jul 30 21:01:50 2007 From: heldal at eml.cc (Per Heldal) Date: Mon, 30 Jul 2007 21:01:50 +0200 Subject: [address-policy-wg] 2007-06: New Policy Proposal (Global Policy for the Allocationof the Remaining IPv4 Address Space) In-Reply-To: References: Message-ID: <1185822110.14886.29.camel@localhost.localdomain> On Mon, 2007-07-30 at 13:09 +0200, Alex Le Heux wrote: > PDP Number: 2007-06 > Global Policy for the Allocation of the Remaining IPv4 Address Space > > Dear Colleagues, > > A new RIPE Policy has been proposed and is now available for > discussion. > > This policy describes the process for the allocation of the remaining > IPv4 space from IANA to the RIRs. When a minimum amount of available > space is reached, an identical number of IPv4 allocation units (/8s) > will be allocated from IANA to each RIR, replacing the current IPv4 > allocation policy. The proposal claims to create "certainty on how the remaining space will be allocated". To me it seems the only advantage is to the RIRs with a slow burn-rate who may get space to allocate for 1-2 years longer than the big RIRs. It's not obvious that this makes it easier to predict the exact date of depletion -- for anyone. Nor does it anything to prevent a run on the remaining resources. How can/do you prevent registry-shopping in the period after the first RIRs run out of addresses? To avoid a run between the RIRs to get the last few /8s it might be an idea to hand out at least one /8 to each RIR in the last round. Alternatively one could define a last chunk of /8s to be split between the RIRs according to their burn-rate in the last months leading up to that point. Although impossible, I belive the best would be if all RIRs run out at the exact same time which is the opposite of what the suggested policy aim to achieve. //per From rgaglian at antel.net.uy Mon Jul 30 21:35:25 2007 From: rgaglian at antel.net.uy (Roque Gagliano) Date: Mon, 30 Jul 2007 16:35:25 -0300 Subject: [address-policy-wg] 2007-06: New Policy Proposal (Global Policy for the Allocationof the Remaining IPv4 Address Space) In-Reply-To: <1185822110.14886.29.camel@localhost.localdomain> References: <1185822110.14886.29.camel@localhost.localdomain> Message-ID: <1185824125.14995.81.camel@jessy.antel.net.uy> Hi, here my comments. Roque > The proposal claims to create "certainty on how the remaining space will > be allocated". > > To me it seems the only advantage is to the RIRs with a slow burn-rate > who may get space to allocate for 1-2 years longer than the big RIRs. > It's not obvious that this makes it easier to predict the exact date of > depletion -- for anyone. Nor does it anything to prevent a run on the > remaining resources. It does in the sense that each RIR will know the size of their last allocation. > How can/do you prevent registry-shopping in the period after the first > RIRs run out of addresses? > we cant. not just registry shopping but also a secondary market. However when RIRs are involved there are certain policies in place. > To avoid a run between the RIRs to get the last few /8s it might be an > idea to hand out at least one /8 to each RIR in the last round. That is what we are proposing setting N=1. The issue is that as a global policy it needs to be approved by all the RIR, and that takes at least 18 months. If we reach consensus that allocating the last /8s to each RIR make sense, we just need to discuss how big the size of that last allocation should be. We proposed 5x/8, but many people finds that too big. what about N=2 or 3? > > Although impossible, I belive the best would be if all RIRs run out at > the exact same time which is the opposite of what the suggested policy > aim to achieve. This policy is a global policy only affects how IANA allocates addresses to the RIRs, it does not study each RIR individually. Some RIR allocates a minimum of a /20, other a /22, etc. I believe that if we approved this policy each RIR could discussed more conservative policies and hopefully the RIR pool will never run out (check the "slow landing" proposal at ARIN as an example). > > //per > -- ------------------------------------------------------------- Roque Gagliano ANTEL - URUGUAY rgaglian at antel.net.uy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From heldal at eml.cc Mon Jul 30 23:11:45 2007 From: heldal at eml.cc (Per Heldal) Date: Mon, 30 Jul 2007 23:11:45 +0200 Subject: [address-policy-wg] 2007-06: New Policy Proposal (Global Policy for the Allocationof the Remaining IPv4 Address Space) In-Reply-To: <1185824125.14995.81.camel@jessy.antel.net.uy> References: <1185822110.14886.29.camel@localhost.localdomain> <1185824125.14995.81.camel@jessy.antel.net.uy> Message-ID: <1185829905.14886.69.camel@localhost.localdomain> On Mon, 2007-07-30 at 16:35 -0300, Roque Gagliano wrote: > Hi, here my comments. > Roque > > > The proposal claims to create "certainty on how the remaining space will > > be allocated". > > > > To me it seems the only advantage is to the RIRs with a slow burn-rate > > who may get space to allocate for 1-2 years longer than the big RIRs. > > It's not obvious that this makes it easier to predict the exact date of > > depletion -- for anyone. Nor does it anything to prevent a run on the > > remaining resources. > > It does in the sense that each RIR will know the size of their last > allocation. > > How can/do you prevent registry-shopping in the period after the first > > RIRs run out of addresses? > > > we cant. not just registry shopping but also a secondary market. However > when RIRs are involved there are certain policies in place. > > > To avoid a run between the RIRs to get the last few /8s it might be an > > idea to hand out at least one /8 to each RIR in the last round. > > That is what we are proposing setting N=1. The issue is that as a global > policy it needs to be approved by all the RIR, and that takes at least > 18 months. If we reach consensus that allocating the last /8s to each > RIR make sense, we just need to discuss how big the size of that last > allocation should be. We proposed 5x/8, but many people finds that too > big. what about N=2 or 3? > The amount of trouble at the time of depletion may turn out to be proportional to N. I.e. the smaller the better. If we are to deviate from the principle of "documented need", I believe it is better to define a last pool of /8s (e.g. 15) that is to be split among the RIRs according to their consumption. Some may get 5 /8s, others only 1, but they'll run out at about the same time. The RIRs provide data wrt their consumption to the NRO which in turn advise IANA/ICANN when it is time to make the final allocation. > > > > Although impossible, I belive the best would be if all RIRs run out at > > the exact same time which is the opposite of what the suggested policy > > aim to achieve. > > This policy is a global policy only affects how IANA allocates addresses to the RIRs, it does not study each RIR individually. Some RIR allocates a minimum of a /20, > other a /22, etc. The behaviour of individual RIRs is irrelevant unless IANA aspire to dictate RIR policies. If you really want more restrictive policies globally why don't you suggest such directly to each RIR. > I believe that if we approved this policy each RIR > could discussed more conservative policies and hopefully the RIR pool > will never run out (check the "slow landing" proposal at ARIN as an > example). Suggestions like the "soft landing" proposal in ARIN amount to little more than wishful thinking. Policy-changes may limit the number of smaller blocks and thus affect routing-table-growth. The volume of address-consumption OTOH is tied to growth in the broadband-market on which changes to allocation policies have minimal effect -- unless you go as far as to introduce some form of rationing. //per From david.conrad at icann.org Mon Jul 30 23:50:01 2007 From: david.conrad at icann.org (David Conrad) Date: Mon, 30 Jul 2007 14:50:01 -0700 Subject: [address-policy-wg] 2007-06: New Policy Proposal (Global Policy for the Allocationof the Remaining IPv4 Address Space) In-Reply-To: <1185829905.14886.69.camel@localhost.localdomain> References: <1185822110.14886.29.camel@localhost.localdomain> <1185824125.14995.81.camel@jessy.antel.net.uy> <1185829905.14886.69.camel@localhost.localdomain> Message-ID: <7E1FC540-6AA6-4508-8441-910F36A1233F@icann.org> Per, On Jul 30, 2007, at 2:11 PM, Per Heldal wrote: > If we are to deviate from the principle of "documented need", I > believe > it is better to define a last pool of /8s (e.g. 15) that is to be > split > among the RIRs according to their consumption. We (actually, Leo) did this exercise internally a while ago. It is a bit challenging to come up with a single answer as the outcome greatly depends on the starting conditions. That is, consumption is quite non-linear and if you choose a recent starting point you'll get a different answer than if you choose a historical starting point. This is further complicated by the fact that it is highly unlikely that current consumption patterns will remain constant over the lifetime of the IPv4 free pool. Of course, we can always close our eyes and pick numbers at semi-random... >> I believe that if we approved this policy each RIR >> could discussed more conservative policies and hopefully the RIR pool >> will never run out (check the "slow landing" proposal at ARIN as an >> example). > > Suggestions like the "soft landing" proposal in ARIN amount to little > more than wishful thinking. Policy-changes may limit the number of > smaller blocks and thus affect routing-table-growth. The volume of > address-consumption OTOH is tied to growth in the broadband-market on > which changes to allocation policies have minimal effect -- unless you > go as far as to introduce some form of rationing. Um. "Soft Landing" is a form of rationing. It increases the requirements for obtaining space as the free pool diminishes, making it harder and harder to obtain new blocks from the registry. In theory, the end effect would be to encourage increased efficiency in the use of IPv4 address space, even amongst broadband providers. Rgds, -drc From lpont at lacaixa.es Tue Jul 31 01:03:22 2007 From: lpont at lacaixa.es (lpont at lacaixa.es) Date: Tue, 31 Jul 2007 01:03:22 +0200 Subject: [address-policy-wg] LLUIS PONT GASAU/CAIXA01 es troba fora de l'oficina. Message-ID: Estar? ausente de la oficina desde el 30/07/2007 y no volver? hasta el 15/08/2007. Estar? fora de l'oficina des del 30/07/2007 fins el 15/08/2007. Per temes urgents, contacteu si us plau amb l'Elisabet Moliner (934047037). Gr?cies. From rw at firstpr.com.au Tue Jul 31 02:56:58 2007 From: rw at firstpr.com.au (Robin Whittle) Date: Tue, 31 Jul 2007 10:56:58 +1000 Subject: [address-policy-wg] new policy proposal (reserve IPv4 space for new architecture) In-Reply-To: <20070730154301.GR69215@Space.Net> References: <46ADE7FD.5080303@firstpr.com.au> <20070730154301.GR69215@Space.Net> Message-ID: <46AE88DA.9070606@firstpr.com.au> Hi Gert, Thanks for your response and for changing the subject line. I agree this is a difficult proposal to make at present. It is early days regarding a "new architecture", but the only proposals which involve no host changes and which work for both IPv4 and IPv6 are in two classes. Firstly BGP improvements. Secondly, ITR-ETR tunneling schemes, as a form of "locator-ID separation, which are IP-based have nothing directly to do with BGP. Unless someone invents a dramatic (several orders of magnitude) improvement to BGP regarding the number of prefixes the global system can handle, and unless someone invents a totally different solution for BGP-less multihoming, portability etc. than the ITR-ETR tunneling schemes, then I think one of these IP-based ITR-ETR tunneling schemes will be built. I guess that some time in the next year or so the BGP proposals and one of the IP-based schemes will be given to IETF WGs for serious development. I imagine that most people would think that these schemes are not yet well developed enough to justify locking up address space to await their completion. However, if nothing is done soon, then there won't be any fresh space left when the new scheme is ready to run. I think that the chosen IP-based ITR-ETR tunneling scheme will still be used to greatly improve the utilisation of IPv4 space, using space which is currently assigned. So it is not disastrous for long-term efficient use of the IPv4 space if no fresh space is reserved. Over time, if the scheme works as well as I think it will, a lot of the currently assigned address space would be assigned to the new scheme without any need for incentives. Roque Gagliano wrote: > What about using the Class E for this use? Can anyone comment on how the installed base of operating systems is likely to handle 240.0.0.0/4? It is not 224.0.0.0/4 multicast, but it has never been used. So I guess there has been no testing of how it would be handled. If this space was universally, or almost universally, handled well by operating systems and any other devices (routers, WiFi cameras, NAT software etc.) then it may need only an administrative change to use it for general Internet traffic. But if this is the case, then why wouldn't it be allocated to RIRs in the usual way? Randy Bush wrote: > until the map and encap and other hackers give way to good math > folk, we will get nowhere. and there has been zero motion in > this direction. I used to have a gung-ho approach to dragging that slacker protocol BGP into the modern world. Imagine a modern IT system gagging on a few hundred thousand of anything, especially when most of these things don't change from one week to the next! It would be great if you and these bright math people could contribute to the discussion in the Routing Research Group, to soup up BGP or replace it incrementally with something far better. Before doing so, you might like to read my message where I summarise how I came to realise why the performance of the BGP network is unlikely to be drastically improved, at least in terms of the number of prefixes it handles. http://www1.ietf.org/mail-archive/web/ram/current/msg01645.html I try to maintain a list of potential BGP improvements at: http://www.firstpr.com.au/ip/sram-ip-forwarding/#BGP_improvements but the best place to look is the RRG's wiki: http://www3.tools.ietf.org/group/irtf/trac/wiki/RoutingResearchGroup and the IDR WG, for which there are links in my previous message. - Robin http://www.firstpr.com.au/ip/ivip/ From heldal at eml.cc Tue Jul 31 12:58:22 2007 From: heldal at eml.cc (Per Heldal) Date: Tue, 31 Jul 2007 12:58:22 +0200 Subject: [address-policy-wg] new policy proposal (reserve IPv4 space for new architecture) In-Reply-To: <46AE88DA.9070606@firstpr.com.au> References: <46ADE7FD.5080303@firstpr.com.au> <20070730154301.GR69215@Space.Net> <46AE88DA.9070606@firstpr.com.au> Message-ID: <1185879502.14886.141.camel@localhost.localdomain> On Tue, 2007-07-31 at 10:56 +1000, Robin Whittle wrote: > Hi Gert, > > Thanks for your response and for changing the subject line. > > I agree this is a difficult proposal to make at present. > > It is early days regarding a "new architecture", but the only > proposals which involve no host changes and which work for both > IPv4 and IPv6 are in two classes. Firstly BGP improvements. > Secondly, ITR-ETR tunneling schemes, as a form of "locator-ID > separation, which are IP-based have nothing directly to do with BGP. > > Unless someone invents a dramatic (several orders of magnitude) > improvement to BGP regarding the number of prefixes the global > system can handle, and unless someone invents a totally different > solution for BGP-less multihoming, portability etc. than the > ITR-ETR tunneling schemes, then I think one of these IP-based > ITR-ETR tunneling schemes will be built. > > I guess that some time in the next year or so the BGP proposals > and one of the IP-based schemes will be given to IETF WGs for > serious development. Too little too late. It's awfully hard to operate networks on hot air and promises;) Even if there was a completed and universally accepted RFC today we'd probably face at least 5 years until the technology is widely deployed. Has anybody in the RIR community done research and and/or created statistics about: How many of those who have recently received v4 allocations were in possession of under-utilised blocks when the last allocation was made? (current policies should already prevent that) What are recently allocated addresses used for (%age of addresses consumed for end-user-termination, hosting, network infrastructure and other purposes)? My point is that I don't think it will make a significant difference to the overall consumption of addresses if we were able to hand out the remaining space in smaller chunks. Better utilisation of previously allocated blocks is always an issue, but there is effectively no incentive for those with under-utilised blocks to contribute parts of their resources back to the community. Even if the community would agree on how to handle previous allocations we don't have the (operational) mechanism that can be used to impose the same (draconian) rules on all resource-holders (e.g. route-certificates). > > I imagine that most people would think that these schemes are not > yet well developed enough to justify locking up address space to > await their completion. However, if nothing is done soon, then > there won't be any fresh space left when the new scheme is ready > to run. > > I think that the chosen IP-based ITR-ETR tunneling scheme will > still be used to greatly improve the utilisation of IPv4 space, > using space which is currently assigned. So it is not disastrous > for long-term efficient use of the IPv4 space if no fresh space is > reserved. Over time, if the scheme works as well as I think it > will, a lot of the currently assigned address space would be > assigned to the new scheme without any need for incentives. I agree that improved IDR scalability might provide some relief when there is no more fresh space to allocate from. But do you seriously expect anyone with say a /16 who only need a /22 or maybe even less to voluntarily give up the parts they don't use? > > Roque Gagliano wrote: > > > What about using the Class E for this use? > > Can anyone comment on how the installed base of operating systems > is likely to handle 240.0.0.0/4? It is not 224.0.0.0/4 multicast, > but it has never been used. So I guess there has been no testing > of how it would be handled. http://lists.arin.net/pipermail/ppml/2007-April/006679.html (that thread on the ppml-list spans at least april and may archives) //per From alexlh at ripe.net Tue Jul 31 19:40:55 2007 From: alexlh at ripe.net (Alex Le Heux) Date: Tue, 31 Jul 2007 19:40:55 +0200 Subject: [address-policy-wg] New IPv4 blocks allocated to RIPE NCC Message-ID: [Apologies for duplicate mails] Dear Colleagues, The RIPE NCC received the IPv4 address ranges 94/8 and 95/8 from the IANA in July 2007. We will begin allocating from these ranges in the near future. The minimum allocation size from these two /8s has been set at /21. You may wish to adjust any filters you have in place accordingly. More information on the IP space administered by the RIPE NCC can be found at: https://www.ripe.net/ripe/docs/ripe-ncc-managed-address-space.html Please also note that two "pilot" prefixes are being announced from each /8. These prefixes are: 95.192.0.0/16 95.255.248.0/21 They all originate in AS12654. The following pingable addresses are available in these blocks: 95.192.0.1 95.255.248.1 More information on this "pilot" activity is available in the document "De-Bogonising New Address Blocks", which can be found at: http://www.ripe.net/ripe/docs/ripe-351.html Best regards, Alex Le Heux RIPE NCC Policy Implementation Co-ordinator From alexlh at ripe.net Tue Jul 31 19:40:55 2007 From: alexlh at ripe.net (Alex Le Heux) Date: Tue, 31 Jul 2007 19:40:55 +0200 Subject: [address-policy-wg] New IPv4 blocks allocated to RIPE NCC Message-ID: [Apologies for duplicate mails] Dear Colleagues, The RIPE NCC received the IPv4 address ranges 94/8 and 95/8 from the IANA in July 2007. We will begin allocating from these ranges in the near future. The minimum allocation size from these two /8s has been set at /21. You may wish to adjust any filters you have in place accordingly. More information on the IP space administered by the RIPE NCC can be found at: https://www.ripe.net/ripe/docs/ripe-ncc-managed-address-space.html Please also note that two "pilot" prefixes are being announced from each /8. These prefixes are: 95.192.0.0/16 95.255.248.0/21 They all originate in AS12654. The following pingable addresses are available in these blocks: 95.192.0.1 95.255.248.1 More information on this "pilot" activity is available in the document "De-Bogonising New Address Blocks", which can be found at: http://www.ripe.net/ripe/docs/ripe-351.html Best regards, Alex Le Heux RIPE NCC Policy Implementation Co-ordinator