[arin-ppml] Draft Policy 2010-7: Simplified IPv6 policy
Member Services
info at arin.net
Tue Feb 23 15:24:24 EST 2010
Draft Policy 2010-7
Simplified IPv6 policy
On 18 February 2010 the ARIN Advisory Council (AC) selected "Simplified
IPv6 policy " as a draft policy for adoption discussion on the PPML and
at the Public Policy Meeting in Toronto in April.
The draft was developed by the AC from policy proposal "106. Simplified
IPv6 policy". Per the Policy Development Process the AC submitted text
to ARIN for a staff and legal assessment prior to its selection as a
draft policy. Below the draft policy is the ARIN staff and legal
assessment, followed by the text that was submitted by the AC.
Draft Policy 2010-7 is below and can be found at:
https://www.arin.net/policy/proposals/2010_7.htm
You are encouraged to discuss Draft Policy 2010-7 on the PPML prior to
the April Public Policy Meeting. Both the discussion on the list and
at the meeting will be used by the ARIN Advisory Council to determine
the community consensus for adopting this as policy.
The ARIN Policy Development Process can be found at:
https://www.arin.net/policy/pdp.html
Draft Policies and Proposals under discussion can be found at:
https://www.arin.net/policy/proposals/index.html
Regards,
Member Services
American Registry for Internet Numbers (ARIN)
## * ##
Draft Policy 2010-7
Simplified IPv6 policy
Version/Date: 23 February 2010
Policy statement:
Delete 6.1 Introduction - This is all historical.
Leave 6.3 as is (renumber to 6.1) - These still accurately reflect the
Goals we want our policy to follow.
Delete 6.4.2 - 6.4.4 - These principles don't seem worthy of elevation
to special status. 6.4.1 is handled in a separate Draft Policy.
Replace 6.5 - Policies for allocations and assignments with text below
(renumber to 6.2). This seems to be where most of the changes and
simplification are needed.
Delete 6.7 Appendix A: HD-Ratio - The numbers from this table were used
to determine the thresholds in 6.2 below, so this section is confusing
and no longer needed.
Delete 6.9 IPv6 Reassignments policy - This is redundant and covered
better elsewhere.
Move 6.10 into 6.2.3.2 below
Replacement text:
2.12. Critical Infrastructure Providers
Critical infrastructure providers of the Internet include public
exchange points, core DNS service providers (e.g. ICANN-sanctioned root,
gTLD, and ccTLD operators) as well as the RIRs and IANA.
4.4. Micro-allocation
ARIN will make IPv4 micro-allocations to Critical Infrastructure
Providers per section 2.8. These allocations will be no longer than a
/24. Multiple allocations may be granted in certain situations.
4.4.1. Allocation and assignment from specific blocks
Exchange point allocations MUST be allocated from specific blocks
reserved only for this purpose. All other micro-allocations WILL be
allocated out of other blocks reserved for micro-allocation purposes.
ARIN will make a list of these blocks publicly available.
4.4.2. Exchange point requirements
Exchange point operators must provide justification for the allocation,
including: connection policy, location, other participants (minimum of
two total), ASN, and contact information. ISPs and other organizations
receiving these micro-allocations will be charged under the ISP fee
schedule, while end-users will be charged under the fee schedule for
end-users. This policy does not preclude exchange point operators from
requesting address space under other policies.
6.2. Policies for IPv6 allocations and assignments
6.2.1. Allocations and assignments
To meet the goal of Fairness, ARIN makes both allocations and
assignments according to common criteria. Allocations are made to LIRs,
and assignments to certain end users.
6.2.2. Assignments from LIRs/ISPs
End-users are assigned an end site assignment from their LIR or ISP. The
exact size of the assignment is a local decision for the LIR or ISP to
make, using a minimum value of a /64 (when only one subnet is
anticipated for the end site) up to the normal maximum of /48, except in
cases of extra large end sites where a larger assignment can be justified.
The following guidelines may be useful (but they are only guidelines):
* /64 when it is known that one and only one subnet is needed
* /56 for small sites, those expected to need only a few subnets
over the next 5 years.
* /48 for larger sites
For end sites to whom reverse DNS will be delegated, the LIR/ISP should
consider making an assignment on a nibble (4-bit) boundary to simplify
reverse lookup delegation.
6.2.3. Allocations and assignments from ARIN
6.2.3.1 Goals
To balance the goals of Aggregation, Conservation, Fairness, and
Minimized Overhead, ARIN normally issues IPv6 addresses only in the
discrete sizes of /48, /40, /32, /28, /24, or larger. Each organization
or discrete network may qualify for one allocation or assignment of each
size.
6.2.3.1.1 Allocation and assignment from specific blocks
Each allocation/assignment size will be made out of separate blocks
reserved for that purpose. Additionally, non-routed assignments for
internal infrastructure, and assignments to Critical Infrastructure
Providers per section 2.8, will each be made out of separate blocks
reserved for those purposes. ARIN will make a list of these blocks
publicly available.
6.2.3.2 X-Small (/48)
To qualify for a /48 allocation or assignment, an organization must:
* Be Multihomed per section 2.7, and qualify for an ASN per section
5; or
* Serve at least 1000 hosts; or
* Demonstrate efficient utilization of all direct IPv4 assignments
and allocations, each of which must be covered by any current ARIN RSA; or
* Require a non-routed block for internal infrastructure; or
* Be a Critical Infrastructure Provider per section 2.8.
6.2.3.3 Small (/40)
To qualify for a /40 allocation or assignment, an organization must:
* Have two or more Multihomed sites, each of which would qualify
for a /48; or
* Serve at least 2000 hosts; or
* Be an LIR.
6.2.3.4 Medium (/32)
To qualify for a /32 allocation or assignment, an organization must:
* Have 100 or more sites, each of which would qualify for a /48; or
* Be an existing, known LIR; or
* Have a plan to provide IPv6 connectivity to other organizations
and assign at least 100 end-site assignments to those organizations
within 5 years.
6.2.3.5 Large (/28)
To qualify for a /28, an organization must demonstrate the need to make
assignments and/or reallocations equal to at least 25,000 /48s, based on
current network infrastructure and customer base.
6.2.3.6 X-Large (/24)
To qualify for a /24, an organization must demonstrate the need to make
assignments and/or reallocations equal to at least 330,000 /48s, based
on current network infrastructure and customer base.
6.2.3.7 XX-Large (larger than /24)
Allocations or assignments larger than /24 may be made only in
exceptional cases, to organizations that demonstrate the need to make
assignments and/or reallocations equal to at least 4,500,000 /48s, based
on current network infrastructure and customer base. If approved, the
allocation prefix length will be based on the number of /24s justified
(at 4,500,000 /48s each), rounded up to the next whole CIDR prefix.
Subsequent XX-Large assignments may be made if justified using the same
criteria.
6.3. Registration (Copied from NRPM 6.5.5)
When an organization holding an IPv6 address allocation makes IPv6
address assignments, it must register assignment information in a
database, accessible by RIRs as appropriate (information registered by
ARIN may be replaced by a distributed database for registering address
management information in future). Information is registered in units of
assigned /56 networks. When more than a /56 is assigned to an
organization, the assigning organization is responsible for ensuring
that the address space is registered in an ARIN database.
6.3.1. Residential Customer Privacy (Copied from NRPM 6.5.5.1)
To maintain the privacy of their residential customers, an organization
with downstream residential customers may substitute that organization's
name for the customer's name, e.g. 'Private Customer - XYZ Network', and
the customer's street address may read 'Private Residence'. Each private
downstream residential reassignment must have accurate upstream Abuse
and Technical POCs visible on the WHOIS record for that block.
6.3.2. Reverse lookup (Copied from NRPM 6.5.6)
When ARIN delegates IPv6 address space to an organization, it also
delegates the responsibility to manage the reverse lookup zone that
corresponds to the allocated IPv6 address space. Each organization
should properly manage its reverse lookup zone. When making an address
assignment, the organization must delegate to an assignee organization,
upon request, the responsibility to manage the reverse lookup zone that
corresponds to the assigned address.
Rationale:
This policy proposal attempts to simplify IPv6 policy in a number of ways.
For example, it:
* Deletes a number of historical sections and items that duplicate
text elsewhere in the NRPM.
* Removes the HD-ratio, instead incorporating values calculated
from it as the basis for qualification criteria.
It also replaces & rewrites section 6.5 "Policies for allocations and
assignments" entirely. This rewrite:
* Eliminates the different criteria for allocations (ISPs) vs.
assignments (end users) and replaces them with a single common set of
criteria for both classes of users. The allocation vs. assignment
distinction itself is preserved, as it still forms a useful basis for a
cost-recovery fee structure, and for other parts of the NRPM (such as
whois policy).
* Creates a size-class-based system for allocating IPv6 address
blocks.
This has a number of advantages over the existing policy:
* Allows for safe filtering of traffic-engineering (TE)
more-specific route announcements.
* In exchange (since PA more-specifics are expected to be
filterable), allows any multihomed organization to get an assignment
from ARIN. The smaller number of such PI assignments (compared to TE
more-specifics) should mean that such assignments will largely be
accepted across the DFZ.
* Expands the use of discrete blocks from which all allocations
will be of identical prefix length and categorization. This will enable
safer and easier TE filtering, as mentioned above.
* Expands the availability of non-routed blocks for internal
infrastructure. Since routable blocks are available to any multihomed
organization, there is no longer a need to restrict the availability of
blocks from the non-routable pool.
* Makes allocations available to any LIR.
Note: In the event of an M&A transfer per section 8.2 that would result
in more than one block of a given size class being held by the combined
organization, the organization should be encouraged to renumber into a
single larger block and return the smaller block(s) when feasible.
However, as long as the organization doesn't require any additional
resources, this policy does not force them to make any changes. OTOH, if
they request a larger block and still hold two or more smaller blocks,
they would be required to return the smaller block as a condition for
receiving the larger one.
Related non-policy suggestion: in order to provide a small incentive for
organizations to renumber and return out of smaller unneeded blocks, the
ARIN fee schedule could be modified such that fees are assessed,
according to the ARIN fee schedule, for each size block issued, rather
than based on the total quantity of space held.
FAQs:
Q1: How did you come up with the thresholds?
A1: /48: Many of the criteria for a /48 were copied from existing
policy. The notable exception is that any Multihomed network that
qualifies for an ASN can also get a /48. /40: Since we don't give out
multiple /48s (except in the case of MDN), anyone outgrowing a /48 needs
a /40. Hence, the /40 requirements are 2x the /48 requirements. In
addition, LIRs who don't qualify for a /32 can get a /40, since they
need to be able to assign /48s. /32: Some of these requirements were
inherited from existing policy. The existing 200 sites requirement was
reduced to 100, and made to apply to assignments as well as allocations.
/28: Since we don't give out multiple /32s (except in the case of MDN),
anyone outgrowing a /32 needs a /28. The /28 requirements are based on
the current HD-ratio-based requirement for a /32 (6,183,533 /56s)
converted to /48s (24154) and rounded up to 25,000. /24+: Similarly, the
requirements for a /24 are based on the HD-ratio requirement for a /28,
and the requirement for more than one /24 are based on the HD-ratio
requirement for a /24.
Q2: What about timeframes for meeting the allocation criteria?
A2: All requests are based on current usage, so no timeframes are
involved. For example, if an ISP has a /32 and is applying for a /28,
they will be required to demonstrate that they have already assigned
25,000 /48s. Since there are 64k /48s in a /32, there is no longer any
need to make predictions about future assignments.
Q3: The proposal says "Each organization or discrete network may qualify
for one allocation or assignment of each size". It is fairly clear how
staff would evaluate whether a network qualifies for a given block size,
if it's the first block, but it is not clear how it would work if the
network already has a block assigned or allocated to it.
For instance, suppose a network has 50 sites. They qualify for a /40. A
year later they come back, have 150 sites, and want a /32. Do they
qualify for a /32, because they have more than 100 sites, or is some
consideration given to how the existing /40 has been used? It seems like
the former would be the logical interpretation, since the policy doesn't
mention anything about consideration of existing blocks, and says you
can have one of each block size.
A3: Correct. If you qualify for a larger block, you also qualify for one
of each smaller size.
Timetable for implementation: Immediate (as soon as practical).
#####
STAFF ASSESSMENT
Proposal: Simplified IPv6 Policy
Proposal Version (Date): 01 February 2010
Date of Assessment: 16 February 2010
1. Proposal Summary (Staff Understanding)
ARIN staff understands this policy would allow a network (whether ISP or
end-user) to qualify for one each of the following prefix lengths: /48,
/40, /32, /28, and /24 (with anything larger being issued in /24 units).
Qualification is based on a number of factors including multi-homing,
host count, number of sites, and number of /48s projected to be used.
Each organization or discrete network can qualify for one block of each
size. Each block would be issued from a specific range reserved only
for that block size.
2. Comments
A. ARIN Staff Comments
• In section 6.2.3.1, the policy proposal notes: "and must pay fees
according to ARIN's fee schedule [1] for each size issued." This text
should be removed, as it is not policy text. Matters relating to fees
are outside the NRPM's purview and are typically covered under the ARIN
fee schedule https://www.arin.net/fees/fee_schedule.html.
• The policy provides no mechanism for a large network to get a 6th
network block if it efficiently utilizes its first 5 blocks. While this
likely won't be an issue for a few years, it bears consideration for
future policy development.
• The policy says to move current NRPM sections 6.9 and 6.10 into
6.2.3.2 and provides replacement text; however, staff cannot see where
6.9 is covered. In further review of 6.9, it appears that this is
redundant text which is already covered in NRPM section 6.5.4 so we
suggest removing 6.9 from the policy text altogether.
B. ARIN General Counsel
"At this time counsel has no significant legal comments.”
3. Resource Impact
This policy would have minimal resource impact. It is estimated that
implementation would occur within 3 months after ratification by the
ARIN Board of Trustees. The following would be needed in order to implement:
• New guidelines
• A new IPv6 request form
• Staff training
4. Proposal Text
Delete 6.1 Introduction - This is all historical.
Leave 6.3 as is (renumber to 6.1) - I think these still accurately
reflect the Goals we want our policy to follow.
Delete 6.4.2 - 6.4.4 - These principles don't seem worthy of elevation
to special status. 6.4.1 is handled in a separate Draft Policy.
Replace 6.5 - Policies for allocations and assignments with text below
(renumber to 6.2) This seems to be where most of the changes and
simplification are needed.
Delete 6.7 Appendix A: HD-Ratio - The numbers from this table were used
to determine the thresholds in 6.2 below, so this section is confusing
and no longer needed.
Move 6.9 and 6.10 into 6.2.3.2 below
Replacement text:
2.12. Critical Infrastructure Providers
Critical infrastructure providers of the Internet include public
exchange points, core DNS service providers (e.g. ICANN-sanctioned root,
gTLD, and ccTLD operators) as well as the RIRs and IANA.
4.4. Micro-allocation
ARIN will make IPv4 micro-allocations to Critical Infrastructure
Providers per section 2.8. These allocations will be no longer than a
/24. Multiple allocations may be granted in certain situations.
4.4.1. Allocation and assignment from specific blocks
Exchange point allocations MUST be allocated from specific blocks
reserved only for this purpose. All other micro-allocations WILL be
allocated out of other blocks reserved for micro-allocation purposes.
ARIN will make a list of these blocks publicly available.
4.4.2. Exchange point requirements
Exchange point operators must provide justification for the allocation,
including: connection policy, location, other participants (minimum of
two total), ASN, and contact information. ISPs and other organizations
receiving these micro-allocations will be charged under the ISP fee
schedule, while end-users will be charged under the fee schedule for
end-users. This policy does not preclude exchange point operators from
requesting address space under other policies.
6.2. Policies for IPv6 allocations and assignments
6.2.1. Allocations and assignments
To meet the goal of Fairness, ARIN makes both allocations and
assignments according to common criteria. Allocations are made to LIRs,
and assignments to certain end users.
6.2.2. Assignments from LIRs/ISPs
End-users are assigned an end site assignment from their LIR or ISP. The
exact size of the assignment is a local decision for the LIR or ISP to
make, using a minimum value of a /64 (when only one subnet is
anticipated for the end site) up to the normal maximum of /48, except in
cases of extra large end sites where a larger assignment can be justified.
The following guidelines may be useful (but they are only guidelines):
* /64 when it is known that one and only one subnet is needed
* /56 for small sites, those expected to need only a few subnets
over the next 5 years.
* /48 for larger sites
For end sites to whom reverse DNS will be delegated, the LIR/ISP should
consider making an assignment on a nibble (4-bit) boundary to simplify
reverse lookup delegation.
6.2.3. Allocations and assignments from ARIN
6.2.3.1 Goals
To balance the goals of Aggregation, Conservation, Fairness, and
Minimized Overhead, ARIN normally issues IPv6 addresses only in the
discrete sizes of /48, /40, /32, /28, or /24 or larger. Each
organization or discrete network may qualify for one allocation or
assignment of each size, and must pay fees according to ARIN's fee
schedule [1] <https://www.arin.net/fees/fee_schedule.html > for each
size issued.
6.2.3.1.1 Allocation and assignment from specific blocks
Each allocation/assignment size will be made out of separate blocks
reserved for that purpose. Additionally, non-routed assignments for
internal infrastructure, and assignments to Critical Infrastructure
Providers per section 2.8, will each be made out of separate blocks
reserved for those purposes. ARIN will make a list of these blocks
publicly available.
6.2.3.2 X-Small (/48)
To qualify for a /48 allocation or assignment, an organization must:
* Be Multihomed per section 2.7, and qualify for an ASN per section
5; or
* Serve at least 1000 hosts; or
* Demonstrate efficient utilization of all direct IPv4 assignments
and allocations, each of which must be covered by any current ARIN RSA; or
* Require a non-routed block for internal infrastructure; or
* Be a Critical Infrastructure Provider per section 2.8.
6.2.3.3 Small (/40)
To qualify for a /40 allocation or assignment, an organization must:
* Have two or more Multihomed sites, each of which would qualify for
a /48; or
* Serve at least 2000 hosts; or
* Be an LIR.
6.2.3.4 Medium (/32)
To qualify for a /32 allocation or assignment, an organization must:
* Have 100 or more sites, each of which would qualify for a /48; or
* Be an existing, known LIR; or
* Have a plan to provide IPv6 connectivity to other organizations
and assign at least 100 end-site assignments to those organizations
within 5 years.
6.2.3.5 Large (/28)
To qualify for a /28, an organization must demonstrate the need to make
assignments and/or reallocations equal to at least 25,000 /48s, based on
current network infrastructure and customer base.
6.2.3.6 X-Large (/24)
To qualify for a /24, an organization must demonstrate the need to make
assignments and/or reallocations equal to at least 330,000 /48s, based
on current network infrastructure and customer base.
6.2.3.7 XX-Large (larger than /24)
Allocations or assignments larger than /24 may be made only in
exceptional cases, to organizations that demonstrate the need to make
assignments and/or reallocations equal to at least 4,500,000 /48s, based
on current network infrastructure and customer base. If approved, the
allocation prefix length will be based on the number of /24s justified
(at 4,500,000 /48s each).
6.3. Registration (Copied from NRPM 6.5.5)
When an organization holding an IPv6 address allocation makes IPv6
address assignments, it must register assignment information in a
database, accessible by RIRs as appropriate (information registered by
ARIN may be replaced by a distributed database for registering address
management information in future). Information is registered in units of
assigned /56 networks. When more than a /56 is assigned to an
organization, the assigning organization is responsible for ensuring
that the address space is registered in an ARIN database.
6.3.1. Residential Customer Privacy (Copied from NRPM 6.5.5.1)
To maintain the privacy of their residential customers, an organization
with downstream residential customers may substitute that organization's
name for the customer's name, e.g. 'Private Customer - XYZ Network', and
the customer's street address may read 'Private Residence'. Each private
downstream residential reassignment must have accurate upstream Abuse
and Technical POCs visible on the WHOIS record for that block.
6.3.2. Reverse lookup (Copied from NRPM 6.5.6)
When ARIN delegates IPv6 address space to an organization, it also
delegates the responsibility to manage the reverse lookup zone that
corresponds to the allocated IPv6 address space. Each organization
should properly manage its reverse lookup zone. When making an address
assignment, the organization must delegate to an assignee organization,
upon request, the responsibility to manage the reverse lookup zone that
corresponds to the assigned address.
Rationale:
This policy proposal attempts to simplify IPv6 policy in a number of ways.
For example, it:
* Deletes a number of historical sections and items that duplicate
text elsewhere in the NRPM.
* Removes the HD-ratio, instead incorporating values calculated
from it as the basis for qualification criteria.
It also replaces & rewrites section 6.5 "Policies for allocations and
assignments" entirely. This rewrite:
* Eliminates the different criteria for allocations (ISPs) vs.
assignments (end users) and replaces them with a single common set of
criteria for both classes of users. The allocation vs. assignment
distinction itself is preserved, as it still forms a useful basis for a
cost-recovery fee structure, and for other parts of the NRPM (such as
whois policy).
* Creates a size-class-based system for allocating IPv6 address blocks.
This has a number of advantages over the existing policy:
* Allows for safe filtering of traffic-engineering (TE)
more-specific route announcements.
* In exchange (since PA more-specifics are expected to be
filterable), allows any multihomed organization to get an assignment
from ARIN. The smaller number of such PI assignments (compared to TE
more-specifics) should mean that such assignments will largely be
accepted across the DFZ.
* Expands the use of discrete blocks from which all allocations
will be of identical prefix length and categorization. This will enable
safer and easier TE filtering, as mentioned above.
* Expands the availability of non-routed blocks for internal
infrastructure. Since routable blocks are available to any multihomed
organization, there is no longer a need to restrict the availability of
blocks from the non-routable pool.
* Makes allocations available to any LIR.
Note: In the event of an M&A transfer per section 8.2 that would result
in more than one block of a given size class being held by the combined
organization, the organization should be encouraged to renumber into a
single larger block and return the smaller block(s) when feasible.
However, as long as the organization doesn't require any additional
resources, this policy does not force them to make any changes. OTOH, if
they request a larger block and still hold two or more smaller blocks,
they would be required to return the smaller block as a condition for
receiving the larger one.
FAQs:
Q1: How did you come up with the thresholds?
A1: /48: Many of the criteria for a /48 were copied from existing
policy. The notable exception is that any Multihomed network that
qualifies for an ASN can also get a /48. /40: Since we don't give out
multiple /48s (except in the case of MDN), anyone outgrowing a /48 needs
a /40. Hence, the /40 requirements are 2x the /48 requirements. In
addition, LIRs who don't qualify for a /32 can get a /40, since they
need to be able to assign /48s. /32: Some of these requirements were
inherited from existing policy. The existing 200 sites requirement was
reduced to 100, and made to apply to assignments as well as allocations.
/28: Since we don't give out multiple /32s (except in the case of MDN),
anyone outgrowing a /32 needs a /28. The /28 requirements are based on
the current HD-ratio-based requirement for a /32 (6,183,533 /56s)
converted to /48s (24154) and rounded up to 25,000. /24+: Similarly, the
requirements for a /24 are based on the HD-ratio requirement for a /28,
and the requirement for more than one /24 are based on the HD-ratio
requirement for a /24.
Q2: What about timeframes for meeting the allocation criteria?
A2: All requests are based on current usage, so no timeframes are
involved. For example, if an ISP has a /32 and is applying for a /28,
they will be required to demonstrate that they have already assigned
25,000 /48s. Since there are 64k /48s in a /32, there is no longer any
need to make predictions about future assignments.
Q3: The proposal says "Each organization or discrete network may qualify
for one allocation or assignment of each size". It is fairly clear how
staff would evaluate whether a network qualifies for a given block size,
if it's the first block, but it is not clear how it would work if the
network already has a block assigned or allocated to it.
For instance, suppose a network has 50 sites. They qualify for a /40. A
year later they come back, have 150 sites, and want a /32. Do they
qualify for a /32, because they have more than 100 sites, or is some
consideration given to how the existing /40 has been used? It seems like
the former would be the logical interpretation, since the policy doesn't
mention anything about consideration of existing blocks, and says you
can have one of each block size.
A3: Correct. If you qualify for a larger block, you also qualify for one
of each smaller size.
More information about the ARIN-PPML
mailing list