[要約] RFC 5889は、アドホックネットワークにおけるIPアドレッシングモデルに関する標準化文書です。その目的は、アドホックネットワーク内での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

アドホックネットワークのIPアドレス指定モデル

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によって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。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.

このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http://www.rfc-editor.org/info/rfc5889で取得できます。

Copyright Notice

著作権表示

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

Copyright(c)2010 IETF Trustおよび文書著者として特定された人。全著作権所有。

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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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 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.

ルーターは最終的に、ルーター自体で直接実行できる多様なアプリケーション、または接続されたホストまたはネットワークへの割り当てのために、追加のIPプレフィックスが必要になる場合があることに注意してください。IPv6の場合、これらのアドレスはグローバル[RFC3587]、一意のローカル[RFC4193]、またはLink-Local [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.

このドキュメントでは、[RFC1918]および[RFC4632]で定義されている語彙とIPv4の[RFC4632]、およびIPv6の[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.

このモデルは、Routerの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.

インターフェイスを接続するリンクが他のインターフェイスへの接続の仮定を有効にしない場合、「リンクで」と想定できるアドレスは、そのインターフェイス自体のアドレスです。リンクローカルアドレスは「リンク上」であると想定されていますが、セクション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 Autoconfigurationがルーティングプロトコルの最も広い配列に適用できます。

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.

IPv4はIPv4がそうでない可能性を提供しているため、このドキュメントで提供されているガイドラインはIPv6とIPv4でわずかに異なることに注意してください(つまり、IPv6インターフェイスにオンリンクサブネットプレフィックスを単純に構成しない可能性があります)。モデル。

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

o このインターフェイスで構成されたIPアドレスは、少なくともルーティングドメイン内で一意でなければならず、

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:

[RFC4291]に従ってIPv6リンクローカルアドレスが各インターフェイスに割り当てられているが、一般的には、近隣への接続性が常に変化している可能性があるため、リンクローカルアドレスは未定の接続性のリンクで有用性が限られていることに注意してください。既知の制限は次のとおりです。

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 一般に、IPv6リンクローカルアドレスが複数のリンクにわたって一意であることを保証するメカニズムはありませんが、修正されたEUI-64フォームのIIDを使用したリンクローカルアドレスはグローバルに一意でなければなりません。

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.

したがって、Autoconfigurationソリューションは、主にIPv6 Link-Localではない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

o このインターフェイスで構成されたIPアドレスは、少なくともルーティングドメイン内で一意でなければならず、

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).

このコンテキストでのIPv4リンクローカルアドレス[RFC3927]の使用は、IPv6リンクローカルアドレスのセクション6.1で概説されている制限がIPv4 Link-Localアドレスに関するものでもあるため、ほとんどのアプリケーションでは落胆する必要があることに注意してください。これらの制限は、選択する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] Hares、S。およびD. Katz、「管理ドメインとルーティングドメイン:インターネットでのルーティングのモデル」、RFC 1136、1989年12月。

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

[RFC4291] Hinden、R。およびS. Deering、「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] Cheshire、S.、Aboba、B。、およびE. Guttman、「IPv4 Link-Localアドレスの動的構成」、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.、Moskowitz、B.、Karrenberg、D.、De Groot、G。、およびE. Lear、「Private Internetsのアドレス割り当て」、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. Haberman、「ユニークなローカル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.、Deering、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] Fuller、V。およびT. Li、「クラスレス間ドメインルーティング(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.、Murphy、S。、およびY. Yang、「ルーティングプロトコルに対する一般的な脅威」、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.

この文書は、Teco Boot、Thomas Clausen、Ulrich Herberg、Thomas Narten、Erik Nordmark、Charles Perkins、Zach Shelby、Dave Thalerなど、(アルファベット順)(アルファベット順)を含む複数の個人からの議論と貢献を反映しています。

Authors' Addresses

著者のアドレス

Emmanuel Baccelli (editor) INRIA

エマニュエル・バッケリ(編集者)インリア

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

Mark Townsley (editor) Cisco Systems

マークタウンズリー(編集者)シスコシステム

   EMail: mark@townsley.net