doc: Add RFC documents

1 files changed, 899 insertions, 0 deletions

diff --git a/doc/rfc/rfc4193.txt b/doc/rfc/rfc4193.txt
new file mode 100644
index 0000000..17e2c0b
--- /dev/null
+++ b/doc/rfc/rfc4193.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Network Working Group                                          R. Hinden
+Request for Comments: 4193                                         Nokia
+Category: Standards Track                                    B. Haberman
+                                                                 JHU-APL
+                                                            October 2005
+
+
+                  Unique Local IPv6 Unicast Addresses
+
+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.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document defines an IPv6 unicast address format that is globally
+   unique and is intended for local communications, usually inside of a
+   site.  These addresses are not expected to be routable on the global
+   Internet.
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Acknowledgements ................................................3
+   3. Local IPv6 Unicast Addresses ....................................3
+      3.1. Format .....................................................3
+           3.1.1. Background ..........................................4
+      3.2. Global ID ..................................................4
+           3.2.1. Locally Assigned Global IDs .........................5
+           3.2.2. Sample Code for Pseudo-Random Global ID Algorithm ...5
+           3.2.3. Analysis of the Uniqueness of Global IDs ............6
+      3.3. Scope Definition ...........................................6
+   4. Operational Guidelines ..........................................7
+      4.1. Routing ....................................................7
+      4.2. Renumbering and Site Merging ...............................7
+      4.3. Site Border Router and Firewall Packet Filtering ...........8
+      4.4. DNS Issues .................................................8
+      4.5. Application and Higher Level Protocol Issues ...............9
+      4.6. Use of Local IPv6 Addresses for Local Communication ........9
+      4.7. Use of Local IPv6 Addresses with VPNs .....................10
+
+
+
+Hinden & Haberman           Standards Track                     [Page 1]
+
+RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
+
+
+   5. Global Routing Considerations ..................................11
+      5.1. From the Standpoint of the Internet .......................11
+      5.2. From the Standpoint of a Site .............................11
+   6. Advantages and Disadvantages ...................................12
+      6.1. Advantages ................................................12
+      6.2. Disadvantages .............................................13
+   7. Security Considerations ........................................13
+   8. IANA Considerations ............................................13
+   9. References .....................................................13
+      9.1. Normative References ......................................13
+      9.2. Informative References ....................................14
+
+1.  Introduction
+
+   This document defines an IPv6 unicast address format that is globally
+   unique and is intended for local communications [IPV6].  These
+   addresses are called Unique Local IPv6 Unicast Addresses and are
+   abbreviated in this document as Local IPv6 addresses.  They are not
+   expected to be routable on the global Internet.  They are routable
+   inside of a more limited area such as a site.  They may also be
+   routed between a limited set of sites.
+
+   Local IPv6 unicast addresses have the following characteristics:
+
+      - Globally unique prefix (with high probability of uniqueness).
+
+      - Well-known prefix to allow for easy filtering at site
+        boundaries.
+
+      - Allow sites to be combined or privately interconnected without
+        creating any address conflicts or requiring renumbering of
+        interfaces that use these prefixes.
+
+      - Internet Service Provider independent and can be used for
+        communications inside of a site without having any permanent or
+        intermittent Internet connectivity.
+
+      - If accidentally leaked outside of a site via routing or DNS,
+        there is no conflict with any other addresses.
+
+      - In practice, applications may treat these addresses like global
+        scoped addresses.
+
+   This document defines the format of Local IPv6 addresses, how to
+   allocate them, and usage considerations including routing, site
+   border routers, DNS, application support, VPN usage, and guidelines
+   for how to use for local communication inside a site.
+
+
+
+
+Hinden & Haberman           Standards Track                     [Page 2]
+
+RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
+
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+2.  Acknowledgements
+
+   The underlying idea of creating Local IPv6 addresses described in
+   this document has been proposed a number of times by a variety of
+   people.  The authors of this document do not claim exclusive credit.
+   Credit goes to Brian Carpenter, Christian Huitema, Aidan Williams,
+   Andrew White, Charlie Perkins, and many others.  The authors would
+   also like to thank Brian Carpenter, Charlie Perkins, Harald
+   Alvestrand, Keith Moore, Margaret Wasserman, Shannon Behrens, Alan
+   Beard, Hans Kruse, Geoff Huston, Pekka Savola, Christian Huitema, Tim
+   Chown, Steve Bellovin, Alex Zinin, Tony Hain, Bill Fenner, Sam
+   Hartman, and Elwyn Davies for their comments and suggestions on this
+   document.
+
+3.  Local IPv6 Unicast Addresses
+
+3.1.  Format
+
+   The Local IPv6 addresses are created using a pseudo-randomly
+   allocated global ID.  They have the following format:
+
+      | 7 bits |1|  40 bits   |  16 bits  |          64 bits           |
+      +--------+-+------------+-----------+----------------------------+
+      | Prefix |L| Global ID  | Subnet ID |        Interface ID        |
+      +--------+-+------------+-----------+----------------------------+
+
+   Where:
+
+      Prefix            FC00::/7 prefix to identify Local IPv6 unicast
+                        addresses.
+
+      L                 Set to 1 if the prefix is locally assigned.
+                        Set to 0 may be defined in the future.  See
+                        Section 3.2 for additional information.
+
+      Global ID         40-bit global identifier used to create a
+                        globally unique prefix.  See Section 3.2 for
+                        additional information.
+
+      Subnet ID         16-bit Subnet ID is an identifier of a subnet
+                        within the site.
+
+      Interface ID      64-bit Interface ID as defined in [ADDARCH].
+
+
+
+
+Hinden & Haberman           Standards Track                     [Page 3]
+
+RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
+
+
+3.1.1.  Background
+
+   There were a range of choices available when choosing the size of the
+   prefix and Global ID field length.  There is a direct tradeoff
+   between having a Global ID field large enough to support foreseeable
+   future growth and not using too much of the IPv6 address space
+   needlessly.  A reasonable way of evaluating a specific field length
+   is to compare it to a projected 2050 world population of 9.3 billion
+   [POPUL] and the number of resulting /48 prefixes per person.  A range
+   of prefix choices is shown in the following table:
+
+    Prefix  Global ID     Number of          Prefixes    % of IPv6
+            Length        /48 Prefixes       per Person  Address Space
+
+    /11       37           137,438,953,472     15         0.049%
+    /10       38           274,877,906,944     30         0.098%
+    /9        39           549,755,813,888     59         0.195%
+    /8        40         1,099,511,627,776    118         0.391%
+    /7        41         2,199,023,255,552    236         0.781%
+    /6        42         4,398,046,511,104    473         1.563%
+
+   A very high utilization ratio of these allocations can be assumed
+   because the Global ID field does not require internal structure, and
+   there is no reason to be able to aggregate the prefixes.
+
+   The authors believe that a /7 prefix resulting in a 41-bit Global ID
+   space (including the L bit) is a good choice.  It provides for a
+   large number of assignments (i.e., 2.2 trillion) and at the same time
+   uses less than .8% of the total IPv6 address space.  It is unlikely
+   that this space will be exhausted.  If more than this were to be
+   needed, then additional IPv6 address space could be allocated for
+   this purpose.
+
+3.2.  Global ID
+
+   The allocation of Global IDs is pseudo-random [RANDOM].  They MUST
+   NOT be assigned sequentially or with well-known numbers.  This is to
+   ensure that there is not any relationship between allocations and to
+   help clarify that these prefixes are not intended to be routed
+   globally.  Specifically, these prefixes are not designed to
+   aggregate.
+
+   This document defines a specific local method to allocate Global IDs,
+   indicated by setting the L bit to 1.  Another method, indicated by
+   clearing the L bit, may be defined later.  Apart from the allocation
+   method, all Local IPv6 addresses behave and are treated identically.
+
+
+
+
+
+Hinden & Haberman           Standards Track                     [Page 4]
+
+RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
+
+
+   The local assignments are self-generated and do not need any central
+   coordination or assignment, but have an extremely high probability of
+   being unique.
+
+3.2.1.  Locally Assigned Global IDs
+
+   Locally assigned Global IDs MUST be generated with a pseudo-random
+   algorithm consistent with [RANDOM].  Section 3.2.2 describes a
+   suggested algorithm.  It is important that all sites generating
+   Global IDs use a functionally similar algorithm to ensure there is a
+   high probability of uniqueness.
+
+   The use of a pseudo-random algorithm to generate Global IDs in the
+   locally assigned prefix gives an assurance that any network numbered
+   using such a prefix is highly unlikely to have that address space
+   clash with any other network that has another locally assigned prefix
+   allocated to it.  This is a particularly useful property when
+   considering a number of scenarios including networks that merge,
+   overlapping VPN address space, or hosts mobile between such networks.
+
+3.2.2.  Sample Code for Pseudo-Random Global ID Algorithm
+
+   The algorithm described below is intended to be used for locally
+   assigned Global IDs.  In each case the resulting global ID will be
+   used in the appropriate prefix as defined in Section 3.2.
+
+     1) Obtain the current time of day in 64-bit NTP format [NTP].
+
+     2) Obtain an EUI-64 identifier from the system running this
+        algorithm.  If an EUI-64 does not exist, one can be created from
+        a 48-bit MAC address as specified in [ADDARCH].  If an EUI-64
+        cannot be obtained or created, a suitably unique identifier,
+        local to the node, should be used (e.g., system serial number).
+
+     3) Concatenate the time of day with the system-specific identifier
+        in order to create a key.
+
+     4) Compute an SHA-1 digest on the key as specified in [FIPS, SHA1];
+        the resulting value is 160 bits.
+
+     5) Use the least significant 40 bits as the Global ID.
+
+     6) Concatenate FC00::/7, the L bit set to 1, and the 40-bit Global
+        ID to create a Local IPv6 address prefix.
+
+   This algorithm will result in a Global ID that is reasonably unique
+   and can be used to create a locally assigned Local IPv6 address
+   prefix.
+
+
+
+Hinden & Haberman           Standards Track                     [Page 5]
+
+RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
+
+
+3.2.3.  Analysis of the Uniqueness of Global IDs
+
+   The selection of a pseudo random Global ID is similar to the
+   selection of an SSRC identifier in RTP/RTCP defined in Section 8.1 of
+   [RTP].  This analysis is adapted from that document.
+
+   Since Global IDs are chosen randomly (and independently), it is
+   possible that separate networks have chosen the same Global ID.  For
+   any given network, with one or more random Global IDs, that has
+   inter-connections to other such networks, having a total of N such
+   IDs, the probability that two or more of these IDs will collide can
+   be approximated using the formula:
+
+      P = 1 - exp(-N**2 / 2**(L+1))
+
+   where P is the probability of collision, N is the number of
+   interconnected Global IDs, and L is the length of the Global ID.
+
+   The following table shows the probability of a collision for a range
+   of connections using a 40-bit Global ID field.
+
+      Connections      Probability of Collision
+
+          2                1.81*10^-12
+         10                4.54*10^-11
+        100                4.54*10^-09
+       1000                4.54*10^-07
+      10000                4.54*10^-05
+
+   Based on this analysis, the uniqueness of locally generated Global
+   IDs is adequate for sites planning a small to moderate amount of
+   inter-site communication using locally generated Global IDs.
+
+3.3.  Scope Definition
+
+   By default, the scope of these addresses is global.  That is, they
+   are not limited by ambiguity like the site-local addresses defined in
+   [ADDARCH].  Rather, these prefixes are globally unique, and as such,
+   their applicability is greater than site-local addresses.  Their
+   limitation is in the routability of the prefixes, which is limited to
+   a site and any explicit routing agreements with other sites to
+   propagate them (also see Section 4.1).  Also, unlike site-locals, a
+   site may have more than one of these prefixes and use them at the
+   same time.
+
+
+
+
+
+
+
+Hinden & Haberman           Standards Track                     [Page 6]
+
+RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
+
+
+4.  Operational Guidelines
+
+   The guidelines in this section do not require any change to the
+   normal routing and forwarding functionality in an IPv6 host or
+   router.  These are configuration and operational usage guidelines.
+
+4.1.  Routing
+
+   Local IPv6 addresses are designed to be routed inside of a site in
+   the same manner as other types of unicast addresses.  They can be
+   carried in any IPv6 routing protocol without any change.
+
+   It is expected that they would share the same Subnet IDs with
+   provider-based global unicast addresses, if they were being used
+   concurrently [GLOBAL].
+
+   The default behavior of exterior routing protocol sessions between
+   administrative routing regions must be to ignore receipt of and not
+   advertise prefixes in the FC00::/7 block.  A network operator may
+   specifically configure prefixes longer than FC00::/7 for inter-site
+   communication.
+
+   If BGP is being used at the site border with an ISP, the default BGP
+   configuration must filter out any Local IPv6 address prefixes, both
+   incoming and outgoing.  It must be set both to keep any Local IPv6
+   address prefixes from being advertised outside of the site as well as
+   to keep these prefixes from being learned from another site.  The
+   exception to this is if there are specific /48 or longer routes
+   created for one or more Local IPv6 prefixes.
+
+   For link-state IGPs, it is suggested that a site utilizing IPv6 local
+   address prefixes be contained within one IGP domain or area.  By
+   containing an IPv6 local address prefix to a single link-state area
+   or domain, the distribution of prefixes can be controlled.
+
+4.2.  Renumbering and Site Merging
+
+   The use of Local IPv6 addresses in a site results in making
+   communication that uses these addresses independent of renumbering a
+   site's provider-based global addresses.
+
+   When merging multiple sites, the addresses created with these
+   prefixes are unlikely to need to be renumbered because all of the
+   addresses have a high probability of being unique.  Routes for each
+   specific prefix would have to be configured to allow routing to work
+   correctly between the formerly separate sites.
+
+
+
+
+
+Hinden & Haberman           Standards Track                     [Page 7]
+
+RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
+
+
+4.3.  Site Border Router and Firewall Packet Filtering
+
+   While no serious harm will be done if packets with these addresses
+   are sent outside of a site via a default route, it is recommended
+   that routers be configured by default to keep any packets with Local
+   IPv6 addresses from leaking outside of the site and to keep any site
+   prefixes from being advertised outside of their site.
+
+   Site border routers and firewalls should be configured to not forward
+   any packets with Local IPv6 source or destination addresses outside
+   of the site, unless they have been explicitly configured with routing
+   information about specific /48 or longer Local IPv6 prefixes.  This
+   will ensure that packets with Local IPv6 destination addresses will
+   not be forwarded outside of the site via a default route.  The
+   default behavior of these devices should be to install a "reject"
+   route for these prefixes.  Site border routers should respond with
+   the appropriate ICMPv6 Destination Unreachable message to inform the
+   source that the packet was not forwarded. [ICMPV6].  This feedback is
+   important to avoid transport protocol timeouts.
+
+   Routers that maintain peering arrangements between Autonomous Systems
+   throughout the Internet should obey the recommendations for site
+   border routers, unless configured otherwise.
+
+4.4.  DNS Issues
+
+   At the present time, AAAA and PTR records for locally assigned local
+   IPv6 addresses are not recommended to be installed in the global DNS.
+
+   For background on this recommendation, one of the concerns about
+   adding AAAA and PTR records to the global DNS for locally assigned
+   Local IPv6 addresses stems from the lack of complete assurance that
+   the prefixes are unique.  There is a small possibility that the same
+   locally assigned IPv6 Local addresses will be used by two different
+   organizations both claiming to be authoritative with different
+   contents.  In this scenario, it is likely there will be a connection
+   attempt to the closest host with the corresponding locally assigned
+   IPv6 Local address.  This may result in connection timeouts,
+   connection failures indicated by ICMP Destination Unreachable
+   messages, or successful connections to the wrong host.  Due to this
+   concern, adding AAAA records for these addresses to the global DNS is
+   thought to be unwise.
+
+   Reverse (address-to-name) queries for locally assigned IPv6 Local
+   addresses MUST NOT be sent to name servers for the global DNS, due to
+   the load that such queries would create for the authoritative name
+   servers for the ip6.arpa zone.  This form of query load is not
+   specific to locally assigned Local IPv6 addresses; any current form
+
+
+
+Hinden & Haberman           Standards Track                     [Page 8]
+
+RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
+
+
+   of local addressing creates additional load of this kind, due to
+   reverse queries leaking out of the site.  However, since allowing
+   such queries to escape from the site serves no useful purpose, there
+   is no good reason to make the existing load problems worse.
+
+   The recommended way to avoid sending such queries to nameservers for
+   the global DNS is for recursive name server implementations to act as
+   if they were authoritative for an empty d.f.ip6.arpa zone and return
+   RCODE 3 for any such query.  Implementations that choose this
+   strategy should allow it to be overridden, but returning an RCODE 3
+   response for such queries should be the default, both because this
+   will reduce the query load problem and also because, if the site
+   administrator has not set up the reverse tree corresponding to the
+   locally assigned IPv6 Local addresses in use, returning RCODE 3 is in
+   fact the correct answer.
+
+4.5.  Application and Higher Level Protocol Issues
+
+   Application and other higher level protocols can treat Local IPv6
+   addresses in the same manner as other types of global unicast
+   addresses.  No special handling is required.  This type of address
+   may not be reachable, but that is no different from other types of
+   IPv6 global unicast address.  Applications need to be able to handle
+   multiple addresses that may or may not be reachable at any point in
+   time.  In most cases, this complexity should be hidden in APIs.
+
+   From a host's perspective, the difference between Local IPv6 and
+   other types of global unicast addresses shows up as different
+   reachability and could be handled by default in that way.  In some
+   cases, it is better for nodes and applications to treat them
+   differently from global unicast addresses.  A starting point might be
+   to give them preference over global unicast, but fall back to global
+   unicast if a particular destination is found to be unreachable.  Much
+   of this behavior can be controlled by how they are allocated to nodes
+   and put into the DNS.  However, it is useful if a host can have both
+   types of addresses and use them appropriately.
+
+   Note that the address selection mechanisms of [ADDSEL], and in
+   particular the policy override mechanism replacing default address
+   selection, are expected to be used on a site where Local IPv6
+   addresses are configured.
+
+4.6.  Use of Local IPv6 Addresses for Local Communication
+
+   Local IPv6 addresses, like global scope unicast addresses, are only
+   assigned to nodes if their use has been enabled (via IPv6 address
+   autoconfiguration [ADDAUTO], DHCPv6 [DHCP6], or manually).  They are
+
+
+
+
+Hinden & Haberman           Standards Track                     [Page 9]
+
+RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
+
+
+   not created automatically in the way that IPv6 link-local addresses
+   are and will not appear or be used unless they are purposely
+   configured.
+
+   In order for hosts to autoconfigure Local IPv6 addresses, routers
+   have to be configured to advertise Local IPv6 /64 prefixes in router
+   advertisements, or a DHCPv6 server must have been configured to
+   assign them.  In order for a node to learn the Local IPv6 address of
+   another node, the Local IPv6 address must have been installed in a
+   naming system (e.g., DNS, proprietary naming system, etc.)  For these
+   reasons, controlling their usage in a site is straightforward.
+
+   To limit the use of Local IPv6 addresses the following guidelines
+   apply:
+
+      - Nodes that are to only be reachable inside of a site:  The local
+        DNS should be configured to only include the Local IPv6
+        addresses of these nodes.  Nodes with only Local IPv6 addresses
+        must not be installed in the global DNS.
+
+      - Nodes that are to be limited to only communicate with other
+        nodes in the site:  These nodes should be set to only
+        autoconfigure Local IPv6 addresses via [ADDAUTO] or to only
+        receive Local IPv6 addresses via [DHCP6].  Note: For the case
+        where both global and Local IPv6 prefixes are being advertised
+        on a subnet, this will require a switch in the devices to only
+        autoconfigure Local IPv6 addresses.
+
+      - Nodes that are to be reachable from inside of the site and from
+        outside of the site:  The DNS should be configured to include
+        the global addresses of these nodes.  The local DNS may be
+        configured to also include the Local IPv6 addresses of these
+        nodes.
+
+      - Nodes that can communicate with other nodes inside of the site
+        and outside of the site: These nodes should autoconfigure global
+        addresses via [ADDAUTO] or receive global address via [DHCP6].
+        They may also obtain Local IPv6 addresses via the same
+        mechanisms.
+
+4.7.  Use of Local IPv6 Addresses with VPNs
+
+   Local IPv6 addresses can be used for inter-site Virtual Private
+   Networks (VPN) if appropriate routes are set up.  Because the
+   addresses are unique, these VPNs will work reliably and without the
+   need for translation.  They have the additional property that they
+   will continue to work if the individual sites are renumbered or
+   merged.
+
+
+
+Hinden & Haberman           Standards Track                    [Page 10]
+
+RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
+
+
+5.  Global Routing Considerations
+
+   Section 4.1 provides operational guidelines that forbid default
+   routing of local addresses between sites.  Concerns were raised to
+   the IPv6 working group and to the IETF as a whole that sites may
+   attempt to use local addresses as globally routed provider-
+   independent addresses.  This section describes why using local
+   addresses as globally-routed provider-independent addresses is
+   unadvisable.
+
+5.1.  From the Standpoint of the Internet
+
+   There is a mismatch between the structure of IPv6 local addresses and
+   the normal IPv6 wide area routing model.  The /48 prefix of an IPv6
+   local addresses fits nowhere in the normal hierarchy of IPv6 unicast
+   addresses.  Normal IPv6 unicast addresses can be routed
+   hierarchically down to physical subnet (link) level and only have to
+   be flat-routed on the physical subnet.  IPv6 local addresses would
+   have to be flat-routed even over the wide area Internet.
+
+   Thus, packets whose destination address is an IPv6 local address
+   could be routed over the wide area only if the corresponding /48
+   prefix were carried by the wide area routing protocol in use, such as
+   BGP.  This contravenes the operational assumption that long prefixes
+   will be aggregated into many fewer short prefixes, to limit the table
+   size and convergence time of the routing protocol.  If a network uses
+   both normal IPv6 addresses [ADDARCH] and IPv6 local addresses, these
+   types of addresses will certainly not aggregate with each other,
+   since they differ from the most significant bit onwards.  Neither
+   will IPv6 local addresses aggregate with each other, due to their
+   random bit patterns.  This means that there would be a very
+   significant operational penalty for attempting to use IPv6 local
+   address prefixes generically with currently known wide area routing
+   technology.
+
+5.2.  From the Standpoint of a Site
+
+   There are a number of design factors in IPv6 local addresses that
+   reduce the likelihood that IPv6 local addresses will be used as
+   arbitrary global unicast addresses.  These include:
+
+      - The default rules to filter packets and routes make it very
+        difficult to use IPv6 local addresses for arbitrary use across
+        the Internet.  For a site to use them as general purpose unicast
+        addresses, it would have to make sure that the default rules
+        were not being used by all other sites and intermediate ISPs
+        used for their current and future communication.
+
+
+
+
+Hinden & Haberman           Standards Track                    [Page 11]
+
+RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
+
+
+      - They are not mathematically guaranteed to be unique and are not
+        registered in public databases.  Collisions, while highly
+        unlikely, are possible and a collision can compromise the
+        integrity of the communications.  The lack of public
+        registration creates operational problems.
+
+      - The addresses are allocated randomly.  If a site had multiple
+        prefixes that it wanted to be used globally, the cost of
+        advertising them would be very high because they could not be
+        aggregated.
+
+      - They have a long prefix (i.e., /48) so a single local address
+        prefix doesn't provide enough address space to be used
+        exclusively by the largest organizations.
+
+6.  Advantages and Disadvantages
+
+6.1.  Advantages
+
+   This approach has the following advantages:
+
+      - Provides Local IPv6 prefixes that can be used independently of
+        any provider-based IPv6 unicast address allocations.  This is
+        useful for sites not always connected to the Internet or sites
+        that wish to have a distinct prefix that can be used to localize
+        traffic inside of the site.
+
+      - Applications can treat these addresses in an identical manner as
+        any other type of global IPv6 unicast addresses.
+
+      - Sites can be merged without any renumbering of the Local IPv6
+        addresses.
+
+      - Sites can change their provider-based IPv6 unicast address
+        without disrupting any communication that uses Local IPv6
+        addresses.
+
+      - Well-known prefix that allows for easy filtering at site
+        boundary.
+
+      - Can be used for inter-site VPNs.
+
+      - If accidently leaked outside of a site via routing or DNS, there
+        is no conflict with any other addresses.
+
+
+
+
+
+
+
+Hinden & Haberman           Standards Track                    [Page 12]
+
+RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
+
+
+6.2.  Disadvantages
+
+   This approach has the following disadvantages:
+
+      - Not possible to route Local IPv6 prefixes on the global Internet
+        with current routing technology.  Consequentially, it is
+        necessary to have the default behavior of site border routers to
+        filter these addresses.
+
+      - There is a very low probability of non-unique locally assigned
+        Global IDs being generated by the algorithm in Section 3.2.3.
+        This risk can be ignored for all practical purposes, but it
+        leads to a theoretical risk of clashing address prefixes.
+
+7.  Security Considerations
+
+   Local IPv6 addresses do not provide any inherent security to the
+   nodes that use them.  They may be used with filters at site
+   boundaries to keep Local IPv6 traffic inside of the site, but this is
+   no more or less secure than filtering any other type of global IPv6
+   unicast addresses.
+
+   Local IPv6 addresses do allow for address-based security mechanisms,
+   including IPsec, across end to end VPN connections.
+
+8.  IANA Considerations
+
+   The IANA has assigned the FC00::/7 prefix to "Unique Local Unicast".
+
+9.  References
+
+9.1.  Normative References
+
+   [ADDARCH]  Hinden, R. and S. Deering, "Internet Protocol Version 6
+             (IPv6) Addressing Architecture", RFC 3513, April 2003.
+
+   [FIPS]    "Federal Information Processing Standards Publication",
+             (FIPS PUB) 180-1, Secure Hash Standard, 17 April 1995.
+
+   [GLOBAL]  Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global
+             Unicast Address Format", RFC 3587, August 2003.
+
+   [ICMPV6]  Conta, A. and S. Deering, "Internet Control Message
+             Protocol (ICMPv6) for the Internet Protocol Version 6
+             (IPv6) Specification", RFC 2463, December 1998.
+
+
+
+
+
+
+Hinden & Haberman           Standards Track                    [Page 13]
+
+RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
+
+
+   [IPV6]    Deering, S. and R. Hinden, "Internet Protocol, Version 6
+             (IPv6) Specification", RFC 2460, December 1998.
+
+   [NTP]     Mills, D., "Network Time Protocol (Version 3)
+             Specification, Implementation and Analysis", RFC 1305,
+             March 1992.
+
+   [RANDOM]  Eastlake, D., 3rd, Schiller, J., and S. Crocker,
+             "Randomness Requirements for Security", BCP 106, RFC 4086,
+             June 2005.
+
+   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+             Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [SHA1]    Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1
+             (SHA1)", RFC 3174, September 2001.
+
+9.2.  Informative References
+
+   [ADDAUTO] Thomson, S. and T. Narten, "IPv6 Stateless Address
+             Autoconfiguration", RFC 2462, December 1998.
+
+   [ADDSEL]  Draves, R., "Default Address Selection for Internet
+             Protocol version 6 (IPv6)", RFC 3484, February 2003.
+
+   [DHCP6]   Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and
+             M. Carney, "Dynamic Host Configuration Protocol for IPv6
+             (DHCPv6)", RFC 3315, July 2003.
+
+   [POPUL]   Population Reference Bureau, "World Population Data Sheet
+             of the Population Reference Bureau 2002",  August 2002.
+
+   [RTP]     Schulzrinne, H.,  Casner, S., Frederick, R., and V.
+             Jacobson, "RTP: A Transport Protocol for Real-Time
+             Applications", STD 64, RFC 3550, July 2003.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hinden & Haberman           Standards Track                    [Page 14]
+
+RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
+
+
+Authors' Addresses
+
+   Robert M. Hinden
+   Nokia
+   313 Fairchild Drive
+   Mountain View, CA 94043
+   USA
+
+   Phone: +1 650 625-2004
+   EMail: bob.hinden@nokia.com
+
+
+   Brian Haberman
+   Johns Hopkins University
+   Applied Physics Lab
+   11100 Johns Hopkins Road
+   Laurel, MD 20723
+   USA
+
+   Phone: +1 443 778 1319
+   EMail: brian@innovationslab.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hinden & Haberman           Standards Track                    [Page 15]
+
+RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Hinden & Haberman           Standards Track                    [Page 16]
+