RFC 2471 HISTORIC IPV6 · ADDRESSING · EXPERIMENTAL

IPv6 Testing Addresses: IPv6 Testing Address Allocation

Temporary IPv6 addresses for testing prototype software on the 6bone.

On rfc-editor.org ↗
PUBLISHED
December 1998
AUTHORS
R. Hinden, R. Fink, J. Postel
STREAM
IETF
BUILDS ON
RFC 1897 — IPv6 Testing Addresses
OBSOLETED BY
RFC 3701 — 6bone (IPv6 Testing Address Allocation) Phaseout
DOI
10.17487/RFC2471

RFC text

Contents
Original text · RFC Editor View on rfc-editor.org ↗
Network Working Group                                         R. Hinden
Request for Comments: 2471				          Nokia
Obsoletes: 1897                                                 R. Fink
Category: Experimental                                             LBNL
                                                              J. Postel
                                                                    ISI
                                                          December 1998


                    IPv6 Testing Address Allocation

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard of any kind.
   Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Copyright Notice

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

1.0 Introduction

   This document describes an allocation plan for IPv6 addresses to be
   used in testing IPv6 prototype software.  These addresses are
   temporary and will be reclaimed in the future.  Any IPv6 system using
   these addresses will have to renumber at some time in the future.
   These addresses will not to be routable in the Internet other than
   for IPv6 testing.

   The address format for the IPv6 test address is consistent with the
   "Aggregatable Global Unicast Address Allocation" [AGGR] and "TLA and
   NLA Assignment Rules" [TLAASN].

   This document is intended to replace RFC 1897 "IPv6 Testing Address
   Allocation", January 1996.  RFC 1897 will become historic.

   The addresses described in this document are consistent with the IPv6
   Addressing Architecture [ARCH].  They may be assigned to nodes
   manually, with IPv6 Auto Address Allocation [AUTO], or with DHCP for
   IPv6 [DHCPv6].

   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.0 Address Format

   The Aggregatable Global Unicast Address Allocation format defined in
   [AGGR] is as follows:

      | 3 |  13 |    32     |   16   |          64 bits               |
      +---+-----+-----------+--------+--------------------------------+
      |FP | TLA | NLA ID    | SLA ID |         Interface ID           |
      |   | ID  |           |        |                                |
      +---+-----+-----------+--------+--------------------------------+

   where:

      FP = 001 = Format Prefix

           This is the Format Prefix used to identify aggregatable
           global unicast addresses.

      TLA = 0x1FFE = Top-Level Aggregation Identifier

           This is a TLA ID assigned by the IANA for 6bone testing under
           the auspices of the IETF IPng Transition Working Group 6bone
           testbed activity.  It is to be administered by the chair of
           the 6bone activity (currently Bob Fink <rlfink@lbl.gov>).
           The use of this TLA ID is temporary.  All users of these
           addresses in this TLA ID will be required to renumber at some
           time in the future.

      NLA ID = Next-Level Aggregation Identifier

           The NLA ID space will be assigned, by the TLA ID
           administrator, in an addressing hierarchy sufficient to
           identify transit networks and end user sites consistent with
           the architecture and topology of the 6bone. This will provide
           a multi-level transit service consistent with the 6bone goals
           of fully testing IPv6 technology in real use environments.

      SLA ID = Site-Level Aggregation Identifier

           The SLA ID field is used by an individual organization to
           create its own local addressing hierarchy and to identify
           subnets.  Assignment of the SLA ID field is the
           responsibility of each individual organization.

      Interface ID

           This is the interface identifier of the interface on the link
           as defined in the appropriate IPv6 over <link> document, such
           as [ETHER], [FDDI], etc.

4.0 References

   [ARCH]    Hinden, R., "IP Version 6 Addressing Architecture",
             RFC 2373, July 1998.

   [AGGR]    Hinden, R., Deering, S., O'Dell, M., "An Aggregatable
             Global Unicast Address Format", RFC 2374, July 1998.

   [AUTO]    Thompson, S. and T. Narten, "IPv6 Stateless Address
             Autoconfiguration", RFC 1971, August 1996.

   [DHCP6]   Bound, J., "Host Configuration Protocol for IPv6", Work in
             Progress.

   [ETHER]   Crawford, M., "Transmission of IPv6 Packets over Ethernet
             Networks", RFC 2464, December 1998.

   [FDDI]    Crawford, M., "Transmission of IPv6 Packets over FDDI
             Networks", RFC 2467, December 1998.

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

   [TLAASN]  Hinden, R., "TLA and NLA Assignment Rules", Work in
             Progress.

5.0 Security Considerations

   This document defines a test approach for creating aggregatable
   address consistent with [AGGR].  It does not have any direct impact
   on Internet infrastructure security.  Authentication of IPv6 packets
   is defined in [AUTH].

6.0  Authors' Addresses

   Robert M. Hinden
   Nokia
   232 Java Drive
   Sunnyvale, CA 94089
   USA

   Phone: +1 408 990-2004
   EMail: hinden@iprg.nokia.com


   Robert Fink
   Lawrence Berkeley National Laboratory
   MS 50A-3111
   Berkeley, CA 94720
   USA

   Phone: +1 510 486-5692
   EMail: rlfink@lbl.gov


   Jon Postel (Deceased)
   Information Sciences Institute
   4676 Admiralty Way
   Marina del Rey, CA 90292-6695
   USA

7.0  Full Copyright Statement

   Copyright (C) The Internet Society (1998).  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.

ISO Plain Language

On this page
PROBLEMIPv6 prototype software needed an address allocation for testing that was separate from ordinary Internet routing.
MECHANISMThe RFC assigns the 6bone testbed a temporary TLA ID of 0x1FFE within the aggregatable global unicast address format.
WHY IT FADEDRFC 2471 is Historic and was replaced by RFC 3701; users of the temporary addresses were required to renumber.

§1.0Temporary Addresses for Testing

RFC 2471 describes an allocation plan for IPv6 addresses used to test prototype software. The addresses are temporary, will be reclaimed, and require systems using them to renumber in the future. They are not routable on the Internet except for IPv6 testing.

The address space is for IPv6 tests, not permanent network use. Systems using it must be ready to change addresses later.

§2.0The 6bone Address Format

The address format follows the aggregatable global unicast format. The RFC assigns TLA ID 0x1FFE for 6bone testing. The NLA ID identifies transit networks and end-user sites in the testbed hierarchy; each organization uses its SLA ID field to create a local hierarchy and identify subnets.

The address contains fields for the 6bone, network sites, local subnets, and an interface. Organizations manage their own site-level part.

§2.0Assignment and Renumbering

The 0x1FFE TLA ID is temporary and is administered by the chair of the 6bone activity. Addresses may be assigned manually, through IPv6 autoconfiguration, or with DHCP for IPv6. The RFC states that all users of the addresses will have to renumber at some time in the future.

The 6bone activity chair administers this temporary allocation. Users can configure addresses in several ways, but all must eventually renumber.