DRAFT: IPv6 Address Allocation and Assignment Policy
|
Brett Carr
Ondrej Sury
Filiz Yilmaz
Ingrid Wijte
Jordi Palet Martinez
Document ID: ripe-TBA
Date: TBA
How to read this draft document:
This document relates to RIPE policy proposal 2008-05
- Anycasting Assignments for TLDs and Tier 0/1 ENUM. If approved, it will replace ripe-466.
To show you how the new document would be different to the old
one, we have highlighted any new text or changes to the existing
text.
We indicate changes to existing text in the document like this:
| ORIGINAL
TEXT |
NEW
TEXT |
The text from the current policy
document that will be replaced is displayed here. |
The proposed
new text will be displayed here. |
All other text in the document will not be replaced.
Abstract
This document defines registry policies for the assignment and
allocation of globally unique IPv6 addresses to Internet Service
Providers (ISPs) and other organisations . It was developed through
joint discussions among the APNIC, ARIN and RIPE communities.
Contents
1. Introduction
1.1. Overview
2. Definitions
2.1. Internet Registry (IR)
2.2. Regional Internet Registry (RIR)
2.3. National Internet Registry (NIR)
2.4. Local Internet Registry (LIR)
2.5. Allocate
2.6. Assign
2.7. Utilisation
2.8. HD-Ratio
2.9. End Site
3. Goals of IPv6 address space management
3.1. Goals
3.2. Uniqueness
3.3. Registration
3.4. Aggregation
3.5. Conservation
3.6. Fairness
3.7. Minimised Overhead
3.8. Conflict of Goals
4. IPv6 Policy Principles
4.1. Address space not to be considered property
4.2. Routability not guaranteed
4.3. Minimum Allocation
4.4. Consideration of IPv4 Infrastructure
5. Policies for Allocations and Assignments
5.1. Initial Allocation
5.1.1. Initial Allocation Criteria
5.1.2. Initial Allocation Size
5.2. Subsequent Allocation
5.2.1. Subsequent Allocation Criteria
5.2.2. Applied HD-Ratio
5.2.3. Subsequent Allocation Size
5.3. LIR-to-ISP Allocation
5.4. Assignment
5.4.1. Assignment Address Space Size
5.4.2. Assignments Shorter than a /48 to a single End Site
5.4.3. Assignment to Operator's Infrastructure
5.5. Registration
5.6. Reverse Lookup
5.7. Existing IPv6 Address Space Holders
6. Assignments for Internet Experiments
6.1. Defining the Experiment
6.2. Publication
6.3. Non-commercial Basis
6.4. Period of the Temporary Resource Registration
6.5. Registration
6.6. Making the Request
8.
IPv6 Provider Independent (PI) Assignments
9.
References
10.
Appendix A: HD-Ratio
11.
Appendix B: Background Information
11.1.
Background
11.2.
Why a Joint Policy?
11.3.
The Size of IPv6's Address Space
11.4.
Acknowledgment
1. Introduction
1.1. Overview
This document describes policies for the allocation and assignment of
globally unique Internet Protocol version 6 (IPv6) address space.
[RFC 4291] designates 2000::/3 to be global unicast address space that the
Internet Assigned Numbers Authority (IANA) may allocate to the RIRs.
In accordance with [RFC 4291], IANA allocated initial ranges of
global unicast IPv6 address space from the 2000::/3 address block to
the RIRs.
This document concerns the initial and subsequent
allocations of the 2000::/3 unicast address space, for which RIRs
formulate allocation and assignment policies. All bits to the left of
/64 are in scope.
This
policy is subject to future review and potential revision, subject to
continuing experience in the administration of IPv6.
2. Definitions
[Note: Some of these definitions will be replaced by definitions from other
RIR documents in order to be more consistent.]
The
following terms and their definitions are of particular importance to
the understanding of the goals, environment and policies described in
this document.
Responsibility
for management of IPv6 address spaces is distributed globally in
accordance with the hierarchical structure shown below.

2.1. Internet Registry (IR)
An Internet Registry is an organisation that is responsible for
distributing IP address space to its members or customers and for
registering those distributions. IRs are classified according to
their primary function and territorial scope within the hierarchical
structure depicted in the figure above.
2.2. Regional Internet Registry (RIR)
Regional Internet Registries are established and authorised by
respective regional communities and recognised by the IANA to serve
and represent large geographical regions. The primary role of RIRs is
to manage and distribute public Internet address space within their
respective regions.
2.3. National Internet Registry (NIR)
A National Internet Registry primarily allocates address space to its
members or constituents, which are generally LIRs organised at a
national level. NIRs exist mostly in the Asia Pacific region.
2.4. Local Internet Registry (LIR)
A Local Internet Registry is an IR that primarily assigns address
space to the users of the network services that it provides. LIRs are
generally ISPs whose customers are primarily End Users and possibly
other ISPs.
2.5. Allocate
To "allocate" means to distribute address space to IRs for the
purpose of subsequent distribution by them.
2.6. Assign
To "assign" means to delegate address space to an ISP or End User
for specific use within the Internet infrastructure they operate.
Assignments must only be made for specific purposes documented by
specific organisations and are not to be sub-assigned to other
parties.
2.7. Utilisation
The actual usage of addresses within each assignment may be low when
compared to IPv4 assignments. In IPv6, "utilisation" is
only measured in terms of the bits to the left of the efficiency
measurement unit (/56). In other words, "utilisation"
effectively refers to the assignment of network prefixes to End Sites
and not the number of addresses assigned within individual End Site
assignments.
Throughout this document, the term "utilisation" refers to
the assignment of network prefixes to End Sites and not the number of
addresses assigned within individual subnets within those End Sites.
2.8. HD-Ratio
The
HD-Ratio is a way of measuring the efficiency of address assignment
[RFC
3194 ]. It is an adaptation of
the H-Ratio originally defined in [RFC1715
] and is expressed as follows:
Log (number of allocated objects) ?
HD = ----------------------------------------------
Log (maximum number of allocatable objects)
where (in the case of this document) the objects are IPv6 site
addresses assigned from an IPv6 prefix of a given size.
2.9. End Site
An
End Site is defined as an End User (subscriber) who has a business or
legal relationship (same or associated entities) with a service
provider that involves:
that service provider assigning address space to the End User
that service provider providing transit service for the End User to
other sites
that service provider carrying the End User's traffic
that service provider advertising an aggregate prefix route that
contains the End User's assignment
3. Goals of IPv6 Address Space Management
3.1. Goals
IPv6 address space is a public resource that must be managed in a
prudent manner with regards to the long-term interests of the
Internet. Responsible address space management involves balancing a
set of sometimes competing goals. The following are the goals
relevant to IPv6 address policy.
3.2. Uniqueness
Every assignment and/or allocation of address space must guarantee
uniqueness worldwide. This is an absolute requirement for ensuring
that every public host on the Internet can be uniquely identified.
3.3. Registration
Internet address space must be registered in a registry database
accessible to appropriate members of the Internet community. This is
necessary to ensure the uniqueness of each Internet address and to
provide reference information for Internet troubleshooting at all
levels, ranging from all RIRs and IRs to End Users.
The goal of registration should be applied within the context of
reasonable privacy considerations and applicable laws.
3.4. Aggregation
Wherever possible, address space should be distributed in a
hierarchical manner, according to the topology of network
infrastructure. This is necessary to permit the aggregation of
routing information by ISPs and to limit the expansion of Internet
routing tables.
This goal is particularly important in IPv6 addressing, where the
size of the total address pool creates significant implications for
both internal and external routing.
IPv6 address policies should seek to avoid fragmentation of address
ranges.
Further, RIRs should apply practices that maximise the potential for
subsequent allocations to be made contiguous with past allocations
currently held. However, there can be no guarantee of contiguous
allocation.
3.5. Conservation
Although IPv6 provides an extremely large pool of address space,
address policies should avoid unnecessarily wasteful practices.
Requests for address space should be supported by appropriate
documentation and stockpiling of unused addresses should be avoided.
3.6. Fairness
All policies and practices relating to the use of public address
space should apply fairly and equitably to all existing and potential
members of the Internet community, regardless of their location,
nationality, size, or any other factor.
3.7. Minimised Overhead
It is desirable to minimise the overhead associated with obtaining
address space. Overhead includes the need to go back to RIRs for
additional space too frequently, the overhead associated with
managing address space that grows through a number of small
successive incremental expansions rather than through fewer, but
larger, expansions.
3.8. Conflict of Goals
The goals described above will often conflict with each other, or
with the needs of individual IRs or End Users. All IRs evaluating
requests for allocations and assignments must make judgments, seeking
to balance the needs of the applicant with the needs of the Internet
community as a whole.
In IPv6 address policy, the goal of aggregation is considered to be
the most important.
4. IPv6 Policy Principles
To address the goals described in the previous section, the policies
in this document discuss and follow the basic principles described
below.
4.1. Address Space Not to be Considered Property
It is contrary to the goals of this document and is not in the
interests of the Internet community as a whole for address space to
be considered freehold property.
The policies in this document are based upon the understanding that
globally unique IPv6 unicast address space is licensed for use rather
than owned. Specifically, IP addresses will be allocated and assigned
on a license basis, with licenses subject to renewal on a periodic
basis. The granting of a license is subject to specific conditions
applied at the start or renewal of the license.
RIRs will generally renew licenses automatically, provided requesting
organisations are making a "good faith" effort at meeting the
criteria under which they qualified for or were granted an allocation
or assignment. However, in those cases where a requesting
organisation is not using the address space as intended, or is
showing bad faith in following through on the associated obligation,
RIRs reserve the right to not renew the license.Note
that when a license is renewed, the new license will be evaluated
under and governed by the applicable IPv6 address policies in place
at the time of renewal, which may differ from the policy in place at
the time of the original allocation or assignment.
4.2. Routability Not Guaranteed
There is no guarantee that any address allocation or assignment will
be globally routable.
However, RIRs must apply procedures that reduce the possibility of
fragmented address space which may lead to a loss of routability.
4.3. Minimum Allocation
RIRs will apply a minimum size for IPv6 allocations to facilitate
prefix-based filtering.
The minimum allocation size for IPv6 address space is /32.
4.4. Consideration of IPv4 Infrastructure
Where
an existing IPv4 service provider requests IPv6 space for eventual
transition of existing services to IPv6, the number of present IPv4
customers may be used to justify a larger request than would be
justified if based solely on the IPv6 infrastructure.
5. Policies for Allocations and Assignments
5.1. Initial Allocation
5.1.1. Initial Allocation Criteria
To
qualify for an initial allocation of IPv6 address space, an
organisation must:
a) be an LIR;
b) advertise the allocation that they will receive as a single
prefix if the prefix is to be used on the Internet;
c) have a plan for making sub-allocations to other organisations
and/or End Site assignments within two years.
5.1.2. Initial Allocation Size
Organisations that meet the initial allocation criteria are eligible
to receive a minimum allocation of /32.
Organisations may qualify for an initial allocation greater than /32
by submitting documentation that reasonably justifies the request. If
so, the allocation size will be based on the number of existing users
and the extent of the organisation's infrastructure.
5.2. Subsequent allocation
Organisations that hold an existing IPv6 allocation may receive a
subsequent allocation in accordance with the following policies.
5.2.1. Subsequent Allocation Criteria
Subsequent
allocation will be provided when an organisation (i.e. ISP/LIR)
satisfies the evaluation threshold of past address utilisation in
terms of the number of sites in units of /56 assignments. The
HD-Ratio [RFC
3194] is used to determine the
utilisation thresholds that justify the allocation of additional
address as described below.
5.2.2. Applied HD-Ratio
The HD-Ratio value of 0.94 is adopted as indicating an acceptable
address utilisation for justifying the allocation of additional
address space. Appendix A provides a table showing the number of
assignments that are necessary to achieve an acceptable utilisation
value for a given address block size.
5.2.3. Subsequent allocation size
When an organisation has achieved an acceptable utilisation for its
allocated address space, it is immediately eligible to obtain an
additional allocation that results in a doubling of the address space
allocated to it. Where possible, the allocation will be made from an
adjacent address block, meaning that its existing allocation is
extended by one bit to the left.
If an organisation needs more address space, it must provide
documentation justifying its requirements for a two-year period. The
allocation made will be based on this requirement.
5.3. LIR-to-ISP Allocation
There is no specific policy for an organisation (LIR) to allocate
address space to subordinate ISPs. Each LIR organisation may develop
its own policy for subordinate ISPs to encourage optimum utilisation
of the total address block allocated to the LIR. However, all /48
assignments to End Sites are required to be registered either by the
LIR or its subordinate ISPs in such a way that the RIR/NIR can
properly evaluate the HD-Ratio when a subsequent allocation becomes
necessary.
5.4. Assignment
LIRs must make IPv6 assignments in accordance with the following
provisions.
5.4.1. Assignment Address Space Size
End
Users are assigned an End Site assignment from their LIR or ISP. The
size of the assignment is a local decision for the LIR or ISP to
make, using a minimum value of a /64 (only one subnet is anticipated
for the End Site).
5.4.2. Assignment of Multiple /48s to a Single End Site
When a single End Site requires an assignment shorter than a /48, it
must request the assignment with documentation or materials that
justify the request. Requests for multiple or additional prefixes
exceeding a /48 assignment for a single End Site will be processed
and reviewed (i.e., evaluation of justification) at the RIR/NIR
level.
Note: There is no experience at the present time with the assignment
of multiple network prefixes to the same End Site. Having the RIR
review all such assignments is intended to be a temporary measure
until some experience has been gained and some common policies can be
developed. In addition, additional work at defining policies in this
space will likely be carried out in the near future.
5.4.3. Assignment to Operator's Infrastructure
An organisation (i.e. ISP/LIR) may assign a network prefix per PoP as
the service infrastructure of an IPv6 service operator. Each
assignment to a PoP is regarded as one assignment regardless of the
number of users using the PoP. A separate assignment can be obtained
for the in-house operations of the operator.
5.5. Registration
When an organisation holding an IPv6 address allocation makes IPv6
address assignments, it must register assignment information in a
database, accessible by RIRs as appropriate. (Information registered
by an RIR/NIR may be replaced by a distributed database for
registering address management information in future). Information is
registered at the granularity of End Site assignments. When more than
a /48 is assigned to an organisation, the assigning organisation is
responsible for ensuring that the address space is registered in an
RIR/NIR database.
RIR/NIRs will use registered data to calculate the HD-Ratio at the
time of application for subsequent allocation and to check for
changes in assignments over time.
IRs shall maintain systems and practices that protect the security of
personal and commercial information that is used in request
evaluation, but which is not required for public registration.
5.6. Reverse Lookup
When an RIR/NIR delegates IPv6 address space to an organisation, it
also delegates the responsibility to manage the reverse lookup zone
that corresponds to the allocated IPv6 address space. Each
organisation should properly manage its reverse lookup zone. When
making an address assignment, the organisation must delegate to an
assignee organisation, upon request, the responsibility to manage the
reverse lookup zone that corresponds to the assigned address.
5.7. Existing IPv6 Address Space Holders
Organisations
that received /35 IPv6 allocations under the previous IPv6 address
policy are immediately entitled to have their allocation expanded to
a /32 address block without providing justification so long as they
satisfy the criteria in Section 5.1.1.
The /32 address block will contain the already allocated smaller
address block (one or multiple /35 address blocks in many cases) that
was already reserved by the RIR for a subsequent allocation to the
organisation. Requests for additional space beyond the minimum /32
size will be evaluated as discussed elsewhere in the document.
6.0 Assignments for Internet Experiments
Organisations often require deployment tests for new Internet
services and technologies. These require numbering resources for the
duration of the test.
The policy goal of resource conservation is of reduced importance
when resources are issued on a temporary basis.
6.1 Defining the Experiment
An organisation receiving numbering resources must document the
experiment. This may be in the form of a current IETF Experimental
RFC (http://www.ietf.org/rfc/rfc2026.txt
see Sec. 4.2.1) or an
"experiment proposal" detailing the resources required and the
activities to be carried out.
6.2 Publication
The experiment proposal must be made public (e.g. published on web
site), upon registration of the resources by the RIPE NCC. Following
the conclusion of the experiment the results must be published free
of charge and free from disclosure constraints.
6.3 Non-commercial Basis
Resources issued for an experiment must not be used for commercial
purposes.
6.4 Period of the Temporary Resource Registration
The resources will be issued on a temporary basis for a period of one
year. Renewal of the resource's registration is possible on receipt
of a new request that details any continuation of the experiment
during the extended period.
The resources issued cannot be used for a commercial service
following the conclusion of the experiment.
6.5 Registration
The RIPE NCC will register the resources issued in the RIPE Whois
Database.
6.6 Making the Request
The request must be made by a Local Internet Registry (LIR) using
the appropriate request form for the resource found at:
http://www.ripe.net/ripe/docs/internet-registries.html#request
| ORIGINAL
TEXT |
NEW
TEXT |
7. Assignments for Anycasting TLD Nameservers
If the name server set of a ccTLD or a gTLD without anycasting
technology applied would not pass the 'IANA Administrative Procedure
for Root Zone Name Server Delegation and Glue Data' the TLD
administrator may receive a single dedicated /48 network prefix for
the sole purpose of anycasting name servers, as described in RFC
3258.
The prefix will be assigned by the RIPE NCC directly to the TLD, upon
a request properly submitted to the RIPE NCC, either directly or
through a sponsoring LIR. TLD anycasting address assignments are
subject to the policies described in the RIPE NCC document entitled
"Contractual Requirements for Provider Independent Resources
Holders in the RIPE NCC Service Region".
Anycasting assignments are registered with a status of 'ASSIGNED
ANYCAST' in the RIPE Database and must be returned to the RIPE NCC if
not in use for anycast DNS any longer. |
7. Assignments TLD and Tier 0/1 ENUM Nameservers
The organisations applicable under this policy are TLD managers, as
recorded in the IANA's Root Zone Database and ENUM administrators, as assigned by the ITU. The organisation may receive up to four /48 prefixes per TLD and four /48 prefixes per ENUM. These prefixes must be used for the sole purpose of anycasting authoritative DNS servers for the stated TLD/ENUM, as described in BCP126/RFC4786
Assignments for authoritative TLD or ENUM Tier 0/1 DNS lookup services are subject to the policies described in the RIPE Document entitled "Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region".
Anycasting assignments are registered with a status of 'ASSIGNED ANYCAST' in the RIPE Database and must be returned to the RIPE NCC if not in use for infrastructure providing authoritative TLD or ENUM Tier 0/1 DNS lookup services any longer.
|
8. IPv6 Provider Independent (PI) Assignments
To qualify for IPv6 PI address space, an organisation must:
a) not be an LIR
b) demonstrate that it will be multihomed
c) meet the requirements of the policies described in the RIPE NCC Document entitled "Contractual Requirements for Provider Independent Resources Holders in the RIPE NCC Service Region"
The RIPE NCC will assign the prefix directly to the End User organisations upon a request properly submitted to the RIPE NCC, either directly or through a sponsoring LIR.
The minimum size of the assignment is a /48. Organisations requesting a larger assignment (shorter prefix) must provide documentation justifying the need for additional subnets.
Additional assignments may also be made when the need is demonstrated and documented based on address usage, or because different routing requirements exist for additional assignments. When possible, these further assignments will be made from an adjacent address block.
Assignments will be made from a separate 'designated block' to facilitate filtering practices.
The PI assignment cannot be further assigned to other organisations.
9. References
[RFC1715]
"The H Ratio for Address Assignment Efficiency", C.
Huitema. November 1994, ftp://ftp.ripe.net/rfc/rfc1715.txt.
[RFC2026]
"The Internet Standards Process -- Revision 3 IETF Experimental
RFC ftp://ftp.ripe.net/rfc/rfc2026.txt
see Sec. 4.2.1
[RFC2462] "IPv6 Stateless Address Autoconfiguration", S.
Thomson, T. Narten, 1998, ftp://ftp.ripe.net/rfc/rfc2462.txt
[RFC
4291] "IP Version 6 Addressing Architecture", R. Hinden, S.
Deering. February 2006, ftp://ftp.ripe.net/rfc/rfc4291.txt
[RFC2928]
"Initial IPv6 Sub-TLA ID Assignments", R. Hinden, S.
Deering, R. Fink, T. Hain. September 2000
ftp://ftp.ripe.net/rfc/rfc2928.txt
[RFC3194]
"The H-Density Ratio for Address Assignment Efficiency An Update
on the H ratio", A. Durand, C. Huitema. November 2001,
ftp://ftp.ripe.net/rfc/rfc3194.txt
10. Appendix A: HD-Ratio
The utilisation threshold T, expressed as a number of individual /56 prefixes to be allocated from IPv6 prefix P, can be calculated as:
Thus, the utilisation threshold for an organisation requesting subsequent allocation of IPv6 address block is specified as a function of the prefix size and target HD ratio. This utilisation refers to the use of /56s as an efficiency measurement unit, and does not refer to the utilisation of addresses within those End Sites. It is an address allocation utilisation ratio and not an address assignment utilisation ratio.
In accordance with the recommendations of [RFC 3194], this document adopts an HD-Ratio of 0.94 as the utilisation threshold for IPv6 address space allocations.
The following table provides equivalent absolute and percentage address utilisation figures for IPv6 prefixes, corresponding to an HD-Ratio of 0.94.
|
Prefix
|
Total
/56s |
/56s
HD 0.94 |
Util
% |
|
10 |
70368744177664 |
10388121308479 |
14.76 |
|
11 |
35184372088832 |
5414630391777 |
15.39 |
|
12 |
17592186044416 |
2822283395519 |
16.04 |
|
13 |
8796093022208 |
1471066903609 |
16.72 |
|
14 |
4398046511104 |
766768439460 |
17.43 |
|
15 |
2199023255552 |
399664922315 |
18.17 |
|
16 |
1099511627776 |
208318498661 |
18.95 |
|
17 |
549755813888 |
108582451102 |
19.75 |
|
18 |
274877906944 |
56596743751 |
20.59 |
|
19 |
137438953472 |
29500083768 |
21.46 |
|
20 |
68719476736 |
15376413635 |
22.38 |
|
21 |
34359738368 |
8014692369 |
23.33 |
|
22 |
17179869184 |
4177521189 |
24.32 |
|
23 |
8589934592 |
2177461403 |
25.35 |
|
24 |
4294967296 |
1134964479 |
26.43 |
|
25 |
2147483648 |
591580804 |
27.55 |
|
26 |
1073741824 |
308351367 |
28.72 |
|
27 |
536870912 |
160722871 |
29.94 |
|
28 |
268435456 |
83774045 |
31.21 |
|
29 |
134217728 |
43665787 |
32.53 |
|
30 |
67108864 |
22760044 |
33.92 |
|
31 |
33554432 |
11863283 |
35.36 |
|
32 |
16777216 |
6183533 |
36.86 |
11. Appendix B: Background Information
11.1. Background
The impetus for revising the 1999 provisional IPv6 policy started
with the APNIC meeting held in Taiwan in August 2001. Follow-on
discussions were held at the October 2001 RIPE and ARIN meetings.
During these meetings, the participants recognised an urgent need for
more detailed, complete policies. One result of the meetings was the
establishment of a single mailing list to discuss a revised policy
together with a desire to develop a general policy that all RIRs
could use. This document does not provide details of individual
discussions that lead to policies described in this document;
detailed information can be found in the individual meeting minutes
at the www.apnic.net, www.arin.net, and www.ripe.net web sites.
In September 2002, at the RIPE 43 Meeting in Rhodes, Greece, the RIPE
community approved the policy allowing Internet experiments to
receive temporary assignments. As a result, Section 6 was added to
this document in January 2003.
11.2. Why a Joint Policy?
IPv6 addresses are a public resource that must be managed with
consideration to the long-term interests of the Internet community.
Although regional registries adopt allocation policies according to
their own internal processes, address policies should largely be
uniform across registries. Having significantly varying policies in
different regions is undesirable because it can lead to situations
where "registry shopping" can occur as requesting
organisations request addresses from the registry that has the most
favorable policy for their particular desires. This can lead to the
policies in one region undermining the efforts of registries in other
regions with regards to prudent stewardship of the address space. In
cases where regional variations from the policy are deemed necessary,
the preferred approach is to raise the issue in the other regional
registries in order to develop a consensus approach that all
registries can support.
11.3. The Size of IPv6's Address Space
Compared to IPv4, IPv6 has a seemingly endless amount of address
space. While superficially true, short-sighted and wasteful
allocation policies could also result in the adoption of practices
that lead to premature exhaustion of the address space.
It should be noted that the 128-bit address
space is divided into three logical parts, with the usage of each
component managed differently. The rightmost 64 bits, the Interface
Identifier [RFC4291], will often be a globally unique IEEE identifier
(e.g., mac address). Although an "inefficient" way to use
the Interface Identifier field from the perspective of maximising the
number of addressable nodes, the numbering scheme was explicitly
chosen to simplify Stateless Address Autoconfiguration [RFC2462].
The
middle bits of an address indicate the subnet ID. This field may
often be inefficiently utilised, but the operational benefits of a
consistent width subnet field were deemed to be outweigh the
drawbacks. This is a variable length field, determined by each LIR's
local assignment policy.
11.4. Acknowledgment
The initial version of this document was produced by the JPNIC IPv6
policy drafting team consisting of Akihiro Inomata, Akinori Maemura,
Kosuke Ito, Kuniaki Kondo, Takashi Arano, Tomohiro Fujisaki, and
Toshiyuki Yamasaki. Special thanks goes out to this team, who worked
over a holiday in order to produce an initial document quickly.
An editing team was then organised by representatives from each of
the three RIRs (Takashi Arano, Chair of APNIC's Policy SIG, Thomas
Narten, Chair of ARIN's IPv6 WG, and David Kessens, Chair of the RIPE
IPv6 Working Group).
The editing team would like to acknowledge the contributions to this
document of Takashi Arano, John Crain, Steve Deering, Gert Doering,
Kosuke Ito, Richard Jimmerson, David Kessens, Mirjam Kuehne, Anne
Lord, Jun Murai, Paul Mylotte, Thomas Narten, Ray Plzak, Dave Pratt,
Stuart Prevost, Barbara Roseman, Gerard Ross, Paul Wilson, Cathy
Wittbrodt and Wilfried Woeber.
The final editing of the initial version of this document was done by
Thomas Narten.
|