RFC 5889 - IP Addressing Model in Ad Hoc Networks 日本語訳

URL : https://tools.ietf.org/html/rfc5889
タイトル : RFC 5889 - アドホックネットワークにおけるIPアドレス指定モデル
翻訳編集 : 自動生成

Internet Engineering Task Force (IETF)                  E. Baccelli, Ed.
Request for Comments: 5889                                         INRIA
Category: Informational                                 M. Townsley, Ed.
ISSN: 2070-1721                                            Cisco Systems
                                                          September 2010

                 IP Addressing Model in Ad Hoc Networks

Abstract

抽象

This document describes a model for configuring IP addresses and subnet prefixes on the interfaces of routers which connect to links with undetermined connectivity properties.

この文書は未定接続のプロパティとのリンクに接続するルータのインターフェイス上でIPアドレスとサブネットプレフィックスを設定するためのモデルについて説明します。

Status of This Memo

このメモのステータス

This document is not an Internet Standards Track specification; it is published for informational purposes.

このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.

このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 RFC 5741のセクション2を参照してください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5889.

このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5889で取得することができます。

著作権表示

著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   3.  Applicability Statement . . . . . . . . . . . . . . . . . . . . 4
   4.  IP Subnet Prefix Configuration  . . . . . . . . . . . . . . . . 4
   5.  IP Address Configuration  . . . . . . . . . . . . . . . . . . . 4
   6.  Addressing Model  . . . . . . . . . . . . . . . . . . . . . . . 5
     6.1.  IPv6 Model  . . . . . . . . . . . . . . . . . . . . . . . . 5
     6.2.  IPv4 Model  . . . . . . . . . . . . . . . . . . . . . . . . 6
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
   Appendix A.  Contributors . . . . . . . . . . . . . . . . . . . . . 7

1. Introduction

1. はじめに

The appropriate configuration of IP addresses and subnet masks for router network interfaces is generally a prerequisite to the correct functioning of routing protocols. Consideration of various items, including underlying link capabilities and connectivity, geographical topology, available address blocks, assumed traffic patterns etc., are used when determining the appropriate network topology and the associated IP interface configuration.

ルータネットワークインターフェイスのIPアドレスとサブネットマスクの適切な構成は、一般に、ルーティングプロトコルが正しく機能するための前提条件です。基本的なリンク機能と接続性、地理的トポロジー、利用可能なアドレスブロックを含む様々なアイテムの考慮事項は、適切なネットワークトポロジと関連するIPインターフェイスの設定を決定するときなど、トラフィックパターンが、使用されていると仮定する。

When the capabilities and connectivity of the links that connect routers are well-known and stable, logical network topology design and corresponding IP interface configuration are straightforward. Absent any assumption about link-level connectivity, however, there is no canonical method for determining a given IP interface configuration.

ルータを接続するリンクの機能と接続がよく知られており、安定している場合は、論理的なネットワークトポロジの設計とそれに対応するIPインタフェースの設定は簡単です。リンクレベルの接続性についての仮定が存在しない、しかし、与えられたIPインターフェイスコンフィギュレーションを決定するための正規の方法は存在しません。

Link-level connectivity is generally qualified as undetermined when it is unplanned and/or time-varying in character. Ad hoc networks are typical examples of networks with undetermined link-level connectivity. Routing protocols for ad hoc networks are purposely designed to detect and maintain paths across the network, even when faced with links with undetermined connectivity, assuming that routers' interfaces are configured with IP addresses. This document thus proposes a model for configuration of IP addresses and subnet prefixes on router interfaces to links with undetermined connectivity properties, to allow routing protocols and data packet forwarding to function.

それは計画外および/または時間的に変化する文字であるときに、リンクレベルの接続は、一般的に未定として認定されます。アドホックネットワークは未定リンクレベルの接続性を持つネットワークの典型的な例です。アドホックネットワークのルーティングプロトコルは、意図的にルータのインタフェースがIPアドレスで構成されていると仮定すると、未定の接続とのリンクに直面した場合でも、ネットワークを介してパスを検出し、維持するように設計されています。この文書は、このようなルーティングプロトコルとデータパケット転送が機能するように、未定の接続特性を有するリンクへのルータインターフェイス上のIPアドレスとサブネット・プレフィックスの構成のためのモデルを提案しています。

Note that routers may ultimately need additional IP prefixes for the diverse applications that could run directly on the routers themselves, or for assignment to attached hosts or networks. For

ルータは最終的にルータ自身上で直接実行できる多様なアプリケーションのために、または接続されたホストやネットワークへの割り当てのために追加のIPプレフィックスを必要とする場合があります。ために

IPv6, these addresses may be global [RFC3587], Unique-Local [RFC4193] or Link-Local [RFC4291]. For IPv4, the addresses may be global (i.e., public) or private [RFC1918]. In general, global scope is desired over local scope, though it is understood that this may not always be achievable via automatic configuration mechanisms. In this document however, automatic configuration of the prefixes used for general applications is considered as a problem that is separable from that of automatic configuration of addresses and prefixes necessary for routing protocols to function. This document thus focuses on the latter: the type of IP address and subnet mask configuration necessary for routing protocols and data packet forwarding to function.

IPv6は、これらのアドレスは、グローバルな[RFC3587]、ユニークなローカル[RFC4193]またはリンクローカル[RFC4291]かもしれません。 IPv4の場合、アドレスはグローバル（すなわち、パブリック）またはプライベート[RFC1918]であってもよいです。これが常に自動構成メカニズムを介して達成可能ではないかもしれないことが理解されるが、一般的に、グローバルスコープは、ローカルスコープ上に望まれています。しかし、この文書では、一般的な用途に使用されるプレフィックスの自動設定は、アドレスの自動構成のものから分離され、機能するルーティングプロトコルに必要なプレフィックス問題として考えられています。この文書では、このようにして後者に焦点を当てて：機能するプロトコルとデータパケット転送をルーティングするために必要なIPアドレスとサブネットマスクの構成の種類を。

2. Terminology

2.用語

This document uses the vocabulary and the concepts defined in [RFC1918] and [RFC4632] for IPv4, as well as [RFC4291] for IPv6.

この文書は、IPv6のための語彙とIPv4の[RFC1918]及び[RFC4632]で定義された概念と同様に、[RFC4291]を使用します。

3. Applicability Statement

3.適用性に関する声明

This model gives guidance about the configuration of IP addresses and the IP subnet prefixes on a router's IP interfaces, which connect to links with undetermined connectivity properties.

このモデルは未定接続のプロパティとのリンクに接続するルータのIPインタフェース、上のIPアドレスとIPサブネットプレフィックスの構成に関するガイダンスを提供します。

When more specific assumptions can be made regarding the connectivity between interfaces or the (persistent) reachability of some addresses, these should be considered when configuring subnet prefixes.

より具体的な仮定がインターフェイスまたはいくつかのアドレスの（永続的）到達可能性との間の接続について行うことができる場合、サブネット・プレフィックスを設定する場合、これらを考慮すべきです。

4. IP Subnet Prefix Configuration

4. IPサブネットプレフィックスの設定

If the link to which an interface connects enables no assumptions of connectivity to other interfaces, the only addresses that can be assumed "on link", are the address(es) of that interface itself. Note that while link-local addresses are assumed to be "on link", the utility of link-local addresses is limited as described in Section 6.

インターフェースが接続するリンクは、他のインターフェイスへの接続の仮定を可能にしない場合は、「リンク」と仮定することができる唯一のアドレスは、そのインターフェイス自体のアドレス（ES）です。リンクローカルアドレスは、「リンク」であると仮定されている間、セクション6で説明したように、リンクローカルアドレスの有用性が制限されることに留意されたいです。

Thus, subnet prefix configuration on such interfaces must not make any promises in terms of direct (one hop) IP connectivity to IP addresses other than that of the interface itself. This suggests the following principle:

したがって、そのようなインターフェイス上のサブネットプレフィックスの構成は、インタフェース自体のそれ以外のIPアドレスへの直接（1つのホップ）のIP接続性の点で任意の約束してはなりません。これは、次の原則を提案しています：

o no on-link subnet prefix should be configured on such an interface.

O無オンリンクサブネットプレフィックスは、インターフェイスに設定されなければなりません。

Note that if layer 2 communication is enabled between a pair of interfaces, IP packet exchange is also enabled, even if IP subnet configuration is absent or different on each of these interfaces.

IPサブネットの構成は、これらのインタフェースの各々に存在しないか又は異なっていても、レイヤ2通信インタフェースの対の間に有効になっている場合、IPパケット交換も有効になっていることに留意されたいです。

Also note that if, on the contrary, assumptions can be made regarding the connectivity between interfaces, or regarding the persistent reachability of some addresses, these should be considered when configuring IP subnet prefixes, and the corresponding interface(s) may in such case be configured with an on-link subnet prefix.

また場合は、逆に、仮定はインターフェイス間の接続について行うことができ、またはIPサブネットプレフィックスを設定する際に、いくつかのアドレスの永続的な到達可能性については、これらを考慮すべきであり、対応するインターフェース（複数可）は、このような場合であってもよいことに注意してくださいオンリンクサブネットプレフィックスで構成されました。

5. IP Address Configuration

5. IPアドレス設定

Routing protocols running on a router may exhibit different requirements for uniqueness of interface addresses; some have no such requirements, others have requirements ranging from local uniqueness only, to uniqueness within, at least, the routing domain (as defined in [RFC1136]).

ルータ上で実行されているルーティングプロトコルは、インターフェイスアドレスの一意性のためのさまざまな要件を示すことができます。いくつかは他のものは（[RFC1136]で定義されるように）、少なくとも、ルーティングドメイン内の一意性ために、唯一のローカル一意の範囲の要件を有する、そのような要件を持っていません。

Routing protocols that do not require unique IP addresses within the routing domain utilize a separate unique identifier within the routing protocol itself; such identifiers could be based on factory assignment or configuration.

ルーティングプロトコル自体の中に別の一意の識別子を利用ルーティングドメイン内で一意のIPアドレスを必要としないルーティングプロトコル。そのような識別子は、工場の割り当てや構成に基づくことができます。

Nevertheless, configuring an IP address that is unique within the routing domain satisfies the less stringent uniqueness requirements, while also enabling protocols that have the most stringent requirements of uniqueness within the routing domain. As a result, the following principle allows for IP autoconfiguration to apply to the widest array of routing protocols:

また、ルーティングドメイン内で一意の最も厳しい要件を持つプロトコルを可能にしながらもかかわらず、ルーティングドメイン内で一意であるIPアドレスを設定することは、それほど厳格で一意性の要件を満たしています。その結果、以下の原理は、ルーティングプロトコルの広い配列に適用するIPの自動設定が可能になります：

o an IP address assigned to an interface that connects to a link with undetermined connectivity properties should be unique, at least within the routing domain.

O未定の接続特性を有するリンクに接続するインターフェイスに割り当てられたIPアドレスは、少なくとも、ルーティングドメイン内で一意でなければなりません。

6. Addressing Model

6.モデルへの対応

Sections 4 and 5 describe principles for IP address and subnet prefix configuration on an interface of a router, when that interface connects to a link with undetermined connectivity properties. The following describes guidelines that follow from these principles, respectively for IPv6 and IPv4.

そのインターフェイスは、未定の接続特性を有するリンクに接続したときのセクション4及び5は、ルータのインターフェイスのIPアドレスとサブネットプレフィックス構成のための原理を説明しています。次は、IPv6とIPv4のために、それぞれ、これらの原理から従うガイドラインについて説明します。

Note that the guidelines provided in this document slightly differ for IPv6 and IPv4, as IPv6 offers possibilities that IPv4 does not (i.e., the possibility to simply not configure any on-link subnet prefix on an IPv6 interface), which provide a "cleaner" model.

IPv6が「きれい」を提供したIPv4は（すなわち、可能性は、単にIPv6インターフェイス上のすべてのオンリンクサブネットプレフィックスを設定しないように）しない可能性を提供していますように、この文書で提供されたガイドラインは若干、IPv6とIPv4のために異なることに注意してください型。

6.1. IPv6 Model

6.1. IPv6のモデル

For IPv6, the principles described in Sections 4 and 5 suggest the following rules:

IPv6の場合、セクション4および5に記載された原理は、以下のルールを提案します：

o An IP address configured on this interface should be unique, at least within the routing domain, and

このインターフェイス上で設定されたIPアドレスは、少なくともルーティングドメイン内で、一意である必要があり、O、及び

o No on-link subnet prefix is configured on this interface.

Oノーオンリンクサブネットプレフィックスは、このインターフェイス上に設定されています。

Note that while an IPv6 link-local address is assigned to each interface as per [RFC4291], in general link-local addresses are of limited utility on links with undetermined connectivity, as connectivity to neighbors may be constantly changing. The known limitations are:

近隣への接続が絶えず変化することができるように、一般に、リンクローカルアドレスは、未定の接続とのリンク上の限られた有用性のものであり、IPv6リンクローカルアドレスは[RFC4291]に従って各インターフェースに割り当てられていることに留意されたいです。既知の制限事項は以下のとおりです。

o In general, there is no mechanism to ensure that IPv6 link-local addresses are unique across multiple links, though link-local addresses using an IID that are of the modified EUI-64 form should be globally unique.

O一般に、修飾されたEUI-64形式のものでIIDを使用してリンクローカルアドレスは、グローバルに一意でなければならないが、IPv6リンクローカルアドレスは、複数のリンク全体で一意であることを保証するメカニズムはありません。

o Routers cannot forward any packets with link-local source or destination addresses to other links (as per [RFC4291]), while most of the time, routers need to be able to forward packets to/ from different links.

ほとんどの時間は、ルータが異なるリンクから/へパケットを転送できるようにする必要がありながら、Oルータは、（[RFC4291]あたりのような）他のリンクにリンクローカル送信元または宛先アドレスを持つパケットを転送することができません。

Therefore, autoconfiguration solutions should be encouraged to primarily focus on configuring IP addresses that are not IPv6 link-local.

そのため、自動ソリューションは、主に、IPv6のリンクローカルでないIPアドレスを設定するに注力するよう奨励されるべきです。

6.2. IPv4 Model

6.2. IPv4のモデル

For IPv4, the principles described in Sections 4 and 5 suggest rules similar to those mentioned for IPv6 in Section 6.1, that are:

IPv4の場合、セクション4および5に記載された原理は、セクション6.1でIPv6用に述べたものと同様の規則を、示唆しています。

o An IP address configured on this interface should be unique, at least within the routing domain, and

このインターフェイス上で設定されたIPアドレスは、少なくともルーティングドメイン内で、一意である必要があり、O、及び

o Any subnet prefix configured on this interface should be 32 bits long.

Oこのインターフェイスで構成された任意のサブネットプレフィックスは32ビット長であるべきです。

Note that the use of IPv4 link-local addresses [RFC3927] in this context should be discouraged for most applications, as the limitations outlined in Section 6.1 for IPv6 link-local addresses also concern IPv4 link-local addresses. These limitations are further exacerbated by the smaller pool of IPv4 link-local addresses to choose from and thus increased reliance on Duplicate Address Detection (DAD).

IPv6リンクローカルアドレスについては、セクション6.1で概説さの制限もIPv4リンクローカルアドレスに関係するとして、この文脈でIPv4リンクローカルアドレス[RFC3927]の使用は、ほとんどのアプリケーションのために落胆する必要があることに注意してください。これらの制限は、さらにから選択するIPv4リンクローカルアドレスの小さなプールによって悪化ので、重複アドレス検出（DAD）への依存度を高めています。

7. Security Considerations

7.セキュリティの考慮事項

This document focuses on the IP address and subnet mask configuration necessary for routing protocols and data packet forwarding to function. [RFC4593] describes generic threats to routing protocols, whose applicability is not altered by the presence of interfaces with undetermined connectivity properties. As such, the addressing model described in this document does not introduce new security threats.

この文書では、機能するためのプロトコルおよびデータ・パケット転送をルーティングするために必要なIPアドレスとサブネットマスクの設定に焦点を当てています。 [RFC4593]は適用未定の接続特性を有するインターフェースの存在によって変化しないルーティングプロトコルへの一般的な脅威を記述する。そのため、このドキュメントで説明するのアドレッシングモデルは、新たなセキュリティの脅威を導入しません。

However, the possible lack of pre-established infrastructure or authority, as enabled by the use of interfaces with undetermined connectivity properties, may render some of the attacks described in [RFC4593] easier to undertake. In particular, detection of malevolent misconfiguration may be more difficult to detect and to locate.

しかし、事前に確立されたインフラや権限の可能性欠如は、未定の接続性を有するインタフェースの使用によって可能と、[RFC4593]で説明された攻撃に着手しやすいの一部をレンダリングすることがあります。特に、悪意設定ミスの検出は、検出し見つけることがより困難であり得ます。

8. References

8.参照文献

8.1. Normative References

8.1. 引用規格

[RFC1136] Hares, S. and D. Katz, "Administrative Domains and Routing Domains: A model for routing in the Internet", RFC 1136, December 1989.

[RFC1136]野兎、S.及びD.カッツ、「管理ドメインとルーティングドメイン：インターネットにルーティングするためのモデル」、RFC 1136、1989年12月。

[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.

[RFC4291] HindenとR.とS.デアリング、 "IPバージョン6アドレッシング体系"、RFC 4291、2006年2月。

[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration of IPv4 Link-Local Addresses", RFC 3927, May 2005.

[RFC3927]チェシャー、S.、Aboba、B.、およびE.ガットマン、 "IPv4のリンクローカルアドレスの動的構成"、RFC 3927、2005年5月。

[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.

[RFC1918] Rekhter、Y.、モスコウィッツ、B.、Karrenberg、D.、グルート、G.、およびE.リアド、 "個人的なインターネットのための配分"、BCP 5、RFC 1918、1996年2月。

[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.

[RFC4193] HindenとR.とB.ハーバーマン、 "ユニークローカルIPv6ユニキャストアドレス"、RFC 4193、2005年10月。

[RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global Unicast Address Format", RFC 3587, August 2003.

[RFC3587] HindenとR.、デアリング、S.、およびE. Nordmarkと、 "IPv6のグローバルユニキャストアドレス形式"、RFC 3587、2003年8月。

[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, August 2006.

[RFC4632]フラー、V.およびT.李、 "クラスレスドメイン間ルーティング（CIDR）：インターネットアドレスの割り当てと集計プラン"、BCP 122、RFC 4632、2006年8月。

8.2. Informative References

8.2. 参考文献

[RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing Protocols", RFC 4593, October 2006.

[RFC4593] Barbir、A.、マーフィー、S.、およびY.ヤン、 "ルーティングプロトコルへの一般的な脅威"、RFC 4593、2006年10月。

Appendix A. Contributors

付録A.協力者

This document reflects discussions and contributions from several individuals including (in alphabetical order): Teco Boot, Thomas Clausen, Ulrich Herberg, Thomas Narten, Erik Nordmark, Charles Perkins, Zach Shelby, and Dave Thaler.

テコブーツ、トーマス・クラウゼン、ウルリッヒHerberg、トーマスNarten氏、エリックNordmarkと、チャールズ・パーキンス、ザックシェルビー、とDaveターラー：この文書は、（アルファベット順）を含むいくつかの個人からの議論と貢献を反映しています。

Authors' Addresses

著者のアドレス

Emmanuel Baccelli (editor) INRIA

エマニュエルBaccelli（編集者）INRIA

EMail: Emmanuel.Baccelli@inria.fr URI: http://www.emmanuelbaccelli.org/

電子メール：Emmanuel.Baccelli@inria.fr URI：http://www.emmanuelbaccelli.org/

Mark Townsley (editor) Cisco Systems

マークTownsley（エディタ）シスコシステムズ

EMail: mark@townsley.net

メールアドレス：mark@townsley.net