[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Wg-ipv6-guide] Final Draft
Hi Anne,
We are happy that you post the edited document on the SIG-ML directly.
I think SIG-ML is now appropriate ML if we want further comments.
Thanks for your consideration for this.
regards,
Toshi
From: Anne Lord <anne@apnic.net>
Subject: Re: [Wg-ipv6-guide] Final Draft
Date: Wed, 10 Mar 2004 10:37:55 +1000
> hi Toshi,
>
> Thank you for sending this document through, and many thanks to the team
> for all their hard work.
>
> The Secretariat will begin editing this document as requested. One
> question. Are you happy with the Secretariat posting directly to the
> sig-policy mailing list or would you like us to send the edited document to
> the working group mailing list for a quick review?
>
> Best wishes,
> Anne
> --
>
> At 09:48 PM 3/9/2004 +0900, Toshiyuki Hosaka wrote:
> >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
>
> _______________________________________________
> Wg-ipv6-guide mailing list
> Wg-ipv6-guide@lists.apnic.net
> http://mailman.apnic.net/mailman/listinfo/wg-ipv6-guide
>
>
