The final /8 policy proposals, part 2
Hello WG, I want to continue the discussion about the Final /8 proposals (2008-06 and 2009-04). The responses to my last question ("Do we (this working group) want to put IPv6 related requirements in the policy?") were 100% negative: We don't want IPv6 related requirements in the Final /8 policy. The next question is about the amount of addresses someone can get from the Final /8. I think we have a number of options here: a) Everyone gets one (and only one) fixed size block, as described in 2008-06 b) All requests are downscaled by a certain factor, as described in 2009-04 c) We place a limit on the amount of addresses that can be requested per time slot (year?) I think it is important to think about new companies. They will very probably require some IPv4 address space during the transition from IPv4 to IPv6. I think the whole community will be in a lot of trouble if we make a policy that makes it impossible for new entrants to participate in a dual-stack world. Once we have discussed this basic issue I'll steer the discussion back to the other differences between the proposals. Please keep the discussion on this topic for now. Thank you, Sander Steffann APWG co-chair
Hello,
The next question is about the amount of addresses someone can get from the Final /8. I think we have a number of options here: a) Everyone gets one (and only one) fixed size block, as described in 2008-06
IMHO, the "one size fits all" approach doesn't seem the right way to go. The rationale in the original proposal was clearly directed towards IPv6 deployment and maintaining interconnection to the IPv4 world in this szenario. Even if I think, this is a sensible approach, we agreed 100%, that we don't want IPv6 related requirements in this proposal (and let me add, neither explicit nor implicit).
b) All requests are downscaled by a certain factor, as described in 2009-04
This sounds sensible to me. A downsscaling factor of 64 will give enough address space to stay in the allocation business for some (small "some) years. Newcomers are not discriminated, as it seems easier to me for a newcomer to deploy multiplexing techniques than for an established operator with a large legacy network. So the goal to keep newcomers in the game is achieved as well (and reinforced by the proposed argument (d) below).
c) We place a limit on the amount of addresses that can be requested per time slot (year?)
and/or (d) upon further allocation requests, the LIR has to demonstrate IP use under the downscaling paradigm (e.g., some kind of multiplexing technology is deployed for the last allocation). Regards, Andreas -- -- Andreas Schachtner afs Holding GmbH communication technologies & solutions http://afs-com.de/ Geschaeftsfuehrer Andreas Schachtner HRB 15448, Amtsgericht Dortmund
Hi, On Sun, Jul 05, 2009 at 12:19:48PM +0200, Andreas Schachtner wrote:
b) All requests are downscaled by a certain factor, as described in 2009-04
This sounds sensible to me. A downsscaling factor of 64 will give enough address space to stay in the allocation business for some (small "some) years.
How exactly would "downscaling" work? A company demonstrates need for (say) a /19, and they get 8192/64 = a /25 - while a newcomer demonstrates the need for a /24, and gets a /30... So if we go that way, quite some thought needs to go into implementation details. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 128645 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
On Sun, Jul 05, 2009 at 06:41:17PM +0200, Gert Doering wrote:
So if we go that way, quite some thought needs to go into implementation details.
before diving into these or before selecting different options, shouldn't the overall goals of, say, "fairness" and "sustainability" be broken down into a tangible set of criteria against which the solutions could be evaluated? This would also ease the assessment of potential subversion tactics. -Peter
Hi Peter, ...
before diving into these or before selecting different options, shouldn't the overall goals of, say, "fairness" and "sustainability" be broken down into a tangible set of criteria against which the solutions could be evaluated? This would also ease the assessment of potential subversion tactics.
I agree with your comment, to think about "fairness" and "sustainability". But the latter, IHMO contradicts with Randy's comment, that IPv4 has no future (to which I agree also). In the first of Sander's questions, there were no one favouring IPv6 requirements with IPv4 allocations, so that's out of scope right now, UNLESS we're reopening that topic again (which I won't do). What's left over, is to look into the "fairness", which is achieved partly, that I request and monitor, that everybody still requesting IPv4 plays by the rules: For allowing some "sustainability" for a couple of years, everybody has to deploy multiplexing techniques for newly allocated adress ranges. [This might introduce IPv6 requirements through a backdoos, as deploying multiplexing techniques may prove as expensive as migrating to IPv6, or even more.] Regards, Andreas -- -- Andreas Schachtner afs Holding GmbH communication technologies & solutions http://afs-com.de/ Geschaeftsfuehrer Andreas Schachtner HRB 15448, Amtsgericht Dortmund
...
How exactly would "downscaling" work? A company demonstrates need for (say) a /19, and they get 8192/64 = a /25 - while a newcomer demonstrates the need for a /24, and gets a /30...
Aehem, a fixed threshold to give them a reasonable IPv4 footprint would do. But this is a quick answer, again. Proper engineering is needed, not to end in dead ends.
So if we go that way, quite some thought needs to go into implementation details.
Definitely. Regards, Andreas I agree with Peters comment, to think about "fairness" and "sustainability". But the latter, IHMO contradicts with Randy's comment, that IPv4 has no future (to which I agree also). In the first of Sander's questions, there were no one favouring IPv6 requirements with IPv4 allocations, so that's out of scope right now, UNLESS we're reopening that topic again (which I won't do). What's left over, is to look into the "fairness", which is achieved partly, that I request and monitor, that everybody still requesting IPv4 plays by the rules: For allowing "sustainability" for a couple of years, everybody has to deploy multiplexing techniques for newly allocated adress ranges. [This might introduce IPv6 requirements through a backdoos, as deploying multiplexing techniques may prove as expensive as migrating to IPv6, or even more.]
Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 128645
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
-- -- Andreas Schachtner afs Holding GmbH communication technologies & solutions http://afs-com.de/ Geschaeftsfuehrer Andreas Schachtner HRB 15448, Amtsgericht Dortmund
Andreas and all, I agree, the one-size-fits-all approach is a fools errand. Andreas Schachtner wrote:
Hello,
The next question is about the amount of addresses someone can get from the Final /8. I think we have a number of options here: a) Everyone gets one (and only one) fixed size block, as described in 2008-06
IMHO, the "one size fits all" approach doesn't seem the right way to go. The rationale in the original proposal was clearly directed towards IPv6 deployment and maintaining interconnection to the IPv4 world in this szenario. Even if I think, this is a sensible approach, we agreed 100%, that we don't want IPv6 related requirements in this proposal (and let me add, neither explicit nor implicit).
b) All requests are downscaled by a certain factor, as described in 2009-04
This sounds sensible to me. A downsscaling factor of 64 will give enough address space to stay in the allocation business for some (small "some) years.
Newcomers are not discriminated, as it seems easier to me for a newcomer to deploy multiplexing techniques than for an established operator with a large legacy network. So the goal to keep newcomers in the game is achieved as well (and reinforced by the proposed argument (d) below).
c) We place a limit on the amount of addresses that can be requested per time slot (year?)
and/or
(d) upon further allocation requests, the LIR has to demonstrate IP use under the downscaling paradigm (e.g., some kind of multiplexing technology is deployed for the last allocation).
Regards, Andreas --
-- Andreas Schachtner
afs Holding GmbH communication technologies & solutions http://afs-com.de/
Geschaeftsfuehrer Andreas Schachtner HRB 15448, Amtsgericht Dortmund
------------------------------------------------------------------------ Part 1.2Type: application/pgp-signature
Regards, Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "YES WE CAN!" Barack ( Berry ) Obama "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 My Phone: 214-244-4827
Hello, If you ask me; the requests should be processed like now, with 3 differences: - IF someone/a company has IPv4 address space already they need to prove that they use it in the right way (1 IP/VPS or 2 IP/server or 1 IP/NIC or 1 IP/SSL certificate for example sounds reasonable for me). If this is not the case (they use more IPv4 addresses for this) the new allocation will be refused. - Someone/a company without IPv4 address space already should get only a /24 or a /23, after they have proven to use this correctly (see above) they could request another range. - The biggest range someone can get with any new request should be limited to a /22. Requests should be processed at a first-come-first-serve base (where possible) if you ask me. With kind regards, Mark Scholten -----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Sander Steffann Sent: zondag 5 juli 2009 11:13 To: Address Policy Working Group Subject: [address-policy-wg] The final /8 policy proposals, part 2 Hello WG, I want to continue the discussion about the Final /8 proposals (2008-06 and 2009-04). The responses to my last question ("Do we (this working group) want to put IPv6 related requirements in the policy?") were 100% negative: We don't want IPv6 related requirements in the Final /8 policy. The next question is about the amount of addresses someone can get from the Final /8. I think we have a number of options here: a) Everyone gets one (and only one) fixed size block, as described in 2008-06 b) All requests are downscaled by a certain factor, as described in 2009-04 c) We place a limit on the amount of addresses that can be requested per time slot (year?) I think it is important to think about new companies. They will very probably require some IPv4 address space during the transition from IPv4 to IPv6. I think the whole community will be in a lot of trouble if we make a policy that makes it impossible for new entrants to participate in a dual-stack world. Once we have discussed this basic issue I'll steer the discussion back to the other differences between the proposals. Please keep the discussion on this topic for now. Thank you, Sander Steffann APWG co-chair
Am quite up for capping the request size, if a newcomer comes along and wants a big bunch of v4 addresses then they are obviously not transitioning and not the sort of people that we want to be wasting the remaining v4 address space on. The only edge case I can think of here is when $company has address space from $provider and $provider tells them to get lost and they find they have to fend for themselves. Do people think that this will become a problem? people ditching v4 only customers in order to get address space back (i.e making them IPv4 homeless?)? Dave. ------------------------------------------------ David Freedman Group Network Engineering Claranet Limited http://www.clara.net -----Original Message----- From: address-policy-wg-admin@ripe.net on behalf of Stream Service Sent: Sun 7/5/2009 11:52 To: 'Address Policy Working Group' Subject: RE: [address-policy-wg] The final /8 policy proposals, part 2 Hello, If you ask me; the requests should be processed like now, with 3 differences: - IF someone/a company has IPv4 address space already they need to prove that they use it in the right way (1 IP/VPS or 2 IP/server or 1 IP/NIC or 1 IP/SSL certificate for example sounds reasonable for me). If this is not the case (they use more IPv4 addresses for this) the new allocation will be refused. - Someone/a company without IPv4 address space already should get only a /24 or a /23, after they have proven to use this correctly (see above) they could request another range. - The biggest range someone can get with any new request should be limited to a /22. Requests should be processed at a first-come-first-serve base (where possible) if you ask me. With kind regards, Mark Scholten -----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Sander Steffann Sent: zondag 5 juli 2009 11:13 To: Address Policy Working Group Subject: [address-policy-wg] The final /8 policy proposals, part 2 Hello WG, I want to continue the discussion about the Final /8 proposals (2008-06 and 2009-04). The responses to my last question ("Do we (this working group) want to put IPv6 related requirements in the policy?") were 100% negative: We don't want IPv6 related requirements in the Final /8 policy. The next question is about the amount of addresses someone can get from the Final /8. I think we have a number of options here: a) Everyone gets one (and only one) fixed size block, as described in 2008-06 b) All requests are downscaled by a certain factor, as described in 2009-04 c) We place a limit on the amount of addresses that can be requested per time slot (year?) I think it is important to think about new companies. They will very probably require some IPv4 address space during the transition from IPv4 to IPv6. I think the whole community will be in a lot of trouble if we make a policy that makes it impossible for new entrants to participate in a dual-stack world. Once we have discussed this basic issue I'll steer the discussion back to the other differences between the proposals. Please keep the discussion on this topic for now. Thank you, Sander Steffann APWG co-chair
* Stream Service:
- IF someone/a company has IPv4 address space already they need to prove that they use it in the right way (1 IP/VPS or 2 IP/server or 1 IP/NIC or 1 IP/SSL certificate for example sounds reasonable for me).
With current Internet standards, you need at least 4 IPv4 addresses per host if you want to implement full IP layer separation. Proprietary solutions can reduce that to 1 IPv4 address per host, but there's no IETF or IEEE standard for it, and the technology is not universally available. -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
Sander Steffann <sander@steffann.nl>
a) Everyone gets one (and only one) fixed size block, as described in 2008-06
apnic chose this path, i believe for the following reason you state:
I think it is important to think about new companies. They will very probably require some IPv4 address space during the transition from IPv4 to IPv6. I think the whole community will be in a lot of trouble if we make a policy that makes it impossible for new entrants to participate in a dual-stack world.
Andreas Schachtner <Andreas@Schachtner.eu> wrote:
IMHO, the "one size fits all" approach doesn't seem the right way to go.
you're right, of course. but the problem is, nothing will fit all. we are out of ipv4 space. concepts such as meeting needs of existing players are now pretty much irrelevant. randy
Randy and all, How far and how much effort has been exercised by the RIR's in reclaiming unused IPv4 addresses so far? I haven't seen much activity in this area of late, and in fact no activity/effort in this area. Seems to me that there is an awful lot of assinged but unused IPv4 address space that could/should be reclaimed for re-allocation to more needy or yet to be known entities. Randy Bush wrote:
Sander Steffann <sander@steffann.nl>
a) Everyone gets one (and only one) fixed size block, as described in 2008-06
apnic chose this path, i believe for the following reason you state:
I think it is important to think about new companies. They will very probably require some IPv4 address space during the transition from IPv4 to IPv6. I think the whole community will be in a lot of trouble if we make a policy that makes it impossible for new entrants to participate in a dual-stack world.
Andreas Schachtner <Andreas@Schachtner.eu> wrote:
IMHO, the "one size fits all" approach doesn't seem the right way to go.
you're right, of course. but the problem is, nothing will fit all. we are out of ipv4 space. concepts such as meeting needs of existing players are now pretty much irrelevant.
randy
Regards, Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "YES WE CAN!" Barack ( Berry ) Obama "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 My Phone: 214-244-4827
On Sun, 2009-07-05 at 11:12 +0200, Sander Steffann wrote:
Hello WG,
I want to continue the discussion about the Final /8 proposals (2008-06 and 2009-04). The responses to my last question ("Do we (this working group) want to put IPv6 related requirements in the policy?") were 100% negative: We don't want IPv6 related requirements in the Final /8 policy.
I think APNIC has got it mostly right. To reserve some space for transition-services is the only suggestion I've seen that can have a lasting effect throughout the transition period. Everything else has been/is about skewing the balance to change who gets most out of the remaining chunks. Keep it simple. One single fixed-size block for each new registrant that qualify for or already has a v6 block, and no prior v4 allocation. A whole /8 for might be more than necessary for this though. How many /20 - /22 -size allocations does RIPE-NCC make each year where the registrant has no prior allocation? The intention of such a policy is IMHO primarily to protect new innovative players from abuse (extortion) by the V4 powerhouses. Once established they should seek expansion elsewhere (v6) or compete for the same resources as everyone else. One-size-fits all is therefore appropriate, as it would be near impossible for the NCC to differentiate. //per
Hello,
Keep it simple. One single fixed-size block for each new registrant that qualify for or already has a v6 block, and no prior v4 allocation.
A whole /8 for might be more than necessary for this though.
Maybe we can reserve a certain amount of address space for this. A whole /8 might indeed be too much. The RIPE NCC seems to grow with about 700 new LIRs each year. If we want to have at least enough for the first 5 years we need 3500 blocks of address space. Let's round that up to 4096. If we use a fixed allocation size of /22 we will need to reserve a /10. That leaves 3/4 of the final /8 for the existing LIRs. The numbers are a bit arbitrary, but it sounds reasonable to me... Sander PS: not speaking as a working group chair
On 06/07/2009 2:45, "Sander Steffann" <sander@steffann.nl> wrote: [...]
A whole /8 for might be more than necessary for this though.
Maybe we can reserve a certain amount of address space for this. A whole /8 might indeed be too much. The RIPE NCC seems to grow with about 700 new LIRs each year. If we want to have at least enough for the first 5 years we need 3500 blocks of address space. Let's round that up to 4096. If we use a fixed allocation size of /22 we will need to reserve a /10. That leaves 3/4 of the final /8 for the existing LIRs.
I think it is also important to take account of non-member registrations. As I understand it, the RIPE NCC has been making more PI assignments than allocations for a good four or five years. If address space is only available to LIRs (members) then anyone who previously would have settled for a little bit of PI would need to become a member. The reserved space would be used up faster than a projection based on new member allocations alone would suggest. It would be helpful if RIPE NCC staff could provide statistics showing the number and size distribution of PI assignments over the last five years. It would also be good to know how much of the address space currently set aside for PI assignments remains available. Regards, Leo Vegoda
My draft... On Jul 6, 2009, at 20:57, Leo Vegoda wrote: [...]
It would be helpful if RIPE NCC staff could provide statistics showing the number and size distribution of PI assignments over the last five years. It would also be good to know how much of the address space currently set aside for PI assignments remains available.
Dear Leo, IPv4 PI Number of assignments size 2004 2005 2006 2007 2008 2009 /16 0 0 1 0 0 2 /17 2 0 1 1 0 0 /18 3 1 2 3 10 2 /19 12 3 7 4 12 10 /20 23 25 28 23 44 23 /21 54 51 56 89 100 52 /22 236 260 260 260 399 192 /23 359 384 463 776 571 244 /24 551 724 895 972 1046 440 /25 11 9 22 8 8 6 /26 7 7 6 0 5 1 /27 7 4 8 8 7 2 /28 0 0 8 0 1 0 /29 0 2 1 0 8 0 total 1265 1470 1758 2151 2211 974 Note: Both /16 assignments in 2009 are temporary assignments that will be returned before the end of the year. IPv4 PI Assignment size year total IPs 2004 986400 2005 897744 2006 1153800 2007 1305312 2008 1617520 2009 881536 IPv4 Allocation numbers and sizes year number total size 2004 1001 37838336 2005 1143 57196544 2006 1213 59731968 2007 1333 62085120 2008 1649 44496896 2009 844 24535040 To put these numbers in perspective: The RIPE NCC assigns more PI prefixes than we allocate as PA, while the number of IPs assigned as PI is around 3% of the total that we assign or allocate. The RIPE NCC does not set aside address space for PI assignments larger than the current minimum allocation size, a /21, because these assignments can be made from any of our IANA allocations. We do mark some free blocks with a minimum allocation size of less than a /21 as usable for smaller PI assignments. This list is periodically reviewed and currently contains a bit over a /11 of address space. If you have any questions about these numbers, please do not hesitate to ask. Best regards, Alex Le Heux RIPE NCC
On Jul 8, 2009, at 16:43, Alex Le Heux wrote:
My draft...
This email was not the draft, it is the final version. Apologies for the confusion. Alex Le Heux RIPE NCC
On Jul 6, 2009, at 20:57, Leo Vegoda wrote:
[...]
It would be helpful if RIPE NCC staff could provide statistics showing the number and size distribution of PI assignments over the last five years. It would also be good to know how much of the address space currently set aside for PI assignments remains available.
Dear Leo,
IPv4 PI Number of assignments
size 2004 2005 2006 2007 2008 2009 /16 0 0 1 0 0 2 /17 2 0 1 1 0 0 /18 3 1 2 3 10 2 /19 12 3 7 4 12 10 /20 23 25 28 23 44 23 /21 54 51 56 89 100 52 /22 236 260 260 260 399 192 /23 359 384 463 776 571 244 /24 551 724 895 972 1046 440 /25 11 9 22 8 8 6 /26 7 7 6 0 5 1 /27 7 4 8 8 7 2 /28 0 0 8 0 1 0 /29 0 2 1 0 8 0 total 1265 1470 1758 2151 2211 974
Note: Both /16 assignments in 2009 are temporary assignments that will be returned before the end of the year.
IPv4 PI Assignment size
year total IPs
2004 986400 2005 897744 2006 1153800 2007 1305312 2008 1617520 2009 881536
IPv4 Allocation numbers and sizes
year number total size
2004 1001 37838336 2005 1143 57196544 2006 1213 59731968 2007 1333 62085120 2008 1649 44496896 2009 844 24535040
To put these numbers in perspective: The RIPE NCC assigns more PI prefixes than we allocate as PA, while the number of IPs assigned as PI is around 3% of the total that we assign or allocate.
The RIPE NCC does not set aside address space for PI assignments larger than the current minimum allocation size, a /21, because these assignments can be made from any of our IANA allocations. We do mark some free blocks with a minimum allocation size of less than a /21 as usable for smaller PI assignments. This list is periodically reviewed and currently contains a bit over a /11 of address space.
If you have any questions about these numbers, please do not hesitate to ask.
Best regards,
Alex Le Heux RIPE NCC
Best regards, Alex Le Heux RIPE NCC IP Resource Analyst
Hi Alex, Thank you for these numbers. I think they are very useful. On 08/07/2009 7:43, "Alex Le Heux" <alexlh@ripe.net> wrote:
size 2004 2005 2006 2007 2008 2009 /16 0 0 1 0 0 2 /17 2 0 1 1 0 0 /18 3 1 2 3 10 2 /19 12 3 7 4 12 10 /20 23 25 28 23 44 23 /21 54 51 56 89 100 52 /22 236 260 260 260 399 192
This suggests to me that if the default allocation from a reserved prefix is a /22, as suggested earlier, then we should assume that there will be at least an extra 300-400 prefixes used per year just from people who will request PI and maybe add some more onto that from people who would have been happy with a PA assignment but won't be able to get it. I think reserving a /10 to be cut into /22s would underestimate demand for the space. I doubt it would last anywhere near five years. We should probably consider whether we reserve more space or divide whatever we reserve into longer prefixes, maybe /24s. Regards, Leo Vegoda
Hello Alex, So if I understand correctly a new LIR will get at least a /21 range (IPv4)? Maybe this should be reduced to a /24 or /23 when we reach the last /8 range. Regards, Mark Scholten -----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Alex Le Heux Sent: woensdag 8 juli 2009 16:44 To: Leo Vegoda Cc: Address Policy Working Group Subject: Re: [address-policy-wg] The final /8 policy proposals, part 2 My draft... On Jul 6, 2009, at 20:57, Leo Vegoda wrote: [...]
It would be helpful if RIPE NCC staff could provide statistics showing the number and size distribution of PI assignments over the last five years. It would also be good to know how much of the address space currently set aside for PI assignments remains available.
Dear Leo, IPv4 PI Number of assignments size 2004 2005 2006 2007 2008 2009 /16 0 0 1 0 0 2 /17 2 0 1 1 0 0 /18 3 1 2 3 10 2 /19 12 3 7 4 12 10 /20 23 25 28 23 44 23 /21 54 51 56 89 100 52 /22 236 260 260 260 399 192 /23 359 384 463 776 571 244 /24 551 724 895 972 1046 440 /25 11 9 22 8 8 6 /26 7 7 6 0 5 1 /27 7 4 8 8 7 2 /28 0 0 8 0 1 0 /29 0 2 1 0 8 0 total 1265 1470 1758 2151 2211 974 Note: Both /16 assignments in 2009 are temporary assignments that will be returned before the end of the year. IPv4 PI Assignment size year total IPs 2004 986400 2005 897744 2006 1153800 2007 1305312 2008 1617520 2009 881536 IPv4 Allocation numbers and sizes year number total size 2004 1001 37838336 2005 1143 57196544 2006 1213 59731968 2007 1333 62085120 2008 1649 44496896 2009 844 24535040 To put these numbers in perspective: The RIPE NCC assigns more PI prefixes than we allocate as PA, while the number of IPs assigned as PI is around 3% of the total that we assign or allocate. The RIPE NCC does not set aside address space for PI assignments larger than the current minimum allocation size, a /21, because these assignments can be made from any of our IANA allocations. We do mark some free blocks with a minimum allocation size of less than a /21 as usable for smaller PI assignments. This list is periodically reviewed and currently contains a bit over a /11 of address space. If you have any questions about these numbers, please do not hesitate to ask. Best regards, Alex Le Heux RIPE NCC
Dear Mark,
So if I understand correctly a new LIR will get at least a /21 range (IPv4)?
Maybe this should be reduced to a /24 or /23 when we reach the last /8 range.
This is correct: The minimum allocation size is a /21, as described in the IPv4 Address Policy: 5.1 First Allocation The RIPE NCC’s minimum allocation size is /21. Best regards, Alex Le Heux RIPE NCC
Hello, We are looking on getting an IPv6 PI range. But we want to use it for the same services we are running in the IPv4 world. Could you say if it is allowed under IPv6 PI (some say yes, some say no and if you ask me it should be: yes, of course it is allowed). The things we want to use IPv6 PI for: - dedicated servers (servers are owned by us) - co located servers (servers are owned by clients) - VPN (we have a few clients that use it, per VPN client at least 1 IP) - VPS guests (per VPS guest at least 1 IP) - https (per host an IP) And if it is not allowed: what would happen if we do it and someone discovers it. Thanks in advance for the answers. With kind regards, Mark Scholten
Dear Mark, We recently submitted PI request tickets to ripe for IPv4 and IPv6 with excactly the same details. The IPv4 request got assigned, the IPv6 rejected due to the difference in the policies regarding VPN connections (internet access). ----- Original message -----
The PI IPv6 assignment cannot be further assigned to other organisations. http://www.ripe.net/ripe/docs/ripe-472.html#_8._IPv6_Provider
The definition of what an Infrastructure Assignment is is different when comparing v6 and v4 policies. It is currently being discussed to align both policies.
Op 13-7-2009 15:04, Stream Service || Mark Scholten schreef:
Hello,
We are looking on getting an IPv6 PI range. But we want to use it for the same services we are running in the IPv4 world. Could you say if it is allowed under IPv6 PI (some say yes, some say no and if you ask me it should be: yes, of course it is allowed).
The things we want to use IPv6 PI for: - dedicated servers (servers are owned by us) - co located servers (servers are owned by clients) - VPN (we have a few clients that use it, per VPN client at least 1 IP) - VPS guests (per VPS guest at least 1 IP) - https (per host an IP)
And if it is not allowed: what would happen if we do it and someone discovers it.
Thanks in advance for the answers.
With kind regards,
Mark Scholten
Michiel and all, That seems terribly odd. Michiel Klaver wrote:
Dear Mark,
We recently submitted PI request tickets to ripe for IPv4 and IPv6 with excactly the same details. The IPv4 request got assigned, the IPv6 rejected due to the difference in the policies regarding VPN connections (internet access).
----- Original message -----
The PI IPv6 assignment cannot be further assigned to other organisations. http://www.ripe.net/ripe/docs/ripe-472.html#_8._IPv6_Provider
The definition of what an Infrastructure Assignment is is different when comparing v6 and v4 policies. It is currently being discussed to align both policies.
Op 13-7-2009 15:04, Stream Service || Mark Scholten schreef:
Hello,
We are looking on getting an IPv6 PI range. But we want to use it for the same services we are running in the IPv4 world. Could you say if it is allowed under IPv6 PI (some say yes, some say no and if you ask me it should be: yes, of course it is allowed).
The things we want to use IPv6 PI for: - dedicated servers (servers are owned by us) - co located servers (servers are owned by clients) - VPN (we have a few clients that use it, per VPN client at least 1 IP) - VPS guests (per VPS guest at least 1 IP) - https (per host an IP)
And if it is not allowed: what would happen if we do it and someone discovers it.
Thanks in advance for the answers.
With kind regards,
Mark Scholten
Regards, Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "YES WE CAN!" Barack ( Berry ) Obama "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 My Phone: 214-244-4827
Dear Mark,
We recently submitted PI request tickets to ripe for IPv4 and IPv6 with excactly the same details. The IPv4 request got assigned, the IPv6 rejected due to the difference in the policies regarding VPN connections (internet access).
----- Original message -----
The PI IPv6 assignment cannot be further assigned to other organisations. http://www.ripe.net/ripe/docs/ripe-472.html#_8._IPv6_Provider
The definition of what an Infrastructure Assignment is is different when comparing v6 and v4 policies. It is currently being discussed to align both
Hello, Are there people here that say that a small change of the current policy is a problem? The change would be that the list I did mention earlier is a valid reason to get a IPv6 PI range. If no one is saying that it is a problem at this moment to create a formal proposal to change it (or a new proposal based on the current one) I would like to create it the coming week. The target of the change will be to make it a little bit easier to get IPv6 PI for organizations, so more organizations could start offering their services on IPv6 (PA isn't enough for many organizations if they are not the LIR). With kind regards, Mark Scholten -----Original Message----- From: Jeffrey A. Williams [mailto:jwkckid1@ix.netcom.com] Sent: maandag 13 juli 2009 23:33 To: michiel@klaver.it Cc: Stream Service || Mark Scholten; 'Address Policy Working Group' Subject: Re: [address-policy-wg] IPv6 PI Michiel and all, That seems terribly odd. Michiel Klaver wrote: policies.
Op 13-7-2009 15:04, Stream Service || Mark Scholten schreef:
Hello,
We are looking on getting an IPv6 PI range. But we want to use it for
the
same services we are running in the IPv4 world. Could you say if it is allowed under IPv6 PI (some say yes, some say no and if you ask me it should be: yes, of course it is allowed).
The things we want to use IPv6 PI for: - dedicated servers (servers are owned by us) - co located servers (servers are owned by clients) - VPN (we have a few clients that use it, per VPN client at least 1 IP) - VPS guests (per VPS guest at least 1 IP) - https (per host an IP)
And if it is not allowed: what would happen if we do it and someone discovers it.
Thanks in advance for the answers.
With kind regards,
Mark Scholten
Regards, Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "YES WE CAN!" Barack ( Berry ) Obama "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 My Phone: 214-244-4827
Stream Service || Mark Scholten wrote:
Hello,
Are there people here that say that a small change of the current policy is a problem?
There are always people who will say that change is a problem.
The change would be that the list I did mention earlier is a valid reason to get a IPv6 PI range.
You gave a "list", quoting back from that email:
- dedicated servers (servers are owned by us) - co located servers (servers are owned by clients) - VPN (we have a few clients that use it, per VPN client at least 1) - VPS guests (per VPS guest at least 1 IP) - https (per host an IP)
How many addresses and prefixes are you talking about? How is routing arranged for these, are the in different ASNs etc? I don't see how that "list" would suddenly make you qualify for "PI" especially as there are no details at all, just that you have some hosts somewhere. "HTTPS" seems to always be a great target for claiming you need an extra IP address, but why can't you host that in PA space? DNS can be updated quite easily and voila host moved.
If no one is saying that it is a problem at this moment to create a formal proposal to change it (or a new proposal based on the current one) I would like to create it the coming week. The target of the change will be to make it a little bit easier to get IPv6 PI for organizations, so more organizations could start offering their services on IPv6 (PA isn't enough for many organizations if they are not the LIR).
And why and how don't they qualify for the current IPv6-PI rules? Greets, Jeroen
It shouldn't be the only reason to get IPv6 PI, it should be combined with a different routing policy or the usage ratio should be high enough to get another IPv6 PI range (unlikely in most cases). HTTPS - 1 IP per SSL certificate should be enough (and with IPv6 you get many IPs with a /48). Sometimes PA isn't enough (for example someone uses uplinks from 2 networks to create their own network but isn't a LIR). It may also be because changing it in the future is not nice (read: if you have many servers with different configurations an IP change makes changing networks almost impossible!). It is (or was) possible to get IPv4 PI with (almost) the same argumentation and to move those organizations to IPv6 it might be required to offer it in the IPv6 PI policy. Just changing DNS is with advanced configurations never enough to change a host. Also when servers have to be moved DNS is normally not fast enough with changing (because many DNS resolvers don't follow the TTL you did set). I didn't say they don't qualify in the current policy. I asked IF they qualify yet or not. This is because some people say yes they qualify and some others say they don't qualify. Some people say that it is not allowed to use a single IP for a VPN you or client uses and others say feel free to use 65k IPv6 addresses for that. Some people say it is not allowed to offer co location clients (they have the same routing policy) 2 IPv6 addresses if you only have IPv6 PI and others say give them 65k IPv6 addresses per server or per client. Because of the many times we moved between networks in the past we always prefer PI above PA. With IPv6 it is even more important to not change IP addresses (because of the many IP addresses you will probably use after sometime). Regards, Mark -----Original Message----- From: Jeroen Massar [mailto:jeroen@unfix.org] Sent: dinsdag 14 juli 2009 14:36 To: Stream Service || Mark Scholten Cc: 'Address Policy Working Group' Subject: Re: [address-policy-wg] IPv6 PI Stream Service || Mark Scholten wrote:
Hello,
Are there people here that say that a small change of the current policy is a problem?
There are always people who will say that change is a problem.
The change would be that the list I did mention earlier is a valid reason to get a IPv6 PI range.
You gave a "list", quoting back from that email:
- dedicated servers (servers are owned by us) - co located servers (servers are owned by clients) - VPN (we have a few clients that use it, per VPN client at least 1) - VPS guests (per VPS guest at least 1 IP) - https (per host an IP)
If no one is saying that it is a problem at this moment to create a formal proposal to change it (or a new proposal based on the current one) I would like to create it the coming week. The target of the change will be to make it a little bit easier to get IPv6 PI for organizations, so more organizations could start offering their services on IPv6 (PA isn't enough for many organizations if they are not
How many addresses and prefixes are you talking about? How is routing arranged for these, are the in different ASNs etc? I don't see how that "list" would suddenly make you qualify for "PI" especially as there are no details at all, just that you have some hosts somewhere. "HTTPS" seems to always be a great target for claiming you need an extra IP address, but why can't you host that in PA space? DNS can be updated quite easily and voila host moved. the LIR). And why and how don't they qualify for the current IPv6-PI rules? Greets, Jeroen
Stream Service || Mark Scholten wrote:
I didn't say they don't qualify in the current policy. I asked IF they qualify yet or not. This is because some people say yes they qualify and some others say they don't qualify.
IM[...]HO, as long as this uncertainty exists, which is an uncertainty as to whether there is a problem, it will be impossible to make a convincing case for a policy proposal, for the simple reason that any such proposal would not address a known problem. You say that "some people say" one thing or another. You can test what the current policy allows by making a request through your chosen LIR to the RIPE NCC. Then, when you have an answer and (in case of refusal) an explanation, you'll be in a position to state any problem that you believe exists. IHTH VBR, mvg, etc, Niall O'Reilly
Mark, could you remind me of the reasons why you (think you) cannot (or do not want to) play along with "everyone else" and become an LIR to get your own PA space? Looking at the recently distributed draft charging scheme for 2010 the financial aspects should not be that different (unless you find some LIR that offers you a free ride :-) for getting PI assigned, for whatever reason). Wilfried Stream Service || Mark Scholten wrote:
It shouldn't be the only reason to get IPv6 PI, it should be combined with a different routing policy or the usage ratio should be high enough to get another IPv6 PI range (unlikely in most cases).
HTTPS - 1 IP per SSL certificate should be enough (and with IPv6 you get many IPs with a /48).
Sometimes PA isn't enough (for example someone uses uplinks from 2 networks to create their own network but isn't a LIR). It may also be because changing it in the future is not nice (read: if you have many servers with different configurations an IP change makes changing networks almost impossible!). It is (or was) possible to get IPv4 PI with (almost) the same argumentation and to move those organizations to IPv6 it might be required to offer it in the IPv6 PI policy.
Just changing DNS is with advanced configurations never enough to change a host. Also when servers have to be moved DNS is normally not fast enough with changing (because many DNS resolvers don't follow the TTL you did set).
I didn't say they don't qualify in the current policy. I asked IF they qualify yet or not. This is because some people say yes they qualify and some others say they don't qualify.
Some people say that it is not allowed to use a single IP for a VPN you or client uses and others say feel free to use 65k IPv6 addresses for that. Some people say it is not allowed to offer co location clients (they have the same routing policy) 2 IPv6 addresses if you only have IPv6 PI and others say give them 65k IPv6 addresses per server or per client.
Because of the many times we moved between networks in the past we always prefer PI above PA. With IPv6 it is even more important to not change IP addresses (because of the many IP addresses you will probably use after sometime).
Regards, Mark
-----Original Message----- From: Jeroen Massar [mailto:jeroen@unfix.org] Sent: dinsdag 14 juli 2009 14:36 To: Stream Service || Mark Scholten Cc: 'Address Policy Working Group' Subject: Re: [address-policy-wg] IPv6 PI
Stream Service || Mark Scholten wrote:
Hello,
Are there people here that say that a small change of the current policy is a problem?
There are always people who will say that change is a problem.
The change would be that the list I did mention earlier is a valid reason to get a IPv6 PI range.
You gave a "list", quoting back from that email:
- dedicated servers (servers are owned by us) - co located servers (servers are owned by clients) - VPN (we have a few clients that use it, per VPN client at least 1) - VPS guests (per VPS guest at least 1 IP) - https (per host an IP)
How many addresses and prefixes are you talking about? How is routing arranged for these, are the in different ASNs etc?
I don't see how that "list" would suddenly make you qualify for "PI" especially as there are no details at all, just that you have some hosts somewhere.
"HTTPS" seems to always be a great target for claiming you need an extra IP address, but why can't you host that in PA space? DNS can be updated quite easily and voila host moved.
If no one is saying that it is a problem at this moment to create a formal proposal to change it (or a new proposal based on the current one) I would like to create it the coming week. The target of the change will be to make it a little bit easier to get IPv6 PI for organizations, so more organizations could start offering their services on IPv6 (PA isn't enough for many organizations if they are not
the LIR).
And why and how don't they qualify for the current IPv6-PI rules?
Greets, Jeroen
On Jul 14, 2009, at 1:42 PM, Stream Service || Mark Scholten wrote:
Hello,
Are there people here that say that a small change of the current policy is a problem? The change would be that the list I did mention earlier is a valid reason to get a IPv6 PI range.
If no one is saying that it is a problem at this moment to create a formal proposal to change it (or a new proposal based on the current one) I would like to create it the coming week. The target of the change will be to make it a little bit easier to get IPv6 PI for organizations, so more organizations could start offering their services on IPv6 (PA isn't enough for many organizations if they are not the LIR).
With kind regards,
Mark Scholten
What change are you thinking of ? If it goes in the direction to allow sub-assingment (in any way shape or form) from within a PI block I wouldn't support it. And to answer your question, I guess that there will always be some objection to change...it's in people's nature. MarcoH
I was thinking to change it that way that is will allow (in the policy) that this are also valid claims to get a IPv6 PI range and when you need an extra range you will be able to get it when you meet the earlier mentioned ratio. De-aggregation is not something that I would add (if not yet specified in the current policy). Sub allocations to clients without changing it in the RIPE database should be possible if you ask me. This way it would be possible (if you follow the policy) that it can be used for small sub-assignments to co location and/or VPN users (please note it wouldn't be registered in the RIPE database, it is the same as some current IPv4 networks use IPv4 PI address space). Some networks aren't currently a LIR, so they can't get an IPv6 PA range (if I am correct) and with this change in policy it should reduce the number of IPv6 PI request (else we would need to request a IPv6 PI range per VPN connection and/or per co location client). Regards, Mark -----Original Message----- From: Marco Hogewoning [mailto:marcoh@marcoh.net] Sent: dinsdag 14 juli 2009 14:38 To: Stream Service || Mark Scholten Cc: 'Address Policy Working Group' Subject: Re: [address-policy-wg] IPv6 PI On Jul 14, 2009, at 1:42 PM, Stream Service || Mark Scholten wrote:
Hello,
Are there people here that say that a small change of the current policy is a problem? The change would be that the list I did mention earlier is a valid reason to get a IPv6 PI range.
If no one is saying that it is a problem at this moment to create a formal proposal to change it (or a new proposal based on the current one) I would like to create it the coming week. The target of the change will be to make it a little bit easier to get IPv6 PI for organizations, so more organizations could start offering their services on IPv6 (PA isn't enough for many organizations if they are not the LIR).
With kind regards,
Mark Scholten
What change are you thinking of ? If it goes in the direction to allow sub-assingment (in any way shape or form) from within a PI block I wouldn't support it. And to answer your question, I guess that there will always be some objection to change...it's in people's nature. MarcoH
Dear Mark, Rule #1 of breaking the rules: don¹t get caught. That said, if you do break the rules and get caught, the standard applies that you get tarred and feathered and have to sing a lullaby during the next RIPE plenary session. But seriously what kind of response were you expecting? Best, Remco On 13-07-09 15:04, "Stream Service || Mark Scholten" <mark@streamservice.nl> wrote:
Hello,
We are looking on getting an IPv6 PI range. But we want to use it for the same services we are running in the IPv4 world. Could you say if it is allowed under IPv6 PI (some say yes, some say no and if you ask me it should be: yes, of course it is allowed).
The things we want to use IPv6 PI for: - dedicated servers (servers are owned by us) - co located servers (servers are owned by clients) - VPN (we have a few clients that use it, per VPN client at least 1 IP) - VPS guests (per VPS guest at least 1 IP) - https (per host an IP)
And if it is not allowed: what would happen if we do it and someone discovers it.
Thanks in advance for the answers.
With kind regards,
Mark Scholten
This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, Floor 6, 17 Thomas More Street, Thomas More Square, London E1W 1YW. Registered in England and Wales No. 6293383.
Stream Service || Mark Scholten wrote:
Hello,
We are looking on getting an IPv6 PI range. But we want to use it for the same services we are running in the IPv4 world. Could you say if it is allowed under IPv6 PI (some say yes, some say no and if you ask me it should be: yes, of course it is allowed).
The things we want to use IPv6 PI for: - dedicated servers (servers are owned by us) - co located servers (servers are owned by clients) - VPN (we have a few clients that use it, per VPN client at least 1 IP) - VPS guests (per VPS guest at least 1 IP) - https (per host an IP)
Thus exactly how much address space where you thinking for this? Don't forget the HD ratio of course. Greets, Jeroen
Hi,
We are looking on getting an IPv6 PI range. But we want to use it for the same services we are running in the IPv4 world. Could you say if it is allowed under IPv6 PI (some say yes, some say no and if you ask me it should be: yes, of course it is allowed).
Have you tried asking the RIPE resource analysts? Are you an LIR? Is there a reason you can't apply for your own PA /32 instead of getting a PI /48? Cheers, Rob -- JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG
Hello, We are not a LIR and currently there is also no plan at this moment to become a LIR in the near future. I mainly want to know if it is allowed, if it is not allowed we will not give clients IPv6 space and if they want it we forward them to also request an IPv6 PI range. With kind regards and thank for the fast answers, Mark Scholten -----Original Message----- From: Rob Evans [mailto:rhe@nosc.ja.net] Sent: maandag 13 juli 2009 15:47 To: Stream Service || Mark Scholten Cc: 'Address Policy Working Group' Subject: Re: [address-policy-wg] IPv6 PI Hi,
We are looking on getting an IPv6 PI range. But we want to use it for the same services we are running in the IPv4 world. Could you say if it is allowed under IPv6 PI (some say yes, some say no and if you ask me it should be: yes, of course it is allowed).
Have you tried asking the RIPE resource analysts? Are you an LIR? Is there a reason you can't apply for your own PA /32 instead of getting a PI /48? Cheers, Rob -- JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG
On 13/07/2009 9:05, "Stream Service || Mark Scholten" <mark@streamservice.nl> wrote:
Hello,
We are not a LIR and currently there is also no plan at this moment to become a LIR in the near future. I mainly want to know if it is allowed, if it is not allowed we will not give clients IPv6 space and if they want it we forward them to also request an IPv6 PI range.
The policy governing IPv6 PI assignments is published here: http://www.ripe.net/ripe/docs/ripe-472.html#_8._IPv6_Provider Other than not being an LIR, you need to demonstrate that you will be multi-homed and able to sign the contract. Regards, Leo
On Wed, 2009-07-08 at 16:43 +0200, Alex Le Heux wrote:
IPv4 PI Number of assignments
size 2004 2005 2006 2007 2008 2009 /16 0 0 1 0 0 2 /17 2 0 1 1 0 0 /18 3 1 2 3 10 2 /19 12 3 7 4 12 10 /20 23 25 28 23 44 23 /21 54 51 56 89 100 52 /22 236 260 260 260 399 192 /23 359 384 463 776 571 244 /24 551 724 895 972 1046 440 /25 11 9 22 8 8 6 /26 7 7 6 0 5 1 /27 7 4 8 8 7 2 /28 0 0 8 0 1 0 /29 0 2 1 0 8 0 total 1265 1470 1758 2151 2211 974
Do you have the data to split these numbers across two tables, one with 1st assignment to new registrants and one with extensions? //per
Dear Per, On Jul 9, 2009, at 17:41, Per Heldal wrote:
On Wed, 2009-07-08 at 16:43 +0200, Alex Le Heux wrote:
IPv4 PI Number of assignments
size 2004 2005 2006 2007 2008 2009 /16 0 0 1 0 0 2 /17 2 0 1 1 0 0 /18 3 1 2 3 10 2 /19 12 3 7 4 12 10 /20 23 25 28 23 44 23 /21 54 51 56 89 100 52 /22 236 260 260 260 399 192 /23 359 384 463 776 571 244 /24 551 724 895 972 1046 440 /25 11 9 22 8 8 6 /26 7 7 6 0 5 1 /27 7 4 8 8 7 2 /28 0 0 8 0 1 0 /29 0 2 1 0 8 0 total 1265 1470 1758 2151 2211 974
Do you have the data to split these numbers across two tables, one with 1st assignment to new registrants and one with extensions?
As this table concerns PI space, the vast majority of holders have only a single assignment. Therefore almost all of these concern new registrants. Best regards, Alex Le Heux RIPE NCC
On Jul 6, 2009, at 10:07 AM, Per Heldal wrote:
On Sun, 2009-07-05 at 11:12 +0200, Sander Steffann wrote:
Hello WG,
I want to continue the discussion about the Final /8 proposals (2008-06 and 2009-04). The responses to my last question ("Do we (this working group) want to put IPv6 related requirements in the policy?") were 100% negative: We don't want IPv6 related requirements in the Final /8 policy.
I think APNIC has got it mostly right. To reserve some space for transition-services is the only suggestion I've seen that can have a lasting effect throughout the transition period. Everything else has been/is about skewing the balance to change who gets most out of the remaining chunks.
Keep it simple. One single fixed-size block for each new registrant that qualify for or already has a v6 block, and no prior v4 allocation.
A whole /8 for might be more than necessary for this though. How many /20 - /22 -size allocations does RIPE-NCC make each year where the registrant has no prior allocation?
The intention of such a policy is IMHO primarily to protect new innovative players from abuse (extortion) by the V4 powerhouses. Once established they should seek expansion elsewhere (v6) or compete for the same resources as everyone else. One-size-fits all is therefore appropriate, as it would be near impossible for the NCC to differentiate.
This more or less makes sense, you might define these blocks as "PI" to circumvent the whole membership discussion and wether or not a reciver of such block should need to be PI. MarcoH
participants (20)
-
Alex Le Heux -
Andreas Schachtner -
David Freedman -
Florian Weimer -
Gert Doering -
Jeffrey A. Williams -
Jeroen Massar -
Leo Vegoda -
Marco Hogewoning -
Michiel Klaver -
Niall O'Reilly -
Per Heldal -
Peter Koch -
Randy Bush -
Remco van Mook -
Rob Evans -
Sander Steffann -
Stream Service -
Stream Service || Mark Scholten -
Wilfried Woeber, UniVie/ACOnet