Network Working Group                                        M. Blanchet
Internet-Draft                                                  Viagenie
Expires: November 5, 2001                                    May 6, 2001


      IPv6 Test Address Space Reserved for Documentation, Examples and
                              Private Testing
                        draft-blanchet-ipngwg-testadd-00

Status of this Memo

     This document is an Internet-Draft and is in full conformance with
     all provisions of Section 10 of RFC2026.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF), its areas, and its working groups. Note that
     other groups may also distribute working documents as
     Internet-Drafts.

     Internet-Drafts are draft documents valid for a maximum of six
     months and may be updated, replaced, or obsoleted by other documents
     at any time. It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     The list of current Internet-Drafts can be accessed at
     http://www.ietf.org/1id-abstracts.html

     The list of Internet-Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html.

     This Internet-Draft will expire on November 5, 2001.

Copyright Notice

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

Abstract

     To reduce the likelihood of conflict and confusion, an IPv6 prefix
     is reserved for use in private testing or as examples in other RFCs,
     documentation, and the like. Since site local addresses have special
     meaning in IPv6, these cannot be used in many example situations and
     are confusing.  Instead, an IPv6 prefix is reserved in the range of
     the test address space.


1. Rationale

     IPv6 introduces many types of addresses in its addressing
     architecture RFC 2373[1], like scoped addresses (link-local,
     site-local) and global addresses.  It also introduces mechanisms for
     renumbering RFC 2462[2],RFC 2894[5]. Organisations might want to
     make tests networks, using the different kinds of addresses and try
     renumbering.  For example, one could have site-local as well as a
     global prefix and try to renumber to another global prefix while
     preserving its site-local addresses live. RFCs, vendor
     documentation, books and the like also give examples with addresses.
     Authors always have an issue of using: already allocated addresses,
     not currently allocated addresses or private (site-local) addresses
     in their examples. Using the configuration examples in a real
     environment can cause a problem. If the example uses site-local as
     global address example, then the actual mechanism for handling
     scoped addresses with site-local scoping can not be done. If
     allocated addresses are used, then this obviously can make address
     spoofing inadvertly if the environment is connected to the internet.
     Same could happen later for a non-currently allocated address space
     that becomes allocated. Similar, but different, discussion also
     applies to top level domain names and some have been reserved for
     the same purposes RFC 2606[4].


2. Assignment

     The prefix 3ffe:ff00/24, out of the test address spaceRFC 2471[3].
     currently used on the 6bone is reserved for any documentation or
     private testing purposes.  The 6bone will never use that prefix.


3. IANA Considerations

     IANA reserve 3ffe:ff00/24 address space out of the test address
     space so that no one will ever receive this allocation.


4. Security Considerations

     This document encourages the use of test addresses in private
     testing and documentation so that less issues will arise from people
     that could instead use address space already allocated or to be
     allocated in the future.  These could cause ip address spoofing.
     This proposal minimize such possible conflicts.


References

     [1]  Hinden, R.M. and S.E. Deering, "IP Version 6 Addressing
          Architecture", RFC 2373, July 1998.

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

     [3]  Hinden, R.M., Fink, R. and J. Postel, "IPv6 Testing Address
          Allocation", RFC 2471, December 1998.

     [4]  Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names", BCP
          32, RFC 2606, June 1999.

     [5]  Crawford, M., "Router Renumbering for IPv6", RFC 2894, August
          2000.

Author's Address

     Marc Blanchet
     Viagenie
     2875 boul. Laurier, bureau 300
     Sainte-Foy, QC  G1V 2M2
     Canada

     Phone: +1 418 656 9254
     EMail: Marc.Blanchet@viagenie.qc.ca
     URI:   http://www.viagenie.qc.ca/



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 implmentation 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.