As per Relevance of the word registry, we have this rfc below:
Network Working Group Y.
Request for Comments: 2073
Category: Standards Track P.
STUPI.
R.
Ipsilon
S.
Xerox
J.
January 1997
An IPv6 Provider-Based Unicast Address
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
1.0
This document defines an IPv6 provider-based unicast address
for use in the Internet. The address format defined in this
is consistent with the "IPv6 Addressing Architecture" [ARCH] and
"An Architecture for IPv6 Unicast Address Allocation" [ALLOC], and
intended to facilitate scalable Internet routing
The unicast address format defined in this document doesn't
the use of other unicast address formats
2.0 Overview of the IPv6
IPv6 addresses are 128-bit identifiers for interfaces and sets
interfaces. There are three types of addresses: Unicast, Anycast
and Multicast. This document defines a specific type of
address
In this document, fields in addresses are given specific names,
example "subscriber". When this name is used with the term "ID" (
"identifier") after the name (e.g., "subscriber ID"), it refers
the contents of the named field. When it is used with the
"prefix" (e.g., "subscriber prefix") it refers to all of the
up to and including this field
Rekhter, et. al. Standards Track [Page 1]
RFC 2073 IPv6 Provider-Based Unicast Address Format January 1997
The specific type of an IPv6 address is indicated by the leading
in the address. The variable-length field comprising these
bits is called the Format Prefix (FP).
This document defines an address format for the 010 (binary)
Prefix for Provider-Based Unicast addresses. The same address
could be used for other Format Prefixes, as long as these
Prefixes also identify IPv6 unicast addresses. Only the "010"
Prefix is defined here
3.0 IPv6 Provider-Based Unicast Address
This document defines an address format for the IPv6 provider-
unicast address assignment. It is expected that this address
will be widely used for IPv6 nodes connected to the Internet
The address format defined in this document conforms to
"Architecture for IPv6 Unicast Address Allocation" [ALLOC].
Specifically, the format is designed to support aggregation
network layer reachability information at multiple levels of
hierarchy
For addresses of the format described in this document the
administration is organized into a three level hierarchy -- registry
provider, and subscriber. The address format defined here
flexible address allocation at each level of the
administration hierarchy in such a way as to support a wide
of demands for address allocation
This document assumes that the Internet routing system doesn't
any assumptions about the specific structure and semantics of an IPv
address, except for the structure and semantics of the Format
part of the address, and the use of the "longest prefix match
algorithm (on arbitrary bit boundaries) for making a
decision
The address format defined in this document is intended to
scalable Internet-wide routing that does not impose any
on connectivity among the providers, as well as among the
and subscribers
Rekhter, et. al. Standards Track [Page 2]
RFC 2073 IPv6 Provider-Based Unicast Address Format January 1997
3.1 Provider-Based Unicast Address
For the purpose of address allocation, the address format defined
this document consists of the following parts: Format Prefix
Registry ID, Provider ID, Subscriber ID, and an Intra-
part. The Intra-Subscriber part definition is the responsibility
the subscriber and is not defined in this document. The provider
based unicast address format is as follows
| 3 | 5 bits | n bits | 56-n bits | 64 bits |
+---+----------+------------+--------------+--------------------+
|010|RegistryID| ProviderID | SubscriberID | Intra-Subscriber |
+---+----------+------------+--------------+--------------------+
The following sections specify each part of the IPv6 Provider-
Unicast address format. In general other allocation strategies
possible within this framework, but the ones described in
document will be used to assign IPv6 provider-based addresses
3.2 Registry
With the growth of the Internet and its increasing globalization
much thought has been given to the evolution of the Network
address space allocation and assignment process. RFC 1466,
"Guidelines for Management of IP Address Space", proposes a plan
defines distributed allocation and assignment of the IPv4
space
As the Internet transitions to IPv6, the plan for
allocation and assignment of the IPv4 address space established
RFC1466 forms a base for the distributed allocation and assignment
the IPv6 address space
The Internet Assigned Number Authority (IANA) is the
registry for the IPv6 address space. The IANA may allocate blocks
IPv6 addresses and delegate the assignment of those blocks
qualified Regional Registries. The IANA will serve as the
registry in cases where no delegated registration authority has
identified
The Registry ID of the IPv6 provider-based unicast address format
intended to facilitate a broad geographic address allocation
facilitate the operations of the distributed Regional Registries
The Registry ID immediately follows the format prefix part of an IPv
address
Rekhter, et. al. Standards Track [Page 3]
RFC 2073 IPv6 Provider-Based Unicast Address Format January 1997
At present there are three Regional Registries: INTERNIC, RIPE NCC
and APNIC. In addition, address allocation could be done directly
the IANA. Corresponding to this division of address allocation,
document defines the following Registry IDs
Regional Registry Value (binary
-------------------- --------------
Multi-Regional (IANA) 10000
RIPE NCC 01000
INTERNIC 11000
APNIC 00100
All other values of the Registry ID are reserved by the IANA
Use of the Multi-regional Registry ID permits flexibility in
assignments which are outside of the geographical regions
allocated. The IANA will be responsible for managing address
registration under the Multi-Regional Registry ID
It is expected that the IANA, and any designated Regional Registries
allocate addresses in conformance with this overall scheme.
there are qualifying Regional Registries established,
responsibility for allocation from within that block will
delegated to that registry
A Regional Registry may have more than one block of
allocated to it (as a result the Registry would have
Registry IDs associated with it).
3.3 Provider ID and Subscriber
This document leaves the organization of the Provider ID
Subscriber ID portions of address up to individual registries
Particularly the registry needs to define how much address space
given to providers and their subscribers. There are several
which must be addressed when doing this. These include
o There will likely be a mixture of providers of different sizes
o Small providers will grow to become large providers
o Large providers will lose customers and become small providers
In extreme cases, the registry will require them to return
of their address space to the registry
o Organizations which need to be multi-homed to more than
provider will request a Provider ID assignment
It is important that a registry design its Provider ID space to
flexibility and at the same time use the address space efficiently
Rekhter, et. al. Standards Track [Page 4]
RFC 2073 IPv6 Provider-Based Unicast Address Format January 1997
3.3.1 Provider
The value of the Provider ID associated with an address block
registry allocates to a particular provider uniquely identifies
provider within the registry
This document assumes that some subscribers may decide to
their address space directly from a registry, thus making
addresses independent of the provider(s) they are directly attached
3.3.2 Subscriber
The structure and assignment strategy of Subscriber ID's is
by each provider
A (direct) provider may decide to group its subscribers into regions
This grouping may be useful when the (direct) provider is attached
another (indirect) provider at multiple points, as it allows
direct provider to exert a certain degree of control over
coupling between the attachment points and flow of the
destined to a particular subscriber (see Section 5.3.1 of [ALLOC]).
To accommodate such a grouping the (direct) provider may
some small number of high-order bits of the Subscriber ID as
Subscriber-Region ID. The purpose of a Subscriber-Region ID is
identify a group of subscribers that are within a close
proximity to each other (from the provider's point of view), and
could be reachable through a particular attachment point between
(direct) provider and other (indirect) provider(s).
3.4 Intra-Subscriber
This document leaves the organization of Intra-Subscriber portion
the address up to individual subscribers
The provider-based unicast address format described in this
leaves 64 bits for the local portion of the address. The editors
this document recommend that subscribers use IPv6 auto-
capabilities [AUTO] to generate addresses using link-
addresses as Interface ID such as 48 bit IEEE-802 MAC addresses.
this case 16 bits are left for the Subnet ID. This should
(e.g., 65,535 subnets) for all but the largest of subscribers.
is shown as follows
| 64 bits | 16 bits | 48 bits |
+--------------------------------+-----------+------------------+
| Subscriber Prefix | Subnet ID | Interface ID |
+--------------------------------+-----------+------------------+
Rekhter, et. al. Standards Track [Page 5]
RFC 2073 IPv6 Provider-Based Unicast Address Format January 1997
Subscribers who need additional subnets (and who desire to
to use 48 bit IEEE-802 MAC addresses for Interface ID's) can
accommodated by having the provider assign them a block of
prefixes. Alternatively, an extremely large subscriber could
assigned its own Provider ID which would give it additional bits
address space to create its own local address hierarchy
4.0 National
A Regional Registry may allocate blocks of address space to
National Registries. The National Registry then becomes the
that allocates address space to individual providers within
country served by the National Registry
To create National Registries the Regional Registry may add a
of hierarchy in the Provider ID field to create National Registries
The resulting Provider Prefix is as follows
| 3 | 5 bits | n bits | m bits | 56-n-m | 64 bits |
+---+----------+----------+----------+------------+----------------+
|010|RegistryID| National | Provider | Subscriber |Intra-Subscriber
| | |RegistryID| ID | ID | |
+---+----------+----------+----------+------------+----------------+
This document assumes that within each regional registry there
be a relatively small number of national registries. The size of
National-Registry ID should be related to the number of countries
the region administrated by the regional registry and the number
providers expected to be in each country
5.0
The editors would like to express our thanks to Jim Bound (Digital),
Scott Bradner (Harvard), Brian Carpenter (CERN), Geoff
(AANET), and Tony Li (cisco) for their review and
comments
6.0
[ALLOC] Rekhter, Y., Li, T., "An Architecture for IPv6
Address Allocation", RFC 1887, December 1995.
[ARCH] Hinden, R., "IP Version 6 Addressing Architecture",
RFC 1884, December 1995.
[AUTO] Thompson, S., "IPv6 Stateless Address Autoconfiguration",
RFC 1972, August 1996.
Rekhter, et. al. Standards Track [Page 6]
RFC 2073 IPv6 Provider-Based Unicast Address Format January 1997
7.0 Security
Security issues are not discussed in this memo
8.0 Editors'
Yakov
Cisco Systems, Inc
170 West Tasman
San Jose, CA 95134-1706
Phone: +1 914 528-0090
EMail: yakov@cisco.
Peter
STUPI.
Box 9129
S-102 72
Phone:+46 8 6699720
EMail: roll@Stupi.
Robert M.
Ipsilon Networks, Inc
2191 E. Bayshore
Palo Alto, CA 94303
Phone: +1 415 846 4604
EMail: hinden@ipsilon.
Stephen E.
Xerox Palo Alto Research
3333 Coyote Hill
Palo Alto, CA 94304
Phone: +1 415 812 4839
Fax: +1 415 812 4471
EMail: deering@parc.xerox.
Jon
Information Sciences
4676 Admiralty
Marina del Rey, CA 90292-6695
Phone: +1 310 822 1511
Fax: +1 310 823 6714
EMail: postel@isi.
Rekhter, et. al. Standards Track [Page 7]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
