doc: Add RFC documents

1 files changed, 563 insertions, 0 deletions

diff --git a/doc/rfc/rfc3177.txt b/doc/rfc/rfc3177.txt
new file mode 100644
index 0000000..491647f
--- /dev/null
+++ b/doc/rfc/rfc3177.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group                                                IAB
+Request for Comments: 3177                                          IESG
+Category: Informational                                   September 2001
+
+
+     IAB/IESG Recommendations on IPv6 Address Allocations to Sites
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+Abstract
+
+   This document provides recommendations to the addressing registries
+   (APNIC, ARIN and RIPE-NCC) on policies for assigning IPv6 address
+   blocks to end sites.  In particular, it recommends the assignment of
+   /48 in the general case, /64 when it is known that one and only one
+   subnet is needed and /128 when it is absolutely known that one and
+   only one device is connecting.
+
+   The original recommendations were made in an IAB/IESG statement
+   mailed to the registries on September 1, 2000.  This document refines
+   the original recommendation and documents it for the historical
+   record.
+
+1. Introduction
+
+   There have been many discussions between IETF and RIR experts on the
+   topic of IPv6 address allocation policy.  This memo addresses the
+   issue of the boundary in between the public and the private topology
+   in the Internet, that is, how much address space should an ISP
+   allocate to homes, small and large enterprises, mobile networks and
+   transient customers.
+
+   This document does not address the issue of the other boundaries in
+   the public topology, that is, between the RIRs and the LIRs.
+
+   This document was developed by the IPv6 Directorate, IAB and IESG,
+   and is a recommendation from the IAB and IESG to the RIRs.
+
+
+
+
+
+
+IAB & IESG                   Informational                      [Page 1]
+
+RFC 3177       IAB/IESG Recommendations on IPv6 Addresses September 2001
+
+
+2. Background
+
+   The technical principles that apply to address allocation seek to
+   balance healthy conservation practices and wisdom with a certain ease
+   of access.  On one hand, when managing a potentially limited
+   resource, one must conserve wisely to prevent exhaustion within an
+   expected lifetime.  On the other hand, the IPv6 address space is in
+   no sense as limited a resource as the IPv4 address space, and
+   unwarranted conservatism acts as a disincentive in a marketplace
+   already dampened by other factors.  So from a market development
+   perspective, we would like to see it be very easy for a user or an
+   ISP to obtain as many IPv6 addresses as they really need without a
+   prospect of immediate renumbering or of scaling inefficiencies.
+
+   The IETF makes no comment on business issues or relationships.
+   However, in general, we observe that technical delegation policy can
+   have strong business impacts.  A strong requirement of the address
+   delegation plan is that it not be predicated on or unduly bias
+   business relationships or models.
+
+   The IPv6 address, as currently defined, consists of 64 bits of
+   "network number" and 64 bits of "host number".  The technical reasons
+   for this are several.  The requirements for IPv6 agreed to in 1993
+   included a plan to be able to address approximately 2^40 networks and
+   2^50 hosts; the 64/64 split effectively accomplishes this.
+   Procedures used in host address assignment, such as the router
+   advertisement of a network's prefix to hosts [RFC2462], which in turn
+   place a locally unique number in the host portion, depend on this
+   split.  Subnet numbers must be assumed to come from the network part.
+   This is not to preclude routing protocols such as IS-IS level 1
+   (intra-area) routing, which routes individual host addresses, but
+   says that it may not be depended upon in the world outside that zone.
+   The 64-bit host field can also be used with EUI-64 for a flat,
+   uniquely allocated space, and therefore it may not be globally
+   treated as a subnetting resource.  Those concerned with privacy
+   issues linked to the presence of a globally unique identifier may
+   note that 64 bits makes a large enough field to maintain excellent
+   random-number-draw properties for self-configured End System
+   Designators.  That alternative construction of this 64-bit host part
+   of an IPv6 address is documented in [RFC3041].
+
+   While the IETF has also gone to a great deal of effort to minimize
+   the impacts of network renumbering, renumbering of IPv6 networks is
+   neither invisible nor completely painless.  Therefore, renumbering
+   should be considered a tolerable event, but to be avoided if
+   reasonably feasible.
+
+
+
+
+
+IAB & IESG                   Informational                      [Page 2]
+
+RFC 3177       IAB/IESG Recommendations on IPv6 Addresses September 2001
+
+
+   In [RFC2374] and [RFC2450], the IETF's IPNG working group has
+   recommended that the address block given to a single edge network
+   which may be recursively subnetted be a 48-bit prefix.  This gives
+   each such network 2^16 subnet numbers to use in routing, and a very
+   large number of unique host numbers within each network.  This is
+   deemed to be large enough for most enterprises, and to leave plenty
+   of room for delegation of address blocks to aggregating entities.
+
+   It is not obvious, however, that all edge networks are likely to be
+   recursively subnetted; a single PC in a home or a telephone in a
+   mobile cellular network, for example, may or may not interface to a
+   subnetted local network.  When a network number is delegated to a
+   place that will not require subnetting, therefore, it might be
+   acceptable for an ISP to give a single 64-bit prefix - perhaps shared
+   among the dial-in connections to the same ISP router.  However this
+   decision may be taken in the knowledge that there is objectively no
+   shortage of /48s, and the expectation that personal, home networks
+   will become the norm.  Indeed, it is widely expected that all IPv6
+   subscribers, whether domestic (homes), mobile (vehicles or
+   individuals), or enterprises of any size, will eventually possess
+   multiple always-on hosts, at least one subnet with the potential for
+   additional subnetting, and therefore some internal routing
+   capability.  In other words the subscriber allocation unit is not
+   always a host; it is always potentially a site.  The question this
+   memo is addressing is how much address space should be delegated to
+   such sites.
+
+3. Address Delegation Recommendations
+
+   The IESG and the IAB recommend the allocations for the boundary
+   between the public and the private topology to follow those general
+   rules:
+
+      -  /48 in the general case, except for very large subscribers.
+      -  /64 when it is known that one and only one subnet is needed by
+         design.
+      -  /128 when it is absolutely known that one and only one device
+         is connecting.
+
+   In particular, we recommend:
+
+      -  Home network subscribers, connecting through on-demand or
+         always-on connections should receive a /48.
+      -  Small and large enterprises should receive a /48.
+      -  Very large subscribers could receive a /47 or slightly shorter
+         prefix, or multiple /48's.
+
+
+
+
+
+IAB & IESG                   Informational                      [Page 3]
+
+RFC 3177       IAB/IESG Recommendations on IPv6 Addresses September 2001
+
+
+      -  Mobile networks, such as vehicles or mobile phones with an
+         additional network interface (such as bluetooth or 802.11b)
+         should receive a static /64 prefix to allow the connection of
+         multiple devices through one subnet.
+      -  A single PC, with no additional need to subnet, dialing-up from
+         a hotel room may receive its /128 IPv6 address for a PPP style
+         connection as part of a /64 prefix.
+
+   Note that there seems to be little benefit in not giving a /48 if
+   future growth is anticipated.  In the following, we give the
+   arguments for a uniform use of /48 and then demonstrate that it is
+   entirely compatible with responsible stewardship of the total IPv6
+   address space.
+
+   The arguments for the fixed boundary are:
+
+      -  That only by having a provider-independent boundary can we
+         guarantee that a change of ISP will not require a costly
+         internal restructuring or consolidation of subnets.
+
+      -  That during straightforward site renumbering from one prefix to
+         another the whole process, including parallel running of the
+         two prefixes, would be greatly complicated if the prefixes had
+         different lengths (depending of course on the size and
+         complexity of the site).
+
+      -  There are various possible approaches to multihoming for IPv6
+         sites, including the techniques already used for IPv4
+         multihoming.  The main open issue is finding solutions that
+         scale massively without unduly damaging route aggregation
+         and/or optimal route selection.  Much more work remains to be
+         done in this area, but it seems likely that several approaches
+         will be deployed in practice, each with their own advantages
+         and disadvantages.  Some (but not all) will work better with a
+         fixed prefix boundary.  (Multihoming is discussed in more
+         detail below.)
+
+      -  To allow easy growth of the subscribers' networks without need
+         to go back to ISPs for more space (except for that relatively
+         small number of subscribers for which a /48 is not enough).
+
+      -  To remove the burden from the ISPs and registries of judging
+         sites' needs for address space, unless the site requests more
+         space than a /48.  This carries several advantages:
+
+         -  It may become less critical for ISPs to be able to maintain
+            detailed knowledge of their customers' network architecture
+            and growth plans,
+
+
+
+IAB & IESG                   Informational                      [Page 4]
+
+RFC 3177       IAB/IESG Recommendations on IPv6 Addresses September 2001
+
+
+         -  ISPs and registries may reduce the effort spent on assessing
+            rates of address consumption, with address space ample for
+            long-term growth plans,
+         -  Registry operations may be made more efficient or more
+            focused, by reducing the urgency of tracking and assessment.
+         -  Address space will no longer be a precious resource for
+            customers, removing the major incentive for subscribers to
+            install v6/v6 NATs, which would defeat the IPv6 restoration
+            of address transparency.
+
+      -  To allow the site to maintain a single reverse-DNS zone
+         covering all prefixes.
+
+      -  If and only if a site can use the same subnetting structure
+         under each of its prefixes, then it can use the same zone file
+         for the address-to-name mapping of all of them.  And, using the
+         conventions of [RFC2874], it can roll the reverse mapping data
+         into the "forward" (name-keyed) zone.
+
+   Specific advantages of the fixed boundary being at /48 include
+
+      -  To leave open the technical option of retro-fitting the GSE
+         (Global, Site and End-System Designator, a.k.a., "8+8")
+         proposal for separating locators and identifiers, which assumes
+         a fixed boundary between global and site addressing at /48.
+         Although the GSE technique was deferred a couple of years ago,
+         it still has strong proponents.  Also, the IRTF Namespace
+         Research Group is actively looking into topics closely related
+         to GSE.  It is still possible that GSE or a derivative of GSE
+         will be used with IPv6 in the future.
+
+      -  Since the site-local prefix is fec0::/48, global site prefixes
+         of /48 will allow sites to easily maintain a trivial (identity)
+         mapping between the global topology and the site-local topology
+         in the SLA field.
+
+      -  Similarly, if the 6to4 proposal is widely deployed, migration
+         from a 6to4 prefix, which is /48 by construction, to a native
+         IPv6 prefix will be simplified if the native prefix is /48.
+
+4. Conservation of Address Space
+
+   The question naturally arises whether giving a /48 to every
+   subscriber represents a profligate waste of address space.  Objective
+   analysis shows that this is not the case.  A /48 prefix under the 001
+   Global Unicast Address prefix contains 45 variable bits.  That is,
+   the number of available prefixes is 2 to the power 45 or about 35
+   trillion (35,184,372,088,832).
+
+
+
+IAB & IESG                   Informational                      [Page 5]
+
+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: iab@iab.org
+
+
+   Internet Engineering Steering Group
+
+   Email: iesg@ietf.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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]
+