IPv6 Assignment and Allocation Policy Document

Hello all,


Below is a mail I just send to the ipv6-wg at ripe.net mailing list. (The
mailing list of the IPv6 working group at RIPE). It includes a draft
version of the proposed IPv6 assignment guidelines. We would like all
discussion about these guidelines to take place on the ipv6 mailing
list, rather than this one, so please subscribe to it if you are
interested in participating in the discussions.

To subscribe to the ipv6-wg mailing list, write to majordomo at ripe.net
with "subscribe ipv6-wg" in the body.

Kind regards,

Paula Caslav
RIPE NCC

------- Forwarded Message

Date:     Mon, 25 Jan 1999 11:46:45 +0100
From:     Paula Caslav <paula at ripe.net>
Sender:   owner-ipv6-wg at ripe.net
To:       ipv6-wg at ripe.net
Subject:  IPv6 Assignment and Allocation Policy Document


Hello all,

This is a draft version of the IPv6 assignment guidelines that we have
been working on with the other Regional Registries. We would like your
feedback on this at the RIPE meeting, and on this mailing list. The
other Registries are now also discussing this with their communities. 

Please note that when refering to the global adressing authority, we
use the name IANA in this draft for now, but we will update this as
soon as the ICANN developments progress.

Kind regards,

Paula Caslav
RIPE NCC

- - --------------------begin included draft----------------------------


IPv6 ASSIGNMENT AND ALLOCATION POLICY DOCUMENT (3rd draft)

TABLE OF CONTENTS

	Abstract
	1.	Scope
	2.	IPv6 Address Space and the Internet Registry System
	2.1	The Internet Registry System Hierarchy
	2.2	Goals of the Internet Registry System
	3.	IPv6 Technical Framework
	3.1	IPv6 Addressing Hierarchy
	3.2	Initial IPv6 Addressing Hierarchy
	4.	Addressing Policies
	4.1	Allocations
	4.2	Assignments
	4.3	Reclamation Methods/Conditions
	5.	Organizations Operating in More than One Region
	6.	DNS and Reverse Address Mapping
	7.	Glossary
	8.	List of References

ABSTRACT

This document describes the registry system for the distribution of
globally unique IPv6 address space, which follows a hierarchical
distribution as it does with IPv4. The distribution of IPv6 address
space is managed by the IANA (formerly IANA) and further delegated by
the Regional Internet Registries (IRs) as described in RFC 1881. The
Regional IRs assign Top-Level Aggregation Identifiers (TLAs) to
organizations, which in turn assign address space to other Internet
Service Providers (ISPs) and end users. This document describes the
policies and procedures associated with IPv6 address space management
that must be followed by the organizations that hold Top-Level
Aggregate IDs.  Since ISPs essentially will be serving as NLA
Registries for their customers, creating additional "layers" to the
Registry system, it is crucial that responsibilities, procedures, and
policies are well understood and consistently applied.

1.	SCOPE

This document first describes the global Internet Registry system for
the distribution of globally unique unicast IPv6 address space, as
defined in RFC 2374, and its operation, then describes the rules and
guidelines governing the distribution of this address space. The rules
set forth in this document are binding for all organizations that have
IPv6 address space allocated and assigned via a Regional IR.

This document does not describe private IPv6 address space, or anycast
and multicast address space distribution. It also does not describe
regional and local refinements of the global rules and
guidelines. This document serves as the base set of operational
guidelines in use by all Regional IRs.  Additional guidelines may be
imposed by a particular Regional IR as appropriate. As experience is
gained in allocating IPv6 addresses, these rules and guidelines may
change.

The remaining sections of this document are presented as follows:

Section 2, IPv6 Address Space and the Internet Registry System,
explains the goals used in assigning IPv6 addresses and outlines the
hierarchical structure of the responsible Internet Registry system
organizations used to achieve those goals.

Section 3, IPv6 Technical Framework, explains the IPv6 addressing
format and outlines the difference between a TLA, NLA, and SLA block.

Section 4, Addressing Policies, describes the requirements for
applying for a TLA allocation and the policies that apply to such
allocations.  It discusses how TLA registries can allocate space to
other ISPs (NLA blocks) and end-users (SLAs).

Section 5, Organizations Operating in More than One Region, describes
the process for requesting address space for organizations operating
in more than one IR region.

Section 6, DNS and Reverse Address Mapping, describes the role of the
Regional IRs in providing reverse delegation and explains how the
Regional IRs can manage subsidiary reverse delegation of
allocated/assigned address space.

Section 7, Glossary, provides a listing of terms used in this document
along with their definitions.

Section 8, List of References, provides a list of documents referenced
in this document.

2	IPv6 ADDRESS SPACE AND THE INTERNET REGISTRY SYSTEM

IPv6 unicast addresses are aggregatable with contiguous bit-wise masks
similar to IPv4 addresses under CIDR.  With IPv6, scarcity of address
space is assumed to no longer exist for the end-user. However, routing
table explosion and the efficient assignment of address space are
still of great concern. Thus, aggregation and efficiency
(conservation) of prefix allocations are explicit goals of the
Internet registry system.

2.1	The Internet Registry System Hierarchy

In order to achieve the goals of the Internet Registry system, a
hierarchy was established which consists of the following levels as
seen from the top down: IANA, Regional Internet Registries, and TLA
Registries.

2.1.1	IANA

The Internet Corporation for Assigned Names and Numbers (IANA) has
authority over all number spaces used in the Internet, including IPv6
address space. IANA allocates parts of the IPv6 address space to
Regional Internet Registries (IRs) according to their established
needs.

2.1.2	Regional Internet Registries

Regional IRs operate in large geographical regions such as
continents. Currently, three Regional IRs are established: ARIN
serving North and South America, the Caribbean, and sub-Saharan
Africa; RIPE NCC serving Europe, the Middle East, and parts of Asia
and Africa; and APNIC serving Asia and Pacific regions.  These
regional IRs also serve areas beyond their core service areas to
ensure that all regions around the globe are covered.  Additional
Regional IRs may be established in the future, but it is expected that
the number of Regional IRs will remain relatively small.  Service
areas will be of continental dimensions.

Regional IRs are established under the authority of the IANA. This
requires consensus within the Internet community of the region and may
require consensus of ISPs in that region.

2.1.3	TLA Registries

TLA Registries are established under the authority of the Regional
IR. These Registries have the same roles and responsibilities as a
Regional IR within their designated service areas.

2.2	Goals of the Internet Registry System

The remainder of this document is primarily concerned with the
management of public IPv6 address space. Every assignment of IPv6
addresses should be made with the following goals in mind for it is in
the interest of the Internet community as a whole that these goals be
pursued. It is worth noting that "conservation" and "aggregation" are
often conflicting goals, and therefore each assignment must be
evaluated carefully. Moreover, these goals may occasionally be in
conflict with the interests of individual end users or ISPs. In such
cases, careful analysis and judgement are necessary to find an
appropriate compromise. The rules and guidelines in this document are
intended to help Regional IRs, ISPs, and end-users in their search for
effective solutions.

2.2.1	Uniqueness

Each public IPv6 address worldwide must be unique. This is an absolute
requirement which guarantees that every host on the Internet can be
uniquely identified.

2.2.2	Aggregation

Public IPv6 addresses are distributed in a hierarchical manner,
permitting the aggregation of routing information. This is necessary
to ensure proper operation of Internet routing.

IPv4 addresses were not as hierarchical as needed for efficient
routing across the Internet. Problems arose in IPv4 network addresses
with classful allocations and inefficient use of them.  This led to
too many routing entries appearing in the default-free core of the
Internet. To overcome this problem, the number of global routes must
be limited according to technical restrictions. These technical
constraints will have to be reevaluated as router technology changes.
Until new paramaters are defined, however, the policies described in
this document will remain valid.

2.2.3	Conservation

Although IPv6 network address resources appear to be endless, care
must be taken to avoid repetition of the IPv4 problems and instead
focus on demonstrated need.  These precautions will help manage and
conserve IPv6 network addresses for future use.

In order to mitigate this problem in use of IPv6, conservation is one
of the main goals.  It should be noted however, that the IPv6
addressing architecture allows end-sites a great amount of
flexibility. Eighty bits out of a total of 128 bits available in an
IPv6 address are used for addressing an end-site. Address space can be
conserved only by carefully evaluating the requirements from TLAs and
NLAs and allocating address space on the basis of demonstrated need.

Experience has shown that the growth and the consequences of growth
were never anticipated with IPv4.  The Regional IRs will apply the
lessons from the IPv4 experience to ensure that conservative policies
are implemented from the beginning.

2.2.4	Registration

In response to the rapid growth of Internet activity, a public
registry system was established to document address space allocation
and assignment. This was necessary to ensure uniqueness of Internet
addresses and to provide information for Internet trouble-shooting at
all levels. As with IPv4 addresses, each of the Regional IRs maintains
a public database where all IPv6 assignments and reassignments are
entered so that network operators can identify other network
organizations.

3.	IPv6 TECHNICAL FRAMEWORK

3.1	IPv6 Addressing Hierarchy

RFC 2373 specifies that aggregatable addresses are organized into a
topological hierarchy which consists of a public topology, a site
topology, and interface identifiers. These in turn map into the
following:

| 3|  13 | 8 |   24   |   16   |          64 bits               |
+--+-----+---+--------+--------+--------------------------------+
|FP| TLA |RES|  NLA   |  SLA   |         Interface ID           |
|  | ID  |   |  ID    |  ID    |                                |
+--+-----+---+--------+--------+--------------------------------+
|-- public topology---|  site  |          Interface             | 
|                     |topology|                                |
+---------------------+--------+--------------------------------+ 
|                              |                                |
|-------- network portion----->+<-------host portion------------|
|                             /64                               | 
|---------------------------------------------------------------|

The site topology is represented by a /48. Each site has a potential
for 65,535 subnets as specified in RFC 2374. The network portion is
represented by the first 64 bits. The host portion is represented by
the last 64 bits of the address. A /64 is the minimum network prefix
that can be assigned within a site. Additional subnets would require
additional prefixes of the same size or shorter to be assigned.  Note
that the boundaries are "hard" between the network and host portions
and that the ID address space cannot be further sub-divided as all
interface ID's are required to be in the EUI-64 format as per RFC
2373/4.  The boundaries are also hard between the public topology and
the site topology division at the /48.  The technical motivation for
this is given in RFC 2374 in order to facilitate multi-homing.

In IPv6, the following prefix boundaries are suggested:
 

	number of the		number of the		          ID	
	left-most		right-most		longest	  length
	bit boundary		bit boundary		prefix    (in bits)
	************		************		*******   ********
TLA ID	     4			    16			 /16       13
Reserved    17			    24			 N/A	    8
NLA ID      25			    48			 /48       24
SLA ID      49			    64			 /64	   16	

3.2	Initial IPv6 Addressing Hierarchy

A slightly modified version of the above (a special case of TLA
0x0001) derives a sub-TLA portion from principally the reserved
address space. This has been described in RFC 2450.

This has the following format and prefix boundaries:

| 3|    13    |   13    |  19     |   16   |       64 bits      |
+--+----------+---------+---------+--------+--------------------+
|FP|   TLA    | sub-TLA |  NLA    |  SLA   |   Interface ID     |
|  |   ID     |         |  ID     |  ID    |                    |
+--+----------+---------+---------+--------+--------------------+

For this TLA, this means that there are the following prefix boundaries:
 
	  number of the		number of the		          ID	
	  left-most 		right-most		longest	  length
	  bit boundary		bit boundary		prefix    (in bits)
	  ************		************		*******   ********
TLA ID         4		    16			 /16       13
sub-TLA ID    17		    29			 /29	   13
NLA ID        30		    48			 /48       19
SLA ID	      49		    64			 /64	   16	

For purposes of a slow start of a sub-TLA, however, a first sub-TLA
allocation would actually always be a /35 block (13 bits instead of
19).

All router interfaces are required to have at least one link-local
unicast address or site-local address. Site-local will be used for all
point-to-point links, loopback addresses, and so forth. As these are
not required to be visible outside the site's network, they do not
require public address space.  Any global unicast address space
assigned must not be used for the link-local or site-local purpose as
there is reserved address space for these addresses.  (Note that all
1's and all 0's are valid unless specifically excluded through
reservation. See list of reserved addresses in RFC 2373.)

4.	ADDRESSING POLICIES

4.1	Allocations

Regional IRs make allocations to requesting organizations that qualify
for a sub-TLA. Those organizations further allocate NLA space to ISP
customers who in turn assign SLA space to end-sites. Sub-TLA holders
can also assign SLA space directly to end-users, and sub-TLA and NLA
holders will use SLA space to address their own networks. This
hierarchical allocation structure allows aggregation of routing
information.

4.1.1	Requirements for Allocating a Sub-TLA 

In order to meet the conservation and aggregation goals discussed
above, only requesting organizations that meet certain requirements
will be allocated sub-TLA space. The requirements for an initial
allocation to an organization are different from the requirements that
have to be met once the initial allocation has been used and
additional address space is requested.

Whereas the requirements for an initial allocation are based on
technical considerations, all additional address space is purely based
on the utilization of the initial allocation.  In order to meet the
aggregation goal, requests for an initial allocation of a sub-TLA have
to be carefully evaluated. It is not necessary for every requesting
organization to obtain sub-TLA space. The following requirements must
be met in order to obtain an initial allocation of sub-TLA address
space:

The requesting organization's IPv6 network must be interconnected with
the IPv6 networks of at least three other organizations that have a
sub-TLA allocated to them, and either:

	-- The requesting organization must have reassigned IPv6
	   addresses received from its upstream provider or providers
	   to 100 SLA customer sites with routed networks.  Dial-in
	   customers do not count toward the 100 IPv6 customer sites.
	   Customers currently using IPv4 host addresses for dial-up
	   should not be assigned an NLA or an SLA, or

	-- The requesting organization must demonstrate a clear intent
	to provide IPv6 service within 3 months after receiving
	allocated address space.  This must be substantiated by such
	documents as an engineering plan or deployment plan.

The above criterion that requires interconnection with at least three
other sub-TLAs creates a bootstrapping problem which can be resolved
by the following requirements that have been defined for a
bootstrapping period:

The requesting organization's network must have BGP peering
relationships with at least three other public Autonomous Systems in
default-free zones,

The requesting organization must show that it already has issued IPv4
address space to 100 customer sites that can meet the criteria for a
/48 IPv6 reassignment, and

The requesting organization must demonstrate a clear intent to provide
IPv6 service within 3 months after receiving allocated address space.
This must be substantiated by such documents as an engineering plan or
deployment plan.

The first 50 requesting organizations who obtain a sub-TLA must
fulfill either the criteria for the bootstrapping or the general
criteria. Only 30 out of these 50 networks/organizations can be
located in one region. After 50 sub-TLAs have been allocated, the
bootstrap criteria will no longer apply.

Once 30 organizations have been allocated sub-TLAs within one region,
additional applications from that region must satisfy the general
criteria, while applications from other regions may only have to
satisfy the bootstrap criteria.  This is because the first group of
registries would not be able to fulfill the first criteria of being
connected to three other sub-TLA networks, since there would be few
sub-TLA networks at the start.  After 50 sub-TLA registries are
formed, there will be enough choices for new prospective sub-TLAs to
find others to connect to and the bootstrapping phase can end. It has
been decided to further limit the amount per region (an area covered
by one Regional IR), so that one region will not have an unfair
advantage over another.

NOTE - Those who qualify for TLA or sub-TLA (whether during bootstrap
or later) and who then fail to demonstrate ongoing utilization, will
have their allocation revoked (defined further in section 4.3).

4.1.2	Size for Initial Allocation/Slow-Start Mechanism

The initial allocation of sub-TLA space will allow 13 bits worth of
NLA IDs to be utilized by the organization receiving the /35 reserved
from the sub-TLA unless the requesting organization submits
documentation to the Regional IR to justify an exception. This initial
allocation allows the organization to create a hierarchy within the
allocation depending on their customer type (ISP or end-site) and the
topology of their own network. For example: this allows the
organization to receive 8,192 NLAs (a /48 each).  The making of
assignments (to ISPs or end-sites) is covered in section 4.2 in more
detail.

The size of the initial allocation has been set to 13 bits because
this allows the TLA Registry some freedom in creating an addressing
hierarchy. If it has other Service Providers as customers (who in turn
have their own end-user customers), this allows the TLA Registry to
sub-allocate smaller blocks to each of them.

4.1.3	Requirements for Next Allocation

Once an organization has used 80% of the sub-TLA address space, the
organization may contact the Regional IR in its region to request that
another range of addresses be allocated.  The size of the next range
depends on the utilization rate of the previous allocation.

It must be stressed that it is not enough to have allocated 80% of the
sub-TLA address space. The addresses must also be assigned and in use
by end-sites. This means that sub-TLA holders must be careful and
conservative in their allocations to their ISP customers. Address
space must be allocated and assigned based on actual
need. Administrative convenience or internal routing table size can
not be a reason to allocate or assign additional address space. It is
expected that sub-TLA holders also apply a slow-start mechanism as
described in section 4.2.2 to their ISP customers.

The next allocation may be another range of sub-TLA space with a
shorter prefix than the previous one. If growth is no longer possible
in the sub-TLA space, it is expected that a full TLA will be
allocated. In order to justify a new range of sub-TLA or TLA space,
the utilization of the previous allocation must be demonstrated.  This
is described below.

4.1.3.1	Verification of Utilization

All assignments to end-sites must be registered in the database of the
Regional IR in the region the sub-TLA holder operates. The TLA
Registry is responsible for the utilization of the sub-TLA and the
registration of the end-site assignments and ISP allocations in the
database. The Regional IR will verify whether all assignments are
registered in the database. In addition to the database entries, the
Regional IR may ask for periodic reports describing the utilization of
the addresses to be sent.

It is required that the end-sites be connected and reachable. The
Regional IR has the right to ping end-sites' /48s. Filtering holes
should be negotiated by the Regional IR and the organization with the
addresses.  Therefore, it is suggested that end-sites use anycast
cluster addresses on their border routers to enable this. It is
expected that one /48 SLA block is enough address space per
end-site. If an end-site requests an additional SLA, the sub-TLA
holder must send the request to the Regional IR for a second opinion.
The information provided below shows address boundaries and their
corresponding amount of address space.

a TLA = /16 of address space
an NLA = /48 of address space
an SLA = /64 of address space

TLA block = 13 bits of address space
NLA block = 19 bits of address space
SLA block = 16 bits of address space

4.1.3.2	Renumbering 

Once it has been decided to allocate additional TLA space to a sub-TLA
holder, the previously allocated sub-TLA must be returned to the
Regional IR.  The sub-TLA holder must then renumber its own
network. This of course has an impact on all of its customers and
customers' networks. Therefore, it is recommended that the sub-TLA
holder and its ISP customers make contractual arrangements with their
customers at the time of the first assignment.  These arrangements
should clarify that the address space will have to be returned in the
event the sub-TLA holder requests a full TLA, in which case, all
end-sites must be renumbered. The sub-TLA holder should inform its
customers early on regarding the upcoming need to renumber. The
sub-TLA will have 3 months to return the sub-TLA space after the next
TLA has been allocated.

Renumbering in IPv6 is considerably easier than in IPv4. Once the
provider has informed its customer about the address range to be used
in the future, the customer's network (end-site) will have two sets of
addresses for a certain period of time.  Hosts learn prefixes from
router advertisements. With each prefix, there is a "valid lifetime"
and a "preferred lifetime" designation.  New sessions should be
initiated with the preferred address, but existing ones can continue
with the old (valid but not preferred) address.  A mechanism called
Router Renumbering (RR) allows address prefixes on routers to be
configured and reconfigured almost as easily as the combination of
Neighbor Discovery and Address Autoconfiguration works for hosts.  It
provides a means for a network manager to make updates to the prefixes
used and advertised by IPv6 routers throughout a site. (M. Crawford,
work in progress)

Note that site-local addresses are not affected by renumbering the
global unicast IPv6 addresses.

4.2	Assignments

4.2.1	Assignments to End-users

Every end-user organization receives a /48 worth of address space (80
bits). Out of this, 16 bits are an SLA block used for subnetting and
another 64 bits are used per interface. All requests for additional address
space from the same TLA Registry must be submitted to the Regional IR
for evaluation (a second opinion). In this case the full utilization
of the initial SLA must be documented. The need for additional address
space must be presented in the form of an engineering plan. Since the
SLA part of the end-user's assignment allows for creating 65,536
subnets, the organization must show in what way this was not
sufficient for their network, and must present a plan showing where
each of the 65,536 subnets is used and why new subnets are necessary.

Only end-user organizations with a need to create subnets in their
network should be assigned a full /48.  Dial-up lines are considered
part of the ISP's infrastructure and should be assigned from the SLA of
that ISP. 

4.2.2	Assignments and Allocations to Other ISPs 

If the TLA Registry has ISP customers (who in turn have end-users),
the TLA Registry could use the 13 bits of NLA address space to create
an addressing hierarchy for them.  Each of the TLA Registry's own
end-users would receive a /48 as specified above, however, the ISP
customers (NLAs) could be "allocated" additional bits in order to
aggregate the ISP's customers internally.  A slow-start mechanism will be used 
for these NLA allocations. 

The NLA block would be an allocation to the ISP and not an assignment.
Therefore, if the ISP does not fully utilize it in a certain period of
time, the range will have to be returned. Also, the sub-TLA
organization should be careful about making these sub-allocations
because they will get a new sub-TLA only when 80% of their entire
sub-TLA block is assigned, not just allocated. Therefore, if they have
many sub-allocations that are not fully used, they might ask the ISPs
to give back some of the address space to use for other customers.

Once an NLA ISP has used up its allocation, it may request an
additional block from the TLA Registry. This block can be any size,
depending on how quickly it took the ISP to use up its first
block. Any additional requests for NLA allocations should be submitted
to the Regional IR for a second opinion.

Each NLA allocation must be registered in the Regional IR
database. All end-user assignments must also be registered in the
Regional IR database. The same procedures for these end-user
assignments apply for the end-user assignments made by the TLA
Registry to their customers directly. In the end, the TLA Registry is
responsible for how the address space is handled and should have an
overview of all the assignments being made by the NLA Service
Providers. TLA Registries will not be permitted to assign static IPv6
addresses to dial-up customers. The Regional IR can at any time ask
for additional information about the allocations and assignments being
made (see /draft-ietf-dhc-dhcpv6-13.txt).

4.3	Reclamation Methods/Conditions 

Allocations are valid only as long as the original criteria are still
met. The criteria for allocating TLA address space may change over
time depending on routing technology. The current target is to limit
the global routing space to roughly 8,000 entries. If 50% of this
limit is reached, routing technology and allocation criteria will be
reviewed.  If routing technology allows additional route entries, the
number of possible TLAs and sub-TLAs may be increased.

If it turns out that routing technology at that time does not allow
additional routing entries, the allocations made up to that point will
be reviewed. Sub-TLA holders with a very low usage rate (to be defined
before publication) or sub-TLA holders that do not meet the new
criteria may have their sub-TLA space revoked. These organizations
will have to renumber and return the sub-TLA within a maximum of 3
months. During the period that routing technology is being
investigated, the Regional IRs will continue allocating address space
even if the number of "possible" routes are reached.

5.	ORGANIZATIONS OPERATING IN MORE THAN ONE REGION

If an organization requesting sub-TLA space operates in more than one
region, and needs separate sub-TLA blocks for routing purposes, it
should request the address space for its entire network from only one
of the Regional IRs. It can apply for an initial allocation that is
larger than 13 bits if it can show that its network is divided into
several components with each needing its own sub-TLA route (each
component individually needs to fulfill the criteria for being a TLA
Registry). The size of the allocation would depend on how many
top-level routes are needed.

For example, if a multinational transit provider can show that it
needs three top-level routes, it would initially receive 15 bits of
NLA space (a /33).  It could then allocate a /35 to each of the
top-level parts of the network and route each one separately. Each of
these sub-allocations would need to be entered in the database of the
Regional IR individually.

6.	DNS AND REVERSE ADDRESS MAPPING

TBD

7.	GLOSSARY

Allocation - The provision of IP address space to ISPs that reassign
their address space to customers.

Assignment - The provision of IP address space to end-user organizations.

End-user - An organization receiving reassignments of IPv6 addresses
exclusively for use in operational networks.

Interface Identifiers - A 64-bit IPv6 unicast address identifier that
identifies an interface on a link.

NLA ID - Next-Level Aggregation Identifier.

NLA ISP - Internet Service Providers receiving IPv6 address
allocations from a TLA Registry.

Public Topology - The collection of providers and exchanges who
provide public Internet transit service.

Regional Internet Registries - Organizations operating in large
geographical regions such as continents which are responsible for fair
distribution of globally unique Internet address space and for
documenting address space allocation and assignment.

Site - A location, physical or virtual, with a network backbone
connecting various network equipment and systems together. There is no
limit to the physical size or scope of a site.

Site Topology - A local, specific site or organization which does not
provide public transit service to nodes outside the site.

SLA ID - Site-Level Aggregation Identifier.

Slow Start - The efficient means by which addresses are allocated to
TLA Registries and to NLA ISPs. This method involves issuing small
address blocks until the provider can show an immediate requirement
for larger blocks.

TLA ID - Top-Level Aggregation Identifier.

TLA Registry - Organizations receiving TLA/sub-TLA ID from Regional
IRs to reassign to customers.

Unicast - An identifier for a single interface. A packet sent to a
unicast address is delivered to the interface identified by that
address. Note that the definition of an IPv4 host is different from an
IPv6 identifier. One physical host may have many interfaces, and
therefore many IPv6 identifiers.

8.	LIST OF REFERENCES




- - --------------------end included draft----------------------------



- ------- End of Forwarded Message



------- End of Forwarded Message