2010-02 New Draft Document Published (Allocations from the last /8)
PDP Number: 2010-02 Allocations from the last /8 Dear Colleagues, The text of the policy proposal 2010-02 has been revised based on the community feedback received on the mailing list. The draft policy document and the impact analysis for the proposal have also been published. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2010-02.html and the draft document at: http://www.ripe.net/ripe/draft-documents/ripe-492-draft2010-02.html We encourage you to read the draft document text and send any comments to address-policy-wg@ripe.net before 4 August. Regards Emilio Madaio Policy Development Officer RIPE NCC
Hi All, I see the policy proposal now deny PI at all. Why? Those who requsted PI (through us) usually are not so big to become a LIR and request /20. They even don't need it. By this proposal, you will stimulate small companies become a LIR and get /22 instead of for example /24 PI. For my point of view, there should not be a difference between PA and PI distribution in the policy. Better is to make some actions to allow de-aggregate prefixes to more than /24. Then those who need /29 will ask for /29, not for /24 PI (now) or even /22 PA (if 2010-02 will be in power). Emilio Madaio написав(ла):
PDP Number: 2010-02 Allocations from the last /8
Dear Colleagues,
The text of the policy proposal 2010-02 has been revised based on the community feedback received on the mailing list.
The draft policy document and the impact analysis for the proposal have also been published.
You can find the full proposal at:
http://www.ripe.net/ripe/policies/proposals/2010-02.html
and the draft document at:
http://www.ripe.net/ripe/draft-documents/ripe-492-draft2010-02.html
We encourage you to read the draft document text and send any comments to address-policy-wg@ripe.net before 4 August.
Regards
Emilio Madaio Policy Development Officer RIPE NCC
-- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
Max, /29 in the global routing table is a bad thing. Those who need multihoming may use PA address space. Now, when contracts to support address space are necessery, there isn't much dfference between PI and PA. 2010/7/7 Max Tulyev <president@ukraine.su>:
Hi All,
I see the policy proposal now deny PI at all. Why?
Those who requsted PI (through us) usually are not so big to become a LIR and request /20. They even don't need it. By this proposal, you will stimulate small companies become a LIR and get /22 instead of for example /24 PI.
For my point of view, there should not be a difference between PA and PI distribution in the policy. Better is to make some actions to allow de-aggregate prefixes to more than /24. Then those who need /29 will ask for /29, not for /24 PI (now) or even /22 PA (if 2010-02 will be in power).
Emilio Madaio написав(ла):
PDP Number: 2010-02 Allocations from the last /8
Dear Colleagues,
The text of the policy proposal 2010-02 has been revised based on the community feedback received on the mailing list.
The draft policy document and the impact analysis for the proposal have also been published.
You can find the full proposal at:
http://www.ripe.net/ripe/policies/proposals/2010-02.html and the draft document at:
http://www.ripe.net/ripe/draft-documents/ripe-492-draft2010-02.html
We encourage you to read the draft document text and send any comments to address-policy-wg@ripe.net before 4 August.
Regards
Emilio Madaio Policy Development Officer RIPE NCC
-- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
-- Regards, Gennady Abramov
Gennady, for now it is bad. But when there will be a lack of IPv4, we have to sacrifice aggregation in favour to conservation. The difference is the independence. PA is not. Gennady A. написав(ла):
Max, /29 in the global routing table is a bad thing.
Those who need multihoming may use PA address space. Now, when contracts to support address space are necessery, there isn't much dfference between PI and PA.
-- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
Hi Max, The proposal has *never* been about PI, ever. Alain and I were requested to include specific wording to that effect. So we did. :-) Best wishes, philip -- Max Tulyev said the following on 7/07/10 20:36 :
Hi All,
I see the policy proposal now deny PI at all. Why?
Those who requsted PI (through us) usually are not so big to become a LIR and request /20. They even don't need it. By this proposal, you will stimulate small companies become a LIR and get /22 instead of for example /24 PI.
For my point of view, there should not be a difference between PA and PI distribution in the policy. Better is to make some actions to allow de-aggregate prefixes to more than /24. Then those who need /29 will ask for /29, not for /24 PI (now) or even /22 PA (if 2010-02 will be in power).
Emilio Madaio написав(ла):
PDP Number: 2010-02 Allocations from the last /8
Dear Colleagues,
The text of the policy proposal 2010-02 has been revised based on the community feedback received on the mailing list.
The draft policy document and the impact analysis for the proposal have also been published.
You can find the full proposal at:
http://www.ripe.net/ripe/policies/proposals/2010-02.html and the draft document at:
http://www.ripe.net/ripe/draft-documents/ripe-492-draft2010-02.html
We encourage you to read the draft document text and send any comments to address-policy-wg@ripe.net before 4 August.
Regards
Emilio Madaio Policy Development Officer RIPE NCC
Hi Philip, there is "Under the current policies, when this proposed policy is triggered, the RIPE NCC will no longer assign ASSIGNED PI and ASSIGNED ANYCAST space." right now at the proposal page. I (and not only me) mean after the policy is in power, RIPE NCC will stop assign PI/ANYCAST at all. I can imagine why it can be with PI, but why ANYCAST? ;) Philip Smith написав(ла):
Hi Max,
The proposal has *never* been about PI, ever. Alain and I were requested to include specific wording to that effect. So we did. :-)
Best wishes,
philip --
Max Tulyev said the following on 7/07/10 20:36 :
Hi All,
I see the policy proposal now deny PI at all. Why?
Those who requsted PI (through us) usually are not so big to become a LIR and request /20. They even don't need it. By this proposal, you will stimulate small companies become a LIR and get /22 instead of for example /24 PI.
For my point of view, there should not be a difference between PA and PI distribution in the policy. Better is to make some actions to allow de-aggregate prefixes to more than /24. Then those who need /29 will ask for /29, not for /24 PI (now) or even /22 PA (if 2010-02 will be in power).
Emilio Madaio написав(ла):
PDP Number: 2010-02 Allocations from the last /8
Dear Colleagues,
The text of the policy proposal 2010-02 has been revised based on the community feedback received on the mailing list.
The draft policy document and the impact analysis for the proposal have also been published.
You can find the full proposal at:
http://www.ripe.net/ripe/policies/proposals/2010-02.html and the draft document at:
http://www.ripe.net/ripe/draft-documents/ripe-492-draft2010-02.html
We encourage you to read the draft document text and send any comments to address-policy-wg@ripe.net before 4 August.
Regards
Emilio Madaio Policy Development Officer RIPE NCC
-- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
On 7 Jul 2010, at 23:16, Philip Smith wrote:
The proposal has *never* been about PI, ever. Alain and I were requested to include specific wording to that effect. So we did. :-)
I'm not sure the words have been picked though. :-) What is the rationale to stop assigning PI ? The PI ban appears to have been introduced between v1 and v2 of this draft, where was the discussion that led to this wording ? The spirit of the proposal appears to be to conserve v4 addressing, to assist with v6 adoption. Fine. But, what about for multihomed end sites that do not need a /22, or have ncc memebrship budget ? What's the *real* difference between an LIR with one end user (their own infrastructure), and a non-LIR with PI ? Other than €1,300 a year... Andy
Hi, On Thu, Jul 08, 2010 at 04:58:00PM +0100, Andy Davidson wrote:
The spirit of the proposal appears to be to conserve v4 addressing, to assist with v6 adoption. Fine. But, what about for multihomed end sites that do not need a /22, or have ncc memebrship budget ? What's the *real* difference between an LIR with one end user (their own infrastructure), and a non-LIR with PI ? Other than ?1,300 a year...
Well, the basic question is "what do we want to do with the last /8"? So far, the only proposal that had any chance of coming near consensus was "chop it in small pieces, give every existing and possible future LIR a *single* piece, and nothing more, ever". The intent is "those that roll out new networks will use IPv6, but are likely to need a few addresses for their translation services" - and since it's very hard to formulate RS-applicable criteria for that, simplicity is our friend here: "a single chunk, done". Let's not forget that IPv4 is running out. So a debate about IPv4 PI space from the last /8 is somewhat moot - basing business decisions on the availability of IPv4 address space is a very very bad idea. It *will* run out, no matter what we do - the only question remaining is "will we able to lessen the pain (especially for future entrants into this arena) a bit with this policy, or not". If you all think that this policy should look different, please voice specific proposals how to change it... but hurry up, because if we spend a year discussing it, there is no IPv4 space left to haggle about. Gert Doering, Address Policy WG Chair -- Total number of prefixes smaller than registry allocations: 150584 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
Am 08.07.2010 18:22, schrieb Gert Doering:
On Thu, Jul 08, 2010 at 04:58:00PM +0100, Andy Davidson wrote:
The spirit of the proposal appears to be to conserve v4 addressing, to assist with v6 adoption. Fine. But, what about for multihomed end sites that do not need a /22, or have ncc memebrship budget ? What's the *real* difference between an LIR with one end user (their own infrastructure), and a non-LIR with PI ? Other than ?1,300 a year...
The $1300 won't matter anymore very soon. People will be willing to pay much more to get a handful of /24.
Well, the basic question is "what do we want to do with the last /8"?
So far, the only proposal that had any chance of coming near consensus was "chop it in small pieces, give every existing and possible future LIR a *single* piece, and nothing more, ever".
The intent is "those that roll out new networks will use IPv6, but are likely to need a few addresses for their translation services" - and since it's very hard to formulate RS-applicable criteria for that, simplicity is our friend here: "a single chunk, done".
Let's not forget that IPv4 is running out. So a debate about IPv4 PI space from the last /8 is somewhat moot - basing business decisions on the availability of IPv4 address space is a very very bad idea.
It should contain a statement about PI space nevertheless, something like "once the first block of last /8 is given out, only /24 PI blocks are given out from the remaining PI aggregation, as long as available". My $0.02 F.
On 7/8/10 2:30 PM, "Fredy Kuenzler" <kuenzler@init7.net> wrote:
Am 08.07.2010 18:22, schrieb Gert Doering:
On Thu, Jul 08, 2010 at 04:58:00PM +0100, Andy Davidson wrote:
The spirit of the proposal appears to be to conserve v4 addressing, to assist with v6 adoption. Fine. But, what about for multihomed end sites that do not need a /22, or have ncc memebrship budget ? What's the *real* difference between an LIR with one end user (their own infrastructure), and a non-LIR with PI ? Other than ?1,300 a year...
The $1300 won't matter anymore very soon. People will be willing to pay much more to get a handful of /24.
I'm not sure that a lot needs to change from status quo to accomplish the goals of supporting transition. Conservation concepts are late to the game and not useful from my perspective. Perhaps the proposal could have done something smaller but more comprehensive like link a requirement of dual stacking to allocations from the last /8 and defined a list of acceptable uses such as NAT64, router loopbacks, point to point links, peering, enough to keep us in business but enough to make sure that anything handed out at this point is directly supporting the transition? Holding space for "what if" is interesting, but possibly wasteful at this late stage and perhaps even creates contention as to "what" to use it for. I like the idea of raising the minimum allocation unit, but I would have defined it as a control measure, perhaps pushing up efficiency of utilization by pushing the envelope of availability to some extent? YMMV, and best, -M<
So far, the only proposal that had any chance of coming near consensus was "chop it in small pieces, give every existing and possible future LIR a *single* piece, and nothing more, ever".
and that was the consensus reached in apnic.
The intent is "those that roll out new networks will use IPv6, but are likely to need a few addresses for their translation services" - and since it's very hard to formulate RS-applicable criteria for that, simplicity is our friend here: "a single chunk, done".
'zactly
It *will* run out, no matter what we do - the only question remaining is "will we able to lessen the pain (especially for future entrants into this arena) a bit with this policy, or not".
for a long while, we have used conserving routing table space to place a barrier to entry to the market. this proposal removes that for future entrants who need a teensie bit of v4 to front to the legacy v4 part of the dual stack network. randy
On 8 Jul 10, at 9:42 PM, Randy Bush wrote:
It *will* run out, no matter what we do - the only question remaining is "will we able to lessen the pain (especially for future entrants into this arena) a bit with this policy, or not".
for a long while, we have used conserving routing table space to place a barrier to entry to the market. this proposal removes that for future entrants who need a teensie bit of v4 to front to the legacy v4 part of the dual stack network.
As implied, this proposal enables future entrants at the expense of routing table conservation. To what extent should the RIR community be concerned about enabling access / competition, versus the ongoing operation of existing networks? Whether we're discussing an IPv4 market or the market for transitionary network services, there are organizations prepared to facilitate new entrants. A "chop it in small pieces" policy would not extend the life of IPv4 indefinitely; we will run out, and these markets will be the only option. Until then, these markets would be artificially devalued. Further, this policy may lead to wasted IPv4 resources if new organizations do not emerge to consume the remaining space. Existing networks may struggle due to inadequate IPv4 resources, while the reserved pool sits unclaimed. The worst case is where all of the above exists together: wasted IPv4 resources in an unclaimed pool, devalued transitionary markets, and network providers unable to grow their services while facing the operational impact of a growing routing table. I would feel much better about this policy if it allowed for subsequent /22 assignments over time. Perhaps a limit of 1 assignment per 90 days, or something along those lines. -Benson
On 08/07/2010 16:58, Andy Davidson wrote:
What is the rationale to stop assigning PI ?
I, too, am very concerned that PI has been dropped as a consideration from the last /8. This will disenfranchise a disproportionately large number of end users. Nick
From the analysis:
This address space may not be a single aggregated /8 and can contain prefixes as long as a /29 or more. Therefore it is possible that at some point the RIPE NCC will be unable to allocate a single /22 block to an LIR and will have to allocate multiple prefixes that total 1,024 IP addresses. Because of this situation, there will effectively no longer be a minimum allocation size within the RIPE NCC service region when this happens.
As I understand it, RIPE NCC is guaranteed to receive one last contiguous /8 from IANA (cf. http://www.icann.org/en/general/allocation-remaining-ipv4-space.htm section 2.1). I think it would be prudent to reserve this particular /8 for the implementation of this policy, instead of specifying «a threshold of a total of one /8». That way the potential problem with fragmentation will only occur once the entire /8 has been allocated and the only thing that is remaining in the pool is returned allocations smaller than /22.
From the proposed policy:
a. LIRs may only receive one allocation from this /8. The size of the allocation made under this policy will be no larger than a /22.
This obviously conflicts with the current minimum allocation size (/21). Does the proposed policy intend to change the minimum allocation size to /22 so that all LIRs are eligible to receive a /22 (no more, no less), or to remove the minimum allocation size completely as suggested by the analysis - even when contiguous /22s are available in the unallocated pool? The language of the policy seems to imply the latter, as it says specifically «no larger» and «at most» (but makes no mention of «no smaller» and/or «at minimum»). I can easily see that being perceived as unfair, as one RIR might only be allocated a /23 at first and then be unable to come back later for another /23 (due to the one allocation only rule). So I'd favour it being a /22, no more, no less (until fragmentation makes that impossible). Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27
Hi Tore, Tore Anderson said the following on 7/07/10 23:01 :
This obviously conflicts with the current minimum allocation size (/21). Does the proposed policy intend to change the minimum allocation size to /22 so that all LIRs are eligible to receive a /22 (no more, no less), or to remove the minimum allocation size completely as suggested by the analysis - even when contiguous /22s are available in the unallocated pool?
As you observe, minimum allocation of /21 makes no sense for a policy proposing maximum allocation of /22. Alain and I hadn't intended to document a minimum allocation size, but I certainly feel that it is very unlikely we'll see requests for allocations smaller than a /22 (I could be wrong of course). My preference is to leave it open so that folks wanting a smaller allocation can get it. philip --
* Philip Smith
Tore Anderson said the following on 7/07/10 23:01 :
This obviously conflicts with the current minimum allocation size (/21). Does the proposed policy intend to change the minimum allocation size to /22 so that all LIRs are eligible to receive a /22 (no more, no less), or to remove the minimum allocation size completely as suggested by the analysis - even when contiguous /22s are available in the unallocated pool?
As you observe, minimum allocation of /21 makes no sense for a policy proposing maximum allocation of /22. Alain and I hadn't intended to document a minimum allocation size, but I certainly feel that it is very unlikely we'll see requests for allocations smaller than a /22 (I could be wrong of course). My preference is to leave it open so that folks wanting a smaller allocation can get it.
Hi Philip, my concern is not with LIRs that for some reason or another want a longer prefix than a /22, but with LIRs that cannot justify an immediate assignment of a /22. Remember that 12 months from now, LIRs will be allocated space to cover the needs for a period to up to three months only (cf. ripe-492, section 5.0). I don't see anything in the current proposal that allows the NCC to disregard this rule. Not all LIRs will go through a /22 in three months. As I understand it, with no minimum allocation size in place, the NCC would have no choice but to deny any requests for /22 coming from these LIRs. And because of the one allocation only rule, they will be unable to come back and request more space after they've gone through the /23 (or longer) they were able to immediately justify. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27
participants (12)
-
Andy Davidson
-
Benson Schliesser
-
Emilio Madaio
-
Fredy Kuenzler
-
Gennady A.
-
Gert Doering
-
Martin Hannigan
-
Max Tulyev
-
Nick Hilliard
-
Philip Smith
-
Randy Bush
-
Tore Anderson