Keyboard Shortcuts
Thread View
j: Next unread messagek: Previous unread messagej a: Jump to all threadsj l: Jump to MailingList overview
On Wed, 14 Feb 2007 09:04:35 +0900 Takashi Arano wrote:
If someone can propose a graduated approach, then we can compare it with the proposed policy.
Firstly let me apologise if I have missed something in this debate on the proposed policy and well done to the authors for addressing this critical and intractable issue.
I see the proposals for Global synchronization as very attractive and hopefully progress can be made here.
Like David Conrad I believe a graduated approach to rationing would be a more appropriate response than maintaining current policies. A gradual(?) tightening of the allocation criteria over the next few years, as certain promulgated thresholds are passed, would have three principal effects:
a) It would extend the life of the remaining pool (making the proposal to retain blocks of v4 address space against some unanticipated need unnecessary) and
b) It would provide more certainty on allocation principals in the run up to ultimate exhaustion and,
c) Provide a motivation to ISP's to do something with v6 (which for all it's problems seems to be the only long term solution on offer).
Remaining with existing policies until exhaustion (real or artificial) would, I suspect, not only lead to chaos for those whose countries/ businesses/ customers require new allocations but also generate an active trading market (either black or otherwise) in allocations.
At the moment there is no incentive for ISP's to adopt potential solutions to v4 exhaustion such as dual v4/v6 stack as the deployment costs are relatively high and the benefits for an individual ISP are, at best, negligible.
I'd suggest that the countdown policy should include measures to first promote and later require some of the steps for an orderly transition to the deployment of v6.
In other words a first step could be (say) a requirement for some deployment of v6 in order to qualify for further allocations of v4 space. This measure alone would raise the bar on obtaining allocations and require some of the real problems of migration to v6 to start being addressed.
Clearly it would be difficult to enforce large v6 deployment but as a first step it should be relatively easy to devise a simple test that a member has some dual stack connectivity?
Other measures such as trading and recycling of v4 space are desperately required but should not delay the development of a countdown roadmap.
At 03:15 07/02/15, Robert Gray wrote:
If someone can propose a graduated approach, then we can compare it with the proposed policy.
Like David Conrad I believe a graduated approach to rationing would be a more appropriate response than maintaining current policies. A gradual(?) tightening of the allocation criteria over the next few years, as certain promulgated thresholds are passed, would have three principal effects:
A graduated approach means that some portions of addresses which can be currently justified to allocate will not be justified in any new graduated policy. In other words, it says the policy will have to be becoming tighter gradually.
My question is HOW. I personally can't imagine which kind of policy will achieve this goal. Even if there are any, who in the world can agree with a new policy which makes him/her giving up requesting addresses or just getting significatly fewer addresses? I guess It would be more tough discussion than the proposed policy will cause.
This is why we have proposed a very simple policy.
Please indicate your idea about what a graduated approach is like even a little bit concretely, if you prefer.
Regards, Takashi Arano
Takashi Arano wrote:
My question is HOW. I personally can't imagine which kind of policy will achieve this goal. Even if there are any, who in the world can agree with a new policy which makes him/her giving up requesting addresses or just getting significatly fewer addresses? I guess It would be more tough discussion than the proposed policy will cause.
Arano-san,
Fair question.
Firstly I was not suggesting any reduction in allocations, clearly to avoid a chaos in the short term applicants need to continue to receive allocations of IPv4 space appropriate to their needs. It was also my suggestion that there would be no artificial retention of space, we'd see allocations down to the last block to allow as long as possible for migration.
The suggestion is that additional criteria for allocation be progressively brought in to make applicants implement IPv6 technologies rather than ignoring it for the most part. I was not envisaging any change to the current criteria.
There has been substantial discussion of IPv6 on the NZNOG list and one of the conclusions I have drawn is that, as with global warming, the threat of exhaustion is inadequate to drive significant action. Commercial imperatives see only the costs and the long term benefits of IPv6 implementation are too remote to allow money to be spent.
Indeed in this part of the world IPv6 transit is simply not available except by tunnelling. My suggestion is to artificially generate demand for action, rather like the Carbon Credits scheme is supposed to motivate people to take useful actions over global warming. It may not work but that is not an adequate reason for taking no action.
For the purposes of illustration only here is a small list of hurdles that could be imposed. I'm a little reluctant to do this as they all could all be objected to on various grounds but perhaps we need to be specific here. The dates are just for illustration!
1. Applicants could be asked to demonstrate that they have implemented a dual stack system somewhere on their network by end 2007
2. By end 2008 a requirement could be that an infrastructural item on their network is dual stack (eg a mail or web server)
3. All visible infrastructural items on the network to be dual stack by end 2009 (also an easy test to automate)
4. A commitment to only deploy dual stack CPE by end 2009 (just a promise but that's the case about a lot of the current requirements)
5. Demonstrate that dual stack equipment is being deployed and perhaps a percentage of current allocation is IPv6 capable by 2010
6. By 2011 a free IPv4 market is established and address space can be traded at market prices. RIR policies are modified to effectively sell new IPv4 space at the market price to prevent arbitrage opportunities.
Sure there are policing issues and people will perhaps not be as truthful as they might. However something needs to start driving IPv6 deployment or I believe we will see some serious problems as IPv4 runs out.
Thank you for your consideration.
Arano-san,
On Feb 15, 2007, at 8:53 AM, Takashi Arano wrote:
A graduated approach means that some portions of addresses which can be currently justified to allocate will not be justified in any new graduated policy. In other words, it says the policy will have to be becoming tighter gradually.
Right.
My question is HOW. I personally can't imagine which kind of policy will achieve this goal.
Some potential examples:
- Currently, APNIC has an "80% rule". Create a policy that when the current free pool is reduced by 50%, make it a 90% rule. When the remaining free pool is reduced by another 50%, make it a 95% rule. Etc.
- Currently, APNIC has no requirement to demonstrate IPv6 support. When the free pool is reduced 25%, APNIC institutes a rule that organization to which new allocations are made must demonstrate their infrastructure is IPv6 capable. When the remaining free pool is reduced another 25%, organizations to which new allocations are made must demonstrate 10% of their customers are IPv6 capable. Etc.
- Currently, APNIC recommends organisations should base their assignment requests on the assumption that 25 percent of the address space will be used immediately and 50 percent used within one year. When the free pool is reduced by 25%, these values should increase to 50 and 75 percent respectively. When the free pool is reduced by 50%, these values should increase to 75 and 90 percent respectively. Etc.
I'm sure there are many others. Mix and match as appropriate. The key bit is that the increasing requirements should be automatic so the policy doesn't need to be modified.
Even if there are any, who in the world can agree with a new policy which makes him/her giving up requesting addresses or just getting significatly fewer addresses?
People put up with the imposition of the existing policies because they felt it was the best way to manage the address space. Would this be different?
Rgds, -drc
Hi David,
David Conrad wrote:
Arano-san,
On Feb 15, 2007, at 8:53 AM, Takashi Arano wrote:
A graduated approach means that some portions of addresses which can be currently justified to allocate will not be justified in any new graduated policy. In other words, it says the policy will have to be becoming tighter gradually.
Right.
My question is HOW. I personally can't imagine which kind of policy will achieve this goal.
Some potential examples:
- Currently, APNIC has an "80% rule". Create a policy that when the
current free pool is reduced by 50%, make it a 90% rule. When the remaining free pool is reduced by another 50%, make it a 95% rule. Etc.
Arano-san and I have discussed this approach already. But we conclude, at least at this moment, that this makes the issue more complex. We have two choices here. 1) keep as is till the end we define, or 2) gradually narrow down to the end we fine. We need to define the goal (or the end) of IPv4 allocation timing, anyway. Approach 2 requires another decision of when to apply the gradual reduced allocation policy.
So, the point at this moment, I beilieve, is that we need to set the timing when RIR should halt the IPv4 allocation. To define the gradual level of what extent we need to reduce should be the next step of issue, if we found that our current proposed approach does not provide enough time range for communities to shift into IPv6.
- Currently, APNIC has no requirement to demonstrate IPv6 support.
When the free pool is reduced 25%, APNIC institutes a rule that organization to which new allocations are made must demonstrate their infrastructure is IPv6 capable. When the remaining free pool is reduced another 25%, organizations to which new allocations are made must demonstrate 10% of their customers are IPv6 capable. Etc.
- Currently, APNIC recommends organisations should base their
assignment requests on the assumption that 25 percent of the address space will be used immediately and 50 percent used within one year. When the free pool is reduced by 25%, these values should increase to 50 and 75 percent respectively. When the free pool is reduced by 50%, these values should increase to 75 and 90 percent respectively. Etc.
I'm sure there are many others. Mix and match as appropriate.
There are many ideas. But these details may not be necessary if we choose a basic principle of simplicity. Our current proposal is based on this.
The key bit is that the increasing requirements should be automatic so the policy doesn't need to be modified.
Humm, Increasing requirements means changing the policy, doesn't it?
One day, I apply a /16, Next day David apply a /16. I got a full /16, but David got a 95% of /16. Is this under the same policy? Is this acceptable? or am I misunderstanding your point?
Even if there are any, who in the world can agree with a new policy which makes him/her giving up requesting addresses or just getting significatly fewer addresses?
People put up with the imposition of the existing policies because they felt it was the best way to manage the address space. Would this be different?
Existing policy does not cover for RIRs how to deal with allocating the last peice in their pool.
Best regards,
Kosuke
Rgds, -drc
sig-policy: APNIC SIG on resource managementpolicy * _______________________________________________ sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
Ito-san,
On Feb 15, 2007, at 6:19 PM, Kosuke Ito wrote:
We have two choices here. 1) keep as is till the end we define, or 2) gradually narrow down to the end we fine. We need to define the goal (or the end) of IPv4 allocation timing, anyway.
Do we?
Approach 2 requires another decision of when to apply the gradual reduced allocation policy.
The idea behind approach 2 is that anyone can still request IPv4 address space if they meet the (increasingly stringent as the free pool is reduced) requirements. It's sort of like Zeno's Paradox (http://www.mathacademy.com/pr/prime/articles/zeno_tort/index.asp). There is no need to set an arbitrary deadline.
To define the gradual level of what extent we need to reduce should be the next step of issue, if we found that our current proposed approach does not provide enough time range for communities to shift into IPv6.
Perhaps I'm too cynical, but I believe that since IPv6 provides insufficient benefit over IPv4 for folks to voluntarily shift, people will not shift to IPv6 until they are forced to. By setting an arbitrary deadline, particularly with setting aside blocks as reserved, I suspect we'd be creating a very fertile ground for "unpleasantness" and demands for changes in policy at the last second.
Humm, Increasing requirements means changing the policy, doesn't it?
Not if the increasing requirements are built into the policy (e.g., when 50% of the remaining address free pool as of date X is reached, do Y. When 50% of that remaining free pool (or 75% of the original free pool) is reached, do Z. Etc.)
One day, I apply a /16, Next day David apply a /16. I got a full /16, but David got a 95% of /16.
I was thinking more of making the requirements more harsh, not what is allocated, but I guess the end result is the same.
Is this under the same policy?
That's the idea.
Is this acceptable?
The alternative is on day X, I could get address space and on day X +1, I couldn't. (I suspect I'd try really, really hard to get my request approved by day X and since there would be a lot of people like me, the registration services folks at APNIC are going to be _really_ _really_ busy on days X-N to X).
Rgds, -drc
the basic trade-off that seems to be under discussion is between staying the course and running out of v4 space on day X while folk get what they need until then, versus giving folk less and less of what they need until day X+Y (you have some good ideas, if one buys into the model in the first place). slow long pain versus one major sharp pain.
but the slow long approach would seem to encourage sick half-solutions, such as (even more) massive nat deployment etc.
but then there is the bright idea of holding some in reserve so we can have some wonderful, very high stake, wars over who gets it and why. this scares me more than either of the above two scenarios. but i am sure we will get a lot of help divvying it up from the governments, itu, lawyers, and politicians. we will totally destroy what is left of cooperative internet stewardship in this process.
the slow versus sharp pain decision seems trivial when compared to the extreme pain of the wars of divvying up a reserve. let's not go there.
randy
Randy,
On Feb 16, 2007, at 11:25 AM, Randy Bush wrote:
slow long pain versus one major sharp pain.
Or boiling the frog...
but the slow long approach would seem to encourage sick half- solutions, such as (even more) massive nat deployment etc.
To be honest, I'm having some difficulty imagining realistic scenarios of future Internet growth that do not require (even more) massive deployment of NAT. If for no other reason than IPv6-only sites (since folks won't be able to get IPv4 addresses) communicating with IPv4 sites (i.e., the vast majority of the Internet).
I'm not sure I see how a major sharp pain would reduce the need for (even more) massive deployment of NAT. At least with slow long pain, there is more of a chance that folks will finish deploying the parallel IPv6 Internet so massive NATing isn't as necessary...
Rgds, -drc
drc,
slow long pain versus one major sharp pain.
Or boiling the frog...
frogs may be neurologically primitive, but they're not *that* primitive.
but the slow long approach would seem to encourage sick half- solutions, such as (even more) massive nat deployment etc.
To be honest, I'm having some difficulty imagining realistic scenarios of future Internet growth that do not require (even more) massive deployment of NAT. If for no other reason than IPv6-only sites (since folks won't be able to get IPv4 addresses) communicating with IPv4 sites (i.e., the vast majority of the Internet).
I'm not sure I see how a major sharp pain would reduce the need for (even more) massive deployment of NAT. At least with slow long pain, there is more of a chance that folks will finish deploying the parallel IPv6 Internet so massive NATing isn't as necessary...
i can accept that. in fact, i can even see a universe where there is v4/v4 address translation between major isps and forget v6; sean doran may be first to publicly propose this some years back.
but my point was that this trade-off space has far less destructive consequences than the proposal of a reserve.
randy
Randy Bush wrote:
but then there is the bright idea of holding some in reserve so we can have some wonderful, very high stake, wars over who gets it and why. this scares me more than either of the above two scenarios. but i am sure we will get a lot of help divvying it up from the governments, itu, lawyers, and politicians. we will totally destroy what is left of cooperative internet stewardship in this process.
The pirates treasure of the last several /8's would prove irresistible for a high stakes scrap, you can easily imagine the lawyers circling the RIR's. I too hope no one wants to go there.
the slow versus sharp pain decision seems trivial when compared to the extreme pain of the wars of divvying up a reserve. let's not go there.
My concern is the that for many (most?) existing players the exhaustion of IPv4 space, whether real or artificial, is not a sharp enough pain for immediate migration. Many users are sitting on adequate allocations for their needs, in some cases historical and in others use of NAT has slowed or even halted growth in their use of IPv4 space.
The point here is that new entrants (regardless of the quality of their plans) and developing counties will bear the greatest pain from IPv4 exhaustion. They are also the least able to use IPv6 only as a solution.
I can imagine large countries in need of IPv4 space arbitrarily using space allocated to others, particularly if such space is 'invisible' or used by remote/small countries with little global clout. Sure this might not get globally routed but it could still be better than no space at all?
Regardless, when we do run out, there is lots of potential for fracturing the internet. The good news is that we have the opportunity to do something positive about it as five (or more) years available is adequate time to plan and deploy a bulk of a solution.
My concern with this proposal is that it seems to avoid the hard issues of a migration plan or an IPv4 trading market that will not only be necessary but I suspect will appear anyway (probably on eBay).
At 04:25 07/02/17, Randy Bush wrote:
but then there is the bright idea of holding some in reserve so we can have some wonderful, very high stake, wars over who gets it and why. this scares me more than either of the above two scenarios. but i am sure we will get a lot of help divvying it up from the governments, itu, lawyers, and politicians. we will totally destroy what is left of cooperative internet stewardship in this process.
the slow versus sharp pain decision seems trivial when compared to the extreme pain of the wars of divvying up a reserve. let's not go there.
I can share your concern.
However, the issue we are proposing about a reserve is closely related to setting X-date. That is, leaving a reserve v.s. not setting X-date. Setting X-date would surely result in leaving some blocks because registries will accept any IPv4 address request before X-date and there needs to be some wasted space to be left for this.
If divvying is too tough, we can throw away an idea of divvying in the modified proposal, where we can just freeze the reserve. Also, the amount of reserve can be tried to be minimum. For example, besides A-date and X-date, we can set A2-date which adjusts and re-announces X-date.
Regards, Takashi Arano
Kosuke Ito wrote:
To define the gradual level of what extent we need to reduce should be the next step of issue, if we found that our current proposed approach does not provide enough time range for communities to shift into IPv6.
Ito-san,
At the heart of the matter, my concern with your proposed policy is that it does not deal with providing an orderly transition to a world where only IPv6 allocations are available.
Geoff Huston in his article "Addressing the Future Internet"
http://www.circleid.com/posts/addressing_the_future_internet/
asks the question: "In designing new protocols, what lessons can be learned from the slow deployment of IPv6 to date?"
Hopefully I will be forgiven for quoting this fragment as it seems very relevant to the proposal:
<quote> .....is that the significant impediment to IPv6 deployment is not availability of network equipment, nor the capability of end systems to support IPv6, nor the capability to roll out IPv6 support in most service providers’ IP network. The impediment for IPv6 deployment appears to be [the lack of] a well-grounded business case to actually do so.
The expectation with IPv6 was that the increasing scarcity of IPv4 addresses would drive service providers and their customer base to IPv6 deployment. What does not appear to be factored into this expectation is that Network Address Translators (NATs) produce a similar outcome in terms of virtually extending the IPv4 address space, and, additionally, are an externalized cost to the service provider. Service providers do not have to fund NAT deployment. For the consumer the use of embedded NATs into the edge device is a zero cost solution. </quote>
The article is a good if somewhat lengthy read.
Anyway the point I am trying to make is that in the continued absence of any external driver to migrate to IPv6 coupled with a policy of no change in IPv4 allocation principals will lead us to position where an orderly transition will be hard to achieve.
At 12:40 PM 17/02/2007, Robert Gray wrote:
Kosuke Ito wrote:
To define the gradual level of what extent we need to reduce should be the next step of issue, if we found that our current proposed approach does not provide enough time range for communities to shift into IPv6.
Ito-san,
At the heart of the matter, my concern with your proposed policy is that it does not deal with providing an orderly transition to a world where only IPv6 allocations are available.
It always struck me that IPv6 represents an incremental and quite conservative step in technology over IPv4, but without the conventional attributes of incremental piecemeal deployment that technology incrementalism usually achieves . The fact that IPv6 deployment is not incrementally deployable, is not backward compatible with IPv4, and is not a deployment that makes sense to undertake in isolation, makes the business case fro deployment really hard to phrase for many actors. The alternative, of more and more dense NAT deployment, simply transfers the cost of address scarcity to others and stays within some form of "comfort zone" of not changing all that much from where we are today. Its not that IPv6 is the "only" way forward here, but perhaps the more constructive question is what is the _preferred_ way forward, and can the environment be structured so as to make such a preferred path a 'natural' one for industry actors to follow?
The other question that I've been asking myself in this topic stream is how and why adoption of this form of policy regarding IPv4 unallocated pool exhaustion would assist us to transition out of the current address distribution regime without major negative forms of disruption to the Internet. Personally, I've not yet seen a clear and convincing case (for me at any rate) to answer this concern.
regards,
Geoff
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Feb 16, 2007, at 9:11 PM, Geoff Huston wrote:
At 12:40 PM 17/02/2007, Robert Gray wrote:
Kosuke Ito wrote:
To define the gradual level of what extent we need to reduce should be the next step of issue, if we found that our current proposed approach does not provide enough time range for communities to shift into IPv6.
Ito-san,
At the heart of the matter, my concern with your proposed policy is that it does not deal with providing an orderly transition to a world where only IPv6 allocations are available.
It always struck me that IPv6 represents an incremental and quite conservative step in technology over IPv4, but without the conventional attributes of incremental piecemeal deployment that technology incrementalism usually achieves . The fact that IPv6 deployment is not incrementally deployable, is not backward compatible with IPv4, and is not a deployment that makes sense to undertake in isolation, makes the business case fro deployment really hard to phrase for many actors. The alternative, of more and more dense NAT deployment, simply transfers the cost of address scarcity to others and stays within some form of "comfort zone" of not changing all that much from where we are today. Its not that IPv6 is the "only" way forward here, but perhaps the more constructive question is what is the _preferred_ way forward, and can the environment be structured so as to make such a preferred path a 'natural' one for industry actors to follow?
The other question that I've been asking myself in this topic stream is how and why adoption of this form of policy regarding IPv4 unallocated pool exhaustion would assist us to transition out of the current address distribution regime without major negative forms of disruption to the Internet. Personally, I've not yet seen a clear and convincing case (for me at any rate) to answer this concern.
I think it makes sense as a kind of "crisis planning" initiative, and works in basically the same ways:
1. In case of emergency (inevitable in this case), an orderly evacuation path is specified. The proximate goal/destination is "out"; working out more specific post-crisis destination(s) is another matter entirely. Panic about the event itself should be reduced, if not eliminated entirely.
2. Publication of the plan reminds people that crises are possible (inevitable in this case). This may cause some of the panic to occur earlier -- at time of publication rather than at the time of the emergency itself -- but even so spreading the disruption out over a longer duration, as opposed to dealing with everyone's all at once, should in principle make it easier for everyone to manage.
3. Early responders may create greater demand for more constructive transition mechanisms, sooner rather than later. With luck, an earlier start at exploring potential successor arrangements will help to reveal promising vs. problematic alternatives, sooner rather than later.
On this view, the proposed mechanisms tend to optimize for near-term order and stability, although potentially at the expense of long-term order and stability. Unless (even more) 11th hour panic would actually be constructive, or the preferred destination is well known and a better transition can be formulated to lead more directly to that successor state, this may be the best we can hope for at the moment...
TV
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Feb 16, 2007, at 9:11 PM, Geoff Huston wrote:
At 12:40 PM 17/02/2007, Robert Gray wrote:
Kosuke Ito wrote:
To define the gradual level of what extent we need to reduce should be the next step of issue, if we found that our current proposed approach does not provide enough time range for communities to shift into IPv6.
Ito-san,
At the heart of the matter, my concern with your proposed policy is that it does not deal with providing an orderly transition to a world where only IPv6 allocations are available.
It always struck me that IPv6 represents an incremental and quite conservative step in technology over IPv4, but without the conventional attributes of incremental piecemeal deployment that technology incrementalism usually achieves . The fact that IPv6 deployment is not incrementally deployable, is not backward compatible with IPv4, and is not a deployment that makes sense to undertake in isolation, makes the business case fro deployment really hard to phrase for many actors. The alternative, of more and more dense NAT deployment, simply transfers the cost of address scarcity to others and stays within some form of "comfort zone" of not changing all that much from where we are today. Its not that IPv6 is the "only" way forward here, but perhaps the more constructive question is what is the _preferred_ way forward, and can the environment be structured so as to make such a preferred path a 'natural' one for industry actors to follow?
The other question that I've been asking myself in this topic stream is how and why adoption of this form of policy regarding IPv4 unallocated pool exhaustion would assist us to transition out of the current address distribution regime without major negative forms of disruption to the Internet. Personally, I've not yet seen a clear and convincing case (for me at any rate) to answer this concern.
I think it makes sense as a kind of "crisis planning" initiative, and works in basically the same ways:
1. In case of emergency (inevitable in this case), an orderly evacuation path is specified. The proximate goal/destination is "out"; working out more specific post-crisis destination(s) is another matter entirely. Panic about the event itself should be reduced, if not eliminated entirely.
2. Publication of the plan reminds people that crises are possible (inevitable in this case). This may cause some of the panic to occur earlier -- at time of publication rather than at the time of the emergency itself -- but even so spreading the disruption out over a longer duration, as opposed to dealing with everyone's all at once, should in principle make it easier for everyone to manage.
3. Early responders may create greater demand for more constructive transition mechanisms, sooner rather than later. With luck, an earlier start at exploring potential successor arrangements will help to reveal promising vs. problematic alternatives, sooner rather than later.
On this view, the proposed mechanisms tend to optimize for near-term order and stability, although potentially at the expense of long-term order and stability. Unless (even more) 11th hour panic would actually be constructive, or the preferred destination is well known and a better transition can be formulated to lead more directly to that successor state, this may be the best we can hope for at the moment...
TV
At 11:11 07/02/17, Geoff Huston wrote:
It always struck me that IPv6 represents an incremental and quite conservative step in technology over IPv4, but without the conventional attributes of incremental piecemeal deployment that technology incrementalism usually achieves . The fact that IPv6 deployment is not incrementally deployable, is not backward compatible with IPv4, and is not a deployment that makes sense to undertake in isolation, makes the business case fro deployment really hard to phrase for many actors. The alternative, of more and more dense NAT deployment, simply transfers the cost of address scarcity to others and stays within some form of "comfort zone" of not changing all that much from where we are today. Its not that IPv6 is the "only" way forward here, but perhaps the more constructive question is what is the _preferred_ way forward, and can the environment be structured so as to make such a preferred path a 'natural' one for industry actors to follow?
Site-level NATs have already contributed to address conservation very much, but not will do more. Provider-lever NATs is technically possible, but not a good solution, I believe. It would be much better to pay money for IPv6 than for provider-level NATs.
The other question that I've been asking myself in this topic stream is how and why adoption of this form of policy regarding IPv4 unallocated pool exhaustion would assist us to transition out of the current address distribution regime without major negative forms of disruption to the Internet. Personally, I've not yet seen a clear and convincing case (for me at any rate) to answer this concern.
IPv4 exhaustion gives negative impact, more or less. The issue here is how to reduce the pain. As Randy said, choice of short sharp pain or long-term pain well describes this issue.
Anyway, time proceeds. We have to confront this issue seriously and as soon as possible.
Regards, Takashi Arano
Arano-san,
On Feb 26, 2007, at 8:34 PM, Takashi Arano wrote:
Site-level NATs have already contributed to address conservation very much, but not will do more.
If you are an IPv6-only site and you want to talk to the vast majority of the Internet that is IPv4-only, how are you going to do it if you don't have NAT?
I suspect the "dual stack" model chosen by the IETF and the fact that the IPv4 free pool will be exhausted before IPv6 is ubiquitous has guaranteed the pervasive deployment of NAT.
Rgds, -drc
At 05:32 PM 27/02/2007, David Conrad wrote:
Arano-san,
On Feb 26, 2007, at 8:34 PM, Takashi Arano wrote:
Site-level NATs have already contributed to address conservation very much, but not will do more.
If you are an IPv6-only site and you want to talk to the vast majority of the Internet that is IPv4-only, how are you going to do it if you don't have NAT?
I suspect the "dual stack" model chosen by the IETF and the fact that the IPv4 free pool will be exhausted before IPv6 is ubiquitous has guaranteed the pervasive deployment of NAT.
"predicting the future is easy - the hard part is getting it right!"
I suspect that the relatively conservative decisions taken in the IETF over IPv6 technology has lead to a rather unusual outcome of what is, in technology terms, an incremental refinement in the technology base, but with an associated implication of disruptive deployment (i.e. lack of capability for piecemeal deployment and backward compatibility with the installed base). Normally, and the Internet itself is a good example, disruptive deployments are driven by disruptive technologies - i.e. the technology offers deployers significant opportunities that are inaccessible to the incumbent operators, and the emerging market is driven by these new opportunities and the investments in the new technology are made in the expectation of market displacement from the installed base.
NATs on the other hand are a more classic example of incrementalism - piecemeal deployment, externalization of costs, no change in existing investment values etc, where the relatively massive deployment of this technology in recent times should come as no surprise.
The predicted exhaustion of the unallocated pool of IPv4 addresses creates some potential for disruption in this industry. The actions of various industry actors would naturally tend to a preference for options that externalize associated costs as much as possible and minimize the potential impact to the value of current investments and service infrastructure. That would appear to make the outcome that David Conrad paints above, that of pervasive deployment of NATS as one that would appear to be a preferred outcome for many actors. Of course this would be a short term preference under the current set of constraints, but the longer term questions about the ultimate viability of such an approach, and the consideration of other factors make the longer term picture extremely speculative.
http://www.potaroo.net/ispcol/2007-02/address-paper.html contains some of my own further thoughts on this subject, for those who are interested in this topic.
regards,
Geoff
Takashi Arano wrote:
IPv4 exhaustion gives negative impact, more or less. The issue here is how to reduce the pain. As Randy said, choice of short sharp pain or long-term pain well describes this issue.
Arano-san
I'm not sure that the choice is this simple.
The community needs to promote a progressive global deployment of IPv6 and this needs to start very soon otherwise there will be no ability to transition when the time (however defined) comes.
I do not think that the imposition of arbitrary exhaustion dates will of itself be sufficient to make this happen.
Anyway, time proceeds. We have to confront this issue seriously and as soon as possible.
Here we agree 100%
The difference in approach seems to be that some of us would like to see more action taken sooner to specifically promote IPv6 deployment rather than concentrating solely on what happens until x-date
Hi Robert,
At 04:51 07/02/28, Robert Gray wrote:
IPv4 exhaustion gives negative impact, more or less. The issue here is how to reduce the pain. As Randy said, choice of short sharp pain or long-term pain well describes this issue.
Arano-san
I'm not sure that the choice is this simple.
The community needs to promote a progressive global deployment of IPv6 and this needs to start very soon otherwise there will be no ability to transition when the time (however defined) comes.
I do not think that the imposition of arbitrary exhaustion dates will of itself be sufficient to make this happen.
Our intention is not to impose something. This is intended to guarantee LIRs to get IPv4 addresses by the specific date pre-announced. As a result, x-date would be shorten just by one a few months. We believe it is useful and necessary for LIR/ISP's planning division.
Anyway, time proceeds. We have to confront this issue seriously and as soon as possible.
Here we agree 100%
The difference in approach seems to be that some of us would like to see more action taken sooner to specifically promote IPv6 deployment rather than concentrating solely on what happens until x-date
Yes, on different hats of mine, the IPv6 forum and Asia Pacific IPv6 Task Force are going to promote IPv6 and provide some guidelines for ISPs more seriously than ever.
Regards, Takashi Arano
This policy proposal has now been introduced into the ARIN region. I will not speak to the merits of this proposal, but will ask the question that the ARIN General Counsel is now taking up: What is the liability exposure to ARIN if this policy is adopted? What are the anti-trust implications if this is adopted by ARIN? Additionally, the attorneys of all the RIRs should consider what is the anti-trust implication of this proposal if adopted globally? I do not intend for this to start a legal discussion on this list by a bunch of people who are not attorneys but rather to say that this proposal like any other proposal can have consequences that the authors of the proposal do not intend. In the case of the anti-trust implications, this could be extremely harmful to any RIR that adopts it, and therefore this should be carefully scrutinized by competent attorneys before the community adopts it.
By this message, I ask Paul Wilson to introduce my comments into the discussion of this policy at the APNIC meeting.
Ray
-----Original Message----- From: sig-policy-bounces@lists.apnic.net [mailto:sig-policy- bounces@lists.apnic.net] On Behalf Of Takashi Arano Sent: Wednesday, February 28, 2007 12:55 AM To: Robert Gray Cc: sig-policy@lists.apnic.net; Takashi Arano; Takashi Arano Subject: Re: [sig-policy] IPv4 countdown policy proposal
Hi Robert,
At 04:51 07/02/28, Robert Gray wrote:
IPv4 exhaustion gives negative impact, more or less. The issue here is how to reduce the pain. As Randy said, choice of
short sharp pain or long-term pain well describes this issue.
Arano-san
I'm not sure that the choice is this simple.
The community needs to promote a progressive global deployment of IPv6
and this needs to start very soon otherwise there will be no ability to transition when the time (however defined) comes.
I do not think that the imposition of arbitrary exhaustion dates will
of itself be sufficient to make this happen.
Our intention is not to impose something. This is intended to guarantee LIRs to get IPv4 addresses by the specific date pre-announced. As a result, x-date would be shorten just by one a few months. We believe it is useful and necessary for LIR/ISP's planning division.
Anyway, time proceeds. We have to confront this issue seriously and as soon as possible.
Here we agree 100%
The difference in approach seems to be that some of us would like to
see more action taken sooner to specifically promote IPv6 deployment rather than concentrating solely on what happens until x-date
Yes, on different hats of mine, the IPv6 forum and Asia Pacific IPv6 Task Force are going to promote IPv6 and provide some guidelines for ISPs more seriously than ever.
Regards, Takashi Arano
sig-policy: APNIC SIG on resource management policy
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
Thanks Ray. I miss you here in Bali by the way.
I think Paul will introduce your comment in front of APNIC community.
I agree that Legal implication should be carefully revisited.
I think the Internet Registries who distribute the IP number resource cannot be helped to comply to the run-out of our resource. I would like to have your ider if you had a diffent perspective on this idea.
I think the legal implication with any address policy action should be resolved by the Registries. Even if the community were advised of such a legal risk, the community at most can take it into account in the framework of their own businesses, but not of Registries. (Correct me if you think I am in a wrong shape.)
The proposer team would really love to find a good solution to confront this forthcoming epoch. We do need your cooperation and we are flexible enough to include any of your inputs regardless technically or at large, in order to achieve OUR goal.
Thank you, and keep in touch on this issue.
Regards, ----- MAEMURA Akinori General Manager, IP Department JPNIC - Japan Network Information Center maem@nic.ad.jp
In message D7E170CA59F2F24EA64244745D01E75904E04D5C@ex.arin.net "RE: [sig-policy] IPv4 countdown policy proposal" "Ray Plzak plzak@arin.net" wrote:
| This policy proposal has now been introduced into the ARIN region. | I will not speak to the merits of this proposal, but will ask the | question that the ARIN General Counsel is now taking up: What is | the liability exposure to ARIN if this policy is adopted? What are | the anti-trust implications if this is adopted by ARIN? Additionally, | the attorneys of all the RIRs should consider what is the anti-trust | implication of this proposal if adopted globally? I do not intend | for this to start a legal discussion on this list by a bunch of people | who are not attorneys but rather to say that this proposal like any | other proposal can have consequences that the authors of the proposal | do not intend. In the case of the anti-trust implications, this could | be extremely harmful to any RIR that adopts it, and therefore this | should be carefully scrutinized by competent attorneys before the | community adopts it. | | By this message, I ask Paul Wilson to introduce my comments into the | discussion of this policy at the APNIC meeting. | | Ray | | > -----Original Message----- | > From: sig-policy-bounces@lists.apnic.net [mailto:sig-policy- | > bounces@lists.apnic.net] On Behalf Of Takashi Arano | > Sent: Wednesday, February 28, 2007 12:55 AM | > To: Robert Gray | > Cc: sig-policy@lists.apnic.net; Takashi Arano; Takashi Arano | > Subject: Re: [sig-policy] IPv4 countdown policy proposal | > | > Hi Robert, | > | > At 04:51 07/02/28, Robert Gray wrote: | > >>IPv4 exhaustion gives negative impact, more or less. | > >>The issue here is how to reduce the pain. As Randy said, choice of | > short sharp pain or long-term pain well describes this issue. | > > | > >Arano-san | > > | > >I'm not sure that the choice is this simple. | > > | > >The community needs to promote a progressive global deployment of IPv6 | > and this needs to start very soon otherwise there will be no ability to | > transition when the time (however defined) comes. | > > | > >I do not think that the imposition of arbitrary exhaustion dates will | > of itself be sufficient to make this happen. | > | > Our intention is not to impose something. | > This is intended to guarantee LIRs to get IPv4 addresses by the | > specific date pre-announced. | > As a result, x-date would be shorten just by one a few months. | > We believe it is useful and necessary for LIR/ISP's planning division. | > | > >>Anyway, time proceeds. We have to confront this issue seriously | > >>and as soon as possible. | > > | > >Here we agree 100% | > > | > >The difference in approach seems to be that some of us would like to | > see more action taken sooner to specifically promote IPv6 deployment | > rather than concentrating solely on what happens until x-date | > | > Yes, on different hats of mine, the IPv6 forum and Asia Pacific IPv6 | > Task Force | > are going to promote IPv6 and provide some guidelines for ISPs more | > seriously than ever. | > | > Regards, | > Takashi Arano | > | > * sig-policy: APNIC SIG on resource management policy | > * | > _______________________________________________ | > sig-policy mailing list | > sig-policy@lists.apnic.net | > http://mailman.apnic.net/mailman/listinfo/sig-policy | | * sig-policy: APNIC SIG on resource management policy * | _______________________________________________ | sig-policy mailing list | sig-policy@lists.apnic.net | http://mailman.apnic.net/mailman/listinfo/sig-policy | |
MAEMURA,
Thank you for your message. One thing to bear in mind is that IPv4 will never "run out" or "be exhausted". What will happen is that the large IANA reserve will be depleted and that consequently RIRs will no longer be able to allocate IPv4 in the same manner as they do currently. The fact is that the RIRs will always have some IPv4 space, just not enough to meet the allocation demand that they currently have, nor even the minimum allocation size. Policy work in this area should be done in such a manner to meet the challenge of the change in the IPv4 allocation environment. The environment will change but it will not go away. If the RIRs stop allocating IPv4 address space then it will be allocated in some other manner. This will not be good for the Internet.
Ray
-----Original Message----- From: MAEMURA Akinori [mailto:maem@nic.ad.jp] Sent: Wednesday, February 28, 2007 11:44 AM To: plzak@arin.net; arano@inetcore.com; bob@brockhurst.co.nz Cc: sig-policy@lists.apnic.net; takashi@arano.jp Subject: Re: [sig-policy] IPv4 countdown policy proposal
Thanks Ray. I miss you here in Bali by the way.
I think Paul will introduce your comment in front of APNIC community.
I agree that Legal implication should be carefully revisited.
I think the Internet Registries who distribute the IP number resource cannot be helped to comply to the run-out of our resource. I would like to have your ider if you had a diffent perspective on this idea.
I think the legal implication with any address policy action should be resolved by the Registries. Even if the community were advised of such a legal risk, the community at most can take it into account in the framework of their own businesses, but not of Registries. (Correct me if you think I am in a wrong shape.)
The proposer team would really love to find a good solution to confront this forthcoming epoch. We do need your cooperation and we are flexible enough to include any of your inputs regardless technically or at large, in order to achieve OUR goal.
Thank you, and keep in touch on this issue.
Regards,
MAEMURA Akinori General Manager, IP Department JPNIC - Japan Network Information Center maem@nic.ad.jp
In message D7E170CA59F2F24EA64244745D01E75904E04D5C@ex.arin.net "RE: [sig-policy] IPv4 countdown policy proposal" "Ray Plzak plzak@arin.net" wrote:
| This policy proposal has now been introduced into the ARIN region. | I will not speak to the merits of this proposal, but will ask the | question that the ARIN General Counsel is now taking up: What is | the liability exposure to ARIN if this policy is adopted? What are | the anti-trust implications if this is adopted by ARIN? Additionally, | the attorneys of all the RIRs should consider what is the anti-trust | implication of this proposal if adopted globally? I do not intend | for this to start a legal discussion on this list by a bunch of people | who are not attorneys but rather to say that this proposal like any | other proposal can have consequences that the authors of the proposal | do not intend. In the case of the anti-trust implications, this could | be extremely harmful to any RIR that adopts it, and therefore this | should be carefully scrutinized by competent attorneys before the | community adopts it. | | By this message, I ask Paul Wilson to introduce my comments into the | discussion of this policy at the APNIC meeting. | | Ray | | > -----Original Message----- | > From: sig-policy-bounces@lists.apnic.net [mailto:sig-policy- | > bounces@lists.apnic.net] On Behalf Of Takashi Arano | > Sent: Wednesday, February 28, 2007 12:55 AM | > To: Robert Gray | > Cc: sig-policy@lists.apnic.net; Takashi Arano; Takashi Arano | > Subject: Re: [sig-policy] IPv4 countdown policy proposal | > | > Hi Robert, | > | > At 04:51 07/02/28, Robert Gray wrote: | > >>IPv4 exhaustion gives negative impact, more or less. | > >>The issue here is how to reduce the pain. As Randy said, choice of | > short sharp pain or long-term pain well describes this issue. | > > | > >Arano-san | > > | > >I'm not sure that the choice is this simple. | > > | > >The community needs to promote a progressive global deployment of IPv6 | > and this needs to start very soon otherwise there will be no ability to | > transition when the time (however defined) comes. | > > | > >I do not think that the imposition of arbitrary exhaustion dates will | > of itself be sufficient to make this happen. | > | > Our intention is not to impose something. | > This is intended to guarantee LIRs to get IPv4 addresses by the | > specific date pre-announced. | > As a result, x-date would be shorten just by one a few months. | > We believe it is useful and necessary for LIR/ISP's planning division. | > | > >>Anyway, time proceeds. We have to confront this issue seriously | > >>and as soon as possible. | > > | > >Here we agree 100% | > > | > >The difference in approach seems to be that some of us would like to | > see more action taken sooner to specifically promote IPv6 deployment | > rather than concentrating solely on what happens until x-date | > | > Yes, on different hats of mine, the IPv6 forum and Asia Pacific IPv6 | > Task Force | > are going to promote IPv6 and provide some guidelines for ISPs more | > seriously than ever. | > | > Regards, | > Takashi Arano | > | > * sig-policy: APNIC SIG on resource management policy | > * | > _______________________________________________ | > sig-policy mailing list | > sig-policy@lists.apnic.net | > http://mailman.apnic.net/mailman/listinfo/sig-policy | | * sig-policy: APNIC SIG on resource management policy
| _______________________________________________ | sig-policy mailing list | sig-policy@lists.apnic.net | http://mailman.apnic.net/mailman/listinfo/sig-policy | |
Hi,
At 07:52 07/02/16, David Conrad wrote:
My question is HOW. I personally can't imagine which kind of policy will achieve this goal.
Some potential examples:
- Currently, APNIC has an "80% rule". Create a policy that when the
current free pool is reduced by 50%, make it a 90% rule. When the remaining free pool is reduced by another 50%, make it a 95% rule. Etc.
I don't believe it doesn't lead to significant conservation.
It is sure that it delays timing of requesting address blocks, but not that it can delay assigning address to their customers or equipments at all. It can postpone X-date a little bit but only a little, I guess.
- Currently, APNIC has no requirement to demonstrate IPv6 support.
When the free pool is reduced 25%, APNIC institutes a rule that organization to which new allocations are made must demonstrate their infrastructure is IPv6 capable. When the remaining free pool is reduced another 25%, organizations to which new allocations are made must demonstrate 10% of their customers are IPv6 capable. Etc.
Good!
- Currently, APNIC recommends organisations should base their
assignment requests on the assumption that 25 percent of the address space will be used immediately and 50 percent used within one year. When the free pool is reduced by 25%, these values should increase to 50 and 75 percent respectively. When the free pool is reduced by 50%, these values should increase to 75 and 90 percent respectively. Etc.
The same thing as above. It only delays timing of requesting address blocks,
I'm sure there are many others.
Again, I don't think there are many. It would be very difficult to decide which portion of address blocks that are currently allocated/assigned will not be allocated/assigned in a new policy.
Regards, Takashi Arano
Arano-san,
On Feb 26, 2007, at 1:43 AM, Takashi Arano wrote:
- Currently, APNIC has an "80% rule". Create a policy that when the
current free pool is reduced by 50%, make it a 90% rule. When the remaining free pool is reduced by another 50%, make it a 95% rule. Etc.
I don't believe it doesn't lead to significant conservation.
The point of this example was to make it self-adjusting. As the free pool gets smaller, the restrictions increase automatically. By definition, it would extend the free pool as far as it needs to go -- the restrictions would get arbitrarily complex so at some point it becomes easier/cheaper/more cost effective to simply deploy IPv6 and the NAT boxes necessary for IPv6-only sites to talk to the rest of the Internet.
As far as I can tell, the difference between this and what is in the IPv4 countdown proposal is there isn't an arbitrary flag day that results in one day people being able to get IPv4 address space and the next day not (regardless of their need or justification).
I'm sure there are many others.
Again, I don't think there are many.
There are a myriad variations and combinations that can be applied.
It would be very difficult to decide which portion of address blocks that are currently allocated/assigned will not be allocated/assigned in a new policy.
I must not understand this comment. I would assume the new policy would apply to the free pool existent at the time the policy was implemented, just like policies have always been applied.
Rgds, -drc
The point of this example was to make it self-adjusting. As the free pool gets smaller, the restrictions increase automatically. By definition, it would extend the free pool as far as it needs to go
the problem with this is, in operational reality, when i can not get the allocation i operationally need, the ipv4 free pool may be there in name but it is useless because i will be forced to do something strange such as nat or ipv6.
randy
On Feb 26, 2007, at 10:54 PM, Randy Bush wrote:
The point of this example was to make it self-adjusting. As the free pool gets smaller, the restrictions increase automatically. By definition, it would extend the free pool as far as it needs to go
the problem with this is, in operational reality, when i can not get the allocation i operationally need, the ipv4 free pool may be there in name but it is useless because i will be forced to do something strange such as nat or ipv6.
Well, yes. Sometime in relatively near future, ISPs are going to get to the point where they have the following choice:
a) say to the customer "Sorry, we don't want your money" b) ask the customer "What do you _REALLY_ need?" c) say to the customer "Here is one (1) IPv4 address. Go NAT your enterprise" d) say to the customer "Here is a /48 for IPv6. Go NAT your enterprise" e) wave money around and say to the black market "name your price!"
regardless of whether the IPv4 countdown proposal goes for quick trauma or chronic pain. I guess I'm just skeptical that the address consuming community is going to be able to have will power to not immediately dig into the reserve on a case-by-case basis without any sort of policy framework to base requests on.
But as I've said, perhaps I'm too cynical.
Rgds, -drc
David Conrad wrote:
c) say to the customer "Here is one (1) IPv4 address. Go NAT your enterprise" d) say to the customer "Here is a /48 for IPv6. Go NAT your enterprise"
There are enough NAT unfriendly protocols for this to be really unattractive to some clients once they find out the limitations. Anyway a small part of the problem has been that one (1) address is seldom enough; a /29 or /30 is generally the minimum usage.
e) wave money around and say to the black market "name your price!"
I wonder on thinking about this how practical a black (or white) market would be given the minimum size of a routable block. I guess it really only applies to the historical allocations.
I think you might have missed one:
f) Brief their lawyers to go after the RIR's and access the 'reserve'.
Now here's a plan that should work for a customer or even an ISP.
Robert,
On Feb 27, 2007, at 11:37 AM, Robert Gray wrote:
David Conrad wrote:
c) say to the customer "Here is one (1) IPv4 address. Go NAT your enterprise" d) say to the customer "Here is a /48 for IPv6. Go NAT your enterprise"
There are enough NAT unfriendly protocols for this to be really unattractive to some clients once they find out the limitations.
It is often surprising to me how much less unattractive options become when the alternative is either "pay more" or "do without". As for (d), that's just a function of "dual stack" and the fact that IPv6 isn't ubiquitous.
To be clear, I'm not arguing this is a good (or bad) approach, rather that within a relatively small number of years, it will be the most common approach because the alternative is to pay more or do without.
e) wave money around and say to the black market "name your price!"
I wonder on thinking about this how practical a black (or white) market would be given the minimum size of a routable block.
I suspect that's something the market will work out.
I guess it really only applies to the historical allocations.
In a few years, all IPv4 allocations will be historic.
I think you might have missed one:
f) Brief their lawyers to go after the RIR's and access the 'reserve'.
Yep. Although at some point, all the lawyers in the world won't be able to get space from the 'reserve' pool as it won't exist...
Rgds, -drc
Hi David,
At 15:24 07/02/27, David Conrad wrote:
Arano-san,
On Feb 26, 2007, at 1:43 AM, Takashi Arano wrote:
- Currently, APNIC has an "80% rule". Create a policy that when the
current free pool is reduced by 50%, make it a 90% rule. When the remaining free pool is reduced by another 50%, make it a 95% rule. Etc.
I don't believe it doesn't lead to significant conservation.
The point of this example was to make it self-adjusting. As the free pool gets smaller, the restrictions increase automatically. By definition, it would extend the free pool as far as it needs to go -- the restrictions would get arbitrarily complex so at some point it becomes easier/cheaper/more cost effective to simply deploy IPv6 and the NAT boxes necessary for IPv6-only sites to talk to the rest of the Internet.
Of course, I believe I understand this.
I don't just understand your example does not seem effective very much for conservation.
Assume that LIR A is consuming IPv4 addresses constantly and they are given /8 of allocation for one year's usage. Here 80% rule results in sebsequent request after ten months when they consume 80% of /8. In 95% rule, they consume 95% of /8 in nearly 12 months and then come back to registries for subsequent addresses. In both rules, LIR is allocated /8 per a year. 95% rule just delays the timeing of subsequent request a little bit. This is why I think your example is not so effective.
I would agree that mix and match may be useful. But even if we succeed in conserving 20%, exhaustion date would be prolonged just one year, where LIRs would have severe time being allocated. If you like gradual policy, probably that policy should conserve more addresses, say 40% which can prolong address life time from 5 years to 8 years or so. In order to do so, I guess policy should be more drastic and we would have to discuss who and in which cases addresses are not allocated/assigned.
Doesn't it make sense?
Regards, Takashi Arano
I'm sure there are many others.
Again, I don't think there are many.
There are a myriad variations and combinations that can be applied.
It would be very difficult to decide which portion of address blocks that are currently allocated/assigned will not be allocated/assigned in a new policy.
I must not understand this comment. I would assume the new policy would apply to the free pool existent at the time the policy was implemented, just like policies have always been applied.
Rgds, -drc
Activity Summary
- 6058 days inactive
- 6058 days old
- sig-policy@lists.apnic.net
- 10 participants
- 30 comments