GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc2073

Network Working Group Y. Rekhter Request for Comments: 2073 cisco Category: Standards Track P. Lothberg

                                                              STUPI.AB
                                                             R. Hinden
                                                      Ipsilon Networks
                                                            S. Deering
                                                            Xerox PARC
                                                             J. Postel
                                                                   ISI
                                                               Editors
                                                          January 1997
           An IPv6 Provider-Based Unicast Address Format

Status of this Memo

 This document specifies an Internet standards track protocol for the
 Internet community, and requests discussion and suggestions for
 improvements.  Please refer to the current edition of the "Internet
 Official Protocol Standards" (STD 1) for the standardization state
 and status of this protocol.  Distribution of this memo is unlimited.

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.

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.

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 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.
 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.

Rekhter, et. al. Standards Track [Page 2] RFC 2073 IPv6 Provider-Based Unicast Address Format January 1997

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  |   n bits   |   56-n bits  |        64 bits     |
    +---+----------+------------+--------------+--------------------+
    |010|RegistryID| ProviderID | SubscriberID |  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.
 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.
 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.

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 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                                 00100
 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 and Subscriber ID

 This document leaves the organization of the Provider ID and
 Subscriber ID portions of address up to individual registries.
 Particularly the registry needs to define how much address space is
 given to providers and their subscribers.  There are several issues
 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 some
      of their address space to the registry.
    o Organizations which need to be multi-homed to more than one
      provider will request a Provider ID assignment.
 It is important that a registry design its Provider ID space to allow
 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 ID

 The value of the Provider ID associated with an address block a
 registry allocates to a particular provider uniquely identifies this
 provider within the registry.
 This document assumes that some subscribers may decide to acquire
 their address space directly from a registry, thus making their
 addresses independent of the provider(s) they are directly attached.

3.3.2 Subscriber ID

 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 provider's point of view), and thus
 could be reachable through a particular attachment point between the
 (direct) provider and other (indirect) provider(s).

3.4 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 recommend that subscribers use IPv6 auto-configuration
 capabilities [AUTO] to generate addresses using link-specific
 addresses as Interface ID such as 48 bit IEEE-802 MAC addresses.  In
 this case 16 bits are 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   |
    +--------------------------------+-----------+------------------+

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 continue
 to use 48 bit IEEE-802 MAC addresses for Interface ID's) can be
 accommodated by having the provider assign them a block of subscriber
 prefixes.  Alternatively, an extremely large subscriber could be
 assigned its own Provider ID which would give it additional 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 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 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 of
 providers expected to be in each country.

5.0 Acknowledgments

 The editors would like to express our thanks to Jim Bound (Digital),
 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", 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 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
 Robert M. Hinden
 Ipsilon Networks, Inc.
 2191 E. Bayshore Road
 Palo Alto, CA 94303
 USA
 Phone: +1 415 846 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

Rekhter, et. al. Standards Track [Page 7]

/data/webs/external/dokuwiki/data/pages/rfc/rfc2073.txt · Last modified: 1997/01/07 01:07 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki