diff options
Diffstat (limited to 'doc/rfc/rfc4193.txt')
| -rw-r--r-- | doc/rfc/rfc4193.txt | 899 |
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] + |