rfc2073.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   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:  [phone]
   EMail:  [e-mail]

   Peter Lothberg
   STUPI.AB
   Box 9129
   S-102 72 Stockholm
   Sweden
   Phone:[phone]
   EMail: [e-mail]

   Robert M. Hinden
   Ipsilon Networks, Inc.
   2191 E. Bayshore Road
   Palo Alto, CA 94303
   USA
   Phone: [phone]
   EMail: [e-mail]

   Stephen E. Deering
   Xerox Palo Alto Research Center
   3333 Coyote Hill Road
   Palo Alto, CA 94304
   USA
   Phone: [phone]
   Fax:   [phone]
   EMail: [e-mail]

   Jon Postel
   Information Sciences Institute
   4676 Admiralty Way
   Marina del Rey, CA 90292-6695
   USA
   Phone: [phone]
   Fax:   [phone]
   EMail: [e-mail]




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