Re: [sig-policy] Fwd: Re: [nznog] Prop 94

On 02/02/2011, at 1:27 PM, Seiichi Kawamura wrote:

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 at lists dot apnic dot net

http://mailman.apnic.net/mailman/listinfo/sig-policy

* sig-policy: APNIC SIG on resource management policy *
_______________________________________________
sig-policy mailing list
sig-policy at lists dot apnic dot net
http://mailman.apnic.net/mailman/listinfo/sig-policy

--
Matthew Moyle-Croft

Peering Manager and Team Lead - Commercial and DSLAMs

Internode /Agile

Level 5, 150 Grenfell Street, Adelaide, SA 5000 Australia
Email: mmc at internode dot com dot au Web: http://www.on.net
Direct: +61-8-8228-2909 Mobile: +61-419-900-366
Reception: +61-8-8228-2999 Fax: +61-8-8235-6909