Autoconfiguration for IP Networking: Enabling Local Communication 翻译

r囧r小猫 2022-02-19 02:43 146阅读 0赞

# IP网络自动配置：实现本地通信 #

**Erik Guttman**  
Sun Microsystems, Germany

> 如果一个因特网协议套件的主机实现可以完全自我配置的话那就太完美了。这样就能让整个套件实现在ROM中或者固件化，这能简化无磁盘的工作站，对于苦恼的局域网管理员和系统厂商来说是一个非常棒的礼物。但我们当前并没有实现它；事实上，连接近都没有。— RFC 1122。

### 文章目录 ###

*  零配置联网
 *  定义一种方法
 *  新兴的解决方案
 *   *  地址自动配置
     *  名称到地址转换
     *  服务发现
     *  多播地址分配
 *  加密Zeroconf协议
 *  网络管理
 *  对未来的展望
 *  参考文献
 *  小贴士
 *   *  IP主机层
     *  早期的自动配置工作

IP主机和网络基础设施自古以来就难以配置—需要网络服务并依赖技术精湛的网络管理员—但新兴的网络协议承诺其能使得主机在不用预先配置以及不需要网络服务的情况下建立IP网络。甚至对于计算资源有限的简易设备，不管它被接入哪里，都将能够使用标准协议进行通信。当前IETF的标准化工作，如Zeroconf工作组的工作，致力于使这种形式的联网更简单和便宜。

那些永久连接到一个受管理的网络的主机通常会被网络管理员赋予静态的网络配置。其他连到受管理网络(例如企业局域网或拨入帐户)的主机则使用动态网络配置。在这些情况下，所有必要的参数都由一个网络配置服务授予主机，网络配置服务本身需要配置。在许多情况下—如临时会议、受管理网络配置失败或者网络服务故障—我们很想建立一个IP网络，但是管理它可能会不切实际甚至不可能。在这些情况下，自动的网络参数配置对于主机是很有价值的。IETF Zeroconf WG的真正目标是实现两个或多个计算设备间经由IP的直接通信。在这个教程中，我给出了零配置联网(Zero Configuration Networking)的背景、当前状态和未来展望。

# 零配置联网 #

自动配置的参数与静态和动态配置分配的参数具有不同的属性。它们是短暂的；它们很可能每次获得时都不一样并且任何时刻都可能改变。自动配置的主机会主动地参与分配和维护它们的配置参数，这些参数只具有本地意义。网络服务的自治意味着主机必须配置网络。

直接比较来说，一般的IP配置是持久的(特别是对于服务器)，或起码是稳定的。IP协议套件致力于实现可扩展性，尤其是在配置方面。地址和名字通常有全局意义，这已被证明对实现因特网增长十分必要。但是，获取和管理全球地址和名字需要许多管理工作。这些过程并不是完全自动化的，并且很可能永远不是。

抛开这些差异，基本的零配置网络协议实际上只意味着对支持IP的设备的较低层进行修改。(小贴士“IP主机分层”中介绍了讨论自动配置所需的术语)。

现有的基于网络的应用程序将在不修改增强的网络服务和使用标准接口的应用程序层的情况下工作。事实上，用户甚至都不应该意识到网络服务层是被自动而不是静态或动态配置的。

在IPv4和IPv6下，四个功能将受益于零配置联网。不需要修改现有接口，零配置协议就将增强名字到地址转换(在应用层)和IP接口配置(在网络层)。之前IP主机没有的功能将引入新的接口：应用层的服务发现和网络层的多播地址分配。

这些额外的服务不会影响现有的应用。他们将“获得提升”，通过提供因特网协议套件一直缺席，但在苹果、微软和Novell的专属网络协议套件中拥有的额外特性。(见小贴士“早期的自动配置工作”)。这些专属协议仅仅因它们易于配置的特性而继续被使用。采用新兴的零配置协议标准将使我们淘汰专属网络—向更广泛的支持前进一步。甚至网络设备厂商也一直同意说专属网络协议已经快要寿终正寝了，应该被替换为IP标准。

由于扩展性和需要降低对现有网络的影响，零配置协议对于整个网络的影响必须受到限制。零配置协议的算法通常使用多播。在实践中，这些协议被限制于单条网络链路(就是指，没有路由器来转发这些协议消息)或者一个网络集合中(路由器被配置为边界，协议消息不会发出边界)。

# 定义一种方法 #

IETF零配置协议标准化的那些工作(当前在Zeroconf、服务定位协议、DNS扩展和IPNG工作组)被认为是克服人工配置与自动化运作间差异的两个主要方法。

第一个策略要求在本地和全局配置间进行转换，从1998年起就在面向消费者的操作系统软件上进行探索了。这个策略暗示，主机只要缺失全局配置，就将支持自动的配置。这两种模式是互斥的，要进行动态配置服务需要从自动（本地）配置转换为动态（全局）配置。

这种转换策略的一个例子是苹果和微软的桌面操作系统采用的网络接口自动配置协议。这个(IETF还没有标准化的)协议使得一个主机能简单地从一个预留范围内选择一个未分配的IP地址。然后主机会尝试从网络上通过动态主机配置协议DHCP获取(全局)IP配置参数。主机周期性地提交DHCP请求，如果网络上存在一个可达的DHCP服务器的话那这最终会成功。一旦一个DHCP服务器答复了，并提供了IP配置参数，这参数就会替换自动配置的那个。

这个机制对于采用了常见的客户端-服务器协议的客户端来说可以很好的工作，因为极少会使用长期链接。即使连接失败，单个网络应用程序操作也会导致明显的事务(transactions)。如果客户端主机进行了网络重配置，应用程序会简单地建立一条新的链接。

然而，如果一个服务器配置修改了，恢复起来就没那么容易了：如果他们不能找到服务器，客户端应用程序就会停止工作。带有动态地址的服务器只能通过一个动态服务发现协议来定位，并且当前极少基于IP的应用采用服务发现。

服务器地址的重配置可能会搞崩服务器软件，服务器软件典型地会绑定到一个(极可能不可变的)地址以接收进入的消息。另外，当一个服务器经由DHCP进行重配置时，它再也不能与还没重配置的客户端进行通信。反之，如果DHCP配置了客户端系统，而没能配置服务器(比如DHCP服务器不可达)，带有全局参数的客户端将无法与服务器通信，这时服务器仍然只有本地自动的配置。

最终，一些及其简单的设备也许会只支持本地IP配置，无法与通过DHCP配置的主机进行通信。比如，可以开发非常廉价的应用来实现远程监控服务，客户端将只需要本地IP配置来跟这些设备通信，除非有额外的网络基础设施。

由于发现了IP配置转换带来的问题，Zeroconf工作组不鼓励这个转换的方法。主机应当要不单独使用自动配置，要不动态或静态配置。两台连接到同个网络的实现零配置协议的主机不管是否有DHCP或者其他服务器，都将能够通信。他们将只需要在冲突时重配置它们的地址(或可能是名字)。

# 新兴的解决方案 #

Zeroconf工作组已经定义了零配置联网协议区的四条需求。为获得进一步解释和详细信息，请参阅草案需求文档。当前，IETF已经推出或者不久就将推出以下几个标准。

## 地址自动配置 ##

首个协议区是地址自动配置。为了让一个IP栈传送IP消息，每个通信终端(源和目标)都需要一个在地址作用域内唯一的IP地址。比如，一个本地链路地址会被配置为链路上唯一。地址自动配置的需求包括允许一个主机：

*  使用唯一的地址配置它的接口；
 *  确定使用哪一个子网掩码(子网掩码用于标识网络地址，并且使得IP协议栈能确定是否它可以直接传输一个数据报)；
 *  探测重复的地址分配；以及
 *  处理冲突。

当前的Ipv4本地链路自动配置规范先后兼容苹果Macintosh和微软Windows操作系统软件，除了一个例外：它推荐维护自动配置的地址(即使一个接口也被配置了全局IPv4地址)而不是从本地转换为全局。当前的规范还包括一些指南，有助于为具有多个启用IP接口的主机消除本地链路寻址的歧义。IPv6的本地链路自动配置是IETF的一个草案标准。

图1中每个设备的每个接口都可以获得和维护一个唯一分配的地址。主机1和主机2共享一个无线链路，在其上，A和B的地址是不同的。主机2、3和4共享一个有线链路，其上，地址C、D和E是唯一的。

为了降低混乱，主机2不会分配与其所连接的任何链接上分配的链接本地地址冲突的地址。主机2不会试图在有线链路上分配地址A，因为A已经分配在无线链路上了。由于主机2无法控制其他主机，如主机1和3，地址A可能会和地址D一样。这种情况可能会给主机2带来歧义。这使得拥有多个接口的主机的本地链路地址的自动配置变得更加复杂。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpbl9zdHJvbmc_size_16_color_FFFFFF_t_70][]  
图 1.IP地址自动配置。每个共享的有线或无线链路上的主机地址(A到E)都是唯一的。

## 名称到地址转换 ##

第二个零配置协议区是名称到地址转换(name-to-address translation)。IP应用程序典型地通过名称而不是地址来标识网络上的终端。当一个终端的地址改变时，这带来了运行上的稳定性，因为它的名字没有变。零配置协议的名称到地址转换需要机制以：

*  获得与一个名字相关联的IP地址，以及
 *  确定与一个IP地址相关联的名字。

后一个特性有助于未来与客户端的通信，并使得服务器能生成人类可读的日志信息。

本地链路多播DNS是在IPv4和IPv6上本地解析名字用的，其使用DNS协议但不需要一个专用DNS服务器。还可以使用节点信息询问协议(node information query protocol)在IPv6上进行名字到地址转换。

图2阐述了使用多播DNS进行名字到地址解析的过程。一个客户端应用程序请求对应于名字“Sally”的地址，名字到地址的翻译可以通过提交DNS请求到一个公知的多播IP地址实现。每个主机都监听这些请求，如果多播DNS请求的名字和自身配置的名字吻合的话则进行答复。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpbl9zdHJvbmc_size_16_color_FFFFFF_t_70 1][]  
图2. 多播DNS协议交互。客户端通过提交一条请求到一个公知多播地址并等待答复，而从叫做“Sally”的主机处获得了IP地址。

## 服务发现 ##

第三个零配置协议区是服务发现。客户端应该要在没有预先配置和网络上没有任何管理员配置的管理服务(如目录)的情况下发现网络上的服务。另外，服务发现协议不得造成广播风暴或过分行为。(一些现存的服务发现协议—最明显的是IPX协议套件的服务广告协议—需要过分的网络资源。)

一些服务是很含糊的，如通用的Web代理、DNS服务器或SMTP中继；这是说，任何这类的服务器都会执行完全一样的功能。另一些服务则很明确，每个服务器实例都是独特的，如不重复数据库、文件服务器或支持IP的打印机。能分辨后一类服务器的能力让客户端能发现它需要的服务器，而不是发现所有它能够通信的服务器(其中大部分对其没有用)。

IETF已经为在IP网络上发现服务的需求标准化了两个机制。服务定位协议(SLP)V2使用管理作用域的多播，因为它被设计来扩展单个管理域（通常包括整个站点，如校园或企业网络）。大部分其他的零配置协议被定义为用在本地链路多播上。SLP提供基于服务类型和服务属性的服务发现，所以客户端可以通过指定需要的特性来发现一个特定的服务器。SLP被定义于使用在IPv4和IPv6上。我在早先的IC文章中更详细的讨论了SLP。

第二个IETF服务发现机制是DNS SRV资源记录，它使得客户端能通过DNS查阅服务。客户端指定要查阅的服务类型、传输协议和域名。对这个询问的答复会提供符合请求的主机的清单。

图3阐述了使用SLPv2的服务发现。客户端应用程序请求服务“Bar”的位置，包括需求的服务类型和服务属性。SLPv2用户代理代表客户端多播这个需求。如果SLPv2服务代理正在广告的服务符合请求的话，它就会响应一个服务答复。  
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpbl9zdHJvbmc_size_16_color_FFFFFF_t_70 2][]  
图3. 使用SLPv2进行服务发现。一个客户端应用请求服务“Bar”的位置，如果SLPv2服务代理正在广告的服务符合请求的话，它就会响应一个服务答复。

## 多播地址分配 ##

工作组指出的第四个协议区是多播地址分配。一些基于多播的应用程序需要获得一个唯一的多播地址以避免其他应用程序(或基于同个应用的会话)与它们冲突。多播地址冲突可能导致应用程序故障，机理类似两台主机配置同样的IP地址：来自两个不同会话的通信可能被传递到不正确的目的地。

Zeroconf多播地址分配协议(ZMAAP)支持应用：

*  分配唯一地址并一直维护；
 *  阻止重分配被分配过的地址；以及
 *  在发生多播分配冲突时被通知。

这些需求和地址自动配置里的不一样，因为多播地址是一个共享资源。在许多情况下，跨网络存在的不同进程需要共享分配控制。第二个和第三个ZMAAP需求使得任何进程能延长一个会话以及发现会话是否仍然有效。

满足需求的推荐协议规范的当前版本可以在Zeroconf工作组页面上找到。

# 加密Zeroconf协议 #

专属自动配置协议不提供加密它们基础操作的机制。AppleTalk、IPX和NetBIOS网络加密机制为应用程序提供面向用户和组群的访问控制，但是自动的配置协议(地址分配、名字解析和服务发现)仍然是未加密的。这使得这些协议套件很简单，但是也使它们易受攻击。

自动配置可以很危险。如果没使用合适的加密机制，能访问一个局域网的任何人都可以轻易破坏那使用的零配置协议。随着无线网络技术的部署和共享网络跨图像缆、供电缆和其他住宅接入媒体的扩展，未授权访问越来越可能了。

由于与零配置网络的基本目的相悖，不能自动地配置加密，但这对于管理者来说仍然很简单。Zeroconf工作组已经指出了一个需求集以确保使用零配置协议的操作会和使用相关配置过的IETF协议一样安全。已经讨论了简单地配置IP主机来加密操作的特别机制，但是还没有推出推荐规范。

进一步发展的一个重要领域是对自动配置网络的安全远程访问。许多家居网络产品已经提供了在私有网络上远程监控设备的专用解决方案。也许建立一个标准网关机制来让远程网络上的主机访问本地配置过的设备会十分有用。未来还需要对建立简单地管理和互用性机制以配置设备组中的加密参数进行研究。

# 网络管理 #

由于零配置协议允许主机同时被自动配置和被管理，网络管理员可能会面临一些问题。

*  使用本地分配地址和名字的IP主机只能在单个局域网上访问。这与被配置为更大作用域的地址的主机反差，如全球唯一IP地址，其(理想情况下)可以被任意因特网上的网络访问(忽略防火墙这些细节)。
 *  现今的管理员希望网络通信被限制于它们配置和控制的主机。在未来，许多在单条链路上的通信可能是处于完全使用本地参数的设备间的—有时在从不获得受管理分配的参数的设备间。
 *  在没有DHCP的网络上，用户预期管理员会通过配置分配来启用联网。在用户习惯了自动配置的网络后，就不会这样了。
 *  用户将会想要在网络上的任意位置访问本地链路配置的服务。这将需要对服务额外的配置或者应用层网关、代理或一个更复杂的策略，这策略涉及远程访问仅本地链路服务所在的网络。

零配置协议将很可能通过减少设置和运行IP主机本地通信时的问题，简化网络管理。同时，主机潜在地将会有两种配置(本地和全局)，这将导致复杂的情况。我在其他地方进一步探讨了零配置网络的许多体系结构问题。

# 对未来的展望 #

IETF不久就将发布零配置协议需求规范和新兴标准跟踪协议。这预示着简单可互用IP设备的发展以及局域网稳定性和可用性的增强。

同样讨论了创建一个profile来指定符合主机实现的零配置协议集。受到IP主机需求规范的启发，这个方法将激励厂商实现单个协议集合。IETF通常会避免推荐或要求特定协议(几乎所有的IETF标准都被分类为可选)。IP主机需求被发布来描述先期经验而不是指定未来的解决方案。因此，还不是很确定Zeroconf工作组是否将制作profile文档。

如我之前提到的，加密机制将需要额外的探索，并且将很可能产生新的网络管理挑战，但是IETF零配置协议不久就将发布；实际上，许多已经在那了。

# 参考文献 #

1.  R. Braden, “Requirements for Internet Hosts—Communication Layers,” IETF RFC 1122, Oct. 1989; available at [http://www.rfc-editor.org/rfc/rfc1122.txt][http_www.rfc-editor.org_rfc_rfc1122.txt].
2.  R. Droms, “Dynamic Host Configuration Protocol,” RFC 2131, Mar. 1997; available at [http://www.rfc-editor.org/rfc/rfc2131.txt][http_www.rfc-editor.org_rfc_rfc2131.txt].
3.  M. Hattig, “ZeroConf Requirements,” Internet draft, Zeroconf WG, Mar. 2001; work in progress.
4.  S. Cheshire and B. Aboba, “Dynamic Configuration of IPv4 Link-local Addresses,” Internet draft, Zeroconf WG, Mar. 2001; work in progress.
5.  S. Thomson and T. Narten, “IPv6 Stateless Address Autoconfiguration,” RFC 2462, Dec. 1998; available at [http://www.rfc-editor.org/rfc/rfc2462.txt][http_www.rfc-editor.org_rfc_rfc2462.txt].
6.  L. Ebisov et al., “Multicast DNS,” Internet draft, DNSEXT WG, Nov. 2000; work in progress.
7.  M. Crawford, “IPv6 Node Information Query,” Internet draft, IPNGWG WG, Aug. 2000; work in progress.
8.  E. Guttman et al., “Service Location Protocol, Version 2,” RFC 2608, June 1999; available at [http://www.rfc-editor.org/rfc/rfc2608.txt][http_www.rfc-editor.org_rfc_rfc2608.txt].
9.  E. Guttman, “Service Location Protocol Modifications for IPv6,” Internet draft, Svrloc WG, Feb. 2001; work in progress.
10. E. Guttman, “The Service Location Protocol,” IEEE Internet Computing, vol. 3, no. 4, July 2000, pp. 71-80.
11. A. Gulbrandsen et al., “A DNS RR for specifying the location of services (DNS SRV),” RFC 2782, Feb. 2000; available at [http://www.rfc-editor.org/rfc/rfc2782.txt][http_www.rfc-editor.org_rfc_rfc2782.txt].
12. O. Catrina et al., “Zeroconf Multicast Address Configuration Protocol (ZMAAP),” Internet draft, Zeroconf WG, March 2001; work in progress.
13. E. Guttman, “Zero Configuration Networking,” Proc. INET 2000, Internet Society, Reston, VA; available at [http://www.isoc.org/inet2000/cdproceedings/3c/3c\_3.htm][http_www.isoc.org_inet2000_cdproceedings_3c_3c_3.htm].

# 小贴士 #

## IP主机层 ##

分层结构是大型稳定可扩展计算平台的基础。图A描述了随处可见的一个分层架构，通常叫做IP协议栈，用于因特网主机。它粗略地对应OSI七层模型。图中没有OSI表示层和会话层。IP应用程序自身实现数据的表示功能。会话特性如协议传输间的加密、压缩或持续性被以ad hoc方式加入多个层。

每个层都通过标准接口为上层提供服务。如果下层使用同样的接口提供同样的功能，服务就能以不同的方式实现；因此，定义在网络服务层的新机制可以不修改现存应用程序就支持他们。不用修改上层使得采用新因特网技术更加容易。需要更新客户端应用程序的网络服务层增强(如e-mail读取器和Web浏览器)不被广泛采用。

每个层都可以被自动地配置。实践中，需要越少配置越好，因为更简单的技术其工作方式更可预期，并且易于部署。传输服务、链路控制和媒体访问层极少需要对因特网主机进行配置。相对地，应用层和网络服务层几乎总是需要配置才能工作。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpbl9zdHJvbmc_size_16_color_FFFFFF_t_70 3][]  
图 A. 因特网主机分层。零配置协议将实现在因特网协议栈的应用层和网络服务层

参考文献

1.  A.Tanenbaum, Computer Networks, Second Edition, Prentice-Hall, Englewood Cliffs, N. J., 1989.

## 早期的自动配置工作 ##

因特网协议套件最初是作为给研究人员使用和维护的一个网络的数据通信标准而出现的。他们的设计目标主要是互用性、可扩展性和伸缩性。IP网络通过(为命名和寻址等)使用唯一参数和委派管理者的机制实现了增长和全球通信。

与此同时，网络软件(和设备)供应商正在开发专属协议套件，这些套件强调易于使用和易于部署。苹果的AppleTalk、Novell的IPX和微软的NetBIOS/SMB的成功源于它们自动精灵地址配置的能力、去中心化的服务发现以及命名功能，这有助于本地通信以及资源，如文件和打印机，的共享。

零配置将桥连这两个不同协议族的鸿沟。支持IP的主机和应用程序将能够利用与AppleTalk提供的相似的机制。然而，完全地自动配置因特网是不可能的。零配置协议支持有限规模(功能性定义而不是决对定义)的网络上的本地通信。当自动配置不够用了，管理者必须计划和部署可扩展的配置的网络。

参考文献

1.  S. Gursharan et al., Inside AppleTalk,Addison-Wesley, Reading, Mass., 1990.
2.  IPX RIP and SAP Router Specification, version 1.30, Part Number 107-000029-001, Novell Inc.,LOCATION?,May 1996.
3.  SMB File Sharing Protocol Extensions 3.0, version 1.09, Microsoft Networks,Nov. 1989.

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpbl9zdHJvbmc_size_16_color_FFFFFF_t_70]: /images/20220219/de515530b9d2473ea62054a2777c5739.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpbl9zdHJvbmc_size_16_color_FFFFFF_t_70 1]: /images/20220219/2c573f1e21f24287a444fba25c9c0c47.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpbl9zdHJvbmc_size_16_color_FFFFFF_t_70 2]: /images/20220219/461cf55f08b046c3b9094d65326b0183.png
[http_www.rfc-editor.org_rfc_rfc1122.txt]: http://www.rfc-editor.org/rfc/rfc1122.txt
[http_www.rfc-editor.org_rfc_rfc2131.txt]: http://www.rfc-editor.org/rfc/rfc2131.txt
[http_www.rfc-editor.org_rfc_rfc2462.txt]: http://www.rfc-editor.org/rfc/rfc2462.txt
[http_www.rfc-editor.org_rfc_rfc2608.txt]: http://www.rfc-editor.org/rfc/rfc2608.txt
[http_www.rfc-editor.org_rfc_rfc2782.txt]: http://www.rfc-editor.org/rfc/rfc2782.txt
[http_www.isoc.org_inet2000_cdproceedings_3c_3c_3.htm]: http://www.isoc.org/inet2000/cdproceedings/3c/3c_3.htm
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpbl9zdHJvbmc_size_16_color_FFFFFF_t_70 3]: /images/20220219/1dcfc880916f4a6a83ef07ec5ea79620.png