Re: [sig-policy] IPv6 Guidelines document
Thank you very much for editing the draft. I think it is compiled in
such a way to get across the points listed by the WG clearly.
I just have one comment and a question regarding the DB registration.
--------------------------------------------------------------------------
11 Registration requirements
---------------------------------
(snip)
* Assignments for networks of /48 or less may be registered, at
the discretion of the LIR and the network administrator.
* Assignments to hosts may be registered, at the discretion of
the LIR and the end site.
--------------------------------------------------------------------------
It is stated that assignments longer than /48 can be registered. Would
such registrations be taken into account when calculating the
utilization?
If the answer is yes, I am not sure if the needs for the registrations
are strong enough, especially registering assignments in host basis,
while adding complications to the policy as well as the registry
database.
Best Regards,
Izumi
From: Anne Lord <anne at apnic dot net>
Subject: [sig-policy] IPv6 Guidelines document
Date: Tue, 04 May 2004 17:43:20 +1000
> Dear colleagues,
>
> Appended to this email is the draft document "APNIC guidelines for IPv6
> allocation and assignment requests".
>
> The document describes a set of guidelines which are intended to assist
> with the understanding of the current IPv6 policy framework as well as the
> evaluation of requests for allocations and assignments of IPv6 address
> space. It is intended to be of use primarily to requestors in the Asia
> Pacific region, but of course anyone is welcome to use it.
>
> Many thanks are due to the IPv6 guidelines working group who contributed
> the text for this document.
>
> The deadline for comments is Tuesday 1st June 2004.
>
> Your feedback is appreciated and very welcome.
>
> Kind regards,
>
> Anne
> APNIC
> --------------------------------------------------------------------
> APNIC Document identity
>
> Title: APNIC guidelines for IPv6 allocation and assignment
> requests
>
> Short title: ipv6-guidelines
> Document ref: draft-ipv6-guidelines
> Version: 001
> Date of original publication: 4 May 2004
> Date of this version: 4 May 2004
> Review scheduled: n/a
> Obsoletes: Previous versions
> Status: Draft
> Comments: n/a
> ---------------------------------------------------------------------
>
>
>
> APNIC guidelines for IPv6 allocation and assignment requests
>
>
>
> About this document
> -------------------
> These guidelines are intended to complement the document "IPv6 address
> allocation and assignment policy", available at:
>
> http://www.apnic.net/docs/policy/ipv6-address-policy.html
>
> These guidelines will be updated from time to time, in consultation
> with the Asia Pacific and global Internet communities, to ensure that
> they remain appropriate to the current addressing environment.
>
>
>
> Table of contents
> -----------------
>
> Section 1: Background
>
> 1 Introduction
>
> 2 Scope
>
> 3 Additional guidance
>
> 4 Goals of address space management
>
> 5 Application of guidelines
>
>
> Section 2: General guidelines
>
> 6 Definition of an "end site"
>
> 7 IPv6 allocations
> 7.1 Initial allocation criteria
> 7.1.1 A plan for 200 /48 assignments
> 7.1.2 Existing IPv4 network infrastructure
> 7.1.3 Supporting documentation
>
> 8 Assignments to end sites
> 8.1 Assignment size
> 8.2 Second opinion request
> 8.2.1 Sub-allocations and second opinion request
> 8.2.2 Supporting documentation
>
> 9 Subsequent allocations
> 9.1 Utilisation of sub-allocated address blocks
> 9.2 Utilisation threshold for a /32 allocation
> 9.3 Utilisation threshold for a /31 allocation
>
> 10 Requesting a reverse delegation
> 10.1 Reverse DNS delegations in ip6.int and ip6.arpa
>
> 11 Registration requirements
> 11.1 Updating registration details
> 11.2 Registering contact persons
>
>
>
> Section 1: Background
> _____________________________________________________________________
>
>
>
> 1 Introduction
> --------------------
>
> These guidelines are developed within the APNIC community, and are
> consistent with the goals and policies applicable to IPv6 address space
> management. They are intended to assist organisations requesting IPv6
> address space only.
>
> Nothing in these guidelines should be considered to replace or modify
> any of the specific policies defined in other APNIC documents.
>
>
>
> 2 Scope
> -------------
>
> This document applies to the management of global unicast IPv6 public
> address space in the Asia Pacific region.
>
> This document does not apply to IPv4, multicast, or unique local IPv6
> unicast addresses, or Autonomous System numbers. It should be read in
> conjunction with other APNIC documents, particularly APNIC-089 "IPv6
> address allocation and assignment policy".
>
>
>
> 3 Additional guidance
> ---------------------------
>
> These guidelines are not intended to be exhaustive. Additional guidance
> and examples are available from the help information available for each
> APNIC request form and in FAQs and other information on the APNIC web
> site:
>
> * Resource guides
> http://www.apnic.net/services
>
> * APNIC FAQs
> http://www.apnic.net/info/faq
>
> * RFC 3152 "Delegation of IP6.ARPA"
> http://www.ietf.cnri.reston.va.us/rfc/rfc3152.txt
>
> * RFC 3177 "IAB/IESG Recommendations on IPv6 Address
> Allocations to Sites"
> http://www.ietf.cnri.reston.va.us/rfc/rfc3177.txt
>
>
>
> 4 Goals of address space management
> -----------------------------------------
>
> In this document, all reference to the goals of address space
> management refer to the goals described in "IPv6 address allocation and
> assignment policy", namely:
>
> * uniqueness;
> * registration;
> * aggregation;
> * conservation;
> * fairness; and
> * minimised overhead.
>
>
>
> 5 Application of guidelines
> ---------------------------------
>
> This document is primarily intended to guide ISPs when making
> assignments to their customers or requesting address space from APNIC.
> The issues discussed in this document reflect many of the
> considerations used by APNIC in evaluating requests for initial
> allocations and subsequent allocations.
>
> It is intended that NIRs will either adopt these or similar guidelines
> for their own members.
>
>
>
>
> Section 2: General guidelines
> _____________________________________________________________________
>
>
>
> 6 Definition of an "end site"
> -----------------------------------
>
> Section 2.9 of "IPv6 address allocation and assignment policy" defines
> an end site as "an end user (subscriber) who has a business
> relationship with a service provider". That section also lists some
> possible business relationships (which would normally be found in the
> contract between the LIR and their customer) that typically indicate
> end sites. End sites do not re-assign any of their IP addresses to
> other organisations.
>
> Examples:
>
> Single end site
>
> * A home or corporate user who has a single contract with a
> service provider for their own device or network.
> * A home or corporate user who has multiple devices to connect
> the Internet, but has only one contract with a service
> provider.
>
> Multiple sites
>
> * A home or corporate user who has multiple contracts with one
> or more service providers.
> * A home or corporate user who has multiple separate networks
> that are not connected each other because each network has
> different management policy, even if they are in the same
> place (for example, a merged company with independent
> networks).
>
>
>
> 7 IPv6 allocations
> ------------------------
>
> APNIC will allocate IPv6 address space to a network with global or
> local connectivity provided the network meets the criteria stated in
> "IPv6 address allocation and assignment policy".
>
> The following networks are examples of the types of organisations that
> most commonly apply for an IPv6 allocation from APNIC. This list is not
> intended to be exhaustive:
>
> * An ISP providing IPv6 connectivity to the global Internet.
> * An ISP providing IPv6 services to end sites and restricting
> connectivity to its own closed network.
> * An ISP providing IPv6 services to end sites and restricting
> connectivity to peering partners.
> * A large organisation providing IPv6 connectivity to its group
> companies or subsidiaries and restricting connectivity to its
> own network.
>
>
> 7.1 Initial allocation criteria
>
> To qualify for an initial allocation of IPv6 address space, an
> organisation must meet the criteria stated in section 5.1.1 of
> "IPv6 address allocation and assignment policy".
>
>
> 7.1.1 A plan for 200 /48 assignments
>
> An organisation must provide a plan to make at least 200 /48
> assignments within two years. However, APNIC regards the
> existence of the plan as a demonstration of the LIR's readiness
> to commence IPv6 services and does not assess the feasibility
> of the plan. For example, an LIR with at least 200 customers
> currently using IPv4 address space can meet the initial
> allocation criteria of 200 /48assignments if it plans to
> provide them with IPv6 connectivity service within two years.
>
> IPv4 sub-allocations made by an LIR to downstream ISPs can be
> used to justify the corresponding amount of /48 assignments.
>
> Below is an example of a plan that that includes a
> sub-allocation to a downstream ISP that meets the initial
> allocation criteria of a plan to assign 200 /48s within two
> years:
>
> /44 sub-allocation to ISP: 16 /48s
> Assignments to PoPs: 20 /48s
> Assignments to end sites: 170 /48s
> ----------------------------------------
> Total number of /48s: 206 /48s
>
> For example, if a CATV provider has 4,000 IP static connection
> customers in IPv4 and 5% of the customers (200 customers) are
> expected to subscribe to IPv6 services, then this provider will
> meet the initial allocation criteria of 200 /48 assignments. (A
> /48 can be assigned to end sites using either static or dynamic
> addressing).
>
> If an LIR assigns a single static IP address in IPv4, the ISP
> can assign up to a /48 in IPv6. The LIR may also assign a
> smaller prefix in accordance with recommendations in RFC 3177.
>
>
> 7.1.2 Existing IPv4 network infrastructure
>
> LIRs can use existing IPv4 customers and IPv4 network
> infrastructure to justify an initial allocation of /32 by
> providing documentation on the number of their existing IPv4
> users as well as the extent of their IPv4 network
> infrastructure.
>
> The HD ratio is used to determine the appropriate size of the
> IPv6 allocation based on IPv4 customer and infrastructure
> assignments. For more information, refer to:
>
> IPv6 allocations to IPv4 networks
> http://www.apnic.net/docs/policy/proposals/prop-016-v001.html
>
> LIRs are likely to be eligible for an initial allocation if
> they meet both of the following conditions:
>
> * They have received an IPv4 allocation as an LIR or meet the
> criteria to receive an IPv4 allocation; and
> * They plan to transfer the existing IPv4 infrastructure or
> customers partly or wholly to IPv6 in two years.
>
> LIRs are still requested to provide the information on their
> plan on how many /48s are to be assigned within two years to
> ensure that they meet the criteria for 200 /48 assignments, or
> to decide the address block size allocated when they request
> more than a /32.
>
> Below is a brief table based on the HD ratio table that states
> the number of IPv4 customers needed to justify an allocation
> size greater than /32. For the full HD ratio table, please see
> Appendix A of the "IPv6 address allocation and assignment
> policy".
>
>
> Prefix No. of customers needed to
> justify the prefix length
> ------ --------------------------
> 32 7,132
> 31 12,417
> 30 21,619
> 29 37,641
> 24 602,249
>
>
> Note: these guidelines do not guarantee the initial allocation
> will be made.
>
>
> 7.1.3 Supporting documentation
>
> The APNIC IPv6 Allocation Request Form gives LIRs the
> opportunity to include additional documentation to support the
> request for an initial IPv6 allocation. Examples of the types
> of information an LIR can include in the "Additional
> information" section of the form to support the request are:
>
> * network diagrams;
> * approximate deployment dates;
> * service plans (web hosting, access service, etc.);
> * network equipment information to demonstrate that the LIR has
> a plan to implement IPv6-ready infrastructure; and
> * IPv4 infrastructure and/or customer information if the LIR
> chooses the option of using existing IPv4 infrastructure to
> justify the request (see Section 7.1.2).
>
> When requesting an initial allocation from APNIC, network
> equipment information, such as the vendor and model name of an
> LIR's equipment, is not mandatory; however, if an LIR requests
> a large pool of address space for CATV or ADSL operations,
> APNIC may ask for information on the network's equipment.
>
> For more information, see:
>
> APNIC IPv6 Allocation Request Form
> http://ftp.apnic.net/apnic/docs/ipv6-alloc-request
>
>
>
> 8 Assignments to end sites
> --------------------------------
>
>
> 8.1 Assignment size
>
> RFC 3177 and the "IPv6 address allocation and assignment
> policy" state that a single end site should usually be assigned
> a /48.
>
> Residential subscribers can receive a /48 when connecting
> through on-demand or?always-on connections such as ADSL or
> CATV.
>
> If an end site is expected to grow, an LIR may assign a /48 to
> an end site where a /64 or /128 may initially seem more
> appropriate (for example, an end site with a single computer).
>
> An LIR must submit a second opinion request to APNIC if it
> plans to assign more than a /48 to a single end site (see
> Section 8.2 below).
>
>
> 8.2 Second opinion request
>
> Currently, the global Internet community considers a /48
> assignment to be sufficient address space for an end site.
>
> Therefore, when an end site requires an assignment larger than
> /48, or it requires additional /48 assignments after the
> initial assignment, the LIR must first submit a second opinion
> request using the following form:
>
> APNIC Second Opinion Request Form
> Web: http://www.apnic.net/services/second-opinion/index.html
> Text: http://ftp.apnic.net/apnic/docs/second-opinion-request
>
>
> 8.2.1 Sub-allocations and second opinion request
>
> LIRs do not need to submit a second opinion request before
> making sub-allocations to downstream ISPs (please see Section 9
> below). However, APNIC encourages LIRs to contact APNIC
> hostmasters for advice if LIRs are unsure how much address
> space to sub-allocate.
>
>
> 8.2.2 Supporting documentation
>
> The APNIC Second Opinion Request Form gives LIRs the
> opportunity to include additional documentation to support the
> request for an assignment to an end site that is larger than a
> /48. Examples of the types of information an LIR can include in
> the Additional information section of the form to support the
> request are:
>
> * Network diagram of an end site
> * Network equipment information
> * Full details to justify multiple /48 assignments to an end
> site (for example, the number of clients (PCs or other
> network equipment) or other information which justify
> multiple /48 assignments)
>
>
>
> 9 Subsequent allocations
> ------------------------------
>
> Currently, when APNIC makes an initial allocation to an LIR, it
> reserves a total of a eight adjacent /32 address blocks, a total of
> /29, for the LIR's consumption. However, this may not always be the
> case as a different allocation system, known as "sparse allocation" is
> currently under discussion. For more information, see prop-005-v001:
>
> "IPv6 address space management"
> http://www.apnic.net/docs/policy/proposals/prop-005-v001.html
>
> AN LIR can apply for a subsequent allocation of IPv6 when it can
> demonstrate that its past IPv6 address utilisation has met or exceeded
> the minimum number of /48 assignments specified by the HD ratio table
> (see Appendix A of the policy document).
>
> Utilisation is calculated based on the number of /48 assignments
> registered in the APNIC Whois Database. This includes /48 assignments
> made from sub-allocations to downstream ISPs.
>
>
> 9.1 Utilisation of sub-allocated address blocks
>
> The size of sub-allocations to downstream ISPs cannot be used
> to justify a subsequent allocation.
>
> An LIR can use assignments made from a sub-allocation to a
> downstream ISP to justify a subsequent allocation request if
> those assignments are registered in the APNIC Whois Database.
>
> If a sub-allocation is made to a downstream ISP, but
> assignments are not registered in the database, it is not
> considered to be utilised.
>
> Below is an example of the total amount of address space
> considered utilised from a sub-allocation of /40 to a
> downstream ISP:
>
>
> /40 sub-allocation to ISP: 256 /48s
> Customer assignments
> made from sub-allocation: 2 /48s
> Downstream ISP PoP 1 /48
> ----------------------------------------------------
> Total address space considered utilised: 3 /48s
>
>
> Therefore, the LIR can only use 3 /48s from the /40
> sub-allocation to help justify its request for a subsequent
> allocation. In the APNIC IPv6 Allocation Request Form, an LIR
> should also note infrastructure (PoPs) and customer assignments
> made by the downstream ISP.
>
> To prevent large proportions of sub-allocations remaining
> unutilised, LIRs should carefully consider and justify the size
> of planned sub-allocations.
>
> Note: LIRs do not need to submit a second opinion request
> before sub-allocating IPv6 address space to downstream ISPs.
>
>
> 9.2 Utilisation threshold for a /32 allocation
>
> A typical LIR will receive as its initial allocation a /32,
> which is the equivalent of 65,536 /48 assignments. According to
> the HD ratio table, an LIR can justify a request for a
> subsequent allocation when it can prove it has assigned the
> equivalent of 7,132 /48 assignment to its customers and its
> PoPs.
>
> Below is an example of a plan that meets the subsequent
> allocation criteria of an LIR that has already received an
> initial allocation of /32:
>
>
> Assignments to PoPs 326 /48s
> Assignments to end sites 6,500 /48s
> Assignments through downstream ISP 306 /48s
> ----------------------------------------------------
> Total number of /48s 7,132 /48s
>
>
> 9.3 Utilisation threshold for a /31 allocation
>
> After an LIR has received an initial /32 allocation and
> justified a request for a subsequent allocation of /32 from an
> adjacent block, the LIR has a total of /31 allocated to it. To
> justify an additional allocation, the LIR must prove that it
> has assigned the equivalent of 12,417 /48s. This includes the
> previous 7,132 /48s used it justify its first subsequent
> allocation.
>
>
>
> 10 Requesting a reverse DNS delegation
> -------------------------------------------
>
> LIRs should maintain reverse DNS delegations for their customers'
> networks. If a network is not specifically associated with an LIR then
> the reverse DNS delegation should be maintained by APNIC. Reverse DNS
> delegations are not compulsory when an end site assigns an address to
> an individual host.
>
> The minimum size of a reverse DNS delegation is /48.
>
>
> 10.1 Reverse DNS delegations in ip6.int and ip6.arpa
>
> As specified in RFC 3152, reverse DNS delegations in the
> ip6.int tree have been deprecated. Accordingly, organisations
> should transfer reverse DNS delegations to the ip6.arpa tree.
> Organisations that need to support legacy systems and therefore
> cannot move out of the ip6.int tree are also requested to
> maintain ip6.arpa delegations.
>
> For more information, see:
>
> Reverse DNS delegations resource guide
> http://www.apnic.net/services/dns_guide.html
>
>
>
> 11 Registration requirements
> ---------------------------------
>
> LIRs are responsible for promptly and accurately registering their
> allocations, sub-allocations, and assignments in the APNIC Whois
> Database, as follows:
>
> * All allocations and sub-allocations must be registered.
> * Assignments for networks greater than /48 must be registered.
> * Assignments for networks of /48 or less may be registered, at
> the discretion of the LIR and the network administrator.
> * Assignments to hosts may be registered, at the discretion of
> the LIR and the end site.
>
> When an LIR makes a sub-allocation to a downstream ISP, the LIR is
> responsible for ensuring that assignments from the sub-allocated range
> are registered in the database; however, the LIR may delegate the
> responsibility to the downstream ISP.
>
> Note: Privacy of customer assignments (prop-007-v001) will be
> implemented in 2004. This new policy no longer requires the
> registration of assignments and sub-allocations to be publicly
> available. The registration of customer assignments is still required,
> but will be 'hidden' by default.
>
>
> 11.1 Updating registration details
>
> LIRs must update the APNIC Whois Database when any of the
> registration information changes. This is the responsibility of
> the LIR concerned, but may be formally delegated to the end
> user as a condition of the original assignment.
>
>
> 11.2 Registering contact persons
>
> Administrative and technical contact persons must be registered
> .
> The registered administrative contact (admin-c) must be someone
> who is physically located at the site of the network, subject
> to the following exceptions:
>
> * For residential networks or users, the network's technical
> contact may be registered as admin-c.
> * For networks in exceptional circumstances that make it
> impractical to maintain an on-site administrative contact, an
> off-site person may be registered as the admin-c.
>
> The technical contact (tech-c) need not be physically located
> at the site of the network, but must be a person who is
> responsible for the day-to-day operation of the network.
>
> * 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
>
>