实现IPv6：KAME项目的经验

Implementing IPv6:experiences at KAME project
Jun-ichiro itojun Hagino <[e-mail]>
Research Laboratory , Internet Initiative Japan Inc.
http://www.kame.net/

 

摘要

KAME项目开始于1998年，主要是想为IPv6、IPsec和其它最新的Internet技术提供基于BSD 许可证的实现方案。本文试图描述我们的动机、目前的进展、曾经遇到的障碍和解决办法，以及我们未来的发展方向。我们的所有源代码已经并将继续在一个类BSD的许可证下发布。

1 IPv6和KAME的动机和历史

IETF(Internet Engineering Task Force) 是在1992 年开始关于IPng 的工作的，当时的主要目的是为了重构IPv4，并使Internet能够更快地增长。IPv4是在1970年代设计的，而且IPv4 地址只有32 位。32 位对于1970 年代的设计来说也许是足够了，但对于1990 年代往后来说却无法满足。IPv4 地址的理论上限是42亿，比地球上的人口少多了。由于IP 地址空间的分段分配，实际上限更要小得多，也就是几亿的样子。在目前“everything over IP ”的大潮下，蜂窝电话、微波炉甚至是每一辆汽车都想通过IP 进行连接。对于1990 年代之后来说，IPv4的设计显然是不能满足要求了。

在1995 年，IPng 的最终候选者被确定下来，我们现在把它叫做IPv6 。我们WIDE 项目（一个Internet 技术的研究协会，由100 多家大学和公司组成）把IPv6 当作前进的目标，并开始了将其实现的努力。截至1996 年，在WIDE 项目内部就有7个独立的IPv6实现方案。

独立的实现方案刚开始看起来确实不错（进行互操作性测试、找出共同的实现方案上的错误以及发现协议的缺陷），但是，随着时间的推移我们遇到了两个问题。首先是人力资源问题— 每一个实现方案都只有一两个专门的编程人员，他们并没有足够的时间来维护他们的代码库。其次是部署问题—我们非常迫切地需要把IPv6栈集成到各种各样的BSD版本中去，还要在BSD许可证下重新发布它们。

在IPv4 的日子里，BSD 的IPv4 栈被大家当做了一个参考实现方案。所有的互操作性测试都是针对BSD IPv4 栈进行的，人们也是从BSD 的代码中学习IPv4的（比如Stevens 的几本“TCP/IP illustrated ”），BSD IPv4 栈被广泛部署以确保灵活性和可靠性，同时它还改进了IETF 的标准。相反，IPv6 一开始并没有（或者只有少数）测试代码库，并不存在一个参考实现方案，而且我们在把IPv6 代码库部署到广域网络（不是微小的实验室网络）方面几乎没有任何经验。

于是，在1997 年秋天，我们决定开展以下努力：(1) 把我们所有的代码库整合成一个，大家有劲往一处使；(2) 将其在BSD 许可证下重新发布；(3) 在全国范围内实际运行这些代码以验证其灵活性和可靠性；(4) 将我们的代码库集成到*BSD 操作系统中以使其得到广泛发布并成为一个参考实现方案。这些就是KAME 项目要做的事情。KAME 项目本身主要是关注上面这些目标的实现（编写代码）。网络操作部分由WIDE 项目中的IPv6 工作组处理。我们
在WIDE 项目中还有其它的一些子项目，主要负责IPv6 一致性测试（TAHI 项目）以及IPv6-for-Linux项目（USAGI项目）。

2 项目的进展

KAME IPv6/IPsec 栈已集成到所有的*BSD 项目中（NetBSD , OpenBSD , FreeBSD和BSD/OS），同时还有多种路由器产品（如Juniper , Extreme , Hitachi和Fujitsu ）、商业操作系统（Apple MacOS X ）和嵌入式产品（比如Windriver的VxWorks ）。我想我完全可以负责任地说，在构建一个IPv6 的参考实现方案方面我们已经成功了。

2.1 集成策略

尽管IPv6/IPsec 的基本规范已有定论，但却存在着几百个针对IPv6 和IPsec的互联网草案，我们如何把这些东西都集成到*BSD里面去就成了一个问题。

我们基本上是沿着两条路来走的，一条是*BSD ，一条是KAME 。*BSD这条路只支持已成为RFC 并且需要广泛使用的规范。而KAME 这条路则负责实现各种各样的互联网草案，以便于我们发现协议缺陷。有些协议草案实际上还是试验性质的，还需要进行严格测试。

例如，Mobile IPv6 目前已经成为了一个RFC ，每次发布一个internet 草案的修正版本的时候，协议头部格式和其它的一些东西都会改变。因此，没有把它集成到*BSD 版本里去。Mobile Ipv6 的代码只在KAME 的发布版本里才有，它是作为一个给最新的*BSD版本的补丁发布的。

3 IPv6实现中的技术障碍

为了使IPv6 获得成功，IPv6 在设计的时候采用了与IPv4 相同的设计原理。所以，IPv6 实现方案的基本部分可以轻松地完成，我们只需要借鉴IPv4 的经验就可以了。不过，在1970年代（设计IPv4 的时候）到1990年代期间所积累经验的基础上，IPv6 里面还是有很多对IPv4 的功能改进和设计修正。有些改进在我们把IPv6 实现到BSD 网络协议栈中去的时候造成了技术上的困难。在本节中我们将就其中的一些困难进行讨论。

3.1 一个接口多个地址

在IPv4 中，我们假定一个IPv4 地址只跟一个接口相关联。实际上一个IPv4地址标识的是一个节点，而不是一个接口。在IPv6 里面，清楚地定义了一个IPv6 地址与一个接口相关联（而不是一个节点），同时假定多个IPv6 地址可以分配给一个接口。

在BSD IPv4 栈的设计中，有许多利用上述情况的假设。例如，路由表条目中为特定的对端保存有一个源地址缓存（struct rtentry 的rt ifa 成员），对这个字段的使用设计就基于IPv4 的假设。对于IPv6 的代码来说，我们没有使用这个缓存来进行源地址选择。我们使用的是RFC3843中描述的源地址选择逻辑。

3.2 内核堆栈和扩展头部链的综合考虑

IPv6 把IPv4 中的选项头部替换成了扩展头部链。在IPv6 中，一个包上可以挂多个扩展头部，组成的结构看上去就像是一个链表。在协议里对于扩展头部的数目并没有定义一个上限。如果我们使用传统的BSD 协议分派逻辑的话，那我们每看到一个扩展头部就会产生一次函数调用。这将产生很深的函数调用链，很可能会造成内核堆栈溢出。为了解决这个问题，我们实现了一个不会造成很深的函数调用链的分派逻辑。

3.3 IPv6协议和API的安全化

当我们着手于IPv6 的实现方案的时候，我们在IPv6 协议和API 规范中发现了一些漏洞，或者说是潜在的漏洞。简单起见，我们把这些问题简要概括如下：

• IPv6 的某些过渡技术可能被恶意的团体用来匿名发送网络流量，或者是绕过访问控制。
• IPv6 的某些过渡技术会在对端对应用程序的识别信息方面引入模糊的解释；给一个应用程序提供的一个IPv6 地址可能会有两种不同的解释。恶意团体会因此搅乱应用程序并利用这种混乱绕过访问控制。

与此同时，我们还根据实现过程中的经验给IETF提供了大量的反馈。

4 以IPv6的实际部署为目标

就目前而言在IPv6的部署方面还存在着几个障碍：

• 很多ISP 都需要为IPv6 做好准备，而且还得开始提供服务，否则用户就无法使用它。ISP 们的确得抢先一步部署IPv6 网络（而不是等待用户提出需求），因为他们需要赶在用户之前积累操作经验，越早越好，而且在用户开始想用IPv6 的时候他们就得拿出一个已经开始工作的主干网络才行。
• xDSL/L2 的大型供应商们也得为IPv6 做好准备，因为很多L3 的ISP 们依赖于他们的业务。
• 用于SO-HO和家庭范围内的廉价的小型的路由器也得为IPv6 做好准备，不过，由于在这个领域价格竞争太激烈了，所以IPv6 可能会被他们排成最低优先级的事情。不过还好，从KAME 项目得到的IPv6 代码库可以帮助他们在自己的产品中实现IPv6。
• 还有很多的IPv6 协议规范需要最终确定（不是最基本的那个），或者是需要进行修改和讨论。同时，各家厂商也需要支持那些附加的规范。

我们现在对于IPv6 在全世界的部署感到非常乐观。目前，美国政府、国防部已在他们的采购单中要求支持IPv6 ，在欧洲已经有很多个IPv6 主干网的项目，在亚洲也已经有了很多的关于部署IPv6 的尝试。我们日本人需要保持现在的发展速度，与其它国家合作，并试图领导全世界的IPv6部署。

5 未来的计划

目前已经决定KAME 项目将会继续到2006 年春天。如上所述，我们仍然在KAME 项目中测试众多的internet 协议草案，并且还要努力保持*BSDIPv6/IPsec 栈的更新。同时，我们的目标已经不再局限于IPv6 ，而将扩展到各种各样的internet技术，比如DCCP，SCTP，组播DNS，以及DNSSEC。

6 结论

本文主要是谈谈KAME 项目的历史和现状、我们遇到的一些技术困难以及我们未来的发展方向。如果要想知道KAME IPv6/IPsec 的实现细节，你只需浏览位于这个网址的代码：ftp://ftp.kame.net/pub/kame/snap/ （我们的代码中加了很多的关于引用RFC的注释），或者还可以参考我们在各种场合提交的论文。

 

 

文章出自:http://blog.chinaunix.net/u/9831/showart_60236.html