RFC 
 2471 
 TOC 
Network Working GroupR. Hinden
Request for Comments: 2471Nokia
Obsoletes: 1897R. Fink
Category: ExperimentalLawrence Berkeley National
 Laboratory
 J. Postel
 Information Sciences Institute
 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 © The Internet Society (1998). All Rights Reserved.


 RFC 
 2471 
 TOC 

Table of Contents

1.  Introduction
2.  Address Format
3.  References (BOILERPLATE)
4.  Security Considerations
5.  Authors' Addresses (BOILERPLATE)
6.  Full Copyright Statement (BOILERPLATE)
7.  References
§  Authors' Addresses
§  Intellectual Property and Copyright Statements




 TOC 

1.  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" [RFC2374] (Hinden, R. and S. Deering, “An IPv6 Aggregatable Global Unicast Address Format,” July 1998.) and "TLA and NLA Assignment Rules" [_XREF_TLAASN] (Hinden, R., “TLA and NLA Assignment Rules,” .).

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 [RFC2373] (Hinden, R. and S. Deering, “IP Version 6 Addressing Architecture,” July 1998.). They may be assigned to nodes manually, with IPv6 Auto Address Allocation [RFC1971] (Thomson, S. and T. Narten, “IPv6 Stateless Address Autoconfiguration,” August 1996.), 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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).



 TOC 

2.  Address Format

The Aggregatable Global Unicast Address Allocation format defined in [RFC2374] (Hinden, R. and S. Deering, “An IPv6 Aggregatable Global Unicast Address Format,” July 1998.) 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 [RFC2464] (Crawford, M., “Transmission of IPv6 Packets over Ethernet Networks,” December 1998.), [RFC2467] (Crawford, M., “Transmission of IPv6 Packets over FDDI Networks,” December 1998.), etc.



 TOC 

3.  References (BOILERPLATE)

This RFC contained boilerplate in this section which has been moved to the RFC2223-compliant unnumbered section "References."



 TOC 

4.  Security Considerations

This document defines a test approach for creating aggregatable address consistent with [RFC2374] (Hinden, R. and S. Deering, “An IPv6 Aggregatable Global Unicast Address Format,” July 1998.). It does not have any direct impact on Internet infrastructure security. Authentication of IPv6 packets is defined in [AUTH].



 TOC 

5.  Authors' Addresses (BOILERPLATE)

This RFC contained boilerplate in this section which has been moved to the RFC2223-compliant unnumbered section "Author's Address."



 TOC 

6.  Full Copyright Statement (BOILERPLATE)

This RFC contained boilerplate in this section which has been moved to the RFC2223-compliant unnumbered section "Full Copyright Statement."



 TOC 

7. References

[RFC2373] Hinden, R. and S. Deering, “IP Version 6 Addressing Architecture,” RFC 2373, July 1998 (TXT, HTML, XML).
[RFC2374] Hinden, R. and S. Deering, “An IPv6 Aggregatable Global Unicast Address Format,” RFC 2374, July 1998 (TXT, HTML, XML).
[RFC1971] Thomson, S. and T. Narten, “IPv6 Stateless Address Autoconfiguration,” RFC 1971, August 1996 (TXT).
[_XREF_DHCP6] Bound, J., “Host Configuration Protocol for IPv6.”
[RFC2464] Crawford, M., “Transmission of IPv6 Packets over Ethernet Networks,” RFC 2464, December 1998 (TXT, HTML, XML).
[RFC2467] Crawford, M., “Transmission of IPv6 Packets over FDDI Networks,” RFC 2467, December 1998 (TXT, HTML, XML).
[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[_XREF_TLAASN] Hinden, R., “TLA and NLA Assignment Rules.”


 TOC 

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
  Information Sciences Institute
  4676 Admiralty Way
  Marina del Rey, CA 90292-6695
  USA


 TOC 

Full Copyright Statement

Intellectual Property