2006-01 Discussion Period extended until 19 June 2007 (Provider Independent (PI) IPv6 Assignments for End User Organisations)
PDP Number: 2006-01 Provider Independent (PI) IPv6 Assignments for End User Organisations Dear Colleagues The text of the policy proposal 2006-01 has changed. We have published the new version today, as a result the discussion period for this proposal has been extended until 19 June 2007. This proposal is intended to provide a solution for organisations that need IPv6 Provider Independent (PI) assignments. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2006-01.html We encourage you to review this policy proposal and send your comments to <address-poliy-wg@ripe.net>. Regards Filiz Yilmaz RIPE NCC Policy Development Officer
On 22 May 2007, at 9:02am, Filiz Yilmaz wrote:
PDP Number: 2006-01 Provider Independent (PI) IPv6 Assignments for End User Organisations
Dear Colleagues
The text of the policy proposal 2006-01 has changed.
The new text has the following statement: "PI IPv6 Assignment Size to End User Organisations: The minimum size of the assignment is /48. However, a larger assignment (shorter prefix) can be provided if duly documented and justified." I am not sure what documentation and justification is required to qualify for a prefix shorter than a /48. What do I need to show the RIPE NCC before they would be able to assign my network a /47? It would be helpful to people considering requesting a PI IPv6 prefix and the RIPE NCC if the policy gave a clear statement of what is required. Also, the proposed text does not define a maximum size for an IPv6 PI assignment. When this is combined with a lack of definition for the qualification requirements it seems that a /32 of IPv6 PI could be assigned. Is that intended? Regards, -- Leo Vegoda IANA Numbers Liaison
Hi Leo, See below, in-line. Regards, Jordi
De: Leo Vegoda <leo.vegoda@icann.org> Responder a: <address-policy-wg-admin@ripe.net> Fecha: Tue, 22 May 2007 17:00:37 -0400 Para: "address-policy-wg@ripe.net" <address-policy-wg@ripe.net> CC: Jordi Palet Martinez <jordi.palet@consulintel.es> Asunto: Re: [address-policy-wg] 2006-01 Discussion Period extended until 19 June 2007 (Provider Independent (PI) IPv6 Assignments for End User Organisations)
On 22 May 2007, at 9:02am, Filiz Yilmaz wrote:
PDP Number: 2006-01 Provider Independent (PI) IPv6 Assignments for End User Organisations
Dear Colleagues
The text of the policy proposal 2006-01 has changed.
The new text has the following statement:
"PI IPv6 Assignment Size to End User Organisations: The minimum size of the assignment is /48. However, a larger assignment (shorter prefix) can be provided if duly documented and justified."
I am not sure what documentation and justification is required to qualify for a prefix shorter than a /48. What do I need to show the RIPE NCC before they would be able to assign my network a /47?
I just tried to keep it simple. I expect the Staff will use the same criteria they use today for providing, for example, a /31 instead of /32.
It would be helpful to people considering requesting a PI IPv6 prefix and the RIPE NCC if the policy gave a clear statement of what is required.
Not sure if that's so easy, and I'm not really sure is really needed. Do you have any idea ? We could also apply that "idea", may be, to the standard IPv6 allocation policy. It will be good to understand if the staff is having problems there, or it is just enough the way they are doing and it may be applied then here the same.
Also, the proposed text does not define a maximum size for an IPv6 PI assignment. When this is combined with a lack of definition for the qualification requirements it seems that a /32 of IPv6 PI could be assigned. Is that intended?
Not at all, it is not intended to assign a /32. However, if the case justify it, we aren't closing the door. I really think it is difficult to find a case that could justify that, in fact probably is very difficult to justify cases that justify something shorter than /44, but you never know how big can be a data center or content provider, for example.
Regards,
-- Leo Vegoda IANA Numbers Liaison
********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
Hi Jordi, On 29 May 2007, at 11:18pm, JORDI PALET MARTINEZ wrote: [...]
The new text has the following statement:
"PI IPv6 Assignment Size to End User Organisations: The minimum size of the assignment is /48. However, a larger assignment (shorter prefix) can be provided if duly documented and justified."
I am not sure what documentation and justification is required to qualify for a prefix shorter than a /48. What do I need to show the RIPE NCC before they would be able to assign my network a /47?
I just tried to keep it simple. I expect the Staff will use the same criteria they use today for providing, for example, a /31 instead of /32.
It would be helpful to put this in the policy text so that anyone considering a request will know whether they are likely to qualify or not.
It would be helpful to people considering requesting a PI IPv6 prefix and the RIPE NCC if the policy gave a clear statement of what is required.
Not sure if that's so easy, and I'm not really sure is really needed. Do you have any idea ? We could also apply that "idea", may be, to the standard IPv6 allocation policy.
It will be good to understand if the staff is having problems there, or it is just enough the way they are doing and it may be applied then here the same.
One of the three principles guiding the policy process is that "it is transparent. All discussions and results are documented and freely available to all."[1] If the criteria for a decision are too difficult to define in the policy text then there's something wrong somewhere.
Also, the proposed text does not define a maximum size for an IPv6 PI assignment. When this is combined with a lack of definition for the qualification requirements it seems that a /32 of IPv6 PI could be assigned. Is that intended?
Not at all, it is not intended to assign a /32. However, if the case justify it, we aren't closing the door. I really think it is difficult to find a case that could justify that, in fact probably is very difficult to justify cases that justify something shorter than /44, but you never know how big can be a data center or content provider, for example.
I think it's difficult to define a case justifying it, too. But that doesn't mean that unreasonable requests won't be made. And if you don't have a clearly defined set of criteria you make things needlessly difficult for both the requesters and the registry. Regards, -- Leo Vegoda IANA Numbers Liaison [1] http://www.ripe.net/ripe/docs/pdp.html
Hi Leo, See below. Regards, Jordi
De: Leo Vegoda <leo.vegoda@icann.org> Responder a: <address-policy-wg-admin@ripe.net> Fecha: Wed, 30 May 2007 08:54:15 +0200 Para: <jordi.palet@consulintel.es> CC: "address-policy-wg@ripe.net" <address-policy-wg@ripe.net> Asunto: Re: [address-policy-wg] 2006-01 Discussion Period extended until 19 June 2007 (Provider Independent (PI) IPv6 Assignments for End User Organisations)
Hi Jordi,
On 29 May 2007, at 11:18pm, JORDI PALET MARTINEZ wrote:
[...]
The new text has the following statement:
"PI IPv6 Assignment Size to End User Organisations: The minimum size of the assignment is /48. However, a larger assignment (shorter prefix) can be provided if duly documented and justified."
I am not sure what documentation and justification is required to qualify for a prefix shorter than a /48. What do I need to show the RIPE NCC before they would be able to assign my network a /47?
I just tried to keep it simple. I expect the Staff will use the same criteria they use today for providing, for example, a /31 instead of /32.
It would be helpful to put this in the policy text so that anyone considering a request will know whether they are likely to qualify or not.
Will do, thanks !
It would be helpful to people considering requesting a PI IPv6 prefix and the RIPE NCC if the policy gave a clear statement of what is required.
Not sure if that's so easy, and I'm not really sure is really needed. Do you have any idea ? We could also apply that "idea", may be, to the standard IPv6 allocation policy.
It will be good to understand if the staff is having problems there, or it is just enough the way they are doing and it may be applied then here the same.
One of the three principles guiding the policy process is that "it is transparent. All discussions and results are documented and freely available to all."[1] If the criteria for a decision are too difficult to define in the policy text then there's something wrong somewhere.
I think in some situations, the staff needs to have some flexibility. Is not a matter of wrong policy, is a matter of avoiding a complex one with too many cases, because every ISP may be one, and we have already guidelines such as RFC3177 and utilization, which the staff, I guess, uses to understand if the right prefix is a /32 or a /30 or whatever. May be having a reference to that is enough ?
Also, the proposed text does not define a maximum size for an IPv6 PI assignment. When this is combined with a lack of definition for the qualification requirements it seems that a /32 of IPv6 PI could be assigned. Is that intended?
Not at all, it is not intended to assign a /32. However, if the case justify it, we aren't closing the door. I really think it is difficult to find a case that could justify that, in fact probably is very difficult to justify cases that justify something shorter than /44, but you never know how big can be a data center or content provider, for example.
I think it's difficult to define a case justifying it, too. But that doesn't mean that unreasonable requests won't be made. And if you don't have a clearly defined set of criteria you make things needlessly difficult for both the requesters and the registry.
Same as above, if the utilization based on RFC3177 recommendations is a good parameter, then the criteria can be defined in a simple way that accommodate all the cases while hostmasters have a good point to check.
Regards,
-- Leo Vegoda IANA Numbers Liaison
********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
Hi Jordi, On 31 May 2007, at 11:12am, JORDI PALET MARTINEZ wrote: [...]
It would be helpful to people considering requesting a PI IPv6 prefix and the RIPE NCC if the policy gave a clear statement of what is required.
Not sure if that's so easy, and I'm not really sure is really needed. Do you have any idea ? We could also apply that "idea", may be, to the standard IPv6 allocation policy.
It will be good to understand if the staff is having problems there, or it is just enough the way they are doing and it may be applied then here the same.
One of the three principles guiding the policy process is that "it is transparent. All discussions and results are documented and freely available to all."[1] If the criteria for a decision are too difficult to define in the policy text then there's something wrong somewhere.
I think in some situations, the staff needs to have some flexibility. Is not a matter of wrong policy, is a matter of avoiding a complex one with too many cases, because every ISP may be one, and we have already guidelines such as RFC3177 and utilization, which the staff, I guess, uses to understand if the right prefix is a /32 or a /30 or whatever. May be having a reference to that is enough ?
I agree that flexibility is good and a complex policy will not work for all cases. Nonetheless, without a statement of what the policy is both the registry staff and the potential requesters are in the dark and that's not really fair to either of them. The policy needs to define some basis for determining the length of a PI prefix so that everyone knows what the policy actually is. The first attempt might not be the right answer but that's not a problem as we know that the IPv6 policy is an interim policy and it will be reviewed in the future when we have more experience in the administration of IPv6.
Also, the proposed text does not define a maximum size for an IPv6 PI assignment. When this is combined with a lack of definition for the qualification requirements it seems that a /32 of IPv6 PI could be assigned. Is that intended?
Not at all, it is not intended to assign a /32. However, if the case justify it, we aren't closing the door. I really think it is difficult to find a case that could justify that, in fact probably is very difficult to justify cases that justify something shorter than /44, but you never know how big can be a data center or content provider, for example.
I think it's difficult to define a case justifying it, too. But that doesn't mean that unreasonable requests won't be made. And if you don't have a clearly defined set of criteria you make things needlessly difficult for both the requesters and the registry.
Same as above, if the utilization based on RFC3177 recommendations is a good parameter, then the criteria can be defined in a simple way that accommodate all the cases while hostmasters have a good point to check.
I think we need something a little better defined than the text in RFC 3177. It says: - Very large subscribers could receive a /47 or slightly shorter prefix, or multiple /48's. Unfortunately, "very large" isn't quantifiable and changes according to your perspective. I'm not sure what the appropriate utilisation requirements should be. I do know that this proposal isn't intended for ISPs that need address space as they can get at least a /32 allocation. Maybe we should be asking for input from people that have already deployed IPv6 on large enterprise networks, at university campuses and so on to describe their experiences and help us work out a quantifiable utilisation requirement for receiving more than a /48. Regards, -- Leo Vegoda IANA Numbers Liaison
Hi, Filiz Yilmaz wrote:
PDP Number: 2006-01 Provider Independent (PI) IPv6 Assignments for End User Organisations
Dear Colleagues
The text of the policy proposal 2006-01 has changed.
We have published the new version today, as a result the discussion period for this proposal has been extended until 19 June 2007. [...]
for starters: the link to Version 2.0 http://www.ripe.net/ripe/policies/proposals/2006-01_v2.pdf ("Submission date: ..Previous versions v1.0 and v2.0 are available as PDF") does not work. Some webmaster@RIPE might want to fix this :-) - Then again, i'm a little puzzled about the most recent(?) changes. I wonder if i missed something, or if the proposal finally got completely useless, trying to find a consensus. Why do we concentrate on "multihoming" now as a requirement for PI-addresses? That's not what "Provider Independent" means to me, even if this is the most likely reason for such a request. What about those who just want a portable block, no renumbering? Why include some routing-policy in an address-policy again? Isn't it enough that the autonomous system request policy already requires >=2 peers? What does that have to do with numbering in the first place? Why isn't the only real thing we need, a contractual relationship of some kind a and small recurring fee good enough? Why other artificial barriers? THERE IS NO ROUTING TABLE PROBLEM. (you might shoot me if i'm proven wrong in 20years) . o O(X-No-Archive: Yes :-}) Simple IPv6 PI Assignment policy: - Being an end-site, not (sub-)assigning address-space to third parties - End-site explicitely states that PI addresses are desired for this assignment and that they are aware of possible the impact of PI vs. PA addresses - PI request MUST be approved by the RIPE NCC, not by a LIR - Maintaining a standardised contractual relationship with an active RIPE LIR or the RIPE NCC directely for the lifetime of the assignment - A recurring fee of 100EUR/y is charged from the RIPE NCC directely or via the handling LIR - RIPE NCC can revoke the assigment if the holder fails to pay the recurring fee within 6 months after the payment is due or is getting otherwise unresponsive - The assignment is at least a /48 from a dedicated supernet-block which clearly identifies it as Provider Independent Prefix - A shorter prefix may be assigned if the end-site provides a network plan and possible contracts with suppliers that hint that a /48 prefix might not contain enough subnets for the planned lifetime of the assignment. The same applies for subsequent assignments to the same end-site. [Actually, PI and PA requirement should just be the same here, but the PA policy isn't really stateing anything clear yet either] - A reservation for a growth up to a /44 is usually considered ..then adapt that to IPv4 PI, too, and we're done/done. ==> PA is still easy and cheap, PI is more hassle and a more expensive so it doesn't get the "default" - and we have some way to get it back to the free pool if it goes zombie, perfect. (DISCLAIMER: That is over-simplified; i'm aware of that - for example - we can't put "100EUR/y" in the policy itself) For the records: i don't really support the current 2006-01 draft in this incarnation. It doesn't really fit anymore. Main reason: Limitation to "multihoming". (I never would have thought that i object to a IPv6 PI policy until today...) -- ======================================================================== = Sascha Lenz SLZ-RIPE slz@baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ========================================================================
Sascha Lenz wrote:
Why do we concentrate on "multihoming" now as a requirement for PI-addresses? That's not what "Provider Independent" means to me, even if this is the most likely reason for such a request.
What about those who just want a portable block, no renumbering?
Agreed - from my 11+ years of being an ISP (well, mostly in the last 5 years or so) with the growing dependency on Internet for many companies, it's enough work for many places to renumber their network. IT-folks know it, try to avoid it as long as possible. When they finally need to do it, e.g. because of switching ISPs, they want to avoid it in the future at almost any cost. That's why we get almost all of our requests for PI space. Multi-homing, though not as common yet, may become an issue, maybe another 3-5 years down the road, but IMO isn't a reason at all for PI-space. All you have to do is make sure you get a provider that will allow a sub-allocation to be announced by another provider. Why PI then?
Simple IPv6 PI Assignment policy:
Your short version seems to cover most anything I can think of. Agreed on the service fee, too. As for who charges it, there's two sides of the medal there ... I can't really tell yet if assigning the Provider to charge it for RIPE is a good idea or not. Probably the easiest, though additional hassles in case of an end user switching his (primary) ISP will follow. Or what happens if the customer refuses (or is unable) to pay the PI dues to the LIR? Couple of things need to be worked out I guess. -garry
That short version is one of the possible paths that I tried, and I'm happy to follow it again, if: 1) RIPE NCC staff confirm that will be enough criteria for them 2) A good number of folks in the list agree and confirm *NOW* and even if a smaller number of folks confirm that they disagree *NOW* What I want to avoid at all means is to go back again for a path that will take months and then we may have nothing. In that case, I prefer to go in small steps and improve it once we have an IPv6 PI that covers a good % of the cases. I learned the lesson with previous proposals that trying to go for *all* in one shoot, don't really work. Regards, Jordi
De: Garry Glendown <garry@nethinks.com> Organización: NETHINKS GmbH, Fulda Responder a: <address-policy-wg-admin@ripe.net> Fecha: Wed, 23 May 2007 06:43:50 +0200 Para: Sascha Lenz <slz@baycix.de> CC: "address-policy-wg@ripe.net" <address-policy-wg@ripe.net> Asunto: Re: [address-policy-wg] 2006-01 Discussion Period extended until 19 June 2007 (Provider Independent (PI) IPv6 Assignments for End User Organisations)
Sascha Lenz wrote:
Why do we concentrate on "multihoming" now as a requirement for PI-addresses? That's not what "Provider Independent" means to me, even if this is the most likely reason for such a request.
What about those who just want a portable block, no renumbering?
Agreed - from my 11+ years of being an ISP (well, mostly in the last 5 years or so) with the growing dependency on Internet for many companies, it's enough work for many places to renumber their network. IT-folks know it, try to avoid it as long as possible. When they finally need to do it, e.g. because of switching ISPs, they want to avoid it in the future at almost any cost. That's why we get almost all of our requests for PI space. Multi-homing, though not as common yet, may become an issue, maybe another 3-5 years down the road, but IMO isn't a reason at all for PI-space. All you have to do is make sure you get a provider that will allow a sub-allocation to be announced by another provider. Why PI then?
Simple IPv6 PI Assignment policy:
Your short version seems to cover most anything I can think of. Agreed on the service fee, too. As for who charges it, there's two sides of the medal there ... I can't really tell yet if assigning the Provider to charge it for RIPE is a good idea or not. Probably the easiest, though additional hassles in case of an end user switching his (primary) ISP will follow. Or what happens if the customer refuses (or is unable) to pay the PI dues to the LIR? Couple of things need to be worked out I guess.
-garry
********************************************** 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.
On 23-mei-2007, at 2:50, Sascha Lenz wrote:
Why do we concentrate on "multihoming" now as a requirement for PI- addresses? That's not what "Provider Independent" means to me, even if this is the most likely reason for such a request.
What about those who just want a portable block, no renumbering?
Why am I even bothering!? The IETF spent 5 years getting scalable multihoming off the ground. Then the operator community / RIR policy makers decided shim6 wasn't good enough before it was even finished and we need PI in IPv6 for multihoming just like in IPv4. That was a bad decision at the wrong time and we'll live to regret it, but it won't kill the IPv6 internet in the immediate future. But now we should go back to the good old days before the invention of CIDR where everyone gets a portable address block, no questions asked? Unlike IPv6 PI for multihoming this will be enough to kill IPv6 really fast if it comes into wide use, just like it almost killed IPv4 in the early 1990s.
Hi, Iljitsch van Beijnum wrote:
On 23-mei-2007, at 2:50, Sascha Lenz wrote:
Why do we concentrate on "multihoming" now as a requirement for PI-addresses? That's not what "Provider Independent" means to me, even if this is the most likely reason for such a request.
What about those who just want a portable block, no renumbering?
Why am I even bothering!?
The IETF spent 5 years getting scalable multihoming off the ground. Then the operator community / RIR policy makers decided shim6 wasn't good enough before it was even finished and we need PI in IPv6 for multihoming just like in IPv4. That was a bad decision at the wrong time and we'll live to regret it, but it won't kill the IPv6 internet in the immediate future.
But now we should go back to the good old days before the invention of CIDR where everyone gets a portable address block, no questions asked? Unlike IPv6 PI for multihoming this will be enough to kill IPv6 really fast if it comes into wide use, just like it almost killed IPv4 in the early 1990s.
Come one, others here also *WERE* there back in the classful times, and screamed "we need a change!!" when their Cisco 3640s hit the end of their usefulnes - heck, even i supported the shim6 (or similiar) development. It's not only you that recognized that problem and started to fear the possible outcome, but you haven't realized that times are changing yet. I don't see any routing table problem for the forseeable future, you have plenty of time to come up with a new, scalable solution and start to deploy it. I still *DO* support *ANYTHING* that keeps the global internet routing tables small and shiny, i really do, but not to that extent that i render the Internet/IPv6 completely useless and "racist" by not allowing IPv6 provider independence. This is real-life internet free market economy nowerdays, deal with it. - I will explain to customers that renumbering is not a big deal if it really isn't in their cases - I will explain to customers that there are other possibilities for multihoming right now and see if that works for them first - I will use any possible other new solution to the problem ("shim6") if it fits the customers needs in the future - I will urge any customer to become a RIR member and explain all advantages of that to them - I will not solicit the usage of PI vs. PA or anything - I will not pass any PI requests or similar from customers if i'm not convinced that they really need it and know what they do but i will NOT deny anyone a routing-table slot just because of their size or monetary issues. So, please, continue with your quest for a better solution, i will appreciate it and bring it to use whereever applicable. P.S.: Anyone got any recent numbers about the percentage of PI announcements in the table vs. PA announcements + deaggregates? -- ======================================================================== = Sascha Lenz SLZ-RIPE slz@baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ========================================================================
Sascha, Sascha Lenz wrote: [...]
P.S.: Anyone got any recent numbers about the percentage of PI announcements in the table vs. PA announcements + deaggregates?
that's probably not the fully adequate answer, but I considered the info in the following two slides (page 9 and 10) as very interesting in this context: http://www.ripe.net/ripe/meetings/ripe-54/presentations/RIPE_NCC_Statistics.... The bottom line is that the # of PI assignments has (considerably) surpassed the number of PA assignments since 2003, and that the load on the routing table for PI is thus bigger than for PA, although the *percentage* of PI space as compared to PA is approx. 2%. Or, the other way 'round, we use more than 50% of (additional) routing table slots for some 2% of address space (PI) and less than 50% for some 98% of PA. Wilfried.
On Wed, 23 May 2007, Wilfried Woeber, UniVie/ACOnet wrote:
Sascha,
Sascha Lenz wrote:
[...]
P.S.: Anyone got any recent numbers about the percentage of PI announcements in the table vs. PA announcements + deaggregates?
that's probably not the fully adequate answer, but I considered the info in the following two slides (page 9 and 10) as very interesting in this context:
http://www.ripe.net/ripe/meetings/ripe-54/presentations/RIPE_NCC_Statistics....
The bottom line is that the # of PI assignments has (considerably) surpassed the number of PA assignments since 2003, and that the load on the routing table for PI is thus bigger than for PA, although the *percentage* of PI space as compared to PA is approx. 2%.
Or, the other way 'round, we use more than 50% of (additional) routing table slots for some 2% of address space (PI) and less than 50% for some 98% of PA.
Are there similar statistics in the other RIR area? If the picture is similar we have in RIPE region, then we have think over PI address policy.... Only my 2 cents.... Janos Mohacsi Network Engineer, Research Associate, Head of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882
Hi Mohacsi Here is the statistic for PI (assignment) vs PA (allocation) for APNIC region. If you need more information please let us know. Year Number of PI Number of PA 2000 23 354 2001 36 337 2002 44 282 2003 62 368 2004 68 478 2005 118 576 2006 103 727 2007 49 244 We don't have the PI policy until 2000. Regards Son Mohacsi Janos wrote:
On Wed, 23 May 2007, Wilfried Woeber, UniVie/ACOnet wrote:
Sascha,
Sascha Lenz wrote:
[...]
P.S.: Anyone got any recent numbers about the percentage of PI announcements in the table vs. PA announcements + deaggregates?
that's probably not the fully adequate answer, but I considered the info in the following two slides (page 9 and 10) as very interesting in this context:
http://www.ripe.net/ripe/meetings/ripe-54/presentations/RIPE_NCC_Statistics....
The bottom line is that the # of PI assignments has (considerably) surpassed the number of PA assignments since 2003, and that the load on the routing table for PI is thus bigger than for PA, although the *percentage* of PI space as compared to PA is approx. 2%.
Or, the other way 'round, we use more than 50% of (additional) routing table slots for some 2% of address space (PI) and less than 50% for some 98% of PA.
Are there similar statistics in the other RIR area? If the picture is similar we have in RIPE region, then we have think over PI address policy....
Only my 2 cents....
Janos Mohacsi Network Engineer, Research Associate, Head of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882
-- -------------------------------------------------------------------- Son Tran email: son@apnic.net Policy Development Manager, APNIC sip: son@voip.apnic.net http://www.apnic.net phone: +61 7 3858 3100 fax: +61 7 3858 3199
Dear Janos, Please see below a presentation from RIPE 53, in which you can find statistics about PI address space assignments http://www.ripe.net/ripe/meetings/ripe-53/presentations/address_space.pdf May you required more information, do not hesitate to contact us Regards, Flor de Maria Paredes Mattos Registration Services Manager RIPE NCC Mohacsi Janos wrote:
On Wed, 23 May 2007, Wilfried Woeber, UniVie/ACOnet wrote:
Sascha,
Sascha Lenz wrote:
[...]
P.S.: Anyone got any recent numbers about the percentage of PI announcements in the table vs. PA announcements + deaggregates?
that's probably not the fully adequate answer, but I considered the info in the following two slides (page 9 and 10) as very interesting in this context:
http://www.ripe.net/ripe/meetings/ripe-54/presentations/RIPE_NCC_Statistics....
The bottom line is that the # of PI assignments has (considerably) surpassed the number of PA assignments since 2003, and that the load on the routing table for PI is thus bigger than for PA, although the *percentage* of PI space as compared to PA is approx. 2%.
Or, the other way 'round, we use more than 50% of (additional) routing table slots for some 2% of address space (PI) and less than 50% for some 98% of PA.
Are there similar statistics in the other RIR area? If the picture is similar we have in RIPE region, then we have think over PI address policy....
Only my 2 cents....
Janos Mohacsi Network Engineer, Research Associate, Head of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882
hi
Are there similar statistics in the other RIR area? If the picture is similar we have in RIPE region, then we have think over PI address policy....
Only my 2 cents....
Janos Mohacsi Network Engineer, Research Associate, Head of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882
this would be the comparison between number of allocations with number of assignments in our region: Allocation 1999 11 2000 42 2001 74 2002 70 2003 104 2004 153 2005 157 2006 202 Assignment 1999 0 2000 7 2001 3 2002 2 2003 6 2004 9 2005 6 2006 14 ricardo patara LACNIC Registration Service Manager --
Mohacsi Janos wrote thus on 05/23/2007 01:59 PM: > > Are there similar statistics in the other RIR area? If the > picture is similar we have in RIPE region, then we have > think over PI address policy.... If this helps, here is some data from the AfriNIC region: ------------------------------------------------------------------------ Year '98 '99 '00 '01 '02 '03 '04 '05 '06 ------------------------------------------------------------------------ PI /16 0 0 0 0.09 0.33 0.34 0.18 1.41 1.74 PA /16 1.81 1.13 3.88 5.81 3.70 3.06 7.58 14.36 39.82 ------------------------------------------------------------------------ rgds ernest -----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Ricardo Patara Sent: 25 May 2007 00:14 To: Mohacsi Janos Cc: Wilfried Woeber, UniVie/ACOnet; Sascha Lenz; address-policy-wg@ripe.net Subject: Re: Did CIDR teach us nothing? was: Re: [address-policy-wg] 2006-01 Discussion Period extended until 19 June 2007 (Provider Independent (PI) IPv6 Assignments for End User Organisations) hi
Are there similar statistics in the other RIR area? If the picture is similar we have in RIPE region, then we have think over PI address policy....
Only my 2 cents....
Janos Mohacsi Network Engineer, Research Associate, Head of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882
this would be the comparison between number of allocations with number of assignments in our region: Allocation 1999 11 2000 42 2001 74 2002 70 2003 104 2004 153 2005 157 2006 202 Assignment 1999 0 2000 7 2001 3 2002 2 2003 6 2004 9 2005 6 2006 14 ricardo patara LACNIC Registration Service Manager -- -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.467 / Virus Database: 269.8.0/817 - Release Date: 24/05/2007 16:01
Hi, On Tue, May 29, 2007 at 01:43:53PM +0400, Hisham R Rojoa wrote:
If this helps, here is some data from the AfriNIC region:
------------------------------------------------------------------------ Year '98 '99 '00 '01 '02 '03 '04 '05 '06 ------------------------------------------------------------------------ PI /16 0 0 0 0.09 0.33 0.34 0.18 1.41 1.74 PA /16 1.81 1.13 3.88 5.81 3.70 3.06 7.58 14.36 39.82 ------------------------------------------------------------------------
Actually, the *number* of allocations would be more relevant for PI vs. PA than the sheer size. In the RIPE region, we have seen that there is much less *space* being used for PI - but it is much more fragmented, thus causing more pain in the routing tables. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 113403 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
Please see below again for the AfriNIC region: ------------------------------------------------- '98 '99 '00 '01 '02 '03 '04 '05 '06 ------------------------------------------------- Alloc 10 8 27 28 21 20 43 82 105 Assigned 1 1 0 9 11 11 6 20 19 ------------------------------------------------- rgds ernest -----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Gert Doering Sent: 29 May 2007 14:56 To: Hisham R Rojoa Cc: 'Ricardo Patara'; 'Mohacsi Janos'; 'Wilfried Woeber, UniVie/ACOnet'; 'Sascha Lenz'; address-policy-wg@ripe.net Subject: Re: Did CIDR teach us nothing? was: Re: [address-policy-wg] 2006-01 Discussion Period extended until 19 June 2007 (Provider Independent (PI) IPv6 Assignments for End User Organisations) Hi, On Tue, May 29, 2007 at 01:43:53PM +0400, Hisham R Rojoa wrote:
If this helps, here is some data from the AfriNIC region:
------------------------------------------------------------------------
Year '98 '99 '00 '01 '02 '03 '04 '05 '06
------------------------------------------------------------------------
PI /16 0 0 0 0.09 0.33 0.34 0.18 1.41 1.74 PA /16 1.81 1.13 3.88 5.81 3.70 3.06 7.58 14.36 39.82 ---------------------------------------------------------------------- --
Actually, the *number* of allocations would be more relevant for PI vs. PA than the sheer size. In the RIPE region, we have seen that there is much less *space* being used for PI - but it is much more fragmented, thus causing more pain in the routing tables. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 113403 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.472 / Virus Database: 269.8.1/822 - Release Date: 28/05/2007 11:40
Mohacsi Janos wrote thus on 05/23/2007 01:59 PM: > > Are there similar statistics in the other RIR area? If the > picture is similar we have in RIPE region, then we have > think over PI address policy.... If this helps, here is some data from the AfriNIC region: ------------------------------------------------------------------------ Year '98 '99 '00 '01 '02 '03 '04 '05 '06 ------------------------------------------------------------------------ PI /16 0 0 0 0.09 0.33 0.34 0.18 1.41 1.74 PA /16 1.81 1.13 3.88 5.81 3.70 3.06 7.58 14.36 39.82 ------------------------------------------------------------------------ rgds ernest
On 23-mei-2007, at 11:47, Wilfried Woeber, UniVie/ACOnet wrote:
http://www.ripe.net/ripe/meetings/ripe-54/presentations/ RIPE_NCC_Statistics.pdf
The bottom line is that the # of PI assignments has (considerably) surpassed the number of PA assignments since 2003, and that the load on the routing table for PI is thus bigger than for PA, although the *percentage* of PI space as compared to PA is approx. 2%.
(As a percentage of the address space, not a percentage of the number of blocks.)
Or, the other way 'round, we use more than 50% of (additional) routing table slots for some 2% of address space (PI) and less than 50% for some 98% of PA.
And that's with IPv4, where you have to show you really need a block of 256 addresses to qualify for a PI block. In IPv6, that hurdle has been removed so it has the potential to see even larger numbers of PI as soon as IPv6 deployment starts taking off.
A couple of additional comments which I should have added in the first place... Iljitsch van Beijnum wrote:
On 23-mei-2007, at 11:47, Wilfried Woeber, UniVie/ACOnet wrote:
http://www.ripe.net/ripe/meetings/ripe-54/presentations/ RIPE_NCC_Statistics.pdf
The bottom line is that the # of PI assignments has (considerably) surpassed the number of PA assignments since 2003, and that the load on the routing table for PI is thus bigger than for PA, although the *percentage* of PI space as compared to PA is approx. 2%.
(As a percentage of the address space, not a percentage of the number of blocks.)
Correct.
Or, the other way 'round, we use more than 50% of (additional) routing table slots for some 2% of address space (PI) and less than 50% for some 98% of PA.
Which of course is not necessarily the full story as there probably are filters in place to prevent a good number of them to show up in the DFZ.
And that's with IPv4, where you have to show you really need a block of 256 addresses to qualify for a PI block.
Minor correction: you don't have to require a /24 equivalent to get PI. Actually, that is the (imho important) cross-link to the proposal for "upgrading" any smaller PI assignment to a /24 "if there are routing problems". Ref: http://www.ripe.net/ripe/policies/proposals/2006-05.html Otoh, going classful again for PIv4 would change the 2%/98% ratio ;-)
In IPv6, that hurdle has been removed so it has the potential to see even larger numbers of PI as soon as IPv6 deployment starts taking off.
Wilfried.
Iljitsch van Beijnum wrote:
The IETF spent 5 years getting scalable multihoming off the ground.
They got shim6 off the ground at last? Excellent. Can you please tell me how to enable it on my mac? Or on my freebsd box at the office? Also, instructions for Linux and windows would be helpful. I await your advice eagerly. Nick
Iljitsch van Beijnum wrote: Apparently, CIDR taught you nothing.
The IETF spent 5 years getting scalable multihoming off the ground. Then the operator community / RIR policy makers decided shim6 wasn't good enough before it was even finished and we need PI in IPv6 for multihoming just like in IPv4.
In general, spending 5 years on such a simple problem is the worst thing to do and, naturally, results in useless output. Actually, shim6, from the beginning, is wrongly architechted. It is not only useless but also harmful. Fortunately, as IPv6 is not deployed at all, we still have some time to start over again throwing away all the details of IPv6. Masataka Ohta
On 22 May 2007, at 8:50pm, Sascha Lenz wrote: [...]
Simple IPv6 PI Assignment policy:
[...]
- A recurring fee of 100EUR/y is charged from the RIPE NCC directely or via the handling LIR
As you noted elsewhere, fee schedule decisions belong to the membership. [...]
- The assignment is at least a /48 from a dedicated supernet-block which clearly identifies it as Provider Independent Prefix - A shorter prefix may be assigned if the end-site provides a network plan and possible contracts with suppliers that hint that a /48 prefix might not contain enough subnets for the planned lifetime of the assignment.
Hint? If prefixes shorter than /48 should not be the default assignment then I think we need more than a "slight or indirect indication or suggestion" that more than a /48 is required. If I just need to hint that I might possibly need more than a /48 over the next 15 years to receive a /44, /40 or /32 then the policy is utterly broken. If you want a free-for-all then propose a policy that clearly and unambiguously states that there is a free for all. If you want restrictions then propose a policy that clearly and unambiguously states what the qualifying criteria are. Vague language makes things more difficult for requesters because they don't know if they qualify or not and so may be dissuaded from requesting something they need. It also makes things very awkward for the RIPE NCC staff. Without a clear set of criteria they aren't in a position to justify refusing an (apparently) unreasonable request. This is likely to lead to refusing all requests or approving all requests - but probably the latter. Regards, -- Leo Vegoda IANA Numbers Liaison
Hi, Leo Vegoda wrote:
On 22 May 2007, at 8:50pm, Sascha Lenz wrote:
[...]
Simple IPv6 PI Assignment policy:
[...]
- A recurring fee of 100EUR/y is charged from the RIPE NCC directely or via the handling LIR
As you noted elsewhere, fee schedule decisions belong to the membership.
yes, i did. This is over-simplified to state my point WHAT a policy needs to look like *in the end*. Some people stressed their point that a vague pointing towards a not-yes-existing contractual relationship isn't going to fly for them as long as they don't know what might be in it, and you obviously don't like vague statements either. So i explicitely say what the outcome should look like - around how many corners that needs to be filed into policies, contracts, memberships etc.... someone from the NCC needs to help me/us with since we are technicians who don't have 100% clue about that. But this is a cruical part of the overall PI policy IMHO.
[...]
- The assignment is at least a /48 from a dedicated supernet-block which clearly identifies it as Provider Independent Prefix - A shorter prefix may be assigned if the end-site provides a network plan and possible contracts with suppliers that hint that a /48 prefix might not contain enough subnets for the planned lifetime of the assignment.
Hint? If prefixes shorter than /48 should not be the default assignment then I think we need more than a "slight or indirect indication or suggestion" that more than a /48 is required. If I just need to hint that I might possibly need more than a /48 over the next 15 years to receive a /44, /40 or /32 then the policy is utterly broken.
Facts: - The PA policy (http://www.ripe.net/ripe/docs/ipv6policy.html#assignment_size) doesn't really say anything specific either, and AFAIK there hasn't been a single End-User Request for </48 yet(?). If the RIPE NCC thinks it can provide input on what they need here or experience like how they deal with </32 PA requests for very large sites, i'm happy to hear them out. Should be similar to what </48 end-user requests should look like. I don't want to make a difference between PI and PA assignment requirements here in the end, that's my plan at least. - It's vague, but it's always stressed that the RIPE NCC hostmasters usually know what they do and have the experience to tell if someone provided the correct amount of information for a given request. Why should that be different for IPv6 PI now? Isn't some kind of contract or bills for equipment like i suggest here enough? That's what i'm usually asked to provide to the NCC if i request some biiiiiiiiiig IPv4 assignment/allocation at least. PROBABLY the PI and PA policy needs something like "utilisation within a 2year term" statement or so similar to the IPv4 assignment policy; that is correct. But i intentionally left that out here since it's not in the PA policy either. (RFC3177 doesn't say anything about a specific timeframe either AFAICR).
If you want a free-for-all then propose a policy that clearly and unambiguously states that there is a free for all. If you want restrictions then propose a policy that clearly and unambiguously states what the qualifying criteria are.
You cannot predict all possible (valid) reasons for a bigger assignment. If you look at a network plan and you see that 16bit subnets is not enough.. fine. IF not, ask them to come back for a subsequent assignment (mind the /44 reservation suggestion) if they really run out of subnets and can show that by means of contracts or equipment bills (similar to IPv4 as mentioned above). (And btw, i think this will rarely happen since i'm not aware of any request </48 for an end-user) It's pretty clear to me, but again, only RIPE NCC Hostmasters might shed light on the real world issues with unusual big requests (IPv4, IPv6 PA) and what they do about it TODAY. I actually want to prevent big assignments to be granted just because some bad network design. But how the hell should we predict what's bad and what not here in writing? Happy to hear suggestions how to prevent this. I personally think that this can only be solved with clue++; at the RIPE NCC Hostmaster level in the end, not by a rigid policy.
Vague language makes things more difficult for requesters because they don't know if they qualify or not and so may be dissuaded from requesting something they need. It also makes things very awkward for the RIPE NCC staff. Without a clear set of criteria they aren't in a position to justify refusing an (apparently) unreasonable request. This is likely to lead to refusing all requests or approving all requests - but probably the latter.
I still trust the RIPE NCC Hostmasters to be reasonable and clueful, but if you think we should start micro-managing via the policies... since it's you, i actually wouldn't object since you have some experience there ;-) But we need some realworld examples from the NCC here to find out what should go into the polic[y|ies] and what not. -- ======================================================================== = Sascha Lenz SLZ-RIPE slz@baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ========================================================================
Sascha, I think we broadly agree, actually :-) On 23 May 2007, at 12:07pm, Sascha Lenz wrote: [...]
- A recurring fee of 100EUR/y is charged from the RIPE NCC directely or via the handling LIR As you noted elsewhere, fee schedule decisions belong to the membership.
yes, i did. This is over-simplified to state my point WHAT a policy needs to look like *in the end*.
Fair enough and I agree that a contract for the assignment is a very important element.
- The assignment is at least a /48 from a dedicated supernet-block which clearly identifies it as Provider Independent Prefix - A shorter prefix may be assigned if the end-site provides a network plan and possible contracts with suppliers that hint that a /48 prefix might not contain enough subnets for the planned lifetime of the assignment. Hint? If prefixes shorter than /48 should not be the default assignment then I think we need more than a "slight or indirect indication or suggestion" that more than a /48 is required. If I just need to hint that I might possibly need more than a /48 over the next 15 years to receive a /44, /40 or /32 then the policy is utterly broken.
Facts:
- The PA policy (http://www.ripe.net/ripe/docs/ ipv6policy.html#assignment_size) doesn't really say anything specific either, and AFAIK there hasn't been a single End-User Request for </48 yet(?).
I agree that the PA policy is equally flawed. I remember several requests for more than a /48 PA assignment. In most cases though, people had misunderstood the difference between an assignment and an allocation and they really need a sub-allocation which does not need approval by the RIPE NCC.
If the RIPE NCC thinks it can provide input on what they need here or experience like how they deal with </32 PA requests for very large sites, i'm happy to hear them out. Should be similar to what </48 end-user requests should look like. I don't want to make a difference between PI and PA assignment requirements here in the end, that's my plan at least.
I think using the same criteria to evaluate PA and PI requests would be useful and fair.
- It's vague, but it's always stressed that the RIPE NCC hostmasters usually know what they do and have the experience to tell if someone provided the correct amount of information for a given request. Why should that be different for IPv6 PI now?
The difference is that the IPv4 using community has over a decade of experience and plenty of documents describing what is and is not efficient. There isn't much IPv6 deployment experience and what is considered efficient usage of a /48 isn't documented (I think).
Isn't some kind of contract or bills for equipment like i suggest here enough? That's what i'm usually asked to provide to the NCC if i request some biiiiiiiiiig IPv4 assignment/allocation at least.
PROBABLY the PI and PA policy needs something like "utilisation within a 2year term" statement or so similar to the IPv4 assignment policy; that is correct. But i intentionally left that out here since it's not in the PA policy either. (RFC3177 doesn't say anything about a specific timeframe either AFAICR).
I agree that something like 'x subnets used in y years' would work. I don't know what x and y should be, though. When we have that I will know how many thousand subnets I have to use before my network qualifies for a /47. That will be genuinely useful for people deploying IPv6 networks. My concern isn't the tools the RIPE NCC will use to determine that someone qualifies. They will use whatever evaluation techniques are appropriate and I don't think the policy needs to worry about them. I just think the policy needs to let them know what they are measuring. [...]
I actually want to prevent big assignments to be granted just because some bad network design. But how the hell should we predict what's bad and what not here in writing? Happy to hear suggestions how to prevent this. I personally think that this can only be solved with clue++; at the RIPE NCC Hostmaster level in the end, not by a rigid policy.
I'm not worried about the RIPE NCC's clue level - they do well there. I just want them to be given the tools they will need when they have to justify their decisions. Regards, -- Leo Vegoda IANA Numbers Liaison
Sascha Lenz wrote:
Filiz Yilmaz wrote:
PDP Number: 2006-01 Provider Independent (PI) IPv6 Assignments for End User Organisations
Dear Colleagues
The text of the policy proposal 2006-01 has changed.
We have published the new version today, as a result the discussion period for this proposal has been extended until 19 June 2007. [...]
For the records: i don't really support the current 2006-01 draft in this incarnation. It doesn't really fit anymore. Main reason: Limitation to "multihoming".
I agree with Sascha here, only considering multihoming as a reason for IPv6 PI space is a big step backwards from the former versions of the proposal. For me it is too big of a limitation to support the draft in this incarnation. Marcus -- man-da.de GmbH, AS8365 Phone: +49 6151 16-6956 Petersenstr. 30 Fax: +49 6151 16-3050 D-64287 Darmstadt e-mail: ms@man-da.de Geschäftsführer Dr. Jürgen Ohrnberger AG Darmstadt, HRB 94 84
Hi Sascha, See below, in-line. Regards, Jordi
De: Sascha Lenz <slz@baycix.de> Organización: BayCIX GmbH Responder a: <address-policy-wg-admin@ripe.net> Fecha: Wed, 23 May 2007 02:50:56 +0200 Para: "address-policy-wg@ripe.net" <address-policy-wg@ripe.net> Asunto: Re: [address-policy-wg] 2006-01 Discussion Period extended until 19 June 2007 (Provider Independent (PI) IPv6 Assignments for End User Organisations)
Hi,
Filiz Yilmaz wrote:
PDP Number: 2006-01 Provider Independent (PI) IPv6 Assignments for End User Organisations
Dear Colleagues
The text of the policy proposal 2006-01 has changed.
We have published the new version today, as a result the discussion period for this proposal has been extended until 19 June 2007. [...]
for starters: the link to Version 2.0
http://www.ripe.net/ripe/policies/proposals/2006-01_v2.pdf
("Submission date: ..Previous versions v1.0 and v2.0 are available as PDF") does not work. Some webmaster@RIPE might want to fix this :-)
- Then again, i'm a little puzzled about the most recent(?) changes. I wonder if i missed something, or if the proposal finally got completely useless, trying to find a consensus.
Why do we concentrate on "multihoming" now as a requirement for PI-addresses? That's not what "Provider Independent" means to me, even if this is the most likely reason for such a request.
I will prefer to have a policy proposal that can justify a criteria for *not only* multihoming, but it turned out that we can't find a way to objectively verify that (from the staff point of view). So I suggested in the last meeting starting, with this case, which is easy to justify in a criteria for the requester and my feeling was that the room agreed in that path. I think it is much better to cover at least some of the cases, instead of trying to cover all. So if you look to the target, right now is data centers and content providers, which are not ISPs. Presumably they are multihomend in 99.9% of the cases. Do you think other cases are not covered ? If so, do you have an idea of an alternative *objective* criteria ?
What about those who just want a portable block, no renumbering?
What will be the objective criteria for the staff to agree on that ? Typically who want to avoid renumbering is because it is multihomed. Do you see any other case ?
Why include some routing-policy in an address-policy again? Isn't it enough that the autonomous system request policy already requires >=2 peers? What does that have to do with numbering in the first place?
Hmmm. If you are refering to: Assigning a /32 would make those blocks behave as other regular LIR allocated ones and follow generally accepted routing filtering practices. At the same time, the blocks would be identifiable as belonging to a special 'super block'. This would also allow organisations to become an LIR and avoid the need for renumbering. It is a mistake, that should have been removed from this version.
Why isn't the only real thing we need, a contractual relationship of some kind a and small recurring fee good enough? Why other artificial barriers?
If the rest of this group believe is ok, and staff also, I'm happy to go that way, but this is not what I heard from the last months discussions !
THERE IS NO ROUTING TABLE PROBLEM. (you might shoot me if i'm proven wrong in 20years) . o O(X-No-Archive: Yes :-})
Simple IPv6 PI Assignment policy:
- Being an end-site, not (sub-)assigning address-space to third parties - End-site explicitely states that PI addresses are desired for this assignment and that they are aware of possible the impact of PI vs. PA addresses - PI request MUST be approved by the RIPE NCC, not by a LIR - Maintaining a standardised contractual relationship with an active RIPE LIR or the RIPE NCC directely for the lifetime of the assignment - A recurring fee of 100EUR/y is charged from the RIPE NCC directely or via the handling LIR - RIPE NCC can revoke the assigment if the holder fails to pay the recurring fee within 6 months after the payment is due or is getting otherwise unresponsive - The assignment is at least a /48 from a dedicated supernet-block which clearly identifies it as Provider Independent Prefix - A shorter prefix may be assigned if the end-site provides a network plan and possible contracts with suppliers that hint that a /48 prefix might not contain enough subnets for the planned lifetime of the assignment. The same applies for subsequent assignments to the same end-site. [Actually, PI and PA requirement should just be the same here, but the PA policy isn't really stateing anything clear yet either] - A reservation for a growth up to a /44 is usually considered
..then adapt that to IPv4 PI, too, and we're done/done. ==> PA is still easy and cheap, PI is more hassle and a more expensive so it doesn't get the "default" - and we have some way to get it back to the free pool if it goes zombie, perfect.
(DISCLAIMER: That is over-simplified; i'm aware of that - for example - we can't put "100EUR/y" in the policy itself)
For the records: i don't really support the current 2006-01 draft in this incarnation. It doesn't really fit anymore. Main reason: Limitation to "multihoming". (I never would have thought that i object to a IPv6 PI policy until today...)
-- ======================================================================== = Sascha Lenz SLZ-RIPE slz@baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ========================================================================
********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
participants (17)
-
Ernest Byaruhanga (AfriNIC) -
Filiz Yilmaz -
Flor Paredes -
Garry Glendown -
Gert Doering -
Hisham R Rojoa -
Iljitsch van Beijnum -
JORDI PALET MARTINEZ -
Leo Vegoda -
Marcus Stoegbauer -
Masataka Ohta -
Mohacsi Janos -
Nick Hilliard -
Ricardo Patara -
Sascha Lenz -
Son Tran -
Wilfried Woeber, UniVie/ACOnet