rfc4193.txt

来自「非常好的dns解析软件」· 文本 代码 · 共 900 行 · 第 1/3 页

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


   Brian Haberman
   Johns Hopkins University
   Applied Physics Lab
   11100 Johns Hopkins Road
   Laurel, MD 20723
   USA

   Phone: [phone]
   EMail: [e-mail]






























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-
   [e-mail].

Acknowledgement

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







Hinden & Haberman           Standards Track                    [Page 16]