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.
このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
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.
この文書は、インターネットホストでユニークな、グローバルにルーティング可能な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サブネットプレフィックスです。したがって、それらは時々、サービス識別子として使用されるunsolicted要求が向けられているために、又は所与の製品が何らかの形で特別扱いインターネットアドレスのセットを指定するサブネット識別子、など。
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アドレスの埋め込みました。ホストは主に、しかし、必ずしも個人または家庭用の低コストのルータとミドルボックスに限定されるものではありません。それは自動的に無効な送信元IPアドレスを持っているように見えるパケットを破棄することができるように別のケースでは、一度IANA（Internet Assigned Numbers Authority）によって予約された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アドレスを使用してサービスにアクセスしないことを要求します。その代わりに、彼らは、典型的には、[6] RFC 2219、ドメインネームシステムによって提供される間接参照のレベルに依存しています。適切に利用する場合、DNSは、メンテナンスのための資源を再構成すると負荷分散を行うために、ユーザーの関与なしとクライアントホストでの構成の変更を必要とせずにサービスオペレータを可能にします。例えば、一つの共通の負荷分散技術は、同じ名前を持つ複数のDNSレコードを採用します。返された答えのセットは、連続した問い合わせにラウンドロビン方式で回転させられます。 1は、このように一般のユーザーには不明のまま個別の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アドレスは、多くのインターネットホストの構成の中に埋め込まれている場合は、IPアドレスブロックは、その歴史的な使用によって妨げになります。これは、Internet Assigned Numbers Authority（IANA）の能力とインターネットレジストリ（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によって定義されるようなDHCPのような標準的な自動化されたコンフィギュレーションプロトコルを可能にするべきである[9]。これらの機能は、元々オペレータインタフェース内で無効にする必要があり、その後、これらの機能を有効にする機能が存在しているオペレータに警告すべきです。これは、問題が発生したときに、製品の所有者またはオペレータは、問題決意と緩和に参加できる可能性が高くなります。
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.
インターネットホストは、彼らが必要とインターネットサービスに関連付けられた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.com」で、このようなsntp-」として、名前「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リソースレコード（RR）を、利用することです。 SRVレコードは、基本ドメイン名と組み合わせてサービス固有の接頭辞を使用してRRの一般的なタイプです。例えば、SRV-認識しSNTPクライアントは「_ntp._udp.example.com」のためにルックアップするためにSRVタイプのクエリを実行することにより、実施例、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.
インターネットホストのためのデフォルト設定、ドキュメント、および構成例は、これらの目的ではなく、ユニークな、グローバルにルーティング可能な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など、適切なローカルサービスのアイデンティティを宣伝する必要があります。非常に多くの場合、これらのサービスが存在するが、その使用の広告と自動設定が不足しています。例えば、DHCPプロトコル、RFC 2132で定義されている[9]、サービス識別子のためのクライアントのクエリに答えるためにサーバーを設定することを可能。 NTPなどのローカルサービスは、利用可能な場合、しかしpervasively、このような共通のプロトコルを使用して広告を出していない、設計者は不必要、中央のサービスに依存しているアドホック初期化メカニズムを展開する可能性が高くなります。
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.
著者のおかげで、この文書への貢献のために、次のレビュー：ポールBarford、ジェフ・ヒューストン、デビッド・マイヤー、マイク・オコナー、マイケル・パットン、トム・ペッチ、およびペッカSavola。ハラルドAlvestrand、スペンサードーキンステッドハーディー、デヴィッドKessens、およびトーマス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]ハバード、K.、Kosters、M.、コンラッド、D.、Karrenberg、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]イーストレーク第3、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]ヒューストン、G.、主よ、A.、およびP.スミス、 "ドキュメンテーションのための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.、モスコウィッツ、B.、Karrenberg、D.、グルート、G.、およびE.リア、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]カーペンター、B.、クロウクロフト、J.、およびY. Rekhter、 "IPv4アドレス動作今日"、RFC 2101、1997年2月。
[8] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", RFC 2030, October 1996.
、RFC 2030 [8]ミルズ、D.、 "IPv4、IPv6、およびOSIのため簡易ネットワークタイムプロトコル（SNTP）バージョン4"、1996年10月。
[9] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[9]アレクサンダー、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の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.、「欠陥のあるルータウィスコンシンインターネット時刻サーバーの洪水大学」、2003年8月http://www.cs.wisc.edu/~plonka/netgear-sntp/
Appendix A. Background
付録A.背景
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.
まただった、128.105.39.11：2003年5月には、ウィスコンシン大学は、NetGearと名付けられたネットワーク製品ベンダーは、大学のNTPサーバーのいずれかのIPアドレスにハードコードされた参照を含むファームウェアで70万ルーターを製造・出荷していたことを発見しました「ntp1.cs.wisc.edu」、公共の地層-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宛て毎秒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との協力を得て、これらの欠陥のあるルータの不正行為による被害を軽減することを目指して、新たなエニータイムサービスを構築します。
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]：このような状況の詳細に関する技術報告書は、World Wide Web上で利用可能です。
Author's Address
著者のアドレス
David Plonka University of Wisconsin - Madison
ウィスコンシン州のデビッドPlonka大学 - マディソン
EMail: plonka@doit.wisc.edu URI: http://net.doit.wisc.edu/~plonka/
電子メール：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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。