INTERNET-DRAFT                                        Y. Rekhter, Cisco
August 30, 1995                                   P. Lothberg, STUPI.AB
Expires in six months                       R. Hinden, Ipsilon Networks
                                                 S. Deering, Xerox PARC
                                                         J. Postel, ISI
                                                                Editors




             An IPv6 Provider-Based Unicast Address Format

              <draft-ietf-ipngwg-unicast-addr-fmt-02.txt>



Status of this Memo

This document is an Internet Draft.  Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas, and
its Working Groups.  Note that other groups may also distribute working
documents as Internet Drafts.

Internet Drafts are draft documents valid for a maximum of six months.
Internet Drafts may be updated, replaced, or obsoleted by other
documents at any time.  It is not appropriate to use Internet Drafts as
reference material or to cite them other than as a ``working draft'' or
``work in progress.''

Please check the 1id-abstracts.txt listing contained in the internet-
drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net,
ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any
Internet Draft.


1.0 Introduction

This document defines an IPv6 provider-based unicast address format for
use in the Internet.  The address format defined in this document is
consistent with the "IPv6 Addressing Architecture" [ARCH] and the "An
Architecture for IPv6 Unicast Address Allocation" [ALLOC], and is
intended to facilitate scalable Internet routing.

The unicast address format defined in this document doesn't preclude the
use of other unicast address formats.






draft-ietf-ipngwg-unicast-addr-fmt-02.txt                       [Page 1]


INTERNET-DRAFT    Provider-Based Unicast Address Format  August 30, 1995


2.0 Overview of the IPv6 Address

IPv6 addresses are 128-bit identifiers for interfaces and sets of
interfaces.  There are three types of addresses: Unicast, Anycast, and
Multicast.  This document defines a specific type of Unicast address.

In this document, fields in addresses are given specific names, for
example "subscriber".  When this name is used with the term "ID" (for
"identifier") after the name (e.g., "subscriber ID"), it refers to the
contents of the named field.  When it is used with the term "prefix"
(e.g.  "subscriber prefix") it refers to all of the address up to and
including this field.

The specific type of an IPv6 address is indicated by the leading bits in
the address.  The variable-length field comprising these leading bits is
called the Format Prefix (FP).

This document defines an address format for the 010 (binary) Format
Prefix for Provider-Based Unicast addresses. The same address format
could be used for other Format Prefixes, as long as these Format
Prefixes also identify IPv6 unicast addresses.  Only the "010" Format
Prefix is defined here.


3.0 IPv6 Provider-Based Unicast Address Format

This document defines an address format for the IPv6 provider-based
unicast address assignment.  It is expected that this address format
will be widely used for IPv6 nodes connected to the Internet.

The address format defined in this document conforms to the
"Architecture for IPv6 Unicast Address Allocation" [ALLOC].
Specifically, the format is designed to support aggregation of network
layer reachability information at multiple levels of routing hierarchy.

For addresses of the format described in this document the address
administration is organized into a three level hierarchy -- registry,
provider, and subscriber.  The address format defined here allows
flexible address allocation at each level of the address administration
hierarchy in such a way as to support a wide spectrum of demands for
address allocation.

This document assumes that the Internet routing system doesn't make any
assumptions about the specific structure and semantics of an IPv6
address, except for the structure and semantics of the Format Prefix
part of the address, and the use of the "longest prefix match" algorithm
(on arbitrary bit boundaries) for making a forwarding decision.




draft-ietf-ipngwg-unicast-addr-fmt-02.txt                       [Page 2]


INTERNET-DRAFT    Provider-Based Unicast Address Format  August 30, 1995


The address format defined in this document is intended to facilitate
scalable Internet-wide routing that does not impose any constraints on
connectivity among the providers, as well as among the providers and
subscribers.


3.1 Provider-Based Unicast Address Structure

For the purpose of address allocation, the address format defined in
this document consists of the following parts:  Format Prefix, Registry
ID, Provider ID, Subscriber ID, and an Intra-Subscriber part.  The
Intra-Subscriber part definition is the responsibility of the subscriber
and is not defined in this document.  The provider-based unicast address
format is as follows:

   | 3 |  5 bits  |  16 bits | 8 |   24 bits  | 8 |    64 bits     |
   +---+----------+----------+---+------------+---+----------------+
   |010|RegistryID|ProviderID|RES|SubscriberID|RES|Intra-Subscriber|
   +---+----------+----------+---+------------+---+----------------+

The following sections specify each part of the IPv6 Provider-Based
Unicast address format.  In general other allocation strategies are
possible within this framework, but the ones described in this document
will be used to assign IPv6 provider-based addresses.

The fields identified as "RES" are reserved and must be set to zero (0).
They are intended to allow for the fields on either side to grow into
that space if needed for future growth.


3.2 Registry ID

With the growth of the Internet and its increasing globalization, much
thought has been given to the evolution of the Network Layer address
space allocation and assignment process.  RFC 1466, "Guidelines for
Management of IP Address Space", proposes a plan that defines
distributed allocation and assignment of the IPv4 address space.

As the Internet transitions to IPv6, the plan for distributed allocation
and assignment of the IPv4 address space established in RFC1466 forms a
base for the distributed allocation and assignment of the IPv6 address
space.

The Internet Assigned Number Authority (IANA) is the principal registry
for the IPv6 address space.  The IANA may allocate blocks of IPv6
addresses and delegate the assignment of those blocks to qualified
Regional Registries.  The IANA will serve as the default registry in
cases where no delegated registration authority has been identified.



draft-ietf-ipngwg-unicast-addr-fmt-02.txt                       [Page 3]


INTERNET-DRAFT    Provider-Based Unicast Address Format  August 30, 1995


The Registry ID of the IPv6 provider-based unicast address format is
intended to facilitate a broad geographic address allocation and
facilitate the operations of the distributed Regional Registries.

The Registry ID immediately follows the format prefix part of an IPv6
address.

At present there are three Regional Registries: INTERNIC, RIPE NCC, and
APNIC.  In addition, address allocation could be done directly by the
IANA.  Corresponding to this division of address allocation, this
document defines the following Registry IDs:

     Regional Registry                     Value (binary)
     --------------------                  --------------

     Multi-Regional (IANA)                 10000
     RIPE NCC                              01000
     INTERNIC                              11000
     APNIC                                 10100

All other values of the Registry ID are reserved by the IANA.

Use of the Multi-regional Registry ID permits flexibility in address
assignments which are outside of the geographical regions already
allocated.  The IANA will be responsible for managing address space
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.  Where there
are qualifying Regional Registries established, primary responsibility
for allocation from within that block will be delegated to that
registry.

A Regional Registry may have more than one block of addresses allocated
to it (as a result the Registry would have multiple Registry IDs
associated with it).


3.3 Provider ID

The Provider ID is initially assigned 16 bits.  At some time in the
future it may be allowed to grow (to the right) into the "RES" field if
additional providers are needed in a particular registry.  The 16-bit
Provider ID provides for 65,535 providers per Registry ID without any
expansion of the Provider ID, or 2,031,585 providers within this format
prefix.

The value of the Provider ID associated with an address block a registry



draft-ietf-ipngwg-unicast-addr-fmt-02.txt                       [Page 4]


INTERNET-DRAFT    Provider-Based Unicast Address Format  August 30, 1995


allocates to a particular provider uniquely identifies this provider
within the registry.

Provider ID's should be allocated from right to left as shown in
following table:

     Provider          Provider ID Value (binary)
     ---------         --------------------------

     Provider 1        0000 0000 0000 0001
     Provider 2        0000 0000 0000 0010
     Provider 3        0000 0000 0000 0011
     Provider 4        0000 0000 0000 0100
     Provider 5        0000 0000 0000 0101
                        :    :    :    :
     Provider 65,535   1111 1111 1111 1111

This document assumes that some subscribers may decide to acquire their
addresses space directly from a registry, thus making their addresses
independent of the provider(s) they are directly attached.


3.4 Subscriber ID

The Subscriber ID is initially assigned 24 bits.  At some time in the
future it may be allowed to grow (to the left) into the "RES" field if
additional subscribers are needed in a particular provider.  The 24-bit
Subscriber ID provides for 16,777,215 subscribers per Provider ID
without any expansion of the Provider ID, or approximately 34 trillion
subscribers within this format prefix.

The structure and assignment strategy of Subscriber ID's is specified 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 to
another (indirect) provider at multiple points, as it allows the direct
provider to exert a certain degree of control over the coupling between
the attachment points and flow of the traffic destined to a particular
subscriber (see Section 5.3.1 of [ALLOC]).

To accommodate such a grouping the (direct) provider may allocate some
small number of high-order bits of the Subscriber ID as a Subscriber-
Region ID.  The purpose of a Subscriber-Region ID is to identify a group
of subscribers that are within a close topological proximity to each
other (from the providers point of view), and thus could be reachable
through a particular attachment point between the (direct) provider and
other (indirect) provider(s).



draft-ietf-ipngwg-unicast-addr-fmt-02.txt                       [Page 5]


INTERNET-DRAFT    Provider-Based Unicast Address Format  August 30, 1995


3.5 Intra-Subscriber Part

This document leaves the organization of Intra-Subscriber portion of the
address up to individual subscribers.

The provider-based unicast address format described in this document
leaves 64 bits for the local portion of the address.  The editors of
this document recommended that subscribers use IPv6 auto-configuration
capabilities [AUTO] to generate addresses using 48 bit IEEE-802 MAC
addresses as Interface IDs.  In this case 16 bits is left for the Subnet
ID.  This should sufficient (e.g., 65,535 subnets) for all but the
largest of subscribers.  This is shown as follows:

   |            64 bits             |  16 bits  |     48 bits      |
   +--------------------------------+-----------+------------------+
   |       Subscriber Prefix        | Subnet ID |   Interface ID   |
   +--------------------------------+-----------+------------------+

Subscribers who need additional subnets (and who desire to continue to
use 48 bit IEEE-802 MAC addresses for Interface ID's) can be
accommodated by allowing the Subnet ID can grow to the left into the
"RES" field.  Alternatively, an extremely large subscriber could be
assigned its own Provider ID which would give it 48 bits of address
space to create its own local address hierarchy.


4.0 National Registries

A Regional Registry may allocate blocks of address space to several
National Registries.  The National Registry then becomes the entity that
allocates address space to individual providers within the country
served by the National Registry.

To create National Registries the Regional Registry may add a layer of
hierarchy in the Provider ID field to create National Registries.  The
resulting Provider Prefix is a follows:


        |   |          |              16 bits              |
        | 3 |  5 bits  |       n bits        |  16-n bits  |
        +---+----------+---------------------+-------------+
        |010|RegistryID|National-Registry ID | Provider ID |
        +---+----------+---------------------+-------------+

This document assumes that within each regional registry there will be a
relatively small number of national registries.  The size of the
National-Registry ID should be related to the number of countries in the
region administrated by the regional registry and the number providers



draft-ietf-ipngwg-unicast-addr-fmt-02.txt                       [Page 6]


INTERNET-DRAFT    Provider-Based Unicast Address Format  August 30, 1995


expected to be in each country.  National Registries who need additional
providers can be supported by allowing the Provider ID to grow to the
right into the "RES" field.
















































draft-ietf-ipngwg-unicast-addr-fmt-02.txt                       [Page 7]


INTERNET-DRAFT    Provider-Based Unicast Address Format  August 30, 1995


6.0 Acknowledgments

The editors would like to express our thanks to Jim Bound (DEC), Scott
Bradner (Harvard), Brian Carpenter (CERN), Geoff Huston (AANET), and
Tony Li (cisco) for their review and constructive comments.


6.0 References



  [ALLOC] Rekhter, Y., Li, T., "An Architecture for IPv6 Unicast Address
          Allocation", Internet Draft.

  [ARCH]  Hinden, R., "IP Version 6 Addressing Architecture" Internet
          Draft.

  [AUTO]  Thompson, S., "IPv6 Stateless Address Autoconfiguration",
          Internet Draft.


7.0 Security Considerations

Security issues are not discussed in this memo.


8.0 Editors' Addresses

     Yakov Rekhter
     Cisco Systems, Inc.
     170 West Tasman Drive
     San Jose, CA 95134-1706
     USA
     Phone:  +1 914 528-0090
     email:  yakov@cisco.com

     Peter Lothberg
     STUPI.AB
     Box 9129
     S-102 72 Stockholm
     Sweden
     Phone:+46 8 6699720
     email: roll@Stupi.SE








draft-ietf-ipngwg-unicast-addr-fmt-02.txt                       [Page 8]


INTERNET-DRAFT    Provider-Based Unicast Address Format  August 30, 1995


     Robert M. Hinden
     Ipsilon Networks, Inc.
     2465 Latham Street, Suite 100
     Mt. View, CA 94040
     USA
     phone: +1 415 528 4604
     email: hinden@ipsilon.com

     Stephen E. Deering
     Xerox Palo Alto Research Center
     3333 Coyote Hill Road
     Palo Alto, CA 94304
     USA
     phone: +1 415 812 4839
     fax:   +1 415 812 4471
     email: deering@parc.xerox.com

     Jon Postel
     Information Sciences Institute
     4676 Admiralty Way
     Marina del Rey, CA 90292-6695
     USA
     phone: +1 310 822 1511
     fax:   +1 310 823 6714
     email: postel@isi.edu


























draft-ietf-ipngwg-unicast-addr-fmt-02.txt                       [Page 9]