RFC1256 日本語訳
1256 ICMP Router Discovery Messages. S. Deering, Ed.. September 1991. (Format: TXT=43059 bytes) (Also RFC0792) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group S. Deering, Editor
Request for Comments: 1256 Xerox PARC
September 1991
ワーキンググループS.デアリング、コメントを求めるエディタ要求をネットワークでつないでください: 1256 ゼロックスPARC1991年9月
ICMP Router Discovery Messages
ICMPルータ発見メッセージ
Status of this Memo
このMemoの状態
This RFC specifies an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. This document is a product of the IETF Router Discovery Working Group. Distribution of this memo is unlimited.
このRFCはIAB標準化過程プロトコルをインターネットコミュニティに指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。 このドキュメントはIETF Routerディスカバリー作業部会の製品です。 このメモの分配は無制限です。
Abstract
要約
This document specifies an extension of the Internet Control Message Protocol (ICMP) to enable hosts attached to multicast or broadcast networks to discover the IP addresses of their neighboring routers.
このドキュメントは、マルチキャストに付けられたホストか放送網がそれらの隣接しているルータのIPアドレスを発見するのを可能にするためにインターネット・コントロール・メッセージ・プロトコル(ICMP)の拡大を指定します。
Table of Contents
目次
1. Terminology 1
2. Protocol Overview 3
3. Message Formats 5
4. Router Specification 7
4.1. Router Configuration Variables 7
4.2. Message Validation by Routers 9
4.3. Router Behavior 9
5. Host Specification 12
5.1. Host Configuration Variables 12
5.2. Message Validation by Hosts 13
5.3. Host Behavior 14
6. Protocol Constants 17
7. Security Considerations 17
References 18
Author's Address 19
1. 用語1 2。 概要3 3について議定書の中で述べてください。 メッセージ・フォーマット5 4。 ルータ仕様7 4.1。 ルータ構成変数7 4.2。 ルータ9 4.3のメッセージ合法化。 ルータの振舞い9 5。 仕様12 5.1を接待してください。 構成変数12 5.2を接待してください。 ホスト13 5.3のメッセージ合法化。 振舞い14 6を接待してください。 定数17 7について議定書の中で述べてください。 セキュリティ問題17参照18作者のアドレス19
1. Terminology
1. 用語
The following terms have a precise meaning when used in this document:
次の用語には、本書では使用されると、正確な意味があります:
system a device that implements the Internet Protocol, IP [9].
インターネットがプロトコルであると実装するデバイス、システムIP[9]。
router a system that forwards IP datagrams, as specified
ルータは指定されるとしてIPデータグラムを進めるシステムです。
Router Discovery Working Group [Page 1] RFC 1256 ICMP Router Discovery Messages September 1991
ルータ発見ワーキンググループ[1ページ]RFC1256ICMPルータ発見メッセージ1991年9月
in [2]. This does not include systems that, though
capable of IP forwarding, have that capability turned
off. Nor does it include systems that do IP forwarding
only insofar as required to obey IP Source Route
options.
[2]で。 これはIP推進ができますが、その能力をオフにするシステムを含んでいません。 また、それはIP Source Routeオプションに従うために必要に応じてその程度においてだけIP推進をするシステムを含んでいません。
host any system that is not a router.
ルータでないあらゆるシステムをホスティングしてください。
multicast unless otherwise qualified, means the use of either IP
multicast [4] or IP broadcast [6] service.
そうでなくない場合、マルチキャストは資格を得て、手段はIPマルチキャスト[4]かIP放送[6]サービスのどちらかの使用です。
link a communication facility or medium over which systems
can communicate at the link layer, i.e., the protocol
layer immediately below IP. The term "physical
network" has sometimes been used (imprecisely) for
this. Examples of links are LANs (possibly bridged to
other LANs), wide-area store-and-forward networks,
satellite channels, and point-to-point links.
システムがリンクレイヤで交信できる通信機器か媒体をリンクしてください、すなわち、IPのすぐ下のプロトコル層。 「物理ネットワーク」という用語はこれに時々(不正確に)使用されました。 リンクに関する例は、LAN(ことによると他のLANにブリッジされる)と、広い領域店とフォワードネットワークと、衛星チャンネルと、ポイントツーポイント接続です。
multicast link
a link over which IP multicast or IP broadcast service
is supported. This includes broadcast media such as
LANs and satellite channels, single point-to-point
links, and some store-and-forward networks such as SMDS
networks [8].
マルチキャストがどのIPマルチキャストの上にリンクをリンクするか、そして、またはIP放送サービスはサポートされます。 これがLANなどの電波媒体を含んでいて、衛星チャンネル、単一のポイントツーポイント接続、および或るものは、SMDSネットワーク[8]などのネットワークを保存して、進めます。
interface a system's attachment point to a link. It is possible
(though unusual) for a system to have more than one
interface to the same link. Interfaces are uniquely
identified by IP unicast addresses; a single interface
may have more than one such address.
システムの付着点をリンクに連結してください。 システムが同じリンクに1つ以上のインタフェースを持っているのは、可能です(珍しいのですが)。 インタフェースはIPユニキャストアドレスによって唯一特定されます。 単一のインタフェースには、そのようなアドレスの1つ以上があるかもしれません。
multicast interface
an interface to a multicast link, that is, an interface
to a link over which IP multicast or IP broadcast
service is supported.
マルチキャストがどのIPマルチキャストの上ですなわち、マルチキャストリンク、インタフェースへのインタフェースをリンクに連結するか、そして、またはIP放送サービスはサポートされます。
subnet either a single subnet of a subnetted IP network [7] or
a single non-subnetted IP network, i.e., the entity
identified by an IP address logically ANDed with its
assigned subnet mask. More than one subnet may exist
on the same link.
「副-網で覆」われたIPネットワーク[7]のただ一つのサブネットか単一の非「副-網で覆」われたIPのどちらかがネットワークでつなぐサブネット、すなわち、実体はIPアドレスを論理的に特定しました。割り当てられたサブネットマスクがあるANDed。 サブネットがそうする1つ以上は同じリンクの上に存在しています。
neighboring having an IP address belonging to the same subnet.
同じサブネットに属すIPアドレスがある近所付き合い。
Router Discovery Working Group [Page 2] RFC 1256 ICMP Router Discovery Messages September 1991
ルータ発見ワーキンググループ[2ページ]RFC1256ICMPルータ発見メッセージ1991年9月
2. Protocol Overview
2. プロトコル概要
Before a host can send IP datagrams beyond its directly-attached subnet, it must discover the address of at least one operational router on that subnet. Typically, this is accomplished by reading a list of one or more router addresses from a (possibly remote) configuration file at startup time. On multicast links, some hosts also discover router addresses by listening to routing protocol traffic. Both of these methods have serious drawbacks: configuration files must be maintained manually -- a significant administrative burden -- and are unable to track dynamic changes in router availability; eavesdropping on routing traffic requires that hosts recognize the particular routing protocols in use, which vary from subnet to subnet and which are subject to change at any time. This document specifies an alternative router discovery method using a pair of ICMP [10] messages, for use on multicast links. It eliminates the need for manual configuration of router addresses and is independent of any specific routing protocol.
ホストが直接付属しているサブネットを超えてIPデータグラムを送ることができる前に、それはそのサブネットで少なくとも1つの操作上のルータのアドレスを発見しなければなりません。 通常、これは、始動時に(ことによるとリモート)の構成ファイルから1つ以上のルータアドレスのリストを読むことによって、達成されます。 また、マルチキャストリンクの上では、何人かのホストが、ルーティング・プロトコルトラフィックを聞くことによって、ルータアドレスを発見します。 これらのメソッドの両方には、重大な欠点があります: 構成ファイルは、手動(重要な管理負担)で維持しなければならなくて、ルータの有用性におけるダイナミックな変化を追うことができません。 ルーティングトラフィックを立ち聞きするのは、いつでも変化するようにホストが使用中の特定のルーティング・プロトコルを認めるのを必要とします。(ルーティング・プロトコルは、サブネットによって異なって、受けることがあります)。 このドキュメントは、マルチキャストリンクにおける使用に1組のICMP[10]メッセージを使用することで代替のルータ発見メソッドを指定します。 それは、ルータアドレスの手動の構成の必要性を排除して、どんな特定のルーティング・プロトコルからも独立しています。
The ICMP router discovery messages are called "Router Advertisements" and "Router Solicitations". Each router periodically multicasts a Router Advertisement from each of its multicast interfaces, announcing the IP address(es) of that interface. Hosts discover the addresses of their neighboring routers simply by listening for advertisements. When a host attached to a multicast link starts up, it may multicast a Router Solicitation to ask for immediate advertisements, rather than waiting for the next periodic ones to arrive; if (and only if) no advertisements are forthcoming, the host may retransmit the solicitation a small number of times, but then must desist from sending any more solicitations. Any routers that subsequently start up, or that were not discovered because of packet loss or temporary link partitioning, are eventually discovered by reception of their periodic (unsolicited) advertisements. (Links that suffer high packet loss rates or frequent partitioning are accommodated by increasing the rate of advertisements, rather than increasing the number of solicitations that hosts are permitted to send.)
ICMPルータ発見メッセージは「ルータ通知とルータ懇願」と呼ばれます。 各ルータ、定期的に、それぞれのマルチキャストインタフェースからのRouter Advertisement、マルチキャスト発表IPはそのインタフェースの(es)を扱います。 ホストは、単に広告の聞こうとすることによって、それらの隣接しているルータのアドレスを発見します。 マルチキャストリンクに付けられたホストが始動すると、始動する、次の周期的なものが到着するのを待っているよりむしろ即座の広告を求めるマルチキャストa Router Solicitation。 (唯一、)、どんな広告も用意されていない、ホストは回の懇願のa少ない番号を再送するかもしれませんが、そして、それ以上の懇願を送るので、やめなければなりません。 次に、始動したか、またはパケット損失か一時的なリンク仕切りのために発見されなかったどんなルータも結局、彼らの周期的な(求められていない)広告のレセプションによって発見されます。 (高いパケット損失率か頻繁な仕切りを受けるリンクがホストが送ることを許可されている懇願の数を増強するよりむしろ広告の速度を増強することによって、設備されます。)
The router discovery messages do not constitute a routing protocol: they enable hosts to discover the existence of neighboring routers, but not which router is best to reach a particular destination. If a host chooses a poor first-hop router for a particular destination, it should receive an ICMP Redirect from that router, identifying a better one.
ルータ発見メッセージはルーティング・プロトコルを構成しません: 彼らは、ホストが、どのルータではなく、隣接しているルータの存在が特定の目的地に達するように最も良いかと発見するのを可能にします。 ホストが特定の目的地への貧しい最初に、ホップルータを選ぶなら、そのルータからICMP Redirectを受けるべきです、より良いものを特定して。
A Router Advertisement includes a "preference level" for each advertised router address. When a host must choose a default router address (i.e., when, for a particular destination, the host has not
Router Advertisementはそれぞれの広告を出しているルータアドレスのための「好みのレベル」を含んでいます。 ホストがデフォルトルータアドレスを選ばなければならない、(すなわち、特定の目的地に関して、ホストはそうしていません。
Router Discovery Working Group [Page 3] RFC 1256 ICMP Router Discovery Messages September 1991
ルータ発見ワーキンググループ[3ページ]RFC1256ICMPルータ発見メッセージ1991年9月
been redirected or configured to use a specific router address), it is expected to choose from those router addresses that have the highest preference level (see Section 3.3.1 in the Host Requirements -- Communication Layers RFC [1]). A network administrator can configure router address preference levels to encourage or discourage the use of particular routers as default routers.
最も高い好みのレベルを持っているそれらのルータアドレスから選ぶと予想されます。特定のルータアドレスを使用するために向け直されるか、または構成される、)、(Host Requirementsのセクション3.3.1を見てください--、コミュニケーションLayers RFC[1])。 ネットワーク管理者は、デフォルトルータとして特定のルータの使用に奨励するか、または水をさしているためにルータアドレス優先順位レベルを構成できます。
A Router Advertisement also includes a "lifetime" field, specifying the maximum length of time that the advertised addresses are to be considered as valid router addresses by hosts, in the absence of further advertisements. This is used to ensure that hosts eventually forget about routers that fail, become unreachable, or stop acting as routers.
また、Router Advertisementは「生涯」分野を含んでいます、最大の長さのホストによる有効なルータアドレスであるとみなされる広告を出しているアドレスがことである時間を指定して、さらなる広告がないとき。 これは、ルータとしてホストが結局失敗するルータを忘れるのを確実にするか、手が届かなくなるか、または行動するのを止めるのに使用されます。
The default advertising rate is once every 7 to 10 minutes, and the default lifetime is 30 minutes. This means that, using the default values, the advertisements are not sufficient as a mechanism for "black hole" detection, i.e., detection of failure of the first hop of an active path -- ideally, black holes should be detected quickly enough to switch to another router before any transport connections or higher-layer sessions time out. It is assumed that hosts already have mechanisms for black hole detection, as required by [1]. Hosts cannot depend on Router Advertisements for this purpose, since they may be unavailable or administratively disabled on any particular link or from any particular router. Therefore, the default advertising rate and lifetime values were chosen simply to make the load imposed on links and hosts by the periodic multicast advertisements negligible, even when there are many routers present. However, a network administrator who wishes to employ advertisements as a supplemental black hole detection mechanism is free to configure smaller values.
デフォルト広告率は、かつての7〜10分毎と、デフォルトです。寿命は30分です。 これは、デフォルト値を使用して、広告が「ブラックホール」検出のためのメカニズムとして十分でないことを意味します、すなわち、アクティブな経路の最初のホップの失敗の検出--理想的に、ブラックホールはどんな輸送の接続か、より高い層のセッションタイムアウトの前にも別のルータに切り替わることができるくらいすぐに検出されるべきです。 ホストにはブラックホール検出のためのメカニズムが必要に応じて[1]で既にあると思われます。 ホストはこのためにRouter Advertisementsを当てにすることができません、彼らが入手できないか、またはどんな特定のリンク、または、どんな特定のルータからも行政上障害があるかもしれないので。 したがって、デフォルト広告率と生涯値は、単に負荷をリンクに課させるために選ばれて、周期的なマルチキャストで取るにたらない状態で広告を主催します、多くの存在しているルータさえありさえするときさえ。 しかしながら、補足のブラックホール検出メカニズムとして広告を使いたがっているネットワーク管理者は自由により小さい値を構成できます。
Router Discovery Working Group [Page 4] RFC 1256 ICMP Router Discovery Messages September 1991
ルータ発見ワーキンググループ[4ページ]RFC1256ICMPルータ発見メッセージ1991年9月
3. Message Formats
3. メッセージ・フォーマット
ICMP Router Advertisement Message
ICMPルータ通知メッセージ
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num Addrs |Addr Entry Size| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router Address[1] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preference Level[1] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router Address[2] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preference Level[2] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
| . |
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| コード| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ヌムAddrs|Addrエントリーサイズ| 生涯| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ルータアドレス[1]| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 好みのレベル[1]| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ルータアドレス[2]| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 好みのレベル[2]| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | | . |
IP Fields:
IP分野:
Source Address An IP address belonging to the interface
from which this message is sent.
このメッセージが送られるインタフェースに属すソースAddress An IPアドレス。
Destination Address The configured AdvertisementAddress or the
IP address of a neighboring host.
構成されたAdvertisementAddressかIPが扱う隣接しているホストの目的地Address。
Time-to-Live 1 if the Destination Address is an IP
multicast address; at least 1 otherwise.
Destination Addressであるなら、生きる時間1はIPマルチキャストアドレスです。 少なくとも、1 そうでなければ。
ICMP Fields:
ICMP分野:
Type 9
9をタイプしてください。
Code 0
コード0
Checksum The 16-bit one's complement of the one's
complement sum of the ICMP message, start-
ing with the ICMP Type. For computing the
checksum, the Checksum field is set to 0.
1の補数の16ビットの1の補数がまとめるICMPメッセージのチェックサム、ICMP Typeとスタートing。 チェックサムを計算するのにおいて、Checksum分野は0に設定されます。
Router Discovery Working Group [Page 5] RFC 1256 ICMP Router Discovery Messages September 1991
ルータ発見ワーキンググループ[5ページ]RFC1256ICMPルータ発見メッセージ1991年9月
Num Addrs The number of router addresses advertised
in this message.
ルータの数が扱うヌムAddrsはこのメッセージに広告を出しました。
Addr Entry Size The number of 32-bit words of information
per each router address (2, in the version
of the protocol described here).
各ルータあたりの情報の32ビットの単語の数が扱うAddr Entry Size(ここで説明されたプロトコルのバージョンの2)。
Lifetime The maximum number of seconds that the
router addresses may be considered valid.
最大の数のルータアドレスが有効であると考えられるかもしれない秒の生涯。
Router Address[i], The sending router's IP address(es) on the
i = 1..Num Addrs interface from which this message is sent.
ルータAddress[i]、iに関する送付ルータのIPアドレス(es)=1。このメッセージが送られるヌムAddrsは連結します。
Preference Level[i], The preferability of each Router Address[i]
i = 1..Num Addrs as a default router address, relative to
other router addresses on the same subnet.
A signed, twos-complement value; higher
values mean more preferable.
好みのLevel[i]、それぞれのRouter Address[i]iの一層良いこと=1。デフォルトルータとしてのヌムAddrsは他のルータに比例して同じサブネットに関するアドレスを扱います。 署名していて、2補数の値。 より高い値は、より望ましいことを意味します。
ICMP Router Solicitation Message
ICMPルータ懇願メッセージ
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| コード| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP Fields:
IP分野:
Source Address An IP address belonging to the interface
from which this message is sent, or 0.
このメッセージが送られるインタフェースに属すソースAddress An IPアドレス、または0。
Destination Address The configured SolicitationAddress.
目的地Addressの構成されたSolicitationAddress。
Time-to-Live 1 if the Destination Address is an IP
multicast address; at least 1 otherwise.
Destination Addressであるなら、生きる時間1はIPマルチキャストアドレスです。 少なくとも、1 そうでなければ。
ICMP Fields:
ICMP分野:
Type 10
10をタイプしてください。
Code 0
コード0
Router Discovery Working Group [Page 6] RFC 1256 ICMP Router Discovery Messages September 1991
ルータ発見ワーキンググループ[6ページ]RFC1256ICMPルータ発見メッセージ1991年9月
Checksum The 16-bit one's complement of the one's
complement sum of the ICMP message, start-
ing with the ICMP Type. For computing the
checksum, the Checksum field is set to 0.
1の補数の16ビットの1の補数がまとめるICMPメッセージのチェックサム、ICMP Typeとスタートing。 チェックサムを計算するのにおいて、Checksum分野は0に設定されます。
Reserved Sent as 0; ignored on reception.
0として送った状態で、予約されます。 レセプションでは、無視されます。
4. Router Specification
4. ルータ仕様
4.1. Router Configuration Variables
4.1. ルータ構成変数
A router that implements the ICMP router discovery messages must allow for the following variables to be configured by system management; default values are specified so as to make it unnecessary to configure any of these variables in many cases.
ICMPルータが発見メッセージであると実装するルータは、以下の変数がシステム管理で構成されるのを許容しなければなりません。 デフォルト値は、多くの場合これらの変数のどれかを構成するのを不要にするように指定されます。
For each multicast interface:
各マルチキャストには、連結してください:
AdvertisementAddress
The IP destination address to be used for multicast
Router Advertisements sent from the interface. The
only permissible values are the all-systems multicast
address, 224.0.0.1, or the limited-broadcast address,
255.255.255.255. (The all-systems address is preferred
wherever possible, i.e., on any link where all
listening hosts support IP multicast.)
マルチキャストRouter Advertisementsに使用されるべきAdvertisementAddressの受信者IPアドレスはインタフェースから発信しました。 唯一の許容値が、マルチキャストが224.0に.0を扱うオールシステム.1、または限られた放送演説、255.255です。.255 .255。 (オールシステムアドレスはどこでも、どんなリンクでもすなわち、上すべての聴取ホストがIPマルチキャストをサポートする可能であるところで好まれます。)
Default: 224.0.0.1 if the router supports IP multicast
on the interface, else 255.255.255.255
デフォルト: 224.0.0.1 ルータが、インタフェース、255.255に関するほかのIPマルチキャストが.255であるとサポートする、.255
MaxAdvertisementInterval
The maximum time allowed between sending multicast
Router Advertisements from the interface, in seconds.
Must be no less than 4 seconds and no greater than 1800
seconds.
最大の時間が秒に送付マルチキャストRouter Advertisementsの間にインタフェースから許容したMaxAdvertisementInterval。 いいえは4秒未満と1800秒以下のそうであるに違いありませんか?
Default: 600 seconds
デフォルト: 600秒
MinAdvertisementInterval
The minimum time allowed between sending unsolicited
multicast Router Advertisements from the interface, in
seconds. Must be no less than 3 seconds and no greater
than MaxAdvertisementInterval.
最小の時間が秒に送付の求められていないマルチキャストRouter Advertisementsの間にインタフェースから許容したMinAdvertisementInterval。 いいえの3秒未満と、よりMaxAdvertisementIntervalはそうであるに違いありませんか?
Default: 0.75 * MaxAdvertisementInterval
デフォルト: 0.75*MaxAdvertisementInterval
Router Discovery Working Group [Page 7] RFC 1256 ICMP Router Discovery Messages September 1991
ルータ発見ワーキンググループ[7ページ]RFC1256ICMPルータ発見メッセージ1991年9月
AdvertisementLifetime
The value to be placed in the Lifetime field of Router
Advertisements sent from the interface, in seconds.
Must be no less than MaxAdvertisementInterval and no
greater than 9000 seconds.
AdvertisementLifetime、Router AdvertisementsのLifetime分野に置かれるべき値は秒にインタフェースから発信しました。 少なくともMaxAdvertisementIntervalと9000秒以下はそうであるに違いありませんか?
Default: 3 * MaxAdvertisementInterval
デフォルト: 3*MaxAdvertisementInterval
For each of the router's IP addresses on its multicast interfaces:
マルチキャストインタフェースのそれぞれのルータのIPアドレスのために:
Advertise
A flag indicating whether or not the address is to be
advertised.
アドレスが広告を出すかどうかことであることを示すA旗の広告を出してください。
Default: TRUE
デフォルト: 本当
PreferenceLevel
The preferability of the address as a default router
address, relative to other router addresses on the same
subnet. A 32-bit, signed, twos-complement integer,
with higher values meaning more preferable. The
minimum value (hex 80000000) is used to indicate that
the address, even though it may be advertised, is not
to be used by neighboring hosts as a default router
address.
デフォルトルータとしてのアドレスの一層良いことが同じサブネットに関する他のルータアドレスに比例して扱うPreferenceLevel。 より高い値が、より望ましいことを意味している32ビットの、そして、署名していて、2補数の整数。 最小値(十六進法80000000)は、それが広告に掲載されるかもしれませんが、アドレスがデフォルトルータアドレスとして隣接しているホストによって使用されないことであることを示すのに使用されます。
Default: 0
デフォルト: 0
The case in which it is useful to configure an address with a preference level of hex 80000000 (rather than simply setting its Advertise flag to FALSE) is when advertisements are being used for "black hole" detection, as mentioned in Section 2. In particular, a router that is to be used to reach only specific IP destinations could advertise its address with a preference level of hex 80000000 (so that neighboring hosts will not use it as a default router for reaching arbitrary IP destinations) and a non-zero lifetime (so that neighboring hosts that have been redirected or configured to use it can detect its failure by timing out the reception of its advertisements).
十六進法80000000の好みのレベルでアドレスを構成するのが役に立つ場合、(単にセットするよりむしろ、それ、広告、FALSEへの旗)、広告は「ブラックホール」検出に使用されています、セクション2で言及されるように時です。 特に、特定のIPの目的地だけに達するのに使用されることになっているルータは十六進法80000000(隣接しているホストが任意のIPの目的地に達するのにデフォルトルータとしてそれを使用しないように)の好みのレベルと非ゼロ生涯でアドレスの広告を出すかもしれません(それを使用するために向け直されるか、または構成された隣接しているホストがタイミングで広告のレセプションから失敗を検出できるように)。
It has been suggested that, when the preference level of an address has not been explicitly configured, a router could set it according to the metric of the router's "default route" (if it has one), rather than defaulting it to zero as suggested above. Thus, a router with a better metric for its default route would advertise a higher preference level for its address. (Note that routing metrics that are encoded such that "lower is better" would have to be inverted
アドレスの好みのレベルが明らかに構成されていないとき、ルータの「デフォルトルート」(それに1つがあるなら)のメートル法によると、ルータがデフォルトとするよりそれをむしろ設定できたことが提案された、それ、上に示されるようにゼロに合わせるために。 したがって、デフォルトルートにおける、よりよくメートル法のaがあるルータはアドレスのために、より高い好みのレベルの広告を出すでしょう。 (「低いのは、より良いこと」が逆にされなければならないようにコード化されるそんなに掘っている測定基準に注意してください。
Router Discovery Working Group [Page 8] RFC 1256 ICMP Router Discovery Messages September 1991
ルータ発見ワーキンググループ[8ページ]RFC1256ICMPルータ発見メッセージ1991年9月
before being used as preference levels in Router Advertisement messages.) Such a strategy might reduce the amount of ICMP Redirect traffic on some links by making it more likely that a host's first choice router for reaching an arbitrary destination is also the best choice. On the other hand, Redirect traffic is rarely a significant load on a link, and there are some cases where such a strategy would result in more Redirect traffic, not less (for example, on links from which the most frequently chosen destinations are best reached via routers other than the one with the best default route). This document makes no recommendation concerning this issue, and implementors are free to try such a strategy, as long as they also support static configuration of preference levels as specified above.
以前、好みとして使用されるのはRouter Advertisementでメッセージを平らにします。) そのような戦略は、いくつかのリンクでまた、任意の目的地に達するためのホストの最初の特選しているルータが最も良い選択であることをよりありそうにすることによって、ICMP Redirectトラフィックの量を減少させるかもしれません。 他方では、めったにRedirectトラフィックはリンクの上のかなりの負荷ではありません、そして、いくつかのケースがそれほど(例えば最も良いデフォルトルートで最も頻繁に選ばれた目的地にもの以外のルータで最も上手に達しているリンクの上に)ではなくそのような戦略が、より多くのRedirectトラフィックをもたらすところにあります。 このドキュメントはこの問題に関して推薦状を全くしません、そして、作成者は自由にそのような戦略を試みることができます、また、彼らが上で指定されるとして好みのレベルの静的な構成をサポートする限り。
4.2. Message Validation by Routers
4.2. ルータによるメッセージ合法化
A router must silently discard any received Router Solicitation messages that do not satisfy the following validity checks:
ルータは静かに以下のバリディティチェックを満たさないどんな受信されたRouter Solicitationメッセージも捨てなければなりません:
- IP Source Address is either 0 or the address of a neighbor
(i.e., an address that matches one of the router's own
addresses on the arrival interface, under the subnet mask
associated with that address.)
- IP Source Addressは隣人の0かアドレスのどちらかです。(すなわち、そのアドレスに関連しているサブネットマスクの下で到着インタフェースに関するルータの自己のアドレスの1つに合っているアドレス。)
- ICMP Checksum is valid.
- ICMP Checksumは有効です。
- ICMP Code is 0.
- ICMP Codeは0歳です。
- ICMP length (derived from the IP length) is 8 or more
octets.
- ICMPの長さ(IPの長さから、派生する)は8つ以上の八重奏です。
The contents of the ICMP Reserved field, and of any octets beyond the first 8, are ignored. Future, backward-compatible changes to the protocol may specify the contents of the Reserved field or of additional octets at the end of the message; backward-incompatible changes may use different Code values.
ICMP Reserved分野、および最初の8を超えたどんな八重奏の内容も無視されます。 プロトコルへの将来的で、後方コンパチブル変化はメッセージの終わりでReserved分野か追加八重奏のコンテンツを指定するかもしれません。 後方の非互換な変化は異なったCode値を使用するかもしれません。
A solicitation that passes the validity checks is called a "valid solicitation".
バリディティチェックを通過する懇願は「有効な懇願」と呼ばれます。
A router may silently discard any received Router Advertisement messages. Any other action on reception of such messages by a router (for example, as part of a "peer discovery" process) is beyond the scope of this document.
ルータは静かにどんな受信されたRouter Advertisementメッセージも捨てるかもしれません。 ルータ(例えば「同輩発見」プロセスの一部として)によるそのようなメッセージのレセプションへのいかなる他の動作もこのドキュメントの範囲を超えています。
4.3. Router Behavior
4.3. ルータの振舞い
The router joins the all-routers IP multicast group (224.0.0.2) on all interfaces on which the router supports IP multicast.
ルータがオールルータIPマルチキャストグループに加わる、(224.0 .0 .2) ルータがIPマルチキャストをサポートするすべてのインタフェースに関して。
Router Discovery Working Group [Page 9] RFC 1256 ICMP Router Discovery Messages September 1991
ルータ発見ワーキンググループ[9ページ]RFC1256ICMPルータ発見メッセージ1991年9月
The term "advertising interface" refers to any functioning and enabled multicast interface that has at least one IP address whose configured Advertise flag is TRUE. From each advertising interface, the router transmits periodic, multicast Router Advertisements, containing the following values:
「広告インタフェース」が少なくとも1IPがだれのものを扱うどんな機能していて可能にされたマルチキャストインタフェースも示す用語は、広告を構成しました。旗はTRUEです。 マルチキャストRouter Advertisements、それぞれの広告インタフェースから、ルータは周期的に伝わって、以下を含んでいると、以下は評価されます。
- In the destination address field of the IP header: the
interface's configured AdvertisementAddress.
- 目的地では、IPヘッダーの分野を扱ってください: インタフェースはAdvertisementAddressを構成しました。
- In the Lifetime field: the interface's configured
AdvertisementLifetime.
- Lifetimeでは、以下をさばいてください。 インタフェースはAdvertisementLifetimeを構成しました。
- In the Router Address[i] and Preference Level[i] fields:
all of the interface's addresses whose Advertise flags are
TRUE, along with their corresponding PreferenceLevel
values. (In the unlikely event that not all addresses fit
in a single advertisement, as constrained by the MTU of the
link, multiple advertisements are sent, with each except
the last containing as many addresses as can fit.)
- Router Address[i]とPreference Level[i]分野で: 広告、旗はそうです。インタフェースのすべてがだれのものを扱う、それらの対応するPreferenceLevel値に伴うTRUE。 (リンクのMTUによって抑制されるようにすべてのアドレスがただ一つの広告で合うというわけではないありそうもないイベントでは、多ページ広告を送ります、最終以外のそれぞれが合うことができるのと同じくらい多くのアドレスを含んでいて。)
The advertisements are not strictly periodic: the interval between subsequent transmissions is randomized to reduce the probability of synchronization with the advertisements from other routers on the same link. This is done by maintaining a separate transmission interval timer for each advertising interface. Each time a multicast advertisement is sent from an interface, that interface's timer is reset to a uniformly-distributed random value between the interface's configured MinAdvertisementInterval and MaxAdvertisementInterval; expiration of the timer causes the next advertisement to be sent from the interface, and a new random value to be chosen. (It is recommended that routers include some unique value, such as one of their IP or link-layer addresses, in the seed used to initialize their pseudo-random number generators. Although the randomization range is configured in units of seconds, the actual randomly-chosen values should not be in units of whole seconds, but rather in units of the highest available timer resolution.)
広告は厳密に周期的ではありません: その後のトランスミッションの間隔は、同じリンクで他のルータからの広告との同期の確率を減少させるためにランダマイズされます。 それぞれの広告インタフェースに別々のトランスミッションインタバルタイマを維持することによって、これをします。 マルチキャスト広告がインタフェースから送られる各回、そのインタフェースのタイマはインタフェースの構成されたMinAdvertisementIntervalとMaxAdvertisementIntervalの間の一様に分散している無作為の値にリセットされます。 タイマの満了で、選ばれるインタフェース、および新しい無作為の値から次の広告を送ります。 (ルータが何らかのユニークな値を含んでいるのは、お勧めです、それらのIPかリンクレイヤアドレスの1つなどのように、それらの疑似乱数生成器を初期化するのに使用される種子で。 無作為化範囲はユニットの秒に構成されますが、実際の手当たりしだいに選ばれた値がユニットの全体の秒、しかし、むしろ最も高い利用可能なタイマ解像度の単位にあるべきではありません。)
For the first few advertisements sent from an interface (up to MAX_INITIAL_ADVERTISEMENTS), if the randomly chosen interval is greater than MAX_INITIAL_ADVERT_INTERVAL, the timer should be set to MAX_INITIAL_ADVERT_INTERVAL instead. Using this smaller interval for the initial advertisements increases the likelihood of a router being discovered quickly when it first becomes available, in the presence of possible packet loss.
手当たりしだいに選ばれた間隔がマックス_INITIAL_ADVERT_INTERVALより大きいならインタフェース(マックス_INITIAL_ADVERTISEMENTSまでの)から送られたわずかな最初の広告において、タイマは代わりにマックス_INITIAL_ADVERT_INTERVALに設定されるべきです。 初期の広告のためにこのより小さい間隔を費やすと、最初に利用可能になるときすぐに発見されるルータの可能性は広げられます、可能なパケット損失の面前で。
In addition to the periodic, unsolicited advertisements, a router sends advertisements in response to valid solicitations received on any of its advertising interfaces. A router may choose to unicast
周期的で、求められていない広告に加えて、ルータは広告インタフェースのいずれでも受けられた有効な懇願に対応して広告を送ります。 ルータはユニキャストに選ばれるかもしれません。
Router Discovery Working Group [Page 10] RFC 1256 ICMP Router Discovery Messages September 1991
ルータ発見ワーキンググループ[10ページ]RFC1256ICMPルータ発見メッセージ1991年9月
the response directly to the soliciting host's address (if it is not zero), or multicast it to the interface's configured AdvertisementAddress; in the latter case, the interface's interval timer is reset to a new random value, as with unsolicited advertisements. A unicast response may be delayed, and a multicast response must be delayed, for a small random interval not greater than MAX_RESPONSE_DELAY, in order to prevent synchronization with other responding routers, and to allow multiple, closely-spaced solicitations to be answered with a single multicast advertisement.
直接請求しているホストのアドレス(それがゼロでないなら)、またはマルチキャストへの応答、それはAdvertisementAddressをインタフェースまで構成しました。 後者の場合では、インタフェースのインタバルタイマは未承諾広告のように新しい無作為の値にリセットされます。 ユニキャスト応答は遅れるかもしれません、そして、他の応じるルータとの同期を防いで、複数の、そして、密接に区切られた懇願がただ一つのマルチキャスト広告で答えられるのを許容するためにマックス_RESPONSE_DELAYほど大きくない小さい無作為の間隔の間、マルチキャスト応答を遅らせなければなりません。
If a router receives a solicitation sent to an IP broadcast address, on an interface whose configured AdvertisementAddress is an IP multicast address, the router may send its response to the IP broadcast address instead of the configured IP multicast address. Such an event indicates a configuration inconsistency, and should be logged for possible corrective action by the network administrator.
ルータが構成されたAdvertisementAddressがIPマルチキャストアドレスであるインタフェースでIP放送演説に送られた懇願を受けるなら、ルータは構成されたIPマルチキャストアドレスの代わりにIP放送演説への応答を送るかもしれません。 そのようなイベントは、構成矛盾を示して、可能な修正措置のためにネットワーク管理者によって登録されるべきです。
It should be noted that an interface may become an advertising interface at times other than system startup, as a result of recovery from an interface failure or through actions of system management such as:
インタフェースが時にはシステム起動か、インタフェース失敗からの回復の結果、以下などのシステム管理の動作を通して広告インタフェースになるかもしれないことに注意されるべきです。
- enabling the interface, if it had been administratively
disabled and it has one or more addresses whose Advertise
flag is TRUE, or
- 広告、インタフェースを可能にして、それが行政上無効にされて、それには1つがあるか、または以上がだれのものを扱うなら旗が可能にする、TRUE
- enabling IP forwarding capability (i.e., changing the
system from being a host to being a router), when the
interface has one or more addresses whose Advertise flag is
TRUE, or
- 広告、IP推進能力(すなわち、システムをホストであるのからルータに変える)を可能にして、インタフェースには1つがあるか、または以上がだれのものを扱うと旗が可能にする、TRUE
- setting the Advertise flag of one or more of the
interface's addresses to TRUE (or adding a new address with
a TRUE Advertise flag), when previously the interface had
no address whose Advertise flag was TRUE.
- 広告、いいえが以前にインタフェースでだれのものを扱ったとき、旗はそうでした。設定、広告、TRUEへのインタフェースのアドレスの1つ以上の旗、(TRUEと共に新しいアドレスを加える、広告、旗)、TRUE。
In such cases, the router must commence transmission of periodic advertisements on the new advertising interface, limiting the first few advertisements to intervals no greater than MAX_INITIAL_ADVERT_INTERVAL. In the case of a host becoming a router, the system must also join the all-routers IP multicast group on all interfaces on which the router supports IP multicast (whether or not they are advertising interfaces).
そのような場合、ルータは新しい広告インタフェースにおける周期的な広告の送信を始めなければなりません、わずかな最初の広告を間隔マックス_INITIAL_よりADVERT_INTERVALに制限して。 また、ホストがルータになる場合では、システムはルータがIPマルチキャストをサポートするすべてのインタフェースに関するオールルータIPマルチキャストグループに加わらなければなりません(それらが広告インタフェースであるか否かに関係なく)。
An interface may also cease to be an advertising interface, through actions of system management such as:
また、インタフェースは、広告インタフェースであることを以下などのシステム管理の動作でやめるかもしれません。
- administratively disabling the interface,
- 行政上、インタフェースを無効にします。
Router Discovery Working Group [Page 11] RFC 1256 ICMP Router Discovery Messages September 1991
ルータ発見ワーキンググループ[11ページ]RFC1256ICMPルータ発見メッセージ1991年9月
- shutting down the system, or disabling the IP forwarding
capability (i.e., changing the system from being a router
to being a host), or
- またはシステムを止めるか、またはIP推進が能力であることを損傷する、(すなわち、システムをルータであるのからホストに変えます)。
- setting the Advertise flags of all of the interface's
addresses to FALSE.
- 設定、広告、FALSEへのインタフェースのアドレスのすべての旗。
In such cases, it is recommended (but not required) that the router transmit a final multicast advertisement on the interface, identical to its previous transmission but with a Lifetime field of zero. In the case of a router becoming a host, the system must also depart from the all-routers IP multicast group on all interfaces on which the router supports IP multicast (whether or not they had been advertising interfaces).
そのような場合、ルータがインタフェースに関する最終的なマルチキャスト広告を伝えることが勧められます(しかし、必要ではありません)、前のトランスミッションにもかかわらず、ゼロのLifetime分野と同じです。 また、ルータがホストになる場合では、システムはルータがIPマルチキャストをサポートするすべてのインタフェースに関するオールルータIPマルチキャストグループから出発しなければなりません(それらが広告インタフェースであったか否かに関係なく)。
When the Advertise flag of one or more of an interface's addresses are set to FALSE by system management, but there remain other addresses on that interface whose Advertise flags are TRUE, it is recommended that the router send a single multicast advertisement containing only those address whose Advertise flags were set to FALSE, with a Lifetime field of zero.
広告、旗はそうでした。いつ、広告、1の旗かインタフェースのアドレスの以上がシステム管理でFALSEに設定されますが、残りもう一方がそのインタフェースでそこでは、だれのものを扱うか、広告、旗がTRUEである、ルータがそれらのアドレスだけを含むaただ一つのマルチキャスト広告を送るのが、お勧めである、だれのもの、ゼロのLifetime分野があるFALSEに、セットしました。
5. Host Specification
5. ホスト仕様
5.1. Host Configuration Variables
5.1. ホスト構成変数
A host that implements the ICMP router discovery messages must allow for the following variables to be configured by system management; default values are specified so as to make it unnecessary to configure any of these variables in many cases.
ICMPルータが発見メッセージであると実装するホストは、以下の変数がシステム管理で構成されるのを許容しなければなりません。 デフォルト値は、多くの場合これらの変数のどれかを構成するのを不要にするように指定されます。
For each multicast interface:
各マルチキャストには、連結してください:
PerformRouterDiscovery
A flag indicating whether or not the host is to perform
ICMP router discovery on the interface.
ホストがICMPルータ発見をインタフェースに実行することになっているかどうかを示しながら、PerformRouterDiscovery Aは弛みます。
Default: TRUE
デフォルト: 本当
SolicitationAddress
The IP destination address to be used for sending
Router Solicitations from the interface. The only
permissible values are the all-routers multicast
address, 224.0.0.2, or the limited-broadcast address,
255.255.255.255. (The all-routers address is preferred
wherever possible, i.e., on any link where all
advertising routers support IP multicast.)
送付Router Solicitationsにインタフェースから使用されるべきSolicitationAddressの受信者IPアドレス。 唯一の許容値が、マルチキャストが224.0に.0を扱うオールルータ.2、または限られた放送演説、255.255です。.255 .255。 (オールルータアドレスはどこでも、どんなリンクでもすなわち、上すべての広告ルータがIPマルチキャストをサポートする可能であるところで好まれます。)
Router Discovery Working Group [Page 12] RFC 1256 ICMP Router Discovery Messages September 1991
ルータ発見ワーキンググループ[12ページ]RFC1256ICMPルータ発見メッセージ1991年9月
Default: 224.0.0.2 if the host supports IP multicast on
the interface, else 255.255.255.255
デフォルト: 224.0.0.2 ホストが、インタフェース、255.255に関するほかのIPマルチキャストが.255であるとサポートする、.255
The Host Requirements -- Communication Layers RFC [1], Section 3.3.1.6, specifies that each host implementation must support a configurable list of default router addresses. The purpose of the ICMP router discovery messages is to eliminate the need to configure that list in hosts attached to multicast links. On non-multicast links, and on multicast links for which ICMP router discovery is not (yet) supported by the routers or is administratively disabled, it will continue to be necessary to configure the default router list in each host. Each entry in the list contains (at least) the following configurable variables:
Host Requirements--コミュニケーションLayers RFC[1]、セクション3.3 .1 .6 各ホスト導入がデフォルトルータアドレスの構成可能なリストをサポートしなければならないと指定します。 ICMPルータ発見メッセージの目的はマルチキャストリンクに付けられたホストでそのリストを構成する必要性をなくします。 非マルチキャストリンクの上と、そして、ICMPルータ発見がルータによって(まだ)サポートされていないか、または行政上無効にされるマルチキャストリンクの上では、それが、各ホストでデフォルトルータリストを構成するのにずっと必要でしょう。 リストにおける各エントリーは(少なくとも)以下の構成可能な変数を含んでいます:
RouterAddress
An IP address of a default router.
デフォルトルータのRouterAddress An IPアドレス。
Default: (none)
デフォルト: (なにも)
PreferenceLevel
The preferability of the RouterAddress as a default
router address, relative to other router addresses on
the same subnet. The Host Requirements RFC does not
specify how this value is to be encoded; to allow the
preference level to be conveyed in a Router
Advertisement or configured by system management, it is
here specified that it be encoded as a 32-bit, signed,
twos-complement integer, with higher values meaning
more preferable. The minimum value (hex 80000000) is
reserved to mean that the address is not to be used as
a default router address, i.e., it is to be used only
for specific IP destinations, of which the host has
been informed by ICMP Redirect or configuration.
デフォルトルータとしてのRouterAddressの一層良いことが同じサブネットに関する他のルータアドレスに比例して扱うPreferenceLevel。 Host Requirements RFCはコード化されるこの値がことである方法を指定しません。 指定されて、好みのレベルがRouter Advertisementを運ばれるか、またはシステム管理で構成されるのを許容するために、32ビットの、そして、署名していて、2補数の整数としてコード化されるのが、ここにそれがあります、より高い値が、より望ましいことを意味している状態で。 最小値(十六進法80000000)はアドレスがデフォルトルータアドレスとして使用されないことであることを意味するために予約されます、すなわち、それが特定のIPの目的地にだけ使用されることになっています。(そこでは、ホストにICMP Redirectか構成によって知らされました)。
Default: 0
デフォルト: 0
5.2. Message Validation by Hosts
5.2. ホストによるメッセージ合法化
A host must silently discard any received Router Advertisement messages that do not satisfy the following validity checks:
ホストは静かに以下のバリディティチェックを満たさないどんな受信されたRouter Advertisementメッセージも捨てなければなりません:
- ICMP Checksum is valid.
- ICMP Checksumは有効です。
- ICMP Code is 0.
- ICMP Codeは0歳です。
- ICMP Num Addrs is greater than or equal to 1.
- ICMPヌムAddrsは1歳以上です。
- ICMP Addr Entry Size is greater than or equal to 2.
- ICMP Addr Entry Sizeは2歳以上です。
Router Discovery Working Group [Page 13] RFC 1256 ICMP Router Discovery Messages September 1991
ルータ発見ワーキンググループ[13ページ]RFC1256ICMPルータ発見メッセージ1991年9月
- ICMP length (derived from the IP length) is greater than or
equal to 8 + (Num Addrs * Addr Entry Size * 4) octets.
- ICMPの長さ(IPの長さから、派生する)は8つ以上の+(ヌムAddrs*Addr Entry Size*4)八重奏です。
The contents of any additional words of per-address information (i.e., other than the Router Address and Preference Level fields), and the contents of any octets beyond the first 8 + (Num Addrs * Addr Entry Size * 4) octets, are ignored. Future, backward-compatible changes to the protocol may specify additional per-address information words, or additional octets at the end of the message; backward-incompatible changes may use different Code values.
アドレス情報(すなわち、Router AddressとPreference Level分野を除いた)のどんな追加単語のコンテンツ、および最初の8つの+(ヌムAddrs*Addr Entry Size*4)八重奏を超えたどんな八重奏のコンテンツも無視されます。 プロトコルへの将来的で、後方コンパチブル変化はメッセージの終わりで1アドレス情報あたりの追加単語、または追加八重奏を指定するかもしれません。 後方の非互換な変化は異なったCode値を使用するかもしれません。
An advertisement that passes the validity checks is called a "valid advertisement".
バリディティチェックを通過する広告は「有効な広告」と呼ばれます。
A host must silently discard any received Router Solicitation messages.
ホストは静かにどんな受信されたRouter Solicitationメッセージも捨てなければなりません。
5.3. Host Behavior
5.3. ホストの振舞い
On any interface on which the host supports IP multicast, the host will be a member of the all-systems IP multicast group (224.0.0.1). This occurs automatically, as specified in [4]; no explicit action is required on the part of the router discovery protocol implementation.
ホストがIPマルチキャストをサポートするどんなインタフェースでも、ホストがオールシステムIPマルチキャストグループのメンバーになる、(224.0 .0 .1)。 これは[4]で指定されるように自動的に起こります。 どんな明白な動作もルータ発見プロトコル実装側の必要ではありません。
A host never sends a Router Advertisement message.
ホストはRouter Advertisementメッセージを決して送りません。
A host silently discards any Router Advertisement message that arrives on an interface for which the host's configured PerformRouterDiscovery flag is FALSE, and it never sends a Router Solicitation on such an interface.
ホストは静かにホストの構成されたPerformRouterDiscovery旗がFALSEであるインタフェースで到着するどんなRouter Advertisementメッセージも捨てます、そして、それはそのようなインタフェースにRouter Solicitationを決して送りません。
A host cannot process an advertisement until it has determined its own IP address(es) and subnet mask(s) for the interface on which the advertisement is received. (On some links, a host may be able to use some combination of BOOTP [3], RARP [5], or ICMP Address Mask messages [7] to discover its own address and mask.) While waiting to learn the address and mask of an interface, a host may save any valid advertisements received on that interface for later processing; this allows router discovery and address/mask discovery to proceed in parallel.
それ自身のIPアドレス(es)とサブネットマスクを広告が受け取られているインタフェースに決定するまで、ホストは広告を処理できません。 (いくつかのリンクの上では、ホストはBOOTP[3]、RARP[5]、またはそれ自身のアドレスとマスクを発見するICMP Address Maskメッセージ[7]の何らかの組み合わせを使用できるかもしれません。) インタフェースのアドレスとマスクを学ぶのを待っている間、ホストは後で処理するためにそのインタフェースに受け取られたどんな有効な広告も保存するかもしれません。 これで、ルータ発見とアドレス/マスク発見は平行で続きます。
To process an advertisement, a host scans the list of router addresses contained in it. It ignores any non-neighboring addresses, i.e., addresses that do not match one of the host's own addresses on the arrival interface, under the subnet mask associated with that address. For each neighboring address, the host does the following:
広告を処理するために、ホストはそれに含まれたルータアドレスのリストをスキャンします。 それはどんな非隣接しているアドレスも無視します、すなわち、到着インタフェースに関するホストの自己のアドレスの1つに合っていないアドレス、そのアドレスに関連しているサブネットマスクの下で。 それぞれの隣接しているアドレスのために、ホストは以下をします:
- If the address is not already present in the host's default
- アドレスが既にホストのデフォルトで存在していないなら
Router Discovery Working Group [Page 14] RFC 1256 ICMP Router Discovery Messages September 1991
ルータ発見ワーキンググループ[14ページ]RFC1256ICMPルータ発見メッセージ1991年9月
router list, a new entry is added to the list, containing
the address along with its accompanying preference level
and a timer initialized to the Lifetime value from the
advertisement.
ルータリスト、新しいエントリーはリストに追加されます、広告からLifetime値に初期化された付随の好みのレベルとタイマに伴うアドレスを含んでいて。
- If the address is already present in the host's default
router list as a result of a previously-received
advertisement, its preference level is updated and its
timer is reset to the values in the newly-received
advertisement.
- アドレスが以前に受け取られていている広告の結果、ホストのデフォルトルータリストに既に存在しているなら、好みのレベルをアップデートします、そして、新たに受け取られていている広告における値にタイマをリセットします。
- If the address is already present in the host's default
router list as a result of system configuration, no change
is made to its preference level; there is no timer
associated with a configured address. (Note that any
router addresses acquired from the "Gateway" subfield of
the vendor extensions field of a BOOTP packet [11] are
considered to be configured addresses; they are assigned
the default preference level of zero, and they do not have
an associated timer. Note further that any address found
in the "giaddr" field of a BOOTP packet [3] identifies a
BOOTP forwarder which is not necessarily an IP router; such
an address should not be installed in the host's default
router list.)
- アドレスがシステム構成の結果、ホストのデフォルトルータリストに既に存在しているなら、変更を全く好みのレベルにしません。 構成されたアドレスに関連しているどんなタイマもありません。 (BOOTPパケット[11]のベンダー拡大分野の「ゲートウェイ」部分体から習得されたどんなルータアドレスも構成されたアドレスであると考えられることに注意してください。 ゼロのデフォルト好みのレベルはそれらに割り当てられます、そして、彼らは関連タイマを持っていません。 BOOTPパケット[3]の"giaddr"野原で発見されるどんなアドレスもBOOTP混載業者を特定することにさらに注意してください(必ずIPルータであるというわけではありません)。 ホストのデフォルトルータリストにそのようなアドレスをインストールするべきではありません。)
Whenever the timer expires in any entry that was created as a result of a received advertisement, that entry is discarded.
タイマが受け取られていている広告の結果、作成されたどんなエントリーでも期限が切れるときはいつも、そのエントリーは捨てられます。
To limit the storage needed for the default router list, a host may choose not to store all of the router addresses discovered via advertisements. If so, the host should discard those addresses with lower preference levels in favor of those with higher levels. It is desirable to retain more than one default router address in the list so that, if the current choice of default router is discovered to be down, the host may immediately choose another default router, without having to wait for the next advertisement to arrive.
デフォルトルータリストに必要であるストレージを制限するために、ホストは、広告で発見されたルータアドレスのすべてを保存しないのを選ぶかもしれません。 そうだとすれば、ホストは、より高いレベルがあるそれらを支持して下側の好みのレベルでそれらのアドレスを捨てるべきです。 リストの1つ以上のデフォルトルータアドレスを保有するのはデフォルトルータの現在の選択が下がっていると発見されるなら、ホストがすぐに別のデフォルトルータを選ぶことができるくらい望ましいです、次の広告が到着するのを待つ必要はなくて。
Any router address advertised with a preference level of hex 80000000 is not to be used by the host as default router address; such an address may be omitted from the default router list, unless its timer is being use as a "black-hole" detection mechanism, as discussed in Section 4.1.
十六進法80000000の好みのレベルで広告に掲載されたどんなルータアドレスもデフォルトルータアドレスとしてホストによって使用されないことです。 そのようなアドレスはデフォルトルータリストから省略されるかもしれません、タイマが「ブラックホール」検出メカニズムとして使用でないなら、セクション4.1で議論するように。
It should be understood that preference levels learned from advertisements do not affect any of the host's cached route entries. For example, if the host has been redirected to use a particular router address to reach a specific IP destination, it continues to use that router address for that destination, even if it discovers
広告から学習された好みのレベルがホストのキャッシュされたルートエントリーのいずれにも影響しないのが理解されるべきです。 例えば、ホストが特定のIPの目的地に達するのに特定のルータアドレスを使用するために向け直されたなら、その目的地にそのルータアドレスを使用し続けている、それは発見します。
Router Discovery Working Group [Page 15] RFC 1256 ICMP Router Discovery Messages September 1991
ルータ発見ワーキンググループ[15ページ]RFC1256ICMPルータ発見メッセージ1991年9月
another router address with a higher preference level. Preference levels influence the choice of router only for an IP destination for which there is no cached or configured route, or whose cached route points to a router that is subsequently discovered to be dead or unreachable.
より高い好みのレベルがある別のルータアドレス。 好みのレベルはキャッシュされたか構成されたルートが全くないか、またはキャッシュされたルートが次に死んでいるか、または手が届かないと発見されるルータを示すIPの目的地だけにルータの選択に影響を及ぼします。
A host is permitted (but not required) to transmit up to MAX_SOLICITATIONS Router Solicitation messages from any of its multicast interfaces after any of the following events:
ホストがマルチキャストインタフェースの以下のイベントのどれかから次々とマックス_SOLICITATIONS Router Solicitationメッセージまで伝わることが許可されています(しかし、必要ではありません):
- The interface is initialized at system startup time.
- インタフェースはシステム起動時に初期化されます。
- The interface is reinitialized after a temporary interface
failure or after being temporarily disabled by system
management.
- インタフェースは一時的なインタフェース失敗の後かシステム管理で一時無効にされた後に、再初期化されます。
- The system changes from being a router to being a host, by
having its IP forwarding capability turned off by system
management.
- システムはルータであるのからホストに変化します、システム管理でIP推進能力をオフにさせることによって。
- The PerformRouterDiscovery flag for the interface is
changed from FALSE to TRUE by system management.
- インタフェースへのPerformRouterDiscovery旗はシステム管理でFALSEからTRUEに変わります。
The IP destination address of the solicitations is the configured SolicitationAddress for the interface. The IP source address may contain zero if the host has not yet determined an address for the interface; otherwise it contains one of the interface's addresses.
懇願の受信者IPアドレスはインタフェースへの構成されたSolicitationAddressです。 ホストがまだインタフェースへのアドレスを決定していないなら、IPソースアドレスはゼロを含むかもしれません。 さもなければ、それはインタフェースのアドレスの1つを含んでいます。
If a host does choose to send a solicitation after one of the above events, it should delay that transmission for a random amount of time between 0 and MAX_SOLICITATION_DELAY. This serves to alleviate congestion when many hosts start up on a link at the same time, such as might happen after recovery from a power failure. (It is recommended that hosts include some unique value, such as one of their IP or link-layer addresses, in the seed used to initialize their pseudo-random number generators. Although the randomization range is specified in units of seconds, the actual randomly-chosen value should not be in units of whole seconds, but rather in units of the highest available timer resolution.)
ホストが、上のイベントの1つの後に懇願を送るのを選ぶなら、それは無作為の時間、0とマックス_SOLICITATION_DELAYの間でそのトランスミッションを遅らせるべきです。 これは、多くのホストが同時にリンクで始動するときの混雑を軽減するのに役立ちます。(混雑は停電からの回復の後に起こるかもしれません)。 (ホストが何らかのユニークな値を入れるのは、お勧めです、彼らのIPかリンクレイヤアドレスの1つなどのように、それらの疑似乱数生成器を初期化するのに使用される種子で。 無作為化範囲はユニットの秒に指定されますが、実際の手当たりしだいに選ばれた値がユニットの全体の秒、しかし、むしろ最も高い利用可能なタイマ解像度の単位にあるべきではありません。)
A host may also choose to further postpone its solicitations, subsequent to one of the above events, until the first time it needs to use a default router.
また、ホストは、さらに懇願を延期するのを選ぶかもしれません、上のイベントの1つにその後です、1回目にデフォルトルータを使用するのが必要になるまで。
Upon receiving a valid advertisement containing at least one neighboring address whose preference level is other than hex 80000000, subsequent to one of the above events, the host must desist from sending any solicitations on that interface (even if none have
上のイベントの1つへのその後の十六進法80000000を除いて、好みのレベルがある少なくとも1つの隣接しているアドレスを含む有効な広告を受け取ると、ホストがどんな懇願もそのインタフェースに送るのでやめなければならない、(なにもはそうしました。
Router Discovery Working Group [Page 16] RFC 1256 ICMP Router Discovery Messages September 1991
ルータ発見ワーキンググループ[16ページ]RFC1256ICMPルータ発見メッセージ1991年9月
been sent yet), until the next time one of the above events occurs. The small number of retransmissions of a solicitation, which are permitted if no such advertisement is received, should be sent at intervals of SOLICITATION_INTERVAL seconds, without randomization.
まだ送る、)、次回まで、上のイベントの1つは起こります。 SOLICITATION_INTERVAL秒ごとにそのようなどれか広告が受け取られていないなら受入れられる懇願の「再-トランスミッション」の少ない数を送るべきです、無作為化なしで。
6. Protocol Constants
6. プロトコル定数
Router constants:
ルータ定数:
MAX_INITIAL_ADVERT_INTERVAL 16 seconds
16秒のマックス_INITIAL_ADVERT_INTERVAL
MAX_INITIAL_ADVERTISEMENTS 3 transmissions
マックス_INITIAL_ADVERTISEMENTS3トランスミッション
MAX_RESPONSE_DELAY 2 seconds
2秒のマックス_RESPONSE_DELAY
Host constants:
定数を接待してください:
MAX_SOLICITATION_DELAY 1 second
マックス_SOLICITATION_DELAY1 2番目
SOLICITATION_INTERVAL 3 seconds
3秒のSOLICITATION_INTERVAL
MAX_SOLICITATIONS 3 transmissions
マックス_SOLICITATIONS3トランスミッション
Additional protocol constants are defined with the message formats in Section 3, and with the router and host configuration variables in Sections 4.1 and 5.1.
セクション3におけるメッセージ・フォーマット、ルータ、およびホスト構成変数がセクション4.1と5.1にある状態で、追加議定書定数は定義されます。
All protocol constants are subject to change in future revisions of the protocol.
プロトコル定数を条件としているすべてがこれから、プロトコルの改正を変えます。
7. Security Considerations
7. セキュリティ問題
This extension of ICMP makes it possible for any system attached to a link to masquerade as a default router for hosts attached to that link. Any traffic sent to such an imposter is vulnerable to eavesdropping, to denial of forwarding service, and to modification by insertion, deletion, or alteration of packets. It should be noted that, on most multicast or broadcast links on which this protocol is expected to operate, eavesdropping is already possible by any system attached to the link, and the Address Resolution Protocol (ARP) used on those links offers a similar opportunity for service denial and message stream modification. For environments where those threats are deemed unacceptable, there are configuration variables to disable dynamic router discovery by hosts.
ICMPのこの拡大で、そのリンクに付けられたホストのためにデフォルトルータのふりをするのはリンクに取り付けられたどんなシステムにも可能になります。 そのような詐欺師に送られたどんなトラフィックも推進サービスの否定に盗み聞くことと、そして、パケットの挿入、削除、または変更による変更に被害を受け易いです。 盗聴がほとんどのマルチキャストか放送リンクで上このプロトコルが作動すると予想されるリンクに取り付けられたどんなシステムでも既に可能であることに注意されるべきであり、それらのリンクの上に使用されるAddress Resolutionプロトコル(ARP)はサービス否定とメッセージストリーム変更の同様の機会を申し出ます。 それらの脅威が容認できないと考えられる環境のために、ホストによるダイナミックなルータ発見を無効にする構成変数があります。
The Router Advertisement message format is defined so as to allow additional information to be added to the message in a backward- compatible manner. One possible use of that capability is to add
Router Advertisementメッセージ・フォーマットは、追加情報が後方のコンパチブル方法によるメッセージに追加されるのを許容するために定義されます。 その能力の1つの活用可能性は加えることです。
Router Discovery Working Group [Page 17] RFC 1256 ICMP Router Discovery Messages September 1991
ルータ発見ワーキンググループ[17ページ]RFC1256ICMPルータ発見メッセージ1991年9月
digital signatures or some other form of authentication information to the advertisements, to enable hosts to verify their authenticity. This is FOR FURTHER STUDY.
または、デジタル化した署名、ある他の認証情報を広告に形成して、ホストが彼らの信憑性について確かめるのを可能にしてください。 これはFOR FURTHER STUDYです。
References
参照
[1] Braden, R., Editor, "Requirements for Internet Hosts --
Communication Layers", RFC 1122, USC/Information Sciences
Institute, October 1989.
[1] ブレーデン、R.、エディタ、「インターネットホストのための要件--コミュニケーションは層にする」、RFC1122、科学が設けるUSC/情報、10月1989日
[2] Braden, R., and J. Postel, "Requirements for Internet Gateways",
RFC 1009, USC/Information Sciences Institute, June 1987.
[2] ブレーデン、R.とJ.ポステル、「インターネットゲートウェイのための要件」RFC1009、科学が1987年6月に設けるUSC/情報。
[3] Croft, B, and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951,
Stanford and SUN Microsystems, September 1985.
[3] 耕地、BとJ.ギルモアと「プロトコル(BOOTP)を独力で進んでください」とRFC951とスタンフォードと太陽マイクロシステムズ、1985年9月。
[4] Deering, S., "Host Extensions for IP Multicasting", RFC 1112,
Stanford University, August 1989.
[4] デアリング、S.、「IPマルチキャスティングのためのホスト拡大」、RFC1112、スタンフォード大学、1989年8月。
[5] Finlayson, R., Mann, T., Mogul J., and M. Theimer, "A Reverse
Address Resolution Protocol", RFC 903, Stanford University, June
1984.
[5] フィンリースンとR.とマンとT.、ムガール人J.とM.Theimer、「逆アドレス解決プロトコル」RFC903、スタンフォード大学(1984年6月)。
[6] Mogul, J., "Broadcasting Internet Datagrams", RFC 919, Stanford
University, October 1984.
[6] ムガール人、J.、「放送インターネットデータグラム」、RFC919、スタンフォード大学、1984年10月。
[7] Mogul J., and J. Postel, "Internet Standard Subnetting
Procedure", RFC 950, USC/Information Sciences Institute, August
1985.
ムガール人J.、およびJ.ポステル、「インターネットの標準のサブネッティング手順」、RFC950、USC/情報科学が1985年8月に設ける[7]。
[8] Piscitello D., and J. Lawrence, "Transmission of IP datagrams
over the SMDS Service", RFC 1209, Bell Communications Research,
March, 1991.
[8]Piscitello D.、およびJ.ローレンス、「SMDS Serviceの上のIPデータグラムのトランスミッション」、RFC1209、ベルコミュニケーションズ・リサーチ(1991年3月)。
[9] Postel, J., "Internet Protocol - DARPA Internet Program Protocol
Specification", RFC 791, DARPA, September 1981.
[9] ポステル、J.、「インターネットは議定書を作ります--DARPAインターネットはプロトコル仕様をプログラムする」RFC791、DARPA、1981年9月。
[10] Postel, J., "Internet Control Message Protocol - DARPA Internet
Program Protocol Specification", RFC 792, USC/Information
Sciences Institute, September 1981.
[10] ポステル、J.、「インターネットはメッセージプロトコルを制御します--DARPAインターネットはプロトコル仕様をプログラムする」RFC792、科学が1981年9月に設けるUSC/情報。
[11] Reynolds, J., "BOOTP Vendor Information Extensions", RFC 1084,
USC/Information Sciences Institute, December 1988.
[11] レイノルズ、J.、「BOOTP売り主情報拡張子」、USC/情報科学が1988年12月に設けるRFC1084。
Router Discovery Working Group [Page 18] RFC 1256 ICMP Router Discovery Messages September 1991
ルータ発見ワーキンググループ[18ページ]RFC1256ICMPルータ発見メッセージ1991年9月
Author's Address
作者のアドレス
Stephen E. Deering
Xerox Palo Alto Research Center
3333 Coyote Hill Road
Palo Alto, CA 94304
スティーブンE.デアリングゼロックスパロアルト研究センター3333コヨーテヒル・Roadパロアルト、カリフォルニア 94304
Phone: (415) 494-4839
以下に電話をしてください。 (415) 494-4839
EMail: deering@xerox.com
メール: deering@xerox.com
Or send comments to gw-discovery@gregorio.stanford.edu.
または、コメントを gw-discovery@gregorio.stanford.edu に送ってください。
Router Discovery Working Group [Page 19]
ルータ発見ワーキンググループ[19ページ]
一覧
スポンサーリンク
