rfc3177.txt

RFC 的详细文档！


RFC 3177       IAB/IESG Recommendations on IPv6 Addresses September 2001


   More precisely,

      -  [RFC1715] defines an "H ratio" based on experience in address
         space assignment in various networks.  The H ratio varies
         between 0 and 0.3, with larger values denoting denser, more
         efficient assignment.  Experience shows that problems start to
         occur when the H ratio becomes greater than 0.25.  At an H
         ratio of 0.25, a 45 bit address space would have 178 billion
         (178 thousand million) identifiers.

            H = log10(178*10^9) / 45 = 0.25

         This means that we feel comfortable about the prospect of
         allocating 178 billions /48 prefixes under that scheme before
         problems start to appear.  To understand how big that number
         is, one has to compare 178 billion to 10 billion, which is the
         projected population on earth in year 2050 (see
         http://www.census.gov/ipc/www/world.html).  These numbers give
         no grounds for concern provided that the ISPs, under the
         guidance of the RIRs, allocate /48's prudently, and that the
         IETF refrains from new recommendations that further reduce the
         remaining 45 variable bits, unless a compelling requirement
         emerges.

      -  We are highly confident in the validity of this analysis, based
         on experience with IPv4 and several other address spaces, and
         on extremely ambitious scaling goals for the Internet amounting
         to an 80 bit address space *per person*.  Even so, being
         acutely aware of the history of under-estimating demand, the
         IETF has reserved more than 85% of the address space (i.e., the
         bulk of the space not under the 001 Global Unicast Address
         prefix).  Therefore, if the analysis does one day turn out to
         be wrong, our successors will still have the option of imposing
         much more restrictive allocation policies on the remaining 85%.
         However, we must stress that vendors should not encode any of
         the boundaries discussed here either in software nor hardware.
         Under that assumption, should we ever have to use the remaining
         85% of the address space, such a migration may not be devoid of
         pain, but it should be far less disruptive than deployment of a
         new version of IP.

   To summarize, we argue that although careful stewardship of IPv6
   address space is essential, this is completely compatible with the
   convenience and simplicity of a uniform prefix size for IPv6 sites of
   any size.  The numbers are such that there seems to be no objective
   risk of running out of space, giving an unfair amount of space to
   early customers, or of getting back into the over-constrained IPv4




IAB & IESG                   Informational                      [Page 6]

RFC 3177       IAB/IESG Recommendations on IPv6 Addresses September 2001


   situation where address conservation and route aggregation damage
   each other.

5. Multihoming Issues

   In the realm of multi-homed networks, the techniques used in IPv4 can
   all be applied, but they have known scaling problems.  Specifically,
   if the same prefix is advertised by multiple ISPs, the routing
   information will grow as a function of the number of multihomed
   sites.  To go beyond this for IPv6, we only have initial proposals on
   the table at this time, and active work is under way in the IETF IPNG
   and Multi6 working groups.  Until current or new proposals become
   more fully developed, existing techniques known to work in IPv4 will
   continue to be used in IPv6.

   Key characteristics of an ideal multi-homing proposal include (at
   minimum) that it provides routing connectivity to any multi-homed
   network globally, conserves address space, produces high quality
   routes via any of the network's providers, enables a multi-homed
   network to connect to multiple ISPs, does not unintentionally bias
   routing to use any proper subset of those networks, does not damage
   route aggregation, and scales to very large numbers of multi-homed
   networks.

   One class of solutions being considered amounts to permanent parallel
   running of two (or more) prefixes per site.  In the absence of a
   fixed prefix boundary, such a site might be required to have multiple
   different internal subnet numbering strategies, (one for each prefix
   length) or, if it only wanted one, be forced to use the most
   restrictive one as defined by the longest prefix it received from any
   of its ISPs.  In this approach, a multi-homed network would have an
   address block from each of its upstream providers.  Each host would
   either have exactly one address picked from the set of upstream
   providers, or one address per host from each of the upstream
   providers.  The first case is essentially a variant on [RFC2260],
   with known scaling limits.

   In the second case (multiple addresses per host), if two multi-homed
   networks communicate, having respectively M and N upstream providers,
   then the one initiating the connection will select one address pair
   from the N*M potential address pairs to connect between, and in so
   doing will select the providers, and therefore the applicable route,
   for the life of the connection.  Given that each path will have a
   different available bit rate, loss rate, and delay, if neither host
   is in possession of any routing or metric information, the initiating
   host has only a 1/(M*N) probability of selecting the optimal address
   pair.  Work on better-than-random address selection is in progress in
   the IETF, but is incomplete.



IAB & IESG                   Informational                      [Page 7]

RFC 3177       IAB/IESG Recommendations on IPv6 Addresses September 2001


   The existing IPv4 Internet shows us that a network prefix which is
   independent of, and globally advertised to, all upstream providers
   permits the routing system to select a reasonably good path within
   the applicable policy.  Present-day routing policies are not QoS
   policies but reachability policies, which means that they will not
   necessarily select the optimal delay, bit rate, or loss rate, but the
   route will be the best within the metrics that are in use.  One may
   therefore conclude that this would work correctly for IPv6 networks
   as well, apart from scaling issues.

6. Security Considerations

   This document does not have any security implications.

7. Acknowledgments

   This document originated from the IETF IPv6 directorate, with much
   input from the IAB and IESG.  The original text forming the basis of
   this document was contributed by Fred Baker and Brian Carpenter.
   Allison Mankin and Thomas Narten merged the original contributions
   into a single document, and Alain Durand edited the document through
   its final stages.

8. References

   [RFC1715]   Huitema, C., "The H Ratio for Address Assignment
               Efficiency", RFC 1715, November 1994.

   [RFC2026]   Bradner, S., "The Internet Standards Process -- Revision
               3", BCP 9, RFC 2026, October 1996.

   [RFC2260]   Bates, T. and Y. Rekhter, "Scalable Support for Multi-
               homed Multi-provider Connectivity", RFC 2260, January
               1998.

   [RFC2374]   Hinden, R., O'Dell, M. and S. Deering, "An IPv6
               Aggregatable Global Unicast Address Format", RFC 2374,
               July 1998.

   [RFC2450]   Hinden, R., "Proposed TLA and NLA Assignment Rule", RFC
               2450, December 1998.

   [RFC2462]   Thompson, S. and T. Narten, "IPv6 Stateless Address
               Autoconfiguration", RFC 2462, December 1998.

   [RFC2874]   Crawford, M. and C. Huitema, "DNS Extensions to Support
               IPv6 Address Aggregation and Renumbering", RFC 2874, July
               2000.



IAB & IESG                   Informational                      [Page 8]

RFC 3177       IAB/IESG Recommendations on IPv6 Addresses September 2001


   [RFC3041]   Narten, T. and R. Draves, "Privacy Extensions for
               Stateless Address Autoconfiguration in IPv6", RFC 3041,
               January 2001.

   [MobIPv6]  Johnson, D. and C. Perkins, "Mobility Support in IPv6",
               Work in Progress.

9.  Authors Address

   Internet Architecture Board

   Email: [e-mail]


   Internet Engineering Steering Group

   Email: [e-mail]


































IAB & IESG                   Informational                      [Page 9]

RFC 3177       IAB/IESG Recommendations on IPv6 Addresses September 2001


10.  Full Copyright Statement

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















IAB & IESG                   Informational                     [Page 10]