Global Routing Operations D. Plonka
Network Working Group University of Wisconsin
Request for Comments: 4085 June 2005
BCP: 105
Category: Best Current Practice
Global Routing Operations D. Plonka
Network Working Group University of Wisconsin
Request for Comments: 4085 June 2005
BCP: 105
Category: Best Current Practice
Embedding Globally-Routable Internet Addresses Considered Harmful
嵌入被认为有害的全局可路由Internet地址
Status of This Memo
关于下段备忘
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
本文件规定了互联网社区的最佳现行做法，并要求进行讨论和提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This document discourages the practice of embedding references to unique, globally-routable IP addresses in Internet hosts, describes some of the resulting problems, and considers selected alternatives. This document is intended to clarify best current practices in this regard.
本文档不鼓励在Internet主机中嵌入对唯一、全局可路由IP地址的引用，描述了由此产生的一些问题，并考虑了选定的替代方案。本文件旨在澄清这方面的最佳现行做法。
Table of Contents
目录
1. Introduction ....................................................2
2. Problems ........................................................2
3. Recommendations .................................................4
3.1. Disable Unused Features ....................................4
3.2. Provide User Interface for IP Features .....................4
3.3. Use Domain Names as Service Identifiers ....................4
3.4. Use Special-Purpose, Reserved IP Addresses When Available ..5
3.5. Discover and Utilize Local Services ........................6
3.6. Avoid Mentioning the IP Addresses of Services ..............6
4. Security Considerations .........................................6
5. Conclusion ......................................................7
6. Acknowledgements ................................................7
7. References ......................................................7
Appendix A. Background ............................................9
1. Introduction ....................................................2
2. Problems ........................................................2
3. Recommendations .................................................4
3.1. Disable Unused Features ....................................4
3.2. Provide User Interface for IP Features .....................4
3.3. Use Domain Names as Service Identifiers ....................4
3.4. Use Special-Purpose, Reserved IP Addresses When Available ..5
3.5. Discover and Utilize Local Services ........................6
3.6. Avoid Mentioning the IP Addresses of Services ..............6
4. Security Considerations .........................................6
5. Conclusion ......................................................7
6. Acknowledgements ................................................7
7. References ......................................................7
Appendix A. Background ............................................9
Some vendors of consumer electronics and network gear have unfortunately chosen to embed, or "hard-code", globally-routable Internet Protocol addresses within their products' firmware. These embedded IP addresses are typically individual server IP addresses or IP subnet prefixes. Thus, they are sometimes used as service identifiers, to which unsolicted requests are directed, or as subnet identifiers, specifying sets of Internet addresses that the given product somehow treats specially.
不幸的是，一些消费类电子产品和网络设备供应商选择在其产品固件中嵌入或“硬编码”全球可路由互联网协议地址。这些嵌入式IP地址通常是单个服务器IP地址或IP子网前缀。因此，它们有时被用作服务标识符，非冲突请求被定向到服务标识符，或者被用作子网标识符，指定给定产品以某种方式专门处理的互联网地址集。
One recent example was the embedding of the globally-routable IP address of a Network Time Protocol server in the firmware of hundreds of thousands of Internet hosts that are now in operation worldwide. The hosts are primarily, but are not necessarily, limited to low-cost routers and middleboxes for personal or residential use. In another case, IP address prefixes that had once been reserved by the Internet Assigned Numbers Authority (IANA) were embedded in a router product so that it can automatically discard packets that appear to have invalid source IP addresses.
最近的一个例子是将网络时间协议服务器的全局可路由IP地址嵌入到目前在全球运行的数十万台Internet主机的固件中。主机主要（但不一定）限于个人或住宅使用的低成本路由器和中间盒。在另一种情况下，曾经由互联网分配号码管理局（IANA）保留的IP地址前缀被嵌入到路由器产品中，以便它可以自动丢弃似乎具有无效源IP地址的数据包。
Such "hard-coding" of globally-routable IP addresses as identifiers within the host's firmware presents significant problems to the operation of the Internet and to the management of its address space.
作为主机固件内标识符的全局可路由IP地址的这种“硬编码”对互联网的操作及其地址空间的管理提出了重大问题。
Ostensibly, this practice arose as an attempt to simplify IP host configuration by pre-loading hosts with IP addresses. Products that rely on such embedded IP addresses initially may appear to be convenient to the product's designer and to its operator or user, but this dubious benefit comes at the expense of others in the Internet community.
从表面上看，这种做法是为了通过预加载具有IP地址的主机来简化IP主机配置。最初依赖这种嵌入式IP地址的产品可能对产品的设计者、运营商或用户来说很方便，但这种可疑的好处是以牺牲互联网社区中的其他人为代价的。
This document denounces the practice of embedding references to unique, globally-routable IP addresses in Internet hosts, describes some of the resulting problems, and considers selected alternatives. It also reminds the Internet community of the ephemeral nature of unique, globally-routable IP addresses; the assignment and use of IP addresses as identifiers is temporary and therefore should not be used in fixed configurations.
本文档谴责在Internet主机中嵌入对唯一、全局可路由IP地址的引用的做法，描述了由此产生的一些问题，并考虑了选定的替代方案。它还提醒互联网社区独特的、全球可路由的IP地址的短暂性；IP地址作为标识符的分配和使用是临时的，因此不应在固定配置中使用。
The embedding of IP addresses in products has caused an increasing number of Internet hosts to rely on a single central Internet service. This can result in a service outage when the aggregate workload overwhelms that service. When fixed addresses are embedded
在产品中嵌入IP地址导致越来越多的Internet主机依赖于单一的中央Internet服务。当总工作负载超过服务时，这可能导致服务中断。当嵌入固定地址时
in an ever-increasing number of client IP hosts, this practice runs directly counter to the design intent of hierarchically deployed services that would otherwise be robust solutions.
在越来越多的客户端IP主机中，这种做法直接违背了分层部署服务的设计意图，否则这些服务将是健壮的解决方案。
The reliability, scalability, and performance of many Internet services require that the pool of users not access a service using its IP address directly. Instead, they typically rely on a level of indirection provided by the Domain Name System, RFC 2219 [6]. When appropriately utilized, the DNS permits the service operator to reconfigure the resources for maintenance and to perform load balancing, without the participation of the users and without a requirement for configuration changes in the client hosts. For instance, one common load-balancing technique employs multiple DNS records with the same name; the set of answers that is returned is rotated in a round-robin fashion in successive queries. Upon receiving such a response to a query, resolvers typically will try the answers in order, until one succeeds, thus enabling the operator to distribute the user request load across a set of servers with discrete IP addresses that generally remain unknown to the user.
许多Internet服务的可靠性、可扩展性和性能要求用户池不能直接使用其IP地址访问服务。相反，它们通常依赖于域名系统RFC2219提供的间接寻址级别[6]。当适当利用时，DNS允许服务运营商重新配置资源以进行维护并执行负载平衡，而无需用户参与，也无需更改客户端主机中的配置。例如，一种常见的负载平衡技术使用具有相同名称的多个DNS记录；返回的答案集在连续查询中以循环方式旋转。在收到对查询的此类响应后，解析程序通常会按顺序尝试回答，直到成功，从而使操作员能够将用户请求负载分布在一组具有离散IP地址的服务器上，这些离散IP地址通常不为用户所知。
Embedding globally-unique IP addresses taints the IP address blocks in which they reside, lessening the usefulness and mobility of those IP address blocks and increasing the cost of operation. Unsolicited traffic may continue to be delivered to the embedded address well after the IP address or block has been reassigned and no longer hosts the service for which that traffic was intended. Circa 1997, the authors of RFC 2101 [7] made this observation:
嵌入全局唯一的IP地址会污染它们所在的IP地址块，降低这些IP地址块的可用性和移动性，并增加操作成本。在IP地址或块被重新分配之后，未经请求的流量可能会继续传送到嵌入地址，并且不再承载该流量预期的服务。大约在1997年，RFC 2101[7]的作者发表了以下观察结果：
Due to dynamic address allocation and increasingly frequent network renumbering, temporal uniqueness of IPv4 addresses is no longer globally guaranteed, which puts their use as identifiers into severe question.
由于动态地址分配和日益频繁的网络重新编号，IPv4地址的时间唯一性不再是全局保证的，这使得它们作为标识符的使用受到严重质疑。
When IP addresses are embedded in the configuration of many Internet hosts, the IP address blocks become encumbered by their historical use. This may interfere with the ability of the Internet Assigned Numbers Authority (IANA) and the Internet Registry (IR) hierarchy to usefully reallocate IP address blocks. Likewise, to facilitate IP address reuse, RFC 2050 [1], encourages Internet Service Providers (ISPs) to treat address assignments as "loans".
当IP地址嵌入到许多Internet主机的配置中时，IP地址块会因其历史使用而受阻。这可能会干扰Internet分配号码管理局（IANA）和Internet注册表（IR）层次结构有效地重新分配IP地址块的能力。同样，为了促进IP地址重用，RFC 2050[1]鼓励互联网服务提供商（ISP）将地址分配视为“贷款”。
Because consumers are not necessarily experienced in the operation of Internet hosts, they cannot be relied upon to fix problems, if and when they arise. Therefore, a significant responsibility lies with the manufacturer or vendor of an Internet host to avoid embedding IP addresses in ways that cause the aforementioned problems.
由于消费者不一定对互联网主机的操作有经验，因此当出现问题时，不能依靠他们来解决问题。因此，互联网主机的制造商或供应商有重大责任避免以导致上述问题的方式嵌入IP地址。
Internet host and router designers, including network product manufacturers, should not assume that their products will be deployed and used in only the single global Internet that they happen to observe today. A myriad of private or future internetworks in which these products will be used may not allow those hosts to establish communications with arbitrary hosts on the global Internet. Since the product failure modes resulting from an unknown future internetwork environment cannot be fully explored, one should avoid assumptions regarding the longevity of our current Internet.
互联网主机和路由器设计师，包括网络产品制造商，不应假设他们的产品将仅在他们今天碰巧观察到的单一全球互联网上部署和使用。大量使用这些产品的私有或未来互联网可能不允许这些主机与全球互联网上的任意主机建立通信。由于未来未知的互联网环境导致的产品故障模式无法得到充分探索，因此应避免对当前互联网寿命的假设。
The following recommendations are presented as best practice today.
以下建议是目前的最佳做法。
Vendors should, by default, disable unnecessary features in their products. This is especially true of features that generate unsolicited Internet traffic. In this way, these hosts will be conservative regarding the unsolicited Internet traffic they produce. For instance, one of the most common uses of embedded IP addresses has been the hard-coding of addresses of well known public Simple Network Time Protocol (SNTP RFC 2030 [8]) servers in products. However, only a small fraction of users will benefit from these products having some notion of the current date and time.
默认情况下，供应商应禁用其产品中不必要的功能。这对于产生未经请求的互联网流量的功能尤其如此。这样，这些主机将对其产生的未经请求的互联网流量保持保守。例如，嵌入式IP地址最常见的用途之一是对产品中著名的公共简单网络时间协议（SNTP RFC 2030[8]）服务器的地址进行硬编码。然而，只有一小部分用户会从这些对当前日期和时间有一定了解的产品中受益。
Vendors should provide an operator interface for every feature that generates unsolicited Internet traffic. A prime example is this: the Domain Name System resolver should have an interface enabling the operator to either explicitly set the choice of servers or enable a standard automated configuration protocol such as DHCP, defined by RFC 2132 [9]. These features should originally be disabled within the operator interface, and subsequently enabling these features should alert the operator that the feature exists. This will make it more likely that the product's owner or operator can participate in problem determination and mitigation when problems arise.
供应商应为产生未经请求的互联网流量的每个功能提供操作员界面。一个主要的例子是：域名系统解析程序应该有一个接口，使操作员能够显式地设置服务器的选择或启用标准的自动配置协议，如RFC 2132[9]定义的DHCP。这些功能最初应在操作员界面中禁用，随后启用这些功能应提醒操作员该功能存在。这将使产品所有者或运营商更有可能在出现问题时参与问题确定和缓解。
RFC 2606 [2] defines the IANA-reserved "example.com", "example.net", and "example.org" domains for use in example configurations and documentation. These are candidate examples to be used in user interface documentation.
RFC 2606[2]定义了IANA保留的“example.com”、“example.net”和“example.org”域，以便在示例配置和文档中使用。这些是在用户界面文档中使用的候选示例。
Internet hosts should use the Domain Name System to determine the IP addresses associated with the Internet services they require.
Internet主机应使用域名系统来确定与其所需的Internet服务相关联的IP地址。
When using domain names as service identifiers in the configurations of deployed Internet hosts, designers and vendors are encouraged to introduce service names. These names should be within a domain that they either control or are permitted to utilize by an agreement with its operator (such as for public services provided by the Internet community). This is commonly done by introducing a service-specific prefix to the domain name.
当在部署的Internet主机的配置中使用域名作为服务标识符时，鼓励设计师和供应商引入服务名称。这些名称应位于其控制的域内，或通过与其运营商的协议允许使用的域内（例如，用于互联网社区提供的公共服务）。这通常是通过在域名中引入特定于服务的前缀来实现的。
For instance, a vendor named "Example, Inc." with the domain "example.com" might configure its product to find its SNTP server by the name "sntp-server.config.example.com" or even by a name that is specific to the product and version, such as "sntp-server.v1.widget.config.example.com". Here the "config.example.com" namespace is dedicated to that vendor's product configuration, with subdomains introduced as deemed necessary. Such special-purpose domain names enable ongoing maintenance and reconfiguration of the services for their client hosts and can aid in the ongoing measurement of service usage throughout the product's lifetime.
例如，域名为“Example.com”的名为“Example，Inc.”的供应商可能会将其产品配置为通过名称“SNTP server.config.Example.com”甚至通过特定于产品和版本的名称（例如“SNTP server.v1.widget.config.Example.com”）查找其SNTP服务器。这里的“config.example.com”名称空间专用于该供应商的产品配置，并根据需要引入子域。此类专用域名支持对其客户机主机的服务进行持续维护和重新配置，并有助于在整个产品生命周期内持续测量服务使用情况。
An alternative to inventing vendor-specific domain naming conventions for a product's service identifiers is to utilize SRV resource records (RRs), defined by RFC 2782 [10]. SRV records are a generic type of RR that uses a service-specific prefix in combination with a base domain name. For example, an SRV-cognizant SNTP client might discover Example, Inc.'s suggested NTP server by performing an SRV-type query to lookup for "_ntp._udp.example.com".
为产品的服务标识符发明特定于供应商的域命名约定的替代方法是利用RFC 2782[10]定义的SRV资源记录（RRs）。SRV记录是一种通用的RR类型，它将特定于服务的前缀与基本域名结合使用。例如，认知SRV的SNTP客户端可能会通过执行SRV类型的查询来查找“\u NTP.\u udp.example.com”，从而发现example，Inc.建议的NTP服务器。
However, note that simply hard-coding DNS name service identifiers rather than IP addresses is not a panacea. Entries in the domain name space are also ephemeral and can change owners for various reasons, including acquisitions and litigation. As such, developers and vendors should explore a product's potential failure modes resulting from the loss of administrative control of a given domain for whatever reason.
但是，请注意，简单地硬编码DNS名称服务标识符而不是IP地址并不是万灵药。域名空间中的条目也是短暂的，可能会因为各种原因（包括收购和诉讼）而改变所有者。因此，无论出于何种原因，开发人员和供应商都应该探索由于失去对给定域的管理控制而导致的产品潜在故障模式。
Default configurations, documentation, and example configurations for Internet hosts should use Internet addresses that reside within special blocks that have been reserved for these purposes, rather than unique, globally-routable IP addresses. For IPv4, RFC 3330 [3] states that the 192.0.2.0/24 block has been assigned for use in documentation and example code. The IPv6 global unicast address prefix 2001:DB8::/32 has been similarly reserved for documentation purposes RFC 3849 [4]. Private Internet Addresses, as defined by RFC 1918 [5], should not be used for such purposes.
Internet主机的默认配置、文档和示例配置应使用驻留在为这些目的而保留的特殊块中的Internet地址，而不是唯一的、全局可路由的IP地址。对于IPv4，RFC 3330[3]声明192.0.2.0/24块已分配用于文档和示例代码中。IPv6全局单播地址前缀2001:DB8:：/32同样保留用于RFC 3849[4]的文档目的。RFC 1918[5]定义的专用互联网地址不应用于此类目的。
Service providers and enterprise network operators should advertise the identities of suitable local services, such as NTP. Very often these services exist, but the advertisement and automated configuration of their use is missing. For instance, the DHCP protocol, as defined by RFC 2132 [9], enables one to configure a server to answer client queries for service identifiers. When local services, including NTP, are available but not pervasively advertised using such common protocols, designers are more likely to deploy ad hoc initialization mechanisms that unnecessarily rely on central services.
服务提供商和企业网络运营商应公布合适的本地服务（如NTP）的身份。这些服务通常都存在，但它们的使用缺少广告和自动配置。例如，RFC 2132[9]定义的DHCP协议允许配置服务器来回答客户端对服务标识符的查询。当本地服务（包括NTP）可用但未使用此类通用协议进行广泛宣传时，设计者更可能部署不必要地依赖中央服务的即席初始化机制。
Operators who provide public services on the global Internet, such as those in the NTP community, should deprecate the explicit advertisement of the IP addresses of public services. These addresses are ephemeral. As such, their widespread citation in public service indexes interferes with the ability to reconfigure the service when necessary to address unexpected, increased traffic and the aforementioned problems.
在全球互联网上提供公共服务的运营商，如NTP社区的运营商，应反对公开公布公共服务的IP地址。这些地址是短暂的。因此，它们在公共服务指数中的广泛引用妨碍了在必要时重新配置服务的能力，以解决意外、增加的流量和上述问题。
Embedding or "hard-coding" IP addresses within a host's configuration often means that a host-based trust model is being employed, and that the Internet host with the given address is trusted in some way. Due to the ephemeral roles of globally-routable IP addresses, the practice of embedding them within products' firmware or default configurations presents a security risk in which unknown parties may be trusted inadvertently.
在主机配置中嵌入或“硬编码”IP地址通常意味着采用基于主机的信任模型，并且以某种方式信任具有给定地址的Internet主机。由于全球可路由IP地址的短暂作用，将其嵌入产品固件或默认配置的做法存在安全风险，未知方可能会在无意中受到信任。
Internet host designers may be tempted to implement some sort of remote control mechanism within a product, by which its Internet host configuration can be changed without reliance on, interaction with, or even the knowledge of, its operator or user. This raises security issues of its own. If such a scheme is implemented, its presence should be fully disclosed to the customer, operator, and user, so that an informed decision can be made, perhaps in accordance with local security or privacy policy. Furthermore, the significant possibility of malicious parties exploiting such a remote control mechanism may completely negate any potential benefit of the remote control scheme. Therefore, remote control mechanisms should be disabled by default, to be subsequently enabled and disabled by the user.
互联网主机设计人员可能会在产品中实施某种远程控制机制，通过这种机制，可以在不依赖其操作员或用户、与其交互甚至不了解其情况的情况下更改其互联网主机配置。这本身就引发了安全问题。如果实施了此类方案，则应向客户、运营商和用户充分披露其存在情况，以便可能根据当地安全或隐私政策做出知情决定。此外，恶意方利用这种远程控制机制的重大可能性可能完全否定远程控制方案的任何潜在好处。因此，默认情况下应禁用远程控制机制，然后由用户启用和禁用。
When large numbers of homogeneous Internet hosts are deployed, it is particularly important that both their designers and other members of the Internet community diligently assess host implementation quality and reconfigurability.
当部署大量同类Internet主机时，其设计者和Internet社区的其他成员认真评估主机实现质量和可重构性尤为重要。
Implementors of host services should avoid any kind of use of unique globally-routable IP addresses within a fixed configuration part of the service implementation. If there is a requirement for pre-configured state, then care should be taken to use an appropriate service identifier and to use standard mechanisms for dynamically resolving the identifier into an IP address. Also, any such identifiers should be alterable in the field through a conventional command and control interface for the service.
主机服务的实现者应该避免在服务实现的固定配置部分中使用唯一的全局可路由IP地址。如果需要预配置状态，则应注意使用适当的服务标识符，并使用标准机制将标识符动态解析为IP地址。此外，任何此类标识符应可通过服务的常规命令和控制接口在现场更改。
The author thanks the following reviewers for their contributions to this document: Paul Barford, Geoff Huston, David Meyer, Mike O'Connor, Michael Patton, Tom Petch, and Pekka Savola. Harald Alvestrand, Spencer Dawkins, Ted Hardie, David Kessens, and Thomas Narten provided valuable feedback during AD and IESG review.
作者感谢以下审稿人对本文的贡献：保罗·巴福德、杰夫·休斯顿、大卫·迈耶、迈克·奥康纳、迈克尔·巴顿、汤姆·佩奇和佩卡·萨沃拉。Harald Alvestrand、Spencer Dawkins、Ted Hardie、David Kessens和Thomas Narten在广告和IESG审查期间提供了宝贵的反馈。
[1] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D., and J. Postel, "Internet Registry IP Allocation Guidelines", BCP 12, RFC 2050, November 1996.
[1] K.哈伯德、M.科斯特斯、D.康拉德、D.卡伦伯格和J.波斯特尔，“互联网注册IP分配指南”，BCP 12，RFC 2050，1996年11月。
[2] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999.
[2] Eastlake 3rd，D.和A.Panitz，“保留顶级域名”，BCP 32，RFC 26061999年6月。
[3] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002.
[3] IANA，“特殊用途IPv4地址”，RFC 3330，2002年9月。
[4] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix Reserved for Documentation", RFC 3849, July 2004.
[4] Huston，G.，Lord，A.，和P.Smith，“保留用于文档的IPv6地址前缀”，RFC 3849，2004年7月。
[5] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[5] Rekhter，Y.，Moskowitz，B.，Karrenberg，D.，de Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[6] Hamilton, M. and R. Wright, "Use of DNS Aliases for Network Services", BCP 17, RFC 2219, October 1997.
[6] Hamilton，M.和R.Wright，“网络服务中DNS别名的使用”，BCP 17，RFC 2219，1997年10月。
[7] Carpenter, B., Crowcroft, J., and Y. Rekhter, "IPv4 Address Behaviour Today", RFC 2101, February 1997.
[7] Carpenter，B.，Crowcroft，J.，和Y.Rekhter，“今天的IPv4地址行为”，RFC 21011997年2月。
[8] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", RFC 2030, October 1996.
[8] Mills，D.，“IPv4、IPv6和OSI的简单网络时间协议（SNTP）第4版”，RFC 2030，1996年10月。
[9] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[9] Alexander，S.和R.Droms，“DHCP选项和BOOTP供应商扩展”，RFC 21321997年3月。
[10] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[10] Gulbrandsen，A.，Vixie，P.和L.Esibov，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2782，2000年2月。
[11] Plonka, D., "Flawed Routers Flood University of Wisconsin
Internet Time Server", August 2003.
http://www.cs.wisc.edu/~plonka/netgear-sntp/
[11] Plonka, D., "Flawed Routers Flood University of Wisconsin
Internet Time Server", August 2003.
http://www.cs.wisc.edu/~plonka/netgear-sntp/
In May 2003, the University of Wisconsin discovered that a network product vendor named NetGear had manufactured and shipped over 700,000 routers with firmware containing a hard-coded reference to the IP address of one of the University's NTP servers: 128.105.39.11, which was also known as "ntp1.cs.wisc.edu", a public stratum-2 NTP server.
2003年5月，威斯康星大学发现，一个名为网件的网络产品供应商已经制造并运载了超过700000台路由器，其中固件包含一个硬编码的参考，该IP地址是一所大学的NTP服务器：128105.3911，也称为“NTP1.C.WISC.EDU”，一个公共STATROM-2 NTP服务器。
Due to that embedded fixed configuration and an unrelated bug in the SNTP client, the affected products occasionally exhibit a failure mode in which each flawed router produces one query per second destined for the IP address 128.105.39.11, and hence produces a large scale flood of Internet traffic from hundreds of thousands of source addresses, destined for the University's network, resulting in significant operational problems.
由于该嵌入式固定配置和SNTP客户端中的一个不相关缺陷，受影响的产品偶尔会出现故障模式，其中每个有缺陷的路由器每秒产生一个指向IP地址128.105.39.11的查询，从而从数十万个源地址产生大规模互联网流量，目的地为大学网络，导致重大运营问题。
These flawed routers are widely deployed throughout the global Internet and are likely to remain in use for years to come. As such, the University of Wisconsin, with the cooperation of NetGear, will build a new anycast time service that aims to mitigate the damage caused by the misbehavior of these flawed routers.
这些有缺陷的路由器广泛部署在全球互联网上，并可能在未来几年继续使用。因此，威斯康星大学，与网件的合作，将建立一个新的任播时间服务，旨在减轻由这些缺陷路由器的不当行为造成的损害。
A technical report regarding the details of this situation is available on the world wide web: Flawed Routers Flood University of Wisconsin Internet Time Server [11].
有关这种情况的技术报告可在万维网上获得：有缺陷的路由器涌入威斯康星大学互联网时间服务器[11 ]。
Author's Address
作者地址
David Plonka University of Wisconsin - Madison
戴维-普朗卡威斯康星大学- Madison
EMail: plonka@doit.wisc.edu
URI: http://net.doit.wisc.edu/~plonka/
EMail: plonka@doit.wisc.edu
URI: http://net.doit.wisc.edu/~plonka/
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。