Orbit

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

I think what Brian is trying to point out, is that you're basically nullifying "the existing criteria" because the "new alternative criteria" is much more relaxed. I agree with Brian here.

There are many other reasons (or unreasonable reasons) that people deaggregate. IMHO, deaggregation caused by the implementation of this policy is most likely to be very small compared to those numbers.

Regards, Seiichi

(2011/01/31 21:35), Izumi Okutani wrote:

Andy, thank you very much for fowarding the discussions.

About the aggregation concern, is the issue being that once an organization becomes an LIR, they might start puching-holing existing assignments from their upstream?

I'm not sure if I understand the issue well, and would be interested to hear more about it if anyone is able to share.

For the 80% requirement, we simply made the % consistent with the subsequent allocation criteria today. (I just realised it's not explicitly stated in the policy document - may I confirm with APNIC secretariat if this is still true?)

I've made some slides on the issue we are trying to solve in this proposal. Hope it clarifies the intention a little better.

thanks, Izumi

(2011/01/31 5:51), Andy Linton wrote:

...

There's been some discussion of prop-094 on the nznog mailing list after last week's meeting in Wellington.

Brian is a former chair of the IAB and IETF and Jamie is the VP of InternetNZ.

I'm forwarding them here.

andy

-------- Original Message -------- Subject: Re: [nznog] Prop 94 Date: Sat, 29 Jan 2011 17:15:56 +1300 From: Brian E Carpenterbrian.e.carpenter@gmail.com Organization: University of Auckland To: jamie baddeleyjamie.baddeley@vpc.co.nz CC: nznog@list.waikato.ac.nznznog@list.waikato.ac.nz

On 2011-01-29 15:49, jamie baddeley wrote:

...

Hi Brian,

I don't think the proposal at this point is too bad. Happy to be persuaded otherwise. If someone is prepared to make the leap into a /22 then 20% of what's remaining in the existing upstream allocation is not a massive amount of space. How many assignments happen from upstream to downstream that is greater than a /22?

Yes, certainly this isn't a disaster, but why set the level at 80% occupied? 90% would halve the amount of potentially wasted or hoarded space.

...

We're expecting everyone who takes the global routing table to be (or have been) busy upgrading to v4/v6 dual stack and I presume as a consequence they have nice shiny routers with lots of mem/cpu etc. Therefore the number of prefixes in the GRT is much less a concern these days right?

Well, routers have kept up with growth because CIDR has been a great success over the last 15+ years, and this seems like a step back: 2 prefixes instead of one for every operator who uses this policy and has multihomed transit. There's a significant risk of IPv4 disaggregation for many reasons during the coming address space end game, so I think we need to be watchful.

As an author of RFC 5887, I fully realise that asking operators to renumber is a hard ask. So the effect of this change will actually be to nullify the renumbering requirement completely - why would any operator take that pain voluntarily?

 Brian

...

jamie

On 28/01/2011, at 3:22 PM, Brian E Carpenter wrote:

...

The APNIC policy proposal 94 allows an operator to put in for new IPv4 space without having to renumber, if they can show that they've used 80% of the space already obtained from their upstream.

http://www.apnic.net/policy/proposals/prop-094

That seems bad in two ways

1. It allows 19.99% of IPv4 space to be hoarded.

2. It probably encourages disaggregation, compared with renumbering

into this new block.

Brian

_______________________________________________ NZNOG mailing list NZNOG@list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

NZNOG mailing list NZNOG@list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

•          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

On 2/02/11 Wed, Feb 2, 01:45, Izumi Okutani wrote:

Thanks for clarifying Brian's point. I see this policy gives the impression of giving out /22 allocations too generously by not requiring renumbering.

My concern is actually the other way around, that keeping the current renumbering criteria after the final /8 makes initial allocation conditions more strict than today.

Today, if a new LIR has existing address holdings from its upstream IR, APNIC can allocate more than a /22 to compensate for the loss of renumbering.

This will no longer be the case after the final /8. For example, if a new LIR's existing address holding is a /21, they must return this /21 in exchange for a /22 allocation from APNIC.

This doesn't make much sense when you request for an allocation to receive an additional IPv4 space.

Do people have thoughts about this?

I recall some of the discussions that lead to the current final /8 policy and I think the core idea was that the /22 that each entity got was for the specific purpose of enabling IPv6 deployment and integration.

New users should use this to give them a presence in both the IPv4 and IPv6 dual stack environments that will need to operate for some time.

Existing users should not use this IPv4 space for business as usual deployments but specifically as IPv6 transition space.

I expect I'll have comments about the size of the global routing table. If IPv6 growth happens as we think/hope/expect it too the the combined tables will have to grow to accommodate the IPv6 routes and the IPv4 tables might grow by up to one prefix per APNIC member because of this. There's simple no escaping the fact that routers carrying full routes are going to get bigger before they can get smaller.

I believe that we should have very few restrictions on this final /22 delegation. It's the last one that each applicant can get and I think that the only condition that should apply is that APNIC ensures that each applicant has an IPv6 allocation (either they already have one or they are given one with this request).

APNIC and the other RIRs will have little they can do in terms of sanctions if someone fails to renumber. They can't refuse to give them any more IPv4 space as by definition there is none and for most they'll have all the IPv6 space they're likely to need.

Making policy that has little or no prospect of being enforced seems pointless. For this reason I think that a number of the policies before us at APNIC 31 run the risk of trying to micro manage this transition in ways that won't succeed.

We should all look at the proposals and ask ourselves what we can realistically achieve together rather than try to cover all the little corner cases. Proposals that seek to try to prolong the agony continue to send a mixed message we should avoid.

We are at a crossroads. The last five /8s will be allocated this week to each of the RIRs and by the time we meet again at APNIC 32 we'll be allocating addresses from those blocks.

We need to provide clear leadership to our wider community that says the old order has finished and the way ahead is to add IPv6 and run a dual stack environment.

There seem to be a large number of proposals discussing corner cases which at most will afford maybe a month of extra allocation time. If you are an organisation and have not made steps to lessen your reliance on additional IPv4 allocations, then I doubt there is any possible proposal which will save you a significant amount of implementation pain.

i would support a proposal to have no more ipv4 policy proposals. i suspect others would as well. ipv4 policy proposal run-out!!!

The more we can do to encourage people to adopt IPv6 and ease there reliance on large IPv4 allocations the better. Dolling IPv4 addresses out in ever smaller amounts to people who refuse to adopt IPv6 just seems like we're drip-feeding an unhealthy addiction.

my vision of the smll allocations of the final /8 policy is, as andy said, to allow v6-only or dual-stacked end sites to front onto the dual-stacked backbones.

randy

...

my vision of the smll allocations of the final /8 policy is, as andy said, to allow v6-only or dual-stacked end sites to front onto the dual-stacked backbones.

So would you envisage us asking for a deployment plan describing how they would use the /22 to get their v6-only or dual-stacked end sites to front onto the dual-stacked backbones?

the final /8 policy uses the one-and-only-one condition to throttle mis-use. it is wonderfully simple. imiho, making people do this and that, or making them lie is not worth much effort.

randy

...

the final /8 policy uses the one-and-only-one condition to throttle mis-use. it is wonderfully simple. imiho, making people do this and that, or making them lie is not worth much effort.

I agree that merely requiring a 'deployment plan' would be insufficient. By this point in the 21st century, they ought to have a viable IPv6 deployment *already*, and *that* could be a requirement of the new allocation. That is not something they can 'lie' about.

and i think allocations from the final /8 should only go to blondes who give us chocolate.

randy

Any organisation which is deploying more Legacy IP even now, without having deployed IPv6 yet, is clearly failing to fulfil that duty.

then we should take away all their ipv4 space

randy

...

...

Any organisation which is deploying more Legacy IP even now, without having deployed IPv6 yet, is clearly failing to fulfil that duty.

then we should take away all their ipv4 space

Another fine plan, but I fear that some may feel it a little excessive.

How about we just refrain from giving them any *more*, since they clearly aren't going to make good use of it

clearly? i deeply envy your omniscience.

look. they apply for something, issue it. do not try to use it to coerce behavior. aside from inviting the lawyers in, it just won't accomplish what you want. keep life simple.

randy

I agree with Andy. Thanks for wording it so nicely.

Nit picking the final /8 policy is going to lead nowhere. Its NOT business as usual and we have to get over it.

I thought the vision behind the final /8 policy was that everyone gets the same small piece of that final /8 if they want it. We can also hand out IPv6 blocks if those people already don't have one.

Trying to figure out how we can better serve IPv4 is not what we want to do right now...

Seiichi

(2011/02/02 8:02), Andy Linton wrote:

On 2/02/11 Wed, Feb 2, 01:45, Izumi Okutani wrote:

...

Thanks for clarifying Brian's point. I see this policy gives the impression of giving out /22 allocations too generously by not requiring renumbering.

My concern is actually the other way around, that keeping the current renumbering criteria after the final /8 makes initial allocation conditions more strict than today.

Today, if a new LIR has existing address holdings from its upstream IR, APNIC can allocate more than a /22 to compensate for the loss of renumbering.

This will no longer be the case after the final /8. For example, if a new LIR's existing address holding is a /21, they must return this /21 in exchange for a /22 allocation from APNIC.

This doesn't make much sense when you request for an allocation to receive an additional IPv4 space.

Do people have thoughts about this?

I recall some of the discussions that lead to the current final /8 policy and I think the core idea was that the /22 that each entity got was for the specific purpose of enabling IPv6 deployment and integration.

New users should use this to give them a presence in both the IPv4 and IPv6 dual stack environments that will need to operate for some time.

Existing users should not use this IPv4 space for business as usual deployments but specifically as IPv6 transition space.

I expect I'll have comments about the size of the global routing table. If IPv6 growth happens as we think/hope/expect it too the the combined tables will have to grow to accommodate the IPv6 routes and the IPv4 tables might grow by up to one prefix per APNIC member because of this. There's simple no escaping the fact that routers carrying full routes are going to get bigger before they can get smaller.

I believe that we should have very few restrictions on this final /22 delegation. It's the last one that each applicant can get and I think that the only condition that should apply is that APNIC ensures that each applicant has an IPv6 allocation (either they already have one or they are given one with this request).

APNIC and the other RIRs will have little they can do in terms of sanctions if someone fails to renumber. They can't refuse to give them any more IPv4 space as by definition there is none and for most they'll have all the IPv6 space they're likely to need.

Making policy that has little or no prospect of being enforced seems pointless. For this reason I think that a number of the policies before us at APNIC 31 run the risk of trying to micro manage this transition in ways that won't succeed.

We should all look at the proposals and ask ourselves what we can realistically achieve together rather than try to cover all the little corner cases. Proposals that seek to try to prolong the agony continue to send a mixed message we should avoid.

We are at a crossroads. The last five /8s will be allocated this week to each of the RIRs and by the time we meet again at APNIC 32 we'll be allocating addresses from those blocks.

We need to provide clear leadership to our wider community that says the old order has finished and the way ahead is to add IPv6 and run a dual stack environment.

•          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

Very well said! I fully agree with that sentiment.

The final /8 is the final /8. The purpose of any policy on how to manage the last /8 is very different any from previous policies on IPv4 distribution. We are not trying to strike the perfect balance between conservation and aggregation and we should not try to cover every possible scenario for every individual case.

The policy managing the last /8 is an attempt to slice up the last chunk of IPv4 addresses in a pragmatic and equitable manner in order to, whilst encouraging the widespread uptake of IPv6. Let's not send mixed messages and let's not be in denial ourselves. Like Andy says, we need to provide clear leadership to the community here.

The sole purpose of the last bits of IPv4 addresses distributed should be to aid the transition to IPv6.

Nurani

On 2 feb 2011, at 00.02, Andy Linton wrote:

I recall some of the discussions that lead to the current final /8 policy and I think the core idea was that the /22 that each entity got was for the specific purpose of enabling IPv6 deployment and integration.

New users should use this to give them a presence in both the IPv4 and IPv6 dual stack environments that will need to operate for some time.

Existing users should not use this IPv4 space for business as usual deployments but specifically as IPv6 transition space.

I expect I'll have comments about the size of the global routing table. If IPv6 growth happens as we think/hope/expect it too the the combined tables will have to grow to accommodate the IPv6 routes and the IPv4 tables might grow by up to one prefix per APNIC member because of this. There's simple no escaping the fact that routers carrying full routes are going to get bigger before they can get smaller.

I believe that we should have very few restrictions on this final /22 delegation. It's the last one that each applicant can get and I think that the only condition that should apply is that APNIC ensures that each applicant has an IPv6 allocation (either they already have one or they are given one with this request).

APNIC and the other RIRs will have little they can do in terms of sanctions if someone fails to renumber. They can't refuse to give them any more IPv4 space as by definition there is none and for most they'll have all the IPv6 space they're likely to need.

Making policy that has little or no prospect of being enforced seems pointless. For this reason I think that a number of the policies before us at APNIC 31 run the risk of trying to micro manage this transition in ways that won't succeed.

We should all look at the proposals and ask ourselves what we can realistically achieve together rather than try to cover all the little corner cases. Proposals that seek to try to prolong the agony continue to send a mixed message we should avoid.

We are at a crossroads. The last five /8s will be allocated this week to each of the RIRs and by the time we meet again at APNIC 32 we'll be allocating addresses from those blocks.

We need to provide clear leadership to our wider community that says the old order has finished and the way ahead is to add IPv6 and run a dual stack environment.

•          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