• 软件测试技术
  • 软件测试博客
  • 软件测试视频
  • 开源软件测试技术
  • 软件测试论坛
  • 软件测试沙龙
  • 软件测试资料下载
  • 软件测试杂志
  • 软件测试人才招聘
    暂时没有公告

字号: | 推荐给好友 上一篇 | 下一篇

RFC2471 - IPv6 Testing Address Allocation

发布: 2007-6-23 14:09 | 作者:   | 来源:   | 查看: 13次 | 进入软件测试论坛讨论

领测软件测试网

   
  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 RFC1897 "IPv6 Testing Address
Allocation", January 1996. RFC1897 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",
RFC2373, July 1998.

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

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

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

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

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

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC2119, 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.

延伸阅读

文章来源于领测软件测试网 https://www.ltesting.net/


关于领测软件测试网 | 领测软件测试网合作伙伴 | 广告服务 | 投稿指南 | 联系我们 | 网站地图 | 友情链接
版权所有(C) 2003-2010 TestAge(领测软件测试网)|领测国际科技(北京)有限公司|软件测试工程师培训网 All Rights Reserved
北京市海淀区中关村南大街9号北京理工科技大厦1402室 京ICP备2023014753号-2
技术支持和业务联系:info@testage.com.cn 电话:010-51297073

软件测试 | 领测国际ISTQBISTQB官网TMMiTMMi认证国际软件测试工程师认证领测软件测试网