ipv6-guidelines.txt		ipv6-guidelines-DRAFT-v012.txt
			----------------------------------------------------------------------------------
	APNIC Document identity		APNIC Document identity
	Title: APNIC guidelines for IPv6 allocation and assignment		Title: APNIC guidelines for IPv6 allocation and assignment requests
	requests		Short title: ipv6-guidelines
			Document ref: APNIC-114
	Short title: ipv6-guidelines		Version: 012
	Document ref: APNIC-114		Date of original publication: 2 July 2004
	Version: 011		Date of this version: TBA
	Date of original publication: 2 July 2004		Review scheduled: n/a
	Date of this version: 20 July 2023		Obsoletes: apnic-114-011
	Review scheduled: n/a		Status: Draft
	Obsoletes: apnic-114-010		Comments: Implements prop-155
	Status: Active		------------------------------------------------------------------------------------
	Comments: Implements prop-145
	About this document		About this document
	These guidelines are intended to complement the document IPv6 address		These guidelines are intended to complement the APNIC Internet Number Resource Policies (apnic-127).
	allocation and assignment policy.
	http://www.apnic.net/policy/ipv6-address-policy		https://www.apnic.net/community/policy/resources
	These guidelines will be updated from time to time, in consultation with		These guidelines will be updated from time to time, in consultation with the Asia Pacific and global Internet communities, to ensure they remain appropriate to the current addressing environment.
	the Asia Pacific and global Internet communities, to ensure they remain
	appropriate to the current addressing environment.
	Table of contents		Table of contents
	Section 1: Background		Section 1: Background
	1. Introduction		1. Introduction
	2. Scope		2. Scope
	3. Additional guidance		3. Additional guidance
	4. Goals of address space management		4. Goals of address space management
	5. Application of guidelines		5. Application of guidelines
	Section 2: General guidelines		Section 2: General guidelines
	6. Definitions		6. Definitions
	7. Sparse Delegation Framework		7. Sparse Delegation Framework
	7.1. Avoiding Fragmentation		7.1. Avoiding Fragmentation
	8. Allocations to LIRs		8. Allocations to LIRs
	8.1. Initial allocation criteria		8.1. Initial allocation criteria
	8.1.1. A plan for 200 assignments		8.1.1. A plan for 200 assignments
	8.1.2. Existing LIRs with IPv4 allocations from APNIC or an		8.1.2. Existing LIRs with IPv4 allocations from APNIC or an
	NIR		NIR
	8.1.3. Initial allocation larger than /32		8.1.3. Initial allocation larger than /32
	8.1.4. Expanding allocations received before August		8.1.4. Expanding allocations received before August
	2004		2004
	8.1.5. Supporting documentation		8.1.5. Supporting documentation
	8.2. Subsequent allocation criteria		8.2. Subsequent allocation criteria
	skipping to change at line 64 ¶		skipping to change at line 49 ¶
	8.1.1. A plan for 200 assignments		8.1.1. A plan for 200 assignments
	8.1.2. Existing LIRs with IPv4 allocations from APNIC or an		8.1.2. Existing LIRs with IPv4 allocations from APNIC or an
	NIR		NIR
	8.1.3. Initial allocation larger than /32		8.1.3. Initial allocation larger than /32
	8.1.4. Expanding allocations received before August		8.1.4. Expanding allocations received before August
	2004		2004
	8.1.5. Supporting documentation		8.1.5. Supporting documentation
	8.2. Subsequent allocation criteria		8.2. Subsequent allocation criteria
	8.2.1. Prior allocations to be used first		8.2.1. Prior allocations to be used first
	8.2.2. Special circumstances		8.2.2. Special circumstances
	9. Portable assignment criteria		9. Portable assignment criteria
	9.1. Initial assignments		9.1. Initial assignments
	9.1.1. Multihoming assignment		9.1.1. Multihoming assignment
	9.1.2. Internet Exchange assignment		9.1.2. Internet Exchange assignment
	9.1.3. Critical Infrastructure assignment		9.1.3. Critical Infrastructure assignment
	9.1.4. Provider Independent assignment		9.1.4. Provider Independent assignment
	9.2. Subsequent assignments		9.2. Subsequent assignments
	10. Delegations by LIRs		10. Delegations by LIRs
	10.1. LIR assignments to end sites		10.1. LIR assignments to end sites
	10.1.1. Second opinion request		10.1.1. Supporting documentation
	10.1.2. Supporting documentation
	10.2. Sub-allocations by LIRs		10.2. Sub-allocations by LIRs
	11. Reverse DNS delegation		11. Reverse DNS delegation
	11.1. Reverse DNS delegations in ip6.int and ip6.arpa		11.1. Reverse DNS delegations in ip6.int and ip6.arpa
	12. Registration requirements		12. Registration requirements
	12.1. Updating registration details		12.1. Updating registration details
	12.2. Registering contact persons		12.2. Registering contact persons
	Section 1: Background		Section 1: Background
	1. Introduction		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 organizations requesting IPv6 address space only.
	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 organizations requesting IPv6
	address space only.
	Nothing in these guidelines should be considered to replace or modify		Nothing in these guidelines should be considered to replace or modify any of the specific policies defined in other APNIC documents.
	any of the specific policies defined in other APNIC documents.
	2. Scope		2. Scope
			This document applies to the management of global unicast IPv6 public address space in the Asia Pacific region.
	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		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 Internet Number Resource Policies (apnic-127).
	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.
	http://www.apnic.net/policy/ipv6-address-policy		https://www.apnic.net/community/policy/resources
	3. Additional guidance		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 website:
	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		- Resource guides
	http://www.apnic.net/publications/media-library/documents		http://www.apnic.net/publications/media-library/documents
	- APNIC FAQs		- APNIC FAQs
	http://www.apnic.net/faq		http://www.apnic.net/faq
	- RFC 3596 DNS Extensions to Support IP Version 6		- RFC 3596 DNS Extensions to Support IP Version 6
	http://www.apnic.net/external-pages/rfcs/ietf-rfc-3596		http://www.apnic.net/external-pages/rfcs/ietf-rfc-3596
	- RFC 6177 IPv6 Address Assignment to End Sites		- RFC 6177 IPv6 Address Assignment to End Sites
	http://www.apnic.net/external-pages/rfcs/ietf-rfc-6177		http://www.apnic.net/external-pages/rfcs/ietf-rfc-6177
	4. Goals of address space management		4. Goals of address space management
			In this document, all reference to the goals of address space management refer to the goals described in the IPv6 address allocation and assignment policy, namely:
	In this document, all reference to the goals of address space management
	refer to the goals described in the IPv6 address allocation and
	assignment policy, namely:
	- uniqueness;		- uniqueness;
	- registration;		- registration;
	- aggregation;		- aggregation;
	- conservation;		- conservation;
	- fairness; and		- fairness; and
	- minimized overhead.		- minimized overhead.
	5. Application of guidelines		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.
	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		It is intended that NIRs will either adopt these, or similar, guidelines for their own members.
	for their own members.
	Section 2: General guidelines		Section 2: General guidelines
	6. Definitions		6. Definitions
			Terms not defined in this document have the meaning given to them in the APNIC Definition Document and Policy Document.
	Terms not defined in this document have the meaning given to them in the APNIC
	Definition Document and Policy Document.
	https://www.apnic.net/about-apnic/corporate-documents/documents/corporate/definitions/		https://www.apnic.net/about-apnic/corporate-documents/documents/corporate/definitions/
	https://www.apnic.net/community/policy/resources		https://www.apnic.net/community/policy/resources
	7. Sparse Delegation Framework		7. Sparse Delegation Framework
			APNIC delegates blocks of IPv6 address space to resource holders according to a "sparse delegation" algorithm. This delegation process is designed to maximize the growth potential for each delegation by maximizing the distance between them.
	APNIC delegates blocks of IPv6 address space to resource holders
	according to a "sparse delegation" algorithm. This delegation
	process is designed to maximize the growth potential for each
	delegation by maximizing the distance between them.
	The following illustration shows the order in which a sequence of		The following illustration shows the order in which a sequence of 16 delegations would be made in an available free pool using APNIC's sparse delegation algorithm.
	16 delegations would be made in an available free pool using
	APNIC's sparse delegation algorithm.
	Sparse Delegation Sequence		Sparse Delegation Sequence
	|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|		|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
	1 | | | | | | | 2 | | | | | | |		1 | | | | | | | 2 | | | | | | |
	| | | 3 | | | | | | 4 | | |		| | | 3 | | | | | | 4 | | |
	| 5 | | 6 | | 7 | | 8 |		| 5 | | 6 | | 7 | | 8 |
	9 10 11 12 13 14 15 16		9 10 11 12 13 14 15 16
	The sparse delegation algorithm used, selects the starting address		The sparse delegation algorithm used, selects the starting address for each new delegation by calculating the mid-point between the next two start addresses that are furthest apart in the free pool.
	for each new delegation by calculating the mid-point between the		The algorithm works from the beginning address of the free pool to the end address before returning to the first available slot at the beginning of the pool.
	next two start addresses that are furthest apart in the free pool.
	The algorithm works from the beginning address of the free pool to
	the end address before returning to the first available slot at the
	beginning of the pool.
	The effect is to successively sub-divide each remaining free block
	in two, the addresses after that point being used for the new
	delegation and the preceding addresses being left available for
	subsequent delegation.
	In accordance with APNIC's IPv6 address allocation and assignment		The effect is to successively sub-divide each remaining free block in two, the addresses after that point being used for the new delegation and the preceding addresses being left available for subsequent delegation.
	policy, where possible, subsequent delegations to the same resource
	holder are made from an adjacent address block by growing the
	delegation into the free space remaining, unless disaggregated
	ranges are requested for multiple discrete networks.
	7.1. Avoiding Fragmentation		In accordance with APNIC's IPv6 address allocation and assignment policy, where possible, subsequent delegations to the same resource holder are made from an adjacent address block by growing the
			delegation into the free space remaining, unless disaggregated ranges are requested for multiple discrete networks.
	While the free space between sparse delegations is initially		7.1. Avoiding Fragmentation
	very large, the size of available blocks reduces as more		While the free space between sparse delegations is initially very large, the size of available blocks reduces as more sub-divisions occur. To minimize this effect, APNIC manages its central pool by making similar sized delegations from a number of sub-pools, with large delegations made from one pool, small delegations made from another, and so on.
	sub-divisions occur. To minimize this effect, APNIC manages
	its central pool by making similar sized delegations from a
	number of sub-pools, with large delegations made from one
	pool, small delegations made from another, and so on.
	In this way, the high frequency of smaller delegations will		In this way, the high frequency of smaller delegations will not cause sub-divisions of free space available to large address block holders, as they are taken from different sub-pools.
	not cause sub-divisions of free space available to large
	address block holders, as they are taken from different
	sub-pools.
	For more information about the resource ranges managed by		For more information about the resource ranges managed by APNIC see:
	APNIC see:
	http://www.apnic.net/resources		http://www.apnic.net/resources
	8. Allocations to LIRs		8. Allocations to LIRs
			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".
	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 organizations that		The following networks are examples of the types of organizations that most commonly apply for an IPv6 allocation from APNIC.
	most commonly apply for an IPv6 allocation from APNIC.
	This list is not intended to be exhaustive:		This list is not intended to be exhaustive:
	- An organization providing IPv6 connectivity to the global		- An organization providing IPv6 connectivity to the global
	Internet.		Internet.
	- An organization providing IPv6 connectivity to end sites.		- An organization providing IPv6 connectivity to end sites.
	- An organization providing IPv6 access to shared facilities,		- An organization providing IPv6 access to shared facilities,
	storage, computing, or other services.		storage, computing, or other services.
	- A large organization providing IPv6 connectivity to its own group		- A large organization providing IPv6 connectivity to its own group
	or subsidiaries.		or subsidiaries.
	8.1. Initial allocation criteria		8.1. Initial allocation criteria
	To qualify for an initial allocation of IPv6 address space, an
	organization must meet the criteria stated in section 5.2.1 of
	"IPv6 address allocation and assignment policy". Under d) in
	section 5.2.1, an organization can choose from one of the two
	alternative criteria:
	1. Have a plan for making at least 200 assignments to other
	organizations within two years, OR
	2. Be an existing LIR with IPv4 allocations from APNIC, or
	from an NIR, which will make IPv6 assignments or
	sub-allocations to other organizations and announce the
	allocations in the inter-domain routing system within two
	years
	These two alternative criteria are explained in sections
	8.1.1. and 8.1.2. below.
	8.1.1. A plan for 200 assignments
	An organization must provide a plan to make at least
	200 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 assignments 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 /56
	assignments.
	For example:
	If a CATV provider has 4,000 IP static connection		To qualify for an initial allocation of IPv6 address space, an organization must meet the criteria stated in Part 3: IPv6 Policy of "APNIC Internet Number Resource Policies".
	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 assignments. (A /56 can be assigned to
	end sites using either static or dynamic addressing).
	If an LIR assigns a single static IP address in IPv4,		An organization can choose from one of the two alternative criteria:
	the ISP can assign up to a /48 in IPv6. The LIR may
	also assign a smaller prefix in accordance with
	recommendations in RFC 6177.
	8.1.2. LIRs with existing IPv4 allocations from APNIC or an		1. Have a plan for making at least 200 assignments to other organizations within two years, OR
	NIR		2. Be an existing LIR with IPv4 allocations from APNIC, or from an NIR, which will make IPv6 assignments or sub-allocations to other organizations and announce the allocations in the inter-domain routing system within two years
	To qualify under this criterion, an organization must:		These two alternative criteria are explained in sections 8.1.1. and 8.1.2. below.
	- Document an existing IPv4 allocation made to it by		8.1.1. A plan for 200 assignments
	APNIC, or an NIR
	- Commit to making IPv6 assignments and/or
	sub-allocations
	- Agree to announce the IPv6 allocation in the routing
	table within two years
	Note: Historical IP ranges do not meet the criteria of		An organization must provide a plan to make at least 200 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 assignment if it plans to provide them with IPv6 connectivity service within two years.
	being "an existing IPv4 allocation from APNIC, or an
	NIR". Historical IP ranges are defined in Section 2.2
	of: Policies for historical Internet resources in the
	APNIC Whois Database.
	http://www.apnic.net/policy/historical-resource-policies		IPv4 sub-allocations made by an LIR to downstream ISPs can be used to justify the corresponding amount of /56 assignments. 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 assignments. (A /56 can be assigned to end sites using either static or dynamic addressing).
	8.1.3. Initial allocations larger than /32		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 6177.
	LIRs can use existing IPv4 customers and IPv4 network		8.1.2. LIRs with existing IPv4 allocations from APNIC or an NIR
	infrastructure to justify an initial allocation larger
	than a /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		To qualify under this criterion, an organization must:
	of the IPv6 allocation based on IPv4 customer and		- Document an existing IPv4 allocation made to it by APNIC, or an NIR
	infrastructure assignments. For more information,		- Commit to making IPv6 assignments and/or sub-allocations
	refer to section 5.2.3 of the "IPv6 address allocation		- Agree to announce the IPv6 allocation in the routing table within two years
	and assignment policy".
	http://www.apnic.net/policy/ipv6-address-policy		Note: Historical IP ranges do not meet the criteria of being "an existing IPv4 allocation from APNIC, or an NIR". Historical IP ranges are defined at:
	LIRs are likely to be eligible for an initial		https://help.apnic.net/s/article/Historical-resources
	allocation if they meet both of the following
	conditions:
	- They have received an IPv4 allocation as an LIR, or		8.1.3. Initial allocations larger than /32
	meet the criteria to receive an IPv4 allocation; and		LIRs can use existing IPv4 customers and IPv4 network infrastructure to justify an initial allocation larger than a /32 by providing documentation on the number of their existing IPv4 users as well as the extent of their IPv4 network infrastructure.
	- They plan to transfer the existing IPv4		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
	infrastructure or customers partly, or wholly, to		https://www.apnic.net/community/policy/resources#a_h_8_3_2
	IPv6 in two years.
	LIRs are still requested to provide information on how		LIRs are likely to be eligible for an initial allocation if they meet both of the following conditions:
	many /56s they expect to assign within the first two
	years.
	8.1.4. Expanding allocations received before August 2004		- 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.
	Organizations that received an initial allocation of		LIRs are still requested to provide information on how many /56s they expect to assign within the first two years.
	IPv6 can take advantage of the August 2004 policy
	permitting initial allocations larger than /32.
	To expand the initial allocation size without needing		8.1.4. Expanding allocations received before August 2004 Organizations that received an initial allocation of IPv6 can take advantage of the August 2004 policy permitting initial allocations larger than /32.
	to meet subsequent allocation criteria, the LIR must		To expand the initial allocation size without needing to meet subsequent allocation criteria, the LIR must have received its initial allocation before 16 August 2004 and must meet the initial allocation criteria described "APNIC Internet Number Resource Policies".
	have received its initial allocation before 16 August
	2004 and must meet the initial allocation criteria
	described in Section 5. of the "IPv6 address
	allocation and assignment policy".
	http://www.apnic.net/policy/ipv6-address-policy		https://www.apnic.net/community/policy/resources
	For more information, see: prop-021: Expansion of the		For more information, see: prop-021: Expansion of the initial allocation space for existing IPv6 address space holders.
	initial allocation space for existing IPv6 address
	space holders.
	http://www.apnic.net/policy/proposals/prop-021		http://www.apnic.net/policy/proposals/prop-021
	8.1.5. Supporting documentation		8.1.5. 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
	- a brief description of IPv6 deployment method (use
	of IPv6 tunneling, dual stack, etc.)
	- 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
	8.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.
	8.2. Subsequent allocation criteria
	8.2.1. Prior allocations to be used first
	An LIR is not eligible to receive subsequent
	allocations until its current assignments reach a HD
	ratio of 0.94 based on /56 assignments.
	8.2.2. Special circumstances
	An LIR may request an exception to the HD 0.94 rule
	when:
	- It has a demonstrated need for an assignment that is		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:
	larger than the amount of remaining space,		- network diagrams
			- approximate deployment dates
			- a brief description of IPv6 deployment method (use of IPv6 tunneling, dual stack, etc.)
			- 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 8.1.2.).
	- It is announcing its existing IPv6 allocation and		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.
	can demonstrate a need or requirement to build
	discrete networks,
	- It requires the additional allocation for technical		8.2. Subsequent allocation criteria
	reasons such as for IPv4 to IPv6 transitional		8.2.1. Prior allocations to be used first
	technologies, or		An LIR is not eligible to receive subsequent allocations until its current assignments reach a HD ratio of 0.94 based on /56 assignments.
	- It can demonstrate other reasons accepted by APNIC		8.2.2. Special circumstances
	as valid circumstance, or in accord with applicable		An LIR may request an exception to the HD 0.94 rule when:
	policies.		- It has a demonstrated need for an assignment that is larger than the amount of remaining space,
			- It is announcing its existing IPv6 allocation and can demonstrate a need or requirement to build discrete networks,
			- It requires the additional allocation for technical reasons such as for IPv4 to IPv6 transitional technologies, or
			- It can demonstrate other reasons accepted by APNIC as valid circumstance, or in accord with applicable policies.
	9. Portable assignment criteria		9. Portable assignment criteria
			Organizations with a previously delegated IPv4 assignment from APNIC are eligible for an appropriately sized IPv6 block under Section 5.1 of the IPv6 address allocation and assignment policy.
	Organizations with a previously delegated IPv4 assignment from APNIC are		Organizations are also able to demonstrate a need for direct assignment of IPv6 address blocks under the following conditions.
	eligible for an appropriately sized IPv6 block under Section 5.1 of the
	IPv6 address allocation and assignment policy.
	Organizations are also able to demonstrate a need for direct assignment
	of IPv6 address blocks under the following conditions.
	- Multihoming assignment		- Multihoming assignment
	- Internet Exchange assignment		- Internet Exchange assignment
	- Critical Infrastructure assignment		- Critical Infrastructure assignment
	- Provider Independent assignment		- Provider Independent assignment
	9.1. Initial assignments		9.1. Initial assignments
			APNIC will allocate a minimum of a /48 to organizations that meet the following criteria.
	APNIC will allocate a minimum of a /48 to organizations that
	meet the following criteria.
	9.1.1. Multihoming assignment
	1. To be eligible for an IPv6 assignment under this
	policy, an organization needs to be, or plan to be,
	receiving fulltime connectivity from more than one
	ISP, and
	2. have one or more of its routing prefixes announced
	by at least two ISPs.
	9.1.2. Internet Exchange assignment
	1. An Internet Exchange Point (IX or IXP) is a layer 1
	and layer 2-network structure that interconnects
	three or more Autonomous Systems (AS) for the
	purpose of Internet traffic interchange.
	2. Addresses delegated under this policy must be used
	exclusively to connect participant devices to the
	Exchange Point.
	9.1.3. Critical Infrastructure assignment
	1. Critical infrastructure assignments are available
	only to the actual operators of network
	infrastructure that perform the functions
	described in the policy.
	2. Examples of Critical Infrastructure networks are
	listed at 5.9.3 of the IPv6 address allocation and
	assignment policy.
	3. The maximum assignment made under these terms is
	/32 per operator.
	9.1.4. Provider Independent assignment
	Direct assignment of IPv6 addresses is possible where
	an organization can demonstrate other reasons accepted
	by APNIC as valid circumstance, or in accord with
	applicable policies.
	For example, organizations that can demonstrate;
	1. the network is statically addressed and of a size
	or complexity that make renumbering operationally
	impractical, together with evidence that dynamic or
	multiple addressing options are either not
	available from the relevant ISP or are unsuitable;
	or
	2. that any future renumbering of the relevant network
	could potentially interfere with services of a
	critical medical or civic nature, or
	3. other reasons accepted by APNIC as valid		9.1.1. Multihoming assignment
	circumstance, or in accord with applicable		1. To be eligible for an IPv6 assignment under this policy, an organization needs to be, or plan to be, receiving fulltime connectivity from more than one ISP, and
	policies.		2. have one or more of its routing prefixes announced by at least two ISPs.
	Note: A larger address block may be assigned according		9.1.2. Internet Exchange assignment
	to demonstrated need. Only one IPv6 address block is		1. An Internet Exchange Point (IX or IXP) is a layer 1 and layer 2-network structure that interconnects three or more Autonomous Systems (AS) for the purpose of Internet traffic interchange.
	to be assigned to an organization upon an initial		2. Addresses delegated under this policy must be used exclusively to connect participant devices to the Exchange Point.
	request; subnets of this block may be assigned by the
	organization to its different sites if needed.
	9.2. Subsequent assignments		9.1.3. Critical Infrastructure assignment
			1. Critical infrastructure assignments are available only to the actual operators of network infrastructure that perform the functions described in the policy.
			2. Examples of Critical Infrastructure networks are listed at 5.9.3 of the IPv6 address allocation and assignment policy.
			3. The maximum assignment made under these terms is /32 per operator.
	Eligibility for subsequent Provider Independent assignments		9.1.4. Provider Independent assignment
	under Section 5.9.4 of the IPv6 address allocation and		Eligibility:
	assignment policy is subject to the following conditions:		Organizations or individuals with no previously delegated IPv4 assignment from APNIC or any other Regional Internet Registry (RIR) are eligible to apply for a /48 IPv6 PI assignment.
			Eligible organizations or individuals must meet the requirements specified in the APNIC policies for IPv6 PI assignments, including justification for the requested address space as specified in Section 9.1.4 of "APNIC Internet Number Resource Policies".
	- An address block larger than /48 may be assigned if;		Agreement to Announce IPv6 Address Space:
			Organizations or individuals receiving a /48 IPv6 PI assignment must agree to use and announce the IPv6 address space within twelve (12) months from the assignment date.
	1. the network address plan demonstrates that the need is		Monitoring and Reclamation:
	above a /48 0.94 HD-ratio, or		APNIC may monitor the assigned PI IPv6 address space to ensure its utilization.
	2. the network plan is for multiple discrete networks. That		If, after the twelve (12) month period, the IPv6 PI address space is not announced or APNIC determine that it is not in use for the intended purpose, the assigned IPv6 PI address space shall be subject to reclamation.
	is, the organization can demonstrate a need or
	requirement to build discrete networks, and
	3. the organization can demonstrate the use of the previous		Reclaimed IPv6 PI address space will be returned to the free pool for reassignment.
	assignment generated the minimum possible number of
	global routing announcements and the maximum aggregation
	of that block, and
	4. how the subsequent assignment would be managed to		9.2. Subsequent assignments
	minimize the growth of the global IPv6 routing table.		Eligibility for subsequent Provider Independent assignments under Section 5.9.4 of the IPv6 address allocation and assignment policy is subject to the following conditions:
			- An address block larger than /48 may be assigned if;
			1. the network address plan demonstrates that the need is above a /48 0.94 HD-ratio, or
			2. the network plan is for multiple discrete networks. That is, the organization can demonstrate a need or requirement to build discrete networks, and
			3. the organization can demonstrate the use of the previous assignment generated the minimum possible number of global routing announcements and the maximum aggregation of that block, and
			4. how the subsequent assignment would be managed to minimize the growth of the global IPv6 routing table.
	10. Delegations by LIRs		10. Delegations by LIRs
	10.1. LIR assignments to end sites
	An LIR can assign a /64 to /48 to an end site customer
	network based on their requirements.
	The following guidelines may be useful:
			10.1. LIR assignments to end sites
			An LIR can assign a /64 to /48 to an end site customer network based on their requirements.
			The following guidelines may be useful:
	- /64 where it is known that only one subnet is required.		- /64 where it is known that only one subnet is required.
			- /56 for small sites where it is expected only a few subnets will be required within the next two years. Subscribers can receive a /56 when connecting through on-demand or always-on connections such as small office and home office enterprises.
			- /48 for larger sites, or if an end site is expected to grow into a large network.
	- /56 for small sites where it is expected only a few subnets		10.1.1. Supporting documentation
	will be required within the next two years. Subscribers can		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.
	receive a /56 when connecting through on-demand or		Examples of the types of information an LIR can include in the Additional information section of the form to support the request are:
	always-on connections such as small office and home office		- Network diagram of an end site
	enterprises.		- 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)
	- /48 for larger sites, or if an end site is expected to grow
	into a large network.
	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 10.1.2 below).
	http://www.apnic.net/second-opinion
	10.1.1. 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.
	http://www.apnic.net/second-opinion
	10.1.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)
	10.2. Sub-allocations by LIRs
	LIRs do not need to submit a second opinion request before		10.2. Sub-allocations by LIRs
	making sub-allocations to downstream ISPs (please see Section		LIRs do not need to submit a second opinion request before making sub-allocations to downstream ISPs (please see Section 8.2 above). However, APNIC encourages LIRs to contact APNIC hostmasters for advice if LIRs are unsure how much address space to sub-allocate.
	8.2 above). However, APNIC encourages LIRs to contact APNIC
	hostmasters for advice if LIRs are unsure how much address
	space to sub-allocate.
	11. Reverse DNS delegation		11. 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. In both IPv4 and IPv6 networks, it is the LIR's responsibility to delegate or to maintain PTR records for its customers' networks.
	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. In both IPv4
	and IPv6 networks, it is the LIR's responsibility to delegate or to
	maintain PTR records for its customers' networks.
	The size of a reverse DNS delegation by an LIR to an end site will
	usually be a /48, which is the recommended minimum assignment to an end
	site specified in RFC 6177. However, it is possible to delegate a prefix
	longer than /48. Some organizations may delegate such a prefix in their
	internal network.
	11.1. Reverse DNS delegations in ip6.int and ip6.arpa
	As specified in RFC 3596, reverse DNS delegations in the		The size of a reverse DNS delegation by an LIR to an end site will usually be a /48, which is the recommended minimum assignment to an end site specified in RFC 6177. However, it is possible to delegate a prefix longer than /48. Some organizations may delegate such a prefix in their internal network.
	ip6.int tree have been deprecated, and APNIC has now removed
	all ip6.int reverse delegations from the APNIC Whois
	Database.
	For more information, see: Reverse DNS delegations resource		11.1. Reverse DNS delegations in ip6.int and ip6.arpa
	guide		As specified in RFC 3596, reverse DNS delegations in the ip6.int tree have been deprecated, and APNIC has now removed all ip6.int reverse delegations from the APNIC Whois Database.
			For more information, see: Reverse DNS delegations resource guide
	http://www.apnic.net/dns		http://www.apnic.net/dns
	12. Registration requirements		12. Registration requirements
			LIRs are responsible for promptly and accurately registering their allocations, sub-allocations, and assignments in the APNIC Whois Database, as follows:
	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.		- All allocations and sub-allocations must be registered.
	- Assignments for networks equal to or larger than /48 must be		- Assignments for networks equal to or larger than /48 must be registered.
	registered.		- Registration of assignments smaller than /48 is optional and may be registered at the discretion of the LIR and the network administrator.
	- Registration of assignments smaller than /48 is optional and may
	be registered at the discretion of the LIR and the network
	administrator.
	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.
	If an LIR registers an assignment smaller than a /48, it will be counted
	as a utilized /48 when assessing existing address utilization for future
	IPv6 allocation requests.
	Note: Privacy of customer assignments (prop-007-v001) was implemented in
	2004. APNIC 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.
	12.1. Updating registration details
	LIRs must update the APNIC Whois Database when any of the		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.
	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.
	12.2. Registering contact persons		If an LIR registers an assignment smaller than a /48, it will be counted as a utilized /48 when assessing existing address utilization for future IPv6 allocation requests.
	Administrative and technical contact persons must be		Note: Privacy of customer assignments (prop-007-v001) was implemented in 2004. APNIC 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.
	registered. In addition, it is mandatory to register an
	Incident Report Team (IRT) object for each allocation and
	assignment record in the APNIC Whois Database.
	The registered administrative contact (admin-c) must be		12.1. Updating registration details
	someone who is physically located at the site of the network,		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.
	subject to the following exceptions:
	- For residential networks or users, the network's technical		12.2. Registering contact persons
	contact may be registered as admin-c.		Administrative and technical contact persons must be registered. In addition, it is mandatory to register an Incident Report Team (IRT) object for each allocation and assignment record in the APNIC Whois Database.
	- For networks in exceptional circumstances that make it		The registered administrative contact (admin-c) must be someone who is physically located at the site of the network, subject to the following exceptions:
	impractical to maintain an on-site administrative contact,		- For residential networks or users, the network's technical contact may be registered as admin-c.
	an off-site person may be registered as the 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		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.
	at the site of the network, but must be a person who is
	responsible for the day-to-day operation of the network.
End of changes. 98 change blocks.
	488 lines changed or deleted		150 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/