Dear APNIC secretariat and all,
On behalf of co-chairs I would like to thank all the members of this
WG for participating the discussion on the IPv6 Guideline Document. We
made the presentation for our activity at the APNIC 17 last month, and
one action item was set as below.
"pol-17-004: Secretariat to edit and publish the IPv6 guidelines
document on the sig-policy maililng list."
We hereby request APNIC secretariat to edit our draft taking various
comments from the community, part of which we described in the ppt
slides at the meeting, into consideration. The final draft version is
attached later in this mail.
We look forward to seeing an edited document on the sig-ML.
Thanks again and best regards,
Toshi
-----------------------------------------------------------------
APNIC guidelines for IPv6 allocation and assignment requests
(Version 0.4 : 20040305)
About this document
These guidelines are intended to complement the document Policies for
IPv6 address space management in the Asia Pacific region, which
provides for APNIC to publish guidelines relating to specific request
evaluation requirements and best current practice issues.
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
1. Introduction
2. Scope
3. Additional guidance
4. Goals of address space management
5. Application of guidelines
6. Definition of a 'site'
6.1 Assignment address space size
7. Initial allocation criteria
7.1 Use of existing IPv4 infrastructure
7.2 Documentation required
7.2.1 Supplementary Document
7.3 Closed networks
8. Second opinion requests
8.1 Sub-Allocations and Second Opinion Request
8.2 Documentation required
9. Subsequent allocations
10. Requesting a reverse delegation
11. Database registrations
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 IPv6 public address
space in the Asia Pacific region.
Where practical, the guidelines in this document are expressed in
relation to types of connectivity, rather than to specific
technologies.
This document does not apply to IPv4, Multicast, or 'Unique local IPv6
unicast address, 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
4. Goals of address space management
In this document, all reference to the goals of address space
management refer to the goals described in Policies for IPv6
address space management in the Asia Pacific region, namely:
* uniqueness;
* registration;
* aggregation;
* conservation;
* fairness; and
* minimized 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.
6. Definition of a 'site'
An end site is defined as an end user who has a business relationship,
i.e. has a contract, with a service provider to receive their service.
The end user (the end site) cannot re-assign IP addresses to other
organization out of its assigned IP address space.
The number of sites is counted in accordance with the number of
contracts. Each 'end site' is eligible to receive /48 assignment in
general case.
For example;
(Single site)
- A home(corporate) user who has a single contract with a
service provider for its own device and/or network.
- A home(corporate) user who has multiple devices to connect
the internet, but has only one contract with a service
provider.
(Multiple sites)
- A home (corporate) user who has multiple contracts with (a)
service provider(s).
- A home (corporate) user who has multiple separate networks,
and they are not connected each other because each network
has different management policy, even if they are in the
same place. (-note- In this case this user is considered to
have multiple contracts with (a) service provider(s).
e.g.) A merged company with independenet networks
If two or more organizations each possessing
independent networks merged into a single organization
but continues to exchanging seperate contracts with
ISPs, they can be considered as multiple sites.
6.1 Assignment address space size
A single site may be assigned a /48 in general case as the policy
defines.
For example;
- Residential subscribers, connecting through on-demand or
always-on connections such as through ADSL/CATV, can
receive a /48.
- Even in the case where a /64 or a /128 seems to approproate
initially (e.g. single PC), LIRs still can assign a /48 when
future growth is anticipated.
- A single site may receive larger address space than a /48
only if the case is justified by RIR/NIR level. (see 8.
Second Opnion Request)
7. Initial allocation criteria
According to current IPv6 policy, to qualify for an initial allocation
of IPv6 address space, an organization must meet the criteria stated in
IPv6 policy clause 5.1.1.
Followings are the supplementary information about initial allocation
criteria especially on 200*/48 criteria, to which the requestor can
refer.
(Planning 200*/48 assignment)
- An organization must provide a 'plan' to make at least 200
/48 assignments, but is not necessarily required to 'commit'
200. RIR/NIR regards the exisitence of a 'plan' to provide
IPv6 services or its readiness to commence, not its
feasibility.
e.g) An ISP which has 200 or more customers can meet the
initial allocation criteria of 200*/48, if it plans to
provide them with IPv6 connectivity service.
- sub-allocations to downstream ISPs can be taken into account
as "to be assigned /48". (*)
e.g) The following case meets the initial allocation
criteria of 200*/48.
Plan within the next two years:
/44 sub-allocation (= 16*/48 assignments)
assignments to POPs 20*/48
assignments to "sites" 170*/48
-----------------------------------------
total 206*/48 > 200*/48
(*) When subsequent allocation requests, only /48s
registered to RIR/NIR database are counted (not all the
sub-allocated space. See 9. Subsequent Allocations)
- A /48 can be assigned for customers to both static and
dynamically addressed networks.
- Existing IPv4 infrastructure/customers can also be taken
into consideration.
e.g) If a CATV provider has 4,000 IP static connection(*)
customers in IPv4 and 5%(200) of them are expected to
subscribe IPv6 service connection, then, this provider
meets the initial allocation criteria of 200*/48.
(*) Even if LIRs assign a single static IP in IPv4, it's up
to the ISP to assign a /48 to these customers.
7.1 Use of existing IPv4 infrastructure
LIRs can justify their requested initial allocation size by the
number of their existing IPv4 users as well as the extent of their
IPv4 network infrastructure. LIRs can choose this option to show
their eligibility to receive initial IPv6 allocation.
From this perspective LIRs are likely to be eligible for an initial
allocation criteria in case they;
- meet the current IPv4 allocation criteria AND
- receive the current IPv4 allocation as an LIR AND
- plan to tranfer the existing IPv4 infrastructure
or customers partly or wholly to IPv6 in two years.
Note: this is just to provide an idea, and not guarantee the initial
allocation.
However 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 200*/48 criteria, or to decide the address block
size allocated when they request larger space than a /32.
7.2 Documentation required
When LIRs request their initial IPv6 address allocation to RIR/NIR,
LIRs are requested to provide designated request form as well as the
following supportive information.
- Network diagram
- Network equipment information. This is to ensure LIR has a
plan to implement IPv6 ready infrastructure.
- Approximate deployment date.
- Service plan (Web hosting, Access service, etc)
- IPv4 infrastructure and/or customer information if LIR
chooses the option of use of existing IPv4 infrastructure
(see 7.1 Use of existing IPv4 infrastructure).
7.2.1 Supplementary Document
When requesting an initial allocation to RIR/NIR, model/Vendor
name of LIR's network equipment is not mandatory but there may be
a case that RIR/NIR asks those information if LIRs require a
plenty of pool address such as CATV/ADSL operator.
7.3 Closed networks
APNIC will allocate global IPv6 address space to organization which
network is reachable or not reachable from global IPv6 Internet, if
its organization meets the conditions stated in current IPv6 policy,
[5.1.1 Initial allocation criteria], since it does not require
global route advertisement.
For example organizations below are likely to meet 5.1.1(c) in
the current IPv6 policy despite they are closed networks.
Therefore if they meet other criteria listed in 5.1.1, they are
eligible to obtain IPv6 addresses.
- An ISP which provides IPv6 services to other organization
(company or individual) but its network is closed within its
ISP or restricted ISPs such as peering partners.
- A large company who provides IPv6 connectivity to its group
companies or subsidiaries and its network is closed within
itself.
8. Second opinion requests
When one single end site requires shorter prefix than /48 (e.g. /47 ,
/46...)for 2 years requirement, or it requires additional /48(s) after
its initial assignment, LIRs must follow Second opinion request
process prior to the assignment.
It is considered that a /48 address space is sufficent per one single
end site, and there is no experience with such assignments as /47 to
a single end site. Until such experience is gained RIR/NIR will review
all such assignements.
8.1 Sub-Allocations and Second Opinion Request
RIR/NIR do not require a Second Opinion Request for
sub-allocations to downstream ISPs. (Please see [9.
Subsequent allocations].) Nevertheless when LIRs are unsure how
much address space to sub-allocate, LIRs are recommended to ask
RIRs/NIRs for advice.
8.2 Documentation required
In addition to the designated request form, LIRs are requested to
provide RIR/NIR with the detailed network information as below;
- Network diagram of an end-site
- Network equipment information
- Full details to justify multiple /48 assignments to an
end-site
(e.g. the number of clients (PCs or other NW equipments) or
other information which justify multiple /48s assignment)
9. Subsequent allocations
- An example of a typical ISP.
(1) 1st subsequent allocation
A typical ISP receives /32 that is 65,536 * /48s as an initial
allocation.
If this ISP allocates or assigns 7,132 * /48s to it's customers and
its POPs, this ISP has a right of the 1st subsequent allocation.
7,132 is from the HD-Ratio table ( Policy : Appendix A )
Example
assignments to POPs 326 * /48
assignments to end sites 6,500 * /48
assignments through downstream ISP 306 * /48
------------------------------------------------
total 7,132 * /48s
(2) Subsequent allocation (Example of the 2nd subsequent allocation)
This ISP receives additional /32 from an adjacent address block as
the second allocation. Now, this ISP has one /31 address block.
If this ISP allocates or assigns 12,417 * /48s including the
previous 7,132 * /48s to it's customers and its POPs, this ISP has a
right of the 2nd subsequent allocation.
12,417 is from the HD-Ratio table ( Policy : Appendix A )
- Utilization in case of Sub-allocation
Utilization is calculated based on the number of /48 assignments
which are registered in the registry database(*) including
/48 assignments through downstream ISPs. It is not based on the size
of sub-allocations to the downstream ISPs.
(*) needed clarified definition.
If a sub-allocation is made to a down stream ISP, but assignments
are not registered in the database, it will not considered utilized.
e.g.) /40 sub-allocation is made to a downstream ISP. 2*/48 is
assigned from this block. In this case, 2*/48 is considered as
utilized, not /40(256*/48).
So, LIRs should carefully consider and justify the sub-allocation
size'.
<note> In IPv4, Sub-allocations to downstream ISPs are considered as
assignment.
- RIRs/NIRs do not request to LIRs for a Second Opinion Requests (SOR)
for sub-allocations to downstream ISPs.
<note> In IPv4, To prevent LIRs from making unrealistic
sub-allocations, RIRs/NIRs have a policy requesting for an SOR,
so that RIRs/NIRs can see the details of the allocations.
- RIRs temporarily reserve 8 * /32 adjacent address blocks for each
organization. This space is worth /29. But unless each organization
obtains additional allocation, these spaces can be allocated to other
organizations based on the Space Allocation System.
http://xxx.xxx.apnic.net
10. Requesting a reverse delegation
- Responsibility of delegation
- When RIR allocates to LIR,
- Reserve lookup must be delegated to LIR.
- When LIR assigns to end site,
- Reserve lookup must be delegated to end site upon end site's
request.
- When LIR allocates to it's downstream ISP,
- Reserve lookup must be delegated to LIR.
- When downstream ISP assigns to end site
- Reserve lookup must be delegated from downstream ISP to end
site upon end site's request. It means it is downstream ISP
or end site's responsibility.
- Registration of each host
It is not compulsory nor recomended. There is no recommendation or
suggenstion about it in any document.
- Registration of Temporary addresses defined in RFC3041
It is not compulsory nor recomended. The reason is same as Registration
of each host.
- Minimum size
- Minimum size of reverse delegation is /48.
- ip6.int. / ip6.arpa
- ip6.int is now deprecated for all organizations.
- Shifting from ip6.int. to ip6.arpa. is appreciated for all
organizations.
- If it is impossible to shift, the organization are requested to
have both environment.
11. Database registrations
- Definition of Database
In this policy, "database" means the Whois Databases of RIRs and NIRs.
- The organization responsible for registration
(1) Allocation
Each RIR is responsible for registering initial and subsequent
allocation information in a database. Typical example is the /32
or /31 allocations to ISPs.
(2) Assignment
(a) When an organization that is holding an address allocation
makes assignments, this organization is responsible for
registering the assignment. Typical example of this organization
is ISP.
(b) When an organization makes an assignment through downstream
ISP, Ether LIR or downstream ISP is responsible for
registering the assignment.
So, LIRs need some rules or contracts between downstream ISPs in
order to receive assignment information.
(3) Sub-allocations
Each sub-allocations must be registered by LIRs when making
allocations to its downstream ISPs.
- Database to be registered
- If NIR doesn't have it's own database, RIR's database is the
one to be registered.
- If NIR starts it's own database service, each organizaton must
register NIR's database after NIR's announcement.
- Items to be registered
http://www.apnic.net/db/ref/attributes/attributes-inet6num.html
- Registration grater then /48
For example, the organization which has assigned /47 have to register
the /47 block in the database.
- Updating of the database
When some information is updated in the database, the organization
which has assigned it is responsible for updating the database.
----------------------------------------------------------------------
End of document
_______________________________________________
Wg-ipv6-guide mailing list
Wg-ipv6-guide@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/wg-ipv6-guide
