Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria

[Dean Pemberton]

Changing or removing the rules is not the way to address people submitting
invalid or misleading information.

Also I doubt that the hostmasters would be 'aware' of a case. If they were
then the question would be why did they approve the resource application.



On Wednesday, 4 February 2015, Aftab Siddiqui 
wrote:

> Hi Dean,
> Thanks for raising the question.
>
> Could I ask that the APNIC hostmasters to comment on the following:
>>
>> Have you ever been made aware of a situation where due of the current
>> wording of the relevant clauses in the policy, a member or potential member
>> has not made a resource application where they would otherwise have been
>> able to?
>>
>
> Would like to add something here to the question, "have you even been made
> aware of a situation where applicant provided wrong or fake multi-homing
> information just to meet the criteria?"
>
>
>> In other words has the current policy in the eyes of the host masters
>> ever been a barrier to entry?
>>
>> Very valid point.
>
>
> Regards,
>
> Aftab A. Siddiqui
>
>
>


-- 
--
Dean Pemberton

Technical Policy Advisor
InternetNZ
+64 21 920 363 (mob)
d...@internetnz.net.nz

To promote the Internet's benefits and uses, and protect its potential.
*  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

Re: [sig-policy] [New Policy Proposal ] prop-112: On demand expansion of IPv6 address allocation size in legacy IPv6 space [SECURITY=UNCLASSIFIED]

[Owen DeLong]

> On Feb 3, 2015, at 7:47 PM, (Tomohiro -INSTALLER- Fujisaki/藤崎 智宏) 
>  wrote:
> 
> 
> Hi Owen, Mike,
> 
> Thank you for your comments.
> 
> I'm the author of prop-112.
> 
> The purpose of this policy proposal is not to align the boundary but
> to utilize unused space. Up to /29 is reserved for each /32 in the
> legacy space.

I understood that from the beginning.

I oppose that purpose.

I would support policy that provided nibble-aligned boundaries.

I hope this is sufficiently clear.

> 
> | From: sig-policy-boun...@lists.apnic.net 
> [mailto:sig-policy-boun...@lists.apnic.net] On Behalf Of Owen DeLong
> | Sent: Wednesday, 4 February 2015 4:05 p.m.
> | To: Masato Yamanishi
> | Cc: sig-policy@lists.apnic.net
> | Subject: Re: [sig-policy] [New Policy Proposal ] prop-112: On demand 
> expansion of IPv6 address allocation size in legacy IPv6 space
> | 
> | I will again oppose this as written. I would much rather see policy deliver 
> nibble-boundary based allocations.
> | 
> | I would rather see such organizations issued new /28s than expand these 
> /32s into /29s.
> 
> And renumbering will be necessary for this expansion, and the
> legacy space folders have used their address space for a long time,
> it might be difficult.

No, I am not proposing that anyone be required to renumber. I am proposing 
giving them a second prefix, requesting that they not make any new assignments 
in the old prefix and that when or if it dies of attrition, the old prefix be 
returned.

> Technically, I also think nibble boundary is reasonable, but that
> should be considered in other proposal.

Then I oppose this proposal as written. I made a proposal for nibble 
boundaries, but it was rejected, largely due to misunderstandings and some 
difficulties with power during the meeting where I was presenting the proposal 
remotely.

Owen

*  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

Re: [sig-policy] [New Policy Proposal ] prop-112: On demand expansion of IPv6 address allocation size in legacy IPv6 space [SECURITY=UNCLASSIFIED]

[Owen DeLong]

> On Feb 3, 2015, at 8:12 PM, Robert Hudson  wrote:
> 
> On 4 February 2015 at 14:54, Dean Pemberton  > wrote:
> There are a number of things that concern me about this proposal. 
> 
> 1) it doesn't appear to support needs based allocation
> 2) it doesn't support allocation on nibble boundaries which operators have 
> said repeatedly is a major issue. 
> 
> As I read it...
> 
> The proposal addresses only organisations who already have /32 allocations in 
> the legacy IPv6 block (the IP ranges this includes are defined in the 
> proposal).  The allocation policy in the legacy block was effectively to 
> carve out a /29, but then only provide the applicant with a /32 out of this 
> /29 - meaning the gap between the /29 and the /32 remains un-allocated.

That is correct. However, rather than expanding this swamp, I would support 
issuing additional /28s to these organizations and draining the early 
allocation swamp through attrition.

> Prop-112 simply proposes that the owner of one of these /32 allocations can, 
> if the require it, request to "fill out" the /29 which is allocated to them 
> in the back-end, so that they end up with a contiguous block of IP address 
> space.  It is not possible to stretch this to a nibble boundary (/28), 
> because the next allocation in the legacy IPv6 block could/would overlap this.

Correct, hence my suggestion that they simply be issued new /28s.

> The proposal does NOT impact /32 allocations that were made since the newer 
> policy of sparse allocation was introduced.  Those are left to be dealt with 
> under the existing rules.
> 
> If the proposal is not accepted, the gap between /32 and /29 is "wasted" for 
> every allocation within the legacy IPv6 block.  This "wastes" 30,064,771,072 
> /64 networks, unless a policy is proposed and approved to somehow use this 
> address space in another fashion.

Note there are actually multiple blocks as pointed out. Forever is a very long 
time.

The better solution, which does not waste all of them forever, is to allocate 
new /28s to those organizations that need more than a /32 ask that they not 
make any new allocations or assignments within the original /32, and return the 
/32 when or if they ever vacate it through attrition.

For organizations that are lucky enough to have the correct neighbor vacate 
their /32, their prefix could, then, be expanded to a /28 without issue.

Even with this policy, most of that space will remain wasted anyway, it will 
just be wasted in a different place where it can never be used for a different 
purpose.

> I'm happy to be corrected on any of this.  But if my understanding is 
> correct, the benefits of this proposal vastly outweigh any negatives, and I 
> believe SAGE-AU will be supporting it.

They do not, actually. While 30,064,771,072 sounds like a lot of /64s, the 
simple reality is that when you’re handing them out to end-users 65,536 at a 
time and to ISPs 4,294,967,296 at a time (minimum), it’s really not so many. 
When you consider that RIRs are given more than 1024 times that amount of space 
each time they apply to IANA and that no RIR has even come close to needing a 
second /12 from IANA so far, I think it is better to hold that particular space 
in reserve until its current mess is cleaned up through attrition, even if that 
never happens.

Owen

*  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

Re: [sig-policy] [New Policy Proposal ] prop-112: On demand expansion of IPv6 address allocation size in legacy IPv6 space [SECURITY=UNCLASSIFIED]

[Owen DeLong]

> On Feb 3, 2015, at 8:12 PM, Robert Hudson  > wrote:
> 
> On 4 February 2015 at 14:54, Dean Pemberton  > wrote:
> There are a number of things that concern me about this proposal. 
> 
> 1) it doesn't appear to support needs based allocation
> 2) it doesn't support allocation on nibble boundaries which operators have 
> said repeatedly is a major issue. 
> 
> As I read it...
> 
> The proposal addresses only organisations who already have /32 allocations in 
> the legacy IPv6 block (the IP ranges this includes are defined in the 
> proposal).  The allocation policy in the legacy block was effectively to 
> carve out a /29, but then only provide the applicant with a /32 out of this 
> /29 - meaning the gap between the /29 and the /32 remains un-allocated.

That is correct. However, rather than expanding this swamp, I would support 
issuing additional /28s to these organizations and draining the early 
allocation swamp through attrition.

> Prop-112 simply proposes that the owner of one of these /32 allocations can, 
> if the require it, request to "fill out" the /29 which is allocated to them 
> in the back-end, so that they end up with a contiguous block of IP address 
> space.  It is not possible to stretch this to a nibble boundary (/28), 
> because the next allocation in the legacy IPv6 block could/would overlap this.

Correct, hence my suggestion that they simply be issued new /28s.

> The proposal does NOT impact /32 allocations that were made since the newer 
> policy of sparse allocation was introduced.  Those are left to be dealt with 
> under the existing rules.
> 
> If the proposal is not accepted, the gap between /32 and /29 is "wasted" for 
> every allocation within the legacy IPv6 block.  This "wastes" 30,064,771,072 
> /64 networks, unless a policy is proposed and approved to somehow use this 
> address space in another fashion.

Note there are actually multiple blocks as pointed out. Forever is a very long 
time.

The better solution, which does not waste all of them forever, is to allocate 
new /28s to those organizations that need more than a /32 ask that they not 
make any new allocations or assignments within the original /32, and return the 
/32 when or if they ever vacate it through attrition.

For organizations that are lucky enough to have the correct neighbor vacate 
their /32, their prefix could, then, be expanded to a /28 without issue.

Even with this policy, most of that space will remain wasted anyway, it will 
just be wasted in a different place where it can never be used for a different 
purpose.

> I'm happy to be corrected on any of this.  But if my understanding is 
> correct, the benefits of this proposal vastly outweigh any negatives, and I 
> believe SAGE-AU will be supporting it.

They do not, actually. While 30,064,771,072 sounds like a lot of /64s, the 
simple reality is that when you’re handing them out to end-users 65,536 at a 
time and to ISPs 4,294,967,296 at a time (minimum), it’s really not so many. 
When you consider that RIRs are given more than 1024 times that amount of space 
each time they apply to IANA and that no RIR has even come close to needing a 
second /12 from IANA so far, I think it is better to hold that particular space 
in reserve until its current mess is cleaned up through attrition, even if that 
never happens.

Owen

*  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] New Version of prop-115-v001: Registration of detailed assignment information in whois DB

[Masato Yamanishi]

Dear SIG members

The Problem statement "Registration of detailed assignment information
in whois DB" has been assigned a Policy Proposal number following the
submission of a new version sent to the Policy SIG for consideration.

The proposal, "prop-115-v001: Registration of detailed assignment
information in whois DB" now includes an objective and proposed solution.

Information about this and earlier versions is available from:

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

You are encouraged you to express your views on the proposal:

 - Do you support or oppose this proposal?
 - Does this proposal solve a problem you are experiencing? If so,
   tell the community about your situation.
 - Do you see any disadvantages in this proposal?
 - Is there anything in the proposal that is not clear?
 - What changes could be made to this proposal to make it more
   effective?



Regards,

Masato




prop-115-v001: Registration of detailed assignment information in
   whois DB


Proposer:  Ruri Hiromi
   hir...@inetcore.com

   Tomohiro Fujisaki
   fujis...@syce.net


1. Problem statement


Recently, there are some cases need to get IP address assignment
information in more detail to specify user IP address.

With out this information, operators cannot filter out specific
address range, and it might lead to 'over-filter' (i.e. filtering
whole ISP's address range).

For example:

1) 'Port' range information in IPv4

ISPs are using 'CGN' or other kinds of IPv4 address sharing
technology with assignment of IP address and specified port
range to their users.

In this case, port information is necessary to specify one user.

ex) 192.0.2.24/32 1-256 is for HomeA
192.0.2.24/32 257-511 is for HomeB

or 192.0.2.0/24 1-65536 is shared address of ISP-X
minimum size is /32

2) address assignment size information in IPv6

   The IPv6 address assignment size may be different from ISP to
   ISP, and address ranges in one ISP. Address assignment prefix
   size will be necessary.

   ex) 2001:db8:1::0/56 is for HomeA
   2001:db8:1:1::0/48 is for HomeB

   or 2001:db8:1::/36's minimum size is /56


2. Objective of policy change
-

Lots of operators look a record when harmful behavior coming to
their network to identify its IP address confirming it can be
filtered or not.

The goal is providing more specific information to support these
actions.


3. Situation in other regions
-

No same regulation/discussion can be seen in other regions.


4. Proposed policy solution
---

Provide accurate filtering information generated from whois DB.

For IPv4, propose to add 'port range' information to IP address
entry.

For IPv6, propose to provide 'assignment prefix size' information
for specific IPv6 address.


5. Advantages / Disadvantages
-

Advantages:

 - operators can set filtering by IP address based on correct assignment
   information base.

 - users who share same address space can be avoid to be including bulk
   filtering.

Disadvantages:

 - registration rule will move to more strict manner.

 - strict watch and control in registration of database records.

 - additional record or option will be considered.

 - privilege for withdrawing detailed information will be set for these
   records.


6. Impact on APNIC
--

This might be beyond the scope of using whois DB.


7. Other Consideration
--

For the security reason, this detailed records may be able to see
only by operators.(some kind of user control/privilege setting is
needed)

For hosting services, /32 in IPv4 and /128 in IPv6 registration
should be discussed based on its operability and possibility. But a
harmful activities to filter by IP addresses are coming from hosting
services as well. Here it seemed to be some demands.


References
--

TBD
*  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

Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria

[George Kuo]

Hello Dean,

We are not aware of any potential members who may have decided not to 
apply for IPv4 addresses or AS numbers based on how they have 
interpreted the policy wording.


However, we explain the policy criteria to any potential members who do 
contact APNIC, and those who are not multihoming do not qualify for An 
IPv4 or ASN assignment based on the current policy.


Currently, we don't keep a record of these unsuccessful requests, but
we can begin to keep records in the future if this information is
required.

George K

On 4/02/2015 5:13 am, Dean Pemberton wrote:

Could I ask that the APNIC hostmasters to comment on the following:

Have you ever been made aware of a situation where due of the current
wording of the relevant clauses in the policy, a member or potential
member has not made a resource application where they would otherwise
have been able to?

In other words has the current policy in the eyes of the host masters
ever been a barrier to entry?




On Wednesday, 4 February 2015, Masato Yamanishi mailto:myama...@gmail.com>> wrote:

Dear SIG members

The proposal "prop-114: Modification in the ASN eligibility criteria"
has been sent to the Policy SIG for review.

It  will be presented at the Open Policy Meeting at APNIC 39 in Fukuoka,
Japan on Thursday, 5 March 2015.

We invite you to review and comment on the proposal on the mailing list
before the meeting.

The comment period on the mailing list before an APNIC meeting is an
important part of the policy development process. We encourage you to
express your views on the proposal:

  - Do you support or oppose this proposal?
  - Does this proposal solve a problem you are experiencing? If so,
   tell the community about your situation.
  - Do you see any disadvantages in this proposal?
  - Is there anything in the proposal that is not clear?
  - What changes could be made to this proposal to make it more
   effective?


Information about this proposal is available at:

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


Regards,

Masato





---
prop-114-v001: Modification in the ASN eligibility criteria
---

Proposer: Aftab Siddiqui
aftab.siddi...@gmail.com


   Skeeve Stevens
ske...@eintellegonetworks.com



1. Problem statement


 The current ASN assignment policy dictates two eligibility criteria
 and both should be fulfilled in order to get an ASN. The policy
 seems to imply that both requirements i.e. multi-homing and clearly
 defined single routing policy must be met simultaneously, this has
 created much confusion in interpreting the policy.

 As a result organizations have either provided incorrect
information
 to get the ASN or barred themselves from applying.


2. Objective of policy change
-

 In order to make the policy guidelines simpler we are proposing to
 modify the text describing the eligibility criteria for ASN
 assignment by removing multi-homing requirement for the
organization.


3. Situation in other regions
-

ARIN:
 It is not mandatory but optional to be multi-homed in order get ASN

RIPE:
 Policy to remove multi-homing requirement is currently in
discussion
 and the current phase ends 12 February 2015
 Policy - https://www.ripe.net/ripe/policies/proposals/2014-03

LACNIC:
 only inter-connect is mandatory not multi-homing

AFRINIC:
  It is mandatory to be multi-homed in order to get ASN.


4. Proposed policy solution
---

 An organization is eligible for an ASN assignment if it:
  - Is planning to use it within next 6 months


5. Advantages / Disadvantages
-

Advantages:

 Removing the mandatory multi-homing requirement from the policy
will
 make sure that organizations are not tempted to provide wrong
 information in order to fulfil the criteria of eligibility.

Disadvantages:

 No disadvantage.


6. Impact on resource holders
-

 No impact on existing resource holders.


7. References
-



--
--
Dean Pemberton

Technical Policy Advisor
InternetNZ
+64 21 920 363 (mob)
d...@internetnz.net.nz 

To promote the Internet's benefits and uses, and protect its potential.


*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/list

Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria

[Dean Pemberton]

So it doesn't look like there is a problem here.

The hostmasters are clear about the current policy, they explain it to
people who contact them.

Am I missing something?  I'm not at all in favour of policy for policy
sake.

What's the problem statement here?

On Thursday, 5 February 2015, George Kuo  wrote:

> Hello Dean,
>
> We are not aware of any potential members who may have decided not to
> apply for IPv4 addresses or AS numbers based on how they have interpreted
> the policy wording.
>
> However, we explain the policy criteria to any potential members who do
> contact APNIC, and those who are not multihoming do not qualify for An IPv4
> or ASN assignment based on the current policy.
>
> Currently, we don't keep a record of these unsuccessful requests, but
> we can begin to keep records in the future if this information is
> required.
>
> George K
>
> On 4/02/2015 5:13 am, Dean Pemberton wrote:
>
>> Could I ask that the APNIC hostmasters to comment on the following:
>>
>> Have you ever been made aware of a situation where due of the current
>> wording of the relevant clauses in the policy, a member or potential
>> member has not made a resource application where they would otherwise
>> have been able to?
>>
>> In other words has the current policy in the eyes of the host masters
>> ever been a barrier to entry?
>>
>>
>>
>>
>> On Wednesday, 4 February 2015, Masato Yamanishi > > wrote:
>>
>> Dear SIG members
>>
>> The proposal "prop-114: Modification in the ASN eligibility criteria"
>> has been sent to the Policy SIG for review.
>>
>> It  will be presented at the Open Policy Meeting at APNIC 39 in
>> Fukuoka,
>> Japan on Thursday, 5 March 2015.
>>
>> We invite you to review and comment on the proposal on the mailing
>> list
>> before the meeting.
>>
>> The comment period on the mailing list before an APNIC meeting is an
>> important part of the policy development process. We encourage you to
>> express your views on the proposal:
>>
>>   - Do you support or oppose this proposal?
>>   - Does this proposal solve a problem you are experiencing? If
>> so,
>>tell the community about your situation.
>>   - Do you see any disadvantages in this proposal?
>>   - Is there anything in the proposal that is not clear?
>>   - What changes could be made to this proposal to make it more
>>effective?
>>
>>
>> Information about this proposal is available at:
>>
>> http://www.apnic.net/policy/proposals/prop-114
>>
>>
>> Regards,
>>
>> Masato
>>
>>
>>
>>
>>
>> ---
>> prop-114-v001: Modification in the ASN eligibility criteria
>> ---
>>
>> Proposer: Aftab Siddiqui
>> aftab.siddi...@gmail.com
>> 
>>
>>Skeeve Stevens
>> ske...@eintellegonetworks.com
>> 
>>
>>
>> 1. Problem statement
>> 
>>
>>  The current ASN assignment policy dictates two eligibility
>> criteria
>>  and both should be fulfilled in order to get an ASN. The policy
>>  seems to imply that both requirements i.e. multi-homing and
>> clearly
>>  defined single routing policy must be met simultaneously, this
>> has
>>  created much confusion in interpreting the policy.
>>
>>  As a result organizations have either provided incorrect
>> information
>>  to get the ASN or barred themselves from applying.
>>
>>
>> 2. Objective of policy change
>> -
>>
>>  In order to make the policy guidelines simpler we are proposing
>> to
>>  modify the text describing the eligibility criteria for ASN
>>  assignment by removing multi-homing requirement for the
>> organization.
>>
>>
>> 3. Situation in other regions
>> -
>>
>> ARIN:
>>  It is not mandatory but optional to be multi-homed in order get
>> ASN
>>
>> RIPE:
>>  Policy to remove multi-homing requirement is currently in
>> discussion
>>  and the current phase ends 12 February 2015
>>  Policy - https://www.ripe.net/ripe/
>> policies/proposals/2014-03
>>
>> LACNIC:
>>  only inter-connect is mandatory not multi-homing
>>
>> AFRINIC:
>>   It is mandatory to be multi-homed in order to get ASN.
>>
>>
>> 4. Proposed policy solution
>> ---
>>
>>  An organization is eligible for an ASN assignment if it:
>>   - Is planning to use it within next 6 months
>>
>>
>> 5. Advantages / Disadvantages
>> -
>>
>> Advantages:
>>
>>  Removing the mandatory multi-homing requirement from the policy
>> will
>>  make sure that organizations are not tempted to provide wrong
>>  info