RFC4286 日本語訳
4286 Multicast Router Discovery. B. Haberman, J. Martin. December 2005. (Format: TXT=35540 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group B. Haberman
Request for Comments: 4286 JHU APL
Category: Standards Track J. Martin
Netzwert AG
December 2005
コメントを求めるワーキンググループB.ハーバーマンの要求をネットワークでつないでください: 4286年のJHU APLカテゴリ: 標準化過程J.マーチンNetzwert株式会社2005年12月
Multicast Router Discovery
マルチキャストルータ発見
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
The concept of Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) snooping requires the ability to identify the location of multicast routers. Since snooping is not standardized, there are many mechanisms in use to identify the multicast routers. However, this can lead to interoperability issues between multicast routers and snooping switches from different vendors.
インターネットGroup Managementプロトコル(IGMP)とMulticast Listenerディスカバリー(MLD)詮索の概念はマルチキャストルータの位置を特定する能力を必要とします。 以来、詮索は標準化されないで、マルチキャストルータを特定するために使用中の多くのメカニズムがあります。 しかしながら、これは異なったベンダーからのマルチキャストルータとスイッチについて詮索することの間の相互運用性問題に通じることができます。
This document introduces a general mechanism that allows for the discovery of multicast routers. This new mechanism, Multicast Router Discovery (MRD), introduces a standardized means of identifying multicast routers without a dependency on particular multicast routing protocols.
このドキュメントはマルチキャストの発見のためにルータを許容する一般的機構を紹介します。 この新しいメカニズム(Multicast Routerディスカバリー(MRD))は特定のマルチキャストルーティング・プロトコルで依存なしでマルチキャストルータを特定する標準化された手段を導入します。
Haberman, et al. Standards Track [Page 1] RFC 4286 Multicast Router Discovery December 2005
ハーバーマン、他 規格はマルチキャストルータ発見2005年12月にRFC4286を追跡します[1ページ]。
Table of Contents
目次
1. Introduction ....................................................3
2. Protocol Overview ...............................................3
3. Multicast Router Advertisement ..................................4
3.1. Advertisement Configuration Variables ......................4
3.1.1. AdvertisementInterval ...............................5
3.1.2. AdvertisementJitter .................................5
3.1.3. MaxInitialAdvertisementInterval .....................5
3.1.4. MaxInitialAdvertisements ............................5
3.1.5. NeighborDeadInterval ................................5
3.1.6. MaxMessageRate ......................................6
3.2. Advertisement Packet Format ................................6
3.2.1. Type Field ..........................................6
3.2.2. Advertisement Interval Field ........................6
3.2.3. Checksum Field ......................................6
3.2.4. Query Interval Field ................................7
3.2.5. Robustness Variable Field ...........................7
3.3. IP Header Fields ...........................................7
3.3.1. Source Address ......................................7
3.3.2. Destination Address .................................7
3.3.3. Time-to-Live / Hop Limit ............................7
3.3.4. IPv4 Protocol .......................................7
3.3.5. IPv6 Next Header ....................................7
3.4. Sending Multicast Router Advertisements ....................8
3.5. Receiving Multicast Router Advertisements ..................8
4. Multicast Router Solicitation ...................................9
4.1. Solicitation Packet Format .................................9
4.1.1. Type Field ..........................................9
4.1.2. Reserved Field ......................................9
4.1.3. Checksum Field ......................................9
4.2. IP Header Fields ..........................................10
4.2.1. Source Address .....................................10
4.2.2. Destination Address ................................10
4.2.3. Time-to-Live / Hop Limit ...........................10
4.2.4. IPv4 Protocol ......................................10
4.2.5. IPv6 Next Header ...................................10
4.3. Sending Multicast Router Solicitations ....................10
4.4. Receiving Multicast Router Solicitations ..................10
5. Multicast Router Termination ...................................11
5.1. Termination Packet Format .................................11
5.1.1. Type Field .........................................11
5.1.2. Reserved Field .....................................11
5.1.3. Checksum Field .....................................11
5.2. IP Header Fields ..........................................12
5.2.1. Source Address .....................................12
5.2.2. Destination Address ................................12
5.2.3. Time-to-Live / Hop Limit ...........................12
1. 序論…3 2. 概要について議定書の中で述べてください…3 3. マルチキャストルータ通知…4 3.1. 広告構成変数…4 3.1.1. AdvertisementInterval…5 3.1.2. AdvertisementJitter…5 3.1.3. MaxInitialAdvertisementInterval…5 3.1.4. MaxInitialAdvertisements…5 3.1.5. NeighborDeadInterval…5 3.1.6. MaxMessageRate…6 3.2. 広告パケット・フォーマット…6 3.2.1. 分野をタイプしてください…6 3.2.2. 広告間隔分野…6 3.2.3. チェックサム分野…6 3.2.4. 間隔分野について質問してください…7 3.2.5. 丈夫さ変数フィールド…7 3.3. IPヘッダーフィールド…7 3.3.1. ソースアドレス…7 3.3.2. 送付先アドレス…7 3.3.3. 生きる時間/ホップ限界…7 3.3.4. IPv4は議定書を作ります…7 3.3.5. IPv6次ヘッダー…7 3.4. マルチキャストルータ通知を送ります…8 3.5. マルチキャストルータ通知を受け取ります…8 4. マルチキャストルータ懇願…9 4.1. 懇願パケット・フォーマット…9 4.1.1. 分野をタイプしてください…9 4.1.2. 分野を予約します…9 4.1.3. チェックサム分野…9 4.2. IPヘッダーフィールド…10 4.2.1. ソースアドレス…10 4.2.2. 送付先アドレス…10 4.2.3. 生きる時間/ホップ限界…10 4.2.4. IPv4は議定書を作ります…10 4.2.5. IPv6次ヘッダー…10 4.3. マルチキャストルータ懇願を送ります…10 4.4. マルチキャストルータ懇願を受けます…10 5. マルチキャストルータ終了…11 5.1. 終了パケット・フォーマット…11 5.1.1. 分野をタイプしてください…11 5.1.2. 分野を予約します…11 5.1.3. チェックサム分野…11 5.2. IPヘッダーフィールド…12 5.2.1. ソースアドレス…12 5.2.2. 送付先アドレス…12 5.2.3. 生きる時間/ホップ限界…12
Haberman, et al. Standards Track [Page 2] RFC 4286 Multicast Router Discovery December 2005
ハーバーマン、他 規格はマルチキャストルータ発見2005年12月にRFC4286を追跡します[2ページ]。
5.2.4. IPv4 Protocol ......................................12
5.2.5. IPv6 Next Header ...................................12
5.3. Sending Multicast Router Terminations .....................12
5.4. Receiving Multicast Router Terminations ...................12
6. Protocol Constants .............................................13
7. Security Considerations ........................................13
8. IANA Considerations ............................................14
9. Acknowledgements ...............................................15
10. References ....................................................15
10.1. Normative References .....................................15
10.2. Informative Reference ....................................16
5.2.4. IPv4は議定書を作ります…12 5.2.5. IPv6次ヘッダー…12 5.3. マルチキャストルータ終了を送ります…12 5.4. マルチキャストルータ終了を受けます…12 6. 定数について議定書の中で述べてください…13 7. セキュリティ問題…13 8. IANA問題…14 9. 承認…15 10. 参照…15 10.1. 標準の参照…15 10.2. 有益な参照…16
1. Introduction
1. 序論
Multicast Router Discovery (MRD) messages are useful for determining which nodes attached to a switch have multicast routing enabled. This capability is useful in a layer-2 bridging domain with snooping switches. By utilizing MRD messages, layer-2 switches can determine where to send multicast source data and group membership messages [1] [2]. Multicast source data and group membership reports must be received by all multicast routers on a segment. Using the group membership protocol Query messages to discover multicast routers is insufficient due to query suppression.
スイッチに取り付けられたどのノードでマルチキャストルーティングを可能にするかを決定することのマルチキャストRouterディスカバリー(MRD)メッセージは役に立ちます。 この能力は、スイッチについて詮索するので、層-2ブリッジするドメインで役に立ちます。 MRDメッセージを利用することによって、層-2個のスイッチが、マルチキャストソースデータとグループ会員資格メッセージ[1][2]をどこに送るかを決定できます。 すべてのマルチキャストルータはセグメントにマルチキャストソースデータとグループ会員資格レポートを受け取らなければなりません。 マルチキャストルータを発見するグループ会員資格プロトコルQueryメッセージを使用するのは質問抑圧のために不十分です。
Although MRD messages could be sent as ICMP messages, the group management protocols were chosen since this functionality is multicast specific. The addition of this functionality to the group membership protocol also allows operators to have congruence between MRD problems and data forwarding issues.
ICMPメッセージとしてMRDメッセージを送ることができましたが、この機能性がマルチキャスト特有であるので、グループ管理プロトコルを選びました。 また、グループ会員資格プロトコルへのこの機能性の追加で、オペレータはMRD問題とデータ推進問題の間に適合を持つことができます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [3].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[3]で説明されるように本書では解釈されることであるべきですか?
2. Protocol Overview
2. プロトコル概要
Multicast Router Discovery consists of three messages for discovering multicast routers. The Multicast Router Advertisement is sent by routers to advertise that IP multicast forwarding is enabled. Devices may send Multicast Router Solicitation messages in order to solicit Advertisement messages from multicast routers. The Multicast Router Termination messages are sent when a router stops IP multicast routing functions on an interface.
マルチキャストRouterディスカバリーはマルチキャストルータを発見することへの3つのメッセージから成ります。 ルータでMulticast Router Advertisementを送って、IPマルチキャスト推進が可能にされるのは広告を出します。 デバイスは、マルチキャストルータからのAdvertisementメッセージに請求するためにメッセージをMulticast Router Solicitationに送るかもしれません。 ルータがインタフェースでIPマルチキャスト経路選択機能を止めると、Multicast Router Terminationメッセージを送ります。
Multicast routers send unsolicited Advertisements periodically on all interfaces on which multicast forwarding is enabled. Advertisement messages are also sent in response to Solicitations. In addition to advertising the location of multicast routers, Advertisements also
マルチキャストルータは定期的にマルチキャスト推進が可能にされるすべてのインタフェースに求められていないAdvertisementsを送ります。 また、Solicitationsに対応して広告メッセージを送ります。 マルチキャストルータ、Advertisementsの位置も広告を出すことに加えて
Haberman, et al. Standards Track [Page 3] RFC 4286 Multicast Router Discovery December 2005
ハーバーマン、他 規格はマルチキャストルータ発見2005年12月にRFC4286を追跡します[3ページ]。
convey useful information concerning group management protocol variables. This information can be used for consistency checking on the subnet.
集団経営プロトコル変数に関して役に立つ情報を伝えてください。 サブネットについて検査する一貫性にこの情報を使用できます。
A device sends Solicitation messages whenever it wishes to discover multicast routers on a directly attached link.
直接付属しているリンクの上にマルチキャストルータを発見したがっているときはいつも、デバイスはメッセージをSolicitationに送ります。
A router sends Termination messages when it terminates multicast routing functionality on an interface.
それがインタフェースに関するマルチキャストルーティングの機能性を終えると、ルータはメッセージをTerminationに送ります。
All MRD messages are sent with an IPv4 Time to Live (TTL) or IPv6 Hop Limit of 1 and contain the Router Alert Option [4] [5]. All MRD messages SHOULD be rate-limited as per the MaxMessageRate variable.
すべてのMRDメッセージが、IPv4 Timeと共に1のLive(TTL)かIPv6 Hop Limitに送られて、Router Alert Option[4][5]を含んでいます。 すべてのMRDメッセージSHOULDがMaxMessageRate変数のようにレートによって限られます。
Advertisement and Termination messages are sent to the All-Snoopers multicast address.
All-詮索好きマルチキャストアドレスに広告とTerminationメッセージを送ります。
Solicitation messages are sent to the All-Routers multicast address.
All-ルータマルチキャストアドレスに懇願メッセージを送ります。
Any data beyond the fixed message format MUST be ignored.
固定メッセージ・フォーマットを超えたどんなデータも無視しなければなりません。
3. Multicast Router Advertisement
3. マルチキャストルータ通知
Multicast Router Advertisements are sent unsolicited periodically on all router interfaces on which multicast forwarding is enabled. They are also sent in response to Multicast Router Solicitation messages.
マルチキャストRouter Advertisementsを送る、求められていなさ、どのマルチキャスト推進が可能にされるかに関してすべてのルータで定期的に連結します。 また、Multicast Router Solicitationメッセージに対応してそれらを送ります。
Advertisements are sent
広告を送ります。
1. Upon the expiration of a periodic (modulo randomization) timer
1. 周期的な(法無作為化)タイマの満了に関して
2. As part of a router's start-up procedure
2. ルータの始動手順の一部として
3. During the restart of a multicast forwarding interface
3. マルチキャスト推進インタフェースの再開の間
4. On receipt of a Solicitation message
4. Solicitationメッセージを受け取り次第
All Advertisements are sent as Internet Group Management Protocol (for IPv4) or Multicast Listener Discovery (for IPv6) messages to the All-Snoopers multicast address. These messages SHOULD be rate- limited as per the MaxMessageRate variable.
インターネットGroup Managementプロトコル(IPv4のための)かMulticast Listenerディスカバリー(IPv6のための)メッセージとしてAll-詮索好きマルチキャストアドレスにすべてのAdvertisementsを送ります。 MaxMessageRateに従って制限されたレートが可変であったなら、これらはSHOULDを通信させます。
3.1. Advertisement Configuration Variables
3.1. 広告構成変数
An MRD implementation MUST support the following variables being configured by system management. Default values are specified to make it unnecessary to configure any of these variables in many cases.
MRD実装はシステム管理で構成される以下の変数をサポートしなければなりません。 デフォルト値は、多くの場合これらの変数のどれかを構成するのを不要にするように指定されます。
Haberman, et al. Standards Track [Page 4] RFC 4286 Multicast Router Discovery December 2005
ハーバーマン、他 規格はマルチキャストルータ発見2005年12月にRFC4286を追跡します[4ページ]。
3.1.1. AdvertisementInterval
3.1.1. AdvertisementInterval
This variable is the base interval (in integer seconds) between the transmissions of unsolicited Advertisements on an interface. This value MUST be no less than 4 seconds and no greater than 180 seconds.
この変数はインタフェースにおける求められていないAdvertisementsのトランスミッションのベース間隔(整数秒の)です。 この値は4秒未満と180秒以下ノーでなければなりません。
Default: 20 seconds
デフォルト: 20秒
3.1.2. AdvertisementJitter
3.1.2. AdvertisementJitter
This is the maximum time (in seconds) by which the AdvertisementInterval is perturbed for each unsolicited Advertisement. Note that the purpose of this jitter is to avoid synchronization of multiple routers on a network, hence choosing a value of zero is discouraged. This value MUST be an integer no less than 0 seconds and no greater than AdvertisementInterval.
これは最大の時間(秒の)です。AdvertisementIntervalがそれぞれの求められていないAdvertisementのために混乱させられている このジターの目的がネットワークにおける複数のルータの同期を避けることであり、したがって、ゼロの値を選ぶのがお勧めできないことに注意してください。 この値は、0秒未満の整数ノー、と、よりAdvertisementInterval以下でなければなりません。
The AdvertisementJitter MUST be 0.025*AdvertisementInterval
AdvertisementJitterは0.025*AdvertisementIntervalであるに違いありません。
3.1.3. MaxInitialAdvertisementInterval
3.1.3. MaxInitialAdvertisementInterval
The first unsolicited Advertisement transmitted on an interface is sent after waiting a random interval (in seconds) less than this variable. This prevents a flood of Advertisements when multiple routers start up at the same time.
無作為の間隔(秒の)を待たなかった後に、この変数よりインタフェースで伝えられた最初の求められていないAdvertisementを送ります。 複数のルータが同時に始動すると、これはAdvertisementsの洪水を防ぎます。
Default: 2 seconds
デフォルト: 2秒
3.1.4. MaxInitialAdvertisements
3.1.4. MaxInitialAdvertisements
This variable is the maximum number of unsolicited Advertisements that will be transmitted by the advertising interface when MRD starts up.
この変数はMRDが始動するとき広告インタフェースによって伝えられる求められていないAdvertisementsの最大数です。
Default: 3
デフォルト: 3
3.1.5. NeighborDeadInterval
3.1.5. NeighborDeadInterval
The NeighborDeadInterval variable is the maximum time (in seconds) allowed to elapse (after receipt of the last valid Advertisement) before a neighboring router is declared unreachable. This variable is maintained per neighbor. An MRD receiver should set the NeighborDeadInterval to 3 times the sum of Advertisement Interval Field received plus the AdvertisementJitter calculated from the received Advertisement Interval Field. This ensures consistent behavior between multiple devices on a network.
NeighborDeadInterval変数は隣接しているルータが手が届かないと宣言される前に経過できた(最後の有効なAdvertisementの領収書の後に)最大の時間(秒の)です。 この変数は隣人単位で維持されます。 MRD受信機はAdvertisement Interval Fieldの合計が受けた3回と容認されたAdvertisement Interval Fieldから計算されたAdvertisementJitterにNeighborDeadIntervalを設定するはずです。 これはネットワークの複数のデバイスの間の一貫した振舞いを確実にします。
Haberman, et al. Standards Track [Page 5] RFC 4286 Multicast Router Discovery December 2005
ハーバーマン、他 規格はマルチキャストルータ発見2005年12月にRFC4286を追跡します[5ページ]。
Default : 3 * (Advertisement Interval Field + calculated AdvertisementJitter)
デフォルト: 3 * (広告Interval Field+計算されたAdvertisementJitter)
3.1.6. MaxMessageRate
3.1.6. MaxMessageRate
The MaxMessageRate variable is the maximum aggregate number of messages an MRD implementation SHOULD send (per second) per interface or per management or logging destination.
MaxMessageRate変数はMRD実装SHOULDがインタフェースか管理単位で送る(1秒単位で)メッセージか伐採の目的地の最大の集合数です。
Default: 10
デフォルト: 10
3.2. Advertisement Packet Format
3.2. 広告パケット・フォーマット
The Advertisement message has the following format:
Advertisementメッセージには、以下の形式があります:
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 | Ad. Interval | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Query Interval | Robustness Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 広告。 間隔| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 質問間隔| 丈夫さ変数| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.1. Type Field
3.2.1. タイプ分野
The Type field identifies the message as an Advertisement. It is set to 0x30 for IPv4 and 151 for IPv6.
Type分野は、メッセージがAdvertisementであると認識します。 それはIPv4のための0×30とIPv6のための151へのセットです。
3.2.2. Advertisement Interval Field
3.2.2. 広告間隔分野
This field specifies the periodic time interval at which unsolicited Advertisement messages are transmitted in units of seconds. This value is set to the configured AdvertisementInterval.
この分野は求められていないAdvertisementメッセージがユニットの秒に送られる周期的な時間間隔を指定します。 この値は構成されたAdvertisementIntervalに設定されます。
3.2.3. Checksum Field
3.2.3. チェックサム分野
The checksum field is set as follows:
チェックサム分野は以下の通り設定されます:
1. For IPv4 it is the 16-bit one's complement of the one's
complement sum of the IGMP message, starting with the Type field.
For computing the checksum, the checksum field is set to 0.
1. IPv4に関しては、それはIGMPメッセージの1の補数合計の16ビットの1の補数です、Type野原から始まって。 チェックサムを計算するのにおいて、チェックサム分野は0に設定されます。
2. For IPv6 it is ICMPv6 checksum as specified in [6].
2. IPv6に関しては、それは指定されるとして[6]のICMPv6チェックサムです。
Haberman, et al. Standards Track [Page 6] RFC 4286 Multicast Router Discovery December 2005
ハーバーマン、他 規格はマルチキャストルータ発見2005年12月にRFC4286を追跡します[6ページ]。
3.2.4. Query Interval Field
3.2.4. 質問間隔分野
The Query Interval field is set to the Query Interval value (in seconds) in use by IGMP or MLD on the interface. If IGMP or MLD is not enabled on the advertising interface, this field MUST be set to 0. Note that this is the Querier's Query Interval (QQI), not the Querier's Query Interval Code (QQIC) as specified in the IGMP/MLD specifications.
Query Interval分野はインタフェースのIGMPかMLDによる使用でのQuery Interval値(秒の)へのセットです。 IGMPかMLDが広告インタフェースで有効にされないなら、この分野を0に設定しなければなりません。 これが指定されるとしてのIGMP/MLD仕様によるQuerierのQuery Interval Code(QQIC)ではなく、QuerierのQuery Interval(QQI)であることに注意してください。
3.2.5. Robustness Variable Field
3.2.5. 丈夫さ変数フィールド
This field is set to the Robustness Variable in use by IGMPv2 [2], IGMPv3 [7], or MLD [8] [9] on the advertising interface. If IGMPv1 is in use or no group management protocol is enabled on the interface, this field MUST be set to 0.
この分野は広告インタフェースでIGMPv2[2]、IGMPv3[7]、またはMLD[8][9]で使用中のRobustness Variableへのセットです。 IGMPv1が使用中であるか、またはグループ管理プロトコルが全くインタフェースで可能にされないなら、この分野を0に設定しなければなりません。
3.3. IP Header Fields
3.3. IPヘッダーフィールド
3.3.1. Source Address
3.3.1. ソースアドレス
The IP source address is set to an IP address configured on the advertising interface. For IPv6, a link-local address MUST be used.
IPソースアドレスは広告インタフェースで構成されたIPアドレスに設定されます。 IPv6のために、リンクローカルアドレスを使用しなければなりません。
3.3.2. Destination Address
3.3.2. 送付先アドレス
The IP destination address is set to the All-Snoopers multicast address.
受信者IPアドレスはAll-詮索好きマルチキャストアドレスに設定されます。
3.3.3. Time-to-Live / Hop Limit
3.3.3. 生きる時間/ホップ限界
The IPv4 TTL and IPv6 Hop Limit are set to 1.
IPv4 TTLとIPv6 Hop Limitは1に用意ができています。
3.3.4. IPv4 Protocol
3.3.4. IPv4プロトコル
The IPv4 Protocol field is set to IGMP (2).
IPv4プロトコル分野はIGMP(2)に設定されます。
3.3.5. IPv6 Next Header
3.3.5. IPv6次ヘッダー
The ICMPv6 header is identified by a Next Header value of 58 in the immediately preceding header [6].
ICMPv6ヘッダーはすぐに前のヘッダー[6]の58のNext Header値によって特定されます。
Haberman, et al. Standards Track [Page 7] RFC 4286 Multicast Router Discovery December 2005
ハーバーマン、他 規格はマルチキャストルータ発見2005年12月にRFC4286を追跡します[7ページ]。
3.4. Sending Multicast Router Advertisements
3.4. 送付マルチキャストルータ通知
Advertisement messages are sent when the following events occur:
以下のイベントが起こるとき、広告メッセージを送ります:
1. The expiration of the periodic advertisement interval timer.
Note that this timer is not strictly periodic since the base
AdvertisementInterval is varied at each interval by a random
value no more than plus or minus AdvertisementJitter seconds.
1. 周期的な広告インタバルタイマの満了。 ベースAdvertisementIntervalが無作為の値によってまたは、AdvertisementJitter秒を引いてだけ各間隔を置いて変えられるのでこのタイマが厳密に周期的でないことに注意してください。
2. After a random delay less than MaxInitialAdvertisementInterval
when an interface is first enabled, is (re-)initialized, or MRD
is enabled. A router may send up to a maximum of
MaxInitialAdvertisements Advertisements, waiting for a random
delay less than MaxInitialAdvertisementInterval between each
successive message. Multiple Advertisements are sent for
robustness in the face of packet loss on the network.
2. インタフェースであるときに、MaxInitialAdvertisementIntervalより少ない無作為の遅れは後に、最初に、可能にされて、ある、(再、)、初期化、MRDは有効にされます。 ルータは最大MaxInitialAdvertisements Advertisementsまで発信するかもしれません、MaxInitialAdvertisementIntervalほどそれぞれの連続したメッセージの間で無作為の遅れを待っていなくて。 ネットワークにおけるパケット損失に直面して丈夫さのために複数のAdvertisementsを送ります。
This is to prevent an implosion of Advertisements. An example of this occurring would be when many routers are powered on at the same time. When a Solicitation is received, an Advertisement is sent in response with a random delay less than MAX_RESPONSE_DELAY. If a Solicitation is received while an Advertisement is pending, that Solicitation MUST be ignored.
これは、Advertisementsの内部破裂を防ぐためのものです。 この発生に関する例は多くのルータが同時に電源を入れられている時でしょう。 Solicitationが受け取られているとき、無作為の遅れがマックス_RESPONSE_DELAYより少ない状態で応答でAdvertisementを送ります。 Advertisementが未定ですが、Solicitationが受け取られているなら、そのSolicitationを無視しなければなりません。
Changes in the Query Interval or Robustness Variable MUST NOT trigger a new Advertisement; however, the new values MUST be used in all future Advertisement messages.
Query IntervalかRobustness Variableにおける変化は新しいAdvertisementの引き金となってはいけません。 しかしながら、すべての将来のAdvertisementメッセージで新しい値を使用しなければなりません。
When an Advertisement is sent, the periodic advertisement interval timer MUST be reset.
Advertisementを送るとき、周期的な広告インタバルタイマをリセットしなければなりません。
3.5. Receiving Multicast Router Advertisements
3.5. マルチキャストルータ通知を受け取ります。
Upon receiving an Advertisement message, devices validate the message with the following criteria:
Advertisementメッセージを受け取ると、デバイスは以下の評価基準があるメッセージを有効にします:
1. The checksum is correct
1. チェックサムは正しいです。
2. The IP destination address is equal to the All-Snoopers multicast
address
2. 受信者IPアドレスはAll-詮索好きマルチキャストアドレスと等しいです。
3. For IPv6, the IP source address is a link-local address
3. IPv6に関しては、IPソースアドレスはリンクローカルアドレスです。
An Advertisement not meeting the validity requirements MUST be silently discarded and may be logged in a rate-limited manner as per the MaxMessageRate variable.
正当性必要条件を満たさないAdvertisementは静かに捨てなければならなくて、MaxMessageRate変数に従ってレートで限られた方法で登録されるかもしれません。
Haberman, et al. Standards Track [Page 8] RFC 4286 Multicast Router Discovery December 2005
ハーバーマン、他 規格はマルチキャストルータ発見2005年12月にRFC4286を追跡します[8ページ]。
If an Advertisement is not received for a particular neighbor within a NeighborDeadInterval time interval, then the neighbor is considered unreachable.
AdvertisementがNeighborDeadInterval時間間隔以内の特定の隣人のために受け取られないなら、隣人は手が届かないと考えられます。
4. Multicast Router Solicitation
4. マルチキャストルータ懇願
Multicast Router Solicitation messages are used to solicit Advertisements from multicast routers on a segment. These messages are used when a device wishes to discover multicast routers. Upon receiving a solicitation on an interface with IP multicast forwarding and MRD enabled, a router will respond with an Advertisement.
マルチキャストRouter Solicitationメッセージは、セグメントでマルチキャストルータから広告を勧誘するのに使用されます。 デバイスがマルチキャストルータを発見したがっているとき、これらのメッセージは使用されています。 有効にされるIPのマルチキャスト推進とMRDとのインタフェースで懇願を受けると、ルータはAdvertisementと共に応じるでしょう。
Solicitations may be sent when these occur:
これらが起こるとき、懇願を送るかもしれません:
1. An interface is (re-)initialized
1. インタフェースがそうである、(再、)、初期化
2. MRD is enabled
2. MRDは有効にされます。
Solicitations are sent to the All-Routers multicast address and SHOULD be rate-limited, as per the MaxMessageRate variable.
All-ルータマルチキャストアドレスに懇願を送ります、そして、SHOULDはMaxMessageRate変数のようにレートで限ります。
4.1. Solicitation Packet Format
4.1. 懇願パケット・フォーマット
The Solicitation message has the following format:
Solicitationメッセージには、以下の形式があります:
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 | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 予約されます。| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.1.1. Type Field
4.1.1. タイプ分野
The Type field identifies the message as a Solicitation. It is set to 0x31 for IPv4 and 152 for IPv6.
Type分野は、メッセージがSolicitationであると認識します。 それはIPv4のための0×31とIPv6のための152へのセットです。
4.1.2. Reserved Field
4.1.2. 予約された分野
The Reserved field is set to 0 on transmission and ignored on reception.
Reserved分野は、トランスミッションのときに0に設定されて、レセプションで無視されます。
4.1.3. Checksum Field
4.1.3. チェックサム分野
The checksum field is set as follows:
チェックサム分野は以下の通り設定されます:
o For IPv4 it is the 16-bit one's complement of the one's complement
sum of the IGMP message, starting with the Type field. For
computing the checksum, the checksum field is set to 0.
o IPv4に関しては、それはIGMPメッセージの1の補数合計の16ビットの1の補数です、Type野原から始まって。 チェックサムを計算するのにおいて、チェックサム分野は0に設定されます。
Haberman, et al. Standards Track [Page 9] RFC 4286 Multicast Router Discovery December 2005
ハーバーマン、他 規格はマルチキャストルータ発見2005年12月にRFC4286を追跡します[9ページ]。
o For IPv6 it is ICMPv6 checksum as specified in [6].
o IPv6に関しては、それは指定されるとして[6]のICMPv6チェックサムです。
4.2. IP Header Fields
4.2. IPヘッダーフィールド
4.2.1. Source Address
4.2.1. ソースアドレス
The IP source address is set to an IP address configured on the soliciting interface. For IPv6, a link-local address MUST be used.
IPソースアドレスは請求インタフェースで構成されたIPアドレスに設定されます。 IPv6のために、リンクローカルアドレスを使用しなければなりません。
4.2.2. Destination Address
4.2.2. 送付先アドレス
The IP destination address is set to the All-Routers multicast address.
受信者IPアドレスはAll-ルータマルチキャストアドレスに設定されます。
4.2.3. Time-to-Live / Hop Limit
4.2.3. 生きる時間/ホップ限界
The IPv4 TTL and IPv6 Hop Limit are set to 1.
IPv4 TTLとIPv6 Hop Limitは1に用意ができています。
4.2.4. IPv4 Protocol
4.2.4. IPv4プロトコル
The IPv4 Protocol field is set to IGMP (2).
IPv4プロトコル分野はIGMP(2)に設定されます。
4.2.5. IPv6 Next Header
4.2.5. IPv6次ヘッダー
The ICMPv6 header is identified by a Next Header value of 58 in the immediately preceding header [6].
ICMPv6ヘッダーはすぐに前のヘッダー[6]の58のNext Header値によって特定されます。
4.3. Sending Multicast Router Solicitations
4.3. 送付マルチキャストルータ懇願
Solicitation messages are sent when the following events occur:
以下のイベントが起こるとき、懇願メッセージを送ります:
o After waiting for a random delay less than MAX_SOLICITATION_DELAY
when an interface first becomes operational, is (re-)initialized,
or MRD is enabled. A device may send up to a maximum of
MAX_SOLICITATIONS, waiting for a random delay less than
MAX_SOLICITATION_DELAY between each solicitation.
o インタフェースは最初に、操作上になって、あるときマックス_SOLICITATION_DELAYより後に無作為の遅れを待たない、(再、)、初期化、MRDは有効にされます。 デバイスは最大マックス_SOLICITATIONSまで発信するかもしれません、マックス_SOLICITATION_DELAYほど各懇願の間で無作為の遅れを待っていなくて。
o Optionally, for an implementation specific event.
o 任意に、実装の特定のイベントのために。
Solicitations MUST be rate-limited as per the MaxMessageRate variable; the implementation MUST send no more than MAX_SOLICITATIONS in MAX_SOLICITATION_DELAY seconds.
懇願はMaxMessageRate変数に従ってレートで限らなければなりません。 実装はマックス_SOLICITATION_DELAY秒にマックス_SOLICITATIONSより発信してはいけません。
4.4. Receiving Multicast Router Solicitations
4.4. マルチキャストルータ懇願を受けます。
A Solicitation message MUST be validated before a response is sent. A router MUST verify the following:
応答を送る前にSolicitationメッセージを有効にしなければなりません。 ルータは以下について確かめなければなりません:
Haberman, et al. Standards Track [Page 10] RFC 4286 Multicast Router Discovery December 2005
ハーバーマン、他 規格はマルチキャストルータ発見2005年12月にRFC4286を追跡します[10ページ]。
o The checksum is correct.
o チェックサムは正しいです。
o The IP destination address is the All-Routers multicast address.
o 受信者IPアドレスはAll-ルータマルチキャストアドレスです。
o For IPv6, the IP source address MUST be a link-local address.
o IPv6に関しては、IPソースアドレスはリンクローカルアドレスであるに違いありません。
Solicitations not meeting the validity requirements SHOULD be silently discarded and may be logged in a rate-limited manner as per the MaxMessageRate variable.
正当性要件SHOULDに会わない懇願は、静かに捨てられて、MaxMessageRate変数に従ってレートで限られた方法で登録されるかもしれません。
5. Multicast Router Termination
5. マルチキャストルータ終了
The Multicast Router Termination message is used to expedite the notification of a change in the status of a router's multicast forwarding functions. Multicast routers send Terminations when multicast forwarding is disabled on the advertising interface.
Multicast Router Terminationメッセージは、機能を進めながらルータのマルチキャストの状態で変化の通知を速めるのに使用されます。 マルチキャスト推進が広告インタフェースで無効にされるとき、マルチキャストルータはTerminationsを送ります。
5.1. Termination Packet Format
5.1. 終了パケット・フォーマット
The Termination message has the following format:
Terminationメッセージには、以下の形式があります:
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 | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 予約されます。| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.1.1. Type Field
5.1.1. タイプ分野
The Type field identifies the message as a Termination. It is set to 0x32 for IPv4 and 153 for IPv6.
Type分野は、メッセージがTerminationであると認識します。 それはIPv4のための0×32とIPv6のための153へのセットです。
5.1.2. Reserved Field
5.1.2. 予約された分野
The Reserved field is set to 0 on transmission and ignored on reception.
Reserved分野は、トランスミッションのときに0に設定されて、レセプションで無視されます。
5.1.3. Checksum Field
5.1.3. チェックサム分野
The checksum field is set as follows:
チェックサム分野は以下の通り設定されます:
o For IPv4 it is the 16-bit one's complement of the one's complement
sum of the IGMP message, starting with the Type field. For
computing the checksum, the checksum field is set to 0.
o IPv4に関しては、それはIGMPメッセージの1の補数合計の16ビットの1の補数です、Type野原から始まって。 チェックサムを計算するのにおいて、チェックサム分野は0に設定されます。
o For IPv6 it is ICMPv6 checksum as specified in [6].
o IPv6に関しては、それは指定されるとして[6]のICMPv6チェックサムです。
Haberman, et al. Standards Track [Page 11] RFC 4286 Multicast Router Discovery December 2005
ハーバーマン、他 規格はマルチキャストルータ発見2005年12月にRFC4286を追跡します[11ページ]。
5.2. IP Header Fields
5.2. IPヘッダーフィールド
5.2.1. Source Address
5.2.1. ソースアドレス
The IP source address is set to an IP address configured on the advertising interface. For IPv6, a link-local address MUST be used.
IPソースアドレスは広告インタフェースで構成されたIPアドレスに設定されます。 IPv6のために、リンクローカルアドレスを使用しなければなりません。
5.2.2. Destination Address
5.2.2. 送付先アドレス
The IP destination address is set to the All-Snoopers multicast address.
受信者IPアドレスはAll-詮索好きマルチキャストアドレスに設定されます。
5.2.3. Time-to-Live / Hop Limit
5.2.3. 生きる時間/ホップ限界
The IPv4 TTL and IPv6 Hop Limit are set to 1.
IPv4 TTLとIPv6 Hop Limitは1に用意ができています。
5.2.4. IPv4 Protocol
5.2.4. IPv4プロトコル
The IPv4 Protocol field is set to IGMP (2).
IPv4プロトコル分野はIGMP(2)に設定されます。
5.2.5. IPv6 Next Header
5.2.5. IPv6次ヘッダー
The ICMPv6 header is identified by a Next Header value of 58 in the immediately preceding header [6].
ICMPv6ヘッダーはすぐに前のヘッダー[6]の58のNext Header値によって特定されます。
5.3. Sending Multicast Router Terminations
5.3. 送付マルチキャストルータ終了
Termination messages are sent by multicast routers when
マルチキャストルータで終了メッセージを送る、いつ
o Multicast forwarding is disabled on an interface
o マルチキャスト推進はインタフェースで無効にされます。
o An interface is administratively disabled
o インタフェースは行政上無効にされます。
o The router is gracefully shut down
o ルータは優雅に止められます。
o MRD is disabled
o MRDは障害があります。
The sending of Termination messages SHOULD be rate-limited as per the MaxMessageRate variable.
TerminationメッセージSHOULDの発信はMaxMessageRate変数のようにレートによって限られます。
5.4. Receiving Multicast Router Terminations
5.4. マルチキャストルータ終了を受けます。
Upon receiving a Termination message, devices validate the message. The validation criteria are the following:
Terminationメッセージを受け取ると、デバイスはメッセージを有効にします。 合法化評価基準は以下です:
o Checksum MUST be correct.
o チェックサムは正しいに違いありません。
Haberman, et al. Standards Track [Page 12] RFC 4286 Multicast Router Discovery December 2005
ハーバーマン、他 規格はマルチキャストルータ発見2005年12月にRFC4286を追跡します[12ページ]。
o IP destination address MUST equal the All-Snoopers multicast
address.
o 受信者IPアドレスはAll-詮索好きマルチキャストアドレスと等しくなければなりません。
o For IPv6, the IP source address MUST be a link-local address.
o IPv6に関しては、IPソースアドレスはリンクローカルアドレスであるに違いありません。
Termination messages not meeting the validity requirements MUST be silently discarded and may be logged in a rate-limited manner as per the MaxMessageRate variable.
正当性必要条件を満たさない終了メッセージは、静かに捨てなければならなくて、MaxMessageRate変数に従ってレートで限られた方法で登録されるかもしれません。
If the message passes these validation steps, a Solicitation is sent. If an Advertisement is not received within NeighborDeadInterval, the sending router is removed from the list of active multicast routers.
メッセージがこれらの合法化階段を通り過ぎるなら、Solicitationを送ります。 NeighborDeadIntervalの中にAdvertisementを受け取らないなら、アクティブなマルチキャストルータのリストから送付ルータを取り除きます。
6. Protocol Constants
6. プロトコル定数
The following list identifies constants used in the MRD protocol. These constants are used in the calculation of parameters.
以下のリストはMRDプロトコルに使用される定数を特定します。 これらの定数はパラメタの計算に使用されます。
o MAX_RESPONSE_DELAY 2 seconds
o 2秒のマックス_RESPONSE_DELAY
o MAX_SOLICITATION_DELAY 1 second
o マックス_SOLICITATION_DELAY1 2番目
o MAX_SOLICITATIONS 3 transmissions
o マックス_SOLICITATIONS3トランスミッション
7. Security Considerations
7. セキュリティ問題
As MRD is a link-local protocol, there is no circumstance in which it would be correct for an MRD receiver to receive MRD traffic from an off-network source. For IPv6, MRD messages MUST have a valid link- local source address. Any messages received without a valid link- local source address MUST be discarded. Similarly, for IPv4, the MRD receiver MUST determine if the source address is local to the receiving interface, and MUST discard any messages that have a non- local source. Determining what networks are local may be accomplished through configuration information or operational capabilities.
MRDがリンクローカルのプロトコルであるので、MRD受信機がオフネットワークソースからMRDトラフィックを受けるのが、正しい状況が全くありません。 IPv6に関しては、MRDメッセージには、有効なリンク地元筋アドレスがなければなりません。 有効なリンク地元筋アドレスなしで受け取られたどんなメッセージも捨てなければなりません。 同様に、IPv4に関して、MRD受信機は、ソースアドレスが受信インタフェースにローカルであるかどうか決定しなければならなくて、非地元筋がいるどんなメッセージも捨てなければなりません。 どんなネットワークがローカルであるかを決定するのが設定情報か運用能力で実行されるかもしれません。
Rogue nodes may attempt to attack a network running MRD by sending spoofed Advertisement, Solicitation, or Termination messages. Each type of spoofed message can be dealt with using existing technology.
凶暴なノードは、Advertisementであると偽造された発信、Solicitation、またはTerminationメッセージでネットワーク実行MRDを攻撃するのを試みるかもしれません。 既存の技術を使用することでそれぞれのタイプの偽造しているメッセージに対処できます。
A rogue node may attempt to interrupt multicast service by sending spoofed Termination messages. As described in Section 5.4, all Termination messages are validated by sending a Solicitation message. By sending a Solicitation, the node will force the transmission of an Advertisement by an active router.
凶暴なノードは、偽造しているTerminationメッセージを送ることによってマルチキャストサービスを中断するのを試みるかもしれません。 セクション5.4で説明されるように、すべてのTerminationメッセージがSolicitationメッセージを送ることによって、有効にされます。 Solicitationを送ることによって、ノードはアクティブなルータでAdvertisementのトランスミッションを強制するでしょう。
Haberman, et al. Standards Track [Page 13] RFC 4286 Multicast Router Discovery December 2005
ハーバーマン、他 規格はマルチキャストルータ発見2005年12月にRFC4286を追跡します[13ページ]。
Spoofed Solicitation messages do not cause any operational harm. They may be used as a flooding mechanism to attack a multicast router. This attack can be mitigated through the rate-limiting recommendation for all MRD messages.
偽造しているSolicitationメッセージは少しの操作上の害も引き起こしません。 それらは、マルチキャストルータを攻撃するのに氾濫メカニズムとして使用されるかもしれません。 すべてのMRDメッセージのためのレートを制限する推薦でこの攻撃を緩和できます。
The Multicast Router Advertisement message may allow rogue machines to masquerade as multicast routers. This could allow those machines to eavesdrop on multicast data transmissions. Additionally, it could constitute a denial of service attack to other hosts in the same snooping domain or sharing the same device port in the presence of high-rate multicast flows.
Multicast Router Advertisementメッセージで、凶暴なマシンはマルチキャストルータのふりをすることができるかもしれません。 これで、それらのマシンはマルチキャストデータ伝送を立ち聞きできるかもしれません。 さらに、高い率マルチキャスト流れがあるときそれは同じ詮索ドメインか同じデバイスポートを共有する際に他のホストにサービス不能攻撃を構成するかもしれません。
The technology available in SEND [10] can be utilized to address spoofed Advertisement messages in IPv6 networks. IPv6 Multicast routers in an MRD-enabled network can use SEND-based link-local addresses as the IPv6 source address for MRD messages. When a switch receives an initial Advertisement, it can use the information in the SEND-based address to challenge the router to authenticate itself. It should be noted that this approach only applies to IPv6 networks.
IPv6ネットワークでAdvertisementメッセージであると偽造されたアドレスにSEND[10]で利用可能な技術を利用できます。 MRDによって可能にされたネットワークにおけるIPv6 MulticastルータはMRDメッセージにIPv6ソースアドレスとしてSENDベースのリンクローカルのアドレスを使用できます。 スイッチが初期のAdvertisementを受けるとき、それは、それ自体を認証するようにルータに挑むのにSENDベースのアドレスで情報を使用できます。 このアプローチがIPv6ネットワークに適用されるだけであることに注意されるべきです。
Another solution that supports both IPv4 and IPv6 is to use IPsec in Encapsulating Security Payload (ESP) mode [11] to protect against attacks by ensuring that messages came from a system with the proper key. When using IPsec, the messages sent to the All-Snoopers address should be authenticated using ESP. Should encryption not be desired, ESP with a null encryption algorithm and a symmetric authentication algorithm, such as HMAC-SHA-1, is viable. For keying, a symmetric signature algorithm with a single manually configured key is used for routers sending Advertisements. This allows validation that the MRD message was sent by a system with the key. It should be noted that this does not prevent a system with the key from forging a message and it requires the disabling of IPsec's Replay Protection. It is the responsibility of the network administrator to ensure that the same key is present on all possible MRD participants.
IPv4とIPv6の両方をサポートする他の解決法はメッセージが適切なキーと共にシステムから来たのを確実にすることによって攻撃から守るのにEncapsulating Security有効搭載量(超能力)モード[11]でIPsecを使用することです。 IPsecを使用するとき、All-詮索好きアドレスに送られたメッセージは、超能力を使用することで認証されるべきです。 暗号化を望んでいないなら、ヌル暗号化アルゴリズムがある超能力とHMAC-SHA-1などの左右対称の認証アルゴリズムは実行可能です。 合わせるのにおいて、単一の手動で構成されたキーがある左右対称の署名アルゴリズムはルータ送付Advertisementsに使用されます。 これはMRDメッセージがキーと共にシステムによって送られた合法化を許します。 これが、キーがあるシステムがメッセージを作り出すのを防がないことに注意されるべきであり、それはIPsecのReplay Protectionを無効にすることを必要とします。 同じキーがすべての可能なMRD関係者に存在しているのを保証するのは、ネットワーク管理者の責任です。
8. IANA Considerations
8. IANA問題
This document introduces three new IGMP messages. Each of these messages requires a new IGMP Type value. The IANA has assigned three new IGMP Type values to the Multicast Router Discovery Protocol:
このドキュメントは3つの新しいIGMPメッセージを紹介します。 それぞれに関するこれらのメッセージは新しいIGMP Type値を必要とします。 IANAは3つの新しいIGMP Type値をMulticast Routerディスカバリープロトコルに割り当てました:
+-----------+-----------------+--------------------------------+
| IGMP Type | Section | Message Name |
+-----------+-----------------+--------------------------------+
| 0x30 | Section 3.2.1 | Multicast Router Advertisement |
| 0x31 | Section 4.1.1 | Multicast Router Solicitation |
| 0x32 | Section 5.1.1 | Multicast Router Termination |
+-----------+-----------------+--------------------------------+
+-----------+-----------------+--------------------------------+ | IGMPはタイプします。| セクション| メッセージ名| +-----------+-----------------+--------------------------------+ | 0×30| セクション3.2 .1| マルチキャストルータ通知| | 0×31| セクション4.1 .1| マルチキャストルータ懇願| | 0×32| セクション5.1 .1| マルチキャストルータ終了| +-----------+-----------------+--------------------------------+
Haberman, et al. Standards Track [Page 14] RFC 4286 Multicast Router Discovery December 2005
ハーバーマン、他 規格はマルチキャストルータ発見2005年12月にRFC4286を追跡します[14ページ]。
This document also introduces three new MLD messages. Each of these messages requires a new ICMPv6 Type value. The IANA has assigned three new ICMPv6 Type values from the Informational range:
また、このドキュメントは3つの新しいMLDメッセージを紹介します。 それぞれに関するこれらのメッセージは新しいICMPv6 Type値を必要とします。 IANAはInformational範囲から3つの新しいICMPv6 Type値を割り当てました:
+-------------+-----------------+--------------------------------+ | ICMPv6 Type | Section | Message Name | +-------------+-----------------+--------------------------------+ | 151 | Section 3.2.1 | Multicast Router Advertisement | | 152 | Section 4.1.1 | Multicast Router Solicitation | | 153 | Section 5.1.1 | Multicast Router Termination | +-------------+-----------------+--------------------------------+
+-------------+-----------------+--------------------------------+ | ICMPv6はタイプします。| セクション| メッセージ名| +-------------+-----------------+--------------------------------+ | 151 | セクション3.2 .1| マルチキャストルータ通知| | 152 | セクション4.1 .1| マルチキャストルータ懇願| | 153 | セクション5.1 .1| マルチキャストルータ終了| +-------------+-----------------+--------------------------------+
This document also requires the assignment of an All-Snoopers multicast address for IPv4. This multicast address is in the 224.0.0/24 range since it is used for link-local, control messages. The IPv4 multicast address for All-Snoopers is 224.0.0.106.
また、このドキュメントはIPv4のためのAll-詮索好きマルチキャストアドレスの課題を必要とします。 それがリンクローカルのコントロールメッセージに使用されるので、このマルチキャストアドレスは224.0.0/24範囲にあります。 All-詮索好きのためのIPv4マルチキャストアドレスはそうです。224.0 .0 .106。
A corresponding IPv6 multicast address has also been assigned. Following the guidelines in [12], the IPv6 multicast address is a link-local in scope and has a group-ID value equal to the low-order 8 bits of the requested IPv4 multicast address. The IPv6 multicast address is FF02:0:0:0:0:0:0:6A.
また、対応するIPv6マルチキャストアドレスを割り当ててあります。 [12]でガイドラインに従って、IPv6マルチキャストアドレスは、範囲のリンクローカルであり、要求されたIPv4マルチキャストアドレスの下位の8ビットと等しいグループID値を持っています。 IPv6マルチキャストアドレスはFF02です:、0:0:0、:、0:0:0、: 6A。
9. Acknowledgements
9. 承認
Brad Cain and Shantam Biswis are the authors of the original Multicast Router Discovery proposal.
ブラッド・カインとShantam BiswisはオリジナルのMulticast Routerディスカバリー提案の作者です。
ICMP Router Discovery [13] was used as a general model for Multicast Router Discovery.
ICMP Routerディスカバリー[13]はMulticast Routerディスカバリーに一般的なモデルとして使用されました。
Morten Christensen, Pekka Savola, Hugh Holbrook, and Isidor Kouvelas provided helpful feedback on various versions of this document.
モーテンクリステンセン、ペッカSavola、ヒューHolbrook、およびIsidor Kouvelasはこのドキュメントの様々なバージョンの役立っているフィードバックを提供しました。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[1] Deering, S., "Host extensions for IP multicasting", STD 5, RFC
1112, August 1989.
[1] デアリング、S.、「IPマルチキャスティングのためのホスト拡大」、STD5、RFC1112、1989年8月。
[2] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version 3",
RFC 3376, October 2002.
[2] カイン、B.とデアリングとS.とKouvelasとI.とフェナー、B.とA.Thyagarajan、「インターネット集団経営は議定書を作ります、バージョン3インチ、RFC3376、2002年10月。」
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
Haberman, et al. Standards Track [Page 15] RFC 4286 Multicast Router Discovery December 2005
ハーバーマン、他 規格はマルチキャストルータ発見2005年12月にRFC4286を追跡します[15ページ]。
[4] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
[4] キャッツ、D.、「IPルータ警戒オプション」、RFC2113、1997年2月。
[5] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC
2711, October 1999.
[5] ヤマウズラとC.とA.ジャクソン、「IPv6ルータ警戒オプション」、RFC2711、1999年10月。
[6] Conta, A. and S. Deering, "Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification", RFC 2463, December 1998.
[6] コンタ、A.、およびS.デアリング、「インターネットへのインターネット・コントロール・メッセージ・プロトコル(ICMPv6)はバージョン6(IPv6)仕様を議定書の中で述べます」、RFC2463、1998年12月。
[7] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version 3",
RFC 3376, October 2002.
[7] カイン、B.とデアリングとS.とKouvelasとI.とフェナー、B.とA.Thyagarajan、「インターネット集団経営は議定書を作ります、バージョン3インチ、RFC3376、2002年10月。」
[8] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener
Discovery (MLD) for IPv6", RFC 2710, October 1999.
[8] デアリング、S.、フェナー、W.、およびB.ハーバーマン、「IPv6"、RFC2710、1999年10月のためのマルチキャストリスナー発見(MLD)。」
[9] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2
(MLDv2) for IPv6", RFC 3810, June 2004.
そして、[9] ビーダ、R.、L.コスタ、「IPv6"、RFC3810、2004年6月のためのマルチキャストリスナー発見バージョン2(MLDv2)。」
[10] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[10]ArkkoとJ.とケンフとJ.とZill、B.とP.Nikander、「安全な隣人発見(発信する)」、RFC3971、2005年3月。
[11] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998.
[11] ケントとS.とR.アトキンソン、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC2406、1998年11月。
[12] Haberman, B., "Allocation Guidelines for IPv6 Multicast
Addresses", RFC 3307, August 2002.
[12] ハーバーマン、B.、「IPv6マルチキャストアドレスのための配分ガイドライン」、RFC3307、2002年8月。
10.2. Informative Reference
10.2. 有益な参照
[13] Deering, S., "ICMP Router Discovery Messages", RFC 1256,
September 1991.
[13] デアリング、S.、「ICMPルータ発見メッセージ」、RFC1256、1991年9月。
Haberman, et al. Standards Track [Page 16] RFC 4286 Multicast Router Discovery December 2005
ハーバーマン、他 規格はマルチキャストルータ発見2005年12月にRFC4286を追跡します[16ページ]。
Authors' Addresses
作者のアドレス
Brian Haberman Johns Hopkins University Applied Physics Lab 11100 Johns Hopkins Road Laurel, MD 20723-6099 US
ブライアンハーバーマンジョーンズ・ホプキンス大学応用物理学研究室11100のジョーンズ・ホプキン・Road MD20723-6099ローレル(米国)
Phone: +1 443 778 1319 EMail: brian@innovationslab.net
以下に電話をしてください。 +1 1319年の443 778メール: brian@innovationslab.net
Jim Martin Netzwert AG An den Treptowers 1 D-12435 Berlin Germany
ジムマーチンNetzwert株式会社An書斎Treptowers1D-12435ベルリンドイツ
Phone: +49.30/5 900 80-1180 EMail: jim@netzwert.ag
以下に電話をしてください。 +49.30/5 900 80-1180メール: jim@netzwert.ag
Haberman, et al. Standards Track [Page 17] RFC 4286 Multicast Router Discovery December 2005
ハーバーマン、他 規格はマルチキャストルータ発見2005年12月にRFC4286を追跡します[17ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Haberman, et al. Standards Track [Page 18]
ハーバーマン、他 標準化過程[18ページ]
一覧
スポンサーリンク
