Orbit

Hi,

Izumi Okutani wrote:

Sanjaya wrote:

...

Geoff Huston wrote:

...

At 07:08 PM 25/09/2006, Izumi Okutani wrote:

...

Hi, I received some questions from our LIRs about this proposal and thought I'd share them on this list as well.

• Should the initial allocation criteria be changed with this policy to

200 customers, instead of /48s?

$B!!(B"have a plan for making at least 200 /48 assignments to other organizations within two years."

This could be a logically consistent change, in that it appears that the intent of the Ipv6 allocation policy is to allow IPv6 resource allocations to be available to service providers with customers.

Thanks. Yes, it seems to me that /48 has lost its original context now that ISPs can assign any size to its customers.

This, my understand, is not influencing to the initial allocation criteria of having a plan of service size at least 200 /48s assignments to other organizations (maybe 200 "customers" when assigning a /48 each) within two years. And also, the original policy does mention that it is on the LIRs decision which size of address space up to a /48 to their customers. RIR/NIR will not give any comment on it unless LIR need to assign the larger size than a /48 to a customer.

From the beginning, the assignment size is flexible between /48 to /64.

...

...

...

• What would be the minimum registration requirements per endsite?

A suggestion JPNIC has is to allow all dynamic assignments and /64s to be aggregated as LIR's infrastructure, but require all other assignments per endsite, to be consistent with v4.

Would there be any particular motivation to deviate from a practice that is consistent with Ipv4? (I can't think of any at this stage.)

The reason I can think of is the overall size of the IPv6 space. If people starts registering /64s and smaller assignments to the NIR/RIR, our disk storage will fill up rather quickly and the utilization calculation will take longer. I'm not saying this can't be done.

Considering that the registration requirement primary reason is to measure utilization, how about aggregating the assignment report to whatever size the HD ratio calculation is based on? And can we confirm that it is now based on /56?

I understand the registration requirement as for clarifying who is in responsible of the address space as well as for calculating utilization. Assuming this is the case, wouldn't it blur who is responsible for the address space if we allow aggregation in /56?

I agree. There is no technical reason to say which size. It is the matter of balancing between how precisely RIR/NIR need to know the utilization of allocated address space and how easy each LIR report/register it with the reasonably low overhead.

Kosuke

Izumi

•          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

# Mail Subject changed to "DB registration requirement"

Sanjaya wrote:

Kosuke Ito wrote:

...

...

...

...

...

• What would be the minimum registration requirements per endsite?

A suggestion JPNIC has is to allow all dynamic assignments and /64s to be aggregated as LIR's infrastructure, but require all other assignments per endsite, to be consistent with v4.

Would there be any particular motivation to deviate from a practice that is consistent with Ipv4? (I can't think of any at this stage.)

The reason I can think of is the overall size of the IPv6 space. If people starts registering /64s and smaller assignments to the NIR/RIR, our disk storage will fill up rather quickly and the utilization calculation will take longer. I'm not saying this can't be done.

Considering that the registration requirement primary reason is to measure utilization, how about aggregating the assignment report to whatever size the HD ratio calculation is based on? And can we confirm that it is now based on /56?

I understand the registration requirement as for clarifying who is in responsible of the address space as well as for calculating utilization. Assuming this is the case, wouldn't it blur who is responsible for the address space if we allow aggregation in /56?

I agree. There is no technical reason to say which size. It is the matter of balancing between how precisely RIR/NIR need to know the utilization of allocated address space and how easy each LIR report/register it with the reasonably low overhead.

Kosuke

Good points Izumi and Kosuke. Other than potential disk space and calculation issues (not an insurmountable issue whatsoever), I have no objections to either use the current IPv4 registration requirement or amend it to encourage/require aggregation at the infrastructure level.

Thanks Sanjaya.

Just to clarify our intention a little more, JPNIC suggested that ISPs can aggregate /64s as their infrastructures as they can be considered as router interface address(just like /30s in IPv4).

We don't see reasons for other sizes to be aggregated at this stage, but interested to hear other opinions as well.

Izumi

Randy Bush wrote:

...

Just to clarify our intention a little more, JPNIC suggested that ISPs can aggregate /64s as their infrastructures as they can be considered as router interface address(just like /30s in IPv4).

conservative isps use /126 for point to point links. there is no actual need for more. as to why /127's do not work, see rfc 3627.

Ack'd.I heard /64 is quite common in practice, so I felt we could accomodate upto /64s.

Perhaps, we don't need to specify the size and state that assignments to router interface can be considered as infrastructure? Or are you suggesting that any size shorter than /126 should be registered indivisually?

Izumi

# Mail Subject changed to "The initial allocation criteria"

(snip)

...

...

...

...

• Should the initial allocation criteria be changed with this policy to

200 customers, instead of /48s?

(have a plan for making at least 200 /48 assignments to other organizations within two years."

This could be a logically consistent change, in that it appears that the intent of the Ipv6 allocation policy is to allow IPv6 resource allocations to be available to service providers with customers.

Thanks. Yes, it seems to me that /48 has lost its original context now that ISPs can assign any size to its customers.

This, my understand, is not influencing to the initial allocation criteria of having a plan of service size at least 200 /48s assignments to other organizations (maybe 200 "customers" when assigning a /48 each) within two years. And also, the original policy does mention that it is on the LIRs decision which size of address space up to a /48 to their customers. RIR/NIR will not give any comment on it unless LIR need to assign the larger size than a /48 to a customer. From the beginning, the assignment size is flexible between /48 to /64.

(snip)

Thanks for the clarification Kosuke-san. Understood that the policy had been flexible about the assignment size from when it was first adopoted.

Either way, the current initial allocation criteria is tough for ISPs that chose to assign, say, /56 to a single customer(they must have a plan for 51,200*/56 assignments). It's even tougher if they assign /64s.

If we wish to give choices to ISPs about the assignment size, I think we should make conditions equal for all sizes at the initial allocation as well.

Izumi