From filiz at ripe.net Tue Jun 6 12:04:53 2006 From: filiz at ripe.net (Filiz Yilmaz) Date: Tue, 06 Jun 2006 12:04:53 +0200 Subject: [address-policy-wg] 2005-03 Policy Proposal Withdrawn (IPv6 Initial Allocation) Message-ID: <20060606100453.ECF7F2F595@herring.ripe.net> PDP Number: 2005-03 IPv6 Initial Allocation Dear Colleagues The proposal 2005-03, IPv6 Initial Allocation, has been withdrawn by the proposer who thought this proposal is superceded by poposal 2006-02, IPv6 Address Allocation and Assignment Policy. The proposal is archived now and you can find it at: http://www.ripe.net/ripe/policies/proposals/2005-3.html Regards Filiz Yilmaz RIPE NCC Policy Development Officer From jordi.palet at consulintel.es Wed Jun 7 14:20:02 2006 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed, 07 Jun 2006 14:20:02 +0200 Subject: [address-policy-wg] Re: [policy-announce] 2006-02 New Policy Proposal (IPv6 Address Allocation and Assignment Policy) In-Reply-To: <20060531124305.C2B972F592@herring.ripe.net> Message-ID: Hi, I will like to know if anyone has any comments/inputs on this proposal. I tried to follow the suggestions received after the presentation of the IPv6 PI policy at the last meeting. Thanks ! Regards, Jordi > De: Filiz Yilmaz > Responder a: > Fecha: Wed, 31 May 2006 14:43:05 +0200 > Para: > CC: Jordi Palet Martinez , Hans Petter Holen > , "address-policy-wg at ripe.net" > Asunto: [policy-announce] 2006-02 New Policy Proposal (IPv6 Address Allocation > and Assignment Policy) > > PDP Number: 2006-02 > IPv6 Address Allocation and Assignment Policy > > Dear Colleagues > > A proposed change to RIPE Document ripe-267 is now available for > discussion. > > You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2006-02.html > > We encourage you to review this proposal and send your comments to > before 28 June 2006. > > > Regards > > Filiz Yilmaz > RIPE NCC > Policy Development Officer > ********************************************** 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 david.conrad at icann.org Wed Jun 7 21:54:18 2006 From: david.conrad at icann.org (David Conrad) Date: Wed, 7 Jun 2006 12:54:18 -0700 Subject: [address-policy-wg] Re: [policy-announce] 2006-02 New Policy Proposal (IPv6 Address Allocation and Assignment Policy) In-Reply-To: References: Message-ID: Jordi, Unlurking from the sidelines and speaking only for myself, some comments on your proposal: > It is clear that there are small Internet Service providers (ISPs) > that do not currently have 200 customers, consequently is not > feasible for them to make ?at least 200 /48? assignments in two > years. It is, however, unfair that these ISPs have no access to > IPv6 address space. I'm confused. According to RIPE-267 (section 5.1.1), the existing policy doesn't require requesters to have 200 customers. All that it requires is that an LIR not be an end site, provide IPv6 connectivity, and "have a plan for making at least 200 /48 assignments to other organisations within two years." Note it says "a plan". An organization incapable of coming up with _a plan_ to allocate 200 /48s has more significant problems than not having IPv6 space. > In some cases, organisations may have a small number of sites, but > still need their own block so that they can avoid future > renumbering, if they change their upstream provider or identify a > need to become Multihomed. Can you identify an organization that does not want to avoid renumbering or which might not identify a need to be multihomed? > b) plan to provide IPv6 connectivity to other organisations or to > its own/related departments/entities/sites to which it will assign / > 48s by advertising that connectivity through a single aggregated > address allocation > > and > c) have a plan for making a reasonable number of /48 assignments > within two years I have a couple of LANs at my house. A /48 for each LAN sounds reasonable to me. Does that justify an IPv6 /32? More seriously, impositions of subjective evaluations like figuring out what is "reasonable" are generally things to be avoided. Also, vagueness of terms such as "own/related departments/entities/sites" are just begging for abuse. A person is an entity. Should an organization with a "reasonable" number of people justify a /32? > a. Arguments Supporting the Proposal ... > The difficulty encountered in receiving IPv6 address space by some > big entities that have a need to use IPv6 is a clear barrier for > its deployment. The lack of transparent renumbering, scalable multi-homing, or IPv6- only applications is a much more significant barrier to deployment. You are attempting to fix a technology problem by hacking policy in a way that would exacerbate the technology problem. This seems suboptimal to me. But that's probably just me. > By setting up this policy, we would avoid creating an unfair > situation among different RIR service regions. Other RIRs have > already modified the original IPv6 common policy to avoid these > barriers. http://www.bumperart.com/ProductDetails.aspx? SKU=2004011203&productID=523 > We could possibly say that an arbitrary number of sites in order to > qualify for an allocation could be considered illegal in some > countries. The RIPE community cannot set policies that could prove > unlawful as this could have important implications. If you have documentary proof of potential illegality, it would probably be worthwhile to provide it. If not, this sentence is merely FUD and should be stricken. Even if you do have evidence that some country's law is being broken, it isn't clear to me how that should affect RIPE policy. For example, I believe a country in the RIPE region has passed a law (or is in the process of passing a law) that requires IP address space to be allocated by that country's government. Should RIPE therefore only allocate address space to governments? > b. Arguments Opposing the Proposal > > One possible effect of this proposal would be a growth of global > routing tables. This is only to be expected when new allocations > are made possible under this proposal. Too simplistic. This proposal, like all PI oriented allocation policies, changes routing scalability from O(number of service providers) to O(number of organizations). Pretending this is "only to be expected" is simply wrong. You can argue that technology will permit O(number of organizations) in the default free routing system, but that is a different argument than "it is to be expected". > Opposing arguments should avoid being unfair to smaller ISPs that > could not justify a fixed number of assignments. Is it unfair that carriers that fly Boeing 747s get more revenues than carriers that fly Saab 340s? A fixed number of assignments was an attempt to quantify a "reasonable" level of aggregation. Given the routing technology used in IPv6 depends on aggregatability to scale, there is an implicit assumption that those who cannot provide aggregation of leaves should themselves become a leaf under some other aggregator. > Such a policy could be seen as irrational "In an insane world the sane man must appear insane" -- Spock > and might be comparable with imposing a similar requirement for > IPv4 address space allocations, which the community would be > unlikely to accept. In at least one region, initial allocations of PI IPv4 required demonstration of utilization of half the initial PI allocation, so in essence, there was an implicit requirement to meet a fixed number to justify an allocation. Of course, this wasn't in the RIPE region, but weren't you the one arguing that the other regions have a similar policy to what you propose as justification for your proposal? Rgds, -drc From tim.streater at dante.org.uk Thu Jun 8 11:20:52 2006 From: tim.streater at dante.org.uk (Tim Streater) Date: Thu, 08 Jun 2006 10:20:52 +0100 Subject: [address-policy-wg] Re: [policy-announce] 2006-02 New Policy Proposal (IPv6 Address Allocation and Assignment Policy) In-Reply-To: References: Message-ID: <7.0.1.0.0.20060608101607.04b23fd8@dante.org.uk> At 20:54 07/06/2006, David Conrad wrote: >Jordi, > >Unlurking from the sidelines and speaking only for myself, some >comments on your proposal: > >>It is clear that there are small Internet Service providers (ISPs) >>that do not currently have 200 customers, consequently is not >>feasible for them to make "at least 200 /48" assignments in two >>years. It is, however, unfair that these ISPs have no access to >>IPv6 address space. > >I'm confused. According to RIPE-267 (section 5.1.1), the existing >policy doesn't require requesters to have 200 customers. All that it >requires is that an LIR not be an end site, provide IPv6 >connectivity, and "have a plan for making at least 200 /48 >assignments to other organisations within two years." > >Note it says "a plan". An organization incapable of coming up with >_a plan_ to allocate 200 /48s has more significant problems than not >having IPv6 space. We manage transit networks. We need v6 address space to address our backbones. We expect the allocation to be routed so we could outsource the management of the backbone to some distant entity. All our customers are LIRs and therefore need no space from us. We therefore, in reality, expect to allocate no addresses to no customers in the next two years. I could put together a plan contradicting this fact, but it would be a lie. Why should I lie to the RIR in order to get obtain space? -- Tim From cfriacas at fccn.pt Thu Jun 8 12:11:29 2006 From: cfriacas at fccn.pt (Carlos Friacas) Date: Thu, 8 Jun 2006 11:11:29 +0100 (WEST) Subject: [address-policy-wg] Re: [policy-announce] 2006-02 New Policy Proposal (IPv6 Address Allocation and Assignment Policy) In-Reply-To: <7.0.1.0.0.20060608101607.04b23fd8@dante.org.uk> References: <7.0.1.0.0.20060608101607.04b23fd8@dante.org.uk> Message-ID: On Thu, 8 Jun 2006, Tim Streater wrote: > At 20:54 07/06/2006, David Conrad wrote: >> Jordi, >> >> Unlurking from the sidelines and speaking only for myself, some >> comments on your proposal: >> >>> It is clear that there are small Internet Service providers (ISPs) >>> that do not currently have 200 customers, consequently is not >>> feasible for them to make "at least 200 /48" assignments in two >>> years. It is, however, unfair that these ISPs have no access to >>> IPv6 address space. >> >> I'm confused. According to RIPE-267 (section 5.1.1), the existing >> policy doesn't require requesters to have 200 customers. All that it >> requires is that an LIR not be an end site, provide IPv6 >> connectivity, and "have a plan for making at least 200 /48 >> assignments to other organisations within two years." >> >> Note it says "a plan". An organization incapable of coming up with >> _a plan_ to allocate 200 /48s has more significant problems than not >> having IPv6 space. > > > We manage transit networks. We need v6 address space to address our > backbones. We expect the allocation to be routed so we could outsource the > management of the backbone to some distant entity. All our customers are LIRs > and therefore need no space from us. We therefore, in reality, expect to > allocate no addresses to no customers in the next two years. > > I could put together a plan contradicting this fact, but it would be a lie. > Why should I lie to the RIR in order to get obtain space? This concept of "transit networks" should be part of the policy! Tim is not the only one i saw complaints from about this... > -- Tim Best Regards, ./Carlos -------------- Wide Area Network (WAN) Workgroup, CMF8-RIPE, CF596-ARIN FCCN - Fundacao para a Computacao Cientifica Nacional http://www.fccn.pt "Internet is just routes (184902/571), naming (millions) and... people!" From cfriacas at fccn.pt Thu Jun 8 12:25:55 2006 From: cfriacas at fccn.pt (Carlos Friacas) Date: Thu, 8 Jun 2006 11:25:55 +0100 (WEST) Subject: [address-policy-wg] Re: [policy-announce] 2006-02 New Policy Proposal (IPv6 Address Allocation and Assignment Policy) In-Reply-To: References: Message-ID: On Wed, 7 Jun 2006, David Conrad wrote: > Can you identify an organization that does not want to avoid renumbering or > which might not identify a need to be multihomed? Yes!!! ...there are a lot of clueless people around ;-) > I have a couple of LANs at my house. A /48 for each LAN sounds reasonable to > me. Does that justify an IPv6 /32? It really shouldn't. Most of people outside the so called "v6-community" find very odd that 1 customer gets addressing for 65536 LANs... ;-) > More seriously, impositions of subjective evaluations like figuring out what > is "reasonable" are generally things to be avoided. Also, vagueness of terms > such as "own/related departments/entities/sites" are just begging for abuse. > A person is an entity. Should an organization with a "reasonable" number of > people justify a /32? That's going again on the subjective side... :-( We had enough with the 200-hurdle already, right? > The lack of transparent renumbering, scalable multi-homing, or IPv6-only > applications is a much more significant barrier to deployment. You are > attempting to fix a technology problem by hacking policy in a way that would > exacerbate the technology problem. This seems suboptimal to me. But that's > probably just me. No. You can add me to that list too... :-) > If you have documentary proof of potential illegality, it would probably be > worthwhile to provide it. If not, this sentence is merely FUD and should be > stricken. Even if you do have evidence that some country's law is being > broken, it isn't clear to me how that should affect RIPE policy. For > example, I believe a country in the RIPE region has passed a law (or is in > the process of passing a law) Can i ask *which* one ? :-) > that requires IP address space to be allocated > by that country's government. Should RIPE therefore only allocate address > space to governments? I don't think organisations where govts don't want to control ip allocations will like the extra bureaucracy level. ;-) >> b. Arguments Opposing the Proposal >> >> One possible effect of this proposal would be a growth of global routing >> tables. This is only to be expected when new allocations are made possible >> under this proposal. > > Too simplistic. This proposal, like all PI oriented allocation policies, > changes routing scalability from O(number of service providers) to O(number > of organizations). Pretending this is "only to be expected" is simply wrong. > You can argue that technology will permit O(number of organizations) in the > default free routing system, but that is a different argument than "it is to > be expected". Strongly agree. > A fixed number of assignments was an attempt to quantify a "reasonable" level > of aggregation. Given the routing technology used in IPv6 depends on > aggregatability to scale, there is an implicit assumption that those who > cannot provide aggregation of leaves should themselves become a leaf under > some other aggregator. Yes, but... certain business models are not compatible with this... :-( (...) > Rgds, > -drc > Just my 2 (euro-)cents. Regards, ./Carlos -------------- Wide Area Network (WAN) Workgroup, CMF8-RIPE, CF596-ARIN FCCN - Fundacao para a Computacao Cientifica Nacional http://www.fccn.pt "Internet is just routes (184902/571), naming (millions) and... people!" From jeroen at unfix.org Thu Jun 8 14:04:22 2006 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 08 Jun 2006 14:04:22 +0200 Subject: [address-policy-wg] Re: ... 2006-02 New Policy Proposal (IPv6 Address Allocation and Assignment Policy) In-Reply-To: References: Message-ID: <1149768262.14916.19.camel@firenze.zurich.ibm.com> On Wed, 2006-06-07 at 12:54 -0700, David Conrad wrote: > Jordi, > > Unlurking from the sidelines and speaking only for myself, some > comments on your proposal: [..] > Can you identify an organization that does not want to avoid > renumbering or which might not identify a need to be multihomed? Nobody wants to renumber. Simple fact. You can renumber your home, but anything where more than say (random number) 20+ machines are involved is a mess, especially when you don't have all the factors in your own control: routing, dns (at remote places), firewall entries (at remote places) etc etc etc. Thus avoiding renumbering is a thing that everybody wants. As such every organisation in whatever form will want to have their own address space at a certain point. Unless you want to force NAT down everybodies throat, but that will only end up in more problems anyway, and while they might not be our problems, a bit of empathy on their side is nice too :) For current ISP type organisations there should not be a problem for getting a plan for 200 sites. But if you are only your own office and you want your own web/mail/...- servers then you are never going to be that large, even if you plan for it. That is why they need a *seperate* policy, or at least seperate in wording from the current one. The whole problem with these policies is that they seem more targetted at "Routes" and not at "Address Space". Currently one can request a /31 and simply give one half of it (a /32) to somebody else. Two companies happy under the hat of one LIR and filtering won't affect this either as most people either filter >/48 or >/32. That said, IMHO there should be the availability of address space to anybody who can show a demand for it, thus: /32 and larger for ISP's, thus companies that (plan to) provide connectivity to other sites. This is the current policy. This allows every such ISP to grow for quite some time, even if they are small. They pay a LIR fee every year, thus they won't simply get it and not use it, there will be a business case to get it in the first place. a /48 or larger for non-ISP's, thus endsites and the like. To get these you don't become a full LIR, but you do pay a substantial yearly fee to make sure that one really needs it. If you are too small that you can't cough up a certain amount of money you won't easily be able to buy and maintain (personal costs) the correct equipment for running the connectivity anyway (but that is my pov) Everyone who really needs it thus should be able to get address space. But the amount of address space SHOULD measure up to the amount that will actually be used. Wasting space does not make sense, unless you want our children's children to complain about those filthy people who stole all the address space when there was still plenty. (okay there are about 7 tries left after 2000::/3 is used... Routing policy wise: I am being a bit mean here as above I state that routing and addressing are seperate. Also note that none of the RIR's can force anybody to accept any kind of routing policy whatsoever, though one might be inclined to play along the nice rules. (That said, if anybody with some value would steal say 666::/32 and simply use it then most likely it will simply work as long as your network is important enough that the others have to accept it otherwise they would loose customers. It is just not 'nice' to do, but it can be done by a few if they wanted it) The /32's are PA, as such they SHOULD not be deaggregated as such only the /32 and up should pop up in the routing tables. The /48's are PI, as such these can pop up in the size allocated. There is one large issue with this though. Say you are Company XYZ. You have an office in London and one in Beijing and a couple of others. To keep firewall rules simple you want the same block, as you can then filter on 2001:db8::/40. Thus you announce the /40 in one go. Your webservers though are in the London office. Thus when some person in China goes to the website, the traffic flows to Beijing, as that is the best announcement that will be received in that area. This thus means that you will have to accept and forward yourself (with some magic or an internal/private network) all this traffic over your small 2mbit line to London. As such this gives a load of issues and one will be inclined quickly to announce the /48's seperatly per office. The same goes for the PA space of course as at a certain point you will want to do a bit more Traffic Engineering and at the moment the only way to do this is to announce more specifics in BGP. There is potential (note that I write potential ;) problem that could arise, being that the routing table size becomes very large. There is one nice side-effect to this. Lets say that 500.000 allocations will be made. That means that RIPE will receive: 500.0000 * 2000 EUR yearly. That should allow for some good people to get an incentive to build some nice routing setup that also scales to that magnitude... Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 313 bytes Desc: This is a digitally signed message part URL: From david.conrad at icann.org Thu Jun 8 19:02:17 2006 From: david.conrad at icann.org (David Conrad) Date: Thu, 8 Jun 2006 10:02:17 -0700 Subject: [address-policy-wg] Re: [policy-announce] 2006-02 New Policy Proposal (IPv6 Address Allocation and Assignment Policy) In-Reply-To: <7.0.1.0.0.20060608101607.04b23fd8@dante.org.uk> References: <7.0.1.0.0.20060608101607.04b23fd8@dante.org.uk> Message-ID: <5DEB684F-69CC-417C-871B-EB19AD60A342@icann.org> Tim, On Jun 8, 2006, at 2:20 AM, Tim Streater wrote: > We manage transit networks. We need v6 address space to address our > backbones. This appears to be a different set of criteria than what Jordi was using to justify his proposal. > We expect the allocation to be routed so we could outsource the > management of the backbone to some distant entity. All our > customers are LIRs and therefore need no space from us. We > therefore, in reality, expect to allocate no addresses to no > customers in the next two years. Sounds to me like a modification to the IPv6 IXP allocation policy would meet your unusual scenario. > I could put together a plan contradicting this fact, but it would > be a lie. Why should I lie to the RIR in order to get obtain space? You shouldn't, of course. Rgds, -drc From david.conrad at icann.org Thu Jun 8 19:53:51 2006 From: david.conrad at icann.org (David Conrad) Date: Thu, 8 Jun 2006 10:53:51 -0700 Subject: [address-policy-wg] Re: [policy-announce] 2006-02 New Policy Proposal (IPv6 Address Allocation and Assignment Policy) In-Reply-To: <448813CB.5080805@avernus.net> References: <448813CB.5080805@avernus.net> Message-ID: Niall, On Jun 8, 2006, at 5:10 AM, Niall Murphy wrote: > This is the most weaselly-worded clause of any RIR policy I've read. No argument, although I'm sure I can find more weaselly-worded clauses if I looked :-). > If we *actually* cared about creating a /real/ barrier to DFZ > membership - for aggregation or for any other reason - why on earth > would we require a *plan* rather than actual numbers? Personal opinion: appeasement of the more vocal and insistent in the IPv6 community who felt the RIRs were blocking deployment of IPv6. Perhaps not surprisingly, this appeasement attempt apparently failed to either significantly increase deployment of IPv6 or quiet those vocal and insistent members of the IPv6 community. I suspect the latter would only be happy with FCFS, however I also suspect the former will only be addressed when IPv6 is finished. > As it stands, the 'plan' clause is a sufficient loophole that it > does not serve well either purpose of enforcing aggregation, or > *not* enforcing aggregation. It is far from being a clear and > credible policy, and it should be taken out and shot. You have it within your power to propose such a policy revision... Rgds, -drc From david.conrad at icann.org Thu Jun 8 22:12:23 2006 From: david.conrad at icann.org (David Conrad) Date: Thu, 8 Jun 2006 13:12:23 -0700 Subject: [address-policy-wg] Re: ... 2006-02 New Policy Proposal (IPv6 Address Allocation and Assignment Policy) In-Reply-To: <1149768262.14916.19.camel@firenze.zurich.ibm.com> References: <1149768262.14916.19.camel@firenze.zurich.ibm.com> Message-ID: Jeroen, On Jun 8, 2006, at 5:04 AM, Jeroen Massar wrote: > As such every organisation in whatever form will want to have > their own address space at a certain point. Unless you want to > force NAT > down everybodies throat, I don't think the RIRs are in a position to force anything down anyone's throat. The RIRs exist at the mercy and pleasure of its members. Like NATv4, NATv6 will occur is the market demands it. Given renumbering is hard in IPv6 and IPv6 uses the same routing technology as IPv4, NATv6 is assured. > For current ISP type organisations there should not be a problem for > getting a plan for 200 sites. Yep. > But if you are only your own office and > you want your own web/mail/...- servers then you are never going to be > that large, even if you plan for it. That is why they need a > *seperate* > policy, or at least seperate in wording from the current one. Personal opinion: what was needed was for IPv6 to be finished before we attempted to deploy it. It wasn't. Now we have the challenge of trying to engineer _policies_ to address technical failure. One can argue that there is plenty of routing system headroom and/or we'll fix the technology soon, so it is OK to allocate PI to all and sundry, but people said that about CIDR back in the early to mid-90's. The reality is that it is _highly_ likely that in the future, we'll have to deal with the increased nitrogen content of the pool that we pee in today. > The whole problem with these policies is that they seem more targetted > at "Routes" and not at "Address Space". Exactly. And the reason for this is that IPv6 made the exact same mistake as IPv4 in overloading the address with both routing locator and end point identifier. > Everyone who really needs it thus should be able to get address space. They can. I think what you meant is everybody who really needs it should be able to get provider independent address space. > But the amount of address space SHOULD measure up to the amount that > will actually be used. This doesn't make sense in the context of IPv6. "Amount of address space" is irrelevant given the lower 64 bits is inconceivably sparsely used by fiat. IPv6 allocations are oriented towards networks not addresses. > I am being a bit mean here as above I state that routing and > addressing > are seperate. Unfortunately, IPv6 does not treat them as separate and that, I believe, leads to the difficulty. Ideally, routing prefixes would be allocated to transit networks and end point identifiers would be assigned to end users. These two address spaces can and should be separate, but IPv6 maps both into the same address space. End users would present their end point identifiers to the transit networks for transit services. However, we're not in the ideal, so many of the policies that are being proposed are attempting to paper around the problem. > The /48's are PI, as such these can pop up in the size allocated. There are 281,474,976,710,656 possible /48s. The routing system can't flat route 32 bits, how is it going to route 48 bits? > There is potential (note that I write potential ;) problem that could > arise, being that the routing table size becomes very large. To be clear, routing table size isn't really the issue. It is routing table thrash. But yes, that is the potential problem and every PI oriented proposal I've seen to date exacerbates the problem. > There is one nice side-effect to this. Lets say that 500.000 > allocations > will be made. That means that RIPE will receive: 500.0000 * 2000 > EUR yearly. > That should allow for some good people to get an incentive to build > some > nice routing setup that also scales to that magnitude... The problem hasn't been solved with IPv4. What makes you think it'll be solved with IPv6? Rgds, -drc From david.conrad at icann.org Thu Jun 8 23:50:29 2006 From: david.conrad at icann.org (David Conrad) Date: Thu, 8 Jun 2006 14:50:29 -0700 Subject: [address-policy-wg] Re: [policy-announce] 2006-02 New Policy Proposal (IPv6 Address Allocation and Assignment Policy) In-Reply-To: References: Message-ID: <6600DA98-A787-491D-A841-39E60005218A@icann.org> Carlos, On Jun 8, 2006, at 3:25 AM, Carlos Friacas wrote: >> More seriously, impositions of subjective evaluations like >> figuring out what is "reasonable" are generally things to be >> avoided. Also, vagueness of terms such as "own/related >> departments/entities/sites" are just begging for abuse. A person >> is an entity. Should an organization with a "reasonable" number >> of people justify a /32? > > That's going again on the subjective side... :-( Right. > We had enough with the 200-hurdle already, right? There is a difference between subjective and arbitrary. 200 is arbitrary. It was a number picked out of thin air that was felt to be a reasonable compromise. However, once that number has been chosen, it can be objectively verified. The problem with subjective values like "reasonable" is that it leaves it to the registry staff to figure out what the right value is. This is an icky place to be as it can change depending on day, mood of the registry person, phase of moon, etc. In my opinion, arbitrary is OK (not perfect, but workable as long as the arbitrary number is reached by consensus). Subjective is just asking for trouble. Rgds, -drc From marc.van.selm at nc3a.nato.int Fri Jun 9 08:05:52 2006 From: marc.van.selm at nc3a.nato.int (Marc van Selm) Date: Fri, 9 Jun 2006 08:05:52 +0200 Subject: [address-policy-wg] Re: [policy-announce] 2006-02 New Policy Proposal (IPv6 Address Allocation and Assignment Policy) In-Reply-To: References: Message-ID: <200606090805.52649.marc.van.selm@nc3a.nato.int> On Wednesday 07 June 2006 14:20, JORDI PALET MARTINEZ wrote: > Hi, > > I will like to know if anyone has any comments/inputs on this proposal. > > I tried to follow the suggestions received after the presentation of the > IPv6 PI policy at the last meeting. I still support PI space and like the contractual relationship with the RIR. I do not like the requirement that the block must be returned after 3 years. That is against the main reason why PI is useful. Freedom of renumbering everytime one needs to change ISP. When one needs to start over after 3 years one might as wel use PA because one needs to renumber once in a while anyway. The whole purpose of PI, in my mind, is to be able to build and extend a business critical and possibly worldwide network without having to renumber for the sake of it. (Not that I want to hardcode IP addresses but a transparent renumbering of a large network is to costly and interferes to much with the core business) Marc -- Marc van Selm NATO C3 Agency CIS Division E-mail: marc.van.selm at nc3a.nato.int (PGP capable) From marc.van.selm at nc3a.nato.int Fri Jun 9 08:09:50 2006 From: marc.van.selm at nc3a.nato.int (Marc van Selm) Date: Fri, 9 Jun 2006 08:09:50 +0200 Subject: [address-policy-wg] Re: [policy-announce] 2006-02 New Policy Proposal (IPv6 Address Allocation and Assignment Policy) In-Reply-To: References: Message-ID: <200606090809.50979.marc.van.selm@nc3a.nato.int> On Thursday 08 June 2006 12:25, Carlos Friacas wrote: > On Wed, 7 Jun 2006, David Conrad wrote: > > Can you identify an organization that does not want to avoid renumbering > > or which might not identify a need to be multihomed? > > Yes!!! ...there are a lot of clueless people around ;-) > > > I have a couple of LANs at my house. A /48 for each LAN sounds > > reasonable to me. Does that justify an IPv6 /32? I think the /32 came from the standard filtering "rule" that some people adopt. Although I see the rationale for enforcing aggregation I wonder if the generic rule to block anything that is smaller holds ground and is that useful. -- Marc van Selm NATO C3 Agency CIS Division E-mail: marc.van.selm at nc3a.nato.int (PGP capable) From marc.van.selm at nc3a.nato.int Fri Jun 9 08:20:43 2006 From: marc.van.selm at nc3a.nato.int (Marc van Selm) Date: Fri, 9 Jun 2006 08:20:43 +0200 Subject: [address-policy-wg] 2005-03 Policy Proposal Withdrawn (IPv6 Initial Allocation) In-Reply-To: <20060606100453.ECF7F2F595@herring.ripe.net> References: <20060606100453.ECF7F2F595@herring.ripe.net> Message-ID: <200606090820.43585.marc.van.selm@nc3a.nato.int> On Tuesday 06 June 2006 12:04, Filiz Yilmaz wrote: > PDP Number: 2005-03 > IPv6 Initial Allocation > > Dear Colleagues > > The proposal 2005-03, IPv6 Initial Allocation, has been withdrawn by the > proposer who thought this proposal is superceded by poposal 2006-02, IPv6 > Address Allocation and Assignment Policy. 2006-02 fits in NATO's business model and I personally think it makes good sense and has removed the (in my view) unverifiable constraints and arbritrary limits. Marc -- Marc van Selm NATO C3 Agency CIS Division E-mail: marc.van.selm at nc3a.nato.int (PGP capable) From stefan.camilleri at maltanet.net Thu Jun 8 12:31:39 2006 From: stefan.camilleri at maltanet.net (Stefan Camilleri) Date: Thu, 8 Jun 2006 12:31:39 +0200 Subject: [address-policy-wg] Re: [policy-announce] 2006-02 New Policy Proposal (IPv6 Address Allocation and Assignment Policy) In-Reply-To: Message-ID: <000b01c68ae6$bb1d5250$2200a8c0@streamoffice.datastream.com.mt> Jordi, Having recently experienced current RIPE policy on IPv6 Address Allocation, I cannot figure out David Conrad's outburst and felt I needed to put in my penny's worth as a countermeasure. >> It is clear that there are small Internet Service providers (ISPs) >> that do not currently have 200 customers, consequently is not feasible >> for them to make ?at least 200 /48? assignments in two years. It is, >> however, unfair that these ISPs have no access to >> IPv6 address space. >I'm confused. According to RIPE-267 (section 5.1.1), the existing policy doesn't require requesters to have >200 customers. All that it requires is that an LIR not be an end site, provide IPv6 connectivity, and "have a >plan for making at least 200 /48 assignments to other organisations within two years." >Note it says "a plan". An organization incapable of coming up with _a plan_ to allocate 200 /48s has more >significant problems than not having IPv6 space. It seems that a number of people at the helm of the Internet decision process need some exposure to realities of the ISP business and more specifically to the issues related to the introduction of IPv6. I had never questioned RIPE policies on IPv4 assignments even though they may seemed at times overly bureaucratic. If anything, of late, I believe they're a wee bit laxing. I've seen /20s being assigned to Garage operations!! Dangerous when you think of all the fuss about IPv4 running out! Anyway, to come back to Dave Conrad, the issue here is IPv6. That is what changes everything. We have over /17 of IPv4 address space allocated. We have over 20,000 broadband customers and well over 200 clients that would benefit from Ipv6 assignments and who now either have a /24 to /28 or use NAT. We also operate a small transit network and are linked to a major European Tier1 provider. Finally we are part of an Ipv6 task force trying to determine the future direction of IPv6 rollout. But basically I CANNOT have a plan, at this stage for /48 on Ipv6. Its WAY too early. On the other hand we are upgrading our kit as part of the normal hardware lifetime updates and we consider this the right time to go for Ipv6 peering. Like Tim in his submission I could EASILY put a plan together contradicting my current reality... But why should I lie to RIPE? And one final thing, we're talking about IPv6. The addressing space that can allow 2000 addresses per square meter on the planet as some of the current cliches go... We're established and qualified in the business but I have to beg, grovel or lie to get this allocation!! THAT is confusing Stephen > -----Original Message----- > From: address-policy-wg-admin at ripe.net > [mailto:address-policy-wg-admin at ripe.net] On Behalf Of David Conrad > Sent: L-Erbg?a, 7 ta' ?unju 2006 21:54 > To: jordi.palet at consulintel.es > Cc: address-policy-wg at ripe.net > Subject: Re: [address-policy-wg] Re: [policy-announce] > 2006-02 New Policy Proposal (IPv6 Address Allocation and > Assignment Policy) > > Jordi, > > Unlurking from the sidelines and speaking only for myself, > some comments on your proposal: > > > It is clear that there are small Internet Service providers (ISPs) > > that do not currently have 200 customers, consequently is > not feasible > > for them to make ?at least 200 /48? assignments in two > years. It is, > > however, unfair that these ISPs have no access to > > IPv6 address space. > > I'm confused. According to RIPE-267 (section 5.1.1), the > existing policy doesn't require requesters to have 200 > customers. All that it requires is that an LIR not be an end > site, provide IPv6 connectivity, and "have a plan for making > at least 200 /48 assignments to other organisations within two years." > > Note it says "a plan". An organization incapable of coming > up with _a plan_ to allocate 200 /48s has more significant > problems than not having IPv6 space. > > > In some cases, organisations may have a small number of sites, but > > still need their own block so that they can avoid future > renumbering, > > if they change their upstream provider or identify a need to become > > Multihomed. > > Can you identify an organization that does not want to avoid > renumbering or which might not identify a need to be multihomed? > > > b) plan to provide IPv6 connectivity to other organisations > or to its > > own/related departments/entities/sites to which it will > assign / 48s > > by advertising that connectivity through a single > aggregated address > > allocation > > > > and > > c) have a plan for making a reasonable number of /48 assignments > > within two years > > I have a couple of LANs at my house. A /48 for each LAN > sounds reasonable to me. Does that justify an IPv6 /32? > > More seriously, impositions of subjective evaluations like > figuring out what is "reasonable" are generally things to be > avoided. Also, vagueness of terms such as "own/related > departments/entities/sites" > are just begging for abuse. A person is an entity. Should > an organization with a "reasonable" number of people justify a /32? > > > a. Arguments Supporting the Proposal > ... > > The difficulty encountered in receiving IPv6 address space > by some big > > entities that have a need to use IPv6 is a clear barrier for its > > deployment. > > The lack of transparent renumbering, scalable multi-homing, or IPv6- > only applications is a much more significant barrier to deployment. > You are attempting to fix a technology problem by hacking > policy in a way that would exacerbate the technology problem. > This seems suboptimal to me. But that's probably just me. > > > By setting up this policy, we would avoid creating an > unfair situation > > among different RIR service regions. Other RIRs have > already modified > > the original IPv6 common policy to avoid these barriers. > > http://www.bumperart.com/ProductDetails.aspx? > SKU=2004011203&productID=523 > > > We could possibly say that an arbitrary number of sites in order to > > qualify for an allocation could be considered illegal in some > > countries. The RIPE community cannot set policies that could prove > > unlawful as this could have important implications. > > If you have documentary proof of potential illegality, it > would probably be worthwhile to provide it. If not, this > sentence is merely FUD and should be stricken. Even if you > do have evidence that some country's law is being broken, it > isn't clear to me how that should affect RIPE policy. For > example, I believe a country in the RIPE region has passed a > law (or is in the process of passing a law) that requires IP > address space to be allocated by that country's government. > Should RIPE therefore only allocate address space to governments? > > > b. Arguments Opposing the Proposal > > > > One possible effect of this proposal would be a growth of global > > routing tables. This is only to be expected when new > allocations are > > made possible under this proposal. > > Too simplistic. This proposal, like all PI oriented > allocation policies, changes routing scalability from > O(number of service > providers) to O(number of organizations). Pretending this is > "only to be expected" is simply wrong. You can argue that > technology will permit O(number of organizations) in the > default free routing system, but that is a different argument > than "it is to be expected". > > > Opposing arguments should avoid being unfair to smaller ISPs that > > could not justify a fixed number of assignments. > > Is it unfair that carriers that fly Boeing 747s get more > revenues than carriers that fly Saab 340s? > > A fixed number of assignments was an attempt to quantify a > "reasonable" level of aggregation. Given the routing > technology used in IPv6 depends on aggregatability to scale, > there is an implicit assumption that those who cannot provide > aggregation of leaves should themselves become a leaf under > some other aggregator. > > > Such a policy could be seen as irrational > > "In an insane world the sane man must appear insane" -- Spock > > > and might be comparable with imposing a similar requirement for > > IPv4 address space allocations, which the community would > be unlikely > > to accept. > > In at least one region, initial allocations of PI IPv4 > required demonstration of utilization of half the initial PI > allocation, so in essence, there was an implicit requirement > to meet a fixed number to justify an allocation. Of course, > this wasn't in the RIPE region, but weren't you the one > arguing that the other regions have a similar policy to what > you propose as justification for your proposal? > > Rgds, > -drc > > From niallm at avernus.net Thu Jun 8 14:10:51 2006 From: niallm at avernus.net (Niall Murphy) Date: Thu, 08 Jun 2006 13:10:51 +0100 Subject: [address-policy-wg] Re: [policy-announce] 2006-02 New Policy Proposal (IPv6 Address Allocation and Assignment Policy) In-Reply-To: References: Message-ID: <448813CB.5080805@avernus.net> David Conrad wrote: > I'm confused. According to RIPE-267 (section 5.1.1), the existing > policy doesn't require requesters to have 200 customers. All that it > requires is that an LIR not be an end site, provide IPv6 connectivity, > and "have a plan for making at least 200 /48 assignments to other > organisations within two years." > > Note it says "a plan". An organization incapable of coming up with _a > plan_ to allocate 200 /48s has more significant problems than not > having IPv6 space. This is the most weaselly-worded clause of any RIR policy I've read. If we *actually* cared about creating a /real/ barrier to DFZ membership - for aggregation or for any other reason - why on earth would we require a *plan* rather than actual numbers? Conversely, if we *don't* care about creating a real barrier, why have this charade at all? As it stands, the 'plan' clause is a sufficient loophole that it does not serve well either purpose of enforcing aggregation, or *not* enforcing aggregation. It is far from being a clear and credible policy, and it should be taken out and shot. Niall, who apologises for the excessive markup From heldal at eml.cc Fri Jun 9 11:38:00 2006 From: heldal at eml.cc (Per Heldal) Date: Fri, 09 Jun 2006 11:38:00 +0200 Subject: [address-policy-wg] Re: [policy-announce] 2006-02 New Policy Proposal (IPv6 Address Allocation and Assignment Policy) In-Reply-To: <200606090805.52649.marc.van.selm@nc3a.nato.int> References: <200606090805.52649.marc.van.selm@nc3a.nato.int> Message-ID: <1149845880.16953.263434545@webmail.messagingengine.com> On Fri, 9 Jun 2006 08:05:52 +0200, "Marc van Selm" said: [snip] > I do not like the requirement that the block must be returned after 3 > years. > That is against the main reason why PI is useful. Freedom of renumbering > everytime one needs to change ISP. When one needs to start over after 3 > years > one might as wel use PA because one needs to renumber once in a while > anyway. We're not talking 3 years from the assignment is made, but 3 years from the time when there is consensus that PI in the traditional sense is no longer necessary. So, if say in 2012 the community decides that some available multi-homing solution works, scales etc for all uses, you have to migrate by 2015. The availability of tools to handle and/or eliminate any re-numbering issues would be an important criteria for such a decision. [I support PI if I have my arms twisted to fully implement v6 *now*, but the fundamental question is whether v6 without a scalable routing architecture is ready for use.] //per -- Per Heldal http://heldal.eml.cc/ From nick at inex.ie Fri Jun 9 14:03:33 2006 From: nick at inex.ie (Nick Hilliard) Date: Fri, 09 Jun 2006 13:03:33 +0100 Subject: [address-policy-wg] Re: [policy-announce] 2006-02 New Policy Proposal (IPv6 Address Allocation and Assignment Policy) In-Reply-To: <448813CB.5080805@avernus.net> References: <448813CB.5080805@avernus.net> Message-ID: <1149854613.19493.60.camel@pancake.netability.ie> > This is the most weaselly-worded clause of any RIR policy I've read. Let's examine what possibilities there are: plan vs requirement: 1. Specify that a plan should exist to deploy x number of v6 sites within y years: this is nonsense from the point of view that anyone can create a plan to deploy anything, regardless of whether this plan is in any grounded in reality. This comes back to the "do we lie to the RIR" issue. 2. Specify that an immediate requirement exist for x amount of v6 sites right now: this is probably worse in the sense that the RIR has no way to validate this type of claim and that it will end up with more porky pies being told to the RIR. 3. Specify that all LIRs who request a first ipv6 allocation are given a /32. No particular justification required, except that the space be used for routing ipv6 traffic on the internet. "reasonable number" vs "at least x". 1. "at least x" has been proved to be completely meaningless in practice. In fact, it's become such an problem that not only do oranisations endemically lie about it, people openly admit to lying about it. This is an extraordinary situation, to put it diplomatically. 2. "reasonable number" is weasly, no doubt about it, but if a utilisation requirement be added, what's the option here? 200x/48 is a very large amount of deployment space if you're a small LIR with only a couple of customer, but you multihome and have a valid business/technical reason for anb ipv6 allocation. But if you're a huge enterprise organisation or a tier-1 transit provider or something, 200 x /48 might be very small. "reasonable" is suitably meaningless to cover both situations. I mean, what are we actually trying to do here? Do we want LIRs to have easy access to v6 space or not? Why don't we just scrap this requirement completely and say that all LIRs can apply for and receive an ipv6 /32, so long as its primary purpose is for routing ipv6 packets on their and their customers networks (simply to avoid ipv6 registry space being used for other non-related purposes where global uniqueness is a requirement). Is this substantially different from the de-facto situation at the moment? It certainly involves fewer lies and much less pretence on the part of the RIR (if the RIR can be reasonably blamed for its policies and I'm not saying that it should be). > Niall, who apologises for the excessive markup For your excessive markup, you're buying coffee next time. :-) Nick From leo at ripe.net Fri Jun 9 15:32:48 2006 From: leo at ripe.net (leo vegoda) Date: Fri, 09 Jun 2006 15:32:48 +0200 Subject: [address-policy-wg] Re: [policy-announce] 2006-02 New Policy Proposal (IPv6 Address Allocation and Assignment Policy) In-Reply-To: <1149854613.19493.60.camel@pancake.netability.ie> References: <448813CB.5080805@avernus.net> <1149854613.19493.60.camel@pancake.netability.ie> Message-ID: <44897880.5090108@ripe.net> Nick Hilliard wrote: >> This is the most weaselly-worded clause of any RIR policy I've read. > > Let's examine what possibilities there are: > > plan vs requirement: > > 1. Specify that a plan should exist to deploy x number of v6 sites > within y years: this is nonsense from the point of view that > anyone can create a plan to deploy anything, regardless of > whether this plan is in any grounded in reality. This comes > back to the "do we lie to the RIR" issue. > 2. Specify that an immediate requirement exist for x amount of v6 > sites right now: this is probably worse in the sense that the > RIR has no way to validate this type of claim and that it will > end up with more porky pies being told to the RIR. Where an LIR has an existing deployed IPv4 infrastructure and is looking to provide IPv6 addresses for all or some of that network this option is not too unrealistic. There is normally a reasonable basis for working out what network elements an LIR needs to address. The problem with a requirement like this is that it makes it more difficult to evaluate the needs to new entrants to the market. > 3. Specify that all LIRs who request a first ipv6 allocation are > given a /32. No particular justification required, except that > the space be used for routing ipv6 traffic on the internet. This one's the easiest to do, of course. Regards, -- leo vegoda Registration Services Manager RIPE NCC From nick at inex.ie Fri Jun 9 16:13:24 2006 From: nick at inex.ie (Nick Hilliard) Date: Fri, 09 Jun 2006 15:13:24 +0100 Subject: [address-policy-wg] Re: [policy-announce] 2006-02 New Policy Proposal (IPv6 Address Allocation and Assignment Policy) In-Reply-To: <44897880.5090108@ripe.net> References: <448813CB.5080805@avernus.net> <1149854613.19493.60.camel@pancake.netability.ie> <44897880.5090108@ripe.net> Message-ID: <1149862404.19493.93.camel@pancake.netability.ie> > out what network elements an LIR needs to address. The problem with a > requirement like this is that it makes it more difficult to evaluate the > needs to new entrants to the market. Indeed - the .eu registrar incident was very scary for this very reason. Nick From nick at inex.ie Fri Jun 9 16:27:46 2006 From: nick at inex.ie (Nick Hilliard) Date: Fri, 09 Jun 2006 15:27:46 +0100 Subject: [address-policy-wg] Comments on 2006-01 (IPv6 Address Allocation and Assignment Policy) In-Reply-To: <1149845880.16953.263434545@webmail.messagingengine.com> References: <200606090805.52649.marc.van.selm@nc3a.nato.int> <1149845880.16953.263434545@webmail.messagingengine.com> Message-ID: <1149863266.19493.110.camel@pancake.netability.ie> [let's not mix up 2006-01 and 2006-02] > We're not talking 3 years from the assignment is made, but 3 years from > the time when there is consensus that PI in the traditional sense is no > longer necessary. And if consensus does not occur? We haven't even reached the stage of running code yet, and there is very significant controversy about whether shim6 will ever be a suitable solution to the multihoming problem. > [I support PI if I have my arms twisted to fully implement v6 *now*, but > the fundamental question is whether v6 without a scalable routing > architecture is ready for use.] Agreed. And I vote that we stop using v4 on the same principle: that it doesn't have a scalable routing architecture and is consequently not ready for production use. Oh, but wait??! I support ipv6 PI space. We have no option about its requirement now, and in the 10 years that ipv6 has been around in its (more-or-less) current form, the only potential alternative to emerge is shim6, which is a long way from having running code, quite a bit further from production deployment and the way things are looking at the moment, furthest still from rough consensus. I do not support the current policy proposal 2006-01 (v2.0) as it stands, although it could be fixed to make it more palatable. The primary problem is the implicit fixed lifetime of the address space assignment for those organisations who require PI6 space but who have no particular reason to eventually become a LIR. A LIR has significant requirements in terms of administration, and it does not seem reasonable to me to encumber those organisations who have a simple requirement for portable address space with the choice of either becoming a LIR or being forced to renumber. This makes the proposal unpalatable. I would be more inclined to support a scenario where the PI6 space assignment is permanent but contingent on a simpler contractual relationship with the RIR, and where that contractual relationship does not force the assignee to become a LIR at some arbitrary point in the future. The minimum assignment size of /32 is too large. PI6 space should be assigned in some accordance with the requirements of the assignee. It makes no sense to assign a /32 to a small organisation with a multihoming requirement, just because there are lots of /32's available. Adjusting this policy to assign smaller amount of address space will not cause any difference in count-size to the PI prefix swamp, because the number of assignments will be directly related to the number of assignees, not the size of the assignment (multiple assignments will probably be uncommon, given the amount of v6 address space available). Assignment from a super block is a good thing. The proposal should note that an ipv6 assignment should not count towards the requestor LIR's billing score. If the assignee has a direct relationship with the RIR, then this channel should be used to deal with the administrative expense of assigning and maintaining the PI space assignment. The proposal should also note that if the direct relationship between the assignee and the RIR is ended, then the address space will be reclaimed by the RIR. We have a lot of ipv4 address space assignment leakage, and now that we've learned the lesson, there is no need to make the same mistake with ipv6. Nick From niallm at avernus.net Fri Jun 9 15:42:05 2006 From: niallm at avernus.net (Niall Murphy) Date: Fri, 09 Jun 2006 14:42:05 +0100 Subject: [address-policy-wg] Re: [policy-announce] 2006-02 New Policy Proposal (IPv6 Address Allocation and Assignment Policy) In-Reply-To: <44897880.5090108@ripe.net> References: <448813CB.5080805@avernus.net> <1149854613.19493.60.camel@pancake.netability.ie> <44897880.5090108@ripe.net> Message-ID: <44897AAD.8070108@avernus.net> leo vegoda wrote: > Where an LIR has an existing deployed IPv4 infrastructure and is > looking to provide IPv6 addresses for all or some of that network this > option is not too unrealistic. There is normally a reasonable basis > for working out what network elements an LIR needs to address. The > problem with a requirement like this is that it makes it more > difficult to evaluate the needs to new entrants to the market. Yes. And, sadly, it's new entrants who in some senses we'd most like to encourage. Niall From david.conrad at icann.org Fri Jun 9 19:39:16 2006 From: david.conrad at icann.org (David Conrad) Date: Fri, 9 Jun 2006 10:39:16 -0700 Subject: [address-policy-wg] Re: [policy-announce] 2006-02 New Policy Proposal (IPv6 Address Allocation and Assignment Policy) In-Reply-To: <000b01c68ae6$bb1d5250$2200a8c0@streamoffice.datastream.com.mt> References: <000b01c68ae6$bb1d5250$2200a8c0@streamoffice.datastream.com.mt> Message-ID: <21554F86-D97B-4298-A689-51D3BF938A2F@icann.org> Stefan, On Jun 8, 2006, at 3:31 AM, Stefan Camilleri wrote: > It seems that a number of people at the helm of the Internet > decision process need some exposure to realities of the ISP > business and more specifically to the issues related to the > introduction of IPv6. In the context of IP address policies, you, as part of the RIPE community, are the one "at the helm of the Internet decision process" -- it is you and the rest of the RIPE community that are creating the policies. If you need more exposure to reality... :-) > We have over /17 of IPv4 address space allocated. We have over > 20,000 broadband customers and well over 200 clients that would > benefit from Ipv6 assignments and who now either have a /24 to /28 > or use NAT. We also operate a small transit network and are linked > to a major European Tier1 provider. Finally we are part of an Ipv6 > task force trying to determine the future direction of IPv6 > rollout. But basically I CANNOT have a plan, at this stage for /48 > on Ipv6. Its WAY too early. On the other hand we are upgrading our > kit as part of the normal hardware lifetime updates and we consider > this the right time to go for Ipv6 peering. Like Tim in his > submission I could EASILY put a plan together contradicting my > current reality... But why should I lie to RIPE? You shouldn't. Just to be clear, you are saying you cannot come up with plans that you believe represents a reasonable approximation to what you believe your IPv6 needs will be for your customers _in two years_? When do you expect to provide v6 services to your customers? > And one final thing, we're talking about IPv6. Actually, since IPv6 followed IPv4's mistake of co-mingling location with identity, we're really talking about routing scalability. Since IPv6 uses the exact same routing technology as IPv4, it isn't too surprising that the same problems that we're experiencing in IPv4 reoccur with IPv6. > The addressing space that can allow 2000 addresses per square meter > on the planet as some of the current cliches go... This piece of misinformation is probably among the most damaging the IPv6 community has inflicted on itself. While theoretically true in the pedantic sense, in reality it is pure misdirection and completely irrelevant. > We're established and qualified in the business but I have to beg, > grovel or lie to get this allocation!! Dramatic, but I suspect a bit of hyperbole. I'm honestly curious: have you applied to RIPE for IPv6 address space and been rejected? > THAT is confusing If it is confusing, it is probably because you've drunk the IPv6 Forum cool aid. IPv6 did not address (pun intended) the routing scalability issue. As such, the same constraints that impact address usage (note: not address availability) in IPv4 apply to IPv6. What is confusing to me is that network operators of today seem so eager to recreate the problems that nearly caused the Internet to break in the mid-nineties. However, the nice thing about history repeating itself is that you know what to expect... Rgds, -drc From jwkckid1 at ix.netcom.com Sun Jun 11 12:19:07 2006 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Sun, 11 Jun 2006 03:19:07 -0700 Subject: [address-policy-wg] Re: [policy-announce] 2006-02 New Policy Proposal (IPv6 Address Allocation and Assignment Policy) References: <000b01c68ae6$bb1d5250$2200a8c0@streamoffice.datastream.com.mt> Message-ID: <448BEE15.4B172C21@ix.netcom.com> Stefan, and all, David's outbursts in the realm of the ridiculous are legendary in internet lore. Stefan Camilleri wrote: > Jordi, > > Having recently experienced current RIPE policy on IPv6 Address Allocation, I cannot figure out David Conrad's outburst and felt I needed to put in my penny's worth as a countermeasure. > > >> It is clear that there are small Internet Service providers (ISPs) > >> that do not currently have 200 customers, consequently is not feasible > >> for them to make ???at least 200 /48??? assignments in two years. It is, > >> however, unfair that these ISPs have no access to > >> IPv6 address space. > > >I'm confused. According to RIPE-267 (section 5.1.1), the existing policy doesn't require requesters to have >200 customers. All that it requires is that an LIR not be an end site, provide IPv6 connectivity, and "have a >plan for making at least 200 /48 assignments to other organisations within two years." > > >Note it says "a plan". An organization incapable of coming up with _a plan_ to allocate 200 /48s has more > >significant problems than not having IPv6 space. > > It seems that a number of people at the helm of the Internet decision process need some exposure to realities of the ISP business and more specifically to the issues related to the introduction of IPv6. I had never questioned RIPE policies on IPv4 assignments even though they may seemed at times overly bureaucratic. If anything, of late, I believe they're a wee bit laxing. I've seen /20s being assigned to Garage operations!! Dangerous when you think of all the fuss about IPv4 running out! Anyway, to come back to Dave Conrad, the issue here is IPv6. That is what changes everything. > > We have over /17 of IPv4 address space allocated. We have over 20,000 broadband customers and well over 200 clients that would benefit from Ipv6 assignments and who now either have a /24 to /28 or use NAT. We also operate a small transit network and are linked to a major European Tier1 provider. Finally we are part of an Ipv6 task force trying to determine the future direction of IPv6 rollout. But basically I CANNOT have a plan, at this stage for /48 on Ipv6. Its WAY too early. On the other hand we are upgrading our kit as part of the normal hardware lifetime updates and we consider this the right time to go for Ipv6 peering. Like Tim in his submission I could EASILY put a plan together contradicting my current reality... But why should I lie to RIPE? > > And one final thing, we're talking about IPv6. The addressing space that can allow 2000 addresses per square meter on the planet as some of the current cliches go... We're established and qualified in the business but I have to beg, grovel or lie to get this allocation!! THAT is confusing > > Stephen > > > -----Original Message----- > > From: address-policy-wg-admin at ripe.net > > [mailto:address-policy-wg-admin at ripe.net] On Behalf Of David Conrad > > Sent: L-Erbg??a, 7 ta' ? unju 2006 21:54 > > To: jordi.palet at consulintel.es > > Cc: address-policy-wg at ripe.net > > Subject: Re: [address-policy-wg] Re: [policy-announce] > > 2006-02 New Policy Proposal (IPv6 Address Allocation and > > Assignment Policy) > > > > Jordi, > > > > Unlurking from the sidelines and speaking only for myself, > > some comments on your proposal: > > > > > It is clear that there are small Internet Service providers (ISPs) > > > that do not currently have 200 customers, consequently is > > not feasible > > > for them to make ???at least 200 /48??? assignments in two > > years. It is, > > > however, unfair that these ISPs have no access to > > > IPv6 address space. > > > > I'm confused. According to RIPE-267 (section 5.1.1), the > > existing policy doesn't require requesters to have 200 > > customers. All that it requires is that an LIR not be an end > > site, provide IPv6 connectivity, and "have a plan for making > > at least 200 /48 assignments to other organisations within two years." > > > > Note it says "a plan". An organization incapable of coming > > up with _a plan_ to allocate 200 /48s has more significant > > problems than not having IPv6 space. > > > > > In some cases, organisations may have a small number of sites, but > > > still need their own block so that they can avoid future > > renumbering, > > > if they change their upstream provider or identify a need to become > > > Multihomed. > > > > Can you identify an organization that does not want to avoid > > renumbering or which might not identify a need to be multihomed? > > > > > b) plan to provide IPv6 connectivity to other organisations > > or to its > > > own/related departments/entities/sites to which it will > > assign / 48s > > > by advertising that connectivity through a single > > aggregated address > > > allocation > > > > > > and > > > c) have a plan for making a reasonable number of /48 assignments > > > within two years > > > > I have a couple of LANs at my house. A /48 for each LAN > > sounds reasonable to me. Does that justify an IPv6 /32? > > > > More seriously, impositions of subjective evaluations like > > figuring out what is "reasonable" are generally things to be > > avoided. Also, vagueness of terms such as "own/related > > departments/entities/sites" > > are just begging for abuse. A person is an entity. Should > > an organization with a "reasonable" number of people justify a /32? > > > > > a. Arguments Supporting the Proposal > > ... > > > The difficulty encountered in receiving IPv6 address space > > by some big > > > entities that have a need to use IPv6 is a clear barrier for its > > > deployment. > > > > The lack of transparent renumbering, scalable multi-homing, or IPv6- > > only applications is a much more significant barrier to deployment. > > You are attempting to fix a technology problem by hacking > > policy in a way that would exacerbate the technology problem. > > This seems suboptimal to me. But that's probably just me. > > > > > By setting up this policy, we would avoid creating an > > unfair situation > > > among different RIR service regions. Other RIRs have > > already modified > > > the original IPv6 common policy to avoid these barriers. > > > > http://www.bumperart.com/ProductDetails.aspx? > > SKU=2004011203&productID=523 > > > > > We could possibly say that an arbitrary number of sites in order to > > > qualify for an allocation could be considered illegal in some > > > countries. The RIPE community cannot set policies that could prove > > > unlawful as this could have important implications. > > > > If you have documentary proof of potential illegality, it > > would probably be worthwhile to provide it. If not, this > > sentence is merely FUD and should be stricken. Even if you > > do have evidence that some country's law is being broken, it > > isn't clear to me how that should affect RIPE policy. For > > example, I believe a country in the RIPE region has passed a > > law (or is in the process of passing a law) that requires IP > > address space to be allocated by that country's government. > > Should RIPE therefore only allocate address space to governments? > > > > > b. Arguments Opposing the Proposal > > > > > > One possible effect of this proposal would be a growth of global > > > routing tables. This is only to be expected when new > > allocations are > > > made possible under this proposal. > > > > Too simplistic. This proposal, like all PI oriented > > allocation policies, changes routing scalability from > > O(number of service > > providers) to O(number of organizations). Pretending this is > > "only to be expected" is simply wrong. You can argue that > > technology will permit O(number of organizations) in the > > default free routing system, but that is a different argument > > than "it is to be expected". > > > > > Opposing arguments should avoid being unfair to smaller ISPs that > > > could not justify a fixed number of assignments. > > > > Is it unfair that carriers that fly Boeing 747s get more > > revenues than carriers that fly Saab 340s? > > > > A fixed number of assignments was an attempt to quantify a > > "reasonable" level of aggregation. Given the routing > > technology used in IPv6 depends on aggregatability to scale, > > there is an implicit assumption that those who cannot provide > > aggregation of leaves should themselves become a leaf under > > some other aggregator. > > > > > Such a policy could be seen as irrational > > > > "In an insane world the sane man must appear insane" -- Spock > > > > > and might be comparable with imposing a similar requirement for > > > IPv4 address space allocations, which the community would > > be unlikely > > > to accept. > > > > In at least one region, initial allocations of PI IPv4 > > required demonstration of utilization of half the initial PI > > allocation, so in essence, there was an implicit requirement > > to meet a fixed number to justify an allocation. Of course, > > this wasn't in the RIPE region, but weren't you the one > > arguing that the other regions have a similar policy to what > > you propose as justification for your proposal? > > > > Rgds, > > -drc > > > > -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Obediance 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 stefan.camilleri at maltanet.net Mon Jun 12 08:57:13 2006 From: stefan.camilleri at maltanet.net (Stefan Camilleri) Date: Mon, 12 Jun 2006 08:57:13 +0200 Subject: [address-policy-wg] Re: [policy-announce] 2006-02 New Policy Proposal (IPv6 Address Allocation and Assignment Policy) In-Reply-To: <21554F86-D97B-4298-A689-51D3BF938A2F@icann.org> Message-ID: <00c101c68ded$6f45f8a0$2200a8c0@streamoffice.datastream.com.mt> > > It seems that a number of people at the helm of the > Internet decision > > process need some exposure to realities of the ISP business > and more > > specifically to the issues related to the introduction of IPv6. > > In the context of IP address policies, you, as part of the > RIPE community, are the one "at the helm of the Internet > decision process" > -- it is you and the rest of the RIPE community that are > creating the policies. If you need more exposure to reality... :-) > Hence my submissions in this forum. Us small fry rarely get the chance to globe trot to the various voting events! > > We have over /17 of IPv4 address space allocated. We have > over 20,000 > > broadband customers and well over 200 clients that would > benefit from > > Ipv6 assignments and who now either have a /24 to /28 or > use NAT. We > > also operate a small transit network and are linked to a major > > European Tier1 provider. Finally we are part of an Ipv6 task force > > trying to determine the future direction of IPv6 rollout. But > > basically I CANNOT have a plan, at this stage for /48 on > Ipv6. Its WAY > > too early. On the other hand we are upgrading our kit as > part of the > > normal hardware lifetime updates and we consider this the > right time > > to go for Ipv6 peering. Like Tim in his submission I could > EASILY put > > a plan together contradicting my current reality... But why > should I > > lie to RIPE? > > You shouldn't. Just to be clear, you are saying you cannot > come up with plans that you believe represents a reasonable > approximation to what you believe your IPv6 needs will be for > your customers _in two years_? > > When do you expect to provide v6 services to your customers? Bottom line is I do not know. My customers have not yet requested it so how can I plan for any numbers. Plus not all my network components are yet up to a fully fledge rollout. For sure, however I'll have zero IPv6 networks unless I have some sort of fantasy plan for 200 /48's (and who came up with this /48 assinment chunk anyway???) > > And one final thing, we're talking about IPv6. > > Actually, since IPv6 followed IPv4's mistake of co-mingling > location with identity, we're really talking about routing > scalability. Since > IPv6 uses the exact same routing technology as IPv4, it isn't > too surprising that the same problems that we're experiencing > in IPv4 reoccur with IPv6. > > > The addressing space that can allow 2000 addresses per > square meter on > > the planet as some of the current cliches go... > > This piece of misinformation is probably among the most damaging the > IPv6 community has inflicted on itself. While theoretically > true in the pedantic sense, in reality it is pure > misdirection and completely irrelevant. I agree here. There is a lot of misinformation and silly cliches doing the rounds. However one thing is certainly true. With some reasonable policies in place there is room for everyone without fragmenting routing space and with practically little to no one needing to ever apply for a /32 allocation within lifetimes. That is .... if the /48 and /64 assignment policies can ever be re-written. > > We're established and qualified in the business but I have to beg, > > grovel or lie to get this allocation!! > > Dramatic, but I suspect a bit of hyperbole. > > I'm honestly curious: have you applied to RIPE for IPv6 > address space and been rejected? Glad you've got the point ;-) .. And yes, I did apply and yes I was rejected. > > > THAT is confusing > > If it is confusing, it is probably because you've drunk the > IPv6 Forum cool aid. IPv6 did not address (pun intended) the > routing scalability issue. As such, the same constraints > that impact address usage (note: not address availability) in > IPv4 apply to IPv6. What is confusing to me is that network > operators of today seem so eager to recreate the problems > that nearly caused the Internet to break in the mid-nineties. > However, the nice thing about history repeating itself is > that you know what to expect... Funny but in my ignorance I am unaware of IPv6 Forum cool aid or whatever ... Where was routing scalability not addressed may I ask. > Rgds, > -drc > From dogwallah at gmail.com Mon Jun 12 15:24:59 2006 From: dogwallah at gmail.com (McTim) Date: Mon, 12 Jun 2006 16:24:59 +0300 Subject: [address-policy-wg] Re: [policy-announce] 2006-02 New Policy Proposal (IPv6 Address Allocation and Assignment Policy) In-Reply-To: <00c101c68ded$6f45f8a0$2200a8c0@streamoffice.datastream.com.mt> References: <21554F86-D97B-4298-A689-51D3BF938A2F@icann.org> <00c101c68ded$6f45f8a0$2200a8c0@streamoffice.datastream.com.mt> Message-ID: On 6/12/06, Stefan Camilleri wrote: > some sort of fantasy plan for 200 /48's (and who came up with this /48 assinment > chunk anyway???) These are IETF recommendations IIRC. > > Funny but in my ignorance I am unaware of IPv6 Forum cool aid or whatever ... > Where was routing scalability not addressed may I ask. IETF set the above recomendations for the reasons of aggregation (and hence routing scalability). -- Cheers, McTim $ whois -h whois.afrinic.net mctim From stefan.camilleri at maltanet.net Mon Jun 12 15:35:53 2006 From: stefan.camilleri at maltanet.net (Stefan Camilleri) Date: Mon, 12 Jun 2006 15:35:53 +0200 Subject: [address-policy-wg] Re: [policy-announce] 2006-02 New Policy Proposal (IPv6 Address Allocation and Assignment Policy) In-Reply-To: Message-ID: <001d01c68e25$20a42400$2200a8c0@streamoffice.datastream.com.mt> Thanks... Twas a tounge in cheek comment on me part! :-)) And in fact Still, I fail to see the logic of /48 and /64 (obviously aggreagation was behind this but why these numbers).. Though that's outside the scope of this thread. S > -----Original Message----- > From: McTim [mailto:dogwallah at gmail.com] > Sent: It-Tnejn, 12 ta' ?unju 2006 15:25 > To: Stephen Camilleri > Cc: David Conrad; address-policy-wg at ripe.net > Subject: Re: [address-policy-wg] Re: [policy-announce] > 2006-02 New Policy Proposal (IPv6 Address Allocation and > Assignment Policy) > > On 6/12/06, Stefan Camilleri wrote: > > > > some sort of fantasy plan for 200 /48's (and who came up > with this /48 > > assinment chunk anyway???) > > These are IETF recommendations IIRC. > > > > > > Funny but in my ignorance I am unaware of IPv6 Forum cool > aid or whatever ... > > Where was routing scalability not addressed may I ask. > > IETF set the above recomendations for the reasons of > aggregation (and hence routing scalability). > > -- > Cheers, > > McTim > $ whois -h whois.afrinic.net mctim > From david.conrad at icann.org Mon Jun 12 17:59:42 2006 From: david.conrad at icann.org (David Conrad) Date: Mon, 12 Jun 2006 08:59:42 -0700 Subject: [address-policy-wg] Re: [policy-announce] 2006-02 New Policy Proposal (IPv6 Address Allocation and Assignment Policy) In-Reply-To: <00c101c68ded$6f45f8a0$2200a8c0@streamoffice.datastream.com.mt> References: <00c101c68ded$6f45f8a0$2200a8c0@streamoffice.datastream.com.mt> Message-ID: <3E0D3980-134B-46E1-9B02-713F2F3416A4@icann.org> Stefan, On Jun 11, 2006, at 11:57 PM, Stefan Camilleri wrote: > Hence my submissions in this forum. Us small fry rarely get the > chance to globe > trot to the various voting events! RIPE-NCC uses in-person voting to determine policies? >> When do you expect to provide v6 services to your customers? > Bottom line is I do not know. Remember, the world ends on Dec 21, 2012 (according to the Mayans and Geoff Huston). Presumably, you'll want to begin offering v6 service sometime before that... > My customers have not yet requested it so how can > I plan for any numbers. It is called "marketing projections". > Plus not all my network components are yet up to a fully > fledge rollout. For sure, however I'll have zero IPv6 networks > unless I have > some sort of fantasy plan for 200 /48's I guess I don't see the big deal in coming up with a plan. If, by some chance, you don't meet the plan you specify, you can simply return the v6 space you were allocated, no? If you have allocated address space to customers, I would imagine RIPE-NCC could be convinced to give you a bit of extra time. (Perhaps that's a good place for policy revision?) > (and who came up with this /48 assinment chunk anyway???) The same folks who brought you a maximum of 4096 entries in the default-free zone. > With some reasonable policies in > place there is room for everyone without fragmenting routing space Fragmentation of the routing space occurs for two major reasons: multiple allocations from RIRs and traffic engineering. While the RIRs have some control over the first, it is the ISPs that are in control of the second. To date, there are quite a few more specifics announced in IPv4. Since IPv6 doesn't provide any additional mechanisms for TE, why wouldn't more specifics be announced in IPv6? > and with > practically little to no one needing to ever apply for a /32 > allocation within > lifetimes. You are aware, of course, that /19s and /20s of IPv6 address space have already been allocated, right? It'll be interesting to see how many more specifics get announced out of those allocations... > That is .... if the /48 and /64 assignment policies can ever be > re-written. That's a different policy proposal. >> I'm honestly curious: have you applied to RIPE for IPv6 >> address space and been rejected? > Glad you've got the point ;-) .. And yes, I did apply and yes I was > rejected. Fascinating. > Where was routing scalability not addressed may I ask. Despite promises to the contrary, the IPng working group. Rgds, -drc From david.conrad at icann.org Mon Jun 12 17:59:42 2006 From: david.conrad at icann.org (David Conrad) Date: Mon, 12 Jun 2006 08:59:42 -0700 Subject: [address-policy-wg] Re: [policy-announce] 2006-02 New Policy Proposal (IPv6 Address Allocation and Assignment Policy) In-Reply-To: <00c101c68ded$6f45f8a0$2200a8c0@streamoffice.datastream.com.mt> References: <00c101c68ded$6f45f8a0$2200a8c0@streamoffice.datastream.com.mt> Message-ID: <3E0D3980-134B-46E1-9B02-713F2F3416A4@icann.org> Stefan, On Jun 11, 2006, at 11:57 PM, Stefan Camilleri wrote: > Hence my submissions in this forum. Us small fry rarely get the > chance to globe > trot to the various voting events! RIPE-NCC uses in-person voting to determine policies? >> When do you expect to provide v6 services to your customers? > Bottom line is I do not know. Remember, the world ends on Dec 21, 2012 (according to the Mayans and Geoff Huston). Presumably, you'll want to begin offering v6 service sometime before that... > My customers have not yet requested it so how can > I plan for any numbers. It is called "marketing projections". > Plus not all my network components are yet up to a fully > fledge rollout. For sure, however I'll have zero IPv6 networks > unless I have > some sort of fantasy plan for 200 /48's I guess I don't see the big deal in coming up with a plan. If, by some chance, you don't meet the plan you specify, you can simply return the v6 space you were allocated, no? If you have allocated address space to customers, I would imagine RIPE-NCC could be convinced to give you a bit of extra time. (Perhaps that's a good place for policy revision?) > (and who came up with this /48 assinment chunk anyway???) The same folks who brought you a maximum of 4096 entries in the default-free zone. > With some reasonable policies in > place there is room for everyone without fragmenting routing space Fragmentation of the routing space occurs for two major reasons: multiple allocations from RIRs and traffic engineering. While the RIRs have some control over the first, it is the ISPs that are in control of the second. To date, there are quite a few more specifics announced in IPv4. Since IPv6 doesn't provide any additional mechanisms for TE, why wouldn't more specifics be announced in IPv6? > and with > practically little to no one needing to ever apply for a /32 > allocation within > lifetimes. You are aware, of course, that /19s and /20s of IPv6 address space have already been allocated, right? It'll be interesting to see how many more specifics get announced out of those allocations... > That is .... if the /48 and /64 assignment policies can ever be > re-written. That's a different policy proposal. >> I'm honestly curious: have you applied to RIPE for IPv6 >> address space and been rejected? > Glad you've got the point ;-) .. And yes, I did apply and yes I was > rejected. Fascinating. > Where was routing scalability not addressed may I ask. Despite promises to the contrary, the IPng working group. Rgds, -drc From david.conrad at icann.org Mon Jun 12 18:03:15 2006 From: david.conrad at icann.org (David Conrad) Date: Mon, 12 Jun 2006 09:03:15 -0700 Subject: [address-policy-wg] Re: [policy-announce] 2006-02 New Policy Proposal (IPv6 Address Allocation and Assignment Policy) In-Reply-To: <001d01c68e25$20a42400$2200a8c0@streamoffice.datastream.com.mt> References: <001d01c68e25$20a42400$2200a8c0@streamoffice.datastream.com.mt> Message-ID: > Still, I fail to see the logic of /48 and /64 (obviously > aggreagation was behind this but why these numbers).. Actually, no. I believe: /64 was for stateless autoconfig (EUI-64). /48 was to make it easier for folks to move between ISPs. Since all allocations to end sites would be the same size, all that would need to change would be the upper 48 bits. Rgds, -drc From david.conrad at icann.org Mon Jun 12 18:03:15 2006 From: david.conrad at icann.org (David Conrad) Date: Mon, 12 Jun 2006 09:03:15 -0700 Subject: [address-policy-wg] Re: [policy-announce] 2006-02 New Policy Proposal (IPv6 Address Allocation and Assignment Policy) In-Reply-To: <001d01c68e25$20a42400$2200a8c0@streamoffice.datastream.com.mt> References: <001d01c68e25$20a42400$2200a8c0@streamoffice.datastream.com.mt> Message-ID: > Still, I fail to see the logic of /48 and /64 (obviously > aggreagation was behind this but why these numbers).. Actually, no. I believe: /64 was for stateless autoconfig (EUI-64). /48 was to make it easier for folks to move between ISPs. Since all allocations to end sites would be the same size, all that would need to change would be the upper 48 bits. Rgds, -drc From Michael.Dillon at btradianz.com Tue Jun 13 15:29:51 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Tue, 13 Jun 2006 14:29:51 +0100 Subject: [address-policy-wg] Re: [policy-announce] 2006-02 New Policy Proposal (IPv6 Address Allocation and Assignment Policy) In-Reply-To: Message-ID: > /64 was for stateless autoconfig (EUI-64). > /48 was to make it easier for folks to move between ISPs. Since all > allocations to end sites would be the same size, all that would need > to change would be the upper 48 bits. In particular, this means that moving between ISPs does not require you to change your internal network topology. Since topology changes can involve a lot of equipment purchase and rewiring, this levels the competitive field for IPv6 access services. You can design your network with the future in mind and then grow into your topology. That is not possible in today's IPv4 world where everybody is concerned with not wasting addresses. --Michael Dillon From leo at ripe.net Tue Jun 13 16:02:24 2006 From: leo at ripe.net (leo vegoda) Date: Tue, 13 Jun 2006 16:02:24 +0200 Subject: [address-policy-wg] Re: [policy-announce] 2006-02 New Policy Proposal (IPv6 Address Allocation and Assignment Policy) In-Reply-To: References: Message-ID: <448EC570.3030701@ripe.net> Michael, Michael.Dillon at btradianz.com wrote: >> /64 was for stateless autoconfig (EUI-64). >> /48 was to make it easier for folks to move between ISPs. Since all >> allocations to end sites would be the same size, all that would need >> to change would be the upper 48 bits. > > In particular, this means that moving between > ISPs does not require you to change your internal > network topology. Since topology changes can > involve a lot of equipment purchase and rewiring, > this levels the competitive field for IPv6 access > services. You can design your network with the > future in mind and then grow into your topology. > That is not possible in today's IPv4 world where > everybody is concerned with not wasting addresses. I think it's worth clarifying that RIPE's IPv4 policy specifically states that one-to-one renumbering for valid assignments are fine. The relevant text can be found at: http://www.ripe.net/ripe/docs/ipv4-policies.html#assign_renumbering Individual ISPs may choose to be assign addresses in a more conservative way than is strictly required. Regards, -- leo vegoda Registration Services Manager RIPE NCC From Michael.Dillon at btradianz.com Tue Jun 13 16:34:55 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Tue, 13 Jun 2006 15:34:55 +0100 Subject: [address-policy-wg] Re: [policy-announce] 2006-02 New Policy Proposal (IPv6 Address Allocation and Assignment Policy) In-Reply-To: <448EC570.3030701@ripe.net> Message-ID: > >You can design your network with the > > future in mind and then grow into your topology. > > That is not possible in today's IPv4 world where > > everybody is concerned with not wasting addresses. > > I think it's worth clarifying that RIPE's IPv4 policy specifically > states that one-to-one renumbering for valid assignments are fine. I understand that. But in the IPv6 world, if I have a plan to build an organization in 20 countries with 3 regional manufacturing plants, and 35 sales offices, I can build the network topology around that plan, even though I only have 8 employees on the second floor of a former typewriter repair shop. I can size my subnets according to my 10-year plan and my ISP will give me the /48 that I need to make it that way. However, in IPv4 my ISP will not accept the 10-year plan and will not give me 6,000 IPv4 addresses for my factory subnet that currently contains only one server. There is a clear philosophical difference between IPv6 addressing and IPv4 addressing. --Michael Dillon --Michael Dillon From david.conrad at icann.org Tue Jun 13 18:31:46 2006 From: david.conrad at icann.org (David Conrad) Date: Tue, 13 Jun 2006 09:31:46 -0700 Subject: [address-policy-wg] Re: [policy-announce] 2006-02 New Policy Proposal (IPv6 Address Allocation and Assignment Policy) In-Reply-To: <003901c68eb5$b7230c30$2200a8c0@streamoffice.datastream.com.mt> References: <003901c68eb5$b7230c30$2200a8c0@streamoffice.datastream.com.mt> Message-ID: <4E697F8E-EA78-410F-A768-BE3DE42F8FC3@icann.org> Stefan, On Jun 12, 2006, at 11:50 PM, Stefan Camilleri wrote: >>> My customers have not yet requested it so how can I plan for any >>> numbers. >> It is called "marketing projections". > I see. So my hunch was right. Just throw in a bunch of numbers and > keep on kidding ourselves It is possible to come up with reasonable projections of the future. People do it every day in business plans. Marketing projections are not inherently "kidding ourselves". They are merely trying to take an estimation of the market and project it into the future. I believe the "plan" requirement of existing IPv6 policies was intended to take into account the fact that deploying IPv6 is an unknown, both in terms of customer uptake and infrastructure requirements. >> If, by some chance, you don't meet the plan you specify, you >> can simply return the v6 space you were allocated, no? If >> you have allocated address space to customers, I would >> imagine RIPE-NCC could be convinced to give you a bit of >> extra time. (Perhaps that's a good place for policy revision?) > Exactly the point. THAT would be an intelligent policy so why all > the fuss about wanting to retain the current policy! This would be a different change than what 2006-02 proposes. > Yes. I was aware of that. Unfortunately IMHO, a bad start in the v6 > allocation process.. But what's done is done. And continues to be done. >>>> I'm honestly curious: have you applied to RIPE for IPv6 address >>>> space >>>> and been rejected? >>> And yes, I did apply and yes I was rejected. >> Fascinating. > Truly awesome ... I'm doing my best to smile :-| Given RIPE-NCC's IPv6 allocation statistics, I got the impression they didn't turn anyone down... :-) Rgds, -drc From leo at ripe.net Tue Jun 13 20:45:29 2006 From: leo at ripe.net (leo vegoda) Date: Tue, 13 Jun 2006 20:45:29 +0200 Subject: [address-policy-wg] Re: [policy-announce] 2006-02 New Policy Proposal (IPv6 Address Allocation and Assignment Policy) In-Reply-To: <4E697F8E-EA78-410F-A768-BE3DE42F8FC3@icann.org> References: <003901c68eb5$b7230c30$2200a8c0@streamoffice.datastream.com.mt> <4E697F8E-EA78-410F-A768-BE3DE42F8FC3@icann.org> Message-ID: <20060613184525.GB31142@ripe.net> Hi David, On Tue, Jun 13, 2006 at 09:31:46AM -0700, David Conrad wrote: [...] > >>>>I'm honestly curious: have you applied to RIPE for IPv6 address > >>>>space > >>>>and been rejected? > >>>And yes, I did apply and yes I was rejected. > >>Fascinating. > >Truly awesome ... I'm doing my best to smile :-| > > Given RIPE-NCC's IPv6 allocation statistics, I got the impression > they didn't turn anyone down... > :-) The vast majority of requests meet the requirements set out in the policy. That number isn't quite 100%, though. A while back we were asked for some statistics on the number of IPv6 related requests we receive and the proportion that did not result in resources being issued. About 2% of requests did not result in an IPv6 allocation or assignment because the requester was unable to meet the requirements defined in the policy. Of those 2%, slightly more than 1% were unable to meet the requirement for a plan to assign 200 or more /48s within two years. You can find the slides on our web site at: http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50-ap-ipv6numbers.pdf and there are video archives of the session available at: mms://webcast.ripe.net/ripe-50/address-policy-1.wmv and here: http://www.ripe.net/ripe/meetings/ripe-50/webcast-files/ap.wmv Regards, -- leo vegoda RIPE NCC Registration Services Manager From stefan.camilleri at maltanet.net Tue Jun 13 08:50:53 2006 From: stefan.camilleri at maltanet.net (Stefan Camilleri) Date: Tue, 13 Jun 2006 08:50:53 +0200 Subject: [address-policy-wg] Re: [policy-announce] 2006-02 New Policy Proposal (IPv6 Address Allocation and Assignment Policy) In-Reply-To: <3E0D3980-134B-46E1-9B02-713F2F3416A4@icann.org> Message-ID: <003901c68eb5$b7230c30$2200a8c0@streamoffice.datastream.com.mt> > -----Original Message----- > From: David Conrad [mailto:david.conrad at icann.org] > Sent: It-Tnejn, 12 ta' ?unju 2006 18:00 > To: Stephen Camilleri > Cc: address-policy-wg at ripe.net > Subject: Re: [address-policy-wg] Re: [policy-announce] > 2006-02 New Policy Proposal (IPv6 Address Allocation and > Assignment Policy) > > Stefan, > > On Jun 11, 2006, at 11:57 PM, Stefan Camilleri wrote: > > Hence my submissions in this forum. Us small fry rarely get > the chance > > to globe trot to the various voting events! > > RIPE-NCC uses in-person voting to determine policies? Thanks for that. It does not seem well advertised but that's my problem I guess. I'll keep an eye open on this. > >> When do you expect to provide v6 services to your customers? > > Bottom line is I do not know. > > Remember, the world ends on Dec 21, 2012 (according to the > Mayans and Geoff Huston). Presumably, you'll want to begin > offering v6 service sometime before that... > I got a different date on that even though RIPE policies permitting I'd still want to offer v6 within less than 4 years. > > My customers have not yet requested it so how can I plan for any > > numbers. > > It is called "marketing projections". I see. So my hunch was right. Just throw in a bunch of numbers and keep on kidding ourselves > > Plus not all my network components are yet up to a fully fledge > > rollout. For sure, however I'll have zero IPv6 networks > unless I have > > some sort of fantasy plan for 200 /48's. > I guess I don't see the big deal in coming up with a plan. > If, by some chance, you don't meet the plan you specify, you > can simply return the v6 space you were allocated, no? If > you have allocated address space to customers, I would > imagine RIPE-NCC could be convinced to give you a bit of > extra time. (Perhaps that's a good place for policy revision?) > Exactly the point. THAT would be an intelligent policy so why all the fuss about wanting to retain the current policy! > > (and who came up with this /48 assinment chunk anyway???) > > The same folks who brought you a maximum of 4096 entries in > the default-free zone. > > > With some reasonable policies in > > place there is room for everyone without fragmenting routing space > > Fragmentation of the routing space occurs for two major reasons: > multiple allocations from RIRs and traffic engineering. > While the RIRs have some control over the first, it is the > ISPs that are in control of the second. To date, there are > quite a few more specifics announced in IPv4. Since IPv6 > doesn't provide any additional mechanisms for TE, why > wouldn't more specifics be announced in IPv6? > > > and with > > practically little to no one needing to ever apply for a /32 > > allocation within lifetimes. > > You are aware, of course, that /19s and /20s of IPv6 address > space have already been allocated, right? It'll be > interesting to see how many more specifics get announced out > of those allocations... Yes. I was aware of that. Unfortunately IMHO, a bad start in the v6 allocation process.. But what's done is done. > > > That is .... if the /48 and /64 assignment policies can ever be > > re-written. > > That's a different policy proposal. > > >> I'm honestly curious: have you applied to RIPE for IPv6 > address space > >> and been rejected? > > Glad you've got the point ;-) .. And yes, I did apply and yes I was > > rejected. > > Fascinating. Truly awesome ... I'm doing my best to smile :-| > > Where was routing scalability not addressed may I ask. > > Despite promises to the contrary, the IPng working group. > > Rgds, > -drc > From stefan.camilleri at maltanet.net Wed Jun 14 08:55:59 2006 From: stefan.camilleri at maltanet.net (Stefan Camilleri) Date: Wed, 14 Jun 2006 08:55:59 +0200 Subject: [address-policy-wg] Re: [policy-announce] 2006-02 New Policy Proposal (IPv6 Address Allocation and Assignment Policy) In-Reply-To: <4E697F8E-EA78-410F-A768-BE3DE42F8FC3@icann.org> Message-ID: <005501c68f7f$97ae29f0$2200a8c0@streamoffice.datastream.com.mt> Dave, > > On Jun 12, 2006, at 11:50 PM, Stefan Camilleri wrote: > >>> My customers have not yet requested it so how can I plan for any > >>> numbers. > >> It is called "marketing projections". > > I see. So my hunch was right. Just throw in a bunch of numbers and > > keep on kidding ourselves > > It is possible to come up with reasonable projections of the > future. > People do it every day in business plans. Marketing > projections are not inherently "kidding ourselves". They are > merely trying to take an estimation of the market and project > it into the future. I believe the "plan" requirement of > existing IPv6 policies was intended to take into account the > fact that deploying IPv6 is an unknown, both in terms of > customer uptake and infrastructure requirements. I'm well aware of that. That is basically the process when planning for Ipv4. We're constantly doing it in our business. However we get a number of nth order equations to which we often have previous solutions/trends and then extrapolate and make educated guesses based on often proven assumptions. IPv6 allocation is unknown (as you also pointed out). Its an equation with many variables and no known points of reference. That is why trying to put a 'marketing' plan TODAY for 200 /48's within 2 years is kidding ourselves. > >> If, by some chance, you don't meet the plan you specify, you can > >> simply return the v6 space you were allocated, no? If you have > >> allocated address space to customers, I would imagine > RIPE-NCC could > >> be convinced to give you a bit of extra time. (Perhaps > that's a good > >> place for policy revision?) > > Exactly the point. THAT would be an intelligent policy so > why all the > > fuss about wanting to retain the current policy! > > This would be a different change than what 2006-02 proposes. True ... But who in the LIR community will recommend that. ;-) > > > Yes. I was aware of that. Unfortunately IMHO, a bad start in the v6 > > allocation process.. But what's done is done. > > And continues to be done. > > >>>> I'm honestly curious: have you applied to RIPE for IPv6 address > >>>> space and been rejected? > >>> And yes, I did apply and yes I was rejected. > >> Fascinating. > > Truly awesome ... I'm doing my best to smile :-| > > Given RIPE-NCC's IPv6 allocation statistics, I got the > impression they didn't turn anyone down... > :-) Well.. You got example no.1 Maybe the rest dreamt up some plan or other. I'd wait and see in 2 years time how many /48's have really been made. > Rgds, > -drc > From Niall.oReilly at ucd.ie Thu Jun 15 10:30:23 2006 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Thu, 15 Jun 2006 09:30:23 +0100 Subject: [address-policy-wg] Comments on 2006-01 (IPv6 Address Allocation and Assignment Policy) In-Reply-To: <1149863266.19493.110.camel@pancake.netability.ie> References: <200606090805.52649.marc.van.selm@nc3a.nato.int> <1149845880.16953.263434545@webmail.messagingengine.com> <1149863266.19493.110.camel@pancake.netability.ie> Message-ID: On 9 Jun 2006, at 15:27, Nick Hilliard wrote: > I do not support the current policy proposal 2006-01 (v2.0) as it > stands, although it could be fixed to make it more palatable. > > The primary problem is the implicit fixed lifetime of the address > space > assignment for those organisations who require PI6 space but who > have no > particular reason to eventually become a LIR. A LIR has significant > requirements in terms of administration, and it does not seem > reasonable > to me to encumber those organisations who have a simple requirement > for > portable address space with the choice of either becoming a LIR or > being > forced to renumber. This makes the proposal unpalatable. > > I would be more inclined to support a scenario where the PI6 space > assignment is permanent but contingent on a simpler contractual > relationship with the RIR, and where that contractual relationship > does > not force the assignee to become a LIR at some arbitrary point in the > future. Nick, I think you're missing the opportunity to read 2006-01 as meaning "PI6 space IS permanent UNTIL we discover and agree the better way, at which point holders of PI6 space have 36 months to adopt the new best practice". I don't see an "implicit fixed lifetime" here, but a committed lifetime to some point beyond our current horizon. Is that SO unpalatable? Beir bua! /Niall From Michael.Dillon at btradianz.com Thu Jun 15 12:31:54 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Thu, 15 Jun 2006 11:31:54 +0100 Subject: [address-policy-wg] Re: [policy-announce] 2006-02 New Policy Proposal (IPv6 Address Allocation and Assignment Policy) In-Reply-To: <005501c68f7f$97ae29f0$2200a8c0@streamoffice.datastream.com.mt> Message-ID: > That is why trying to put a 'marketing' plan TODAY > for 200 /48's within 2 years is kidding ourselves. No, it's kidding RIPE. And since that is exactly what RIPE asked for in their policy, go do it, get your IPv6 allocation, and quit complaining about your inability to write an accurate plan. The policy document does not specify that your plan will be checked for accuracy after 2 years. Still, I don't see why there needs to be any limits at all or any specific numbers in a plan. If someone wants to become an IPv6 LIR, just give them a /32 with no questions asked. RIPE should only need to scrutinize requests for shorter prefixes. --Michael Dillon From randy at psg.com Thu Jun 15 13:37:02 2006 From: randy at psg.com (Randy Bush) Date: Thu, 15 Jun 2006 04:37:02 -0700 Subject: [address-policy-wg] Comments on 2006-01 (IPv6 Address Allocation and Assignment Policy) References: <200606090805.52649.marc.van.selm@nc3a.nato.int> <1149845880.16953.263434545@webmail.messagingengine.com> <1149863266.19493.110.camel@pancake.netability.ie> Message-ID: <17553.18014.885621.898414@roam.psg.com> > I think you're missing the opportunity to read 2006-01 as meaning > "PI6 space IS permanent UNTIL we discover and agree the better way, > at which point holders of PI6 space have 36 months to adopt the new > best practice". > > I don't see an "implicit fixed lifetime" here, but a committed lifetime > to some point beyond our current horizon. how is this unlike the current swamp, other than it being potentially a *lot* larger? randy From Michael.Dillon at btradianz.com Thu Jun 15 16:02:11 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Thu, 15 Jun 2006 15:02:11 +0100 Subject: [address-policy-wg] Re: [policy-announce] 2006-02 New Policy Proposal (IPv6 Address Allocation and Assignment Policy) In-Reply-To: <00ec01c69074$63376a60$2200a8c0@streamoffice.datastream.com.mt> Message-ID: > Oh I could do that. But then... What the hell are policies for > anyway! That's the scope of this thread really. Policies are, or > should be, a good thing. Otherwise they are just a bad joke. Is that > what RIRs want? Fine. Policies are only as good as the people who write them. Since people are flawed, policies will also be flawed. But if there is a good process for changing policies when flaws are noticed, then we can muddle through the flaws. I think RIPE does have a good process for changing policies. However, the policy in effect today is the one that we must follow, even though it has flaws. So instead of complaining about the flaws, work with them. Write a plan to assign 200 /48s within the next two years and get your /32. If there is ever a new policy that allows you to go to RIPE for a small PI block, then you can always hand back the /32 and renumber. Since IPv6 policy allows for all end-sites to use a /48, it should be very easy to renumber. And since we are a long, long way from a shortage of IPv6 addresses, if you need to keep both old and new addresses active for a couple of years, there is no problem. IPv6 is happy to use two different addresses for every interface. --Michael Dillon P.S. I think it is a good idea to have a formal policy to give people PI blocks smaller than a /32 prefix. --Michael Dillon From Michael.Dillon at btradianz.com Thu Jun 15 16:14:50 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Thu, 15 Jun 2006 15:14:50 +0100 Subject: [address-policy-wg] Comments on 2006-01 (IPv6 Address Allocation and Assignment Policy) In-Reply-To: <17553.18014.885621.898414@roam.psg.com> Message-ID: > > I don't see an "implicit fixed lifetime" here, but a committed lifetime > > to some point beyond our current horizon. > > how is this unlike the current swamp, other than it being potentially > a *lot* larger? The current swamp is a block of allocations where the users have no formal agreement with any RIR. All IPv6 blocks are issued with a formal RIR agreement. The current swamp is a block in which a single organization often holds several routable prefixes, i.e. a small ISP asked for 2 class C's and received 2 non-aggregatable /24's. Most large users of IPv6 will receive only a single routable prefix and most PI IPv6 allocations, though smaller, will also be a single routable prefix. The current swamp is a block in which the allocations are not structured according to network topology. All IPv6 blocks are structured, at the highest level, according to continental-scale areas. At a more detailed level, PI blocks smaller than a /32, could be allocated according to some kind of topological addressing plan. For instance, RIPE could have a Scandinavia aggregate, CIS aggregate, Central aggregate (FR, DE, BE, CH, NL, PL, AT), Western aggregate (UK, IE, ES, PT) and Southeast aggregate (Ex-Yugoslavia, GR, TR, IL). There are plenty of grey areas when deciding which agreggate someone belongs in but the best way to handle it is not to draw lines on a map, but to ask the applicant where the bulk of their traffic will go and give them addresses from that aggregate. We are not doomed to repeat the swamp and we already have managed to avoid repeating some of the biggest problems that led to the creation of the swamp. --Michael Dillon P.S. the best way to deal with the bogeymen is to shed some light on the situation. From tim.streater at dante.org.uk Thu Jun 15 17:09:22 2006 From: tim.streater at dante.org.uk (Tim Streater) Date: Thu, 15 Jun 2006 16:09:22 +0100 Subject: [address-policy-wg] Comments on 2006-01 (IPv6 Address Allocation and Assignment Policy) In-Reply-To: References: <17553.18014.885621.898414@roam.psg.com> Message-ID: <7.0.1.0.0.20060615160304.046d7cb8@dante.org.uk> At 15:14 15/06/2006, Michael.Dillon at btradianz.com wrote: >The current swamp is a block in which the allocations >are not structured according to network topology. All >IPv6 blocks are structured, at the highest level, according >to continental-scale areas. At a more detailed level, >PI blocks smaller than a /32, could be allocated >according to some kind of topological addressing plan. >For instance, RIPE could have a Scandinavia aggregate, >CIS aggregate, Central aggregate (FR, DE, BE, CH, NL, PL, AT), >Western aggregate (UK, IE, ES, PT) and Southeast aggregate >(Ex-Yugoslavia, GR, TR, IL). We have one router in almost every country you listed and some you haven't, all within Europe. Do we get 5 /32 then? In addition, one of the networks we manage which also covers a large area is planned to be handed off to its own managing entity, complete with the infrastructure. So we'd like PI v6 space please to address it. And for it and our primary network we plan to allocate 0 addresses to 0 customers for the next 2, 10, 20, infinity years. -- Tim From stefan.camilleri at maltanet.net Thu Jun 15 14:08:18 2006 From: stefan.camilleri at maltanet.net (Stefan Camilleri) Date: Thu, 15 Jun 2006 14:08:18 +0200 Subject: [address-policy-wg] Re: [policy-announce] 2006-02 New Policy Proposal (IPv6 Address Allocation and Assignment Policy) In-Reply-To: Message-ID: <00ec01c69074$63376a60$2200a8c0@streamoffice.datastream.com.mt> Oh I could do that. But then... What the hell are policies for anyway! That's the scope of this thread really. Policies are, or should be, a good thing. Otherwise they are just a bad joke. Is that what RIRs want? Fine. Stefan > -----Original Message----- > From: address-policy-wg-admin at ripe.net > [mailto:address-policy-wg-admin at ripe.net] On Behalf Of > Michael.Dillon at btradianz.com > Sent: Il-?amis, 15 ta' ?unju 2006 12:32 > To: address-policy-wg at ripe.net > Subject: RE: [address-policy-wg] Re: [policy-announce] > 2006-02 New Policy Proposal (IPv6 Address Allocation and > Assignment Policy) > > > That is why trying to put a 'marketing' plan TODAY for 200 /48's > > within 2 years is kidding ourselves. > > No, it's kidding RIPE. And since that is exactly what RIPE > asked for in their policy, go do it, get your IPv6 > allocation, and quit complaining about your inability to > write an accurate plan. The policy document does not specify > that your plan will be checked for accuracy after 2 years. > > Still, I don't see why there needs to be any limits at all or > any specific numbers in a plan. > If someone wants to become an IPv6 LIR, just give them a /32 > with no questions asked. RIPE should only need to scrutinize > requests for shorter prefixes. > > --Michael Dillon > From Michael.Dillon at btradianz.com Fri Jun 16 12:00:05 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Fri, 16 Jun 2006 11:00:05 +0100 Subject: [address-policy-wg] Comments on 2006-01 (IPv6 Address Allocation and Assignment Policy) In-Reply-To: <7.0.1.0.0.20060615160304.046d7cb8@dante.org.uk> Message-ID: > >The current swamp is a block in which the allocations > >are not structured according to network topology. All > >IPv6 blocks are structured, at the highest level, according > >to continental-scale areas. At a more detailed level, > >PI blocks smaller than a /32, could be allocated > >according to some kind of topological addressing plan. > >For instance, RIPE could have a Scandinavia aggregate, > >CIS aggregate, Central aggregate (FR, DE, BE, CH, NL, PL, AT), > >Western aggregate (UK, IE, ES, PT) and Southeast aggregate > >(Ex-Yugoslavia, GR, TR, IL). > > We have one router in almost every country you listed and some you > haven't, all within Europe. Do we get 5 /32 then? If you are an LIR then you get one /32. If a future PI IPv6 policy hands out allocations I suspect they will be considerably smaller than a /32. Maybe /48 or maybe a few of them. You will you have to justify the size of the PI allocation and if RIPE did manage the PI addressing out of several regional aggregates, then you could ask them for 5 different regional /48s. > In addition, one of the networks we manage which also covers a large > area is planned to be handed off to its own managing entity, > complete with the infrastructure. So we'd like PI v6 space please to > address it. Normally, if you are an LIR, you would build this network and assign a /48 per end-site. Then, when the other entity takes control, they could decide to leave it that way or to change ISPs and readdress or to apply to RIPE for a PI allocation. > And for it and our primary network we plan > to allocate 0 addresses to 0 customers for the next 2, 10, 20, infinity years. Yes, when I worked for Ebone we did the same thing until we started selling some end-user Internet access in 2000. A company which sells managed VPN services to clients in which they own the routers and firewalls on the client sites and use NAT exclusively one the CPE routers, is in the same position. Technically, they only assign addresses to themselves for the CPE devices which they own and the NAT pools in those devices. In the IPv6 world, I expect NAT to continue to be used in such scenarios only it will be pure NAT without any port-mapping magic. I agree that the policy around 200 assignments is flawed and should be changed. But if people need addresses today, they need to work with that flawed policy and make a plan to fit it. --Michael Dillon From Michael.Dillon at btradianz.com Fri Jun 16 12:13:59 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Fri, 16 Jun 2006 11:13:59 +0100 Subject: [address-policy-wg] Re: [policy-announce] 2006-02 New Policy Proposal (IPv6 Address Allocation and Assignment Policy) In-Reply-To: <00ec01c69074$63376a60$2200a8c0@streamoffice.datastream.com.mt> Message-ID: > Oh I could do that. But then... What the hell are policies for > anyway! That's the scope of this thread really. Policies are there to guide RIPE members and RIPE NCC employees. If you read RIPE-267 it says: d) have a plan for making at least 200 /48 assignments to other organisations within two years. It doesn't say that you follow the plan exactly or the addresses will be taken away. It does not say that you forever give up your rights to change your plans. It does not say that the plan must be accomplished without setting up new business units. It does not require you to spend a specific amount of money implementing your plan. It does not tell you that you must have assigned 100 of those /48s by the end of the next year. This policy seems to have triggered something in our human psychology because many people in many countries have reacted to this wording like you have. For some reason, almost everyone who reads this policy believes that it contains requirements which are not written there. For that reason alone, it should be changed. Criteria a), b), and c) really are good enough reason to give an IPv6 /32 to an LIR. But, we are talking about 2006-2 which also changes the text of b) and c): a) be an LIR b) plan to provide IPv6 connectivity to other organisations or to its own/related departments/entities/sites to which it will assign /48s by advertising that connectivity through a single aggregated address allocation and c) have a plan for making a reasonable number of /48 assignments within two years It seems like a reasonable change to me. --Michael Dillon From Ian.Meikle at nominet.org.uk Fri Jun 16 13:06:27 2006 From: Ian.Meikle at nominet.org.uk (Ian.Meikle at nominet.org.uk) Date: Fri, 16 Jun 2006 12:06:27 +0100 Subject: [address-policy-wg] Re: [policy-announce] 2006-02 New Policy Proposal (IPv6 Address Allocation and Assignment Policy) In-Reply-To: Message-ID: address-policy-wg-admin at ripe.net wrote on 16/06/2006 11:13:59: > > Oh I could do that. But then... What the hell are policies for > > anyway! That's the scope of this thread really. > > Policies are there to guide RIPE members and RIPE > NCC employees. If you read RIPE-267 it says: > > d) have a plan for making at least 200 /48 > assignments to other organisations within > two years. > > It doesn't say that you follow the plan exactly > or the addresses will be taken away. It does not > say that you forever give up your rights to change > your plans. It does not say that the plan must > be accomplished without setting up new business > units. It does not require you to spend a specific > amount of money implementing your plan. It does not > tell you that you must have assigned 100 of those > /48s by the end of the next year. > > This policy seems to have triggered something in > our human psychology because many people in many > countries have reacted to this wording like you > have. For some reason, almost everyone who reads > this policy believes that it contains requirements > which are not written there. > > For that reason alone, it should be changed. Criteria > a), b), and c) really are good enough reason to give > an IPv6 /32 to an LIR. > > But, we are talking about 2006-2 which also changes > the text of b) and c): > > a) be an LIR > b) plan to provide IPv6 connectivity to other organisations > or to its own/related departments/entities/sites to > which it will assign /48s by advertising that > connectivity through a single aggregated address allocation > I agree wholeheartedly with this change to the wording. The present policy excludes Nominet, which is an Enterprise LIR, from gaining an IPv6 allocation as we have no customers per se. We do have an intention to make our services, including .uk DNS, available over IPv6. > and > > c) have a plan for making a reasonable number of /48 > assignments within two years > This is also better than an arbritrary figure. > It seems like a reasonable change to me. > > --Michael Dillon Ian From stefan.camilleri at maltanet.net Fri Jun 16 14:30:30 2006 From: stefan.camilleri at maltanet.net (Stefan Camilleri) Date: Fri, 16 Jun 2006 14:30:30 +0200 Subject: [address-policy-wg] Re: [policy-announce] 2006-02 New Policy Proposal (IPv6 Address Allocation and Assignment Policy) In-Reply-To: Message-ID: <00f301c69140$a7c3f690$2200a8c0@streamoffice.datastream.com.mt> > -----Original Message----- > From: address-policy-wg-admin at ripe.net > [mailto:address-policy-wg-admin at ripe.net] On Behalf Of > Michael.Dillon at btradianz.com > Sent: Il-?img?a, 16 ta' ?unju 2006 12:14 > To: address-policy-wg at ripe.net > Subject: RE: [address-policy-wg] Re: [policy-announce] > 2006-02 New Policy Proposal (IPv6 Address Allocation and > Assignment Policy) > > > Oh I could do that. But then... What the hell are policies > for anyway! > > That's the scope of this thread really. > > Policies are there to guide RIPE members and RIPE NCC > employees. If you read RIPE-267 it says: > > d) have a plan for making at least 200 /48 > assignments to other organisations within > two years. > > It doesn't say that you follow the plan exactly or the > addresses will be taken away. It does not say that you > forever give up your rights to change your plans. It does not > say that the plan must be accomplished without setting up new > business units. It does not require you to spend a specific > amount of money implementing your plan. It does not tell you > that you must have assigned 100 of those /48s by the end of > the next year. > > This policy seems to have triggered something in our human > psychology because many people in many countries have reacted > to this wording like you have. For some reason, almost > everyone who reads this policy believes that it contains > requirements which are not written there. > > For that reason alone, it should be changed. Criteria a), b), > and c) really are good enough reason to give an IPv6 /32 to an LIR. > > But, we are talking about 2006-2 which also changes the text > of b) and c): > > a) be an LIR > b) plan to provide IPv6 connectivity to other organisations > or to its own/related departments/entities/sites to > which it will assign /48s by advertising that > connectivity through a single aggregated address allocation > > and > > c) have a plan for making a reasonable number of /48 > assignments within two years > > It seems like a reasonable change to me. Excellent... That's the bottom line. So let's change it. What's the use of putting a plan together (I have one ready) whilst knowing full well at the back of one's mind that A) I will be changing these plans B) I have no way to know how I will accomplish this plan C) I have no clue of the amount of money if any I can get approved to allocate towards plan and D) Many of my 'potential' /48 clients are completely as yet unconvinced on the need for v6 That is why I support the text as revised. I could even dare suggest an extra line wherein beneficiaries of /32 should return allocations if unutilised within a term of X years. But that's a different story :) > --Michael Dillon > From dmm at 1-4-5.net Mon Jun 19 17:21:07 2006 From: dmm at 1-4-5.net (David Meyer) Date: Mon, 19 Jun 2006 08:21:07 -0700 Subject: [address-policy-wg] Re: Possible IAB workshop on routing and addressing participants? In-Reply-To: <20060614222106.GA10790@1-4-5.net> References: <20060614222106.GA10790@1-4-5.net> Message-ID: <20060619152107.GB2377@1-4-5.net> [Sorry about the wide distribution/duplicates. Just trying to reach as many of the folks who may be interested as possible --dmm] Folks, The IAB is considering holding a routing and addressing workshop, perhaps in the fall 2006 time frame (see the draft invite below). We're in the process of collecting potential participants, so please pass along any the names of folks that that you think would be productive participants. Thanks, --dmm (for the IAB) ---- Greetings, The IAB is sponsoring a workshop on "Scalable Routing and Addressing Architectures for the Internet" in order to foster interchange between the operator, standards, vendor, and research communities on this important topic. You are being invited to participate in this effort. This workshop effort will consist of mailing list discussions in advance of, and after a face to face meeting. The technical goals of this effort are outlined below. We believe these are the critical elements to fostering a constructive discussion of important routing and addressing technical work going forward and are soliciting workshop participation to work towards those goals. Should you decide to join us in this workshop, you will be expected to attend the face to face meeting [0], contribute to (and possibly present at) that meeting, as well as follow and participate in the mailing list discussions. The most important objective of the workshop is to foster and encourage innovative thinking in an area where there has been little fundamental change for the last twelve years. As such, the primary goals of the workshop include the following two items: (i). Produce a concise problem statement that will serve as the input to future work on this topic. This problem statement will include, among other things, a list of the problems with the current routing and addressing architecture. These include (but are not limited to): - The difficulty in changing provider due to PA/CIDR addressing schemes - The lack of effective multi-homing support - Limited capability to protect against either the spoofing of individual host IP addresses or entire IP address blocks - The limited ability to secure the routing system itself, and (ii). Produce a prioritized list of requirements, all of which must be met by a next generation routing and addressing architecture. A sample list might include (in no particular order): - Retaining the connectionless datagram model of IP routing - Allow users (small and large) to freely switch between providers without substantial service interruption - Include survival of higher-layer connections and associations when connectivity to individual providers changes - Allow both users and ISPs to influence path selection according to traffic management and classification requirements - Provide better support for mobility and nomadicity - Provide architected instrumentation facilities - Allow at least one-to-many multicast - Prevent source address spoofing - Provide a rational economic basis for deployment - Secure the routing infrastructure, including the authentication of updates and the unauthorized injection of information into the routing system - Define scalability requirements for a next generation routing system - Have architected transition mechanisms and be incrementally deployable (where possible) During the workshop, scribes will be assigned to summarize the discussion. Post-workshop, scribes will be expected to participate in finalizing the workshop report. All participants will be expected to review the draft workshop report before publication. The workshop is From iljitsch at muada.com Tue Jun 20 13:48:29 2006 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 20 Jun 2006 13:48:29 +0200 Subject: [address-policy-wg] Re: [policy-announce] 2006-02 New Policy Proposal (IPv6 Address Allocation and Assignment Policy) In-Reply-To: <000b01c68ae6$bb1d5250$2200a8c0@streamoffice.datastream.com.mt> References: <000b01c68ae6$bb1d5250$2200a8c0@streamoffice.datastream.com.mt> Message-ID: On 8-jun-2006, at 12:31, Stefan Camilleri wrote: >> Note it says "a plan". An organization incapable of coming up >> with _a plan_ to allocate 200 /48s has more >> significant problems than not having IPv6 space. [...] > We have over /17 of IPv4 address space allocated. We have over > 20,000 broadband customers and well over 200 clients that would > benefit from Ipv6 assignments and who now either have a /24 to /28 > or use NAT. We also operate a small transit network and are linked > to a major European Tier1 provider. Finally we are part of an Ipv6 > task force trying to determine the future direction of IPv6 > rollout. But basically I CANNOT have a plan, at this stage for /48 > on Ipv6. Its WAY too early. You must have SOME kind of plan if you want to get an IPv6 block in your hands now... This is what I wrote for a customer for their IPv6 request, which was granted without further questions within days: #[REQUIRED INFORMATION]# confirmation: we'll conform to the policy. #[INSERT SUPPLEMENTAL COMMENTS]# We currently have several customers who have asked for IPv6 service. We expect to give out several /48s to colo customers immediately, around 15 within a year and 50 or so within two years. We currently don't have IPv6 capability for our DSL and dial-up infrastructure, but expect to add IPv6 here and start giving out /48s to customers later this year, after we've installed a new router at [...]. We'll then be rolling out IPv6 first to existing customers (25 after a year) but we also expect that we can interest new customers in more advanced capabilities such as IPv6, multicast and IPv6 multicast, reaching the required 200 /48s in the second year. > And one final thing, we're talking about IPv6. The addressing space > that can allow 2000 addresses per square meter on the planet as > some of the current cliches go... We're established and qualified > in the business but I have to beg, grovel or lie to get this > allocation!! THAT is confusing Getting the addresses is not the issue, occupying a slot at the top of the routing hierarchy is. This means you take up an entry in the FIB tables of all IPv6 DFZ routers world wide, which then all have to provide electricity to determine whether the packets flowing through them match your prefix. From stefan.camilleri at maltanet.net Tue Jun 20 16:38:42 2006 From: stefan.camilleri at maltanet.net (Stefan Camilleri) Date: Tue, 20 Jun 2006 16:38:42 +0200 Subject: [address-policy-wg] Re: [policy-announce] 2006-02 New Policy Proposal (IPv6 Address Allocation and Assignment Policy) In-Reply-To: Message-ID: <005801c69477$3a1b8920$2200a8c0@streamoffice.datastream.com.mt> > > On 8-jun-2006, at 12:31, Stefan Camilleri wrote: > > >> Note it says "a plan". An organization incapable of > coming up with > >> _a plan_ to allocate 200 /48s has more significant > problems than not > >> having IPv6 space. > > [...] > > > We have over /17 of IPv4 address space allocated. We have > over 20,000 > > broadband customers and well over 200 clients that would > benefit from > > Ipv6 assignments and who now either have a /24 to /28 or > use NAT. We > > also operate a small transit network and are linked to a major > > European Tier1 provider. Finally we are part of an Ipv6 task force > > trying to determine the future direction of IPv6 rollout. But > > basically I CANNOT have a plan, at this stage for /48 on > Ipv6. Its WAY > > too early. > > You must have SOME kind of plan if you want to get an IPv6 > block in your hands now... This is what I wrote for a > customer for their IPv6 request, which was granted without > further questions within days: > > #[REQUIRED INFORMATION]# > > confirmation: we'll conform to the policy. > > #[INSERT SUPPLEMENTAL COMMENTS]# > > We currently have several customers who have asked for IPv6 > service. We expect to give out several /48s to colo customers > immediately, around 15 within a year and 50 or so within two > years. We currently don't have IPv6 capability for our DSL > and dial-up infrastructure, but expect to add IPv6 here and > start giving out /48s to customers later this year, after > we've installed a new router at [...]. We'll then be rolling > out IPv6 first to existing customers (25 after a year) but we > also expect that we can interest new customers in more > advanced capabilities such as IPv6, multicast and IPv6 > multicast, reaching the required 200 /48s in the second year. May I ask if this is realistic? Its so vague and I sincerely am a bit surprised that you or your customer has so many IPv6 requests from his clients. Still if that's what it takes to keep RIRs happy... > > And one final thing, we're talking about IPv6. The addressing space > > that can allow 2000 addresses per square meter on the > planet as some > > of the current cliches go... We're established and qualified in the > > business but I have to beg, grovel or lie to get this allocation!! > > THAT is confusing > > Getting the addresses is not the issue, occupying a slot at > the top of the routing hierarchy is. This means you take up > an entry in the FIB tables of all IPv6 DFZ routers world > wide, which then all have to provide electricity to determine > whether the packets flowing through them match your prefix. Yes. Maybe thay will necessitate 5 extra CPU cycles.. Let me see.. Maybe an extra 1uwatt of power..Hmmm like 32Joules per annum Please.... ;-)) > From Karsten.Koepp at lambdanet.net Tue Jun 27 08:27:28 2006 From: Karsten.Koepp at lambdanet.net (Koepp, Karsten) Date: Tue, 27 Jun 2006 08:27:28 +0200 Subject: [address-policy-wg] Re: [policy-announce] 2006-02 New Policy Proposal (IPv6 Address Allocation and Assignment Policy) Message-ID: <39F27E3F569FD4119EF200508BAF85B9079B9265@CCGNT30> Hi, I support the proposal to take away the 200 customers' number being further in favour of deleting "and c) have a plan for making a reasonable number of /48 assignments within two years" Address assignment is the entire purpose of becoming a LIR. RIPE has 3800 members, this sums up to less than 20k LIRs globally, all being assigned ONE /32. I am curious to see whether chairs can see consensus after reading the whole thread. Can people please stick to the point when feedback on a certain proposal is asked. I guess this was a major objective when introducing the PDP. regards Karsten > -----Original Message----- > From: JORDI PALET MARTINEZ [mailto:jordi.palet at consulintel.es] > Sent: Wednesday, June 07, 2006 2:20 PM > To: address-policy-wg at ripe.net > Subject: [address-policy-wg] Re: [policy-announce] 2006-02 New Policy > Proposal (IPv6 Address Allocation and Assignment Policy) > > > Hi, > > I will like to know if anyone has any comments/inputs on this > proposal. > > I tried to follow the suggestions received after the > presentation of the > IPv6 PI policy at the last meeting. > > Thanks ! > > Regards, > Jordi > > > > > > De: Filiz Yilmaz > > Responder a: > > Fecha: Wed, 31 May 2006 14:43:05 +0200 > > Para: > > CC: Jordi Palet Martinez , Hans > Petter Holen > > , "address-policy-wg at ripe.net" > > > Asunto: [policy-announce] 2006-02 New Policy Proposal (IPv6 > Address Allocation > > and Assignment Policy) > > > > PDP Number: 2006-02 > > IPv6 Address Allocation and Assignment Policy > > > > Dear Colleagues > > > > A proposed change to RIPE Document ripe-267 is now available for > > discussion. > > > > You can find the full proposal at: > > > > http://www.ripe.net/ripe/policies/proposals/2006-02.html > > > > We encourage you to review this proposal and send your comments to > > before 28 June 2006. > > > > > > Regards > > > > Filiz Yilmaz > > RIPE NCC > > Policy Development Officer > > > > > > > ********************************************** > 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. > > >