From iljitsch at muada.com Fri Jun 1 18:44:18 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Fri, 1 Jun 2007 18:44:18 +0200 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <78600.1180542129@sa.vix.com> References: <027601c7a2c9$5af8f5e0$423816ac@atlanta.polycom.com> <78600.1180542129@sa.vix.com> Message-ID: On 30-mei-2007, at 18:22, Paul_Vixie at isc.org wrote: > first, ARIN does not currently consider routability when allocating > address space. Hm: http://www.arin.net/policy/nrpm.html 6.3.4. Aggregation Wherever possible, address space should be distributed in a hierarchical manner, according to the topology of network infrastructure. This is necessary to permit the aggregation of routing information by ISPs, and to limit the expansion of Internet routing tables. This goal is particularly important in IPv6 addressing, where the size of the total address pool creates significant implications for both internal and external routing. The whole "routing is not guaranteed" thing is obviously in there because of the lawyers since ARIN can't force ISPs to route any given block of address space, not because routability isn't a goal. > non-routable space comes from ietf/iana, not the RIRs. > so, for ARIN to start allocating nonroutable space is a big change. Keeping the RIRs out of the ULA business would nicely avoid any problems resulting from that. Just let the domain sell the ip6.arpa domains in question. > (heck, maybe the old site-local prefix is still available.) http://www.ietf.org/rfc/rfc3879.txt Existing implementations and deployments MAY continue to use this prefix. From iljitsch at muada.com Sat Jun 2 00:39:20 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Sat, 2 Jun 2007 00:39:20 +0200 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <98099.1180717246@sa.vix.com> References: <027601c7a2c9$5af8f5e0$423816ac@atlanta.polycom.com> <78600.1180542129@sa.vix.com> <98099.1180717246@sa.vix.com> Message-ID: On 1-jun-2007, at 19:00, Paul Vixie wrote: > yes. but also because of the other part of my text, which you didn't > include in your reply so i don't know whether you agreed with it or > not: >>> ... we would have to define "routable", we could face implied >>> liability for >>> routability on "normal address space" (even if we continue to >>> disclaim it >>> in the NRPM as we do now), and we would then walk the slippery >>> slope of the >>> changing definition "largest" with respect to breidbart's maxim: > >> But what *IS* the internet? > > It's the largest equivalence class in the reflexive transitive > > symmetric closure of the relationship "can be reached by an IP > > packet from". --Seth Breidbart > in other words, the definition of "routable" depends on who you > want to be > able to exchange packets with. I'm not sure if I agree that there is a potential liability, but then, I'm not a lawyer, I don't play one on TV and the legal system where I live is quite different from that where ARIN is. The question of what "routability" is is not one that I'm interested in. We know what this means today, massaging the definition to fit a particular purpose can only lead to suboptimal results. > "local" and "routable", not so much so. Ok, if that makes you happy: Routable address space: any block of global unicast address space that when announced through or by an internet service provider, allows the holder to receive packets addressed to the addresses in question from all possible sources connected to the internet without additional effort. ULA fails this test because it falls outside the global unicast block and because announcing it to one ISP isn't enough to receive packets from all over the world because people will filter. From iljitsch at muada.com Sat Jun 2 17:35:59 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Sat, 2 Jun 2007 17:35:59 +0200 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <38008.1180742527@sa.vix.com> References: <027601c7a2c9$5af8f5e0$423816ac@atlanta.polycom.com> <78600.1180542129@sa.vix.com> <98099.1180717246@sa.vix.com> <38008.1180742527@sa.vix.com> Message-ID: <225E16DB-CB98-4C4C-B6AC-DE9D3CCB7280@muada.com> On 2-jun-2007, at 2:02, Paul Vixie wrote: > smaller private connectivity domains would only depend on > uniqueness among > their participants. are you trying to make a definition of > "routable" that > depends on which connectivity domain the observer is actually in? > or would > it be enough to say "the connectivity domain that ARIN's members > all share"? How did we get from routability tto uniqueness? "uniqueness among their participants" doesn't sound so bad until people start participating in multiple connectivity domains. I don't want to fumble the math so I'll spare you (and myself), but you get in the situation where there is overlap really fast. Also, in computer science there are only three numbers: 0, 1 and many. If we need more than one block of private space to avoid collisions, the obvious choice is to have as many blocks as there are domains. >> ULA fails this test because it falls outside the global unicast block >> and because announcing it to one ISP isn't enough to receive packets >> from all over the world because people will filter. > so the routability of an address block can also depend on filters? > (and > perhaps on firewalls?) and is an address block that's "routable" > today > capable of being "unroutable" tomorrow? and if it's "routable" > according > to network X, can it be "unroutable" according to network Y? Don't pretend this is news to you. Ever tried to cat herd? Herding network operators is even worse. > i can't imagine how a policy with these dependencies would be > implemented. Hence the "routability not guaranteed" disclaimer. > which is precisely the point i'm trying to make. the RIR system can > guaranty uniqueness among RIR allocations, but can make no assertions > either way as to "routability". since any definition of ULA > depends on > a definition of "routable", i think this slope is too slippery for us. As I said before, if ARIN feels it should only give out "hopefully routable" address space like it does today, no problem, let other people give out ULA-C space. But ARINs definition issues don't preclude the usefulness of ULA-C. From iljitsch at muada.com Sat Jun 2 17:35:59 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Sat, 2 Jun 2007 17:35:59 +0200 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <38008.1180742527@sa.vix.com> References: <027601c7a2c9$5af8f5e0$423816ac@atlanta.polycom.com> <78600.1180542129@sa.vix.com> <98099.1180717246@sa.vix.com> <38008.1180742527@sa.vix.com> Message-ID: <225E16DB-CB98-4C4C-B6AC-DE9D3CCB7280@muada.com> On 2-jun-2007, at 2:02, Paul Vixie wrote: > smaller private connectivity domains would only depend on > uniqueness among > their participants. are you trying to make a definition of > "routable" that > depends on which connectivity domain the observer is actually in? > or would > it be enough to say "the connectivity domain that ARIN's members > all share"? How did we get from routability tto uniqueness? "uniqueness among their participants" doesn't sound so bad until people start participating in multiple connectivity domains. I don't want to fumble the math so I'll spare you (and myself), but you get in the situation where there is overlap really fast. Also, in computer science there are only three numbers: 0, 1 and many. If we need more than one block of private space to avoid collisions, the obvious choice is to have as many blocks as there are domains. >> ULA fails this test because it falls outside the global unicast block >> and because announcing it to one ISP isn't enough to receive packets >> from all over the world because people will filter. > so the routability of an address block can also depend on filters? > (and > perhaps on firewalls?) and is an address block that's "routable" > today > capable of being "unroutable" tomorrow? and if it's "routable" > according > to network X, can it be "unroutable" according to network Y? Don't pretend this is news to you. Ever tried to cat herd? Herding network operators is even worse. > i can't imagine how a policy with these dependencies would be > implemented. Hence the "routability not guaranteed" disclaimer. > which is precisely the point i'm trying to make. the RIR system can > guaranty uniqueness among RIR allocations, but can make no assertions > either way as to "routability". since any definition of ULA > depends on > a definition of "routable", i think this slope is too slippery for us. As I said before, if ARIN feels it should only give out "hopefully routable" address space like it does today, no problem, let other people give out ULA-C space. But ARINs definition issues don't preclude the usefulness of ULA-C. _______________________________________________ This message sent to you through the ARIN Public Policy Mailing List (PPML at arin.net). Manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml From paul at vix.com Fri Jun 1 19:00:46 2007 From: paul at vix.com (Paul Vixie) Date: Fri, 01 Jun 2007 17:00:46 +0000 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: Your message of "Fri, 01 Jun 2007 18:44:18 +0200." References: <027601c7a2c9$5af8f5e0$423816ac@atlanta.polycom.com> <78600.1180542129@sa.vix.com> Message-ID: <98099.1180717246@sa.vix.com> > The whole "routing is not guaranteed" thing is obviously in there > because of the lawyers since ARIN can't force ISPs to route any given > block of address space, not because routability isn't a goal. yes. but also because of the other part of my text, which you didn't include in your reply so i don't know whether you agreed with it or not: >> ... we would have to define "routable", we could face implied liability for >> routability on "normal address space" (even if we continue to disclaim it >> in the NRPM as we do now), and we would then walk the slippery slope of the >> changing definition "largest" with respect to breidbart's maxim: >> But what *IS* the internet? > It's the largest equivalence class in the reflexive transitive > symmetric closure of the relationship "can be reached by an IP > packet from". --Seth Breidbart in other words, the definition of "routable" depends on who you want to be able to exchange packets with. if three networks are numbered in 10.1/16, 10.2/16, and 10.3/16, and they interconnect, then that address space is "routable" for *some* definition of "routable". i don't think we want to have to define, and then live with the implications of, the word "routable". > > non-routable space comes from ietf/iana, not the RIRs. > > so, for ARIN to start allocating nonroutable space is a big change. > > Keeping the RIRs out of the ULA business would nicely avoid any > problems resulting from that. Just let the domain sell the ip6.arpa > domains in question. see above. dunno why you didn't read it the first time i posted it here but i've posted it again and added some explaination. "universal" or "unique" we know the definition of. "local" and "routable", not so much so. From paul at vix.com Sat Jun 2 02:02:07 2007 From: paul at vix.com (Paul Vixie) Date: Sat, 02 Jun 2007 00:02:07 +0000 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: Your message of "Sat, 02 Jun 2007 00:39:20 +0200." References: <027601c7a2c9$5af8f5e0$423816ac@atlanta.polycom.com> <78600.1180542129@sa.vix.com> <98099.1180717246@sa.vix.com> Message-ID: <38008.1180742527@sa.vix.com> > > in other words, the definition of "routable" depends on who > > you want to be able to exchange packets with. > > ... The question of what "routability" is is not one that I'm interested > in. We know what this means today, massaging the definition to fit a > particular purpose can only lead to suboptimal results. we do not know, for the purpose of understanding and implementing a ULA policy, what "routability" means today. your lack of interest in it is not going to advance the debate as to whether ULA is a good or bad policy. > > "local" and "routable", not so much so. > > Ok, if that makes you happy: > > Routable address space: any block of global unicast address space that when > announced through or by an internet service provider, allows the holder to > receive packets addressed to the addresses in question from all possible > sources connected to the internet without additional effort. "the internet"? let me quote this again in case you missed it the last two times: >> But what *IS* the internet? > It's the largest equivalence class in the reflexive transitive > symmetric closure of the relationship "can be reached by an IP > packet from". --Seth Breidbart smaller private connectivity domains would only depend on uniqueness among their participants. are you trying to make a definition of "routable" that depends on which connectivity domain the observer is actually in? or would it be enough to say "the connectivity domain that ARIN's members all share"? > ULA fails this test because it falls outside the global unicast block > and because announcing it to one ISP isn't enough to receive packets > from all over the world because people will filter. so the routability of an address block can also depend on filters? (and perhaps on firewalls?) and is an address block that's "routable" today capable of being "unroutable" tomorrow? and if it's "routable" according to network X, can it be "unroutable" according to network Y? i can't imagine how a policy with these dependencies would be implemented. which is precisely the point i'm trying to make. the RIR system can guaranty uniqueness among RIR allocations, but can make no assertions either way as to "routability". since any definition of ULA depends on a definition of "routable", i think this slope is too slippery for us. From paul at vix.com Sat Jun 2 18:41:27 2007 From: paul at vix.com (Paul Vixie) Date: Sat, 02 Jun 2007 16:41:27 +0000 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: Your message of "Sat, 02 Jun 2007 17:35:59 +0200." <225E16DB-CB98-4C4C-B6AC-DE9D3CCB7280@muada.com> References: <027601c7a2c9$5af8f5e0$423816ac@atlanta.polycom.com> <78600.1180542129@sa.vix.com> <98099.1180717246@sa.vix.com> <38008.1180742527@sa.vix.com> <225E16DB-CB98-4C4C-B6AC-DE9D3CCB7280@muada.com> Message-ID: <39552.1180802487@sa.vix.com> > How did we get from routability tto uniqueness? uniqueness is the RIR goal for allocations today. routability is a new idea that would have to be seriously investigated to make ULA allocations possible. > "uniqueness among their participants" doesn't sound so bad until people > start participating in multiple connectivity domains. I don't want to fumble > the math so I'll spare you (and myself), but you get in the situation where > there is overlap really fast. Also, in computer science there are only three > numbers: 0, 1 and many. If we need more than one block of private space to > avoid collisions, the obvious choice is to have as many blocks as there are > domains. to me, the obvious choice, since even after wasting half the address space on EUI64, IPv6 is a really large space compared to distance vector convergence limits, is one block, IPv6:0/0. some parts of this will be routed. some will not be routed. some will be routed some days but not others. all allocations from the RIR system will be unique. > > which is precisely the point i'm trying to make. the RIR system can > > guaranty uniqueness among RIR allocations, but can make no assertions > > either way as to "routability". since any definition of ULA depends on a > > definition of "routable", i think this slope is too slippery for us. > > As I said before, if ARIN feels it should only give out "hopefully routable" > address space like it does today, no problem, let other people give out > ULA-C space. But ARINs definition issues don't preclude the usefulness of > ULA-C. since ULA is designed to conserve something that we can't use all of (IPv6 address space) because of something else we can't get enough of (routing table size), at the expense of constraining the future usability of the allocations (forcing a renumbering event to go from unroutable to routable) and requiring a new system of monitoring and enforcement, which by example RFC 1918 still lacks), i have to say, ULA looks like all-pain no-gain to me. From filiz at ripe.net Mon Jun 4 13:47:57 2007 From: filiz at ripe.net (Filiz Yilmaz) Date: Mon, 04 Jun 2007 13:47:57 +0200 Subject: [address-policy-wg] 2006-02 Last Call for Comments (IPv6 Address Allocation and Assignment Policy) Message-ID: <20070604114757.0F0F22F583@herring.ripe.net> PDP Number: 2006-02 IPv6 Address Allocation and Assignment Policy Dear Colleagues The proposal described in 2006-02 is now at its Concluding Phase. 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 Please e-mail any final comments about this proposal to address-policy-wg at ripe.net before 2 July 2007. Regards Filiz Yilmaz RIPE NCC Policy Development Officer From filiz at ripe.net Tue Jun 5 16:29:48 2007 From: filiz at ripe.net (Filiz Yilmaz) Date: Tue, 05 Jun 2007 16:29:48 +0200 Subject: [address-policy-wg] 2005-08 Last Call for Comments (Proposal to Amend the IPv6 Assignment and Utilisation Requirement Policy) Message-ID: <20070605142948.11A532F583@herring.ripe.net> PDP Number: 2005-08 Proposal to Amend the IPv6 Assignment and Utilisation Requirement Policy Dear Colleagues The proposal described in 2005-08 is now at its Concluding Phase. This proposal is to amend the RIPE IPv6 address allocation policies regarding the definition of the default size of End Site allocations, the threshold value for End Site allocation efficiency, and the method of calculation of the End Site allocation efficiency metric. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2005-08.html As you may remember, two draft documents for this proposal were published during its Review Phase. Now that both drafts have been moved to Last Call, we have published a combined draft document for your convenience. You can find this combined document at: http://www.ripe.net/ripe/draft-documents/2005-08.html The two separate draft documents for this proposal can still be found at: Defining allocation efficiency measurement unit as /56: http://www.ripe.net/ripe/draft-documents/2005-08-56s.html Changing the HD ratio value to 0.94: http://www.ripe.net/ripe/draft-documents/2005-08-hd-ratio.html Please e-mail any final comments about this proposal to address-policy-wg at ripe.net before 3 July 2007. Regards Filiz Yilmaz RIPE NCC Policy Development Officer From webmaster at ripe.net Thu Jun 7 11:22:58 2007 From: webmaster at ripe.net (RIPE NCC Document Announcement Service) Date: Thu, 07 Jun 2007 11:22:58 +0200 Subject: [address-policy-wg] New RIPE Document available: RIPE-411 Message-ID: <20070607092258.1902A2F583@herring.ripe.net> A new RIPE Document is available from the RIPE Document store. Ref: ripe-411 Title: IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region Author: RIPE NCC Date: June 2007 Format: PDF=82,541 Obsoletes: ripe-405 This document describes the RIPE community?s current IPv4 address allocation and assignment policies. They were developed through a bottom-up, consensus driven, open policy development process in the RIPE Address Policy Working Group (AP WG). The RIPE Network Coordination Centre (RIPE NCC) facilitates and supports this process. These policies apply to the RIPE NCC and the Local Internet Registries (LIRs) within the RIPE NCC service region. You can find this document at: http://www.ripe.net/docs/ripe-411.html Regards RIPE NCC Webmaster From randy at psg.com Thu Jun 7 15:54:15 2007 From: randy at psg.com (Randy Bush) Date: Thu, 07 Jun 2007 06:54:15 -0700 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <7C441817-6409-48D2-8599-1EE7A6FAC0F7@antel.net.uy> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529091805.GA15655@borg.c-l-i.net> <20070529100000.GA16216@borg.c-l-i.net> <465C3FDE.7050708@psg.com> <200705300249.l4U2ndVH019658@cichlid.raleigh.ibm.com> <7C441817-6409-48D2-8599-1EE7A6FAC0F7@antel.net.uy> Message-ID: <46680E07.7030501@psg.com> > Should ULA-C be published in the Whois database? what about reverse DNS > for them, should they be delegated or just reply a NXDOMAIN? let's see. ula-c should be assigned and tracked by rirs. they should have whois and in-addr.arpa. do remind me how they differ from pi space. i keep forgetting. randy From rgaglian at antel.net.uy Thu Jun 7 15:56:32 2007 From: rgaglian at antel.net.uy (Roque Gagliano) Date: Thu, 7 Jun 2007 10:56:32 -0300 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <46680E07.7030501@psg.com> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529091805.GA15655@borg.c-l-i.net> <20070529100000.GA16216@borg.c-l-i.net> <465C3FDE.7050708@psg.com> <200705300249.l4U2ndVH019658@cichlid.raleigh.ibm.com> <7C441817-6409-48D2-8599-1EE7A6FAC0F7@antel.net.uy> <46680E07.7030501@psg.com> Message-ID: more "practical" questions: why should they be cheaper than PI block? do they take less administrative work form RIR? do they take less "space" in their databases? in many RIRs you need to pay a "membership" fee and doing so you get the right to vote in their members meetings, if you get an ULA-C allocation, should you be considered a member? would you pay your membership fee to the RIR? again, why should this allocation be cheaper that a PI allocation? Roque On Jun 7, 2007, at 10:54 AM, Randy Bush wrote: >> Should ULA-C be published in the Whois database? what about >> reverse DNS >> for them, should they be delegated or just reply a NXDOMAIN? > > let's see. ula-c should be assigned and tracked by rirs. they should > have whois and in-addr.arpa. do remind me how they differ from pi > space. i keep forgetting. > > randy ------------------------------------------------------------- Roque Gagliano ANTEL - URUGUAY rgaglian at antel.net.uy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Thu Jun 7 16:21:28 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Thu, 07 Jun 2007 16:21:28 +0200 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: Message-ID: Hi Roque, This is something that never is defined by the policies. It is up to the board to decide and I'm fine with board decisions on this. If you don't, they you should make sure to select a different board composition next time :-). Regards, Jordi De: Roque Gagliano Responder a: Fecha: Thu, 7 Jun 2007 10:56:32 -0300 Para: Randy Bush CC: Thomas Narten , , Asunto: Re: [ppml] [address-policy-wg] Those pesky ULAs again more "practical" questions: why should they be cheaper than PI block? do they take less?administrative?work form RIR? do they take less "space" in their databases?? in many RIRs you need to pay a "membership" fee and doing so you get the right to vote in their members meetings, if you get an ULA-C allocation, should you be considered a member? would you pay your membership fee to the RIR? again, why should this allocation be cheaper that a PI allocation? Roque On Jun 7, 2007, at 10:54 AM, Randy Bush wrote: >> Should ULA-C be published in the Whois database? what about reverse DNS >> for them, should they be delegated or just reply a NXDOMAIN? >> > > let's see.? ula-c should be assigned and tracked by rirs.? they should > have whois and in-addr.arpa.? do remind me how they differ from pi > space.? i keep forgetting. > > randy > ------------------------------------------------------------- Roque Gagliano ANTEL - URUGUAY rgaglian at antel.net.uy _______________________________________________ This message sent to you through the ARIN Public Policy Mailing List (PPML at arin.net). Manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml ********************************************** 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 fw at deneb.enyo.de Thu Jun 7 16:22:34 2007 From: fw at deneb.enyo.de (Florian Weimer) Date: Thu, 07 Jun 2007 16:22:34 +0200 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <78600.1180542129@sa.vix.com> (Paul Vixie's message of "Wed, 30 May 2007 16:22:09 +0000") References: <027601c7a2c9$5af8f5e0$423816ac@atlanta.polycom.com> <78600.1180542129@sa.vix.com> Message-ID: <87bqfr3kut.fsf@mid.deneb.enyo.de> * Paul Vixie: > first, ARIN does not currently consider routability when allocating > address space. non-routable space comes from ietf/iana, not the RIRs. > so, for ARIN to start allocating nonroutable space is a big change. we > would have to define "routable", we could face implied liability for > routability on "normal address space" Why? There is a technical difference between the two offerings (separate address spaces). It seems to me that this criterion is completely sufficient. It's up to the requestor to decide which type they need, and to make sure that the meet the published requirements. On the other hand, the IPv6 address space is so large that any entity can pick some prefix and use it to implement its own ULA registry. If there is real demand for such a service, that demand itself will make sure that the prefix won't be used for any other purpose. (".local." could be seen as a counter-example, but I believe the initial problems have been fixed by now.) From leo.vegoda at icann.org Thu Jun 7 16:22:52 2007 From: leo.vegoda at icann.org (Leo Vegoda) Date: Thu, 7 Jun 2007 16:22:52 +0200 Subject: [address-policy-wg] 2006-01 Discussion Period extended until 19 June 2007 (Provider Independent (PI) IPv6 Assignments for End User Organisations) In-Reply-To: References: Message-ID: Hi Jordi, On 31 May 2007, at 11:12am, JORDI PALET MARTINEZ wrote: [...] >>>> It would be helpful to people considering requesting a PI IPv6 >>>> prefix >>>> and the RIPE NCC if the policy gave a clear statement of what is >>>> required. >>> >>> Not sure if that's so easy, and I'm not really sure is really >>> needed. Do you >>> have any idea ? We could also apply that "idea", may be, to the >>> standard >>> IPv6 allocation policy. >>> >>> It will be good to understand if the staff is having problems >>> there, or it >>> is just enough the way they are doing and it may be applied then >>> here the >>> same. >> >> One of the three principles guiding the policy process is that "it is >> transparent. All discussions and results are documented and freely >> available to all."[1] If the criteria for a decision are too >> difficult to define in the policy text then there's something wrong >> somewhere. > > I think in some situations, the staff needs to have some > flexibility. Is not > a matter of wrong policy, is a matter of avoiding a complex one > with too > many cases, because every ISP may be one, and we have already > guidelines > such as RFC3177 and utilization, which the staff, I guess, uses to > understand if the right prefix is a /32 or a /30 or whatever. May > be having > a reference to that is enough ? I agree that flexibility is good and a complex policy will not work for all cases. Nonetheless, without a statement of what the policy is both the registry staff and the potential requesters are in the dark and that's not really fair to either of them. The policy needs to define some basis for determining the length of a PI prefix so that everyone knows what the policy actually is. The first attempt might not be the right answer but that's not a problem as we know that the IPv6 policy is an interim policy and it will be reviewed in the future when we have more experience in the administration of IPv6. >>>> Also, the proposed text does not define a maximum size for an >>>> IPv6 PI >>>> assignment. When this is combined with a lack of definition for the >>>> qualification requirements it seems that a /32 of IPv6 PI could be >>>> assigned. Is that intended? >>> >>> Not at all, it is not intended to assign a /32. However, if the >>> case justify >>> it, we aren't closing the door. I really think it is difficult to >>> find a >>> case that could justify that, in fact probably is very difficult to >>> justify >>> cases that justify something shorter than /44, but you never know >>> how big >>> can be a data center or content provider, for example. >> >> I think it's difficult to define a case justifying it, too. But that >> doesn't mean that unreasonable requests won't be made. And if you >> don't have a clearly defined set of criteria you make things >> needlessly difficult for both the requesters and the registry. > > Same as above, if the utilization based on RFC3177 recommendations > is a good > parameter, then the criteria can be defined in a simple way that > accommodate > all the cases while hostmasters have a good point to check. I think we need something a little better defined than the text in RFC 3177. It says: - Very large subscribers could receive a /47 or slightly shorter prefix, or multiple /48's. Unfortunately, "very large" isn't quantifiable and changes according to your perspective. I'm not sure what the appropriate utilisation requirements should be. I do know that this proposal isn't intended for ISPs that need address space as they can get at least a /32 allocation. Maybe we should be asking for input from people that have already deployed IPv6 on large enterprise networks, at university campuses and so on to describe their experiences and help us work out a quantifiable utilisation requirement for receiving more than a /48. Regards, -- Leo Vegoda IANA Numbers Liaison From rgaglian at antel.net.uy Thu Jun 7 15:43:57 2007 From: rgaglian at antel.net.uy (Roque Gagliano) Date: Thu, 7 Jun 2007 10:43:57 -0300 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <200705300249.l4U2ndVH019658@cichlid.raleigh.ibm.com> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529091805.GA15655@borg.c-l-i.net> <20070529100000.GA16216@borg.c-l-i.net> <465C3FDE.7050708@psg.com> <200705300249.l4U2ndVH019658@cichlid.raleigh.ibm.com> Message-ID: <7C441817-6409-48D2-8599-1EE7A6FAC0F7@antel.net.uy> > > ULAs are not intended to be publically routed by ISPs. While some may > attempt to get ISPs to route them, ISPs will have clear documentation > saying they are not intended to be used that way, and they are free to > filter them. And in fact they SHOULD be filtered. (I'd say MUST, but > since that is not enforceable...) Should ULA-C be published in the Whois database? what about reverse DNS for them, should they be delegated or just reply a NXDOMAIN? Roque ------------------------------------------------------------- Roque Gagliano ANTEL - URUGUAY rgaglian at antel.net.uy -------------- next part -------------- An HTML attachment was scrubbed... URL: From he at uninett.no Thu Jun 7 17:47:54 2007 From: he at uninett.no (Havard Eidnes) Date: Thu, 07 Jun 2007 17:47:54 +0200 (CEST) Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <46680E07.7030501@psg.com> References: <200705300249.l4U2ndVH019658@cichlid.raleigh.ibm.com> <7C441817-6409-48D2-8599-1EE7A6FAC0F7@antel.net.uy> <46680E07.7030501@psg.com> Message-ID: <20070607.174754.112190619.he@uninett.no> > > Should ULA-C be published in the Whois database? what about reverse DNS > > for them, should they be delegated or just reply a NXDOMAIN? > > let's see. ula-c should be assigned and tracked by rirs. they > should have whois and in-addr.arpa. do remind me how they > differ from pi space. i keep forgetting. Oh, they differ because they are supposedly "not routeable on the public big-I Internet" because "they will be filtered away by ISPs". However, I suspect you are perhaps hinting that when a sufficient number of organizations have been given ULA-C addresses, the pressure on ISPs is going to be like "oh, pretty please, for this amount of $$$, can you please route these ULA-C addresses for me across your network", and after a while with the sheer meat- weight of all the sloppily-handed-out ULA-C addresses, we will have re-created the swamp from IPv4 (192/8)? Regards, - H?vard From nick at inex.ie Thu Jun 7 18:19:35 2007 From: nick at inex.ie (Nick Hilliard) Date: Thu, 07 Jun 2007 17:19:35 +0100 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <20070607.174754.112190619.he@uninett.no> References: <200705300249.l4U2ndVH019658@cichlid.raleigh.ibm.com> <7C441817-6409-48D2-8599-1EE7A6FAC0F7@antel.net.uy> <46680E07.7030501@psg.com> <20070607.174754.112190619.he@uninett.no> Message-ID: <46683017.2030908@inex.ie> Havard Eidnes wrote: > [...] we will have re-created the swamp from IPv4 (192/8)? By introducing ipv6 PI, we are already committing to reproduce a routing swamp, albeit with defined borders (which will allow reasonable length-based prefix filtering). ULA-C would simply be another similarly defined swamp area, of limited reachability and therefore of limited use. Sure, you're going to get a couple of organisation crazeee enough to want to advertise this space. If they're stupid enough to want their business model depend on a completely broken engineering model, let them go ahead with it and see how far it gets them. Nick From rgaglian at antel.net.uy Thu Jun 7 15:56:32 2007 From: rgaglian at antel.net.uy (Roque Gagliano) Date: Thu, 7 Jun 2007 10:56:32 -0300 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <46680E07.7030501@psg.com> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529091805.GA15655@borg.c-l-i.net> <20070529100000.GA16216@borg.c-l-i.net> <465C3FDE.7050708@psg.com> <200705300249.l4U2ndVH019658@cichlid.raleigh.ibm.com> <7C441817-6409-48D2-8599-1EE7A6FAC0F7@antel.net.uy> <46680E07.7030501@psg.com> Message-ID: more "practical" questions: why should they be cheaper than PI block? do they take less administrative work form RIR? do they take less "space" in their databases? in many RIRs you need to pay a "membership" fee and doing so you get the right to vote in their members meetings, if you get an ULA-C allocation, should you be considered a member? would you pay your membership fee to the RIR? again, why should this allocation be cheaper that a PI allocation? Roque On Jun 7, 2007, at 10:54 AM, Randy Bush wrote: >> Should ULA-C be published in the Whois database? what about >> reverse DNS >> for them, should they be delegated or just reply a NXDOMAIN? > > let's see. ula-c should be assigned and tracked by rirs. they should > have whois and in-addr.arpa. do remind me how they differ from pi > space. i keep forgetting. > > randy ------------------------------------------------------------- Roque Gagliano ANTEL - URUGUAY rgaglian at antel.net.uy -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ This message sent to you through the ARIN Public Policy Mailing List (PPML at arin.net). Manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml From david.conrad at icann.org Thu Jun 7 19:24:05 2007 From: david.conrad at icann.org (David Conrad) Date: Thu, 7 Jun 2007 10:24:05 -0700 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <20070607.174754.112190619.he@uninett.no> References: <200705300249.l4U2ndVH019658@cichlid.raleigh.ibm.com> <7C441817-6409-48D2-8599-1EE7A6FAC0F7@antel.net.uy> <46680E07.7030501@psg.com> <20070607.174754.112190619.he@uninett.no> Message-ID: <4BE5E14A-CAFD-4D80-8141-97DA08C849D7@icann.org> On Jun 7, 2007, at 8:47 AM, Havard Eidnes wrote: > we will have re-created the swamp from IPv4 (192/8)? Oh, we've already done that. And, I suspect, recreated the class As as well. Rgds, -drc From kkargel at polartel.com Thu Jun 7 16:16:28 2007 From: kkargel at polartel.com (Kevin Kargel) Date: Thu, 7 Jun 2007 09:16:28 -0500 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066706FB1@mail> Wouldn't it be nice if we had a ULA bit or two to play with in the BGP announcements? Then everyone could define their own.. I know this is facetious and not a serious consideration, but it was an interesting thought.. ________________________________ From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of Roque Gagliano Sent: Thursday, June 07, 2007 8:57 AM To: Randy Bush Cc: Thomas Narten; ppml at arin.net; address-policy-wg at ripe.net Subject: Re: [ppml] [address-policy-wg] Those pesky ULAs again more "practical" questions: why should they be cheaper than PI block? do they take less administrative work form RIR? do they take less "space" in their databases? in many RIRs you need to pay a "membership" fee and doing so you get the right to vote in their members meetings, if you get an ULA-C allocation, should you be considered a member? would you pay your membership fee to the RIR? again, why should this allocation be cheaper that a PI allocation? Roque On Jun 7, 2007, at 10:54 AM, Randy Bush wrote: Should ULA-C be published in the Whois database? what about reverse DNS for them, should they be delegated or just reply a NXDOMAIN? let's see. ula-c should be assigned and tracked by rirs. they should have whois and in-addr.arpa. do remind me how they differ from pi space. i keep forgetting. randy ------------------------------------------------------------- Roque Gagliano ANTEL - URUGUAY rgaglian at antel.net.uy -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at vix.com Thu Jun 7 16:31:10 2007 From: paul at vix.com (Paul Vixie) Date: Thu, 07 Jun 2007 14:31:10 +0000 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: Your message of "Thu, 07 Jun 2007 06:54:15 MST." <46680E07.7030501@psg.com> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529091805.GA15655@borg.c-l-i.net> <20070529100000.GA16216@borg.c-l-i.net> <465C3FDE.7050708@psg.com> <200705300249.l4U2ndVH019658@cichlid.raleigh.ibm.com> <7C441817-6409-48D2-8599-1EE7A6FAC0F7@antel.net.uy> <46680E07.7030501@psg.com> Message-ID: <51726.1181226670@sa.vix.com> > > Should ULA-C be published in the Whois database? what about reverse DNS > > for them, should they be delegated or just reply a NXDOMAIN? > > let's see. ula-c should be assigned and tracked by rirs. they should > have whois and in-addr.arpa. do remind me how they differ from pi > space. i keep forgetting. while i'm uncomfortable with randy's tone here, i agree with his concern. the difference between pi and ula has been given as "not intended to be routed in the DFZ". this means a pi prefix can be routed privately, as for example among cooperating BGP peers at an IX, or between companies involved in private relationships such as banking or manufacturing, and of course, it will mean that "merge/acquire" no longer implies "renumber the RFC1918's on one or both sides". but since we could never possibly fit all of ipv6 into the DFZ, and since the cost and availability of pi is theoretically manageable by us (the RIR system) to make sure everybody who needs it can get and can afford it, i fail to see the virtue of making some of it cheaper and worth less. this whole argument has helped me understand that there is a policy hole but that "unroutable" isn't it. if the RIR system had multiple high order prefixes (IPv6 /10's or whatever) to allocate from, with a minimum length policy that varied, then global static route-ingress filters could be set that would outlaw TE routes, which are the major source of DFZ bloat, way over the top compared to SMB PI routes. i think i oppose ula simply because there's no way to define "local" in a way that will serve a network's needs throughout its probable life cycle, except in the case where RFC1918 (or IPv6 "site local") would have served. From rogerj at jorgensen.no Fri Jun 8 18:44:04 2007 From: rogerj at jorgensen.no (Roger Jorgensen) Date: Fri, 8 Jun 2007 18:44:04 +0200 (CEST) Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <51726.1181226670@sa.vix.com> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529091805.GA15655@borg.c-l-i.net> <20070529100000.GA16216@borg.c-l-i.net> <465C3FDE.7050708@psg.com> <200705300249.l4U2ndVH019658@cichlid.raleigh.ibm.com> <7C441817-6409-48D2-8599-1EE7A6FAC0F7@antel.net.uy> <46680E07.7030501@psg.com> <51726.1181226670@sa.vix.com> Message-ID: On Thu, 7 Jun 2007, Paul Vixie wrote: >>> Should ULA-C be published in the Whois database? what about reverse DNS >>> for them, should they be delegated or just reply a NXDOMAIN? >> let's see. ula-c should be assigned and tracked by rirs. they should >> have whois and in-addr.arpa. do remind me how they differ from pi >> space. i keep forgetting. > while i'm uncomfortable with randy's tone here, i agree with his concern. > the difference between pi and ula has been given as "not intended to be > routed in the DFZ". this means a pi prefix can be routed privately, as > for example among cooperating BGP peers at an IX, or between companies > involved in private relationships such as banking or manufacturing, and > of course, it will mean that "merge/acquire" no longer implies "renumber > the RFC1918's on one or both sides". > > but since we could never possibly fit all of ipv6 into the DFZ, and since > the cost and availability of pi is theoretically manageable by us (the RIR > system) to make sure everybody who needs it can get and can afford it, i > fail to see the virtue of making some of it cheaper and worth less. Well, I was really in favour of ULA-C but now given some time and after listning to all of the arguments, and maybe most important I realized one huge thing that ULA-C maybe can't provide, DNS, which leave it useless for our usage. Without reverse DNS possibility ULA-C is useless. On the other hand, why do we need PI? What we need is a policy that make sure those that could gain from ULA-C can get public routable IP space, and then they can themself decide if they want to route it or not. It's possible and upto them. If we have to call it PI then so be it... I really dislike the name but I can live with it. -- ------------------------------ Roger Jorgensen | - ROJO9-RIPE - RJ85P-NORID roger at jorgensen.no | - IPv6 is The Key! ------------------------------------------------------- From jorgen at hovland.cx Fri Jun 8 22:13:45 2007 From: jorgen at hovland.cx (=?UTF-8?Q?J=C3=B8rgen_Hovland?=) Date: Fri, 8 Jun 2007 22:13:45 +0200 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529091805.GA15655@borg.c-l-i.net> <20070529100000.GA16216@borg.c-l-i.net> <465C3FDE.7050708@psg.com> <200705300249.l4U2ndVH019658@cichlid.raleigh.ibm.com> <7C441817-6409-48D2-8599-1EE7A6FAC0F7@antel.net.uy> <46680E07.7030501@psg.com> <51726.1181226670@sa.vix.com> Message-ID: <000001c7aa09$844aca30$8ce05e90$@cx> > On the other hand, why do we need PI? There are many reasons. That the prefix is routable on the internet is however not always a requirement by the requester. The RIRs could make that as an option when requesting space. It would surely be easier to get PI space if it didn?t have to be routable (on the internet). There could be different requirements for this. j -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Roger Jorgensen Sent: 8. juni 2007 18:44 To: Paul Vixie Cc: ppml at arin.net; address-policy-wg at ripe.net; roger at jorgensen.no Subject: Re: [ppml] [address-policy-wg] Those pesky ULAs again On Thu, 7 Jun 2007, Paul Vixie wrote: >>> Should ULA-C be published in the Whois database? what about reverse DNS >>> for them, should they be delegated or just reply a NXDOMAIN? >> let's see. ula-c should be assigned and tracked by rirs. they should >> have whois and in-addr.arpa. do remind me how they differ from pi >> space. i keep forgetting. > while i'm uncomfortable with randy's tone here, i agree with his concern. > the difference between pi and ula has been given as "not intended to be > routed in the DFZ". this means a pi prefix can be routed privately, as > for example among cooperating BGP peers at an IX, or between companies > involved in private relationships such as banking or manufacturing, and > of course, it will mean that "merge/acquire" no longer implies "renumber > the RFC1918's on one or both sides". > > but since we could never possibly fit all of ipv6 into the DFZ, and since > the cost and availability of pi is theoretically manageable by us (the RIR > system) to make sure everybody who needs it can get and can afford it, i > fail to see the virtue of making some of it cheaper and worth less. Well, I was really in favour of ULA-C but now given some time and after listning to all of the arguments, and maybe most important I realized one huge thing that ULA-C maybe can't provide, DNS, which leave it useless for our usage. Without reverse DNS possibility ULA-C is useless. On the other hand, why do we need PI? What we need is a policy that make sure those that could gain from ULA-C can get public routable IP space, and then they can themself decide if they want to route it or not. It's possible and upto them. If we have to call it PI then so be it... I really dislike the name but I can live with it. -- ------------------------------ Roger Jorgensen | - ROJO9-RIPE - RJ85P-NORID roger at jorgensen.no | - IPv6 is The Key! ------------------------------------------------------- From Paul_Vixie at isc.org Fri Jun 8 19:51:15 2007 From: Paul_Vixie at isc.org (Paul_Vixie at isc.org) Date: Fri, 08 Jun 2007 17:51:15 +0000 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: Your message of "Fri, 08 Jun 2007 18:44:04 +0200." References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529091805.GA15655@borg.c-l-i.net> <20070529100000.GA16216@borg.c-l-i.net> <465C3FDE.7050708@psg.com> <200705300249.l4U2ndVH019658@cichlid.raleigh.ibm.com> <7C441817-6409-48D2-8599-1EE7A6FAC0F7@antel.net.uy> <46680E07.7030501@psg.com> <51726.1181226670@sa.vix.com> Message-ID: <38529.1181325075@sa.vix.com> > > but since we could never possibly fit all of ipv6 into the DFZ, and since > > the cost and availability of pi is theoretically manageable by us (the RIR > > system) to make sure everybody who needs it can get and can afford it, i > > fail to see the virtue of making some of it cheaper and worth less. > > Well, I was really in favour of ULA-C but now given some time and after > listning to all of the arguments, and maybe most important I realized one > huge thing that ULA-C maybe can't provide, DNS, which leave it useless for > our usage. > > Without reverse DNS possibility ULA-C is useless. i agree, but i think that the implications of your statement are very telling. if these addresses really did correspond to "private" networks, then reverse dns could be managed with cutouts, much as is done for RFC 1918 in-addrs now. but since we all expect that these "private" networks will be interconnected among private (non-transit) relationships, we know that the entity seeing one of these "private" addresses and needing to know the PTR for it may not have a direct relationship to the owner of the network using the address. that's another way of saying that these addresses are not actually private, or local; the fact that they aren't intended to be carried in the DFZ matters not at all. > On the other hand, why do we need PI? What we need is a policy that make > sure those that could gain from ULA-C can get public routable IP space, and > then they can themself decide if they want to route it or not. It's possible > and upto them. > > If we have to call it PI then so be it... I really dislike the name but I > can live with it. for this discussion, i think we should forget about the distinction between PI and PA, which only make sense when there is a "provider." perhaps the automotive exchange network will be an LIR for assigning network numbers to its members, or perhaps not. the term we've probably been looking for is UA (unique address, or universal address) in comparison to IPv6 "site local" or IPv4 RFC1918 (which are nonunique and nonuniversal; sometimes "ambiguous"). everybody needs UA, whether they have a provider or not. some UA's will be in the DFZ and some not, according to the business needs of the network owner. one of those business needs is "nobody will route PI UA for me" or "the cost of routing PI UA is very high" and so, some UA will be PA UA. that's not a RIR issue per se, other than that it may drive policy toward smaller/cheaper UA allocations which all come from some particular /10 so that draconian DFZ router operators can reject these routes if they don't originate in peers. From Paul_Vixie at isc.org Fri Jun 8 19:51:15 2007 From: Paul_Vixie at isc.org (Paul_Vixie at isc.org) Date: Fri, 08 Jun 2007 17:51:15 +0000 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: Your message of "Fri, 08 Jun 2007 18:44:04 +0200." References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529091805.GA15655@borg.c-l-i.net> <20070529100000.GA16216@borg.c-l-i.net> <465C3FDE.7050708@psg.com> <200705300249.l4U2ndVH019658@cichlid.raleigh.ibm.com> <7C441817-6409-48D2-8599-1EE7A6FAC0F7@antel.net.uy> <46680E07.7030501@psg.com> <51726.1181226670@sa.vix.com> Message-ID: <38529.1181325075@sa.vix.com> > > but since we could never possibly fit all of ipv6 into the DFZ, and since > > the cost and availability of pi is theoretically manageable by us (the RIR > > system) to make sure everybody who needs it can get and can afford it, i > > fail to see the virtue of making some of it cheaper and worth less. > > Well, I was really in favour of ULA-C but now given some time and after > listning to all of the arguments, and maybe most important I realized one > huge thing that ULA-C maybe can't provide, DNS, which leave it useless for > our usage. > > Without reverse DNS possibility ULA-C is useless. i agree, but i think that the implications of your statement are very telling. if these addresses really did correspond to "private" networks, then reverse dns could be managed with cutouts, much as is done for RFC 1918 in-addrs now. but since we all expect that these "private" networks will be interconnected among private (non-transit) relationships, we know that the entity seeing one of these "private" addresses and needing to know the PTR for it may not have a direct relationship to the owner of the network using the address. that's another way of saying that these addresses are not actually private, or local; the fact that they aren't intended to be carried in the DFZ matters not at all. > On the other hand, why do we need PI? What we need is a policy that make > sure those that could gain from ULA-C can get public routable IP space, and > then they can themself decide if they want to route it or not. It's possible > and upto them. > > If we have to call it PI then so be it... I really dislike the name but I > can live with it. for this discussion, i think we should forget about the distinction between PI and PA, which only make sense when there is a "provider." perhaps the automotive exchange network will be an LIR for assigning network numbers to its members, or perhaps not. the term we've probably been looking for is UA (unique address, or universal address) in comparison to IPv6 "site local" or IPv4 RFC1918 (which are nonunique and nonuniversal; sometimes "ambiguous"). everybody needs UA, whether they have a provider or not. some UA's will be in the DFZ and some not, according to the business needs of the network owner. one of those business needs is "nobody will route PI UA for me" or "the cost of routing PI UA is very high" and so, some UA will be PA UA. that's not a RIR issue per se, other than that it may drive policy toward smaller/cheaper UA allocations which all come from some particular /10 so that draconian DFZ router operators can reject these routes if they don't originate in peers. _______________________________________________ This message sent to you through the ARIN Public Policy Mailing List (PPML at arin.net). Manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml From filiz at ripe.net Mon Jun 11 11:28:34 2007 From: filiz at ripe.net (Filiz Yilmaz) Date: Mon, 11 Jun 2007 11:28:34 +0200 Subject: [address-policy-wg] 2007-05 Discussion Period extended until 9 July 2007 (IPv6 ULA-Central) Message-ID: <20070611092834.3E6272F583@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 9 July 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 michael.dillon at bt.com Mon Jun 11 11:47:01 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 11 Jun 2007 10:47:01 +0100 Subject: [address-policy-wg] 2007-05 Discussion Period extended until 9 July 2007 (IPv6 ULA-Central) In-Reply-To: <20070611092834.3E6272F583@herring.ripe.net> References: <20070611092834.3E6272F583@herring.ripe.net> Message-ID: > PDP Number: 2007-05 > IPv6 ULA-Central > > Dear Colleagues > > The Discussion Period for the proposal described in 2007-05 > has been extended until 9 July 2007. It disturbs me to see that RIPE is seriously engaged in discussing the implementation of an addressing proposal that the IETF has already rejected. Anyone who supports this proposal AT THIS TIME, is also attacking the current structure of the Regional Internet Registry system and its relationship to IANA, the IETF and ICANN. This is not the time or the place to be discussing central ULA addresses. If the IETF has rejected the idea in the past, then it is up to people to fix their design and take it back to the IETF forums. Regional Internet Registries should not create policy for numbering resources which have not been created by the IETF or delegated to the RIRs by IANA. --Michael Dillon From jeroen at unfix.org Mon Jun 11 11:48:00 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Mon, 11 Jun 2007 10:48:00 +0100 Subject: [address-policy-wg] 2007-05 Discussion Period extended until 9 July 2007 (IPv6 ULA-Central) In-Reply-To: <20070611092834.3E6272F583@herring.ripe.net> References: <20070611092834.3E6272F583@herring.ripe.net> Message-ID: <466D1A50.4040000@spaghetti.zurich.ibm.com> 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 9 July 2007. As the IETF is re-addressing this issue at the moment, I suggest that until they are done re-analyzing and coming to a conclusion that this submission is frozen till that work is done and completed. There are various suggestions already that it might be very possible that IANA directly will provide this service. Next to the more likely result that ULA-C won't even exist due to the many concerns raised already by various operators in the community. Please FREEZE this proposal till all that work is done. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From slz at baycix.de Mon Jun 11 12:43:40 2007 From: slz at baycix.de (Sascha Lenz) Date: Mon, 11 Jun 2007 12:43:40 +0200 Subject: [address-policy-wg] 2007-05 Discussion Period extended until 9 July 2007 (IPv6 ULA-Central) In-Reply-To: <466D1A50.4040000@spaghetti.zurich.ibm.com> References: <20070611092834.3E6272F583@herring.ripe.net> <466D1A50.4040000@spaghetti.zurich.ibm.com> Message-ID: <466D275C.5020807@baycix.de> Hi, Jeroen Massar wrote: > 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 9 July 2007. > > As the IETF is re-addressing this issue at the moment, I suggest that > until they are done re-analyzing and coming to a conclusion that this > submission is frozen till that work is done and completed. > > There are various suggestions already that it might be very possible > that IANA directly will provide this service. Next to the more likely > result that ULA-C won't even exist due to the many concerns raised > already by various operators in the community. > > Please FREEZE this proposal till all that work is done. i second that - quite useless at the time being. That's also a reason i didn't comment on the proposal itself. To get that straight: I do like the fast track on proposals, but this one is a little to premature. ...and on a sidenote: following the various threads on various mailinglists, i - for me - came to the conclusion, that i don't like the idea of ULA-C myself anyways. I will be happy with ULA and "PI". -- ======================================================================== = Sascha Lenz SLZ-RIPE slz at baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ======================================================================== From jordi.palet at consulintel.es Mon Jun 11 12:44:30 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Mon, 11 Jun 2007 12:44:30 +0200 Subject: [address-policy-wg] 2007-05 Discussion Period extended until 9 July 2007 (IPv6 ULA-Central) In-Reply-To: Message-ID: The IETF has never rejected this. It was just postponed. In addition to that, once more, there is nothing in the PDP that precludes for following something that is not IETF RFC, and this has been clear in many emails before this one. Actually whoever is stating something like this at this point, in my opinion is trying to manipulate the PDP. Regards, Jordi > De: > Responder a: > Fecha: Mon, 11 Jun 2007 10:47:01 +0100 > Para: > Conversaci?n: [address-policy-wg] 2007-05 Discussion Period extended until 9 > July 2007 (IPv6 ULA-Central) > Asunto: RE: [address-policy-wg] 2007-05 Discussion Period extended until 9 > July 2007 (IPv6 ULA-Central) > >> PDP Number: 2007-05 >> IPv6 ULA-Central >> >> Dear Colleagues >> >> The Discussion Period for the proposal described in 2007-05 >> has been extended until 9 July 2007. > > It disturbs me to see that RIPE is seriously engaged in discussing the > implementation of an addressing proposal that the IETF has already > rejected. Anyone who supports this proposal AT THIS TIME, is also > attacking the current structure of the Regional Internet Registry system > and its relationship to IANA, the IETF and ICANN. > > This is not the time or the place to be discussing central ULA > addresses. If the IETF has rejected the idea in the past, then it is up > to people to fix their design and take it back to the IETF forums. > Regional Internet Registries should not create policy for numbering > resources which have not been created by the IETF or delegated to the > RIRs by IANA. > > --Michael Dillon > ********************************************** 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 Mon Jun 11 12:47:44 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Mon, 11 Jun 2007 12:47:44 +0200 Subject: [address-policy-wg] 2007-05 Discussion Period extended until 9 July 2007 (IPv6 ULA-Central) In-Reply-To: <466D1A50.4040000@spaghetti.zurich.ibm.com> Message-ID: Hi Jeroen, There is no way in the PDP to "freeze" a discussion. In fact keeping the discussion period extended, and just not being pro-active in the discussion may act as a way to "freeze" it, and that's what I'm trying, but emails like this don't help that path. IANA is just one choice, and as I don't agree is the best one, this is why I'm proposing this policy. When the next version of the ID is released, then you will see an update of the current policy proposal text. Regards, Jordi > De: Jeroen Massar > Organizaci?n: Unfix > Responder a: > Fecha: Mon, 11 Jun 2007 10:48:00 +0100 > Para: > CC: > Asunto: Re: [address-policy-wg] 2007-05 Discussion Period extended until 9 > July 2007 (IPv6 ULA-Central) > > 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 9 July 2007. > > As the IETF is re-addressing this issue at the moment, I suggest that > until they are done re-analyzing and coming to a conclusion that this > submission is frozen till that work is done and completed. > > There are various suggestions already that it might be very possible > that IANA directly will provide this service. Next to the more likely > result that ULA-C won't even exist due to the many concerns raised > already by various operators in the community. > > Please FREEZE this proposal till all that work is done. > > Greets, > Jeroen > ********************************************** 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 jeroen at unfix.org Mon Jun 11 12:56:56 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Mon, 11 Jun 2007 11:56:56 +0100 Subject: [address-policy-wg] 2007-05 Discussion Period extended until 9 July 2007 (IPv6 ULA-Central) In-Reply-To: References: Message-ID: <466D2A78.4030406@spaghetti.zurich.ibm.com> JORDI PALET MARTINEZ wrote: > There is no way in the PDP to "freeze" a discussion. Then we either introduce that notion, or we reject this proposal. > In fact keeping the > discussion period extended, and just not being pro-active in the discussion > may act as a way to "freeze" it, and that's what I'm trying, but emails like > this don't help that path. Instead of claiming that the discussion is extended then simply say that it is frozen. Why try to lie about it by calling it differently? > IANA is just one choice, and as I don't agree is the best one, this is why > I'm proposing this policy. You are currently the only one proposing this policy. > When the next version of the ID is released, then you will see an update of > the current policy proposal text. Then simply FREEZE this current one. Marking it as 'under discussion' is useless as there can't be any discussion about something which is not decided on. JORDI PALET MARTINEZ wrote: > The IETF has never rejected this. It was just postponed. Expired and dropped. Which can be read as rejected. Clearly not enough people in the IETF thought it was useful. > In addition to that, once more, there is nothing in the PDP that > precludes for following something that is not IETF RFC, and this has > been clear in many emails before this one. Most people will actually agree with the simple thing that the RIR's should not do anything that the IETF does not want them to do yet. > Actually whoever is stating something like this at this point, in my > opinion is trying to manipulate the PDP. One does not have to take the wordings that literal. Laws are also applied on a per-case basis, as the PDP is sort of a 'law book' in your eyes, consider this one also on this per-case basis. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From rogerj at jorgensen.no Mon Jun 11 14:44:56 2007 From: rogerj at jorgensen.no (Roger Jorgensen) Date: Mon, 11 Jun 2007 14:44:56 +0200 (CEST) Subject: [address-policy-wg] 2007-05 Discussion Period extended until 9 July 2007 (IPv6 ULA-Central) In-Reply-To: <466D1A50.4040000@spaghetti.zurich.ibm.com> References: <20070611092834.3E6272F583@herring.ripe.net> <466D1A50.4040000@spaghetti.zurich.ibm.com> Message-ID: On Mon, 11 Jun 2007, Jeroen Massar wrote: > 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 9 July 2007. > > As the IETF is re-addressing this issue at the moment, I suggest that > until they are done re-analyzing and coming to a conclusion that this > submission is frozen till that work is done and completed. > > There are various suggestions already that it might be very possible > that IANA directly will provide this service. Next to the more likely > result that ULA-C won't even exist due to the many concerns raised > already by various operators in the community. > > Please FREEZE this proposal till all that work is done. Have to agree with Jeroen on this one, stop this proposal until the other group working on this issue has come up with a statement/conclusion. I strongly supported ULA-C in the begging I have now after read through tons of arguments and mail-threads, and added some time to rethink it changed view, ULA-C is broken without DNS... and if you add DNS you are back to start, it is just like any other address space. See Paul Vixie's post about the same subject. ULA-C is from my point of view broken, we don't need it. It is enough with ULA and UA (unique address, or universal address). The last one include what people call PI and PA address space. Those two are enough. Why? ULA is IPv6 version of RFC1918. UA is regular IP addresses, routed or not, provided independed or not. -- ------------------------------ Roger Jorgensen | - ROJO9-RIPE - RJ85P-NORID roger at jorgensen.no | - IPv6 is The Key! ------------------------------------------------------- From jwkckid1 at ix.netcom.com Mon Jun 11 21:33:14 2007 From: jwkckid1 at ix.netcom.com (jwkckid1 at ix.netcom.com) Date: Mon, 11 Jun 2007 14:33:14 -0500 (GMT-05:00) Subject: [address-policy-wg] 2007-05 Discussion Period extended until 9 July 2007 (IPv6 ULA-Central) Message-ID: <30085258.1181590394981.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> Michael and all, Why not? There are efforts in IPv8 and in china, IPv9. -----Original Message----- >From: michael.dillon at bt.com >Sent: Jun 11, 2007 4:47 AM >To: address-policy-wg at ripe.net >Subject: RE: [address-policy-wg] 2007-05 Discussion Period extended until 9 July 2007 (IPv6 ULA-Central) > >> PDP Number: 2007-05 >> IPv6 ULA-Central >> >> Dear Colleagues >> >> The Discussion Period for the proposal described in 2007-05 >> has been extended until 9 July 2007. > >It disturbs me to see that RIPE is seriously engaged in discussing the >implementation of an addressing proposal that the IETF has already >rejected. Anyone who supports this proposal AT THIS TIME, is also >attacking the current structure of the Regional Internet Registry system >and its relationship to IANA, the IETF and ICANN. > >This is not the time or the place to be discussing central ULA >addresses. If the IETF has rejected the idea in the past, then it is up >to people to fix their design and take it back to the IETF forums. >Regional Internet Registries should not create policy for numbering >resources which have not been created by the IETF or delegated to the >RIRs by IANA. > >--Michael Dillon > Regards, Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 From andy at nosignal.org Tue Jun 12 22:58:53 2007 From: andy at nosignal.org (Andy Davidson) Date: Tue, 12 Jun 2007 21:58:53 +0100 Subject: [address-policy-wg] PI for Not-DNS Anycast. Message-ID: <20084E5A-2EC9-4E73-925D-5C9160610856@nosignal.org> Hi, Can I get the community's thoughts on this, please .. I think we have a well defined policy on what to do when someone needs some PI in order to run an Anycasted DNS service. We set out a family of requirements based on geographic diversity, for instance, that clearly states what should be in place when a request for PI for DNS use is made. What if a company wants to try to deploy an anycasted production service for something which is not DNS ? It could be a proprietary protocol, or something standard like http. Is the community view that they should just deaggregate some of their PA - which I don't like the sound of - or apply for PI in the normal way, and pretend anycast isn't necessarily involved ? Many thanks Andy From slz at baycix.de Tue Jun 12 23:54:05 2007 From: slz at baycix.de (Sascha Lenz) Date: Tue, 12 Jun 2007 23:54:05 +0200 Subject: [address-policy-wg] PI for Not-DNS Anycast. In-Reply-To: <20084E5A-2EC9-4E73-925D-5C9160610856@nosignal.org> References: <20084E5A-2EC9-4E73-925D-5C9160610856@nosignal.org> Message-ID: <466F15FD.9000205@baycix.de> Hi, Andy Davidson wrote: > > Hi, > > Can I get the community's thoughts on this, please .. > > I think we have a well defined policy on what to do when someone needs > some PI in order to run an Anycasted DNS service. We set out a family > of requirements based on geographic diversity, for instance, that > clearly states what should be in place when a request for PI for DNS use > is made. > What if a company wants to try to deploy an anycasted production service > for something which is not DNS ? It could be a proprietary protocol, or > something standard like http. Is the community view that they should > just deaggregate some of their PA - which I don't like the sound of - or > apply for PI in the normal way, and pretend anycast isn't necessarily > involved ? during the first round of discussion on http://www.ripe.net/ripe/policies/proposals/2007-02.html some people already raised their voice about "other anycast services, not being DNS" (see mailinglist archives). The problem is, noone came up with some concrete idea what that might be. You obviously don't have an idea about some concrete example either. ==> Currently it doesn't look like there is a need to discuss this as long as noone needs it because all this in only theoretically - is it?. If you have a concrete idea about another setup not related to DNS where Anycast is very helpful or needed, feel free to create another policy proposal which deals with it. If you only want to "try to deploy" like you write, there is http://www.ripe.net/ripe/docs/ipv4-policies.html#8 and http://www.ripe.net/ripe/docs/ipv6policy.html#experiment-assignments already. One can play with that and develop requirements for a new Anycast policy based on the results. ...my 0.02EUR - please don't shoot me if i forgot about some shiny new Anycast solution for some technique that actually already exists -- ======================================================================== = Sascha Lenz SLZ-RIPE slz at baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ======================================================================== From andy at nosignal.org Tue Jun 12 23:59:57 2007 From: andy at nosignal.org (Andy Davidson) Date: Tue, 12 Jun 2007 22:59:57 +0100 Subject: [address-policy-wg] PI for Not-DNS Anycast. In-Reply-To: <466F15FD.9000205@baycix.de> References: <20084E5A-2EC9-4E73-925D-5C9160610856@nosignal.org> <466F15FD.9000205@baycix.de> Message-ID: On 12 Jun 2007, at 22:54, Sascha Lenz wrote: > Andy Davidson wrote: >> What if a company wants to try to deploy an anycasted production >> service for something which is not DNS ? It could be a >> proprietary protocol, or something standard like http. Is the >> community view that they should just deaggregate some of their PA >> - which I don't like the sound of - or apply for PI in the normal >> way, and pretend anycast isn't necessarily involved ? > The problem is, noone came up with some concrete idea what that > might be. You obviously don't have an idea about some concrete > example either. Actually my customer wants to try to anycast streaming audio media. It seems to work in the lab, We want to deploy in the wild now. Andy From Joao_Damas at isc.org Tue Jun 12 23:23:38 2007 From: Joao_Damas at isc.org (Joao Damas) Date: Tue, 12 Jun 2007 23:23:38 +0200 Subject: [address-policy-wg] PI for Not-DNS Anycast. In-Reply-To: <20084E5A-2EC9-4E73-925D-5C9160610856@nosignal.org> References: <20084E5A-2EC9-4E73-925D-5C9160610856@nosignal.org> Message-ID: <2B3F2AFF-572C-458D-9FDD-6FDA6A052D8C@isc.org> On 12 Jun 2007, at 22:58, Andy Davidson wrote: > > Hi, > > Can I get the community's thoughts on this, please .. > > I think we have a well defined policy on what to do when someone > needs some PI in order to run an Anycasted DNS service. We set out > a family of requirements based on geographic diversity, for > instance, that clearly states what should be in place when a > request for PI for DNS use is made. > > What if a company wants to try to deploy an anycasted production > service for something which is not DNS ? It could be a proprietary > protocol, or something standard like http. Is the community view > that they should just deaggregate some of their PA - which I don't > like the sound of - or apply for PI in the normal way, and pretend > anycast isn't necessarily involved ? They could also state their case in this wg. Sounds far more reasonable. Joao Damas From slz at baycix.de Wed Jun 13 00:21:39 2007 From: slz at baycix.de (Sascha Lenz) Date: Wed, 13 Jun 2007 00:21:39 +0200 Subject: [address-policy-wg] PI for Not-DNS Anycast. In-Reply-To: References: <20084E5A-2EC9-4E73-925D-5C9160610856@nosignal.org> <466F15FD.9000205@baycix.de> Message-ID: <466F1C73.7070307@baycix.de> Andy Davidson schrieb: > > On 12 Jun 2007, at 22:54, Sascha Lenz wrote: > >> Andy Davidson wrote: >>> What if a company wants to try to deploy an anycasted production >>> service for something which is not DNS ? It could be a proprietary >>> protocol, or something standard like http. Is the community view >>> that they should just deaggregate some of their PA - which I don't >>> like the sound of - or apply for PI in the normal way, and pretend >>> anycast isn't necessarily involved ? >> The problem is, noone came up with some concrete idea what that might >> be. You obviously don't have an idea about some concrete example either. > > Actually my customer wants to try to anycast streaming audio media. It > seems to work in the lab, We want to deploy in the wild now. that still sounds like an experiment for a new protocol - then follow my suggestion - get them an experiemental assignment. If it works out, suggest a policy. There is no real "legal" way to help you out with the current policies. I don't assume you can justify >250 IPs to get the customer a valid, internet-routable /24-or-smaller assignment (neither PA nor PI since the rules apply to both), and since i strongly hope that it is safe to assume that your customer also developed that for IPv6, you're busted here in any way (no PI assigments in RIPE-land, an additional /48 PA just for that probably not justifyable and probably not really routable worldwide...). OTOH - If you can justify all that amount of address space according to the current policies, you don't have a problem, since the RIRs are not about routing. You don't need their consent to deploy anycast. You just need to follow the policies to get the address space you need. In case of Anycast-DNS the problem is, that you usually only need two IPs - the DNS server and a gateway, which doesn't justify more than a /30 or so :-) Hence, the special policy for Anycast DNS. Due to lack of any real information i'd say ==> Experiment, in my eyes. -- ======================================================================== = Sascha Lenz SLZ-RIPE slz at baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ======================================================================== From swmike at swm.pp.se Wed Jun 13 00:07:44 2007 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 13 Jun 2007 00:07:44 +0200 (CEST) Subject: [address-policy-wg] PI for Not-DNS Anycast. In-Reply-To: <466F15FD.9000205@baycix.de> References: <20084E5A-2EC9-4E73-925D-5C9160610856@nosignal.org> <466F15FD.9000205@baycix.de> Message-ID: On Tue, 12 Jun 2007, Sascha Lenz wrote: > The problem is, noone came up with some concrete idea what that might > be. You obviously don't have an idea about some concrete example either. This is widely used for IRC servers that are prime DDoS targets, either as "anycast" or something that might be called "limitcast", ie a prefix that is only reachable by part of the internet to limit the amount of DDoS drones that can actually send traffic to the prefix in question. -- Mikael Abrahamsson email: swmike at swm.pp.se From peter.galbavy at knowtion.net Wed Jun 13 06:37:34 2007 From: peter.galbavy at knowtion.net (Peter Galbavy) Date: Wed, 13 Jun 2007 05:37:34 +0100 Subject: [address-policy-wg] PI for Not-DNS Anycast. In-Reply-To: <20084E5A-2EC9-4E73-925D-5C9160610856@nosignal.org> References: <20084E5A-2EC9-4E73-925D-5C9160610856@nosignal.org> Message-ID: <466F748E.8050700@knowtion.net> Andy Davidson wrote: > What if a company wants to try to deploy an anycasted production > service for something which is not DNS ? It could be a proprietary > protocol, or something standard like http. Is the community view that > they should just deaggregate some of their PA - which I don't like the > sound of - or apply for PI in the normal way, and pretend anycast > isn't necessarily involved ? I haven't been doing much in this world for a while, but I think that PI space is still the only thing that fulfills the requirement for organisations who wish to establish VPN (IPsec) connections between themselves (as a non BGP/LIR type company) and others. You cannot use PA space as that is not "yours" and cannot be in anyway guarenteed to be around longer than your contract with your ISP (if that) and 1918 space is no good as the RFC cleary states it is not for this kind of thing. Did anything ever come of "solving" this problem since I last mentioned is around 2001 ? First person who says that renumbering, especially between N independent large corporates is feasible should - and I have said this since the 90s - get off the drugs and enter the real world. Peter From andy at nosignal.org Wed Jun 13 09:08:49 2007 From: andy at nosignal.org (Andy Davidson) Date: Wed, 13 Jun 2007 08:08:49 +0100 Subject: [address-policy-wg] PI for Not-DNS Anycast. In-Reply-To: <2B3F2AFF-572C-458D-9FDD-6FDA6A052D8C@isc.org> References: <20084E5A-2EC9-4E73-925D-5C9160610856@nosignal.org> <2B3F2AFF-572C-458D-9FDD-6FDA6A052D8C@isc.org> Message-ID: <463F2AE7-C5D3-4035-ACD0-4757A2065684@nosignal.org> On 12 Jun 2007, at 22:23, Joao Damas wrote: >> I think we have a well defined policy on what to do when someone >> needs some PI in order to run an Anycasted DNS service. We set >> out a family of requirements based on geographic diversity, for >> instance, that clearly states what should be in place when a >> request for PI for DNS use is made. > They could also state their case in this wg. Sounds far more > reasonable. I disagree; its not reasonable for someone to have to state their case for why they need resources on a -wg mailing list. A sponsoring LIR should perform the function of deciding whether an application is appropriate. I'm simply suggesting that there's a hole in current policy (or is there ? Does this resource requirement get covered by 'PI needed to multihome'), that we can look to fill with this real world example. Andy From Joao_Damas at isc.org Wed Jun 13 09:36:23 2007 From: Joao_Damas at isc.org (Joao Damas) Date: Wed, 13 Jun 2007 09:36:23 +0200 Subject: [address-policy-wg] PI for Not-DNS Anycast. In-Reply-To: <463F2AE7-C5D3-4035-ACD0-4757A2065684@nosignal.org> References: <20084E5A-2EC9-4E73-925D-5C9160610856@nosignal.org> <2B3F2AFF-572C-458D-9FDD-6FDA6A052D8C@isc.org> <463F2AE7-C5D3-4035-ACD0-4757A2065684@nosignal.org> Message-ID: <96242214-75D8-48DD-99EC-22A9AC5DB9F4@isc.org> On 13 Jun 2007, at 09:08, Andy Davidson wrote: > > On 12 Jun 2007, at 22:23, Joao Damas wrote: > >>> I think we have a well defined policy on what to do when someone >>> needs some PI in order to run an Anycasted DNS service. We set >>> out a family of requirements based on geographic diversity, for >>> instance, that clearly states what should be in place when a >>> request for PI for DNS use is made. >> They could also state their case in this wg. Sounds far more >> reasonable. > > I disagree; its not reasonable for someone to have to state their > case for why they need resources on a -wg mailing list. A > sponsoring LIR should perform the function of deciding whether an > application is appropriate. Policy is dynamic. If the LIR can't determine whether a request fits current policy or if it doesn't but the LIR would like to evolve policy so that it does, then the discussion needs to take place in the wg. > > I'm simply suggesting that there's a hole in current policy (or is > there ? Does this resource requirement get covered by 'PI needed > to multihome'), that we can look to fill with this real world example. A real world example, needs a real world *specific* example, so provide details of the technical requirements for discussion. Does the proposed use actually work in the real world? Has it been tested, etc? People around here are reasonable. Everyone wants to get their business to work, but the frame for discussion is a technical one, not a marketing one. Joao Damas From leo.vegoda at icann.org Wed Jun 13 10:13:45 2007 From: leo.vegoda at icann.org (Leo Vegoda) Date: Wed, 13 Jun 2007 10:13:45 +0200 Subject: [address-policy-wg] PI for Not-DNS Anycast. In-Reply-To: <466F1C73.7070307@baycix.de> References: <20084E5A-2EC9-4E73-925D-5C9160610856@nosignal.org> <466F15FD.9000205@baycix.de> <466F1C73.7070307@baycix.de> Message-ID: <23A02487-D0C4-492A-9FAB-B65FB6DCF94A@icann.org> On 13 Jun 2007, at 12:21am, Sascha Lenz wrote: [...] >> Actually my customer wants to try to anycast streaming audio >> media. It seems to work in the lab, We want to deploy in the >> wild now. > > that still sounds like an experiment for a new protocol - then > follow my suggestion - get them an experiemental assignment. If it > works out, suggest a policy. That only works if the experiment is for a non-commercial service: "Resources issued must not be used for commercial purposes during or following the conclusion of the experiment." If the service is commercial then it could not benefit from this kind of assignment. If the fees aren't a problem then the easiest way to get the address space might be to sign up as an LIR, get the minimum allocation and break it up. It's not the most elegant solution but it should work. That being said, it would be nice to have a policy that didn't encourage people to do that sort of thing. Regards, -- Leo Vegoda IANA Numbers Liaison From s.steffann at computel.nl Wed Jun 13 10:42:30 2007 From: s.steffann at computel.nl (Sander Steffann) Date: Wed, 13 Jun 2007 10:42:30 +0200 Subject: [address-policy-wg] PI for Not-DNS Anycast. In-Reply-To: References: <20084E5A-2EC9-4E73-925D-5C9160610856@nosignal.org> <466F15FD.9000205@baycix.de> Message-ID: <013201c7ad96$c789b960$dc128953@kantoor.computel.nl> Hi Andy, > > The problem is, noone came up with some concrete idea what that > > might be. You obviously don't have an idea about some concrete > > example either. > > Actually my customer wants to try to anycast streaming audio media. > It seems to work in the lab, We want to deploy in the wild now. Can you give more details of how this works with anycast? I am interested in examples of non-DNS anycast applications. In the past there have been questions about which protocols/applications other than DNS can benefit from anycasting, and you seem to be the first with a concrete example. Thanks, Sander. From swmike at swm.pp.se Wed Jun 13 10:53:01 2007 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 13 Jun 2007 10:53:01 +0200 (CEST) Subject: [address-policy-wg] PI for Not-DNS Anycast. In-Reply-To: <013201c7ad96$c789b960$dc128953@kantoor.computel.nl> References: <20084E5A-2EC9-4E73-925D-5C9160610856@nosignal.org> <466F15FD.9000205@baycix.de> <013201c7ad96$c789b960$dc128953@kantoor.computel.nl> Message-ID: On Wed, 13 Jun 2007, Sander Steffann wrote: > Can you give more details of how this works with anycast? I am > interested in examples of non-DNS anycast applications. In the past > there have been questions about which protocols/applications other than > DNS can benefit from anycasting, and you seem to be the first with a > concrete example. IRC uses a single TCP session and several IRC networks have deployed anycast as a way to limit amount of clients that can potentially ddos a single server. It seems to routing subsystem is stable enough for most users that even long lived TCP sessions as IRC (that might be up for weeks) work well with anycast. It works best with regionally limited announcements though, as these tend to be more stable (direct peering relationships between ISPs). -- Mikael Abrahamsson email: swmike at swm.pp.se From michael.dillon at bt.com Wed Jun 13 11:26:09 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 13 Jun 2007 10:26:09 +0100 Subject: [address-policy-wg] PI for Not-DNS Anycast. In-Reply-To: <466F15FD.9000205@baycix.de> References: <20084E5A-2EC9-4E73-925D-5C9160610856@nosignal.org> <466F15FD.9000205@baycix.de> Message-ID: > some people already raised their voice about "other anycast > services, not being DNS" (see mailinglist archives). > The problem is, noone came up with some concrete idea what > that might be. You obviously don't have an idea about some > concrete example either. I believe that I did give such an example when we discussed this on or about the 10th of May this year. IPv4 Anycast works with any application and any protocol which uses a short-lived connection to serve up information from a relatively static database which has been replicated to many locations. DNS is an example of such an application but not the only possibility. LDAP services could be anycast. Plain old HTTP sites serving static data over short-lived connections can also be anycast. People can design protocols to be anycast-friendly. For instance a long-lived file transfer where missing or delayed packets result in the client sending a NACK, could be done using UDP so that any server in the anycast group would respond to the NACK with the correct data packet. And the protocol would continue to send at least a few packets after not receiving an ACK. Just because some people don't have the imagination to see the possibilities does not mean that RIPE should make restrictive policies that limit innovation in Europe. > ==> Currently it doesn't look like there is a need to discuss > this as long as noone needs it because all this in only > theoretically - is it?. We make policy BEFORE handing out resources. Therefore, the use of the resources has to be somewhat theoretical at the time the policy is made. The current IPv4 anycast policy requires applicants to wast over 99% of their allocation at a time when we are dangerously close to IPv4 exhaustion. This is negligent and we need to correct this. IPv4 anycast allocations should be tied to having a distributed infrastructure in many different locations, not to the use of a specific protocol or specific port number. We should encourage organizations who have IPv4 anycast allocations to offer IPv4 anycast hosting services using their anycast topology. That way we can reduce the waste level, possibly down to zero. --Michael Dillon From slz at baycix.de Wed Jun 13 15:09:54 2007 From: slz at baycix.de (Sascha Lenz) Date: Wed, 13 Jun 2007 15:09:54 +0200 Subject: [address-policy-wg] PI for Not-DNS Anycast. In-Reply-To: <23A02487-D0C4-492A-9FAB-B65FB6DCF94A@icann.org> References: <20084E5A-2EC9-4E73-925D-5C9160610856@nosignal.org> <466F15FD.9000205@baycix.de> <466F1C73.7070307@baycix.de> <23A02487-D0C4-492A-9FAB-B65FB6DCF94A@icann.org> Message-ID: <466FECA2.1040505@baycix.de> Hi, Leo Vegoda wrote: > On 13 Jun 2007, at 12:21am, Sascha Lenz wrote: > > [...] > >>> Actually my customer wants to try to anycast streaming audio media. >>> It seems to work in the lab, We want to deploy in the wild now. >> >> that still sounds like an experiment for a new protocol - then follow >> my suggestion - get them an experiemental assignment. If it works out, >> suggest a policy. > > That only works if the experiment is for a non-commercial service: > > "Resources issued must not be used for commercial purposes during > or following the conclusion of the experiment." > > If the service is commercial then it could not benefit from this kind of > assignment. this is somewhat implicit with "experiment". He wrote "they want to try" - that doesn't sound like anything commercial to me, or probably i'm misguided and it is a fact that todays companies use their customers as beta-testers on a regular basis? ;-) If he'd wrote that they had a *REAL* product and they want to *SELL* it, i wouldn't have come up with the experimental pathway in the first place. > If the fees aren't a problem then the easiest way to get the address > space might be to sign up as an LIR, get the minimum allocation and > break it up. It's not the most elegant solution but it should work. *purr* That's quite a customer-friendly rule-bending in my eyes - it doesn't solve the general "how to justify the size of an assignment needed for routing" issue. They only "half-way right" solution to this in my head sounds like becoming LIR and dedicating a sub-allocation of the PA space you get for Anycast announcement. This way you can seperately announce the Sub-Allocation, and have no problems justifying a routable *assignment* The actual assignment within the sub-allocation can be a /29 then or whatever you really need for the Anycast setup. ...doesn't really sound appealing for me though. > That being said, it would be nice to have a policy that didn't encourage > people to do that sort of thing. Correct. Like i pointed out, if there is a *concrete* need for that, i'm more than happy to have yet another policy on this. -- ======================================================================== = Sascha Lenz SLZ-RIPE slz at baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ======================================================================== From slz at baycix.de Wed Jun 13 15:26:42 2007 From: slz at baycix.de (Sascha Lenz) Date: Wed, 13 Jun 2007 15:26:42 +0200 Subject: [address-policy-wg] PI for Not-DNS Anycast. In-Reply-To: References: <20084E5A-2EC9-4E73-925D-5C9160610856@nosignal.org> <466F15FD.9000205@baycix.de> Message-ID: <466FF092.8080405@baycix.de> Hi, michael.dillon at bt.com wrote: >> some people already raised their voice about "other anycast >> services, not being DNS" (see mailinglist archives). >> The problem is, noone came up with some concrete idea what >> that might be. You obviously don't have an idea about some >> concrete example either. > > I believe that I did give such an example when we discussed this on or > about the 10th of May this year. IPv4 Anycast works with any application my apologies if i missed it. > and any protocol which uses a short-lived connection to serve up > information from a relatively static database which has been replicated > to many locations. DNS is an example of such an application but not the > only possibility. LDAP services could be anycast. Plain old HTTP sites ^^^^^ > serving static data over short-lived connections can also be anycast. ^^^ > People can design protocols to be anycast-friendly. For instance a ^^^ > long-lived file transfer where missing or delayed packets result in the > client sending a NACK, could be done using UDP so that any server in the > anycast group would respond to the NACK with the correct data packet. > And the protocol would continue to send at least a few packets after not > receiving an ACK. > > Just because some people don't have the imagination to see the > possibilities does not mean that RIPE should make restrictive policies > that limit innovation in Europe. I still don't see a point for that. Do you have an implementation? (besides IRC :-) You can develop much, but as long as it's not there, why the need for a policy on that? Do we really want a very very vague policy? Last time i checked, i was told that RIPE NCC doesn't like vague policies. Again, do you have a real world example? Why isn't the policy about experimental assignments, which is there for IPv4 and IPv6 not enough to get the development started? >> ==> Currently it doesn't look like there is a need to discuss >> this as long as noone needs it because all this in only >> theoretically - is it?. > > We make policy BEFORE handing out resources. Therefore, the use of the ..soo in your eyes, the ULA-C policy proposal was timed right? :-) > resources has to be somewhat theoretical at the time the policy is made. > The current IPv4 anycast policy requires applicants to wast over 99% of > their allocation at a time when we are dangerously close to IPv4 > exhaustion. This is negligent and we need to correct this. IPv4 anycast > allocations should be tied to having a distributed infrastructure in > many different locations, not to the use of a specific protocol or > specific port number. We should encourage organizations who have IPv4 > anycast allocations to offer IPv4 anycast hosting services using their > anycast topology. That way we can reduce the waste level, possibly down > to zero. OK, i think i need another .. say two /23s and /32s for Anycast usage, i MIGHT deploy it someday in the future, PROBABLY i will anycast my LDAP servers, EVENTUALLY even my HTTP servers and oh yes i do run an IRC Server... and i have some file-transfer protocol in the back of my head that implements anycast, i will DEVELOP that soon, but i need anycast space now so i can test it, i'm not happy with an experimental assignment because i will sell the services right away during my tests! ... sounds ridiculous to me, but probably i'm not in a good mood today since it's Microsoft Patchday. ==> If someone puts up a policy proposal, i'm happy to think about it again. Please don't misunderstand me, but i'm not fond of long theoratical discussions without much outcome. Someone who thinks we need an Any-Anycast policy, please make up a draft! Get the process going so that we will have a policy in place soon. I completely share the opinion that innovation shouldn't be hindered just because i don't see the point here. -- ======================================================================== = Sascha Lenz SLZ-RIPE slz at baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ======================================================================== From michael.dillon at bt.com Wed Jun 13 16:25:26 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 13 Jun 2007 15:25:26 +0100 Subject: [address-policy-wg] PI for Not-DNS Anycast. In-Reply-To: <466FF092.8080405@baycix.de> References: <20084E5A-2EC9-4E73-925D-5C9160610856@nosignal.org> <466F15FD.9000205@baycix.de> <466FF092.8080405@baycix.de> Message-ID: > You can develop much, but as long as it's not there, why the > need for a policy on that? Do we really want a very very vague policy? > Last time i checked, i was told that RIPE NCC doesn't like > vague policies. Very very vague policies are bad. But policies which specify too much irrelevant detail are also bad. The current IPv4 Anycast policy is bad because it says that some DNS servers are special and deserve to have their own PI block without any of the normal technical justification. Also, these special DNS servers are exempt from the usage rules and are allowed to waste over 99% of their block. A good policy would leave DNS out of the criteria because DNS isn't special. If an organization can show that they have many geographically diverse hosting sites where they will host servers using IPv4 Anycast, then we have something similar to the technical justification that other IPv4 users must provide. In addition, we could require these organizations to have a plan for using a reasonable percentage of their PI block within the first year, perhaps 25%. This would mean that they have to do one of two things: 1) Find other DNS providers that want to use IPv4 Anycast and sell them hosting services. 2) Find people who want to pay for IPv4 Anycast hosting services for some other application. Maybe commercial. Maybe experimental. RIPE normally does not care what end users do on the Internet as long as they build real networks and connect real hosts. Doesn't that sound a lot like a normal LIR/ISP who gets a PI allocation and then sells Internet access services to other companies? IPv4 Anycast is a little bit special and does deserve a policy that is tailored to the TECHNICAL REQUIREMENTS OF IMPLEMENTING IPv4 ANYCAST, but it does not deserve a restrictive policy that is anticompetitive and forces companies to lie and cheat RIPE in order to get a PI block. RIPE's current policy treats IPv4 Anycast as a second class citizen unless it is used by the in-group who run DNS servers. > Again, do you have a real world example? Why isn't the policy > about experimental assignments, which is there for IPv4 and > IPv6 not enough to get the development started? Fixing the IPv4 Anycast policy does not prevent you from proposing a good experimental use policy or proposing changes to the IPv6 policies. We can do all of these things at the same time in separate policy proposals. > > We make policy BEFORE handing out resources. Therefore, the > use of the > > ..soo in your eyes, the ULA-C policy proposal was timed right? :-) No because ULA-C resources do not exist. IPv4 Anycast has been described in RFCs since at least 1993. Check RFC 1546 for the first one that I know of. Also, IPv4 Anycast is mentioned in RFC 3068 where it is used as an address for 6to4 Relay Service. So DNS is not the only IPv4 Anycast application that has been currently implemented. It also exists for 6to4 relay. IPv4 Anycast is an old technology (if 14 years is old) which can be applied to a wide range of applications. We should not be blocking the development of such applications by forcing developers to work their way through the policy process in order to simply get a single /32 address. If we had a rational IPv4 Anycast policy, then some service providers with geographically distributed data centers would get an IPv4 Anycast /24 from RIPE and offer /32's to customer who host their IPv4 Anycast application in their data center. > OK, i think i need another .. say two /23s and /32s for > Anycast usage, i MIGHT deploy it someday in the future, Go sign a contract with an Anycast hosting company and pay their monthly fees. I don't care if you ever get your application functioning and RIPE doesn't care either. As long as you have some hosts connected to the Internet in the Anycast ISP hosting centers, they will give you a fully justified /32 from their /24. --Michael Dillon From leo.vegoda at icann.org Wed Jun 13 16:57:25 2007 From: leo.vegoda at icann.org (Leo Vegoda) Date: Wed, 13 Jun 2007 16:57:25 +0200 Subject: [address-policy-wg] PI for Not-DNS Anycast. In-Reply-To: <466FECA2.1040505@baycix.de> References: <20084E5A-2EC9-4E73-925D-5C9160610856@nosignal.org> <466F15FD.9000205@baycix.de> <466F1C73.7070307@baycix.de> <23A02487-D0C4-492A-9FAB-B65FB6DCF94A@icann.org> <466FECA2.1040505@baycix.de> Message-ID: On 13 Jun 2007, at 3:09pm, Sascha Lenz wrote: [...] >> If the fees aren't a problem then the easiest way to get the >> address space might be to sign up as an LIR, get the minimum >> allocation and break it up. It's not the most elegant solution but >> it should work. > > *purr* That's quite a customer-friendly rule-bending in my eyes - > it doesn't solve the general "how to justify the size of an > assignment needed for routing" issue. > > They only "half-way right" solution to this in my head sounds like > becoming LIR and dedicating a sub-allocation of the PA space you > get for Anycast announcement. This way you can seperately announce > the Sub-Allocation, and have no problems justifying a routable > *assignment* > The actual assignment within the sub-allocation can be a /29 then > or whatever you really need for the Anycast setup. > ...doesn't really sound appealing for me though. Yes, routes could be shorter prefixes than assignments. It's certainly not ideal and it probably means the LIR would never qualify for an additional allocation but it would fix a short term problem while there is no policy meeting this need. Regards, -- Leo Vegoda IANA Numbers Liaison From jwkckid1 at ix.netcom.com Thu Jun 14 07:21:55 2007 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Wed, 13 Jun 2007 22:21:55 -0700 Subject: [address-policy-wg] PI for Not-DNS Anycast. References: <20084E5A-2EC9-4E73-925D-5C9160610856@nosignal.org> <466F15FD.9000205@baycix.de> <466F1C73.7070307@baycix.de> <23A02487-D0C4-492A-9FAB-B65FB6DCF94A@icann.org> <466FECA2.1040505@baycix.de> Message-ID: <4670D06D.3FDD1CD@ix.netcom.com> Sascha and all, Well it's clear that ICANN is and has been using consumers as beta testers for some time. So selling nonsense should come as no suprise iregardless of being "Experimental" or not. Sascha Lenz wrote: > Hi, > > Leo Vegoda wrote: > > On 13 Jun 2007, at 12:21am, Sascha Lenz wrote: > > > > [...] > > > >>> Actually my customer wants to try to anycast streaming audio media. > >>> It seems to work in the lab, We want to deploy in the wild now. > >> > >> that still sounds like an experiment for a new protocol - then follow > >> my suggestion - get them an experiemental assignment. If it works out, > >> suggest a policy. > > > > That only works if the experiment is for a non-commercial service: > > > > "Resources issued must not be used for commercial purposes during > > or following the conclusion of the experiment." > > > > If the service is commercial then it could not benefit from this kind of > > assignment. > > this is somewhat implicit with "experiment". He wrote "they want to try" > - that doesn't sound like anything commercial to me, or probably i'm > misguided and it is a fact that todays companies use their customers as > beta-testers on a regular basis? ;-) > If he'd wrote that they had a *REAL* product and they want to *SELL* it, > i wouldn't have come up with the experimental pathway in the first place. > > > If the fees aren't a problem then the easiest way to get the address > > space might be to sign up as an LIR, get the minimum allocation and > > break it up. It's not the most elegant solution but it should work. > > *purr* That's quite a customer-friendly rule-bending in my eyes - it > doesn't solve the general "how to justify the size of an assignment > needed for routing" issue. > > They only "half-way right" solution to this in my head sounds like > becoming LIR and dedicating a sub-allocation of the PA space you get for > Anycast announcement. This way you can seperately announce the > Sub-Allocation, and have no problems justifying a routable *assignment* > The actual assignment within the sub-allocation can be a /29 then or > whatever you really need for the Anycast setup. > ...doesn't really sound appealing for me though. > > > That being said, it would be nice to have a policy that didn't encourage > > people to do that sort of thing. > > Correct. Like i pointed out, if there is a *concrete* need for that, i'm > more than happy to have yet another policy on this. > > -- > ======================================================================== > = Sascha Lenz SLZ-RIPE slz at baycix.de = > = Network Operations = > = BayCIX GmbH, Landshut * PGP public Key on demand * = > ======================================================================== Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 From jeroen at unfix.org Thu Jun 14 12:00:11 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 14 Jun 2007 11:00:11 +0100 Subject: [address-policy-wg] Re: Revising Centrally Assigned ULA draft In-Reply-To: References: Message-ID: <467111AB.20203@spaghetti.zurich.ibm.com> [cc'ing RIPE address policy + ARIN PPML where the discussion on this happened, I have not seen any 'operators' who have said the below, if there are they are there and can thus raise their voices because they will see this message; removed the silly spam scoring subject...] JORDI PALET MARTINEZ wrote: > Operators have said that they will not be able to use ULA, but they could > use ULA-C, for example for thinks like microallocations for internal > infrastructure's. I really wonder where you got that idea, as I know of no such operator who would ever say that. If there are any, let them bring up their argumentation, please don't come up with "somebody said that" it does not work that way. Real network operators, especially involved in the RIPE or other RIR's, have more than enough address space from their PA allocations that they can easily receive and they very well know how to use a /48 from that for internal infrastructure as everybody does this. The IPv6 PA policies even describe that a /48 can be used per POP of the owner of the PA block. Also in the ARIN region any organization can get a /48 PI block for about $100/year, as such these organizations won't be needing this address space either as they can easily take a /64 out of that for those needs. Firewalling is the key here. > I think the policy proposal that I sent to several regions includes text and > links to other documents that can clarify this perspective. > > For example in RIPE NCC: > http://www.ripe.net/ripe/policies/proposals/2007-05.html That is your proposal indeed. No "Operator" has stood behind this and various people from various organizations have clearly asked you and the RIPE NCC to *freeze* this proposal till at least the IETF has worked out. Anybody needing a "globally unique" block can get either PA or PI space. ULA-C as such is useless. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From rogerj at jorgensen.no Thu Jun 14 12:32:18 2007 From: rogerj at jorgensen.no (Roger Jorgensen) Date: Thu, 14 Jun 2007 12:32:18 +0200 (CEST) Subject: [address-policy-wg] Re: Revising Centrally Assigned ULA draft In-Reply-To: <467111AB.20203@spaghetti.zurich.ibm.com> References: <467111AB.20203@spaghetti.zurich.ibm.com> Message-ID: On Thu, 14 Jun 2007, Jeroen Massar wrote: > JORDI PALET MARTINEZ wrote: >> Operators have said that they will not be able to use ULA, but they could >> use ULA-C, for example for thinks like microallocations for internal >> infrastructure's. what operators? I cant remember to have seen one operator supporting that point of view. My point of view from a LIR/network point of view etc was that ULA-C could be usefull but without reverse DNS it is useless. Maybe even with reverse DNS we want todo it the correct way by using our netblock we got from RIPE. -- ------------------------------ Roger Jorgensen | - ROJO9-RIPE - RJ85P-NORID roger at jorgensen.no | - IPv6 is The Key! ------------------------------------------------------- From filiz at ripe.net Thu Jun 14 15:20:24 2007 From: filiz at ripe.net (Filiz Yilmaz) Date: Thu, 14 Jun 2007 15:20:24 +0200 Subject: [address-policy-wg] 2007-04 New Draft Document Published (IANA Policy for Allocation of ASN Blocks to RIRs) Message-ID: <20070614132024.3E1492F599@herring.ripe.net> PDP Number: 2007-04 IANA Policy for Allocation of ASN Blocks to RIRs Dear Colleagues We have published a draft document for the proposal described in 2007-04. 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 and the draft document at: http://www.ripe.net/ripe/draft-documents/2007-04-draft.html We encourage you to read the draft document text and send any comments to address-policy-wg at ripe.net before 12 July 2007. Regards Filiz Yilmaz RIPE NCC Policy Development Officer From filiz at ripe.net Thu Jun 14 15:29:45 2007 From: filiz at ripe.net (Filiz Yilmaz) Date: Thu, 14 Jun 2007 15:29:45 +0200 Subject: [address-policy-wg] Impact Analysis Message-ID: <467142C9.90504@ripe.net> Dear Colleagues, During the Address Policy Working Group session at the RIPE 53 Meeting in 2006, the community supported the idea of having an impact analysis conducted by the RIPE NCC for each policy that has been proposed. The community wanted to know the expected impact that a policy may have if it is eventually accepted. The RIPE NCC will therefore conduct an impact analysis for every policy proposal that moves to the Review Phase of the RIPE Policy Development Process (PDP) from now on. The impact analysis provides projections in the two areas most discussed by the community: A. Impact of the policy on the registry and addressing system - Information will be provided about the possible impact of the proposal on address/Internet number resource consumption and fragmentation/aggregation. B. Impact of the policy on RIPE NCC operations/services The first impact analysis has been created for the proposal 2007-04, IANA Policy for Allocation of ASN Blocks to RIRs. You can view this analysis under 'Additional Information' in this proposal at: http://www.ripe.net/ripe/policies/proposals/2007-04.html Kind regards Filiz Yilmaz RIPE NCC Policy Development Officer From gert at space.net Thu Jun 14 15:58:37 2007 From: gert at space.net (Gert Doering) Date: Thu, 14 Jun 2007 15:58:37 +0200 Subject: [address-policy-wg] PI for Not-DNS Anycast. In-Reply-To: <463F2AE7-C5D3-4035-ACD0-4757A2065684@nosignal.org> References: <20084E5A-2EC9-4E73-925D-5C9160610856@nosignal.org> <2B3F2AFF-572C-458D-9FDD-6FDA6A052D8C@isc.org> <463F2AE7-C5D3-4035-ACD0-4757A2065684@nosignal.org> Message-ID: <20070614135837.GB69215@Space.Net> Hi, On Wed, Jun 13, 2007 at 08:08:49AM +0100, Andy Davidson wrote: > I'm simply suggesting that there's a hole in current policy (or is > there ? Does this resource requirement get covered by 'PI needed to > multihome'), that we can look to fill with this real world example. The current policy doesn't permit assignment of "PI for generic anycast" - mainly because nobody has stood up and said "we plan do to do *this*, and we plan to do it via anycast, and the current policy doesn't work for us!" yet. "Someone might want to use it some day" is *not* a good argument for making policy. 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 gert at space.net Thu Jun 14 16:03:10 2007 From: gert at space.net (Gert Doering) Date: Thu, 14 Jun 2007 16:03:10 +0200 Subject: [address-policy-wg] PI for Not-DNS Anycast. In-Reply-To: References: <20084E5A-2EC9-4E73-925D-5C9160610856@nosignal.org> <466F15FD.9000205@baycix.de> <013201c7ad96$c789b960$dc128953@kantoor.computel.nl> Message-ID: <20070614140310.GC69215@Space.Net> Hi, On Wed, Jun 13, 2007 at 10:53:01AM +0200, Mikael Abrahamsson wrote: > IRC uses a single TCP session and several IRC networks have deployed > anycast as a way to limit amount of clients that can potentially ddos a > single server. Can you point me to some documentation for that? Or some prefixes that have been used for anycasting IRC servers? I'm really curious how well that works. 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 swmike at swm.pp.se Thu Jun 14 16:16:06 2007 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 14 Jun 2007 16:16:06 +0200 (CEST) Subject: [address-policy-wg] PI for Not-DNS Anycast. In-Reply-To: <20070614140310.GC69215@Space.Net> References: <20084E5A-2EC9-4E73-925D-5C9160610856@nosignal.org> <466F15FD.9000205@baycix.de> <013201c7ad96$c789b960$dc128953@kantoor.computel.nl> <20070614140310.GC69215@Space.Net> Message-ID: On Thu, 14 Jun 2007, Gert Doering wrote: > Hi, > > On Wed, Jun 13, 2007 at 10:53:01AM +0200, Mikael Abrahamsson wrote: >> IRC uses a single TCP session and several IRC networks have deployed >> anycast as a way to limit amount of clients that can potentially ddos a >> single server. > > Can you point me to some documentation for that? Or some prefixes that > have been used for anycasting IRC servers? > > I'm really curious how well that works. 194.68.45.0/24. Afaik there are no official documentation. I ran an EFnet irc-server off of a similar /24 for a couple of years and it worked very well. We only announced it to peering partners in scandinavia though, so it was quite limited in announcement. Solved the ddos problem very nicely back then, though. What you cannot reach you cannot ddos. -- Mikael Abrahamsson email: swmike at swm.pp.se From gert at space.net Thu Jun 14 16:23:21 2007 From: gert at space.net (Gert Doering) Date: Thu, 14 Jun 2007 16:23:21 +0200 Subject: [address-policy-wg] PI for Not-DNS Anycast. In-Reply-To: References: <20084E5A-2EC9-4E73-925D-5C9160610856@nosignal.org> <466F15FD.9000205@baycix.de> <013201c7ad96$c789b960$dc128953@kantoor.computel.nl> <20070614140310.GC69215@Space.Net> Message-ID: <20070614142321.GD69215@Space.Net> Hi, On Thu, Jun 14, 2007 at 04:16:06PM +0200, Mikael Abrahamsson wrote: > Solved the ddos problem very nicely back then, though. What you cannot > reach you cannot ddos. But that's not "anycast"... - in my book, anycast is "the same prefix is announced in multiple locations" (which does help against DoS), not "the prefix isn't visible world wide"...? Gert Doering -- NetMaster -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 305 bytes Desc: not available URL: From swmike at swm.pp.se Thu Jun 14 16:30:06 2007 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 14 Jun 2007 16:30:06 +0200 (CEST) Subject: [address-policy-wg] PI for Not-DNS Anycast. In-Reply-To: <20070614142321.GD69215@Space.Net> References: <20084E5A-2EC9-4E73-925D-5C9160610856@nosignal.org> <466F15FD.9000205@baycix.de> <013201c7ad96$c789b960$dc128953@kantoor.computel.nl> <20070614140310.GC69215@Space.Net> <20070614142321.GD69215@Space.Net> Message-ID: On Thu, 14 Jun 2007, Gert Doering wrote: > But that's not "anycast"... - in my book, anycast is "the same prefix is > announced in multiple locations" (which does help against DoS), not "the > prefix isn't visible world wide"...? I never said it was "anycast". I called it "limitcast". DALnet announces the same prefix in several places in an identical fashion as the one I described. So no, it's not anycast as it's not globally reachable. So they have a lot of servers located at the same IP adress in different geographical locations, and depending on which one is closest to you, you'll reach it. There is no guarantee that you'll reach one of the anycasted ones though, as the prefix is not globally reachable. As far as I know there is no name for this, but personally I refer to it as "limitcast". -- Mikael Abrahamsson email: swmike at swm.pp.se From rogerj at jorgensen.no Thu Jun 14 17:53:53 2007 From: rogerj at jorgensen.no (Roger Jorgensen) Date: Thu, 14 Jun 2007 17:53:53 +0200 (CEST) Subject: [address-policy-wg] PI for Not-DNS Anycast. In-Reply-To: <20070614140310.GC69215@Space.Net> References: <20084E5A-2EC9-4E73-925D-5C9160610856@nosignal.org> <466F15FD.9000205@baycix.de> <013201c7ad96$c789b960$dc128953@kantoor.computel.nl> <20070614140310.GC69215@Space.Net> Message-ID: On Thu, 14 Jun 2007, Gert Doering wrote: > Hi, > > On Wed, Jun 13, 2007 at 10:53:01AM +0200, Mikael Abrahamsson wrote: >> IRC uses a single TCP session and several IRC networks have deployed >> anycast as a way to limit amount of clients that can potentially ddos a >> single server. > > Can you point me to some documentation for that? Or some prefixes that > have been used for anycasting IRC servers? > > I'm really curious how well that works. it work very well, and have a look at inetnum: 194.68.45.0 - 194.68.45.255 netname: DALNET descr: DALnet unrouted servers -- ------------------------------ Roger Jorgensen | - ROJO9-RIPE - RJ85P-NORID roger at jorgensen.no | - IPv6 is The Key! ------------------------------------------------------- From mattias at ahnberg.pp.se Thu Jun 14 20:00:13 2007 From: mattias at ahnberg.pp.se (Mattias Ahnberg) Date: Thu, 14 Jun 2007 20:00:13 +0200 Subject: [address-policy-wg] Re: PI for Not-DNS Anycast. Message-ID: <4671822D.5040004@ahnberg.pp.se> > DALnet announces the same prefix in several places in an identical > fashion as the one I described. So no, it's not anycast as it's not > globally reachable. Other than 194.68.45.0/24 that can't be reached from anywhere we also have another netblock (194.14.236.0/24) that CAN be reached from everywhere i.e. more "true anycast". The obvious problem we face is ofcourse when a server dies and a user ends up on another one and the first comes back again they will be disconnected from the latter and forced onto the first. We're not very bothered by this compared to the advantages it gives us. For others it may be too bad of a setup, ofcourse. -- /ahnberg. From lutz at iks-jena.de Thu Jun 14 16:46:57 2007 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Thu, 14 Jun 2007 14:46:57 +0000 (UTC) Subject: [address-policy-wg] PI for Not-DNS Anycast. References: <20070614142321.GD69215@Space.Net> Message-ID: * Gert Doering wrote: > But that's not "anycast"... - in my book, anycast is "the same prefix > is announced in multiple locations" (which does help against DoS), > not "the prefix isn't visible world wide"...? If the (already managed) areas of visible prefixes do not overlap. there is no reason for not announcing the same prefix in all those areas. From marla.azinger at frontiercorp.com Thu Jun 14 19:31:29 2007 From: marla.azinger at frontiercorp.com (Azinger, Marla) Date: Thu, 14 Jun 2007 13:31:29 -0400 Subject: [address-policy-wg] RE: [ppml] Revising Centrally Assigned ULA draft Message-ID: <454810F09B5AA04E9D78D13A5C39028A0272F925@nyrofcs2ke2k01.corp.pvt> I think a point here that needs to be looked at is this: If ULA-C is addressed by IETF and then in turn we end up with RIR's responsible for handing out ULA-C blocks, then those existing policy's such as ARIN's NRPM 6.10.2 Microallocations for Internal Infastructure should be expired and no longer an active policy. And there are different flavors to the debate of why ULA-C would be better than such policy as ARIN's NRPM 6.10.2 Microallocations for Internal Infastructure. Ie Standardization, conservation ect... Cheers! Marla Azinger Frontier Communications -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of Jeroen Massar Sent: Thursday, June 14, 2007 3:00 AM To: jordi.palet at consulintel.es Cc: ARIN People Posting Mailing List; ipv6 at ietf.org; address-policy-wg at ripe.net Subject: Re: [ppml] Revising Centrally Assigned ULA draft [cc'ing RIPE address policy + ARIN PPML where the discussion on this happened, I have not seen any 'operators' who have said the below, if there are they are there and can thus raise their voices because they will see this message; removed the silly spam scoring subject...] JORDI PALET MARTINEZ wrote: > Operators have said that they will not be able to use ULA, but they could > use ULA-C, for example for thinks like microallocations for internal > infrastructure's. I really wonder where you got that idea, as I know of no such operator who would ever say that. If there are any, let them bring up their argumentation, please don't come up with "somebody said that" it does not work that way. Real network operators, especially involved in the RIPE or other RIR's, have more than enough address space from their PA allocations that they can easily receive and they very well know how to use a /48 from that for internal infrastructure as everybody does this. The IPv6 PA policies even describe that a /48 can be used per POP of the owner of the PA block. Also in the ARIN region any organization can get a /48 PI block for about $100/year, as such these organizations won't be needing this address space either as they can easily take a /64 out of that for those needs. Firewalling is the key here. > I think the policy proposal that I sent to several regions includes text and > links to other documents that can clarify this perspective. > > For example in RIPE NCC: > http://www.ripe.net/ripe/policies/proposals/2007-05.html That is your proposal indeed. No "Operator" has stood behind this and various people from various organizations have clearly asked you and the RIPE NCC to *freeze* this proposal till at least the IETF has worked out. Anybody needing a "globally unique" block can get either PA or PI space. ULA-C as such is useless. Greets, Jeroen From narten at us.ibm.com Fri Jun 15 16:19:15 2007 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 15 Jun 2007 10:19:15 -0400 Subject: [address-policy-wg] Re: [ppml] Revising Centrally Assigned ULA draft In-Reply-To: <467111AB.20203@spaghetti.zurich.ibm.com> References: <467111AB.20203@spaghetti.zurich.ibm.com> Message-ID: <200706151419.l5FEJF7f026533@cichlid.raleigh.ibm.com> Jeroen Massar writes: > JORDI PALET MARTINEZ wrote: > > Operators have said that they will not be able to use ULA, but they cou= > ld > > use ULA-C, for example for thinks like microallocations for internal > > infrastructure's. > I really wonder where you got that idea, as I know of no such operator > who would ever say that. If there are any, let them bring up their > argumentation, please don't come up with "somebody said that" it does > not work that way. Maybe the assertion came from those who supported ARIN Policy Proposal 2006-2: Micro-allocations for Internal Infrastructure (http://www.arin.net/policy/proposals/2006_2.html), where using a /48 out of their aggregate did not solve the technical problem at hand. At that time, the question was raised whether ULA-P solved the problem adequately. The answer I heard was a very clear "no". And ULA-C (if had existed then) would have. Thomas From jordi.palet at consulintel.es Fri Jun 15 17:14:43 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Fri, 15 Jun 2007 15:14:43 +0000 Subject: [address-policy-wg] Re: Revising Centrally Assigned ULA draft In-Reply-To: <467111AB.20203@spaghetti.zurich.ibm.com> Message-ID: If you doubt about folks stating anything, then you should read *before* minutes of meetings. I'm now off-line in a plane, so can't point you to a specific URL, but this has been said at least in one ARIN meeting. It has been clear across all this discussion in several exploders, that there are both opinions, people that want ULA-C and people that don't. What you need to be smart here is to realize that those than don't want ULA-C have no any objective reason to oppose to it, because implementing ULA-C has no negative impact in others. While opposing to it has negative impact to all: Folks will use global space (PA or PI) for doing the function of ULA-C an this is a waste, yes a small waste but a waste. It seems to me irresponsible and unbalanced to do or try things like changing the HD-ratio or the default assignment size to end-sites because it is a waste, and then oppose to those that want to have ULA-C, not impacting in others and avoiding one further small saving in global unicast space. I'm not trying to convince anyone about supporting ULA-C, because it seems an impossible mission at least for a few, but at least, don't object to it if having it doesn't force you in any further implications, which is the case. Regards, Jordi > De: Jeroen Massar > Organizaci?n: Unfix > Responder a: > Fecha: Thu, 14 Jun 2007 11:00:11 +0100 > Para: > CC: ARIN People Posting Mailing List , , > "address-policy-wg at ripe.net" > Asunto: Re: Revising Centrally Assigned ULA draft > > [cc'ing RIPE address policy + ARIN PPML where the discussion on this > happened, I have not seen any 'operators' who have said the below, if > there are they are there and can thus raise their voices because they > will see this message; removed the silly spam scoring subject...] > > JORDI PALET MARTINEZ wrote: >> Operators have said that they will not be able to use ULA, but they could >> use ULA-C, for example for thinks like microallocations for internal >> infrastructure's. > > I really wonder where you got that idea, as I know of no such operator > who would ever say that. If there are any, let them bring up their > argumentation, please don't come up with "somebody said that" it does > not work that way. > > Real network operators, especially involved in the RIPE or other RIR's, > have more than enough address space from their PA allocations that they > can easily receive and they very well know how to use a /48 from that > for internal infrastructure as everybody does this. The IPv6 PA policies > even describe that a /48 can be used per POP of the owner of the PA block. > > Also in the ARIN region any organization can get a /48 PI block for > about $100/year, as such these organizations won't be needing this > address space either as they can easily take a /64 out of that for those > needs. Firewalling is the key here. > > >> I think the policy proposal that I sent to several regions includes text and >> links to other documents that can clarify this perspective. >> >> For example in RIPE NCC: >> http://www.ripe.net/ripe/policies/proposals/2007-05.html > > That is your proposal indeed. No "Operator" has stood behind this and > various people from various organizations have clearly asked you and the > RIPE NCC to *freeze* this proposal till at least the IETF has worked out. > > Anybody needing a "globally unique" block can get either PA or PI space. > ULA-C as such is useless. > > Greets, > Jeroen > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6 at ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- ********************************************** 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 Fri Jun 15 18:03:25 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Fri, 15 Jun 2007 16:03:25 +0000 Subject: [address-policy-wg] Re: [ppml] Revising Centrally Assigned ULA draft In-Reply-To: <454810F09B5AA04E9D78D13A5C39028A0272F925@nyrofcs2ke2k01.corp.pvt> Message-ID: Hi Marla, In fact, when I started to work on this, it was because I realized about the possibility to use ULA-C as the space for the microallocations and talking with different folks they said that it will be possible with ULA-C, but not ULA. I also talked with people from the AC and they considered the point (I was told) to use ULA-C for the microallocations when ULA-C is available. So my view is that probably the microallocations policy should not expire, but instead, be modified to make usage of the ULA-C space instead of global unicast. Regards, Jordi > De: "Azinger, Marla" > Responder a: > Fecha: Thu, 14 Jun 2007 13:31:29 -0400 > Para: Jeroen Massar , > CC: ARIN People Posting Mailing List , , > > Conversaci?n: [ppml] Revising Centrally Assigned ULA draft > Asunto: RE: [ppml] Revising Centrally Assigned ULA draft > > I think a point here that needs to be looked at is this: > > If ULA-C is addressed by IETF and then in turn we end up with RIR's > responsible for handing out ULA-C blocks, then those existing policy's such as > ARIN's NRPM 6.10.2 Microallocations for Internal Infastructure should be > expired and no longer an active policy. > > And there are different flavors to the debate of why ULA-C would be better > than such policy as ARIN's NRPM 6.10.2 Microallocations for Internal > Infastructure. Ie Standardization, conservation ect... > > Cheers! > Marla Azinger > Frontier Communications > > > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of > Jeroen Massar > Sent: Thursday, June 14, 2007 3:00 AM > To: jordi.palet at consulintel.es > Cc: ARIN People Posting Mailing List; ipv6 at ietf.org; > address-policy-wg at ripe.net > Subject: Re: [ppml] Revising Centrally Assigned ULA draft > > > [cc'ing RIPE address policy + ARIN PPML where the discussion on this > happened, I have not seen any 'operators' who have said the below, if > there are they are there and can thus raise their voices because they > will see this message; removed the silly spam scoring subject...] > > JORDI PALET MARTINEZ wrote: >> Operators have said that they will not be able to use ULA, but they could >> use ULA-C, for example for thinks like microallocations for internal >> infrastructure's. > > I really wonder where you got that idea, as I know of no such operator > who would ever say that. If there are any, let them bring up their > argumentation, please don't come up with "somebody said that" it does > not work that way. > > Real network operators, especially involved in the RIPE or other RIR's, > have more than enough address space from their PA allocations that they > can easily receive and they very well know how to use a /48 from that > for internal infrastructure as everybody does this. The IPv6 PA policies > even describe that a /48 can be used per POP of the owner of the PA block. > > Also in the ARIN region any organization can get a /48 PI block for > about $100/year, as such these organizations won't be needing this > address space either as they can easily take a /64 out of that for those > needs. Firewalling is the key here. > > >> I think the policy proposal that I sent to several regions includes text and >> links to other documents that can clarify this perspective. >> >> For example in RIPE NCC: >> http://www.ripe.net/ripe/policies/proposals/2007-05.html > > That is your proposal indeed. No "Operator" has stood behind this and > various people from various organizations have clearly asked you and the > RIPE NCC to *freeze* this proposal till at least the IETF has worked out. > > Anybody needing a "globally unique" block can get either PA or PI space. > ULA-C as such is useless. > > Greets, > Jeroen > ********************************************** 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 randy at psg.com Sat Jun 16 00:58:12 2007 From: randy at psg.com (Randy Bush) Date: Fri, 15 Jun 2007 12:58:12 -1000 Subject: [address-policy-wg] Re: [ppml] Revising Centrally Assigned ULA draft In-Reply-To: <20070616081911.0f6dcfef.ipng@69706e6720323030352d30312d31340a.nosense.org> References: <04576D9D-F221-480C-A38E-421D96C3251E@delong.com> <70DE64CEFD6E9A4EB7FAF3A06314106670703C@mail> <20070616081911.0f6dcfef.ipng@69706e6720323030352d30312d31340a.nosense.org> Message-ID: <46731984.3090708@psg.com> > If (non-globally routed) PI is the answer to the ULA-C question, is > there going to be enough (non-globally routed) PI so that I can get a > (non-globally routed) PI allocation for my home, at a small charge for > the guaranteed uniqueness e.g. US$10 per annum ? How about my Personal > Area Network that interconnects my mobile phone, portable music player > and pedometer in my shoes. Will there be enough (non-globally routed) > PI that everybody on the planet who might end up having that sort of > PAN can get a (non-globally routed) PI address allocation, should they > want one ? How about if they want separate allocations for both their > PAN and their home network. these are rir policy and price issues. they are not technical issues. except for routability, which, as smb says, don't think you ain't gonna want to connect it some day; you will. randy From r.bentley at synergyworks.co.uk Sat Jun 16 14:07:49 2007 From: r.bentley at synergyworks.co.uk (Rob Bentley) Date: Sat, 16 Jun 2007 13:07:49 +0100 Subject: [address-policy-wg] help In-Reply-To: <20070616100003.13630.79018.Mailman@postboy.ripe.net> References: <20070616100003.13630.79018.Mailman@postboy.ripe.net> Message-ID: <2E8EF3D9DD9DFC43BBD431E6A00F7BCC05D82F@sw-sr-01.synergyworks.local> -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of address-policy-wg-request at ripe.net Sent: 16 June 2007 11:00 To: address-policy-wg at ripe.net Subject: address-policy-wg digest, Vol 1 #637 - 4 msgs Send address-policy-wg mailing list submissions to address-policy-wg at ripe.net To subscribe or unsubscribe via the World Wide Web, visit http://www.ripe.net/mailman/listinfo/address-policy-wg or, via email, send a message with subject or body 'help' to address-policy-wg-request at ripe.net You can reach the person managing the list at address-policy-wg-admin at ripe.net When replying, please edit your Subject line so it is more specific than "Re: Contents of address-policy-wg digest..." Today's Topics: 1. Re: [ppml] Revising Centrally Assigned ULA draft (Thomas Narten) 2. Re: Revising Centrally Assigned ULA draft (JORDI PALET MARTINEZ) 3. Re: [ppml] Revising Centrally Assigned ULA draft (JORDI PALET MARTINEZ) 4. Re: [ppml] Revising Centrally Assigned ULA draft (Randy Bush) --__--__-- Message: 1 To: Jeroen Massar cc: jordi.palet at consulintel.es, ARIN People Posting Mailing List , ipv6 at ietf.org, "address-policy-wg at ripe.net" Date: Fri, 15 Jun 2007 10:19:15 -0400 From: Thomas Narten Subject: [address-policy-wg] Re: [ppml] Revising Centrally Assigned ULA draft Jeroen Massar writes: > JORDI PALET MARTINEZ wrote: > > Operators have said that they will not be able to use ULA, but they cou= > ld > > use ULA-C, for example for thinks like microallocations for internal > > infrastructure's. > I really wonder where you got that idea, as I know of no such operator > who would ever say that. If there are any, let them bring up their > argumentation, please don't come up with "somebody said that" it does > not work that way. Maybe the assertion came from those who supported ARIN Policy Proposal 2006-2: Micro-allocations for Internal Infrastructure (http://www.arin.net/policy/proposals/2006_2.html), where using a /48 out of their aggregate did not solve the technical problem at hand. At that time, the question was raised whether ULA-P solved the problem adequately. The answer I heard was a very clear "no". And ULA-C (if had existed then) would have. Thomas --__--__-- Message: 2 Date: Fri, 15 Jun 2007 15:14:43 +0000 From: JORDI PALET MARTINEZ To: CC: ARIN People Posting Mailing List , "address-policy-wg at ripe.net" Reply-To: jordi.palet at consulintel.es Subject: [address-policy-wg] Re: Revising Centrally Assigned ULA draft If you doubt about folks stating anything, then you should read *before* minutes of meetings. I'm now off-line in a plane, so can't point you to a specific URL, but this has been said at least in one ARIN meeting. It has been clear across all this discussion in several exploders, that there are both opinions, people that want ULA-C and people that don't. What you need to be smart here is to realize that those than don't want ULA-C have no any objective reason to oppose to it, because implementing ULA-C has no negative impact in others. While opposing to it has negative impact to all: Folks will use global space (PA or PI) for doing the function of ULA-C an this is a waste, yes a small waste but a waste. It seems to me irresponsible and unbalanced to do or try things like changing the HD-ratio or the default assignment size to end-sites because it is a waste, and then oppose to those that want to have ULA-C, not impacting in others and avoiding one further small saving in global unicast space. I'm not trying to convince anyone about supporting ULA-C, because it seems an impossible mission at least for a few, but at least, don't object to it if having it doesn't force you in any further implications, which is the case. Regards, Jordi > De: Jeroen Massar > Organizaci=F3n: Unfix > Responder a: > Fecha: Thu, 14 Jun 2007 11:00:11 +0100 > Para: > CC: ARIN People Posting Mailing List , , > "address-policy-wg at ripe.net" > Asunto: Re: Revising Centrally Assigned ULA draft >=20 > [cc'ing RIPE address policy + ARIN PPML where the discussion on this > happened, I have not seen any 'operators' who have said the below, if > there are they are there and can thus raise their voices because they > will see this message; removed the silly spam scoring subject...] >=20 > JORDI PALET MARTINEZ wrote: >> Operators have said that they will not be able to use ULA, but they could >> use ULA-C, for example for thinks like microallocations for internal >> infrastructure's. >=20 > I really wonder where you got that idea, as I know of no such operator > who would ever say that. If there are any, let them bring up their > argumentation, please don't come up with "somebody said that" it does > not work that way. >=20 > Real network operators, especially involved in the RIPE or other RIR's, > have more than enough address space from their PA allocations that they > can easily receive and they very well know how to use a /48 from that > for internal infrastructure as everybody does this. The IPv6 PA policies > even describe that a /48 can be used per POP of the owner of the PA block. >=20 > Also in the ARIN region any organization can get a /48 PI block for > about $100/year, as such these organizations won't be needing this > address space either as they can easily take a /64 out of that for those > needs. Firewalling is the key here. >=20 >=20 >> I think the policy proposal that I sent to several regions includes text and >> links to other documents that can clarify this perspective. >>=20 >> For example in RIPE NCC: >> http://www.ripe.net/ripe/policies/proposals/2007-05.html >=20 > That is your proposal indeed. No "Operator" has stood behind this and > various people from various organizations have clearly asked you and the > RIPE NCC to *freeze* this proposal till at least the IETF has worked out. >=20 > Anybody needing a "globally unique" block can get either PA or PI space. > ULA-C as such is useless. >=20 > Greets, > Jeroen >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6 at ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- ********************************************** 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. --__--__-- Message: 3 Date: Fri, 15 Jun 2007 16:03:25 +0000 From: JORDI PALET MARTINEZ To: ARIN People Posting Mailing List CC: , Reply-To: jordi.palet at consulintel.es Subject: [address-policy-wg] Re: [ppml] Revising Centrally Assigned ULA draft Hi Marla, In fact, when I started to work on this, it was because I realized about the possibility to use ULA-C as the space for the microallocations and talking with different folks they said that it will be possible with ULA-C, but not ULA. I also talked with people from the AC and they considered the point (I was told) to use ULA-C for the microallocations when ULA-C is available. So my view is that probably the microallocations policy should not expire, but instead, be modified to make usage of the ULA-C space instead of global unicast. Regards, Jordi > De: "Azinger, Marla" > Responder a: > Fecha: Thu, 14 Jun 2007 13:31:29 -0400 > Para: Jeroen Massar , > CC: ARIN People Posting Mailing List , , > > Conversaci=F3n: [ppml] Revising Centrally Assigned ULA draft > Asunto: RE: [ppml] Revising Centrally Assigned ULA draft >=20 > I think a point here that needs to be looked at is this: >=20 > If ULA-C is addressed by IETF and then in turn we end up with RIR's > responsible for handing out ULA-C blocks, then those existing policy's such as > ARIN's NRPM 6.10.2 Microallocations for Internal Infastructure should be > expired and no longer an active policy. >=20 > And there are different flavors to the debate of why ULA-C would be better > than such policy as ARIN's NRPM 6.10.2 Microallocations for Internal > Infastructure. Ie Standardization, conservation ect... >=20 > Cheers! > Marla Azinger > Frontier Communications >=20 >=20 > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of > Jeroen Massar > Sent: Thursday, June 14, 2007 3:00 AM > To: jordi.palet at consulintel.es > Cc: ARIN People Posting Mailing List; ipv6 at ietf.org; > address-policy-wg at ripe.net > Subject: Re: [ppml] Revising Centrally Assigned ULA draft >=20 >=20 > [cc'ing RIPE address policy + ARIN PPML where the discussion on this > happened, I have not seen any 'operators' who have said the below, if > there are they are there and can thus raise their voices because they > will see this message; removed the silly spam scoring subject...] >=20 > JORDI PALET MARTINEZ wrote: >> Operators have said that they will not be able to use ULA, but they could >> use ULA-C, for example for thinks like microallocations for internal >> infrastructure's. >=20 > I really wonder where you got that idea, as I know of no such operator > who would ever say that. If there are any, let them bring up their > argumentation, please don't come up with "somebody said that" it does > not work that way. >=20 > Real network operators, especially involved in the RIPE or other RIR's, > have more than enough address space from their PA allocations that they > can easily receive and they very well know how to use a /48 from that > for internal infrastructure as everybody does this. The IPv6 PA policies > even describe that a /48 can be used per POP of the owner of the PA block. >=20 > Also in the ARIN region any organization can get a /48 PI block for > about $100/year, as such these organizations won't be needing this > address space either as they can easily take a /64 out of that for those > needs. Firewalling is the key here. >=20 >=20 >> I think the policy proposal that I sent to several regions includes text and >> links to other documents that can clarify this perspective. >>=20 >> For example in RIPE NCC: >> http://www.ripe.net/ripe/policies/proposals/2007-05.html >=20 > That is your proposal indeed. No "Operator" has stood behind this and > various people from various organizations have clearly asked you and the > RIPE NCC to *freeze* this proposal till at least the IETF has worked out. >=20 > Anybody needing a "globally unique" block can get either PA or PI space. > ULA-C as such is useless. >=20 > Greets, > Jeroen >=20 ********************************************** 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. --__--__-- Message: 4 Date: Fri, 15 Jun 2007 12:58:12 -1000 From: Randy Bush To: Mark Smith CC: ipv6 at ietf.org, ARIN People Posting Mailing List , address-policy-wg at ripe.net Subject: [address-policy-wg] Re: [ppml] Revising Centrally Assigned ULA draft > If (non-globally routed) PI is the answer to the ULA-C question, is > there going to be enough (non-globally routed) PI so that I can get a > (non-globally routed) PI allocation for my home, at a small charge for > the guaranteed uniqueness e.g. US$10 per annum ? How about my Personal > Area Network that interconnects my mobile phone, portable music player > and pedometer in my shoes. Will there be enough (non-globally routed) > PI that everybody on the planet who might end up having that sort of > PAN can get a (non-globally routed) PI address allocation, should they > want one ? How about if they want separate allocations for both their > PAN and their home network. these are rir policy and price issues. they are not technical issues. except for routability, which, as smb says, don't think you ain't gonna want to connect it some day; you will. randy End of address-policy-wg Digest From jordi.palet at consulintel.es Sat Jun 16 16:38:08 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Sat, 16 Jun 2007 14:38:08 +0000 Subject: [address-policy-wg] Re: [ppml] Revising Centrally Assigned ULA draft In-Reply-To: <454810F09B5AA04E9D78D13A5C39028A023EFACB@nyrofcs2ke2k01.corp.pvt> Message-ID: Hi Marla, Agree, but actually I was wondering, if the AC/board has the power so just modify the policy in order to use ULA-C space, assuming that when the ULA-C becomes available, it offers the same features required by this policy. It may be much easier and faster instead of going thru the PDP all the way. Or even the staff, because this becomes then only an implementation issue (kind of "we usedd prefix xx until now, but ULA-C is available and we can use that space w/o implications on the existing policy itself, same as if we exhaust the initial prefix for this policy and need to start using a new one"). Anyway is something that could be debated when ULA-C is available :-) Regards, Jordi > De: "Azinger, Marla" > Responder a: > Fecha: Fri, 15 Jun 2007 15:14:31 -0400 > Para: , ARIN People Posting Mailing List > > CC: , > Conversaci?n: [ppml] Revising Centrally Assigned ULA draft > Asunto: RE: [ppml] Revising Centrally Assigned ULA draft > > Jordi- We are saying the same thing. Just how you get there is different. > > It is true, we could either modify or eliminate the current ARIN policy to > work in unison with what might be a finsished RFC on ULA-C. I just believe > that sometimes it is easier to start with a fresh policy. In this case, I > think it would be less confusing to expire the current policy and replace it > with a new one that is more fitting as opposed to trying to modify the current > one. A modification could quickly confuse anyone who has not been following > all of the ULA emails and conversations. > > I suppose we can figure this out when we get to that bridge. > > Cheers! > Marla Azinger > Frontier Communications > ARIN AC > > > > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of > JORDI PALET MARTINEZ > Sent: Friday, June 15, 2007 9:03 AM > To: ARIN People Posting Mailing List > Cc: ipv6 at ietf.org; address-policy-wg at ripe.net > Subject: Re: [ppml] Revising Centrally Assigned ULA draft > > > Hi Marla, > > In fact, when I started to work on this, it was because I realized about the > possibility to use ULA-C as the space for the microallocations and talking > with different folks they said that it will be possible with ULA-C, but not > ULA. > > I also talked with people from the AC and they considered the point (I was > told) to use ULA-C for the microallocations when ULA-C is available. > > So my view is that probably the microallocations policy should not expire, > but instead, be modified to make usage of the ULA-C space instead of global > unicast. > > Regards, > Jordi > > > > >> De: "Azinger, Marla" >> Responder a: >> Fecha: Thu, 14 Jun 2007 13:31:29 -0400 >> Para: Jeroen Massar , >> CC: ARIN People Posting Mailing List , , >> >> Conversaci?n: [ppml] Revising Centrally Assigned ULA draft >> Asunto: RE: [ppml] Revising Centrally Assigned ULA draft >> >> I think a point here that needs to be looked at is this: >> >> If ULA-C is addressed by IETF and then in turn we end up with RIR's >> responsible for handing out ULA-C blocks, then those existing policy's such >> as >> ARIN's NRPM 6.10.2 Microallocations for Internal Infastructure should be >> expired and no longer an active policy. >> >> And there are different flavors to the debate of why ULA-C would be better >> than such policy as ARIN's NRPM 6.10.2 Microallocations for Internal >> Infastructure. Ie Standardization, conservation ect... >> >> Cheers! >> Marla Azinger >> Frontier Communications >> >> >> -----Original Message----- >> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >> Jeroen Massar >> Sent: Thursday, June 14, 2007 3:00 AM >> To: jordi.palet at consulintel.es >> Cc: ARIN People Posting Mailing List; ipv6 at ietf.org; >> address-policy-wg at ripe.net >> Subject: Re: [ppml] Revising Centrally Assigned ULA draft >> >> >> [cc'ing RIPE address policy + ARIN PPML where the discussion on this >> happened, I have not seen any 'operators' who have said the below, if >> there are they are there and can thus raise their voices because they >> will see this message; removed the silly spam scoring subject...] >> >> JORDI PALET MARTINEZ wrote: >>> Operators have said that they will not be able to use ULA, but they could >>> use ULA-C, for example for thinks like microallocations for internal >>> infrastructure's. >> >> I really wonder where you got that idea, as I know of no such operator >> who would ever say that. If there are any, let them bring up their >> argumentation, please don't come up with "somebody said that" it does >> not work that way. >> >> Real network operators, especially involved in the RIPE or other RIR's, >> have more than enough address space from their PA allocations that they >> can easily receive and they very well know how to use a /48 from that >> for internal infrastructure as everybody does this. The IPv6 PA policies >> even describe that a /48 can be used per POP of the owner of the PA block. >> >> Also in the ARIN region any organization can get a /48 PI block for >> about $100/year, as such these organizations won't be needing this >> address space either as they can easily take a /64 out of that for those >> needs. Firewalling is the key here. >> >> >>> I think the policy proposal that I sent to several regions includes text and >>> links to other documents that can clarify this perspective. >>> >>> For example in RIPE NCC: >>> http://www.ripe.net/ripe/policies/proposals/2007-05.html >> >> That is your proposal indeed. No "Operator" has stood behind this and >> various people from various organizations have clearly asked you and the >> RIPE NCC to *freeze* this proposal till at least the IETF has worked out. >> >> Anybody needing a "globally unique" block can get either PA or PI space. >> ULA-C as such is useless. >> >> Greets, >> Jeroen >> > > > > > ********************************************** > 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. > > > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml ********************************************** 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 rogerj at jorgensen.no Sat Jun 16 17:24:08 2007 From: rogerj at jorgensen.no (Roger Jorgensen) Date: Sat, 16 Jun 2007 17:24:08 +0200 (CEST) Subject: [address-policy-wg] Re: [ppml] Revising Centrally Assigned ULA draft In-Reply-To: References: Message-ID: On Sat, 16 Jun 2007, JORDI PALET MARTINEZ wrote: > Anyway is something that could be debated when ULA-C is available :-) if ULA-C is available... why are you so sure it will go through and be accepted? not many have supported it so far. Some of those in favour have changed view, me included. -- ------------------------------ Roger Jorgensen | - ROJO9-RIPE - RJ85P-NORID roger at jorgensen.no | - IPv6 is The Key! ------------------------------------------------------- From marla.azinger at frontiercorp.com Fri Jun 15 21:14:31 2007 From: marla.azinger at frontiercorp.com (Azinger, Marla) Date: Fri, 15 Jun 2007 15:14:31 -0400 Subject: [address-policy-wg] RE: [ppml] Revising Centrally Assigned ULA draft Message-ID: <454810F09B5AA04E9D78D13A5C39028A023EFACB@nyrofcs2ke2k01.corp.pvt> Jordi- We are saying the same thing. Just how you get there is different. It is true, we could either modify or eliminate the current ARIN policy to work in unison with what might be a finsished RFC on ULA-C. I just believe that sometimes it is easier to start with a fresh policy. In this case, I think it would be less confusing to expire the current policy and replace it with a new one that is more fitting as opposed to trying to modify the current one. A modification could quickly confuse anyone who has not been following all of the ULA emails and conversations. I suppose we can figure this out when we get to that bridge. Cheers! Marla Azinger Frontier Communications ARIN AC -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of JORDI PALET MARTINEZ Sent: Friday, June 15, 2007 9:03 AM To: ARIN People Posting Mailing List Cc: ipv6 at ietf.org; address-policy-wg at ripe.net Subject: Re: [ppml] Revising Centrally Assigned ULA draft Hi Marla, In fact, when I started to work on this, it was because I realized about the possibility to use ULA-C as the space for the microallocations and talking with different folks they said that it will be possible with ULA-C, but not ULA. I also talked with people from the AC and they considered the point (I was told) to use ULA-C for the microallocations when ULA-C is available. So my view is that probably the microallocations policy should not expire, but instead, be modified to make usage of the ULA-C space instead of global unicast. Regards, Jordi > De: "Azinger, Marla" > Responder a: > Fecha: Thu, 14 Jun 2007 13:31:29 -0400 > Para: Jeroen Massar , > CC: ARIN People Posting Mailing List , , > > Conversaci?n: [ppml] Revising Centrally Assigned ULA draft > Asunto: RE: [ppml] Revising Centrally Assigned ULA draft > > I think a point here that needs to be looked at is this: > > If ULA-C is addressed by IETF and then in turn we end up with RIR's > responsible for handing out ULA-C blocks, then those existing policy's such as > ARIN's NRPM 6.10.2 Microallocations for Internal Infastructure should be > expired and no longer an active policy. > > And there are different flavors to the debate of why ULA-C would be better > than such policy as ARIN's NRPM 6.10.2 Microallocations for Internal > Infastructure. Ie Standardization, conservation ect... > > Cheers! > Marla Azinger > Frontier Communications > > > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of > Jeroen Massar > Sent: Thursday, June 14, 2007 3:00 AM > To: jordi.palet at consulintel.es > Cc: ARIN People Posting Mailing List; ipv6 at ietf.org; > address-policy-wg at ripe.net > Subject: Re: [ppml] Revising Centrally Assigned ULA draft > > > [cc'ing RIPE address policy + ARIN PPML where the discussion on this > happened, I have not seen any 'operators' who have said the below, if > there are they are there and can thus raise their voices because they > will see this message; removed the silly spam scoring subject...] > > JORDI PALET MARTINEZ wrote: >> Operators have said that they will not be able to use ULA, but they could >> use ULA-C, for example for thinks like microallocations for internal >> infrastructure's. > > I really wonder where you got that idea, as I know of no such operator > who would ever say that. If there are any, let them bring up their > argumentation, please don't come up with "somebody said that" it does > not work that way. > > Real network operators, especially involved in the RIPE or other RIR's, > have more than enough address space from their PA allocations that they > can easily receive and they very well know how to use a /48 from that > for internal infrastructure as everybody does this. The IPv6 PA policies > even describe that a /48 can be used per POP of the owner of the PA block. > > Also in the ARIN region any organization can get a /48 PI block for > about $100/year, as such these organizations won't be needing this > address space either as they can easily take a /64 out of that for those > needs. Firewalling is the key here. > > >> I think the policy proposal that I sent to several regions includes text and >> links to other documents that can clarify this perspective. >> >> For example in RIPE NCC: >> http://www.ripe.net/ripe/policies/proposals/2007-05.html > > That is your proposal indeed. No "Operator" has stood behind this and > various people from various organizations have clearly asked you and the > RIPE NCC to *freeze* this proposal till at least the IETF has worked out. > > Anybody needing a "globally unique" block can get either PA or PI space. > ULA-C as such is useless. > > Greets, > Jeroen > ********************************************** 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. _______________________________________________ This message sent to you through the ARIN Public Policy Mailing List (PPML at arin.net). Manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml From owen at delong.com Fri Jun 15 21:40:52 2007 From: owen at delong.com (Owen DeLong) Date: Fri, 15 Jun 2007 12:40:52 -0700 Subject: [address-policy-wg] Re: [ppml] Revising Centrally Assigned ULA draft In-Reply-To: References: Message-ID: <04576D9D-F221-480C-A38E-421D96C3251E@delong.com> On Jun 15, 2007, at 8:14 AM, JORDI PALET MARTINEZ wrote: > If you doubt about folks stating anything, then you should read > *before* > minutes of meetings. I'm now off-line in a plane, so can't point > you to a > specific URL, but this has been said at least in one ARIN meeting. > > It has been clear across all this discussion in several exploders, > that > there are both opinions, people that want ULA-C and people that > don't. What > you need to be smart here is to realize that those than don't want > ULA-C > have no any objective reason to oppose to it, because implementing > ULA-C has > no negative impact in others. While opposing to it has negative > impact to > all: Folks will use global space (PA or PI) for doing the function > of ULA-C > an this is a waste, yes a small waste but a waste. > Jordi, You have this backwards. Using PI for the purposes of ULA-C is no waste at all. Sectioning off a huge chunk of address space for ULA-C is the waste. If it's all PI, then, it can seamlessly move between being unrouted or routed as the address-holder sees fit and as needs change. If it is set aside as ULA, then, the address space is forever wasted and cannot (theoretically) be used as routable space, no matter how little of it is needed for ULA-C. Those of us who oppose ULA-C have what we believe to be an objective position that it provides no additional benefit over PI space while simultaneously creating some unnecessary classification of addresses that makes their status in the routing table ill-defined at best. In our opinion, this carries the potential for significant consequences globally. Just because we do not agree with you does not mean that our concerns are not legitimate. Do I think UUNET and others should be able to get secondary microallocations to solve the problem they presented? Absolutely. Do I think that we need to set aside a /8, /12, /16, or whatever separate from the rest of PI space to do it? No. We should just issue them a /48 or whatever it is they need from the general pool of available PI space and be done with it. No waste at all. No negative consequences to anyone. No ambiguous status as to where you can or can't route the addresses, etc. Owen From kkargel at polartel.com Fri Jun 15 22:13:40 2007 From: kkargel at polartel.com (Kevin Kargel) Date: Fri, 15 Jun 2007 15:13:40 -0500 Subject: [address-policy-wg] RE: [ppml] Revising Centrally Assigned ULA draft In-Reply-To: <04576D9D-F221-480C-A38E-421D96C3251E@delong.com> Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106670703C@mail> I agree wholeheartedly. There is nothing you can do with ULA-C that you can't do with PI and a minor firewall rule or two. Leaving the space as PI gives it either-or capability, putting it as ULA reduces PI. (And don't talk about 'more PI than we could ever use'.. remember when Mr. Gates told us you would never need more than 640K of RAM?)(of course he denies it now..) > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Owen DeLong > Sent: Friday, June 15, 2007 2:41 PM > To: jordi.palet at consulintel.es > Cc: ARIN People Posting Mailing List; ipv6 at ietf.org; > address-policy-wg at ripe.net > Subject: Re: [ppml] Revising Centrally Assigned ULA draft > > > On Jun 15, 2007, at 8:14 AM, JORDI PALET MARTINEZ wrote: > > > If you doubt about folks stating anything, then you should read > > *before* > > minutes of meetings. I'm now off-line in a plane, so can't > point you > > to a specific URL, but this has been said at least in one ARIN > > meeting. > > > > It has been clear across all this discussion in several exploders, > > that there are both opinions, people that want ULA-C and > people that > > don't. What you need to be smart here is to realize that those than > > don't want ULA-C have no any objective reason to oppose to > it, because > > implementing ULA-C has no negative impact in others. While > opposing to > > it has negative impact to > > all: Folks will use global space (PA or PI) for doing the > function of > > ULA-C an this is a waste, yes a small waste but a waste. > > > Jordi, > You have this backwards. Using PI for the purposes of > ULA-C is no waste at all. Sectioning off a huge chunk of > address space for ULA-C is the waste. > If it's all PI, then, it can seamlessly move between being > unrouted or routed as the address-holder sees fit and as > needs change. If it is set aside as ULA, then, the address > space is forever wasted and cannot (theoretically) be used as > routable space, no matter how little of it is needed for ULA-C. > > Those of us who oppose ULA-C have what we believe to be > an objective position that it provides no additional benefit > over PI space while simultaneously creating some unnecessary > classification of addresses that makes their status in the > routing table ill-defined at best. In our opinion, this > carries the potential for significant consequences globally. > > Just because we do not agree with you does not mean > that our concerns are not legitimate. > > Do I think UUNET and others should be able to get > secondary microallocations to solve the problem they > presented? Absolutely. Do I think that we need to set aside > a /8, /12, /16, or whatever separate from the rest of PI > space to do it? No. > We should just issue them a /48 or whatever it is they need > from the general pool of available PI space and be done with > it. No waste at all. No negative consequences to anyone. > No ambiguous status as to where you can or can't route the > addresses, etc. > > Owen > > _______________________________________________ > This message sent to you through the ARIN Public Policy > Mailing List (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > From ipng at 69706e6720323030352d30312d31340a.nosense.org Sat Jun 16 00:49:11 2007 From: ipng at 69706e6720323030352d30312d31340a.nosense.org (Mark Smith) Date: Sat, 16 Jun 2007 08:19:11 +0930 Subject: [address-policy-wg] Re: [ppml] Revising Centrally Assigned ULA draft In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106670703C@mail> References: <04576D9D-F221-480C-A38E-421D96C3251E@delong.com> <70DE64CEFD6E9A4EB7FAF3A06314106670703C@mail> Message-ID: <20070616081911.0f6dcfef.ipng@69706e6720323030352d30312d31340a.nosense.org> On Fri, 15 Jun 2007 15:13:40 -0500 "Kevin Kargel" wrote: > I agree wholeheartedly. There is nothing you can do with ULA-C that you > can't do with PI and a minor firewall rule or two. Leaving the space as > PI gives it either-or capability, putting it as ULA reduces PI. (And > don't talk about 'more PI than we could ever use'.. remember when Mr. > Gates told us you would never need more than 640K of RAM?)(of course he > denies it now..) > > I understand that that was an IBM design decision - they chose to allow 384KB out of the 1MB of address space of the 8086/8088 for option ROMs for add-in cards. That decision was made during the design of the original IBM PC (i.e. the one before the XT), which originally came with 16KB of RAM (and a audio cassette interface for storage, no serial ports or printer ports, and a monochrome 4KB text adaptor). Allowing 384KB for option ROMs allowed for plenty of IO card expansion, because the platform was initially very barebones, and 640KB was extremely large amount of RAM at the time. The OS at the time didn't provide device drivers, unlike today's OSes - the option ROMs was were that functionality resided. When you look at that problem, at the time it was addressed, the 640KB/384KB boundary seems, at least to me, to be quite reasonable. The IBM PC architecture was never expected to (a) set an industry standard and (b) ever last as long as it has. Gates was unlikely to have ever been consulted on it, or conversely, was only ever agreeing with a decision that had already been made. Don't use this (mis)quote as a lack of design foresight, use it as an example of wildly unexpected success. IPv6 doesn't have the addressing quantity constraints that IPv4 has, so allow for wildly different and expanded uses of it and it's large address space. As a general example of how IPv6's "large" addressing could be used, look at Ethernet. Nobody needs 2^47 unicast addresses on a LAN segment. We "waste" millions of addresses everytime we enable a new LAN segment. The Ethernet address space we "waste" when a point to point ethernet link is brought up is the most "obscene" amount of address space "waste" I've ever seen in my life - because a point-to-point link doesn't even need addressing - the frame is either for this end or the other end. So what has all that "wasted" Ethernet address space got us ? _Convenience_ It is convenient that we can plug an Ethernet card in and not have to worry about configuring addresses or addressing collisions. Non-technical people can buy a network card at the local electrical store, plug it into their computer, and the ethernet functionality work (installing device drivers is obviously not a problem that ethernet attemps to solve). It's the original "plug-and-play". With Ethernet, we get a lot of convenience at the cheap price of 32 or so bits of "wasted" address space (on the rough assumption that nobody would ever build an ethernet segment with more than 65K nodes), or 64 bits in each packet. Here's what the people who chose 48 bit addressing for Ethernet said about the decision : "48-bit host numbers lead to large Ethernet and internet packets. We believe that this will not pose a problem as both local and public data networks continue to offer higher bandwidths at reasonable costs, and the memory and logic costs associated with storing and processing these numbers continue to become lower with the advances in LSI technology." ("48-bit Absolute Internet and Ethernet Host Numbers", Yogan K. Dalal and Robert S. Printis - definately worth a read) When did they say it ? 1981! 26 years ago! The problem with applying an IPv4 mentality to an IPv6 addressing problem is that IPv4 hasn't been an abundant resource for 15 or so years. We've had to give up operational convenience with it because we needed to ensure functionality as the Internet grew. When it came to the crunch, convenience had to be sacrificed. IPv6 address space is abundant, so we can now go back to placing value on operational convenience. All we need to do is ensure there isn't any reckless use of IPv6's address space. So, getting back to the ULA topic : If (non-globally routed) PI is the answer to the ULA-C question, is there going to be enough (non-globally routed) PI so that I can get a (non-globally routed) PI allocation for my home, at a small charge for the guaranteed uniqueness e.g. US$10 per annum ? How about my Personal Area Network that interconnects my mobile phone, portable music player and pedometer in my shoes. Will there be enough (non-globally routed) PI that everybody on the planet who might end up having that sort of PAN can get a (non-globally routed) PI address allocation, should they want one ? How about if they want separate allocations for both their PAN and their home network. If the answer is no, then (non-globally routed) PI it isn't solving the ULA/ULA-C problem. > > > -----Original Message----- > > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > > Behalf Of Owen DeLong > > Sent: Friday, June 15, 2007 2:41 PM > > To: jordi.palet at consulintel.es > > Cc: ARIN People Posting Mailing List; ipv6 at ietf.org; > > address-policy-wg at ripe.net > > Subject: Re: [ppml] Revising Centrally Assigned ULA draft > > > > > > On Jun 15, 2007, at 8:14 AM, JORDI PALET MARTINEZ wrote: > > > > > If you doubt about folks stating anything, then you should read > > > *before* > > > minutes of meetings. I'm now off-line in a plane, so can't > > point you > > > to a specific URL, but this has been said at least in one ARIN > > > meeting. > > > > > > It has been clear across all this discussion in several exploders, > > > that there are both opinions, people that want ULA-C and > > people that > > > don't. What you need to be smart here is to realize that those than > > > don't want ULA-C have no any objective reason to oppose to > > it, because > > > implementing ULA-C has no negative impact in others. While > > opposing to > > > it has negative impact to > > > all: Folks will use global space (PA or PI) for doing the > > function of > > > ULA-C an this is a waste, yes a small waste but a waste. > > > > > Jordi, > > You have this backwards. Using PI for the purposes of > > ULA-C is no waste at all. Sectioning off a huge chunk of > > address space for ULA-C is the waste. > > If it's all PI, then, it can seamlessly move between being > > unrouted or routed as the address-holder sees fit and as > > needs change. If it is set aside as ULA, then, the address > > space is forever wasted and cannot (theoretically) be used as > > routable space, no matter how little of it is needed for ULA-C. > > > > Those of us who oppose ULA-C have what we believe to be > > an objective position that it provides no additional benefit > > over PI space while simultaneously creating some unnecessary > > classification of addresses that makes their status in the > > routing table ill-defined at best. In our opinion, this > > carries the potential for significant consequences globally. > > > > Just because we do not agree with you does not mean > > that our concerns are not legitimate. > > > > Do I think UUNET and others should be able to get > > secondary microallocations to solve the problem they > > presented? Absolutely. Do I think that we need to set aside > > a /8, /12, /16, or whatever separate from the rest of PI > > space to do it? No. > > We should just issue them a /48 or whatever it is they need > > from the general pool of available PI space and be done with > > it. No waste at all. No negative consequences to anyone. > > No ambiguous status as to where you can or can't route the > > addresses, etc. > > > > Owen > > > > _______________________________________________ > > This message sent to you through the ARIN Public Policy > > Mailing List (PPML at arin.net). > > Manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/ppml > > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml From stephen at sprunk.org Mon Jun 18 03:37:12 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Sun, 17 Jun 2007 20:37:12 -0500 Subject: [address-policy-wg] Re: [ppml] Revising Centrally Assigned ULA draft References: Message-ID: <016601c7b14c$3601d8b0$6701a8c0@atlanta.polycom.com> Thus spake "JORDI PALET MARTINEZ" > Agree, but actually I was wondering, if the AC/board has the power > so just modify the policy in order to use ULA-C space, assuming > that when the ULA-C becomes available, it offers the same > features required by this policy. It may be much easier and faster > instead of going thru the PDP all the way. This sounds suspiciously like "I don't seem to have the support of the community, so I wonder if the Board/AC can ignore the process and do what I want anyways." I don't know whether or not they can do that; it doesn't seem possible, but there's probably a loophole or two. However, given the vocal opposition to the proposal (and the very existence of ULA-C), I doubt you'd ever convince them to if they could. It's one thing to sneak through something that nobody cares about either way, but it's entirely different to deliberately exclude the community on something so divisive. > Anyway is something that could be debated when ULA-C is > available :-) If you seriously propose doing the above, I suspect you'll manage to alienate even the folks who agree with ULA-C. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From gert at space.net Mon Jun 18 18:09:11 2007 From: gert at space.net (Gert Doering) Date: Mon, 18 Jun 2007 18:09:11 +0200 Subject: [address-policy-wg] Re: [ppml] Revising Centrally Assigned ULA draft In-Reply-To: <20070616081911.0f6dcfef.ipng@69706e6720323030352d30312d31340a.nosense.org> References: <04576D9D-F221-480C-A38E-421D96C3251E@delong.com> <70DE64CEFD6E9A4EB7FAF3A06314106670703C@mail> <20070616081911.0f6dcfef.ipng@69706e6720323030352d30312d31340a.nosense.org> Message-ID: <20070618160911.GE69215@Space.Net> Hi, On Sat, Jun 16, 2007 at 08:19:11AM +0930, Mark Smith wrote: > If (non-globally routed) PI is the answer to the ULA-C question, is > there going to be enough (non-globally routed) PI so that I can get a > (non-globally routed) PI allocation for my home, at a small charge for > the guaranteed uniqueness e.g. US$10 per annum ? How about my Personal > Area Network that interconnects my mobile phone, portable music player > and pedometer in my shoes. Will there be enough (non-globally routed) > PI that everybody on the planet who might end up having that sort of > PAN can get a (non-globally routed) PI address allocation, should they > want one ? How about if they want separate allocations for both their > PAN and their home network. > > If the answer is no, then (non-globally routed) PI it isn't solving the > ULA/ULA-C problem. Something to consider for the folks that reject ULA-C because "PI would do the job". There is quite a number of people out there that are quite sceptic about PI space - and really do not want to make access to PI space easy and convenient. Consider me one of those - globally routed PI space puts burden on everybody else, so this should be well-considered, and putting some hurdles in people's way might make them reconsider whether they really want PI or not. The "non-routed globally unique address thing", however it is called, should be *very very very* easy to get - I would prefer to see a one-up fee here, but if there is registry service tacked to it, I could live with a small(!) yearly fee. This is where I see the benefit of ULA-C - address space that is unique, and doesn't need artificial obstacles to keep the number of occurances in the routing system low. (Of course this whole debate would immediately stop if the *routing crowd* would stop to offload their problems to address policy. From a pure address policy point of view, I could care less if folks get "a /48" from PA, PI, or ULA space - it's address consumption, and the type of address doesn't matter anything. Routing is hurt, but I see no resonable way (today) to put a global tax on each advertised prefix - which would achieve the "convenience" <-> "global cost" balancing...) Gert Doering -- NetMaster -- 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 andy at nosignal.org Mon Jun 18 18:13:39 2007 From: andy at nosignal.org (Andy Davidson) Date: Mon, 18 Jun 2007 17:13:39 +0100 Subject: [address-policy-wg] PI (was: Revising Centrally Assigned ULA draft) In-Reply-To: <20070618160911.GE69215@Space.Net> References: <04576D9D-F221-480C-A38E-421D96C3251E@delong.com> <70DE64CEFD6E9A4EB7FAF3A06314106670703C@mail> <20070616081911.0f6dcfef.ipng@69706e6720323030352d30312d31340a.nosense.org> <20070618160911.GE69215@Space.Net> Message-ID: <2B529CB9-2E38-4820-A8CC-F46E1C3ADE02@nosignal.org> On 18 Jun 2007, at 17:09, Gert Doering wrote: > There is quite a number of people out there that are quite sceptic > about PI space - and really do not want to make access to PI space > easy and convenient. Consider me one of those - globally routed PI > space puts burden on everybody else, so this should be well- > considered, and putting some hurdles in people's way might make > them reconsider whether they really want PI or not. What, you'd rather people deagg their PA in order to let their customers multi-home ? > Total number of prefixes smaller than registry allocations: 113403 ... because it doesn't look like you prefer that at all .... From gert at space.net Mon Jun 18 18:33:51 2007 From: gert at space.net (Gert Doering) Date: Mon, 18 Jun 2007 18:33:51 +0200 Subject: [address-policy-wg] PI (was: Revising Centrally Assigned ULA draft) In-Reply-To: <2B529CB9-2E38-4820-A8CC-F46E1C3ADE02@nosignal.org> References: <04576D9D-F221-480C-A38E-421D96C3251E@delong.com> <70DE64CEFD6E9A4EB7FAF3A06314106670703C@mail> <20070616081911.0f6dcfef.ipng@69706e6720323030352d30312d31340a.nosense.org> <20070618160911.GE69215@Space.Net> <2B529CB9-2E38-4820-A8CC-F46E1C3ADE02@nosignal.org> Message-ID: <20070618163351.GG69215@Space.Net> Hi, On Mon, Jun 18, 2007 at 05:13:39PM +0100, Andy Davidson wrote: > On 18 Jun 2007, at 17:09, Gert Doering wrote: > > >There is quite a number of people out there that are quite sceptic > >about PI space - and really do not want to make access to PI space > >easy and convenient. Consider me one of those - globally routed PI > >space puts burden on everybody else, so this should be well- > >considered, and putting some hurdles in people's way might make > >them reconsider whether they really want PI or not. > > What, you'd rather people deagg their PA in order to let their > customers multi-home ? Of course not. But multi-homing customers are only one facet of the picture - the other side is customers that just find it inconvenient to renumber when changing providers, so they go for PI, if that is more convenient (and we see this already happening in IPv4 in Europe - PI assignment rates have been going way up in recent years). Given current multi-homing technology (BGP), the number of participants doing BGP-style multi-homing is "somewhat limited" (because not everybody can run a BGP router yet, and ISPs do not usually offer BGP on DSL- or cable-style products yet) - while the number of end-users that would prefer to have a sticky IPv6 address and never having to renumber is virtually unlimited. And I direly want *those* to use PA space - and see that aggregated. For the multihomers, it's very hard to make generic statements, as the differences among these networks are huge. Gert Doering -- NetMaster -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 305 bytes Desc: not available URL: From jeroen at unfix.org Mon Jun 18 23:13:20 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Mon, 18 Jun 2007 22:13:20 +0100 Subject: [address-policy-wg] ULA-C draft version 2 available (I-D ACTION:draft-ietf-ipv6-ula-central-02.txt) Message-ID: <4676F570.7050107@spaghetti.zurich.ibm.com> Reply-To set to ipv6 at ietf.org, use it as there is where the discussion should be. This mail is mostly so that folks can't claim that they "didn't know". IETF is, just like the RIR communities open and individual participation. Thus if you have something on your mind, write down the arguments and send them in. Note on the IETF lists: subscription is helpful, otherwise you might not get the responses (unless you read the public archive). List Admins will, as soon as possible approve mails that get into the queue though, but with todays amount of spam coming in that might not be immediate. The document is at: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-ula-central-02.txt Subscription information + archive etc for ipv6 at ietf.org can be found at: https://www1.ietf.org/mailman/listinfo/ipv6 Greets, Jeroen -------- Original Message -------- A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : Centrally Assigned Unique Local IPv6 Unicast Addresses Author(s) : R. Hinden, B. Haberman Filename : draft-ietf-ipv6-ula-central-02.txt Pages : 11 Date : 2007-6-18 This document defines Centrally allocated IPv6 Unique Local addresses. These addresses are globally unique and are intended for local communications, usually inside of a site. They are not expected to be routable on the global Internet. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-ula-central-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request at ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-ula-central-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv at ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-ula-central-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From Niall.oReilly at ucd.ie Wed Jun 20 10:33:08 2007 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Wed, 20 Jun 2007 09:33:08 +0100 Subject: [address-policy-wg] Impact Analysis In-Reply-To: <467142C9.90504@ripe.net> References: <467142C9.90504@ripe.net> Message-ID: <1C39194C-5D49-48D9-8864-9A38C4C6DBAA@ucd.ie> On 14 Jun 2007, at 14:29, Filiz Yilmaz wrote: > The first impact analysis has been created for the proposal > 2007-04, IANA Policy for Allocation of ASN Blocks to RIRs. You can > view this analysis under 'Additional Information' in this proposal at: I believe it will be useful systematically to recognize advantageous impact as part of this analysis. Best regards, Niall O'Reilly University College Dublin IT Services PGP key ID: AE995ED9 (see www.pgp.net) Fingerprint: 23DC C6DE 8874 2432 2BE0 3905 7987 E48D AE99 5ED9 -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From Niall.oReilly at ucd.ie Wed Jun 20 10:30:31 2007 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Wed, 20 Jun 2007 09:30:31 +0100 Subject: [address-policy-wg] 2007-04 New Draft Document Published (IANA Policy for Allocation of ASN Blocks to RIRs) In-Reply-To: <20070614132024.3E1492F599@herring.ripe.net> References: <20070614132024.3E1492F599@herring.ripe.net> Message-ID: On 14 Jun 2007, at 14:20, Filiz Yilmaz wrote: > 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 I'm surprised at the account given of the impact analysis. If it is really "not anticipate[d] that any significant impact will be caused if this proposal is implemented", I wonder what the motivation for the proposal can be. I should have expected that it would not be difficult to identify some _advantageous_ impact, and that such impact should have been clearly reported. Best regards, Niall O'Reilly University College Dublin IT Services PGP key ID: AE995ED9 (see www.pgp.net) Fingerprint: 23DC C6DE 8874 2432 2BE0 3905 7987 E48D AE99 5ED9 -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From leo.vegoda at icann.org Wed Jun 20 15:09:49 2007 From: leo.vegoda at icann.org (Leo Vegoda) Date: Wed, 20 Jun 2007 15:09:49 +0200 Subject: [address-policy-wg] 2007-04 New Draft Document Published (IANA Policy for Allocation of ASN Blocks to RIRs) In-Reply-To: References: <20070614132024.3E1492F599@herring.ripe.net> Message-ID: <0909DF03-F233-41F5-B1F2-43B64E3717BA@icann.org> Hi Niall, On 20 Jun 2007, at 10:30am, Niall O'Reilly wrote: [...] > I'm surprised at the account given of the impact analysis. > If it is really "not anticipate[d] that any significant > impact will be caused if this proposal is implemented", > I wonder what the motivation for the proposal can be. > > I should have expected that it would not be difficult to > identify some _advantageous_ impact, and that such impact > should have been clearly reported. I see a clear advantage in having all five RIR communities review a proposal and agree a policy as there is no policy at the moment - just precedent. I for one am very much in favour of having a consensus policy to work to. Of course, this would be true of any global policy. This particular policy proposal doesn't really change very much and that could also be seen as an advantage by some, too. However, these points are made in the proposal's "Rationale" section. I suspect that Filiz limited her impact analysis to resource consumption and service impact because these are quantifiable and should help the community discuss the benefits and/or disadvantages of the proposal itself. Regards, -- Leo Vegoda IANA Numbers Liaison From leo.vegoda at icann.org Wed Jun 20 17:35:34 2007 From: leo.vegoda at icann.org (Leo Vegoda) Date: Wed, 20 Jun 2007 17:35:34 +0200 Subject: [address-policy-wg] 2006-02 Last Call for Comments (IPv6 Address Allocation and Assignment Policy) In-Reply-To: <20070604114757.0F0F22F583@herring.ripe.net> References: <20070604114757.0F0F22F583@herring.ripe.net> Message-ID: <86749309-2457-4B64-9212-F030215398EA@icann.org> On 4 Jun 2007, at 1:47pm, Filiz Yilmaz wrote: > PDP Number: 2006-02 > IPv6 Address Allocation and Assignment Policy > > Dear Colleagues > > The proposal described in 2006-02 is now at its Concluding Phase. > > This proposal is to change the IPv6 Initial Allocation criteria and > the End Site definition in the "IPv6 Address Allocation and > Assignment Policy". I am unsure about the relationship between this proposal, which redefines end-sites and allows them to receive a /32 IPv6 allocation and 2006-01, which proposes the introduction of IPv6 PI assignments. Both proposals would allow networks that do not provide typical ISP services to receive IPv6 address space. Non-ISP networks obviously have a demand that needs to be met. 2006-01 would set the minimum prefix length for these assignments at / 48. Shorter prefixes could be assigned "if duly documented and justified" although how this would be done is not explained and ought to be clarified before that proposal is accepted, in my opinion. 2006-02 would allow end sites to receive an allocation and so they would get a minimum of a /32. It appears that if both proposals were accepted then anyone wanting more than a /48 PI assignment could receive a /32 allocation straight away as long as they have a plan to make a few internal assignments. In essence, it seems that the main difference between the two proposals is that anyone willing to pay to become an LIR can receive a /32 prefix even if they would otherwise fail to qualify for a far longer /47 prefix. I'm not sure if this is intentional. If it is not then it is possible that clarifying the basis for PI IPv6 assignments shorter than /48 in 2006-01 would remove the need for 2006-02 entirely. Regards, -- Leo Vegoda IANA Numbers Liaison From gih at apnic.net Wed Jun 20 20:29:35 2007 From: gih at apnic.net (Geoff Huston) Date: Thu, 21 Jun 2007 04:29:35 +1000 Subject: [address-policy-wg] 2007-04 New Draft Document Published (IANA Policy for Allocation of ASN Blocks to RIRs) In-Reply-To: <0909DF03-F233-41F5-B1F2-43B64E3717BA@icann.org> References: <20070614132024.3E1492F599@herring.ripe.net> <0909DF03-F233-41F5-B1F2-43B64E3717BA@icann.org> Message-ID: <4679720F.8090901@apnic.net> Leo Vegoda wrote: > Hi Niall, > > On 20 Jun 2007, at 10:30am, Niall O'Reilly wrote: > > [...] > >> I'm surprised at the account given of the impact analysis. >> If it is really "not anticipate[d] that any significant >> impact will be caused if this proposal is implemented", >> I wonder what the motivation for the proposal can be. >> >> I should have expected that it would not be difficult to >> identify some _advantageous_ impact, and that such impact >> should have been clearly reported. > > I see a clear advantage in having all five RIR communities review a > proposal and agree a policy as there is no policy at the moment - just > precedent. I for one am very much in favour of having a consensus policy > to work to. Of course, this would be true of any global policy. This > particular policy proposal doesn't really change very much and that > could also be seen as an advantage by some, too. However, these points > are made in the proposal's "Rationale" section. > > I suspect that Filiz limited her impact analysis to resource consumption > and service impact because these are quantifiable and should help the > community discuss the benefits and/or disadvantages of the proposal itself. There's policy and there's operational procedures. I must admit that in this case I was of the view that while there is no substantive policy component here, there is merit in simply setting forth the operational procedures we use for IANA to RIR ASN block assignments as a documented procedure. Geoff From jordi.palet at consulintel.es Thu Jun 21 07:38:18 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Thu, 21 Jun 2007 05:38:18 +0000 Subject: [address-policy-wg] 2006-02 Last Call for Comments (IPv6 Address Allocation and Assignment Policy) In-Reply-To: <86749309-2457-4B64-9212-F030215398EA@icann.org> Message-ID: Hi Leo, We are talking about two different things/cases. Both proposals may seem as related, but actually they are not. In fact, we can't relate both policy proposals also, because it is not clear that 2006-01 will go further (at least not with the actual text), as I didn't got inputs to my last replies to previous inputs :-( So it is difficult for me to keep going w/o community review. 2006-02 is intended for entities that have their own network with multiple sites. Those sites behave as end-sites to the "internal" ISP. This is for example the case of Universities, or NATO (just to mention a clear case) that already have indicated in the list their need. I don't see those as PI cases, because they are by their own real ISPs, even if for the same entity, they have their own NOC, staff, etc. to manage the network. Instead 2006-01 is looking for PI cases, for example a data center. So I don't see the need to stop 2006-02, and what it is really needed is to get more input on 2006-01 ! Regards, Jordi > De: Leo Vegoda > Responder a: > Fecha: Wed, 20 Jun 2007 17:35:34 +0200 > Para: > CC: Jordi Palet Martinez > Asunto: Re: [address-policy-wg] 2006-02 Last Call for Comments (IPv6 Address > Allocation and Assignment Policy) > > On 4 Jun 2007, at 1:47pm, Filiz Yilmaz wrote: > >> PDP Number: 2006-02 >> IPv6 Address Allocation and Assignment Policy >> >> Dear Colleagues >> >> The proposal described in 2006-02 is now at its Concluding Phase. >> >> This proposal is to change the IPv6 Initial Allocation criteria and >> the End Site definition in the "IPv6 Address Allocation and >> Assignment Policy". > > I am unsure about the relationship between this proposal, which > redefines end-sites and allows them to receive a /32 IPv6 allocation > and 2006-01, which proposes the introduction of IPv6 PI assignments. > Both proposals would allow networks that do not provide typical ISP > services to receive IPv6 address space. Non-ISP networks obviously > have a demand that needs to be met. > > 2006-01 would set the minimum prefix length for these assignments at / > 48. Shorter prefixes could be assigned "if duly documented and > justified" although how this would be done is not explained and ought > to be clarified before that proposal is accepted, in my opinion. > > 2006-02 would allow end sites to receive an allocation and so they > would get a minimum of a /32. > > It appears that if both proposals were accepted then anyone wanting > more than a /48 PI assignment could receive a /32 allocation straight > away as long as they have a plan to make a few internal assignments. > In essence, it seems that the main difference between the two > proposals is that anyone willing to pay to become an LIR can receive > a /32 prefix even if they would otherwise fail to qualify for a far > longer /47 prefix. > > I'm not sure if this is intentional. If it is not then it is possible > that clarifying the basis for PI IPv6 assignments shorter than /48 in > 2006-01 would remove the need for 2006-02 entirely. > > Regards, > > -- > Leo Vegoda > IANA Numbers Liaison > ********************************************** 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 Niall.oReilly at ucd.ie Thu Jun 21 10:38:28 2007 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Thu, 21 Jun 2007 09:38:28 +0100 Subject: [address-policy-wg] 2007-04 New Draft Document Published (IANA Policy for Allocation of ASN Blocks to RIRs) In-Reply-To: <0909DF03-F233-41F5-B1F2-43B64E3717BA@icann.org> References: <20070614132024.3E1492F599@herring.ripe.net> <0909DF03-F233-41F5-B1F2-43B64E3717BA@icann.org> Message-ID: <9DC312B3-0036-464B-8211-0BD5C780834E@ucd.ie> On 20 Jun 2007, at 14:09, Leo Vegoda wrote: > I see a clear advantage in having all five RIR communities review a > proposal and agree a policy as there is no policy at the moment - > just precedent. Me too. > I for one am very much in favour of having a consensus policy to > work to. Of course, this would be true of any global policy. This > particular policy proposal doesn't really change very much and that > could also be seen as an advantage by some, too. However, these > points are made in the proposal's "Rationale" section. I see a kind of layering distinction between - on the one hand, rationale and arguments for or against (layer of principle, policy or even philosophy), and - on the other, operational impact. I believe it adds clarity to address these separately. > I suspect that Filiz limited her impact analysis to resource > consumption and service impact because these are quantifiable and > should help the community discuss the benefits and/or disadvantages > of the proposal itself. In her position, I'ld probably have done the same. There is a tendency to consider "impact" by assumption "negative". I'm suggesting that this is actually a prejudice which limits the usefulness of the impact analysis. I'm raising this now because On 14 Jun 2007, at 14:29, Filiz Yilmaz wrote: > The first impact analysis has been created for the proposal 2007-04 and it is opportune to give feedback on the new process. For simplicity, let's consider three cases: the impact of a proposed new policy may be assessed as "burdensome", "neutral", or "advantageous". The first case (burdensome) is easiest: there had better be a very strong rationale with clear benefits to the community in order to adopt such a proposal. The third case (advantageous) has (perhaps subtly hidden) consequences for RIR planning. For example, if the proposal is expected to result in significantly more efficient operations, in comparison with existing practices, it may be that forward resource requirement projections will have to be revised. The neutral case is where elegant, but sterile, proposals fall. If a proposal truly isn't expected to have any impact on operations, we should ask, "Why bother?" For clarity, I believe that proposal 2007-04 is not neutral, but advantageous in just the way Leo has put it. Working from documented policy rather than from precedent (or worse, corporate memory, degraded by natural amnesia and staff turnover) will surely be more efficient, less demanding for the staff involved, and clearer for the customers. I think that "good impact" is worth mentioning as well as "bad impact", and that choosing to do so will result in more useful impact analysis for future proposals. FWIW /Niall -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From leo.vegoda at icann.org Thu Jun 21 21:51:04 2007 From: leo.vegoda at icann.org (Leo Vegoda) Date: Thu, 21 Jun 2007 21:51:04 +0200 Subject: [address-policy-wg] 2006-02 Last Call for Comments (IPv6 Address Allocation and Assignment Policy) In-Reply-To: References: Message-ID: Hi Jordi, On 21 Jun 2007, at 7:38am, JORDI PALET MARTINEZ wrote: > > We are talking about two different things/cases. > > Both proposals may seem as related, but actually they are not. > > In fact, we can't relate both policy proposals also, because it is > not clear > that 2006-01 will go further (at least not with the actual text), as I > didn't got inputs to my last replies to previous inputs :-( So it is > difficult for me to keep going w/o community review. 2006-01 seems to have had a couple of dozen comments on it over the last month, actually. Are you referring to something else? > 2006-02 is intended for entities that have their own network with > multiple > sites. I think the intention makes sense but the phrasing of the policy text needs some work. It looks like you want an end site to qualify for a /32 IPv6 allocation if it needs to make *any* size of assignment to multiple internal sites. But the text doesn't actually define what one of these internal sites is. That creates a problem for anyone that wants one of these /32 allocations because they can't work out if they qualify for it or ought to try and get a /47 (or whatever) under the IPv6 PI policy. If the policy text is confusing it's going to create lots of extra work for the requesters and the RIPE NCC. > Those sites behave as end-sites to the "internal" ISP. This is for > example the case of Universities, or NATO (just to mention a clear > case) > that already have indicated in the list their need. I don't see > those as PI > cases, because they are by their own real ISPs, even if for the > same entity, > they have their own NOC, staff, etc. to manage the network. > > Instead 2006-01 is looking for PI cases, for example a data center. > > So I don't see the need to stop 2006-02, and what it is really > needed is to > get more input on 2006-01 ! I think the issue still remains: 2006-01 and 2006-02 need to work together closely. Presumably, a network that does not qualify for a / 47 should not qualify to receive a /32. Or should it? If it should not then how does this policy text ensure that? Because as far as I can tell there isn't a good definition of what one of these 'final' sites is, so anyone can claim that every /64 in their internal network is a site and get a /32 allocation. Regards, -- Leo Vegoda IANA Numbers Liaison From jeroen at unfix.org Fri Jun 22 15:32:59 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 22 Jun 2007 14:32:59 +0100 Subject: [address-policy-wg] How to get a IPv6 /32 the cheap way: go to AFRINIC Message-ID: <467BCF8B.4090308@spaghetti.zurich.ibm.com> [*full rant mode*] My eye just fell on a very strange new allocation, apparently made under some new rules in the AFRINIC region which seem to be very wasteful and very out of sync with the rest of the world who are at least thinking a bit about address conservation instead of just blowing address space like there is no tomorrow: http://www.afrinic.net/docs/policies/afpol-v6200407-000.htm#5 details: 8<-------------- 5.1.1. Initial allocation criteria To qualify for an initial allocation of IPv6 address space, an organization must: a) be an LIR; b) not be an end site; c) show a detailed plan to provide IPv6 connectivity to organizations in the AfriNIC region. d) show a reasonable plan for making /48 IPv6 assignments to end sites in the AfriNIC region within twelve months. The LIR should also plan to announce the allocation as a single aggregated block in the inter-domain routing system within twelve months. 5.1.2. Initial allocation size Organizations that meet the initial allocation criteria are eligible to receive a minimum allocation of /32. ---------------------------------------------->8 Wow, so you make a new 'company' in 911 land and say "I am going to allocate a single /48" and you get a FULL /32 even when you will never ever ever use it or even are going to think about using it? The first "organization" which is using this to waste space seems to be: inet6num: 2001:42d0::/32 netname: AfriNIC-IPv6-1 descr: AfriNIC descr: RIR country: MU Gee, the RIR itself. How many people are using the AFRINIC network? 10-50? Are they really *ever* going to need more than a /48? Are they ever going to have a need for 65536 of those /48's? Really this is just a waste of address space. Yes there is "enough", but being sooo obviously wasteful just to be able to have a nice slot in the routing tables is a bit over done. I hope that the other regions take this in mind too when (re)considering their address policies. Giving out /48's or even a /40 to an organization that is in-effect an end-site I can understand, especially when they can justify the need for that amount of address space. But giving /32's to every single endsite that simply asks for it is very very very far fetched. They will not even ever fill up a /40 of address space even if they would have two sites (read: offices) in every country in Africa, let alone 65536 sites. Such a waste. Funnily later in the above document they point to HD ratios. What point is that when the waste is already happened? RIR's should be giving out address space based on "need" and that need must justified, giving out /32's as "those fit in the routing slots" is a really really bad idea. In short: if you want a nice /32 without issues: setup a small shop in Africa and presto! Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From nick at inex.ie Fri Jun 22 16:02:59 2007 From: nick at inex.ie (Nick Hilliard) Date: Fri, 22 Jun 2007 15:02:59 +0100 Subject: [address-policy-wg] How to get a IPv6 /32 the cheap way: go to AFRINIC In-Reply-To: <467BCF8B.4090308@spaghetti.zurich.ibm.com> References: <467BCF8B.4090308@spaghetti.zurich.ibm.com> Message-ID: <467BD693.5050607@inex.ie> Jeroen Massar wrote: > 5.1.1. Initial allocation criteria > To qualify for an initial allocation of IPv6 address space, an organization must: > a) be an LIR; > b) not be an end site; > c) show a detailed plan to provide IPv6 connectivity to organizations in the > AfriNIC region. > d) show a reasonable plan for making /48 IPv6 assignments to end sites in the > AfriNIC region within twelve months. The LIR should also plan to announce the > allocation as a single aggregated block in the inter-domain routing system > within twelve months. Frankly, I fail to see the problem here. IMO, bona-fide LIRs should be entitled to an ipv6 allocation under these terms at least in the RIPE region. Cool off on the rants, Jeroen. I know it's raining today, but it may be sunny tomorrow. Nick -- Network Ability Ltd. | Head of Operations | Tel: +353 1 6169698 3 Westland Square | INEX - Internet Neutral | Fax: +353 1 6041981 Dublin 2, Ireland | Exchange Association | Email: nick at inex.ie From jordi.palet at consulintel.es Fri Jun 22 16:06:27 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Fri, 22 Jun 2007 16:06:27 +0200 Subject: [address-policy-wg] Re: [ppml] How to get a IPv6 /32 the cheap way: go to AFRINIC In-Reply-To: <467BCF8B.4090308@spaghetti.zurich.ibm.com> Message-ID: Jeroen, This is just ridiculous. All the RIRs have their own /32 for their internal usage. Regards, Jordi > De: Jeroen Massar > Organizaci?n: Unfix > Responder a: > Fecha: Fri, 22 Jun 2007 14:32:59 +0100 > Para: ARIN Address Policy , RIPE Address Policy > , AFRNIC IPv6 , APNIC > IPv6 > Asunto: [ppml] How to get a IPv6 /32 the cheap way: go to AFRINIC > > [*full rant mode*] > > My eye just fell on a very strange new allocation, apparently made under some > new rules in the AFRINIC region which seem to be very wasteful and very out of > sync with the rest of the world who are at least thinking a bit about address > conservation instead of just blowing address space like there is no tomorrow: > > http://www.afrinic.net/docs/policies/afpol-v6200407-000.htm#5 details: > 8<-------------- > 5.1.1. Initial allocation criteria > To qualify for an initial allocation of IPv6 address space, an organization > must: > a) be an LIR; > b) not be an end site; > c) show a detailed plan to provide IPv6 connectivity to organizations in the > AfriNIC region. > d) show a reasonable plan for making /48 IPv6 assignments to end sites in the > AfriNIC region within twelve months. The LIR should also plan to announce the > allocation as a single aggregated block in the inter-domain routing system > within twelve months. > > 5.1.2. Initial allocation size > > Organizations that meet the initial allocation criteria are eligible to > receive a minimum allocation of /32. > ---------------------------------------------->8 > > Wow, so you make a new 'company' in 911 land and say "I am going to allocate a > single /48" and you get a FULL /32 even when you will never ever ever use it > or even are going to think about using it? > > The first "organization" which is using this to waste space seems to be: > > inet6num: 2001:42d0::/32 > netname: AfriNIC-IPv6-1 > descr: AfriNIC > descr: RIR > country: MU > > Gee, the RIR itself. How many people are using the AFRINIC network? 10-50? Are > they really *ever* going to need more than a /48? Are they ever going to have > a need for 65536 of those /48's? > > Really this is just a waste of address space. Yes there is "enough", but being > sooo obviously wasteful just to be able to have a nice slot in the routing > tables is a bit over done. > > > I hope that the other regions take this in mind too when (re)considering their > address policies. > > Giving out /48's or even a /40 to an organization that is in-effect an > end-site I can understand, especially when they can justify the need for that > amount of address space. But giving /32's to every single endsite that simply > asks for it is very very very far fetched. They will not even ever fill up a > /40 of address space even if they would have two sites (read: offices) in > every country in Africa, let alone 65536 sites. Such a waste. > > Funnily later in the above document they point to HD ratios. What point is > that when the waste is already happened? > > > RIR's should be giving out address space based on "need" and that need must > justified, giving out /32's as "those fit in the routing slots" is a really > really bad idea. > > In short: if you want a nice /32 without issues: setup a small shop in Africa > and presto! > > Greets, > Jeroen > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml ********************************************** 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 jeroen at unfix.org Fri Jun 22 16:18:25 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 22 Jun 2007 15:18:25 +0100 Subject: [address-policy-wg] Re: [GLOBAL-V6] [ppml] How to get a IPv6 /32 the cheap way: go to AFRINIC In-Reply-To: References: Message-ID: <467BDA31.4030607@spaghetti.zurich.ibm.com> JORDI PALET MARTINEZ wrote: > Jeroen, > > This is just ridiculous. What is ridiculous is that /32's are getting wasted and will never be used. What is also ridiculous is that RIR policies are trying to avoid end-sites getting /48's in some places who need it to 'control routingtable entries' but then this shows up as a full /32 that never will be used. Now *THAT* is what is ridiculous. I have no problem at all with an organization receiving a justified /48, but a /32 for an organisation that will never ever use more than a /40 is ridiculous. > All the RIRs have their own /32 for their internal usage. APNIC has one indeed: 2001:dc0::/32 but the rest doesn't. ARIN has a 2001:500::/48 which is more correct, they won't need much more. Where exactly is the one for RIPE, ARIN and LACNIC? See that is not !ALL! RIPE even went so far to use 2 /48's (SURFNET+BIT) to avoid coming into the mess of being preferential to themselves. Also, since when is a RIR special in anyway? Also, since when do those networks justify the need of 65536 /48's? The point is not about AFRINIC, it is about wasting address space without justification. Alain Patrick AINA wrote: > This does not meet the requirements above. So you won't get it. It fully does, how else did AFRINIC assign a /32 to themselves? Nick Hilliard wrote: > Frankly, I fail to see the problem here. IMO, bona-fide LIRs should be > entitled to an ipv6 allocation under these terms at least in the RIPE > region. I agree that when an organization can justify (using HD ratios etc) the need for address space that they will fully be able to get that address space without any issues. But is AFRINIC (10-50 people) able to justify a /32 based on that? Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From jordi.palet at consulintel.es Fri Jun 22 17:17:32 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Fri, 22 Jun 2007 17:17:32 +0200 Subject: [address-policy-wg] Re: [GLOBAL-V6] [ppml] How to get a IPv6 /32 the cheap way: go to AFRINIC In-Reply-To: <467BDA31.4030607@spaghetti.zurich.ibm.com> Message-ID: You need to read all the policies before making such statements. For example that explains the /32 in LACNIC. RIRs can be considered, and in fact they are, critical infrastructures, and in some regions, then they get a /32, and while you can't warrantee that a /48 will be filtered, I agree that a /32 is the right size for any critical infrastructure. Regards, Jordi > De: Jeroen Massar > Organizaci?n: Unfix > Responder a: > Fecha: Fri, 22 Jun 2007 15:18:25 +0100 > Para: > CC: , RIPE Address Policy , "IPv6 > in Africa " , APNIC > IPv6 , Nick Hilliard , > > Asunto: Re: [GLOBAL-V6] [ppml] How to get a IPv6 /32 the cheap way: go to > AFRINIC > > JORDI PALET MARTINEZ wrote: >> Jeroen, >> >> This is just ridiculous. > > What is ridiculous is that /32's are getting wasted and will never be used. > What is also ridiculous is that RIR policies are trying to avoid end-sites > getting /48's in some places who need it to 'control routingtable entries' > but then this shows up as a full /32 that never will be used. > > Now *THAT* is what is ridiculous. > > I have no problem at all with an organization receiving a justified /48, but a > /32 for an organisation that will never ever use more than a /40 is > ridiculous. > >> All the RIRs have their own /32 for their internal usage. > > APNIC has one indeed: 2001:dc0::/32 but the rest doesn't. > ARIN has a 2001:500::/48 which is more correct, they won't need much more. > Where exactly is the one for RIPE, ARIN and LACNIC? See that is not !ALL! > > RIPE even went so far to use 2 /48's (SURFNET+BIT) to avoid coming into the > mess of being preferential to themselves. > > Also, since when is a RIR special in anyway? > Also, since when do those networks justify the need of 65536 /48's? > > The point is not about AFRINIC, it is about wasting address space without > justification. > > Alain Patrick AINA wrote: >> This does not meet the requirements above. So you won't get it. > > It fully does, how else did AFRINIC assign a /32 to themselves? > > Nick Hilliard wrote: >> Frankly, I fail to see the problem here. IMO, bona-fide LIRs should be >> entitled to an ipv6 allocation under these terms at least in the RIPE >> region. > > I agree that when an organization can justify (using HD ratios etc) the need > for address space that they will fully be able to get that address space > without any issues. But is AFRINIC (10-50 people) able to justify a /32 based > on that? > > Greets, > Jeroen > ********************************************** 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 jeroen at unfix.org Fri Jun 22 17:24:17 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 22 Jun 2007 16:24:17 +0100 Subject: [address-policy-wg] Re: [GLOBAL-V6] How to get a IPv6 /32 the cheap way: go to AFRINIC In-Reply-To: <200706221451.l5MEpIQP012336@ns1.afrinic.net> References: <467BCF8B.4090308@spaghetti.zurich.ibm.com> <200706221451.l5MEpIQP012336@ns1.afrinic.net> Message-ID: <467BE9A1.80008@spaghetti.zurich.ibm.com> Adiel A. Akplogan wrote: > Hello Jeroen, [..] >> Gee, the RIR itself. How many people are using the AFRINIC network? >> 10-50? Are they really *ever* going to need more than a /48? Are they >> ever going to have a need for 65536 of those /48's? > > You can not take AfriNIC own allocation case to illustrate your > assertion here Why not? Is AfriNIC special, is AfriNIC outside of the policy rules set by their own membership? What does make AfriNIC so special to not even consult the rest of the world, let alone your membership, in making these decisions? So why did that not happen in the first place? > We have allocated that bloc to our own Infrastructure (which has three > locations to be connected together) so each with its own /48. Further > to that we have other IPv6 Internal projects which will probably > require several /48. I can fully understand a /48 per 'location', especially when they are administratively separate and/or very remote from each other. But you will never reach more than 50 of those locations. Those are a large amount and big projects AfriNIC is (going to) run then. By going to provide these services don't you think you are going against your membership, who only recently got the hard policy of only getting a /48 and they have to fully justify it. Or does AfriNIC think that everybody will be eligible for a /32? Also, is AfriNIC really going to use a full /32 with a staff of what 10-50 people or even less than that? AfriNIC is not an ISP as far as I am aware, unless some other business ventures unrelated to you being a RIR is being tapped into. As such, hosting projects is not an option either as that would mean you get clients, and that would be the only way that you could justify having a need for multiple /48's in that area. Can you clarify? > As RIR I think we are in the position to evaluate > our own need before making an allocation and if it > was made be sure that is after careful evaluation. Can you please explain again why a *RIR* (Regional Internet Registry) will be using 65536 /48's in the coming, lets take a liberal, 10 years? Can you show FULL justification for this? Just as a little example, there is a little RIR, one of the older ones, you might know them as "RIPE", they have been around for a long time and helped AfriNIC get off the ground. They are running a LOT of big projects and doing a lot of community work. Still they did not allocate a /32 to themselves, or a /48 for that matter. They are using two /48's from ISP's who donated those prefixes to them. This as their membership decided for them that a RIR is not special and also because they don't claim (_afaik_) to need that kind of address space. A /48 is sufficient for them. Another good example is another little RIR, called ARIN, they also only have a single /48 for their own network, also granted under the policy as specified by their membership. How come that AfriNIC doesn't think that a /48 or max a /40, under your own PI policy which was recently approved by your membership is not good enough. Is AfriNIC special on this planet? >> Really this is just a waste of address space. Yes there is "enough", >> but being sooo obviously wasteful just to be able to have a nice slot >> in the routing >> tables is a bit over done. > > I don't see the waist. I almost am having to ponder asking you how good you are in a role of a RIR if you can't do the math of 65536 /48's being wasted on this. I agree, it is nothing compared to the full address space of 128bits, but that is also what people though about 32bit IPv4 addresses, remind yourself of all the wailing people are doing about MIT having a /8. This is the exact same situation. Except now people are pointing at you when you don't justify the space. Especially when you are doing it without an appropriate policy in place. > Please read http://www.afrinic.net/docs/policies/afpol-v6200701.htm Which is not linked directly from the website, but I did find it from the email archives. Also that policy specifies one single /48. Not a /32 which is as you should know 65536 more than that. Just in case you wonder, as I mentioned already a couple of times also in other threads, I fully support organizations getting a /48 or upto even a /40 or more. But all as long as they can actually JUSTIFY that space. Saying "we are RIR, we can do what we want, we will run big projects" is not a good justification. >> Funnily later in the above document they point to HD ratios. What >> point is >> that when the waste is already happened? > > I think you are confusing the IPv6 allocation to LIR document with PI > assignment document which in fact was a proposal until few days where > it was ratified by AfriNIC board (... but not yet implemented). No I was referring to the following URL which I mentioned in my mail: http://www.afrinic.net/docs/policies/afpol-v6200407-000.htm#5 Also, clearly if such a policy is not implemented yet, how can AfriNIC itself make use of that policy then? >> RIR's should be giving out address space based on "need" and that need >> must justified, giving out /32's as "those fit in the routing slots" >> is a really really bad idea. > > That is what we do. You can not have such affirmation based on a single > case. You didn't give any valid justification (yet), also you didn't even have a policy for this kind of allocation. Doing something once, doesn't mean you didn't break policy, especially when there is no such policy. >> In short: if you want a nice /32 without issues: setup a small shop in >> Africa >> and presto! > > You won't get it like that. Then how did you, being AfriNIC get it? Please elaborate, I am really wondering about how this works. And I very sure that a lot of other people are also very interested in knowing about these practices. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From jeroen at unfix.org Fri Jun 22 17:27:55 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 22 Jun 2007 16:27:55 +0100 Subject: [address-policy-wg] Re: [GLOBAL-V6] [ppml] How to get a IPv6 /32 the cheap way: go to AFRINIC In-Reply-To: References: Message-ID: <467BEA7B.1000608@spaghetti.zurich.ibm.com> JORDI PALET MARTINEZ wrote: > You need to read all the policies before making such statements. For example > that explains the /32 in LACNIC. A 10-50 people organization that is not an ISP, doesn't do hosting, only has 3 offices, get a /32, which is good for 65536 /48's, please explain me how that is 'good justification' ? > RIRs can be considered, and in fact they are, critical infrastructures, and > in some regions, then they get a /32, and while you can't warrantee that a > /48 will be filtered, I agree that a /32 is the right size for any critical > infrastructure. RIR's provide "Address Space" not a "routing guarantee". ARIN has a micro-allocation policies for "critical infrastructure", these are of size /48. This is for The IX "critical infrastructure" policies also only provide a /48. Filtering is something that is happening at the ISP's, not at the RIR. It is nothing that the RIR can do about, and it is also nothing that the RIR would have to worry about. According to your analogy, anybody should be getting IPv4 /24 or IPv6 /32's simply because they have 1 box somewhere and they are afraid of being filtered. That is not how justification of address space works. If it does work that way today, then it definitely has to be changed ASAP. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From jeroen at unfix.org Fri Jun 22 17:36:07 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 22 Jun 2007 16:36:07 +0100 Subject: [address-policy-wg] Re: [GLOBAL-V6] [ppml] How to get a IPv6 /32 the cheap way: go to AFRINIC In-Reply-To: <200706221526.46024.aalain@trstech.net> References: <467BDA31.4030607@spaghetti.zurich.ibm.com> <200706221526.46024.aalain@trstech.net> Message-ID: <467BEC67.5080307@spaghetti.zurich.ibm.com> Alain Patrick AINA wrote: > On Friday 22 June 2007 14:18:25 Jeroen Massar wrote: > >> Alain Patrick AINA wrote: >>> This does not meet the requirements above. So you won't get it. >> It fully does, how else did AFRINIC assign a /32 to themselves? > > This would have been your question instead of concluding so negatively on a > global note. Excuses, I will try to add a short bullet pointed list of items next time with a nice animated powerpoint presentation and an executive summary to make my question come across to you. 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. Their statement of "we are a RIR we know what we are doing" is not good enough, especially as there is no active policy actually allowing them to request such a allocation even under their own policies. Any policy that simply allows any party to get a /32 without justification is the same as when IPv4 started out, where everybody simply got a /8. Indeed at that timepoint there was enough space, but what is the main complaint from various people nowadays: that they should have gotten less as they didn't need it in the first place. We can indeed give IPv6 prefixes for free, give every household a /32, and we'll probably not run out yet; and if we do we have another 7 tries when 2000::/3 runs full. But is that really what people want? To simply squat on the address space as much as possible, so that you at least have it? Not a good thing, especially not a good thing when a RIR does it themselves. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From nick at inex.ie Fri Jun 22 17:44:41 2007 From: nick at inex.ie (Nick Hilliard) Date: Fri, 22 Jun 2007 16:44:41 +0100 Subject: [address-policy-wg] Re: [GLOBAL-V6] [ppml] How to get a IPv6 /32 the cheap way: go to AFRINIC In-Reply-To: <467BDA31.4030607@spaghetti.zurich.ibm.com> References: <467BDA31.4030607@spaghetti.zurich.ibm.com> Message-ID: <467BEE69.60906@inex.ie> Jeroen Massar wrote: > I agree that when an organization can justify (using HD ratios etc) the need > for address space that they will fully be able to get that address space > without any issues. But is AFRINIC (10-50 people) able to justify a /32 based > on that? Jeroen, you're muddling two separate issues here. 1. There is no special justification for a LIR to be assigned a /32 in afrinic areas. As far as I'm concerned, this is fine and I'd be all in favour of this sort of allocation guideline making its way into RIPE-land. 2. Afrinic allocated themselves a /32. Afrinic are a RIR, not a LIR, and it appears that they broke the rules by allocating themselves a /32 (i.e. LIR size) instead of a /48 (end-user size). This is not good. The least we expect from the (monopolistic) RIRs is that they abide strictly by the rules set out by themselves and the community. If they have any sense in the matter, they'll hand themselves back the /32 and re-assign themselves a /48 under the generic PI assignment classification. TBH, the amount of address space which Afrinic allocated to themselves is of very little technical importance. What's relevant is that they broke their own rules, which will damage their reputation and the level of trust they have in their geographic area. Nick -- Network Ability Ltd. | Head of Operations | Tel: +353 1 6169698 3 Westland Square | INEX - Internet Neutral | Fax: +353 1 6041981 Dublin 2, Ireland | Exchange Association | Email: nick at inex.ie From jeroen at unfix.org Fri Jun 22 18:09:06 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 22 Jun 2007 17:09:06 +0100 Subject: [address-policy-wg] Re: [GLOBAL-V6] [ppml] How to get a IPv6 /32 the cheap way: go to AFRINIC In-Reply-To: <467BEE69.60906@inex.ie> References: <467BDA31.4030607@spaghetti.zurich.ibm.com> <467BEE69.60906@inex.ie> Message-ID: <467BF422.7030901@spaghetti.zurich.ibm.com> Nick Hilliard wrote: > Jeroen Massar wrote: >> I agree that when an organization can justify (using HD ratios etc) >> the need >> for address space that they will fully be able to get that address space >> without any issues. But is AFRINIC (10-50 people) able to justify a >> /32 based >> on that? > > Jeroen, > > you're muddling two separate issues here. > > 1. There is no special justification for a LIR to be assigned a /32 in > afrinic areas. As far as I'm concerned, this is fine and I'd be all in > favour of this sort of allocation guideline making its way into RIPE-land. I am also fine with that as long as there is a justification for the address space. Just being LIR is not good enough IMHO. Address space should be provided under the premise that it will actually be used one day. As such /48's are very appropriate for end-sites, upto /40 for large corporations, anything above that should be able to get a /32. But this all by justification of need. That we have enough address space today is great, but when they invent this nice "stay young forever pill to fly to Jupiter and back forever", then people in that era and everybody else also want to have IPv6 address space (unless we replace it again by then :). This thus might affect you yourself too, as such, I speak up on this. > 2. Afrinic allocated themselves a /32. > > Afrinic are a RIR, not a LIR, and it appears that they broke the rules > by allocating themselves a /32 (i.e. LIR size) instead of a /48 > (end-user size). And also without any real justification, as of yet. > This is not good. The least we expect from the (monopolistic) RIRs is > that they abide strictly by the rules set out by themselves and the > community. If they have any sense in the matter, they'll hand themselves > back the /32 and re-assign themselves a /48 under the generic PI > assignment classification. And nobody (I think :) would have a problem with that. Even a /45 would not be looked strangely at, as they can JUSTIFY that amount of address space. (3 offices, 5 very very large projects, reasonably believable IMHO) A /32, is not though. > TBH, the amount of address space which Afrinic allocated to themselves > is of very little technical importance. I agree, relative to a 128bits of address space, a /32 is effectively nothing. > What's relevant is that they broke their own rules, which will damage > their reputation and the level of trust they have in their geographic area. Absolutely. Thanks for getting that out of my ramblings. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From david.conrad at icann.org Fri Jun 22 18:45:05 2007 From: david.conrad at icann.org (David Conrad) Date: Fri, 22 Jun 2007 12:45:05 -0400 Subject: [address-policy-wg] Re: [GLOBAL-V6] [ppml] How to get a IPv6 /32 the cheap way: go to AFRINIC In-Reply-To: <467BF422.7030901@spaghetti.zurich.ibm.com> References: <467BDA31.4030607@spaghetti.zurich.ibm.com> <467BEE69.60906@inex.ie> <467BF422.7030901@spaghetti.zurich.ibm.com> Message-ID: <2A5F2BA8-091A-4D4D-B54F-0FFB09E3E7D3@icann.org> On Jun 22, 2007, at 12:09 PM, Jeroen Massar wrote: >> TBH, the amount of address space which Afrinic allocated to >> themselves >> is of very little technical importance. > I agree, relative to a 128bits of address space, a /32 is > effectively nothing. To state the obvious: there are the same number of /32s in IPv4 space as in IPv6 space. Rgds, -drc From iwumba at yahoo.fr Fri Jun 22 18:44:55 2007 From: iwumba at yahoo.fr (Iwu Mbatelege) Date: Fri, 22 Jun 2007 16:44:55 +0000 (GMT) Subject: [address-policy-wg] Re : [ppml] on PPML? - was Re: How to get ... Message-ID: <378359.11161.qm@web27508.mail.ukl.yahoo.com> Please stop this non sense debate here: Have you also come across the following address waist? I haven't seen you guys making any noise about them! 014/8 Jun 91 IANA - Public Data Network ---- (a whole /8 for an organisation of less than 20 people?) inet6num: 2001:07F8::/29 inet6num: 2001:07FD::/32 netname: K-rootserver-net-20030829 descr: This assignment given to k-root.server.net descr: maintained by the RIPE NCC --- (just for the Kroot server Infratsructure ????? is this an LIR) inet6num2001:0DC0::/32 netnameAPNIC-AP-V6-20030124 descrAPNIC Pty Ltd - Brisbane Offices + Servers descrLevel 1, 33 Park Rd descrPO Box 2131, Milton descrBrisbane, QLD. countryAU --- (just for APNIC??? an LIR?) So is your problem with AfriNIC or you are going to request IANA , RIPE NCC, APNIC too to send you their justifications? note that most of the v6 assignments/allocations above were made in 2003 where none of these RIR had IPv6 PI policy in place. IM. ----- Message d'origine ---- De : Jeroen Massar ? : Edward Lewis Cc : ARIN Address Policy Envoy? le : Vendredi, 22 Juin 2007, 20h23mn 08s Objet : Re: [ppml] on PPML? - was Re: How to get ... Edward Lewis wrote: > At 16:44 +0100 6/22/07, Jeroen Massar wrote: > >> Global address consumption affects everybody globally. As such, if >> AfriNIC >> decides to waste address space, that affects all RIR's globally. As >> such it >> also affects ARIN, as such it affects you. > > I guess I was too subtle in making my point. Which point? Sorry, but not everybody is into prose, some people are engineers and simply want straight words. > If you are criticizing the activities of Afrinic, take it up discreetly > with Afrinic. The "Court of Public Opinion" is not a place for a fair > "fight." It is a problem with AfriNIC that has an effect globally. It is not a fight, it is public questioning. If you want to ignore it, then ignore it. > I don't like the precedent of accusing an RIR of a misdoing and asking > them to publicly defend themselves. The RIR's operate in a delicate > balance of both openness in policy development and resource registration > and confidentiality in handling and judging the worthiness of requests. That openness is not there when a RIR makes up their own rules without asking their membership. Or did I miss the superinternal memo that is not supposed to be public in the first place? > Working in a environment of openness, confidentiality, and neutrality is > difficult. You cannot defend yourself to the fullest because of the > limits of what can be, what can not be, and what might otherwise be > implied. > > Plus this is the ARIN mailing list. Stop thinking in your little American box. Or is the war in Iraq something that does not happen in the US and thus not relevant? To pull something in that also shows that local decisions have global effects. >> Then please try to explain me why I saw this recently: >> 2001:42c8::/32 Canada TGB-V6-AFRICA > > I believe that question is wholly inappropriate for this list. > Especially for this list. (In the pulic meetings, our chair doesn't > tolerate personal "accusations" either, something I was heartened to > witness in April.) If you try to say "Shut up" to me then either: - simply say on this list - simply say so by sending a private message And I am very sure that ARIN staff and other people are also very able to provide me with a similar message when needed very quickly. Please bring arguments along, they tend to help. I brought that up as a note to show you *WHY* it was appropriate to bring these matters up on the PPML mailinglist as policies and decisions happening in other regions *DO* affect ARIN. Let me repeat again, that I have NOTHING against that 2001:42c8::/32 assignment which is really a good thing and very well justified. It only demonstrates that Address Policy is a global thing, not something local. Organizations are global and the Internet is global. Policies and laws etc are not but they do affect us globally. And in case you don't like me mailing, then simply block all mail from jeroen at unfix.org, which is always nicely PGP signed, thus should be very easy to block in your MUA or even MTA. Greets, Jeroen _______________________________________________ This message sent to you through the ARIN Public Policy Mailing List (PPML at arin.net). Manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml _____________________________________________________________________________ Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Fri Jun 22 18:59:14 2007 From: gert at space.net (Gert Doering) Date: Fri, 22 Jun 2007 18:59:14 +0200 Subject: [address-policy-wg] Re : [ppml] on PPML? - was Re: How to get ... In-Reply-To: <378359.11161.qm@web27508.mail.ukl.yahoo.com> References: <378359.11161.qm@web27508.mail.ukl.yahoo.com> Message-ID: <20070622165914.GX69215@Space.Net> Hi, On Fri, Jun 22, 2007 at 04:44:55PM +0000, Iwu Mbatelege wrote: > inet6num: 2001:07F8::/29 > inet6num: 2001:07FD::/32 > > netname: K-rootserver-net-20030829 > > descr: This assignment given to k-root.server.net > > descr: maintained by the RIPE NCC > > --- (just for the Kroot server Infratsructure ????? is this an LIR) There is a special policy for root DNS servers (given that, at that time, there was no other way to get them stable IPv6 addresses, and everybody agreed that it would be useful for the DNS root to have *fixed* addresses). In general, I would appreciate if discussions such as these would not be carried in parallel on *3* policy mailing lists - pick one, and discuss things there, but don't just cc: all of them. This being an AfriNIC policy matter, it belongs to the AfriNIC list, or the GLOBAL-V6 list, but I can't see a reason why this needs to be CC:'ed to the RIPE and ARIN policy lists. 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 leo.vegoda at icann.org Fri Jun 22 19:11:50 2007 From: leo.vegoda at icann.org (Leo Vegoda) Date: Fri, 22 Jun 2007 19:11:50 +0200 Subject: [address-policy-wg] Re : [ppml] on PPML? - was Re: How to get ... In-Reply-To: <378359.11161.qm@web27508.mail.ukl.yahoo.com> References: <378359.11161.qm@web27508.mail.ukl.yahoo.com> Message-ID: <14635C03-1F65-4684-91F3-029BEEDB3419@icann.org> On 22 Jun 2007, at 6:44pm, Iwu Mbatelege wrote: [...] > Have you also come across the following address waist? I haven't seen > you guys making any noise about them! > > 014/8 Jun 91 IANA - Public Data Network > ---- (a whole /8 for an organisation of less than 20 people?) > I am actively reviewing this registry. Over the last few months I have had excellent support from a large number of people and have been able to remove most of the 1000+ assignments that were listed there. It is quite possible that the last 11 assignments are no longer actively used and can be returned. I am in contact with most of those organisations, confirming their status and hope to be able to update RFC 3330 as a result later this year. Regards, -- Leo Vegoda IANA Numbers Liaison From jorgen at hovland.cx Fri Jun 22 19:45:30 2007 From: jorgen at hovland.cx (=?UTF-8?Q?J=C3=B8rgen_Hovland?=) Date: Fri, 22 Jun 2007 19:45:30 +0200 Subject: [address-policy-wg] Re: [GLOBAL-V6] [ppml] How to get a IPv6 /32 the cheap way: go to AFRINIC In-Reply-To: <467BEA7B.1000608@spaghetti.zurich.ibm.com> References: <467BEA7B.1000608@spaghetti.zurich.ibm.com> Message-ID: <003101c7b4f5$20f39510$62dabf30$@cx> Hi, At the moment I believe that any LIR should be able to get an IPv6 prefix. Arguing that they don't need it because of address space only implies that the minimum assignment size policy, which is a /32, needs adjustment (reduce it to /64 for example). As long as each entity only have a single prefix, the dfz should be somewhat optimal. Cheers, J -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Jeroen Massar Sent: 22. juni 2007 17:28 To: jordi.palet at consulintel.es Cc: RIPE Address Policy; ppml at arin.net; APNIC IPv6; IPv6 in Africa Subject: [address-policy-wg] Re: [GLOBAL-V6] [ppml] How to get a IPv6 /32 the cheap way: go to AFRINIC JORDI PALET MARTINEZ wrote: > You need to read all the policies before making such statements. For > example that explains the /32 in LACNIC. A 10-50 people organization that is not an ISP, doesn't do hosting, only has 3 offices, get a /32, which is good for 65536 /48's, please explain me how that is 'good justification' ? > RIRs can be considered, and in fact they are, critical > infrastructures, and in some regions, then they get a /32, and while > you can't warrantee that a > /48 will be filtered, I agree that a /32 is the right size for any > critical infrastructure. RIR's provide "Address Space" not a "routing guarantee". ARIN has a micro-allocation policies for "critical infrastructure", these are of size /48. This is for The IX "critical infrastructure" policies also only provide a /48. Filtering is something that is happening at the ISP's, not at the RIR. It is nothing that the RIR can do about, and it is also nothing that the RIR would have to worry about. According to your analogy, anybody should be getting IPv4 /24 or IPv6 /32's simply because they have 1 box somewhere and they are afraid of being filtered. That is not how justification of address space works. If it does work that way today, then it definitely has to be changed ASAP. Greets, Jeroen From jordi.palet at consulintel.es Fri Jun 22 20:34:36 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Fri, 22 Jun 2007 20:34:36 +0200 Subject: [address-policy-wg] Re: [GLOBAL-V6] [ppml] How to get a IPv6 /32 the cheap way: go to AFRINIC In-Reply-To: <84C1471F-22C0-4970-A939-835B6E9770CF@virtualized.org> Message-ID: Because in some regions the policies, that have been developed by the community say so. I don't agree with the existing definitions of critical infrastructures, but I respect the policies developed following the PDP. If we don't agree with that point, then we should propose policy changes thru the PDP, but not make a useless critic. It is just my opinion, of course. Regards, Jordi > De: David Conrad > Responder a: > Fecha: Fri, 22 Jun 2007 12:45:31 -0400 > Para: > CC: , RIPE Address Policy , APNIC > IPv6 , "IPv6 in Africa > " > Asunto: Re: [GLOBAL-V6] [ppml] How to get a IPv6 /32 the cheap way: go to > AFRINIC > > On Jun 22, 2007, at 11:17 AM, JORDI PALET MARTINEZ wrote: >> RIRs can be considered, and in fact they are, critical >> infrastructures, > > Why? > > Rgds, > -drc > > _______________________________________________ > global-v6 mailing list > global-v6 at lists.apnic.net > http://mailman.apnic.net/mailman/listinfo/global-v6 ********************************************** 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 randy at psg.com Fri Jun 22 21:06:40 2007 From: randy at psg.com (Randy Bush) Date: Fri, 22 Jun 2007 09:06:40 -1000 Subject: [address-policy-wg] Re: [GLOBAL-V6] [ppml] How to get a IPv6 /32 the cheap way: go to AFRINIC In-Reply-To: <003101c7b4f5$20f39510$62dabf30$@cx> References: <467BEA7B.1000608@spaghetti.zurich.ibm.com> <003101c7b4f5$20f39510$62dabf30$@cx> Message-ID: <467C1DC0.80801@psg.com> > As long as each entity only have a single prefix, the dfz should be > somewhat optimal. great idea! was one of the rationales for A, B, and C. oops. randy From nick at inex.ie Fri Jun 22 21:36:35 2007 From: nick at inex.ie (Nick Hilliard) Date: Fri, 22 Jun 2007 20:36:35 +0100 Subject: [GLOBAL-V6] [address-policy-wg] Re: [ppml] How to get a IPv6 /32 the cheap way: go to AFRINIC In-Reply-To: <467C1DC0.80801@psg.com> References: <467BEA7B.1000608@spaghetti.zurich.ibm.com> <003101c7b4f5$20f39510$62dabf30$@cx> <467C1DC0.80801@psg.com> Message-ID: <467C24C3.40108@inex.ie> [cc: list slightly trimmed] Randy Bush wrote: >> As long as each entity only have a single prefix, the dfz should be >> somewhat optimal. > > great idea! was one of the rationales for A, B, and C. oops. Now Randy, a young-un like you mightn't remember back that far, but I seem to remember from the time that the primary motivation for ditching classful addressing was due to number depletion, an issue that we don't have in ipv6, and are unlikely to see in the medium to long term. Besides, ipv6 doesn't implement classful addressing; it simply allows LIRs and PI end-users a sufficiently large amount of address space that additional allocations/assignments shouldn't be necessary to even remotely the same extent as in ipv4. Nick -- Network Ability Ltd. | Head of Operations | Tel: +353 1 6169698 3 Westland Square | INEX - Internet Neutral | Fax: +353 1 6041981 Dublin 2, Ireland | Exchange Association | Email: nick at inex.ie From crain at icann.org Fri Jun 22 21:12:48 2007 From: crain at icann.org (John Crain) Date: Fri, 22 Jun 2007 12:12:48 -0700 Subject: [address-policy-wg] Re: [GLOBAL-V6] [ppml] How to get a IPv6 /32 the cheap way: go to AFRINIC In-Reply-To: <84C1471F-22C0-4970-A939-835B6E9770CF@virtualized.org> References: <84C1471F-22C0-4970-A939-835B6E9770CF@virtualized.org> Message-ID: <8A8ED2E2-1EE3-4BB4-A75E-266E4E195AA1@icann.org> Am going to assume that was a rhetorical question;) I believe that the services needed to allocate address space are indeed critical to continue expansion of the networks and to enabling ISPs to get their addresses. Some of the other services operated by RIR's include DNS for reverse delegation etc. are also in a similar category. So in as far as any of the registration systems and some of the related infrastructure are "Critical" then I think IANA and the RIRs are in a similar boat. Of course if any of our networks disappeared for a few hours life would go on.. In fact I remember a situation in the mid 90's when we had such a fun day at the RIPE NCC:) Most of the policies I've seen recognise this. So probably the most important measure of whether or not they are deemed critical is the fact that the community has decided that this is the case. John L. Crain On Jun 22, 2007, at 9:45 AM, David Conrad wrote: > On Jun 22, 2007, at 11:17 AM, JORDI PALET MARTINEZ wrote: >> RIRs can be considered, and in fact they are, critical >> infrastructures, > > Why? > > Rgds, > -drc > > _______________________________________________ > global-v6 mailing list > global-v6 at lists.apnic.net > http://mailman.apnic.net/mailman/listinfo/global-v6 From randy at psg.com Mon Jun 25 03:57:51 2007 From: randy at psg.com (Randy Bush) Date: Sun, 24 Jun 2007 15:57:51 -1000 Subject: [address-policy-wg] Re: [GLOBAL-V6] [ppml] How to get a IPv6 /32 the cheap way: go to AFRINIC In-Reply-To: References: <84C1471F-22C0-4970-A939-835B6E9770CF@virtualized.org> Message-ID: <467F211F.8040203@psg.com> we all think we're critical, john. the original point was root servers, as their ip addresses are hard coded in jillions of systems around the solar system. from there, it has been the typical slippery slope. now folk think their grandma is critically ill and needs a /32. entropic social effect. when design is by committee, eventually everything turns into crap. randy From aalain at trstech.net Fri Jun 22 15:54:43 2007 From: aalain at trstech.net (Alain Patrick AINA) Date: Fri, 22 Jun 2007 13:54:43 +0000 Subject: [address-policy-wg] Re: [GLOBAL-V6] How to get a IPv6 /32 the cheap way: go to AFRINIC In-Reply-To: <467BCF8B.4090308@spaghetti.zurich.ibm.com> References: <467BCF8B.4090308@spaghetti.zurich.ibm.com> Message-ID: <200706221354.43921.aalain@trstech.net> On Friday 22 June 2007 13:32:59 Jeroen Massar wrote: > [*full rant mode*] > > My eye just fell on a very strange new allocation, apparently made under > some new rules in the AFRINIC region which seem to be very wasteful and > very out of sync with the rest of the world who are at least thinking a bit > about address conservation instead of just blowing address space like there > is no tomorrow: > > http://www.afrinic.net/docs/policies/afpol-v6200407-000.htm#5 details: > 8<-------------- > 5.1.1. Initial allocation criteria > To qualify for an initial allocation of IPv6 address space, an organization > must: a) be an LIR; > b) not be an end site; > c) show a detailed plan to provide IPv6 connectivity to organizations in > the AfriNIC region. > d) show a reasonable plan for making /48 IPv6 assignments to end sites in > the AfriNIC region within twelve months. The LIR should also plan to > announce the allocation as a single aggregated block in the inter-domain > routing system within twelve months. > > 5.1.2. Initial allocation size > > Organizations that meet the initial allocation criteria are eligible to > receive a minimum allocation of /32. > ---------------------------------------------->8 > > Wow, so you make a new 'company' in 911 land and say "I am going to > allocate a single /48" and you get a FULL /32 even when you will never ever > ever use it or even are going to think about using it? This does not meet the requirements above. So you won't get it. --alain From aa at tenet.ac.za Fri Jun 22 16:50:38 2007 From: aa at tenet.ac.za (Andrew Alston) Date: Fri, 22 Jun 2007 16:50:38 +0200 Subject: [address-policy-wg] RE: [afripv6-discuss] Re: [ppml] How to get a IPv6 /32 the cheap way: go to AFRINIC In-Reply-To: References: <467BCF8B.4090308@spaghetti.zurich.ibm.com> Message-ID: <000f01c7b4dc$b8c91860$2a5b4920$@ac.za> I have to agree with Jeroen on this one... How does AfriNIC qualify for more than any other organization getting P.I Space. If we consider that AfriNIC is *NOT* an LIR (you cant be an LIR *and* an RIR?) then we have to consider the space provider independent. If so, the /32 is a violation of the P.I policy found at http://www.afrinic.net/docs/policies/afpol-v6200701.htm To quote the policy point (3): * The intial provider independent assignment size to an end-site should be a /48, or a shorter prefix if the end-site can justify it. As Jeroen says, there needs to be justification. Just my 2c Andrew Alston TENET - Chief Technology Officer -----Original Message----- From: afripv6-discuss-bounces at afrinic.net [mailto:afripv6-discuss-bounces at afrinic.net] On Behalf Of JORDI PALET MARTINEZ Sent: Friday, June 22, 2007 4:06 PM To: ppml at arin.net; ARIN Address Policy; RIPE Address Policy; IPv6 in Africa ; APNIC IPv6 Subject: [afripv6-discuss] Re: [ppml] How to get a IPv6 /32 the cheap way: go to AFRINIC Jeroen, This is just ridiculous. All the RIRs have their own /32 for their internal usage. Regards, Jordi > De: Jeroen Massar > Organizaci?n: Unfix > Responder a: > Fecha: Fri, 22 Jun 2007 14:32:59 +0100 > Para: ARIN Address Policy , RIPE Address Policy > , AFRNIC IPv6 , APNIC > IPv6 > Asunto: [ppml] How to get a IPv6 /32 the cheap way: go to AFRINIC > > [*full rant mode*] > > My eye just fell on a very strange new allocation, apparently made under some > new rules in the AFRINIC region which seem to be very wasteful and very out of > sync with the rest of the world who are at least thinking a bit about address > conservation instead of just blowing address space like there is no tomorrow: > > http://www.afrinic.net/docs/policies/afpol-v6200407-000.htm#5 details: > 8<-------------- > 5.1.1. Initial allocation criteria > To qualify for an initial allocation of IPv6 address space, an organization > must: > a) be an LIR; > b) not be an end site; > c) show a detailed plan to provide IPv6 connectivity to organizations in the > AfriNIC region. > d) show a reasonable plan for making /48 IPv6 assignments to end sites in the > AfriNIC region within twelve months. The LIR should also plan to announce the > allocation as a single aggregated block in the inter-domain routing system > within twelve months. > > 5.1.2. Initial allocation size > > Organizations that meet the initial allocation criteria are eligible to > receive a minimum allocation of /32. > ---------------------------------------------->8 > > Wow, so you make a new 'company' in 911 land and say "I am going to allocate a > single /48" and you get a FULL /32 even when you will never ever ever use it > or even are going to think about using it? > > The first "organization" which is using this to waste space seems to be: > > inet6num: 2001:42d0::/32 > netname: AfriNIC-IPv6-1 > descr: AfriNIC > descr: RIR > country: MU > > Gee, the RIR itself. How many people are using the AFRINIC network? 10-50? Are > they really *ever* going to need more than a /48? Are they ever going to have > a need for 65536 of those /48's? > > Really this is just a waste of address space. Yes there is "enough", but being > sooo obviously wasteful just to be able to have a nice slot in the routing > tables is a bit over done. > > > I hope that the other regions take this in mind too when (re)considering their > address policies. > > Giving out /48's or even a /40 to an organization that is in-effect an > end-site I can understand, especially when they can justify the need for that > amount of address space. But giving /32's to every single endsite that simply > asks for it is very very very far fetched. They will not even ever fill up a > /40 of address space even if they would have two sites (read: offices) in > every country in Africa, let alone 65536 sites. Such a waste. > > Funnily later in the above document they point to HD ratios. What point is > that when the waste is already happened? > > > RIR's should be giving out address space based on "need" and that need must > justified, giving out /32's as "those fit in the routing slots" is a really > really bad idea. > > In short: if you want a nice /32 without issues: setup a small shop in Africa > and presto! > > Greets, > Jeroen > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml ********************************************** 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. _______________________________________________ afripv6-discuss mailing list afripv6-discuss at afrinic.net https://lists.afrinic.net/mailman/listinfo.cgi/afripv6-discuss From adiel at afrinic.net Fri Jun 22 16:45:53 2007 From: adiel at afrinic.net (Adiel A. Akplogan) Date: Fri, 22 Jun 2007 18:45:53 +0400 Subject: [address-policy-wg] Re: [GLOBAL-V6] How to get a IPv6 /32 the cheap way: go to AFRINIC In-Reply-To: <467BCF8B.4090308@spaghetti.zurich.ibm.com> References: <467BCF8B.4090308@spaghetti.zurich.ibm.com> Message-ID: <200706221451.l5MEpIQP012336@ns1.afrinic.net> Hello Jeroen, >[*full rant mode*] > >My eye just fell on a very strange new allocation, apparently made under some >new rules in the AFRINIC region which seem to be very wasteful and very out of >sync with the rest of the world who are at least thinking a bit about address >conservation instead of just blowing address space like there is no tomorrow: > >http://www.afrinic.net/docs/policies/afpol-v6200407-000.htm#5 details: >8<-------------- >5.1.1. Initial allocation criteria >To qualify for an initial allocation of IPv6 address space, an >organization must: >a) be an LIR; >b) not be an end site; >c) show a detailed plan to provide IPv6 connectivity to organizations in the >AfriNIC region. >d) show a reasonable plan for making /48 IPv6 assignments to end sites in the >AfriNIC region within twelve months. The LIR should also plan to announce the >allocation as a single aggregated block in the inter-domain routing system >within twelve months. > >5.1.2. Initial allocation size > >Organizations that meet the initial allocation criteria are eligible to >receive a minimum allocation of /32. >---------------------------------------------->8 > >Wow, so you make a new 'company' in 911 land and say "I am going to allocate a >single /48" and you get a FULL /32 even when you will never ever ever use it >or even are going to think about using it? I think you have missed the point a) which says "be an LIR". So you must already be an LIR (and go through the LIR setup process) to get IPv6 allocation from AfrINIC. >The first "organization" which is using this to waste space seems to be: > >inet6num: 2001:42d0::/32 >netname: AfriNIC-IPv6-1 >descr: AfriNIC >descr: RIR >country: MU > >Gee, the RIR itself. How many people are using the AFRINIC network? 10-50? Are >they really *ever* going to need more than a /48? Are they ever going to have >a need for 65536 of those /48's? You can not take AfriNIC own allocation case to illustrate your assertion here ... We have allocated that bloc to our own Infrastructure (which has three locations to be connected together) so each with its own /48. Further to that we have other IPv6 Internal projects which will probably require several /48. As RIR I think we are in the position to evaluate our own need before making an allocation and if it was made be sure that is after careful evaluation. >Really this is just a waste of address space. Yes there is "enough", but being >sooo obviously wasteful just to be able to have a nice slot in the routing >tables is a bit over done. I don't see the waist. >Giving out /48's or even a /40 to an organization that is in-effect an >end-site I can understand, especially when they can justify the need for that >amount of address space. But giving /32's to every single endsite that simply >asks for it is very very very far fetched. They will not even ever fill up a >/40 of address space even if they would have two sites (read: offices) in >every country in Africa, let alone 65536 sites. Such a waste. Please read http://www.afrinic.net/docs/policies/afpol-v6200701.htm >Funnily later in the above document they point to HD ratios. What point is >that when the waste is already happened? I think you are confusing the IPv6 allocation to LIR document with PI assignment document which in fact was a proposal until few days where it was ratified by AfriNIC board (... but not yet implemented). >RIR's should be giving out address space based on "need" and that need must >justified, giving out /32's as "those fit in the routing slots" is a really >really bad idea. That is what we do. You can not have such affirmation based on a single case. >In short: if you want a nice /32 without issues: setup a small shop in Africa >and presto! You won't get it like that. - a. From aalain at trstech.net Fri Jun 22 17:26:45 2007 From: aalain at trstech.net (Alain Patrick AINA) Date: Fri, 22 Jun 2007 15:26:45 +0000 Subject: [address-policy-wg] Re: [GLOBAL-V6] [ppml] How to get a IPv6 /32 the cheap way: go to AFRINIC In-Reply-To: <467BDA31.4030607@spaghetti.zurich.ibm.com> References: <467BDA31.4030607@spaghetti.zurich.ibm.com> Message-ID: <200706221526.46024.aalain@trstech.net> On Friday 22 June 2007 14:18:25 Jeroen Massar wrote: > > Alain Patrick AINA wrote: > > This does not meet the requirements above. So you won't get it. > > It fully does, how else did AFRINIC assign a /32 to themselves? This would have been your question instead of concluding so negatively on a global note. --alain From pesherb at yahoo.com Fri Jun 22 18:07:33 2007 From: pesherb at yahoo.com (Peter Sherbin) Date: Fri, 22 Jun 2007 09:07:33 -0700 (PDT) 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> Message-ID: <20070622160733.264.qmail@web58705.mail.re1.yahoo.com> > We can indeed give IPv6 prefixes for free, give every household a /32, and > we'll probably not run out yet... But is that really what people want? Precisely. Any entity with a free will is entitled to a part of IPv6 space free of charge. And yes we will need enough addresses pointing to every cell in a human body. Wether current policies and architecture support it and if such space will be used any time soon is another question under discussion, e.g. RAM, etc. Thanks, Peter --- Jeroen Massar wrote: > Alain Patrick AINA wrote: > > On Friday 22 June 2007 14:18:25 Jeroen Massar wrote: > > > >> Alain Patrick AINA wrote: > >>> This does not meet the requirements above. So you won't get it. > >> It fully does, how else did AFRINIC assign a /32 to themselves? > > > > This would have been your question instead of concluding so negatively on a > > global note. > > Excuses, I will try to add a short bullet pointed list of items next time with > a nice animated powerpoint presentation and an executive summary to make my > question come across to you. > > 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. > > Their statement of "we are a RIR we know what we are doing" is not good > enough, especially as there is no active policy actually allowing them to > request such a allocation even under their own policies. > > Any policy that simply allows any party to get a /32 without justification is > the same as when IPv4 started out, where everybody simply got a /8. Indeed at > that timepoint there was enough space, but what is the main complaint from > various people nowadays: that they should have gotten less as they didn't need > it in the first place. > > We can indeed give IPv6 prefixes for free, give every household a /32, and > we'll probably not run out yet; and if we do we have another 7 tries when > 2000::/3 runs full. But is that really what people want? To simply squat on > the address space as much as possible, so that you at least have it? > > Not a good thing, especially not a good thing when a RIR does it themselves. > > Greets, > Jeroen > > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml ____________________________________________________________________________________ Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it out. http://answers.yahoo.com/dir/?link=list&sid=396545469 From kosuke at bugest.net Fri Jun 22 18:04:24 2007 From: kosuke at bugest.net (Kosuke Ito) Date: Sat, 23 Jun 2007 01:04:24 +0900 Subject: [address-policy-wg] Re: [GLOBAL-V6] How to get a IPv6 /32 the cheap way: go to AFRINIC In-Reply-To: <467BCF8B.4090308@spaghetti.zurich.ibm.com> References: <467BCF8B.4090308@spaghetti.zurich.ibm.com> Message-ID: <467BF308.3070708@bugest.net> Please read carefully about the section of Critical Infrastructure. AfriNIC is eligible to have a /32 by the policy. FYI: in the APNIC case which is similar to other region more or less, their policy says, --------------------- Critical infrastructure The following critical infrastructure networks, if operating in the Asia Pacific region, are eligible to receive a portable assignment: root domain name system (DNS) server; global top level domain (gTLD) nameservers; country code TLD (ccTLDs) nameservers; IANA; Regional Internet Registry (RIRs); and National Internet Registry (NIRs). Assignments to critical infrastructure are available only to the actual operators of the network infrastructure performing such functions. Registrar organisations which do not actually host the network housing the registry infrastructure, will not be eligible for an assignment under this policy. The maximum assignment made under these terms is /32 per operator. ---------------------------- For IXs, there is another space reserved to allocate a /48 each IX for their need of globally independent but not routable. It is a good timing to learn about the allocation policy, and if there is something outdated, let's review and renew that point. Best regards, Kosuke Jeroen Massar wrote: > [*full rant mode*] > > My eye just fell on a very strange new allocation, apparently made under some > new rules in the AFRINIC region which seem to be very wasteful and very out of > sync with the rest of the world who are at least thinking a bit about address > conservation instead of just blowing address space like there is no tomorrow: > > http://www.afrinic.net/docs/policies/afpol-v6200407-000.htm#5 details: > 8<-------------- > 5.1.1. Initial allocation criteria > To qualify for an initial allocation of IPv6 address space, an organization must: > a) be an LIR; > b) not be an end site; > c) show a detailed plan to provide IPv6 connectivity to organizations in the > AfriNIC region. > d) show a reasonable plan for making /48 IPv6 assignments to end sites in the > AfriNIC region within twelve months. The LIR should also plan to announce the > allocation as a single aggregated block in the inter-domain routing system > within twelve months. > > 5.1.2. Initial allocation size > > Organizations that meet the initial allocation criteria are eligible to > receive a minimum allocation of /32. > ---------------------------------------------->8 > > Wow, so you make a new 'company' in 911 land and say "I am going to allocate a > single /48" and you get a FULL /32 even when you will never ever ever use it > or even are going to think about using it? > > The first "organization" which is using this to waste space seems to be: > > inet6num: 2001:42d0::/32 > netname: AfriNIC-IPv6-1 > descr: AfriNIC > descr: RIR > country: MU > > Gee, the RIR itself. How many people are using the AFRINIC network? 10-50? Are > they really *ever* going to need more than a /48? Are they ever going to have > a need for 65536 of those /48's? > > Really this is just a waste of address space. Yes there is "enough", but being > sooo obviously wasteful just to be able to have a nice slot in the routing > tables is a bit over done. > > > I hope that the other regions take this in mind too when (re)considering their > address policies. > > Giving out /48's or even a /40 to an organization that is in-effect an > end-site I can understand, especially when they can justify the need for that > amount of address space. But giving /32's to every single endsite that simply > asks for it is very very very far fetched. They will not even ever fill up a > /40 of address space even if they would have two sites (read: offices) in > every country in Africa, let alone 65536 sites. Such a waste. > > Funnily later in the above document they point to HD ratios. What point is > that when the waste is already happened? > > > RIR's should be giving out address space based on "need" and that need must > justified, giving out /32's as "those fit in the routing slots" is a really > really bad idea. > > In short: if you want a nice /32 without issues: setup a small shop in Africa > and presto! > > Greets, > Jeroen > > > > ------------------------------------------------------------------------ > > _______________________________________________ > global-v6 mailing list > global-v6 at lists.apnic.net > http://mailman.apnic.net/mailman/listinfo/global-v6 -- ***************IPv6 Internet Wonderland!****************** Kosuke Ito Master Planning and Steering Gr., IPv6 Prom. Council of JP New Business Office/President Office, IRI Ubiteq, Inc. (Visiting Researcher, SFC Lab. KEIO University) Tel:+81-3-3344-7511 Fax:+81-3-3344-7522 Cell:+81-90-9826-4220 mailto: kosuke[at]v6pc.jp http://www.v6pc.jp/ mailto: k-ito[at]ubiteq.co.jp Lifetime e-mail: kosuke[at]stanfordalumni.org From drc at virtualized.org Fri Jun 22 18:45:31 2007 From: drc at virtualized.org (David Conrad) Date: Fri, 22 Jun 2007 12:45:31 -0400 Subject: [address-policy-wg] Re: [GLOBAL-V6] [ppml] How to get a IPv6 /32 the cheap way: go to AFRINIC In-Reply-To: References: Message-ID: <84C1471F-22C0-4970-A939-835B6E9770CF@virtualized.org> On Jun 22, 2007, at 11:17 AM, JORDI PALET MARTINEZ wrote: > RIRs can be considered, and in fact they are, critical > infrastructures, Why? Rgds, -drc From drc at virtualized.org Fri Jun 22 19:41:52 2007 From: drc at virtualized.org (David Conrad) Date: Fri, 22 Jun 2007 13:41:52 -0400 Subject: [address-policy-wg] Re: [ppml] Re : on PPML? - was Re: How to get ... In-Reply-To: <378359.11161.qm@web27508.mail.ukl.yahoo.com> References: <378359.11161.qm@web27508.mail.ukl.yahoo.com> Message-ID: Iwu, > Have you also come across the following address waist? I haven't seen > you guys making any noise about them! > > 014/8 Jun 91 IANA - Public Data Network > ---- (a whole /8 for an organisation of less than 20 people?) Actually, the PDN /8 was allocated for integrating X.25 networks into the Internet. Individual /32s were assigned to X.25 endpoints run by different companies, so representing 14/8 as "a whole /8 for an organization of less than 20 people" is not accurate. And besides, Leo Vegoda has been very active in recovering the /32s so we can return 14/8 to the free pool. There used to be over 200 assignments in that /8. There are lots of better examples in the "legacy /8" space, however I'm not sure "historical reasons" is a good rationale for current policy in an entirely different address space. > inet6num: 2001:07F8::/29 > inet6num: 2001:07FD::/32 > netname: K-rootserver-net-20030829 > descr: This assignment given to k-root.server.net > descr: maintained by the RIPE NCC > > --- (just for the Kroot server Infratsructure ????? is this an LIR) Because root name server addresses must be encoded into configurations of all caching servers on the Internet, I believe that they are very special and should be treated specially. Rgds, -drc From john.crain at icann.org Fri Jun 22 20:08:01 2007 From: john.crain at icann.org (John Crain) Date: Fri, 22 Jun 2007 11:08:01 -0700 Subject: [address-policy-wg] Re: [GLOBAL-V6] [ppml] How to get a IPv6 /32 the cheap way: go to AFRINIC In-Reply-To: <84C1471F-22C0-4970-A939-835B6E9770CF@virtualized.org> References: <84C1471F-22C0-4970-A939-835B6E9770CF@virtualized.org> Message-ID: Am going to assume that was a rhetorical question;) I believe that the services needed to allocate address space are indeed critical to continue expansion of the networks and to enabling ISPs to get their addresses. Some of the other services operated by RIR's include DNS for reverse delegation etc. are also in a similar category. So in as far as any of the registration systems and some of the related infrastructure are "Critical" then I think IANA and the RIRs are in a similar boat. Of course if any of our networks disappeared for a few hours life would go on.. In fact I remember a situation in the mid 90's when we had such a fun day at the RIPE NCC:) Most of the policies I've seen recognise this. So probably the most important measure of whether or not they are deemed critical is the fact that the community has decided that this is the case. John L. Crain On Jun 22, 2007, at 9:45 AM, David Conrad wrote: > On Jun 22, 2007, at 11:17 AM, JORDI PALET MARTINEZ wrote: >> RIRs can be considered, and in fact they are, critical >> infrastructures, > > Why? > > Rgds, > -drc > > _______________________________________________ > global-v6 mailing list > global-v6 at lists.apnic.net > http://mailman.apnic.net/mailman/listinfo/global-v6 From latif at ladid.lu Fri Jun 22 20:50:44 2007 From: latif at ladid.lu (Latif LADID ("The New Internet based on IPv6")) Date: Fri, 22 Jun 2007 20:50:44 +0200 Subject: [address-policy-wg] RE: [afripv6-discuss] Re: [GLOBAL-V6] [ppml] How to get a IPv6 /32 the cheap way: go to AFRINIC In-Reply-To: <467BF422.7030901@spaghetti.zurich.ibm.com> References: <467BDA31.4030607@spaghetti.zurich.ibm.com><467BEE69.60906@inex.ie> <467BF422.7030901@spaghetti.zurich.ibm.com> Message-ID: <025101c7b4fe$3df99c50$ec1afea9@ipv6forum> Joeren, To be fair, start your rant also about those that got /13 and those that got /19 :-) Latif -----Original Message----- From: afripv6-discuss-bounces at afrinic.net [mailto:afripv6-discuss-bounces at afrinic.net] On Behalf Of Jeroen Massar Sent: 22 June 2007 18:09 To: Nick Hilliard Cc: ppml at arin.net; APNIC IPv6; RIPE Address Policy; IPv6 in Africa Subject: [afripv6-discuss] Re: [GLOBAL-V6] [ppml] How to get a IPv6 /32 the cheap way: go to AFRINIC Nick Hilliard wrote: > Jeroen Massar wrote: >> I agree that when an organization can justify (using HD ratios etc) >> the need for address space that they will fully be able to get that >> address space without any issues. But is AFRINIC (10-50 people) able >> to justify a >> /32 based >> on that? > > Jeroen, > > you're muddling two separate issues here. > > 1. There is no special justification for a LIR to be assigned a /32 in > afrinic areas. As far as I'm concerned, this is fine and I'd be all > in favour of this sort of allocation guideline making its way into RIPE-land. I am also fine with that as long as there is a justification for the address space. Just being LIR is not good enough IMHO. Address space should be provided under the premise that it will actually be used one day. As such /48's are very appropriate for end-sites, upto /40 for large corporations, anything above that should be able to get a /32. But this all by justification of need. That we have enough address space today is great, but when they invent this nice "stay young forever pill to fly to Jupiter and back forever", then people in that era and everybody else also want to have IPv6 address space (unless we replace it again by then :). This thus might affect you yourself too, as such, I speak up on this. > 2. Afrinic allocated themselves a /32. > > Afrinic are a RIR, not a LIR, and it appears that they broke the rules > by allocating themselves a /32 (i.e. LIR size) instead of a /48 > (end-user size). And also without any real justification, as of yet. > This is not good. The least we expect from the (monopolistic) RIRs is > that they abide strictly by the rules set out by themselves and the > community. If they have any sense in the matter, they'll hand > themselves back the /32 and re-assign themselves a /48 under the > generic PI assignment classification. And nobody (I think :) would have a problem with that. Even a /45 would not be looked strangely at, as they can JUSTIFY that amount of address space. (3 offices, 5 very very large projects, reasonably believable IMHO) A /32, is not though. > TBH, the amount of address space which Afrinic allocated to themselves > is of very little technical importance. I agree, relative to a 128bits of address space, a /32 is effectively nothing. > What's relevant is that they broke their own rules, which will damage > their reputation and the level of trust they have in their geographic area. Absolutely. Thanks for getting that out of my ramblings. Greets, Jeroen From bmanning at vacation.karoshi.com Sat Jun 23 14:41:53 2007 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sat, 23 Jun 2007 12:41:53 +0000 Subject: [address-policy-wg] Re: [ppml] [GLOBAL-V6] How to get a IPv6 /32 the cheap way: go to AFRINIC In-Reply-To: <467BEA7B.1000608@spaghetti.zurich.ibm.com> References: <467BEA7B.1000608@spaghetti.zurich.ibm.com> Message-ID: <20070623124153.GA25412@vacation.karoshi.com.> On Fri, Jun 22, 2007 at 04:27:55PM +0100, Jeroen Massar wrote: > > According to your analogy, anybody should be getting IPv4 /24 or IPv6 /32's > simply because they have 1 box somewhere and they are afraid of being filtered. > > That is not how justification of address space works. If it does work that way > today, then it definitely has to be changed ASAP. > > Greets, > Jeroen Jeroen, You have your mission then. Since RIR policies are set regionally, BY THEIR MEMBERS and not globally, you can affect change by going to each RIR and persuading their members to support your policy proposals. When/If you can get concensus by ALL the RIRs on a given suite of policy, Then you get a global policy. See how easy it is? > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml From jordi.palet at consulintel.es Mon Jun 25 22:34:20 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Mon, 25 Jun 2007 16:34:20 -0400 Subject: [address-policy-wg] 2006-02 Last Call for Comments (IPv6 Address Allocation and Assignment Policy) In-Reply-To: Message-ID: Hi Leo, See below. Regards, Jordi > De: Leo Vegoda > Responder a: > Fecha: Thu, 21 Jun 2007 21:51:04 +0200 > Para: > CC: > Asunto: Re: [address-policy-wg] 2006-02 Last Call for Comments (IPv6 Address > Allocation and Assignment Policy) > > Hi Jordi, > > On 21 Jun 2007, at 7:38am, JORDI PALET MARTINEZ wrote: >> >> We are talking about two different things/cases. >> >> Both proposals may seem as related, but actually they are not. >> >> In fact, we can't relate both policy proposals also, because it is >> not clear >> that 2006-01 will go further (at least not with the actual text), as I >> didn't got inputs to my last replies to previous inputs :-( So it is >> difficult for me to keep going w/o community review. > > 2006-01 seems to have had a couple of dozen comments on it over the > last month, actually. Are you referring to something else? I posted some answers to the 2006-1 comments, but never got them replied back (I will check again in case I'm missing anything). > >> 2006-02 is intended for entities that have their own network with >> multiple >> sites. > > I think the intention makes sense but the phrasing of the policy text > needs some work. > > It looks like you want an end site to qualify for a /32 IPv6 > allocation if it needs to make *any* size of assignment to multiple > internal sites. But the text doesn't actually define what one of > these internal sites is. That creates a problem for anyone that wants > one of these /32 allocations because they can't work out if they > qualify for it or ought to try and get a /47 (or whatever) under the > IPv6 PI policy. We can't base this policy proposal in the existence of the IPv6 PI one, because it is not the case. Also, I'm not modifying the way hostsmasters will evaluate the need. If this needs to be fine tuned, my view is that should be done in an alternative proposal (we already discussed in this list about this point before the last call, and I believe the consensus was "let's move ahead and if we need to improve it, let's make it in further reviews"). > > If the policy text is confusing it's going to create lots of extra > work for the requesters and the RIPE NCC. I don't really think it is the case. It will be the same right now for anyone, requesting space because "plan for 200 sites" is basically a lie. We have removed this in other regions, I don't see why we are still willing to set a new barrier, which may become artificial again. > >> Those sites behave as end-sites to the "internal" ISP. This is for >> example the case of Universities, or NATO (just to mention a clear >> case) >> that already have indicated in the list their need. I don't see >> those as PI >> cases, because they are by their own real ISPs, even if for the >> same entity, >> they have their own NOC, staff, etc. to manage the network. >> >> Instead 2006-01 is looking for PI cases, for example a data center. >> >> So I don't see the need to stop 2006-02, and what it is really >> needed is to >> get more input on 2006-01 ! > > I think the issue still remains: 2006-01 and 2006-02 need to work > together closely. Presumably, a network that does not qualify for a / > 47 should not qualify to receive a /32. Or should it? It is not a matter of the size of the prefix. It is a matter of understanding if we are talking about an ISP or something different. An ISP, even if it is an ISP for a specific organization (one that has several sites and consequently need to assign space to them), requires PA. The other cases requires PI. > > If it should not then how does this policy text ensure that? Because > as far as I can tell there isn't a good definition of what one of > these 'final' sites is, so anyone can claim that every /64 in their > internal network is a site and get a /32 allocation. Same as today. I still believe we should move ahead, and if required improve it in following cycles, not be stuck forever. > > Regards, > > -- > Leo Vegoda > IANA Numbers Liaison > ********************************************** 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 leo.vegoda at icann.org Tue Jun 26 00:02:19 2007 From: leo.vegoda at icann.org (Leo Vegoda) Date: Mon, 25 Jun 2007 18:02:19 -0400 Subject: [address-policy-wg] 2006-02 Last Call for Comments (IPv6 Address Allocation and Assignment Policy) In-Reply-To: References: Message-ID: <3579DE61-A788-4FD0-854C-3EEFEFBE9931@icann.org> Hi Jordi, On 25 Jun 2007, at 4:34pm, JORDI PALET MARTINEZ wrote: [...] >> It looks like you want an end site to qualify for a /32 IPv6 >> allocation if it needs to make *any* size of assignment to multiple >> internal sites. But the text doesn't actually define what one of >> these internal sites is. That creates a problem for anyone that wants >> one of these /32 allocations because they can't work out if they >> qualify for it or ought to try and get a /47 (or whatever) under the >> IPv6 PI policy. > > We can't base this policy proposal in the existence of the IPv6 PI > one, > because it is not the case. We can't base one on the other but if both proposals make it through the PDP and become policies it would be a shame if they didn't work well together. [...] >> If the policy text is confusing it's going to create lots of extra >> work for the requesters and the RIPE NCC. > > I don't really think it is the case. It will be the same right now for > anyone, requesting space because "plan for 200 sites" is basically > a lie. We > have removed this in other regions, I don't see why we are still > willing to > set a new barrier, which may become artificial again. I see lots of extra work because I find the proposed policy text confusing. The definitions are vague and that makes it difficult to work out how to apply the conditions. Each requester needs to understand the policy so that they can decide if they qualify and then send in a request. If they find the policy text confusing the RIPE NCC needs to produce an explanation in training material, in e- mail or over the telephone. But wouldn't it be better if the policy text didn't need explanation? I agree that the current policy is flawed but is this proposal an improvement? It seems to maintain the form of the current policy while removing its context. If the intention is to ensure that all LIRs can have a /32 then why not just say that RIPE NCC membership qualifies an LIR for a /32? If RIPE NCC membership alone if not enough then I think you need to work on the definition of a site because I find the recursive nature of your proposed text difficult to understand. [...] >> If it should not then how does this policy text ensure that? Because >> as far as I can tell there isn't a good definition of what one of >> these 'final' sites is, so anyone can claim that every /64 in their >> internal network is a site and get a /32 allocation. > > Same as today. I still believe we should move ahead, and if > required improve > it in following cycles, not be stuck forever. I'm not opposed to making IPv6 address space available to all the networks that need it. I just think basing the policy for doing so on a concept that is so slippery we can't really define it is fatally flawed. If the net effect of your proposal would be that more than 95% of members would qualify for a /32 allocation it is probably simpler to just make the qualifying criterion being a RIPE NCC member. That way we can get rid of impossible to define concepts like "End Site" and near-but-not-quite restrictions, like the requirement for a plan to make more than one assignment to an end site within two years. [slightly reordered] >>> I think the issue still remains: 2006-01 and 2006-02 need to work >>> together closely. Presumably, a network that does not qualify for >>> a / >>> 47 should not qualify to receive a /32. Or should it? >> >> It is not a matter of the size of the prefix. It is a matter of >> understanding if we are talking about an ISP or something >> different. An ISP, >> even if it is an ISP for a specific organization (one that has >> several sites >> and consequently need to assign space to them), requires PA. The >> other cases >> requires PI. 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? Regards, -- Leo Vegoda IANA Numbers Liaison From gert at space.net Tue Jun 26 16:19:28 2007 From: gert at space.net (Gert Doering) Date: Tue, 26 Jun 2007 16:19:28 +0200 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: <20070626141928.GT69215@Space.Net> Hi, On Mon, Jun 25, 2007 at 06:02:19PM -0400, Leo Vegoda wrote: > I'm not opposed to making IPv6 address space available to all the > networks that need it. I just think basing the policy for doing so on > a concept that is so slippery we can't really define it is fatally > flawed. If the net effect of your proposal would be that more than > 95% of members would qualify for a /32 allocation it is probably > simpler to just make the qualifying criterion being a RIPE NCC member. Well. Let's do a straw poll... "who is in favour of doing so?" I think it would make sense, to have "full-weight" LIRs that automatically get a /32-or-bigger allocation, and possibly "light-weight" RIPE "customers" (to get the contractual stuff that is desired) that get a /48-or-so PI. Just as a rough outline - details to be worked out. 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 nick at inex.ie Tue Jun 26 16:35:40 2007 From: nick at inex.ie (Nick Hilliard) Date: Tue, 26 Jun 2007 15:35:40 +0100 Subject: [address-policy-wg] 2006-02 Last Call for Comments (IPv6 Address Allocation and Assignment Policy) In-Reply-To: <20070626141928.GT69215@Space.Net> References: <3579DE61-A788-4FD0-854C-3EEFEFBE9931@icann.org> <20070626141928.GT69215@Space.Net> Message-ID: <4681243C.2010507@inex.ie> >> flawed. If the net effect of your proposal would be that more than >> 95% of members would qualify for a /32 allocation it is probably >> simpler to just make the qualifying criterion being a RIPE NCC member. > > Well. Let's do a straw poll... > > "who is in favour of doing so?" Me. I've expressed this opinion lots of times, although Leo's justification for it is characteristically succinct. Messing around with restrictive policies which are just going to end up making LIRs lie about their requirements is both silly and counter- productive. If a LIR applies for IPv6 address space, they are presumably going to use it. If they don't want it, they are not going to apply for it. What's the big issue here? I would like to see something along the lines of: "A LIR is automatically entitled to an initial IPv6 /32 allocation. If the LIR requires a larger initial allocation or subsequently requires further allocations, justification must be provided." Everyone's been tying themselves up in knots about this policy proposal since May last year, and we've really got no-where since Jordi's original document. Meanwhile, LIRs are still lying, and RIPE is still turning a blind eye to this. Nick -- Network Ability Ltd. | Head of Operations | Tel: +353 1 6169698 3 Westland Square | INEX - Internet Neutral | Fax: +353 1 6041981 Dublin 2, Ireland | Exchange Association | Email: nick at inex.ie From jeroen at unfix.org Tue Jun 26 20:00:52 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 26 Jun 2007 19:00:52 +0100 Subject: [address-policy-wg] 2006-02 Last Call for Comments (IPv6 Address Allocation and Assignment Policy) In-Reply-To: <20070626141928.GT69215@Space.Net> References: <3579DE61-A788-4FD0-854C-3EEFEFBE9931@icann.org> <20070626141928.GT69215@Space.Net> Message-ID: <46815454.6050908@spaghetti.zurich.ibm.com> Gert Doering wrote: [..] > I think it would make sense, to have "full-weight" LIRs that automatically > get a /32-or-bigger allocation, and possibly "light-weight" RIPE "customers" > (to get the contractual stuff that is desired) that get a /48-or-so PI. > > Just as a rough outline - details to be worked out. The outline sounds good to me, you have my support (though of course show details first ;). And it is *MUCH* better than the current proposals which are simply going to waste address space. It is then also very simple "become member, pay fees, justify space requirement, get it, done presto" Also that avoids any need for ULA-C as everybody is covered. Now if only the rest of the RIR community was able to understand that point. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From nick at inex.ie Tue Jun 26 21:41:01 2007 From: nick at inex.ie (Nick Hilliard) Date: Tue, 26 Jun 2007 20:41:01 +0100 Subject: [address-policy-wg] 2006-02 Last Call for Comments (IPv6 Address Allocation and Assignment Policy) In-Reply-To: <46815454.6050908@spaghetti.zurich.ibm.com> References: <3579DE61-A788-4FD0-854C-3EEFEFBE9931@icann.org> <20070626141928.GT69215@Space.Net> <46815454.6050908@spaghetti.zurich.ibm.com> Message-ID: <46816BCD.6090104@inex.ie> Jeroen Massar wrote: > It is then also very simple "become member, pay fees, justify space > requirement, get it, done presto" The whole point is that it's even simpler: "become member, pay fees, get space, done presto" Incidentally, this is irrelevant to ULA-C, which is primarily intended for end-users. Nick From rogerj at jorgensen.no Tue Jun 26 23:14:12 2007 From: rogerj at jorgensen.no (Roger Jorgensen) Date: Tue, 26 Jun 2007 23:14:12 +0200 (CEST) Subject: [address-policy-wg] 2006-02 Last Call for Comments (IPv6 Address Allocation and Assignment Policy) In-Reply-To: <46815454.6050908@spaghetti.zurich.ibm.com> References: <3579DE61-A788-4FD0-854C-3EEFEFBE9931@icann.org> <20070626141928.GT69215@Space.Net> <46815454.6050908@spaghetti.zurich.ibm.com> Message-ID: On Tue, 26 Jun 2007, Jeroen Massar wrote: > Gert Doering wrote: > [..] >> I think it would make sense, to have "full-weight" LIRs that automatically >> get a /32-or-bigger allocation, and possibly "light-weight" RIPE "customers" >> (to get the contractual stuff that is desired) that get a /48-or-so PI. >> >> Just as a rough outline - details to be worked out. > > The outline sounds good to me, you have my support (though of course > show details first ;). My support to. Could maybe make it as easy as to have different fee and some too strict definition of what is full and light. full = can justify /32 with /200 customers (yeah I know it's that 200 rule...) light = everyone else, even if you can justify a /32... the fee atleast 50% lower than the above. > And it is *MUCH* better than the current proposals which are simply > going to waste address space. > > It is then also very simple "become member, pay fees, justify space > requirement, get it, done presto" > > Also that avoids any need for ULA-C as everybody is covered. > Now if only the rest of the RIR community was able to understand that point. we'll get there after a while:) -- ------------------------------ Roger Jorgensen | - ROJO9-RIPE - RJ85P-NORID roger at jorgensen.no | - IPv6 is The Key! ------------------------------------------------------- From mpb at melitacable.com Tue Jun 26 21:09:32 2007 From: mpb at melitacable.com (Mark Pace Balzan) Date: Tue, 26 Jun 2007 21:09:32 +0200 Subject: [address-policy-wg] 2006-02 Last Call for Comments (IPv6 Address Allocation and Assignment Policy) In-Reply-To: <46815454.6050908@spaghetti.zurich.ibm.com> Message-ID: <6A200388CCDEE04485DA0BB2BA064E3101E4AD96@TANGO.melita.local> Seconded.... Good to see a refreshing 'short and to the point' suggestion. After all that has been said over the past months, I guess we need something that will work, rather than be worked-around ! Mark > -----Original Message----- > From: address-policy-wg-admin at ripe.net > [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Jeroen Massar > Sent: 26 June 2007 20:01 > To: Gert Doering > Cc: Leo Vegoda; address-policy-wg at ripe.net > Subject: Re: [address-policy-wg] 2006-02 Last Call for > Comments (IPv6 Address Allocation and Assignment Policy) > > Gert Doering wrote: > [..] > > I think it would make sense, to have "full-weight" LIRs > that automatically > > get a /32-or-bigger allocation, and possibly "light-weight" > RIPE "customers" > > (to get the contractual stuff that is desired) that get a > /48-or-so PI. > > > > Just as a rough outline - details to be worked out. > > The outline sounds good to me, you have my support (though of course > show details first ;). > > And it is *MUCH* better than the current proposals which are simply > going to waste address space. > > It is then also very simple "become member, pay fees, justify space > requirement, get it, done presto" > > Also that avoids any need for ULA-C as everybody is covered. > Now if only the rest of the RIR community was able to > understand that point. > > Greets, > Jeroen > > From jeroen at unfix.org Tue Jun 26 23:37:07 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 26 Jun 2007 22:37:07 +0100 Subject: [address-policy-wg] 2006-02 Last Call for Comments (IPv6 Address Allocation and Assignment Policy) In-Reply-To: <46816BCD.6090104@inex.ie> References: <3579DE61-A788-4FD0-854C-3EEFEFBE9931@icann.org> <20070626141928.GT69215@Space.Net> <46815454.6050908@spaghetti.zurich.ibm.com> <46816BCD.6090104@inex.ie> Message-ID: <46818703.1090906@spaghetti.zurich.ibm.com> Nick Hilliard wrote: > Jeroen Massar wrote: >> It is then also very simple "become member, pay fees, justify space >> requirement, get it, done presto" > > The whole point is that it's even simpler: "become member, pay fees, get > space, done presto" And which prefix size does the organization get then? There are enough end-site organizations that can easily justify a /42 worth of address space, 64 /48's isn't that much if you give every separate building where you have an office a /48 and those offices can definitely be considered sites. Easy is great, but there should be a possibility for sites to request a bit more. When the size becomes smaller than a /40 (eg /32) I do suggest that these prefixes are considered to be PA though and that they cough up the normal LIR fees, at that size one is hopefully running a nice internal ISP anyway who has LIR functions already. > Incidentally, this is irrelevant to ULA-C, which is primarily intended > for end-users. ULA-C should never come in existence in the first place. But why would an end-user not be able to request a /48 when they are willing to pay the fees? (And fill in the paper work, justification, come up with gear, connectivity, pay for all that etc). I am pretty happy that we are running SixXS, as it allows me to simply get the same /48 everywhere I go, the tunnel just moves along with me. Same goes for quite some other users who move from city to city or from country to country (this is my 3rd country for instance :) and I keep the same prefix where-ever I go. Same goes of course when you have PA space and work for an ISP and simply tunnel your own /48 to where-ever you go. As long as you are happy friends with them you can take it along with you. As for folks "but that takes up a routing slot": we now got ~800 routes in the IPv6 DFZ(*), that is a far cry from the 200k in IPv4. Before we even reach 100k most likely (and hopefully) the smart folks have come up with a nice id/loc mechanism. Then at that point the "Tier Wars" can begin, if you are cool enough, and thus have a PA prefix, you can remain in the DFZ, if you are not, thus with a /48 or so, you have to start using id/loc. As the non-PA prefixes are being allocated from well known blocks and they are non-/32 in size, filtering on the can become very easy. Also to mitigate that an ISP has a /20 PA and simply announces /32's one can of course easily handle that by having per-prefix filters. Greets, Jeroen * = before Randy jumps in, lets just define "IPv6 DFZ" as the prefixes that are seen by RIPE's RIS and GRH, those systems are public and are fed by a rather large amount of ISP's around the globe, when they have the prefixes (especially when it is >20% in GRH for instance) then it certainly can be said IMHO that the prefix is "on the Internet") -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From leo.vegoda at icann.org Wed Jun 27 00:35:20 2007 From: leo.vegoda at icann.org (Leo Vegoda) Date: Tue, 26 Jun 2007 18:35:20 -0400 Subject: [address-policy-wg] 2006-02 Last Call for Comments (IPv6 Address Allocation and Assignment Policy) In-Reply-To: <20070626141928.GT69215@Space.Net> References: <3579DE61-A788-4FD0-854C-3EEFEFBE9931@icann.org> <20070626141928.GT69215@Space.Net> Message-ID: <5F924649-DBC0-42D1-9806-3240818C8DDA@icann.org> On 26 Jun 2007, at 10:19am, Gert Doering wrote: > On Mon, Jun 25, 2007 at 06:02:19PM -0400, Leo Vegoda wrote: >> I'm not opposed to making IPv6 address space available to all the >> networks that need it. I just think basing the policy for doing so on >> a concept that is so slippery we can't really define it is fatally >> flawed. If the net effect of your proposal would be that more than >> 95% of members would qualify for a /32 allocation it is probably >> simpler to just make the qualifying criterion being a RIPE NCC >> member. > > Well. Let's do a straw poll... > > "who is in favour of doing so?" However the IPv6 allocation policy is revised, it needs to work well with a PI assignment policy. If the only criterion for receiving a / 32 IPv6 allocation is that you become a RIPE NCC member then you create a situation where networks wanting PI space must demonstrate a need for anything more than a /48 but anyone willing to pay ?3300 can get thousands of times as much space without needing to show any need. One of the goals for IPv6 address space management is: 3.6. Fairness All policies and practices relating to the use of public address space should apply fairly and equitably to all existing and potential members of the Internet community, regardless of their location, nationality, size, or any other factor. I am not sure that this goal can be met if the only barrier to a block 65,636 times as large as a /48 PI assignment is an annual payment to the RIPE NCC. As such, I'd like to see work to update the policy in a way that would allow a quantifiable basis for evaluating requests for both PI and PA. I'm not sure that the current set of proposals allow that. Regards, -- Leo Vegoda IANA Numbers Liaison From jeroen at unfix.org Wed Jun 27 00:49:54 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 26 Jun 2007 23:49:54 +0100 Subject: [address-policy-wg] 2006-02 Last Call for Comments (IPv6 Address Allocation and Assignment Policy) In-Reply-To: <5F924649-DBC0-42D1-9806-3240818C8DDA@icann.org> References: <3579DE61-A788-4FD0-854C-3EEFEFBE9931@icann.org> <20070626141928.GT69215@Space.Net> <5F924649-DBC0-42D1-9806-3240818C8DDA@icann.org> Message-ID: <46819812.3050007@spaghetti.zurich.ibm.com> Leo Vegoda wrote: [..] > However the IPv6 allocation policy is revised, it needs to work well > with a PI assignment policy. If the only criterion for receiving a /32 > IPv6 allocation is that you become a RIPE NCC member then you create a > situation where networks wanting PI space must demonstrate a need for > anything more than a /48 but anyone willing to pay ?3300 can get > thousands of times as much space without needing to show any need. > > One of the goals for IPv6 address space management is: > > 3.6. Fairness Which is why a policy should *always* have a "Justify the address space" clause in there when the requester wants >/48*. That is the real thing that a RIR has to do: verify (as far as possible blabla) that the request really is valid and that the address space will be used. Greets, Jeroen * = with >/48 I mean a /47, /46... /40 etc, the more/less smaller/larger stuff is confusing every time :) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From Niall.oReilly at ucd.ie Wed Jun 27 01:25:30 2007 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Wed, 27 Jun 2007 00:25:30 +0100 Subject: [address-policy-wg] 2006-02 Last Call for Comments (IPv6 Address Allocation and Assignment Policy) In-Reply-To: <46815454.6050908@spaghetti.zurich.ibm.com> References: <3579DE61-A788-4FD0-854C-3EEFEFBE9931@icann.org> <20070626141928.GT69215@Space.Net> <46815454.6050908@spaghetti.zurich.ibm.com> Message-ID: <0C8AA6A9-977D-4F61-B24D-C2F4088394C4@ucd.ie> On 26 Jun 2007, at 19:00, Jeroen Massar wrote: > Also that avoids any need for ULA-C as everybody is covered. Non sequitur. Your conclusion may be true; unless you choose to expose your logic, it is unproven, and may even be just wishful thinking. I'ld really like to see a conclusion (for or against, I don't care) about ULA-C which didn't involve religious convictions. That probably belongs in another thread. Best regards, Niall O'Reilly University College Dublin IT Services PGP key ID: AE995ED9 (see www.pgp.net) Fingerprint: 23DC C6DE 8874 2432 2BE0 3905 7987 E48D AE99 5ED9 -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From jeroen at unfix.org Wed Jun 27 01:41:17 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 27 Jun 2007 00:41:17 +0100 Subject: [address-policy-wg] 2006-02 Last Call for Comments (IPv6 Address Allocation and Assignment Policy) In-Reply-To: <0C8AA6A9-977D-4F61-B24D-C2F4088394C4@ucd.ie> References: <3579DE61-A788-4FD0-854C-3EEFEFBE9931@icann.org> <20070626141928.GT69215@Space.Net> <46815454.6050908@spaghetti.zurich.ibm.com> <0C8AA6A9-977D-4F61-B24D-C2F4088394C4@ucd.ie> Message-ID: <4681A41D.4070905@spaghetti.zurich.ibm.com> Niall O'Reilly wrote: > > On 26 Jun 2007, at 19:00, Jeroen Massar wrote: > >> Also that avoids any need for ULA-C as everybody is covered. > > Non sequitur. > > Your conclusion may be true; unless you choose to expose your > logic, it is unproven, and may even be just wishful thinking. > > I'ld really like to see a conclusion (for or against, I don't > care) about ULA-C which didn't involve religious convictions. > That probably belongs in another thread. Although the latin/greek/whatever might look impressive in writing, can you actually describe what you are wanting to say? A comment with actual content really helps. See the various other discussions about ULA-C and the amount of questions that have been raised and remain unanswered and start tapping into that and answering them, then we can proceed with that part. Upto now those questions remain open and as such there actually is not even a real case at all why such space should exist, except for some people wanting to have "really cheap PI" space for vaguely defined examples. And that case can be solved by what Gert proposed, thus then there really is no need any more for ULA-C. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From gert at space.net Wed Jun 27 08:21:50 2007 From: gert at space.net (Gert Doering) Date: Wed, 27 Jun 2007 08:21:50 +0200 Subject: [address-policy-wg] 2006-02 Last Call for Comments (IPv6 Address Allocation and Assignment Policy) In-Reply-To: <5F924649-DBC0-42D1-9806-3240818C8DDA@icann.org> References: <3579DE61-A788-4FD0-854C-3EEFEFBE9931@icann.org> <20070626141928.GT69215@Space.Net> <5F924649-DBC0-42D1-9806-3240818C8DDA@icann.org> Message-ID: <20070627062150.GD69215@Space.Net> Hi, On Tue, Jun 26, 2007 at 06:35:20PM -0400, Leo Vegoda wrote: > However the IPv6 allocation policy is revised, it needs to work well > with a PI assignment policy. If the only criterion for receiving a / > 32 IPv6 allocation is that you become a RIPE NCC member then you > create a situation where networks wanting PI space must demonstrate a > need for anything more than a /48 but anyone willing to pay ?3300 can > get thousands of times as much space without needing to show any need. Indeed. But given the past 7 years of history, we can't seem to come to a rule set that is more complex than "be LIR, ask for it" that people will agree upon. In IPv4 land, we had entry barriers for LIR allocations for a while, and that didn't work, so we're back to "be LIR, ask for it, get PA space" - and that model seems to work quite well. > One of the goals for IPv6 address space management is: > > 3.6. Fairness > > All policies and practices relating to the use of public address > space > should apply fairly and equitably to all existing and potential > members > of the Internet community, regardless of their location, > nationality, > size, or any other factor. > > I am not sure that this goal can be met if the only barrier to a > block 65,636 times as large as a /48 PI assignment is an annual > payment to the RIPE NCC. One of the differences is a different tag on the address block ("this is for me only" vs. "this is for me and my customers") - PI vs. PA. OTOH, I can't really understand this excitement about the size of the address block. A /48 is large enough for all but the biggest "end user" networks - and a /32 is still fairly small regarding the total amount of /32s in FP 001. If the numbers are so huge, people should really stop worrying about "this guy got a bigger one than I did!!!". Thus I'm not worrying very much about bit haggling (this is IPv6, not IPv4), but about - general availability of IPv6 (-> make PA space *easy* to get) - pressure on the routing system (-> *one* prefix per LIR, if at all possible, and some incentive to not use PI for "normal end sites") 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 305 bytes Desc: not available URL: From rogerj at jorgensen.no Wed Jun 27 08:27:51 2007 From: rogerj at jorgensen.no (Roger Jorgensen) Date: Wed, 27 Jun 2007 08:27:51 +0200 (CEST) Subject: [address-policy-wg] 2006-02 Last Call for Comments (IPv6 Address Allocation and Assignment Policy) In-Reply-To: <0C8AA6A9-977D-4F61-B24D-C2F4088394C4@ucd.ie> References: <3579DE61-A788-4FD0-854C-3EEFEFBE9931@icann.org> <20070626141928.GT69215@Space.Net> <46815454.6050908@spaghetti.zurich.ibm.com> <0C8AA6A9-977D-4F61-B24D-C2F4088394C4@ucd.ie> Message-ID: On Wed, 27 Jun 2007, Niall O'Reilly wrote: > > I'ld really like to see a conclusion (for or against, I don't > care) about ULA-C which didn't involve religious convictions. > That probably belongs in another thread. I am in favour of ULA-C and I belive we have a very good use-case for it where I work, but, there is a huge but there. Without global DNS, that is possibility to have reverse DNS for our ULA-C addresses it is completly useless for our cause. And with DNS you get into other complication and in the end you get something called ULA-C which ain't too different from PI space at all. So my conclusion on this is quite simple, it would be nice to have ULA-C but I dont belive there is any point it wasting time on it anymore. Get a decent PI policy in place that let those that need IP addresses get it and we're done. -- ------------------------------ Roger Jorgensen | - ROJO9-RIPE - RJ85P-NORID roger at jorgensen.no | - IPv6 is The Key! ------------------------------------------------------- From Niall.oReilly at ucd.ie Wed Jun 27 10:33:12 2007 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Wed, 27 Jun 2007 09:33:12 +0100 Subject: [address-policy-wg] 2006-02 Last Call for Comments (IPv6 Address Allocation and Assignment Policy) In-Reply-To: <4681A41D.4070905@spaghetti.zurich.ibm.com> References: <3579DE61-A788-4FD0-854C-3EEFEFBE9931@icann.org> <20070626141928.GT69215@Space.Net> <46815454.6050908@spaghetti.zurich.ibm.com> <0C8AA6A9-977D-4F61-B24D-C2F4088394C4@ucd.ie> <4681A41D.4070905@spaghetti.zurich.ibm.com> Message-ID: <3841A53C-41EE-46E1-ACF6-CE650524E3D1@ucd.ie> On 27 Jun 2007, at 00:41, Jeroen Massar wrote: > See the various other discussions about ULA-C I have, and I'm disappointed by what seems to me, on both (all?) sides to be a combination of hidden agendas, prejudice, grandstanding, and refusal to acknowledge that the opposing argument may even be made in good faith. > and the amount of > questions that have been raised and remain unanswered and start > tapping > into that and answering them, then we can proceed with that part. Upto > now those questions remain open and as such there actually is not > even a > real case at all why such space should exist, except for some people > wanting to have "really cheap PI" space for vaguely defined examples. > > And that case can be solved by what Gert proposed, thus then there > really is no need any more for ULA-C. Simply repeating your opinion isn't going to convince me that it has a real basis. Best regards, Niall O'Reilly University College Dublin IT Services PGP key ID: AE995ED9 (see www.pgp.net) Fingerprint: 23DC C6DE 8874 2432 2BE0 3905 7987 E48D AE99 5ED9 -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From Niall.oReilly at ucd.ie Wed Jun 27 10:53:40 2007 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Wed, 27 Jun 2007 09:53:40 +0100 Subject: [address-policy-wg] 2006-02 Last Call for Comments (IPv6 Address Allocation and Assignment Policy) In-Reply-To: <4681A41D.4070905@spaghetti.zurich.ibm.com> References: <3579DE61-A788-4FD0-854C-3EEFEFBE9931@icann.org> <20070626141928.GT69215@Space.Net> <46815454.6050908@spaghetti.zurich.ibm.com> <0C8AA6A9-977D-4F61-B24D-C2F4088394C4@ucd.ie> <4681A41D.4070905@spaghetti.zurich.ibm.com> Message-ID: On 27 Jun 2007, at 00:41, Jeroen Massar wrote: > See the various other discussions about ULA-C and the amount of > questions that have been raised and remain unanswered and start > tapping > into that and answering them, then we can proceed with that part. No thanks. I don't always recognize a rat-hole, but this one is too easy. 8-) Besides, this is probably not the right thread, or even list. A propos, if I do find time and energy, which would be the most appropriate list? Best regards, Niall O'Reilly University College Dublin IT Services PGP key ID: AE995ED9 (see www.pgp.net) Fingerprint: 23DC C6DE 8874 2432 2BE0 3905 7987 E48D AE99 5ED9 -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From gert at space.net Wed Jun 27 11:29:04 2007 From: gert at space.net (Gert Doering) Date: Wed, 27 Jun 2007 11:29:04 +0200 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> <20070626141928.GT69215@Space.Net> <46815454.6050908@spaghetti.zurich.ibm.com> <0C8AA6A9-977D-4F61-B24D-C2F4088394C4@ucd.ie> <4681A41D.4070905@spaghetti.zurich.ibm.com> Message-ID: <20070627092904.GF69215@Space.Net> Hi, On Wed, Jun 27, 2007 at 09:53:40AM +0100, Niall O'Reilly wrote: > Besides, this is probably not the right thread, or even list. > A propos, if I do find time and energy, which would be the most > appropriate list? The ULA-C discussion is currently happening on the IETF lists, and as far as I understand, the "ipv6"-WG list is the right place. If the IETF says "ULA-C are a good thing" it will come back to the RIPE APWG list (and the other regions' policy fora). 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 ripe-ml-2003 at ssd.axu.tm Wed Jun 27 15:41:54 2007 From: ripe-ml-2003 at ssd.axu.tm (Aleksi Suhonen) Date: Wed, 27 Jun 2007 16:41:54 +0300 Subject: [address-policy-wg] 2006-02 Last Call for Comments (IPv6 Address Allocation and Assignment Policy) Message-ID: <20070627134154.61B831A2DD@tikka.axu.tm> Hello, > And which prefix size does the organization get then? There are enough > end-site organizations that can easily justify a /42 worth of address > space, 64 /48's isn't that much if you give every separate building > where you have an office a /48 and those offices can definitely be > considered sites. Easy is great, but there should be a possibility for > sites to request a bit more. Hmm ... /48 shouldn't be the lower bound for organization internal site subnetting. It should be /64. If every separate building needs several subnets and room to expand, then they should be given 256 /64s (aka /56). Or if it can be shown that some building really needs more, then perhaps a bigger block can be justified. It would still be hard to convince me that an organization would need sixtyfivethousand subnets in every building. Now, if the organization has more than 256 buildings, THEN it might be reasonable to give the organization a bigger block than /48. (Of course, there might be organizations that have very special needs that have nothing to do with office buildings, and I'm not commenting on those at all here.) I may be wrong, -- Aleksi Suhonen / Axu TM Oy Internetworking Consulting Cellular: +358 45 670 2048 World Wide Web: www.axu.tm From jeroen at unfix.org Wed Jun 27 16:17:41 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 27 Jun 2007 15:17:41 +0100 Subject: [address-policy-wg] Re: [GLOBAL-V6] [afripv6-discuss] Re: [ppml] How to get a IPv6 /32 the cheap way: go to AFRINIC In-Reply-To: <025101c7b4fe$3df99c50$ec1afea9@ipv6forum> References: <467BDA31.4030607@spaghetti.zurich.ibm.com><467BEE69.60906@inex.ie> <467BF422.7030901@spaghetti.zurich.ibm.com> <025101c7b4fe$3df99c50$ec1afea9@ipv6forum> Message-ID: <46827185.2010801@spaghetti.zurich.ibm.com> Latif LADID ("The New Internet based on IPv6") wrote: > Joeren, > > To be fair, start your rant also about those that got /13 and those that got > /19 :-) I've not seen a /13 in the routing tables nor in the allocation tables yet. Where did this occur? A /13 would be 34.359.738.368 /48's, I don't know of any ISP currently actively providing residential access in all countries on this planet and then about 5 of those planets. The /19's you mention are for France Telecom and Deutsche Telekom, both clearly where able to justify to the RIR that they needed 536.870.912 /48's, based on HD ratio and home countries respectively having 64 and 83 million inhabitants with most likely added plan of providing the rest of Europe with connectivity too, is not too far fetched. With only the home countries in mind a /21 would have sufficed, but that doesn't cover the HD ratio. Now if there was a /56 policy for home-end-users then it would surely have been way too much, but with the current HD policy it isn't. There are several other such "large" prefixes, but they all are allocated to ISP's who have been around for a long time and are providing connectivity to a large amount of users in a similar way as the above two ISP's. But a single /32 for a ~5 person organization quickly grabbing it before their own PI policy becomes in effect is a bit strange don't you think. And no "we have 3 offices and a few big projects" is far from correct justification. As such, sneaking in a /32 from under their own policies is a waste of address space. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From jeroen at unfix.org Wed Jun 27 16:25:46 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 27 Jun 2007 15:25:46 +0100 Subject: [address-policy-wg] Critical or not and at what size (Was: How to get a IPv6 /32 the cheap way: go to AFRINIC) In-Reply-To: <467BF308.3070708@bugest.net> References: <467BCF8B.4090308@spaghetti.zurich.ibm.com> <467BF308.3070708@bugest.net> Message-ID: <4682736A.7050708@spaghetti.zurich.ibm.com> Kosuke Ito wrote: > Please read carefully about the section of Critical Infrastructure. > > AfriNIC is eligible to have a /32 by the policy. How exactly is a RIR more "Critical" to the Internet than Google, YouTube, MySpace or whatever site somebody uses daily? I understand if one would state "A RIR is critical as it provides service X", but then the RIR itself is not the critical infra, it is that service. RIPE itself doesn't have a /32 nor a /48, they are using a /48 that they have from an ISP out of PA space. K.ROOT *does* fall under critical infra though, and that has, according to that policy a prefix. If one states "but they have a DNS server", then how does that make my DNS server not critical? Especially a DNS server by for instance Akamai powering hunderds of well used domains? [..APNIC policy..] > The maximum assignment made under these terms is /32 per operator. And this is the important portion of that part: "The maximum". That doesn't mean that if you can't justify it that you per default should be getting a /32. The default should be a /48, and more if one can justify it. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From jordi.palet at consulintel.es Wed Jun 27 16:32:52 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed, 27 Jun 2007 10:32:52 -0400 Subject: [address-policy-wg] 2006-02 Last Call for Comments (IPv6 Address Allocation and Assignment Policy) In-Reply-To: <20070627134154.61B831A2DD@tikka.axu.tm> Message-ID: Are you assuming that organizations never subnet inside a building ? In IPv6 if you want to keep things working, the minimum network is /64, so if somebody want to subnet, you need to give them something bigger, and current IETF recommendations are still /48, as per RFC3177. Regards, Jordi > De: Aleksi Suhonen > Organizaci?n: Axu TM Oy > Responder a: > Fecha: Wed, 27 Jun 2007 16:41:54 +0300 > Para: > Asunto: Re: [address-policy-wg] 2006-02 Last Call for Comments (IPv6 Address > Allocation and Assignment Policy) > > Hello, > >> And which prefix size does the organization get then? There are enough >> end-site organizations that can easily justify a /42 worth of address >> space, 64 /48's isn't that much if you give every separate building >> where you have an office a /48 and those offices can definitely be >> considered sites. Easy is great, but there should be a possibility for >> sites to request a bit more. > > Hmm ... /48 shouldn't be the lower bound for organization internal > site subnetting. It should be /64. > > If every separate building needs several subnets and room to expand, > then they should be given 256 /64s (aka /56). Or if it can be shown > that some building really needs more, then perhaps a bigger block > can be justified. It would still be hard to convince me that an > organization would need sixtyfivethousand subnets in every building. > > Now, if the organization has more than 256 buildings, THEN it might > be reasonable to give the organization a bigger block than /48. > (Of course, there might be organizations that have very special > needs that have nothing to do with office buildings, and I'm not > commenting on those at all here.) > > I may be wrong, > > -- > Aleksi Suhonen / Axu TM Oy > Internetworking Consulting > Cellular: +358 45 670 2048 > World Wide Web: www.axu.tm > ********************************************** 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 gert at space.net Wed Jun 27 16:45:41 2007 From: gert at space.net (Gert Doering) Date: Wed, 27 Jun 2007 16:45:41 +0200 Subject: [address-policy-wg] 2006-02 Last Call for Comments (IPv6 Address Allocation and Assignment Policy) In-Reply-To: References: <20070627134154.61B831A2DD@tikka.axu.tm> Message-ID: <20070627144541.GJ69215@Space.Net> Hi, On Wed, Jun 27, 2007 at 10:32:52AM -0400, JORDI PALET MARTINEZ wrote: > Are you assuming that organizations never subnet inside a building ? > > In IPv6 if you want to keep things working, the minimum network is /64, so > if somebody want to subnet, you need to give them something bigger, and > current IETF recommendations are still /48, as per RFC3177. There's nothing in the IETF recommendations that says "per building". So giving a customer a /48, and having that customer assign /56s out of that space to individual buildings, and taking /64s from there to individual LAN networks, is a perfectly workable approach. Gert Doering -- APWG chairs -- 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 jordi.palet at consulintel.es Wed Jun 27 16:50:20 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed, 27 Jun 2007 10:50:20 -0400 Subject: [address-policy-wg] 2006-02 Last Call for Comments (IPv6 Address Allocation and Assignment Policy) In-Reply-To: <20070627144541.GJ69215@Space.Net> Message-ID: No, I didn't meant /48 per building, it was only the reply to the "building" thing comment, but /48 per customer, as you say. Regards, Jordi > De: Gert Doering > Responder a: > Fecha: Wed, 27 Jun 2007 16:45:41 +0200 > Para: JORDI PALET MARTINEZ > CC: > Asunto: Re: [address-policy-wg] 2006-02 Last Call for Comments (IPv6 Address > Allocation and Assignment Policy) > > Hi, > > On Wed, Jun 27, 2007 at 10:32:52AM -0400, JORDI PALET MARTINEZ wrote: >> Are you assuming that organizations never subnet inside a building ? >> >> In IPv6 if you want to keep things working, the minimum network is /64, so >> if somebody want to subnet, you need to give them something bigger, and >> current IETF recommendations are still /48, as per RFC3177. > > There's nothing in the IETF recommendations that says "per building". > > So giving a customer a /48, and having that customer assign /56s out of > that space to individual buildings, and taking /64s from there to > individual LAN networks, is a perfectly workable approach. > > Gert Doering > -- APWG chairs > -- > 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 ********************************************** 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 jeroen at unfix.org Wed Jun 27 16:51:15 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 27 Jun 2007 15:51:15 +0100 Subject: [address-policy-wg] Re: [GLOBAL-V6] How to get a IPv6 /32 the cheap way: go to AFRINIC In-Reply-To: <200706221451.l5MEpIQP012336@ns1.afrinic.net> References: <467BCF8B.4090308@spaghetti.zurich.ibm.com> <200706221451.l5MEpIQP012336@ns1.afrinic.net> Message-ID: <46827963.4070801@spaghetti.zurich.ibm.com> Adiel A. Akplogan wrote: [..] >> Wow, so you make a new 'company' in 911 land and say "I am going to >> allocate a >> single /48" and you get a FULL /32 even when you will never ever ever >> use it >> or even are going to think about using it? > > I think you have missed the point a) which says "be an LIR". So you must > already be an LIR (and go through the LIR setup process) to get IPv6 > allocation from AfrINIC. Is it that difficult to become an LIR then? Last time I checked it simply means having a registered company in a country and paying the bills. For the rest, nothing policy wise will stop one from becoming one. >> The first "organization" which is using this to waste space seems to be: >> >> inet6num: 2001:42d0::/32 >> netname: AfriNIC-IPv6-1 >> descr: AfriNIC >> descr: RIR >> country: MU >> >> Gee, the RIR itself. How many people are using the AFRINIC network? >> 10-50? Are >> they really *ever* going to need more than a /48? Are they ever going >> to have >> a need for 65536 of those /48's? > > You can not take AfriNIC own allocation case to illustrate your > assertion here Why not? It is clearly the first block that has been using this policy. Some other people mentioned that you might have been using the "Critical Infrastructure" policy, but clearly you are not, otherwise you would have mentioned that, but you did not. Also even that policy mentions that a /32 is the maximum size and not the default, meaning that one still has to justify that address space. > We have allocated that bloc to our own Infrastructure (which has three > locations to be connected together) so each with its own /48. > Further to that we have other IPv6 Internal projects which will > probably require several /48. So you allocate 65536 /48's because you have *three* offices and maybe some "big projects". I don't see why those big projects require the need for individual /48's. Reminder: a /48 is 65536 /64's and in total that contains several millions of /128's to be used for addressing. Under that premise, is every website hosted by a virtual hoster also getting their own /48? That will be a huge waste of address space when you justify it like that. I sincerely hope that that is not the justification that AfriNIC is using, as when that is the case it is really disproportionate to the rest of the world. > As RIR I think we are in the position to evaluate our own need > before making an allocation and if it was made be sure that is > after careful evaluation. I wonder how 'careful' this evaluation was and I am seriously doubting any further 'evaluation'. Seeing that three (small) offices and some unspecified projects A /45 (8 /48's) would have been correctly justified by the above, but a /32 (65536 /48's) is really not. That you want a globally routable prefix and your own chunk of space is fine, but don't waste (not waist) the address space. >> Really this is just a waste of address space. Yes there is "enough", >> but being> sooo obviously wasteful just to be able to have a nice >> slot in the routing tables is a bit over done. > > I don't see the waist. You don't see a waste of 65500 /48's which can otherwise really be used by the new PI policy which your membership has voted on and setup? wow. Why does that PI policy exist when one is going to give out /32's for small sites anyway? And yes AfriNIC is a small site. Now if you had more than 200 offices and thousands of employees or what about real customers who are people and users themselves, then a /32 might be justified, but in this case, far from. [..] >> RIR's should be giving out address space based on "need" and that need >> must justified, giving out /32's as "those fit in the routing slots" is >> a really really bad idea. > > That is what we do. You can not have such affirmation based on a single > case. Thus you admit that the justification was wrong, but just because you made a mistake once (which you can still easily turn back btw as the prefix is not in use yet, or just chunk it down to a /45) it can't really be called a mistake? >> In short: if you want a nice /32 without issues: setup a small shop in >> Africa and presto! > > You won't get it like that. Clearly you can, otherwise that /32 you have now would not be there would it not? Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From jordi.palet at consulintel.es Wed Jun 27 23:16:45 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed, 27 Jun 2007 17:16:45 -0400 Subject: [address-policy-wg] The Choice: IPv4 Exhaustion or Transition to IPv6 Message-ID: Hi all, I've published a document trying to analyze the IPv4 exhaustion problem and what is ahead of us, considering among others, changes in policies. http://www.ipv6tf.org/index.php?page=news/newsroom&id=3004 I guess this could be useful in order to understand possible implications of modifying existing policies, or setting up new ones, or even just to create some debate about those changes. The document was completed last April, but didn't had the time to tidy up until a few days ago. Regards, Jordi ********************************************** 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 kosuke at bugest.net Wed Jun 27 23:31:46 2007 From: kosuke at bugest.net (Kosuke Ito) Date: Thu, 28 Jun 2007 06:31:46 +0900 Subject: [address-policy-wg] Re: [GLOBAL-V6] Critical or not and at what size (Was: How to get a IPv6 /32 the cheap way: go to AFRINIC) In-Reply-To: <4682736A.7050708@spaghetti.zurich.ibm.com> References: <467BCF8B.4090308@spaghetti.zurich.ibm.com> <467BF308.3070708@bugest.net> <4682736A.7050708@spaghetti.zurich.ibm.com> Message-ID: <4682D742.5020505@bugest.net> Hi Jeroen, If you have an objection to the current policy, please raise up the counter-proposal to amend the current policy in your region or the other. I am not agueing here if RIR is critical or not. I am just pointing out what the current policy says. I know what you like to say. best regards, Kosuke Jeroen Massar wrote: > Kosuke Ito wrote: > >>Please read carefully about the section of Critical Infrastructure. >> >>AfriNIC is eligible to have a /32 by the policy. > > > How exactly is a RIR more "Critical" to the Internet than Google, > YouTube, MySpace or whatever site somebody uses daily? > > I understand if one would state "A RIR is critical as it provides > service X", but then the RIR itself is not the critical infra, it is > that service. RIPE itself doesn't have a /32 nor a /48, they are using a > /48 that they have from an ISP out of PA space. K.ROOT *does* fall under > critical infra though, and that has, according to that policy a prefix. > > If one states "but they have a DNS server", then how does that make my > DNS server not critical? Especially a DNS server by for instance Akamai > powering hunderds of well used domains? > > [..APNIC policy..] > >>The maximum assignment made under these terms is /32 per operator. > > > And this is the important portion of that part: "The maximum". > That doesn't mean that if you can't justify it that you per default > should be getting a /32. The default should be a /48, and more if one > can justify it. > > Greets, > Jeroen > > > > ------------------------------------------------------------------------ > > _______________________________________________ > global-v6 mailing list > global-v6 at lists.apnic.net > http://mailman.apnic.net/mailman/listinfo/global-v6 -- ***************IPv6 Internet Wonderland!****************** Kosuke Ito Master Planning and Steering Gr., IPv6 Prom. Council of JP New Business Office/President Office, IRI Ubiteq, Inc. (Visiting Researcher, SFC Lab. KEIO University) Tel:+81-3-3344-7511 Fax:+81-3-3344-7522 Cell:+81-90-9826-4220 mailto: kosuke[at]v6pc.jp http://www.v6pc.jp/ mailto: k-ito[at]ubiteq.co.jp Lifetime e-mail: kosuke[at]stanfordalumni.org From kader.bongo at esmt.sn Thu Jun 28 12:03:07 2007 From: kader.bongo at esmt.sn (BONGO Abdoulkadri) Date: Thu, 28 Jun 2007 10:03:07 +0000 Subject: [address-policy-wg] Re: [afripv6-discuss] Re: [GLOBAL-V6] How to get a IPv6 /32 the cheap way: go to AFRINIC In-Reply-To: <46827963.4070801@spaghetti.zurich.ibm.com> References: <467BCF8B.4090308@spaghetti.zurich.ibm.com> <200706221451.l5MEpIQP012336@ns1.afrinic.net> <46827963.4070801@spaghetti.zurich.ibm.com> Message-ID: <4683875B.9020806@esmt.sn> Hi, Is there a problem if Afrinic come back on this /32 allocation ? If yes, tell Jeroen (and all the community), they will understand ; if realy not and if there is no other reason (like numerical justify values ) let's go in this way. It's just a point of vue. Regards Jeroen Massar wrote: >Adiel A. Akplogan wrote: >[..] > > >>>Wow, so you make a new 'company' in 911 land and say "I am going to >>>allocate a >>>single /48" and you get a FULL /32 even when you will never ever ever >>>use it >>>or even are going to think about using it? >>> >>> >>I think you have missed the point a) which says "be an LIR". So you must >>already be an LIR (and go through the LIR setup process) to get IPv6 >>allocation from AfrINIC. >> >> > >Is it that difficult to become an LIR then? Last time I checked it >simply means having a registered company in a country and paying the >bills. For the rest, nothing policy wise will stop one from becoming one. > > > >>>The first "organization" which is using this to waste space seems to be: >>> >>>inet6num: 2001:42d0::/32 >>>netname: AfriNIC-IPv6-1 >>>descr: AfriNIC >>>descr: RIR >>>country: MU >>> >>>Gee, the RIR itself. How many people are using the AFRINIC network? >>>10-50? Are >>>they really *ever* going to need more than a /48? Are they ever going >>>to have >>>a need for 65536 of those /48's? >>> >>> >>You can not take AfriNIC own allocation case to illustrate your >>assertion here >> >> > >Why not? It is clearly the first block that has been using this policy. > >Some other people mentioned that you might have been using the "Critical >Infrastructure" policy, but clearly you are not, otherwise you would >have mentioned that, but you did not. > >Also even that policy mentions that a /32 is the maximum size and not >the default, meaning that one still has to justify that address space. > > > >>We have allocated that bloc to our own Infrastructure (which has three >>locations to be connected together) so each with its own /48. >>Further to that we have other IPv6 Internal projects which will >>probably require several /48. >> >> > >So you allocate 65536 /48's because you have *three* offices and maybe >some "big projects". I don't see why those big projects require the need >for individual /48's. Reminder: a /48 is 65536 /64's and in total that >contains several millions of /128's to be used for addressing. > >Under that premise, is every website hosted by a virtual hoster also >getting their own /48? That will be a huge waste of address space when >you justify it like that. I sincerely hope that that is not the >justification that AfriNIC is using, as when that is the case it is >really disproportionate to the rest of the world. > > > >>As RIR I think we are in the position to evaluate our own need >>before making an allocation and if it was made be sure that is >>after careful evaluation. >> >> > >I wonder how 'careful' this evaluation was and I am seriously doubting >any further 'evaluation'. Seeing that three (small) offices and some >unspecified projects > >A /45 (8 /48's) would have been correctly justified by the above, but a >/32 (65536 /48's) is really not. > >That you want a globally routable prefix and your own chunk of space is >fine, but don't waste (not waist) the address space. > > > >>>Really this is just a waste of address space. Yes there is "enough", >>>but being> sooo obviously wasteful just to be able to have a nice >>>slot in the routing tables is a bit over done. >>> >>> >>I don't see the waist. >> >> > >You don't see a waste of 65500 /48's which can otherwise really be used >by the new PI policy which your membership has voted on and setup? wow. > >Why does that PI policy exist when one is going to give out /32's for >small sites anyway? And yes AfriNIC is a small site. Now if you had more >than 200 offices and thousands of employees or what about real customers >who are people and users themselves, then a /32 might be justified, but >in this case, far from. > >[..] > > >>>RIR's should be giving out address space based on "need" and that need >>>must justified, giving out /32's as "those fit in the routing slots" is >>>a really really bad idea. >>> >>> >>That is what we do. You can not have such affirmation based on a single >>case. >> >> > >Thus you admit that the justification was wrong, but just because you >made a mistake once (which you can still easily turn back btw as the >prefix is not in use yet, or just chunk it down to a /45) it can't >really be called a mistake? > > > >>>In short: if you want a nice /32 without issues: setup a small shop in >>>Africa and presto! >>> >>> >>You won't get it like that. >> >> > >Clearly you can, otherwise that /32 you have now would not be there >would it not? > >Greets, > Jeroen > > > > >------------------------------------------------------------------------ > >_______________________________________________ >afripv6-discuss mailing list >afripv6-discuss at afrinic.net >https://lists.afrinic.net/mailman/listinfo.cgi/afripv6-discuss > > From bortzmeyer at nic.fr Thu Jun 28 13:31:35 2007 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Thu, 28 Jun 2007 13:31:35 +0200 Subject: [address-policy-wg] Re: [GLOBAL-V6] [ppml] How to get a IPv6 /32 the cheap way: go to AFRINIC In-Reply-To: <2A5F2BA8-091A-4D4D-B54F-0FFB09E3E7D3@icann.org> References: <467BDA31.4030607@spaghetti.zurich.ibm.com> <467BEE69.60906@inex.ie> <467BF422.7030901@spaghetti.zurich.ibm.com> <2A5F2BA8-091A-4D4D-B54F-0FFB09E3E7D3@icann.org> Message-ID: <20070628113135.GA19005@nic.fr> On Fri, Jun 22, 2007 at 12:45:05PM -0400, David Conrad wrote a message of 12 lines which said: > To state the obvious: there are the same number of /32s in IPv4 > space as in IPv6 space. In mathematics, yes, not in actual networks, because of RFC 1715 :-) From david.conrad at icann.org Thu Jun 28 15:36:44 2007 From: david.conrad at icann.org (David Conrad) Date: Thu, 28 Jun 2007 09:36:44 -0400 Subject: [address-policy-wg] Re: [GLOBAL-V6] [ppml] How to get a IPv6 /32 the cheap way: go to AFRINIC In-Reply-To: <20070628113135.GA19005@nic.fr> References: <467BDA31.4030607@spaghetti.zurich.ibm.com> <467BEE69.60906@inex.ie> <467BF422.7030901@spaghetti.zurich.ibm.com> <2A5F2BA8-091A-4D4D-B54F-0FFB09E3E7D3@icann.org> <20070628113135.GA19005@nic.fr> Message-ID: <5EC1A108-F1EE-48C9-8E34-61D9F5700D7A@icann.org> On Jun 28, 2007, at 7:31 AM, Stephane Bortzmeyer wrote: > On Fri, Jun 22, 2007 at 12:45:05PM -0400, > David Conrad wrote > a message of 12 lines which said: >> To state the obvious: there are the same number of /32s in IPv4 >> space as in IPv6 space. > In mathematics, yes, not in actual networks, because of RFC 1715 :-) I'm not sure the context of the smiley here, but just to be clear: the H ratio is irrelevant. There really are the same number of /32s in IPv4 space as there are in IPv6. Further, as we're talking about PI allocations, there is no hierarchy so the H ratio doesn't apply. The fact that an IPv4 /32 can address 1 interface (or, with NAT, more) and IPv6 can address "a few" more doesn't really matter. Rgds, -drc From filiz at ripe.net Thu Jun 28 17:28:28 2007 From: filiz at ripe.net (Filiz Yilmaz) Date: Thu, 28 Jun 2007 17:28:28 +0200 Subject: [address-policy-wg] 2007-01 Awaiting Documentation Message-ID: <4683D39C.9010602@ripe.net> Dear Colleagues, As you may remember, during the Address Policy Working Group session at RIPE 54, the community asked us to prepare a draft contract between End Users and the RIPE NCC in order to facilitate discussion about proposal 2007-01, "Direct Internet Resource Assignments to End Users from the RIPE NCC". The RIPE NCC Executive Board will meet at the beginning of September to discuss this draft End User contract. Only after this meeting can a draft contract be published. Until then, the proposer, Nick Hilliard, and the Address Policy Working Group Chairs decided to keep the current status of proposal 2007-01 as "Discussion Phase - Awaiting for Documentation." Kind regards, Filiz Yilmaz RIPE NCC Policy Development Officer From jordi.palet at consulintel.es Sat Jun 30 02:01:38 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Fri, 29 Jun 2007 20:01:38 -0400 Subject: [address-policy-wg] ICANN Board Resolution on the Deployment of IPv6 In-Reply-To: Message-ID: I think this resolution that has been taken unanimously by the board today here in San Juan deservers this email at least: http://www.ipv6tf.org/index.php?page=news/newsroom&id=3052 Regards, Jordi ********************************************** 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.