rfc2374.txt

RFC规范的翻译稿

许较大集聚数，从而使得路由表较小。平面NLA ID 的分配能使分配容易和连接灵活，但
使得路由表较大。
3.5 站点级集聚标识符
SLA ID 字段被单个机构用来创建他自己的本地寻址分级结构与标识子网。除了每个机
构有一个数量很大的子网以外，类似于I P v 4 中的子网。1 6 位的SLA ID 字段支持65 535 
个单个子网。
机构可以选择他们的SLA ID 为平面路由(如在S L A 标识符之间不创建任何逻辑关系，
这会使得路由表较大)，或者在SLA ID 字段中，创建一个两级或多级分级结构(使路由表较
小)。后一种情况表示如下：

   |  n  |   16-n     |               64 位                 |
   +-----+------------+-------------------------------------+
   |SLA1 |    子网    |              接口 ID                |
   +-----+------------+-------------------------------------+

         | m  |16-n-m |               64 位                 |
         +----+-------+-------------------------------------+
         |SLA2|  子网 |               接口 ID               |
         +----+-------+-------------------------------------+

构成SLA ID 字段所选择的方法，由个别机构负责。
在这种地址格式下支持的子网数，除了最大的机构之外，对其他所有机构应该是足够的。
对于需要更多子网的组织，可以和它获得I n t e r n e t 服务的机构商量，以获得附加的站点
标识符，从而用来创建更多的子网。
3.6 接口ID
接口标识符用来标识一条链路上的接口。对链路来说，应该是唯一的。也可以在一个更
宽的范围内是唯一的。许多情况下，一个接口标识符与接口的链路层地址相同，或者根据接
口的链路层地址而得的。用在可集聚全球单播地址格式中的接口标识符要求6 4 位长，并能
构成IEEE EUI-64 格式[ E U I - 6 4 ] 。这些标识符，当全球令牌(如IEEE 48 位M A C )可
用时，具有全球范围意义；当全球令牌不可用时(如串行链路、隧道终点等)，则只具有本地
范围意义。u 位(在IEEE EUI-64 术语中称为全球/本地位)在E U I - 6 4 标识符中必须根据
[ A R C H ]的规定，正确地置位以指示是全球还是本地范围。
创建基于E U I - 6 4 接口标识符的过程定义见[ A R C H ]。形成接口标识符的细节，规
定在相应的IPv6 over<link>技术规范中，诸如IPv6 over Ethernet【 E T H E R 】 ，IPv6 over FDDI
【 F D D I 】 等。
4. 技术动机
在可集聚的地址格式中，字段长度的设计选择需要满足许多技术需求。这些将在下面段
落中介绍。
顶级集聚标识符的长度是1 3 位。可有8 1 9 2 个TLA ID 。选择这样的长度，可使I n 
t e r n e t 上顶级路由器的非默认路由表，能在当前的选路技术且合理地留有余量的情况下，
保持有限的范围。
因为非默认路由器为优化T L A 内部路径和T L A 之间的路径，还要含有大量的长的
前缀，所以保留余量是重要的。
重要的议题不仅是非默认选路表的长度问题，还有拓扑的复杂性决定了当计算一个转发
表时，路由器必须考察非默认路由的拷贝数。当前I P v 4 的实践是通常一个前缀要通过不
同的路径通告1 5 次。
I n t e r n e t 拓扑的复杂性将来还可能增加。重要的是I P v 6 非默认选路应支持更大的
复杂性以及巨大的I n t e r n e t 。
应该提出的是，在写作本文时( 1 9 9 8 年春)，作者作了一个比较，I P v 4 非默认路由
表包含大约50 000 个前缀，表示可能支持大于8 1 9 2 个的路由。现在争论的问题是在当前
的选路技术下，是否I P v 4 目前支持的前缀数已经足够多了。一些需要认真考虑的议题是
路由稳定性以及供应商不支持所有顶级前缀的情况。技术上要求挑选TLA ID 的长度，在考
虑合理余量的情况下，低于I P v 4 所具有的。
选择TLA ID 字段为1 3 位是出于工程的综合考虑。位数太少将不足以支持足够的顶级
组织，位数太多将会超过合理协调的能力。为了处理前面所提到的议题，用当前的选路技术
考虑一个合理的余量是合适的。
如果将来选路技术改进到在非默认路由表中能支持大量的顶级路由，那么如何加大T L 
A标识符，就有两种选择：第一种是扩大TLA ID 字段占用保留字数，这将使TLA ID 数大
约增加二百万个；第二种途径是为这样的地址格式分配另一个格式前缀( F P )。或者将这两
种途径组合，使TLA ID 数量大大地增加。
保留字段的长度为8 位，是为了使TLA ID 字段和NLA ID 字段有大的增长余地。
下一级集聚标识符的长度为2 4 位。如果用平面结构的话，可容纳大约1 6 0 0 万个NLA 
ID 。如果分级使用的话，合成起来大致等效于I P v 4 的地址空间(假定平均网络规模为2 5 
4 个接口)。如果NLA ID 将来需要更多的空间，那么可以将NLA ID 扩展到保留字段来协
调。
站点级集聚标识符字段的长度是1 6 位。每个站点可支持65 535 个子网。本字段长度
的设计目标，对除了最大组织以外的所有组织是足够的。对于需要更多子网的组织，可以和
它获得I n t e r n e t 服务的机构商量，以得到附加的站点标识符，从而用来创建更多的子网。
站点集聚标识符字段是固定长度，这是为了强制标识特定站点的所有前缀，具有同样的
长度(即4 8 位)。这样会方便站点在拓扑中的移动(如变更I S P 以及接到多个I S P 的多家
站点)。
接口标识符字段为6 4 位。选择这个长度是为了满足[ A R C H ]中指定的需求，以支持
基于E U I - 6 4 接口标识符。
致谢
作者对Thomas Narten, Bob Fink, Matt Crawford, Allison Mankin, Jim Bound, 
ChristianHuitema, Scott Bradner, Brian Carpenter, John Stewart 和Daniel Karrenberg 的评论和
建设性意见表示衷心的谢意。
参考文献
   [ALLOC]   IAB and IESG, "IPv6 Address Allocation Management",
             RFC 1881, December 1995.

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

   [AUTH]    Atkinson, R., "IP Authentication Header", RFC 1826, August
             1995.

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

   [ETHER]   Crawford, M., "Transmission of IPv6 Packets over Ethernet
             Networks", Work in Progress.

   [EUI64]   IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
             Registration Authority",
             http://standards.ieee.org/db/oui/tutorials/EUI64.html,
             March 1997.

   [FDDI]    Crawford, M., "Transmission of IPv6 Packets over FDDI
             Networks", Work in Progress.

   [IPV6]    Deering, S., and R. Hinden, "Internet Protocol, Version 6
             (IPv6) Specification", RFC 1883, December 1995.

   [RFC2050] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D.,
             and J. Postel, "Internet Registry IP Allocation
             Guidelines", BCP 12, RFC 1466, November 1996.

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119,
安全性考虑
I P v 6 寻址文件对I n t e r n e t 基础设施安全性无任何直接影响。I P v 6 包的身份验证
定义见【A U T H 】。


Authors' Addresses

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

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


   Mike O'Dell
   UUNET Technologies, Inc.
   3060 Williams Drive
   Fairfax, VA 22030
   USA

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


   Stephen E. Deering
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA 95134-1706
   USA

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

 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.
RFC 2374  An IPv6 Aggregatable Global Unicast Address Format         IPv6 可集聚全球单播地址格式


1
RFC文档中文翻译计划