[要約] 要約：RFC 4085は、グローバルにルーティング可能なインターネットアドレスの埋め込みが問題を引き起こす可能性があることを指摘している。 目的：このRFCの目的は、インターネットアドレスの適切な使用と管理に関するガイドラインを提供し、問題を回避するためのベストプラクティスを示すことです。
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
グローバルにルート可能なインターネットアドレスを埋め込むことは有害であると考えられています
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).
Copyright（c）The Internet Society（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.
このドキュメントでは、インターネットホストに一意のグローバルに普及可能な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
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.
最近の例の1つは、現在世界中で動作している数十万のインターネットホストのファームウェアにあるネットワーク時間プロトコルサーバーのグローバルにルート可能なIPアドレスの埋め込みでした。ホストは主にありますが、必ずしも低コストのルーターと個人用または住宅用のミドルボックスに限定されているわけではありません。別のケースでは、かつてインターネットに割り当てられた数字当局（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.
このドキュメントは、インターネットホストに一意のグローバルにルート可能な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 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アドレスを埋め込むことで、インターネットホストの数が増え、単一の中央インターネットサービスに依存しています。これにより、集計ワークロードがそのサービスを圧倒すると、サービスが停止する可能性があります。固定アドレスが増え続けるクライアント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.
多くのインターネットサービスの信頼性、スケーラビリティ、およびパフォーマンスには、ユーザーのプールがIPアドレスを直接使用してサービスにアクセスしないことが必要です。代わりに、彼らは通常、ドメイン名システムRFC 2219 [6]によって提供される間接レベルに依存しています。DNSは、適切に利用される場合、サービスオペレーターは、ユーザーの参加なしに、クライアントホストの構成変更の要件なしに、メンテナンスのリソースを再構成し、負荷分散を実行することを許可します。たとえば、1つの一般的な負荷分散手法では、同じ名前の複数のDNSレコードを採用しています。返される一連の回答は、連続したクエリでラウンドロビンの方法で回転します。クエリに対するこのような応答を受信すると、リゾルバーは通常、成功するまで回答を順番に試します。したがって、オペレーターは、一般的にユーザーには不明のままである個別の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アドレスブロックの有用性とモビリティを軽減し、操作コストを増加させます。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アドレスが埋め込まれると、IPアドレスブロックは歴史的な使用によって妨げられます。これは、IPアドレスブロックを有用に再配分するために、インターネットが割り当てられた番号登録局（IANA）とインターネットレジストリ（IR）階層の能力を妨げる可能性があります。同様に、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アドレスの最も一般的な用途の1つは、製品のよく知られているパブリックシンプルネットワークタイムプロトコル（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-Reservedの「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.
インターネットホストは、ドメイン名システムを使用して、必要なインターネットサービスに関連付けられた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.
展開されたインターネットホストの構成のサービス識別子としてドメイン名を使用する場合、デザイナーとベンダーはサービス名を導入することをお勧めします。これらの名前は、オペレーターとの契約（インターネットコミュニティが提供する公共サービスなど）で制御するか、利用することが許可されているドメイン内にある必要があります。これは一般に、ドメイン名にサービス固有のプレフィックスを導入することによって行われます。
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、Inc。」という名前のベンダードメイン「Example.com」は、「sntp-server.config.example.com」という名前または「sntp-などの製品とバージョンに固有の名前でさえ、その製品を設定するように製品を構成する可能性があります。server.v1.widget.config.example.com "。ここでは、「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クライアントは、「_ntp._udp.example.com」を検索するためにSRVタイプのクエリを実行することにより、SRVタイプのクエリを実行することにより、例の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.
ただし、IPアドレスではなく、単にハードコーディングDNSネームサービス識別子は万能薬ではないことに注意してください。ドメイン名スペースのエントリも一時的なものであり、買収や訴訟など、さまざまな理由で所有者を変更できます。そのため、開発者とベンダーは、何らかの理由で特定のドメインの管理制御が失われたことに起因する製品の潜在的な障害モードを調査する必要があります。
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.
インターネットホストのデフォルトの構成、ドキュメント、およびサンプル構成は、一意のグローバルにルート可能なIPアドレスではなく、これらの目的のために予約されている特別なブロック内にあるインターネットアドレスを使用する必要があります。IPv4の場合、RFC 3330 [3]は、192.0.2.0/24ブロックがドキュメントおよびサンプルコードで使用するために割り当てられていることを示しています。IPv6グローバルユニキャストアドレスプレフィックス2001：DB8 ::/32は、ドキュメントの目的で同様に予約されています。RFC3849[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アドレスは、ホストベースの信頼モデルが採用されており、指定されたアドレスを持つインターネットホストが何らかの方法で信頼されていることを意味します。グローバルにルート可能な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.
多数の均一なインターネットホストが展開される場合、デザイナーとインターネットコミュニティの他のメンバーの両方がホストの実装の品質と再構成性を熱心に評価することが特に重要です。
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は、ADおよび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] Hubbard、K.、Kosters、M.、Conrad、D.、Karrenberg、D。、およびJ. Postel、「インターネットレジストリ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、「予約済みのトップレベルDNS名」、BCP 32、RFC 2606、1999年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、「Private Internetsのアドレス割り当て」、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] ハミルトン、M。およびR.ライト、「ネットワークサービスのための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アドレスToday」、RFC 2101、1997年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用のSimple Network Time Protocol（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 2132、1997年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 RR（DNS SRV）」、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。、「ウィスコンシン州ウィスコンシン大学インターネットタイムサーバーの欠陥ルーターのフラッド大学」、2003年8月。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月、ウィスコンシン大学は、NetGearという名前のネットワーク製品ベンダーが、大学のNTPサーバーの1つのIPアドレスへのハードコーディング参照を含むファームウェアを備えた700,000ルーターを超えて出荷したことを発見しました。「ntp1.cs.wisc.edu」として知られています。
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向けに運命づけられた1秒あたりのクエリを生成する障害モードを示すことがあり、したがって大規模な洪水が生成される場合があります。大学のネットワークに向けられた数十万のソースアドレスからのインターネットトラフィックは、重大な運用上の問題をもたらしました。
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.
これらの欠陥のあるルーターは、グローバルなインターネット全体に広く展開されており、今後何年も使用され続ける可能性があります。そのため、ウィスコンシン大学は、NetGearの協力により、これらの欠陥のあるルーターの不正行為によって引き起こされる損害を軽減することを目的とした新しいAnycast Timeサービスを構築します。
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].
この状況の詳細に関する技術レポートは、World Wide Web：Flawed Routers Flood University of Wisconsin Internet Time Server [11]で入手できます。
Author's Address
著者の連絡先
David Plonka University of Wisconsin - Madison
ウィスコンシンのデビッド・プロンカ大学 - マディソン
EMail: plonka@doit.wisc.edu
URI: http://net.doit.wisc.edu/~plonka/
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンライン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-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。