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 <address-policy-wg@ripe.net> before 28 June 2006. Regards Filiz Yilmaz RIPE NCC Policy Development Officer
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 <filiz@ripe.net> Responder a: <filiz@ripe.net> Fecha: Wed, 31 May 2006 14:43:05 +0200 Para: <policy-announce@ripe.net> CC: Jordi Palet Martinez <jordi.palet@consulintel.es>, Hans Petter Holen <hph@oslo.net>, "address-policy-wg@ripe.net" <address-policy-wg@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 <address-policy-wg@ripe.net> 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.
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
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
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!"
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
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!"
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
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@nc3a.nato.int (PGP capable)
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@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of David Conrad Sent: L-Erbgħa, 7 ta' Ġunju 2006 21:54 To: jordi.palet@consulintel.es Cc: address-policy-wg@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
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
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
On 6/12/06, Stefan Camilleri <stefan.camilleri@maltanet.net> wrote: <snip>
some sort of fantasy plan for 200 /48's (and who came up with this /48 assinment chunk anyway???)
These are IETF recommendations IIRC. <snip>
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
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@gmail.com] Sent: It-Tnejn, 12 ta' Ġunju 2006 15:25 To: Stephen Camilleri Cc: David Conrad; address-policy-wg@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 <stefan.camilleri@maltanet.net> wrote: <snip>
some sort of fantasy plan for 200 /48's (and who came up with this /48 assinment chunk anyway???)
These are IETF recommendations IIRC.
<snip>
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
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
/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
Michael, Michael.Dillon@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
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
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
-----Original Message----- From: David Conrad [mailto:david.conrad@icann.org] Sent: It-Tnejn, 12 ta' Ġunju 2006 18:00 To: Stephen Camilleri Cc: address-policy-wg@ripe.net Subject: Re: [address-policy-wg] Re: [policy-announce] 2006-02 New Policy Proposal (IPv6 Address Allocation and Assignment Policy)
Stefan,
Hence my submissions in this forum. Us small fry rarely get
On Jun 11, 2006, at 11:57 PM, Stefan Camilleri wrote: 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
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
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-ipv6number... 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
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
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
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@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Michael.Dillon@btradianz.com Sent: Il-Ħamis, 15 ta' Ġunju 2006 12:32 To: address-policy-wg@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
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
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
address-policy-wg-admin@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
-----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Michael.Dillon@btradianz.com Sent: Il-Ġimgħa, 16 ta' Ġunju 2006 12:14 To: address-policy-wg@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
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@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of David Conrad Sent: L-Erbgħa, 7 ta' Ä unju 2006 21:54 To: jordi.palet@consulintel.es Cc: address-policy-wg@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@ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827
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.
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.... ;-))
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
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
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. <climbs onto soapbox>
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. <off soapbox> Niall, who apologises for the excessive markup
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
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
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
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
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
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@nc3a.nato.int (PGP capable)
On Fri, 9 Jun 2006 08:05:52 +0200, "Marc van Selm" <marc.van.selm@nc3a.nato.int> 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/
[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
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
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
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.
participants (18)
-
Carlos Friacas -
David Conrad -
Filiz Yilmaz -
Ian.Meikle＠nominet.org.uk -
Iljitsch van Beijnum -
Jeff Williams -
Jeroen Massar -
JORDI PALET MARTINEZ -
leo vegoda -
Marc van Selm -
McTim -
Michael.Dillon＠btradianz.com -
Niall Murphy -
Niall O'Reilly -
Nick Hilliard -
Per Heldal -
Randy Bush -
Stefan Camilleri -
Tim Streater