[要約] RFC 2894は、IPv6のルーターの再番号付けに関するガイドラインです。その目的は、ネットワークのアドレス再構成を容易にし、IPv6の導入と展開を促進することです。
Network Working Group M. Crawford
Request for Comments: 2894 Fermilab
Category: Standards Track August 2000
Router Renumbering for IPv6
IPv6の変更ルーター
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.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
IESG Note:
IESGノート：
This document defines mechanisms for informing a set of routers of renumbering operations they are to perform, including a mode of operation in environments in which the exact number of routers is unknown. Reliably informing all routers when the actual number of routers is unknown is a difficult problem. Implementation and operational experience will be needed to fully understand the applicabilty and scalability aspects of the mechanisms defined in this document when the number of routers is unknown.
このドキュメントでは、正確な数のルーターが不明な環境での動作モードなど、実行される変更操作のルーターのセットを通知するメカニズムを定義しています。ルーターの実際の数が不明な場合にすべてのルーターを確実に通知することは困難な問題です。ルーターの数が不明な場合、このドキュメントで定義されているメカニズムの適用とスケーラビリティの側面を完全に理解するには、実装と運用の経験が必要です。
Abstract
概要
IPv6 Neighbor Discovery and Address Autoconfiguration conveniently make initial assignments of address prefixes to hosts. Aside from the problem of connection survival across a renumbering event, these two mechanisms also simplify the reconfiguration of hosts when the set of valid prefixes changes.
IPv6ネイバーディスカバリーとアドレスAutoconfigurationは、ホストへのアドレスプレフィックスの初期割り当てを便利に行います。変更イベント全体での接続生存の問題は別として、これらの2つのメカニズムは、有効なプレフィックスのセットが変更されたときにホストの再構成を簡素化します。
This document defines a mechanism called Router Renumbering ("RR") which allows address prefixes on routers to be configured and reconfigured almost as easily as the combination of Neighbor Discovery and Address Autoconfiguration works for hosts. It provides a means for a network manager to make updates to the prefixes used by and advertised by IPv6 routers throughout a site.
このドキュメントでは、ルーターのアドレスプレフィックスを構成および再構成することを可能にするルーターの変更（ "rr"）と呼ばれるメカニズムを定義します。近隣発見の組み合わせとほぼ同じくらい簡単に再構成し、ホスト用のアドレス自動構成作業を行います。ネットワークマネージャーが、サイト全体でIPv6ルーターによって使用され、宣伝されているプレフィックスを更新する手段を提供します。
Table of Contents
目次
1. Functional Overview ....................................... 2
2. Definitions ............................................... 4
2.1. Terminology ......................................... 4
2.2. Requirements ........................................ 5
3. Message Format ............................................ 5
3.1. Router Renumbering Header ........................... 7
3.2. Message Body -- Command Message ..................... 9
3.2.1. Prefix Control Operation ...................... 9
3.2.1.1. Match-Prefix Part ....................... 9
3.2.1.2. Use-Prefix Part ......................... 11
3.3. Message Body -- Result Message ...................... 12
4. Message Processing ........................................ 14
4.1. Header Check ........................................ 14
4.2. Bounds Check ........................................ 15
4.3. Execution ........................................... 16
4.4. Summary of Effects .................................. 17
5. Sequence Number Reset ..................................... 18
6. IANA Considerations ....................................... 19
7. Security Considerations ................................... 19
7.1. Security Policy and Association Database Entries .... 19
8. Implementation and Usage Advice for Reliability ........... 20
8.1. Outline and Definitions ............................. 21
8.2. Computations ........................................ 23
8.3. Additional Assurance Methods ........................ 24
9. Usage Examples ............................................ 25
9.1. Maintaining Global-Scope Prefixes ................... 25
9.2. Renumbering a Subnet ................................ 26
10. Acknowledgments .......................................... 27
11. References ............................................... 28
12. Author's Address ......................................... 29
Appendix -- Derivation of Reliability Estimates ............... 30
Full Copyright Statement ...................................... 32
Router Renumbering Command packets contain a sequence of Prefix Control Operations (PCOs). Each PCO specifies an operation, a Match-Prefix, and zero or more Use-Prefixes. A router processes each PCO in sequence, checking each of its interfaces for an address or prefix which matches the Match-Prefix. For every interface on which a match is found, the operation is applied. The operation is one of ADD, CHANGE, or SET-GLOBAL to instruct the router to respectively add the Use-Prefixes to the set of configured prefixes, remove the prefix which matched the Match-Prefix and replace it with the Use-Prefixes, or replace all global-scope prefixes with the Use-Prefixes. If the set of Use-Prefixes in the PCO is empty, the ADD operation does nothing and the other two reduce to deletions.
ルーターの変更コマンドパケットには、プレフィックス制御操作（PCOS）のシーケンスが含まれています。各PCOは、操作、マッチプレフィックス、およびゼロ以上の使用-Prefixを指定します。ルーターは各PCOを順番に処理し、各インターフェイスをマッチプレフィックスに一致するアドレスまたはプレフィックスをチェックします。一致が見つかったすべてのインターフェイスについて、操作が適用されます。操作はADD、変更、またはセットグロバルの1つであり、ルーターにそれぞれ設定されたプレフィックスのセットに使用-Prefixを追加するように指示し、マッチプレフィックスと一致したプレフィックスを削除して、使用-Prefixesに置き換えるか、または使用してください。すべてのグローバルスコーププレフィックスを使用-Prefixesに置き換えます。PCOの使用-Prefixesのセットが空の場合、ADD操作は何もしません。他の2つは削除に削減されます。
Additional information for each Use-Prefix is included in the Prefix Control Operation: the valid and preferred lifetimes to be included in Router Advertisement Prefix Information Options [ND], and either the L and A flags for the same option, or an indication that they are to be copied from the prefix that matched the Match-Prefix.
各使用-Prefixの追加情報は、プレフィックス制御操作に含まれています。ルーター広告プレフィックス情報オプション[ND]に含まれる有効な寿命と同じオプションのLとAフラグのいずれか、またはそれらが表示されます。Match-Prefixに一致するプレフィックスからコピーされます。
It is possible to instruct routers to create new prefixes by combining the Use-Prefixes in a PCO with some portion of the existing prefix which matched the Match-Prefix. This simplifies certain operations which are expected to be among the most common. For every Use-Prefix, the PCO specifies a number of bits which should be copied from the existing address or prefix which matched the Match-Prefix and appended to the use-prefix prior to configuring the new prefix on the interface. The copied bits are zero or more bits from the positions immediately after the length of the Use- Prefix. If subnetting information is in the same portion of the old and new prefixes, this synthesis allows a single Prefix Control Operation to define a new global prefix on every router in a site, while preserving the subnetting structure.
PCOの使用-Prefixesをマッチプレフィックスと一致させる既存のプレフィックスの一部を組み合わせることにより、ルーターに新しいプレフィックスを作成するように指示することができます。これにより、最も一般的なものになると予想される特定の操作が簡素化されます。使用するたびに、PCOは、インターフェイス上の新しいプレフィックスを構成する前に、マッチプレフィックスと一致し、使用-Prefixに追加された既存のアドレスまたはプレフィックスからコピーする必要がある多数のビットを指定します。コピーされたビットは、使用プレフィックスの長さの直後に位置からゼロ以上ビット以上です。サブネット情報が古いプレフィックスと新しいプレフィックスの同じ部分にある場合、この合成により、単一のプレフィックス制御操作がサイト内のすべてのルーターに新しいグローバルプレフィックスを定義し、サブネット構造を保持します。
Because of the power of the Router Renumbering mechanism, each RR message includes a sequence number to guard against replays, and is required to be authenticated and integrity-checked. Each single Prefix Control Operation is idempotent and so could be retransmitted for improved reliability, as long as the sequence number is current, without concern about multiple processing. However, non-idempotent combinations of PCOs can easily be constructed and messages containing such combinations could not be safely reprocessed. Therefore, all routers are required to guard against processing an RR message more than once. To allow reliable verification that Commands have been received and processed by routers, a mechanism for duplicate-command notification to the management station is included.
ルーターの変更メカニズムの力のため、各RRメッセージにはリプレイをガードするシーケンス番号が含まれており、認証され、整合性チェックされる必要があります。各プレフィックス制御操作は等量であるため、シーケンス番号が最新である限り、複数の処理を懸念しない限り、信頼性を向上させるために再送信することができます。ただし、PCOSの非人気の組み合わせを簡単に構築でき、そのような組み合わせを含むメッセージを安全に再処理することはできません。したがって、すべてのルーターは、RRメッセージの処理を複数回保護するために必要です。コマンドがルーターによって受信および処理されたという信頼できる検証を許可するために、管理ステーションへの重複コマンド通知のメカニズムが含まれています。
Possibly a network manager will want to perform more renumbering, or exercise more detailed control, than can be expressed in a single Router Renumbering packet on the available media. The RR mechanism is most powerful when RR packets are multicast, so IP fragmentation is undesirable. For these reasons, each RR packet contains a "Segment Number". All RR packets which have a Sequence Number greater than or equal to the highest value seen are valid and must be processed. However, a router must keep track of the Segment Numbers of RR messages already processed and avoid reprocessing a message whose Sequence Number and Segment Number match a previously processed message. (This list of processed segment numbers is reset when a new highest Sequence Number is seen.)
おそらく、ネットワークマネージャーは、利用可能なメディアで1つのルーターの変更パケットで表現できるよりも、より多くの変更を行うか、より詳細な制御を行使したいと思うでしょう。RRメカニズムは、RRパケットがマルチキャストである場合に最も強力であるため、IPの断片化は望ましくありません。これらの理由により、各RRパケットには「セグメント番号」が含まれています。見られる最高値以上のシーケンス番号を持つすべてのRRパケットは有効であり、処理する必要があります。ただし、ルーターは、すでに処理されているRRメッセージのセグメント番号を追跡し、シーケンス番号とセグメント番号が以前に処理されたメッセージと一致するメッセージの再処理を避ける必要があります。（この処理されたセグメント番号のリストは、新しい最高のシーケンス番号が表示されるとリセットされます。）
The Segment Number does not impose an ordering on packet processing. If a specific sequence of operations is desired, it may be achieved by ordering the PCOs in a single RR Command message or through the Sequence Number field.
セグメント番号には、パケット処理に順序付けがありません。特定の一連の操作が必要な場合、単一のRRコマンドメッセージでPCOSを注文するか、シーケンス番号フィールドを介してPCOSを注文することで達成される場合があります。
There is a "Test" flag which indicates that all routers should simulate processing of the RR message and not perform any actual reconfiguration. A separate "Report" flag instructs routers to send a Router Renumbering Result message back to the source of the RR Command message indicating the actual or simulated result of the operations in the RR Command message.
すべてのルーターがRRメッセージの処理をシミュレートし、実際の再構成を実行しないことを示す「テスト」フラグがあります。個別の「レポート」フラグは、ルーターに、RRコマンドメッセージの操作の実際のまたはシミュレートされた結果を示すRRコマンドメッセージのソースに表示される結果メッセージを返信するようにルーターに指示します。
The effect or simulated effect of an RR Command message may also be reported to network management by means outside the scope of this document, regardless of the value of the "Report" flag.
RRコマンドメッセージの効果またはシミュレートされた効果は、「レポート」フラグの値に関係なく、このドキュメントの範囲外の手段によってネットワーク管理にも報告される場合があります。
Address This term always refers to a 128-bit IPv6 address [AARCH]. When referring to bits within an address, they are numbered from 0 to 127, with bit 0 being the first bit of the Format Prefix.
アドレスこの用語は、常に128ビットIPv6アドレス[AARCH]を指します。アドレス内のビットを参照する場合、それらは0から127の番号が付けられ、ビット0はフォーマットプレフィックスの最初のビットです。
Prefix A prefix can be understood as an address plus a length, the latter being an integer in the range 0 to 128 indicating how many leading bits are significant. When referring to bits within a prefix, they are numbered in the same way as the bits of an address. For example, the significant bits of a prefix whose length is L are the bits numbered 0 through L-1, inclusive.
接頭辞は、アドレスと長さとして理解できます。後者は0〜128の範囲の整数であり、主要なビットの数が重要であることを示します。プレフィックス内のビットを参照する場合、アドレスのビットと同じ方法で番号が付けられます。たとえば、長さがlであるプレフィックスの大幅なビットは、包括的0からL-1のビット数です。
Match An address A "matches" a prefix P whose length is L if the first L bits of A are identical with the first L bits of P. (Every address matches a prefix of length 0.) A prefix P1 with length L1 matches a prefix P2 of length L2 if L1 >= L2 and the first L2 bits of P1 and P2 are identical.
アドレスA a aの最初のlビットがPの最初のlビットと同一である場合、アドレスa a a a "bise lest a on on preix p（すべてのアドレスは長さ0のプレフィックスと一致します）長さl1を持つプレフィックスP1と一致するプレフィックスP1L1> = L2とP1およびP2の最初のL2ビットの場合、長さL2のプレフィックスP2が同一です。
Prefix Control Operation This is the smallest individual unit of Router Renumbering operation. A Router Renumbering Command packet includes zero or more of these, each comprising one matching condition, called a Match-Prefix Part, and zero or more substitution specifications, called Use-Prefix Parts.
プレフィックス制御操作これは、ルーターの変更操作の最小の個々の単位です。ルーターの名前変更コマンドパケットには、これらのゼロ以上が含まれ、それぞれが一致する1つのマッチング条件で構成され、マッチプレフィックスパーツと呼ばれる条件と、使用-Prefixパーツと呼ばれるゼロ以上の置換仕様が含まれます。
Match-Prefix This is a Prefix against which a router compares the addresses and prefixes configured on its interfaces.
Match-Prefixこれは、ルーターがインターフェイスで構成されたアドレスとプレフィックスを比較するプレフィックスです。
Use-Prefix The prefix and associated information which is to be configured on a router interface when certain conditions are met.
使用して、特定の条件が満たされたときにルーターインターフェイスで構成されるプレフィックスと関連する情報を使用します。
Matched Prefix The existing prefix or address which matched a Match-Prefix.
一致するプレフィックスマッチプレフィックスに一致する既存のプレフィックスまたはアドレス。
New Prefix A prefix constructed from a Use-Prefix, possibly including some of the Matched Prefix.
新しいプレフィックス使用-Prefixから構築されたプレフィックス。おそらく一致したプレフィックスの一部を含む。
Recorded Sequence Number The highest sequence number found in a valid message MUST be recorded in non-volatile storage.
記録されたシーケンス番号有効なメッセージにある最高のシーケンス番号は、不揮発性ストレージに記録する必要があります。
Note that "matches" is a transitive relation but not symmetric. If two prefixes match each other, they are identical.
「一致」は推移的な関係であるが対称ではないことに注意してください。2つのプレフィックスが互いに一致する場合、それらは同一です。
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 [KWORD].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[kword]で説明されていると解釈される。
There are two types of Router Renumbering messages: Commands, which are sent to routers, and Results, which are sent by routers. A third message type is used to synchronize a reset of the Recorded Sequence Number with the cancellation of cryptographic keys. The three types of messages are distinguished the ICMPv6 "Code" field and differ in the contents of the "Message Body" field.
ルーターの名前を変更するルーターには、ルーターに送信されるコマンドと、ルーターによって送信されるコマンドの2つのタイプがあります。3番目のメッセージタイプは、記録されたシーケンス番号のリセットを暗号化キーのキャンセルと同期するために使用されます。3種類のメッセージは、ICMPV6「コード」フィールドと区別され、「メッセージ本文」フィールドの内容が異なります。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ IPv6 header, extension headers /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ ICMPv6 & RR Header (16 octets) /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ RR Message Body /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Router Renumbering Message Format
ルーターの名前変更メッセージ形式
Router Renumbering messages are carried in ICMPv6 packets with Type = 138. The RR message comprises an RR Header, containing the ICMPv6 header, the sequence and segment numbers and other information, and the RR Message Body, of variable length.
Routerの名前変更メッセージは、Type = 138のICMPv6パケットで送られます。RRメッセージは、ICMPv6ヘッダー、シーケンスとセグメント番号、その他の情報、およびさまざまな長さのRRメッセージ本文を含むRRヘッダーを含みます。
All fields marked "reserved" or "res" MUST be set to zero on generation of an RR message, and ignored on receipt.
「予約済み」または「RES」とマークされたすべてのフィールドは、RRメッセージの生成時にゼロに設定し、受領時に無視する必要があります。
All implementations which generate Router Renumbering Command messages MUST support sending them to the All Routers multicast address with link and site scopes, and to unicast addresses of link-local and site-local formats. All routers MUST be capable of receiving RR Commands sent to those multicast addresses and to any of their link local and site local unicast addresses. Implementations SHOULD support sending and receiving RR messages addressed to other unicast addresses. An implementation which is both a sender and receiver of RR commands SHOULD support use of the All Routers multicast address with node scope.
ルーターの変更コマンドメッセージを生成するすべての実装は、リンクとサイトスコープを使用したすべてのルーターマルチキャストアドレス、およびリンクローカルおよびサイトローカル形式のユニキャストアドレスに送信することをサポートする必要があります。すべてのルーターは、これらのマルチキャストアドレスと、ローカルおよびサイトのローカルユニキャストアドレスのいずれかに送信されるRRコマンドを受信できる必要があります。実装は、他のユニキャストアドレスにアドレス指定されたRRメッセージの送信と受信をサポートする必要があります。RRコマンドの送信者および受信者の両方である実装は、ノードスコープですべてのルーターマルチキャストアドレスの使用をサポートする必要があります。
Data authentication and message integrity MUST be provided for all Router Renumbering Command messages by appropriate IP Security [IPSEC] means. The integrity assurance must include the IPv6 destination address and the RR Header and Message Body. See section 7, "Security Considerations".
適切なIPセキュリティ[IPSEC]手段により、データ認証とメッセージの整合性をすべてのルーターに変更するコマンドメッセージに提供する必要があります。整合性保証には、IPv6宛先アドレスとRRヘッダーとメッセージ本文を含める必要があります。セクション7「セキュリティ上の考慮事項」を参照してください。
The use of authentication for Router Renumbering Result messages is RECOMMENDED.
結果メッセージの変更メッセージのルーターの認証の使用をお勧めします。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SequenceNumber |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SegmentNumber | Flags | MaxDelay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
田畑：
Type 138 (decimal), the ICMPv6 type value assigned to Router Renumbering
タイプ138（小数）、ICMPV6タイプの値はルーターに割り当てられています
Code 0 for a Router Renumbering Command 1 for a Router Renumbering Result 255 for a Sequence Number Reset. The Sequence Number Reset is described in section 5.
ルーターのコード0コマンドコマンド1のコマンド1は、シーケンス番号のリセットの結果255を変更します。シーケンス番号のリセットについては、セクション5で説明します。
Checksum The ICMPv6 checksum, as specified in [ICMPV6]. The checksum covers the IPv6 pseudo-header and all fields of the RR message from the Type field onward.
[ICMPv6]で指定されているように、ICMPV6チェックサムをチェックサムします。チェックサムは、IPv6擬似ヘッダーと、タイプフィールドからのRRメッセージのすべてのフィールドをカバーします。
SequenceNumber An unsigned 32-bit sequence number. The sequence number MUST be non-decreasing between Sequence Number Resets.
シーケンスナンバー符号なしの32ビットシーケンス番号。シーケンス番号は、シーケンス番号のリセット間で非廃止されている必要があります。
SegmentNumber An unsigned 8-bit field which enumerates different valid RR messages having the same SequenceNumber. No ordering among RR messages is imposed by the SegmentNumber.
SegmentNumber同じシーケンセンサーを持つ異なる有効なRRメッセージを列挙する署名されていない8ビットフィールド。RRメッセージ間の順序は、SegmentNumberによって課されません。
Flags A combination of one-bit flags. Five are defined and three bits are reserved.
フラグは、1ビットフラグの組み合わせです。5つが定義され、3つのビットが予約されています。
+-+-+-+-+-+-+-+-+
|T|R|A|S|P| res |
+-+-+-+-+-+-+-+-+
The flags T, R, A and S have defined meanings in an RR Command message. In a Result message they MUST be copied from the corresponding Command. The P flag is meaningful only in a Result message and MUST be zero in a transmitted Command and ignored in a received Command.
フラグT、R、A、およびSは、RRコマンドメッセージの意味を定義しています。結果メッセージでは、対応するコマンドからコピーする必要があります。Pフラグは結果メッセージでのみ意味があり、送信されたコマンドではゼロであり、受信コマンドで無視する必要があります。
T Test command -- 0 indicates that the router configuration is to be modified; 1 indicates a "Test" message: processing is to be simulated and no configuration changes are to be made.
Tテストコマンド-0は、ルーター構成を変更することを示します。1「テスト」メッセージを示します。処理はシミュレートされ、構成の変更は行われません。
R Result requested -- 0 indicates that a Result message MUST NOT be sent (but other forms of logging are not precluded); 1 indicates that the router MUST send a Result message upon completion of processing the Command message;
r要求された結果-0は、結果メッセージを送信してはならないことを示します（ただし、他の形式のロギングは除外されません）。1は、コマンドメッセージの処理が完了すると、ルーターが結果メッセージを送信する必要があることを示します。
A All interfaces -- 0 indicates that the Command MUST NOT be applied to interfaces which are administratively shut down; 1 indicates that the Command MUST be applied to all interfaces regardless of administrative shutdown status.
すべてのインターフェイス-0は、コマンドが管理上シャットダウンされているインターフェイスに適用されないことを示します。1は、管理上のシャットダウンステータスに関係なく、コマンドをすべてのインターフェイスに適用する必要があることを示します。
S Site-specific -- This flag MUST be ignored unless the router treats interfaces as belonging to different "sites". 0 indicates that the Command MUST be applied to interfaces regardless of which site they belong to; 1 indicates that the Command MUST be applied only to interfaces which belong to the same site as the interface to which the Command is addressed. If the destination address is appropriate for interfaces belonging to more than one site, then the Command MUST be applied only to interfaces belonging to the same site as the interface on which the Command was received.
Sサイト固有 - ルーターがインターフェイスを異なる「サイト」に属していると扱わない限り、このフラグは無視する必要があります。0は、どのサイトに属しているかに関係なく、コマンドをインターフェイスに適用する必要があることを示します。1は、コマンドが対処されているインターフェイスと同じサイトに属するインターフェイスにのみ適用する必要があることを示します。宛先アドレスが複数のサイトに属するインターフェイスに適している場合、コマンドは、コマンドが受信されたインターフェイスと同じサイトに属するインターフェイスにのみ適用する必要があります。
P Processed previously -- 0 indicates that the Result message contains the complete report of processing the Command;
Pが以前に処理されたP -0は、結果メッセージにコマンドの処理の完全なレポートが含まれていることを示します。
1 indicates that the Command message was previously processed (and is not a Test) and the responding router is not processing it again. This Result message MAY have an empty body.
1は、コマンドメッセージが以前に処理され（テストではない）、応答するルーターが再び処理していないことを示します。この結果メッセージには空のボディがある場合があります。
MaxDelay An unsigned 16-bit field specifying the maximum time, in milliseconds, by which a router MUST delay sending any reply to this Command. Implementations MAY generate the random delay between 0 and MaxDelay milliseconds with a finer granularity than 1ms.
MaxDelayミリ秒単位で最大時間を指定する署名のない16ビットフィールド。これにより、ルーターはこのコマンドへの返信を遅らせる必要があります。実装により、1MSより細かい粒度がある0からMaxdelayミリ秒の間のランダム遅延が生成される場合があります。
The body of an RR Command message is a sequence of zero or more Prefix Control Operations, each of variable length. The end of the sequence MAY be inferred from the IPv6 length and the lengths of extension headers which precede the ICMPv6 header.
RRコマンドメッセージの本文は、それぞれ可変長さのゼロ以上のプレフィックス制御操作のシーケンスです。シーケンスの終了は、IPv6の長さとICMPv6ヘッダーの前にある拡張ヘッダーの長さから推測できます。
A Prefix Control Operation has one Match-Prefix Part of 24 octets, followed by zero or more Use-Prefix Parts of 32 octets each.
プレフィックス制御操作には、24オクテットの1つのマッチプレフィックスパーツがあり、その後、それぞれ32オクテットのゼロ以上の使用-Prefixパーツが続きます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OpCode | OpLength | Ordinal | MatchLen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MinLen | MaxLen | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- MatchPrefix -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
田畑：
OpCode An unsigned 8-bit field specifying the operation to be performed when the associated MatchPrefix matches an interface's prefix or address. Values are:
Opcode関連するMatchprefixがインターフェイスのプレフィックスまたはアドレスと一致するときに実行される操作を指定する符号なしの8ビットフィールド。値は次のとおりです。
1 the ADD operation 2 the CHANGE operation
1操作の追加2変更操作
3 the SET-GLOBAL operation
3セットグローバル操作
OpLength The total length of this Prefix Control Operation, in units of 8 octets. A valid OpLength will always be of the form 4N+3, with N equal to the number of UsePrefix parts (possibly zero).
8オクテットのユニットでのこのプレフィックス制御操作の全長をoplength。有効なoplengthは常にフォーム4n 3であり、nはuseprefixパーツの数（おそらくゼロ）の数に等しくなります。
Ordinal An 8-bit field which MUST have a different value in each Prefix Control Operation contained in a given RR Command message. The value is otherwise unconstrained.
ordinal特定のRRコマンドメッセージに含まれる各プレフィックス制御操作に異なる値を持つ必要がある8ビットフィールド。それ以外の場合は、値は制約されていません。
MatchLen An 8-bit unsigned integer between 0 and 128 inclusive specifying the number of initial bits of MatchPrefix which are significant in matching.
マッチレン0〜128の間の8ビットの署名されていない整数を包括的に指定し、マッチングに重要なMatchPrefixの初期ビットの数を指定します。
MinLen An 8-bit unsigned integer specifying the minimum length which any configured prefix must have in order to be eligible for testing against the MatchPrefix.
Minlen MatchPrefixに対するテストの対象となるために、構成されたプレフィックスが必要とする最小長を指定する8ビットの署名整数。
MaxLen An 8-bit unsigned integer specifying the maximum length which any configured prefix may have in order to be eligible for testing against the MatchPrefix.
Maxlenは、MatchPrefixに対するテストの対象となるために、構成されたプレフィックスが持っている最大長を指定する8ビットの符号なし整数です。
MatchPrefix The 128-bit prefix to be compared with each interface's prefix or address.
MatchPrefix各インターフェイスのプレフィックスまたはアドレスと比較する128ビットプレフィックスを比較します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UseLen | KeepLen | FlagMask | RAFlags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V|P| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- UsePrefix -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
田畑：
UseLen An 8-bit unsigned integer less than or equal to 128 specifying the number of initial bits of UsePrefix to use in creating a new prefix for an interface.
USELENは、インターフェイスの新しいプレフィックスの作成に使用するUsePrefixの初期ビットの数を指定する128以下の8ビットの符号なし整数以下です。
KeepLen An 8-bit unsigned integer less than or equal to (128- UseLen) specifying the number of bits of the prefix or address which matched the associated Match-Prefix which should be retained in the new prefix. The retained bits are those at positions UseLen through (UseLen+KeepLen-1) in the matched address or prefix, and they are copied to the same positions in the New Prefix.
Keeplenは、新しいプレフィックスに保持する必要がある関連するマッチプレフィックスと一致するプレフィックスまたはアドレスのビット数を指定する（128- uselen）以下（128-uselen）以下（128-uselen）以下に等しい。保持されているビットは、一致したアドレスまたはプレフィックスにある（uselen keeplen-1）の位置にあるものであり、それらは新しいプレフィックスの同じ位置にコピーされます。
FlagMask An 8-bit mask. A 1 bit in any position means that the corresponding flag bit in a Router Advertisement (RA) Prefix Information Option for the New Prefix should be set from the RAFlags field in this Use-Prefix Part. A 0 bit in the FlagMask means that the RA flag bit for the New Prefix should be copied from the corresponding RA flag bit of the Matched Prefix.
8ビットマスクをフラッグマスクします。任意の位置の1ビットとは、ルーター広告（RA）プレフィックス情報オプションの対応するフラグビットが、この使用-PrefixパーツのRAFLAGSフィールドから設定する必要があることを意味します。フラッグマスクの0ビットは、新しいプレフィックスのRAフラグビットを、一致したプレフィックスの対応するRAフラグビットからコピーする必要があることを意味します。
RAFlags An 8 bit field which, under control of the FlagMask field, may be used to initialize the flags in Router Advertisement Prefix Information Options [ND] which advertise the New Prefix. Note that only two flags have defined meanings to date: the L (on-link) and A (autonomous configuration) flags. These flags occupy the two leftmost bit positions in the RAFlags field, corresponding to their position in the Prefix Information Option.
Raflags 8ビットフィールドは、フラッグマスクフィールドの制御下で、新しいプレフィックスを宣伝するルーター広告プレフィックス情報オプション[ND]のフラグを初期化するために使用できます。これまでの意味を定義している2つのフラグのみが、L（オンリンク）とA（自律構成）フラグのみであることに注意してください。これらのフラグは、Raflagsフィールドの2つの左のビット位置を占め、プレフィックス情報オプションの位置に対応しています。
Valid Lifetime A 32-bit unsigned integer which is the number of seconds for which the New Prefix will be valid [ND, SAA].
有効な寿命新しい接頭辞が有効になる秒数である32ビットの署名のない整数[nd、saa]。
Preferred Lifetime A 32-bit unsigned integer which is the number of seconds for which the New Prefix will be preferred [ND, SAA].
優先寿命は、新しいプレフィックスが優先される秒数[nd、saa]の32ビットの符号なし整数です。
V A 1-bit flag indicating that the valid lifetime of the New Prefix MUST be effectively decremented in real time.
v新しいプレフィックスの有効な寿命がリアルタイムで効果的に減少する必要があることを示す1ビットフラグ。
P A 1-bit flag indicating that the preferred lifetime of the New Prefix MUST be effectively decremented in real time.
P A 1ビットフラグ新しいプレフィックスの優先寿命をリアルタイムで効果的に減少させる必要があることを示す。
UsePrefix The 128-bit Use-prefix which either becomes or is used in forming (if KeepLen is nonzero) the New Prefix. It MUST NOT have the form of a multicast or link-local address [AARCH].
useprefixフォーミング（keeplenがゼロではない場合）になるか、または新しいプレフィックスのいずれかになるか、または使用される128ビットの使用-prefixを使用します。マルチキャストまたはリンクローカルアドレス[AARCH]の形式を持ってはなりません。
The body of an RR Result message is a sequence of zero or more Match Reports of 24 octets. An RR Command message with the "R" flag set will elicit an RR Result message containing one Match Report for each Prefix Control Operation, for each different prefix it matches on each interface. The Match Report has the following format.
RR結果メッセージの本体は、24オクテットのゼロ以上の一致レポートのシーケンスです。「R」フラグセットを使用したRRコマンドメッセージは、各インターフェイスで一致する各プレフィックスごとに、各プレフィックス制御操作に1つのマッチレポートを含むRR結果メッセージを誘発します。マッチレポートには次の形式があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved |B|F| Ordinal | MatchedLen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| InterfaceIndex |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- MatchedPrefix -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
田畑：
B A one-bit flag which, when set, indicates that one or more fields in the associated PCO were out of bounds. The bounds check is described in section 4.2.
b設定すると、関連するPCOの1つ以上のフィールドが範囲外であることを示す1ビットフラグ。限界チェックについては、セクション4.2で説明します。
F A one-bit flag which, when set, indicates that one or more Use-Prefix parts from the associated PCO were not honored by the router because of attempted formation of a forbidden prefix format, such as a multicast or loopback address.
f設定された場合、関連するPCOからの1つまたは複数の使用-Prefixパーツが、マルチキャストやループバックアドレスなどの禁止されたプレフィックス形式の形成を試みたため、ルーターによって尊重されなかったことを示す1ビットフラグ。
Ordinal Copied from the Prefix Control Operation whose MatchPrefix matched the MatchedPrefix on the interface indicated by InterfaceIndex.
MatchPrefixがInterfaceIndexで示されているインターフェイス上のMatchedPrefixと一致したプレフィックス制御操作からコピーされました。
MatchedLen The length of the Matched Prefix.
一致したプレフィックスの長さを一致させます。
InterfaceIndex The router's numeric designation of the interface on which the MatchedPrefix was configured. This MUST be the same as the value of ipv6IfIndex which designates that index in the SNMP IPv6 MIB General Group [IPV6MIB].
InterfaceIndex MatchedPrefixが構成されたインターフェイスのルーターの数値指定。これは、SNMP IPv6 MIB一般グループ[IPv6mib]のインデックスを指定するIPv6ifindexの値と同じでなければなりません。
It is possible for a Result message to be larger than the Command message which elicited it. Such a Result message may have to be fragmented for transmission. If so, it SHOULD be fragmented to the IPv6 minimum required MTU [IPV6].
結果メッセージがそれを引き出したコマンドメッセージよりも大きくなる可能性があります。このような結果メッセージは、送信のために断片化する必要がある場合があります。その場合、IPv6最小必要なMTU [IPv6]に断片化する必要があります。
Processing of received Router Renumbering Result messages is entirely implementation-defined. Implementation of Command message processing may vary in detail from the procedure set forth below, so long as the result is not affected.
受信したルーターの変更結果メッセージの処理は、完全に実装定義です。コマンドメッセージ処理の実装は、結果が影響を受けない限り、以下に示す手順から詳細に異なる場合があります。
Processing of received Router Renumbering Command messages consists of three conceptual parts: header check, bounds check, and execution.
受信ルーターの変更コマンドメッセージの処理は、ヘッダーチェック、境界チェック、および実行の3つの概念パーツで構成されています。
The ICMPv6 checksum and type are presumed to have been checked before a Router Renumbering module receives a Command to process. In an implementation environment where this may not be the case, those checks MUST be made at this point in the processing.
ICMPV6チェックサムとタイプは、ルーターの変更モジュールが処理するコマンドを受信する前にチェックされたと推定されます。これが当てはまらない可能性のある実装環境では、これらのチェックを処理のこの時点で行う必要があります。
If the ICMPv6 length derived from the IPv6 length is less than 16 octets, the message MUST be discarded and SHOULD be logged to network management.
IPv6の長さに由来するICMPv6の長さが16オクテット未満の場合、メッセージを破棄する必要があり、ネットワーク管理に記録する必要があります。
If the ICMPv6 Code field indicates a Result message, a router which is not a source of RR Command messages MUST discard the message and SHOULD NOT log it to network management.
ICMPV6コードフィールドが結果メッセージを示した場合、RRコマンドメッセージのソースではないルーターはメッセージを破棄する必要があり、ネットワーク管理にログインしないでください。
If the IPv6 destination address is neither an All Routers multicast address [AARCH] nor one of the receiving router's unicast addresses, the message MUST be discarded and SHOULD be logged to network management.
IPv6宛先アドレスがすべてのルーターのマルチキャストアドレス[AARCH]ではない場合、または受信ルーターのユニキャストアドレスの1つではなく、メッセージを破棄する必要があり、ネットワーク管理に記録する必要があります。
Next, the SequenceNumber is compared to the Recorded Sequence Number. (If no RR messages have been received and accepted since system initialization, the Recorded Sequence Number is zero.) This comparison is done with the two numbers considered as unsigned integers, not as DNS-style serial numbers. If the SequenceNumber is less than the Recorded Sequence Number, the message MUST be discarded and SHOULD be logged to network management.
次に、シーケンセンサーは記録されたシーケンス番号と比較されます。（システムの初期化以降にRRメッセージが受信されていない場合、記録されたシーケンス番号はゼロです。）この比較は、DNSスタイルのシリアル番号としてではなく、符号なしの整数と見なされる2つの数値で行われます。シーケンセンサーが記録されたシーケンス番号よりも少ない場合、メッセージを破棄する必要があり、ネットワーク管理に記録する必要があります。
Finally, if the SequenceNumber in the message is greater than the Recorded Sequence Number or the T flag is set, skip to the bounds check. Otherwise the SegmentNumber MUST now be checked. If a correctly authenticated message with the same SequenceNumber and SegmentNumber has not already been processed, skip to the bounds check. Otherwise, this Command is a duplicate and not a Test Command. If the R flag is not set, the duplicate message MUST be discarded and SHOULD NOT be logged to network management. If R is set, an RR Result message with the P flag set MUST be scheduled for transmission to the source address of the Command after a random time uniformly distributed between 0 and MaxDelay milliseconds. The body of that Result message MUST either be empty or be a saved copy of the Result message body generated by processing of the previous message with the same SequenceNumber and SegmentNumber. After scheduling the Result message, the Command MUST be discarded without further processing.
最後に、メッセージ内のシーケンセンサーが記録されたシーケンス番号よりも大きい場合、またはTフラグが設定されている場合は、Bounds Checkにスキップします。それ以外の場合は、SegmentNumberを確認する必要があります。同じシーケンセンサーとSegmentNumberを使用した正しく認証されたメッセージがまだ処理されていない場合は、Bounds Checkにスキップします。それ以外の場合、このコマンドは複製であり、テストコマンドではありません。Rフラグが設定されていない場合、複製メッセージを破棄する必要があり、ネットワーク管理にログインしないでください。Rが設定されている場合、Pフラグセットを使用したRR結果メッセージは、ランダムな時間が0とMaxdelayミリ秒の間に均一に分布した後、コマンドのソースアドレスに送信するようにスケジュールする必要があります。その結果メッセージの本文は、同じシーケンスナンバーとセグメントナンバーを使用して前のメッセージの処理によって生成された結果メッセージ本文の保存されたコピーである必要があります。結果メッセージをスケジュールした後、コマンドはさらに処理せずに破棄する必要があります。
If the SequenceNumber is greater than the Recorded Sequence Number, then the list of processed SegmentNumbers and the set of saved Result messages, if any, MUST be cleared and the Recorded Sequence Number MUST be updated to the value used in the current message, regardless of subsequent processing errors.
シーケンセンサーが記録されたシーケンス番号よりも大きい場合、処理されたセグメント数のリストと保存された結果メッセージのセットをクリアする必要があり、記録されたシーケンス番号を現在のメッセージで使用する値に更新する必要があります。後続の処理エラー。
Next, if the ICMPv6 Code field indicates a Sequence Number Reset, skip to section 5.
次に、ICMPV6コードフィールドがシーケンス番号のリセットを示した場合、セクション5にスキップします。
At this point, if T is set in the RR header and R is not set, the message MAY be discarded without further processing.
この時点で、TがRRヘッダーに設定され、Rが設定されていない場合、メッセージはさらに処理せずに破棄される場合があります。
If the R flag is set, begin constructing an RR Result message. The RR header of the Result message is completely determined at this time except for the Checksum.
Rフラグが設定されている場合は、RR結果メッセージの作成を開始します。結果メッセージのRRヘッダーは、チェックサムを除き、現時点では完全に決定されます。
The values of the following fields of a PCO MUST be checked to ensure that they are within the appropriate bounds.
PCOの次のフィールドの値を確認して、適切な範囲内にあることを確認する必要があります。
OpCode must be a defined value.
opcodeは定義された値である必要があります。
OpLength must be of the form 4N+3 and consistent the the length of the Command packet and the PCO's offset within the packet.
oplengthはフォーム4n 3であり、コマンドパケットの長さとパケット内のPCOのオフセットを一貫している必要があります。
MatchLen must be between 0 and 128 inclusive
Matchlenは0〜128の包括的でなければなりません
UseLen, KeepLen in each Use-Prefix Part must be between 0 and 128 inclusive, as must the sum of the two.
Uselen、各使用-PrefixパーツのKeeplenは、2つの合計と同様に、0〜128の包括的でなければなりません。
If any of these fields are out of range in a PCO, the entire PCO MUST NOT be performed on any interface. If the R flag is set in the RR header then add to the RR Result message a Match Report with the B flag set, the F flag clear, the Ordinal copied from the PCO, and all other fields zero. This Match Report MUST be included only once, not once per interface.
これらのフィールドのいずれかがPCOで範囲外である場合、PCO全体をどのインターフェースでも実行してはなりません。RフラグがRRヘッダーに設定されている場合は、RR結果メッセージにBフラグセット、Fフラグクリア、PCOからコピーされた順序、および他のすべてのフィールドがゼロになるマッチレポートを追加します。このマッチレポートは、インターフェイスごとに1回ではなく、一度だけ含める必要があります。
Note that MinLen and MaxLen need not be explicitly bounds checked, even though certain combinations of values will make any matches impossible.
特定の値の組み合わせが一致を不可能にする場合でも、MinlenとMaxlenを明示的にチェックする必要はないことに注意してください。
For each applicable router interface, as determined by the A and S flags, the Prefix Control Operations in an RR Command message must be carried out in order of appearance. The relative order of PCO processing among different interfaces is not specified.
AフラグとSフラグによって決定される、該当する各ルーターインターフェイスについて、RRコマンドメッセージのプレフィックス制御操作は、外観の順に実行する必要があります。異なるインターフェイス間のPCO処理の相対順序は指定されていません。
If the T flag is set, create a copy of each interface's configuration on which to operate, because the results of processing a PCO may affect the processing of subsequent PCOs. Note that if all operations are performed on one interface before proceeding to another interface, only one interface-configuration copy will be required at a time.
Tフラグが設定されている場合、PCOの処理結果が後続のPCOSの処理に影響を与える可能性があるため、各インターフェイスの構成のコピーを作成します。別のインターフェイスに進む前にすべての操作が1つのインターフェイスで実行される場合、一度に1つのインターフェイス構成コピーのみが必要になることに注意してください。
For each interface and for each Prefix Control Operation, each prefix configured on that interface with a length between the MinLen and MaxLen values in the PCO is tested to determine whether it matches (as defined in section 2.1) the MatchPrefix of the PCO. The configured prefixes are tested in an arbitrary order. Any new prefix configured on an interface by the effect of a given PCO MUST NOT be tested against that PCO, but MUST be tested against all subsequent PCOs in the same RR Command message.
各インターフェイスおよび各プレフィックス制御操作について、PCOのMinlen値とMaxlen値の間の長さでそのインターフェイスで構成された各プレフィックスがテストされ、PCOのマッチフィックスと一致するかどうか（セクション2.1で定義されている）かどうかを判断します。構成されたプレフィックスは、任意の順序でテストされます。特定のPCOの効果によってインターフェイスに構成された新しいプレフィックスは、そのPCOに対してテストする必要はありませんが、同じRRコマンドメッセージの後続のすべてのPCOに対してテストする必要があります。
Under a certain condition the addresses on an interface are also tested to see whether any of them matches the MatchPrefix. If and only if a configured prefix "P" does have a length between MinLen and MaxLen inclusive, does not match the MatchPrefix "M", but M does match P (this can happen only if M is longer than P), then those addresses on that interface which match P MUST be tested to determine whether any of them matches M. If any such address does match M, process the PCO as if P matched M, but when forming New Prefixes, if KeepLen is non-zero, bits are copied from the address. This special case allows a PCO to be easily targeted to a single specific interface in a network.
特定の条件下では、インターフェイス上のアドレスもテストされて、それらのいずれかがMatchPrefixと一致するかどうかを確認します。構成されたプレフィックス「P」の長さがMinlenとMaxlen Inclusiveの長さを持っている場合にのみ、MatchPrefix "M"と一致しませんが、MはP（MがPよりも長い場合にのみ発生する可能性があります）、それらのアドレスはPと一致するインターフェイスでは、それらのいずれかがMに一致するかどうかを判断するためにテストする必要があります。そのようなアドレスがMと一致する場合、PCOをPCOをMAST Mに一致させるかのように処理しますが、新しいプレフィックスを形成する場合、Keeplenがゼロではない場合、ビットはビットです住所からコピーされました。この特別なケースにより、PCOはネットワーク内の単一の特定のインターフェイスを簡単にターゲットにすることができます。
If P does not match M, processing is finished for this combination of PCO, interface and prefix. Continue with another prefix on the same interface if there are any more prefixes which have not been tested against this PCO and were not created by the action of this PCO. If no such prefixes remain on the current interface, continue processing with the next PCO on the same interface, or with another interface.
PがMと一致しない場合、PCO、インターフェイス、プレフィックスのこの組み合わせの処理が完了します。このPCOに対してテストされておらず、このPCOのアクションによって作成されていないプレフィックスがこれ以上ある場合、同じインターフェイス上の別のプレフィックスを続行します。現在のインターフェイスにそのようなプレフィックスが残っていない場合は、同じインターフェイス上の次のPCOまたは別のインターフェイスで処理を続けます。
If P does match M, either directly or because a configured address which matches P also matches M, then P is the Matched Prefix. Perform the following steps.
Pが直接Mと一致する場合、またはPと一致する構成アドレスがMと一致するため、Pは一致したプレフィックスです。次の手順を実行します。
If the Command has the R flag set, add a Match Report to the Result message being constructed.
コマンドにRフラグが設定されている場合は、作成されている結果メッセージに一致レポートを追加します。
If the OpCode is CHANGE, mark P for deletion from the current interface.
オペコードが変更されている場合、現在のインターフェイスから削除をマークします。
If the OpCode is SET-GLOBAL, mark all global-scope prefixes on the current interface for deletion.
オペコードがセットグロバルの場合、削除のために現在のインターフェイスにすべてのグローバルスコーププレフィックスをマークします。
If there are any Use-Prefix parts in the current PCO, form the New Prefixes. Discard any New Prefix which has a forbidden format, and if the R flag is set in the command, set the F flag in the Match Report for this PCO and interface. Forbidden prefix formats include, at a minimum, multicast, unspecified and loopback addresses. [AARCH] Any implementation MAY forbid, or allow the network manager to forbid other formats as well.
現在のPCOに使用されているPrefixパーツがある場合は、新しいプレフィックスを形成します。禁止形式のある新しいプレフィックスを破棄し、Rフラグがコマンドに設定されている場合は、このPCOとインターフェイスのマッチレポートにFフラグを設定します。禁止されたプレフィックス形式には、少なくともマルチキャスト、不特定、ループバックアドレスが含まれます。[AARCH]実装は禁止されている場合もあれば、ネットワークマネージャーも他の形式を禁止することもできます。
For each New Prefix which is already configured on the current interface, unmark that prefix for deletion and update the lifetimes and RA flags. For each New Prefix which is not already configured, add the prefix and, if appropriate, configure an address with that prefix.
現在のインターフェイスで既に構成されている新しいプレフィックスごとに、削除のためにそのプレフィックスをマークし、ライフタイムとRAフラグを更新します。まだ構成されていない新しいプレフィックスごとに、プレフィックスを追加し、必要に応じてそのプレフィックスでアドレスを構成します。
Delete any prefixes which are still marked for deletion, together with any addresses which match those prefixes but do not match any prefix which is not marked for deletion.
削除のためにまだマークされているプレフィックスを削除します。これらのプレフィックスに一致するアドレスとともに、削除にマークされていないプレフィックスと一致しません。
After processing all the Prefix Control Operations on all the interfaces, an implementation MUST record the SegmentNumber of the packet in a list associated with the SequenceNumber.
すべてのインターフェイスですべてのプレフィックス制御操作を処理した後、実装はシーケンセンサーに関連付けられたリストにパケットのセグメント数を記録する必要があります。
If the Command has the R flag set, compute the Checksum and schedule the Result message for transmission after a random time interval uniformly distributed between 0 and MaxDelay milliseconds. This interval SHOULD begin at the conclusion of processing, not the beginning. A copy of the Result message MAY be saved to be retransmitted in response to a duplicate Command.
コマンドにRフラグが設定されている場合は、チェックサムを計算し、ランダムな時間間隔が0と最大ミリ秒の間に均一に分布した後に結果メッセージをスケジュールします。この間隔は、開始ではなく、処理の終了時に開始する必要があります。結果メッセージのコピーは、重複コマンドに応じて再送信されるように保存される場合があります。
The only Neighbor Discovery [ND] parameters which can be affected by Router Renumbering are the following.
ルーターの変更によって影響を受ける可能性のある唯一の隣接発見[ND]パラメーターは次のとおりです。
A router's addresses and advertised prefixes, including the prefix lengths.
ルーターのアドレスと、プレフィックスの長さを含む宣伝されたプレフィックス。
The flag bits (L and A, and any which may be defined in the future) and the valid and preferred lifetimes which appear in a Router Advertisement Prefix Information Option.
フラグビット（LおよびA、および将来定義される可能性がある）およびルーター広告プレフィックス情報オプションに表示される有効で好ましい寿命。
That unnamed property of the lifetimes which specifies whether they are fixed values or decrementing in real time.
固定値であるか、リアルタイムで減少するかを指定する生涯の名前のない財産。
Other internal router information, such as the time until the next unsolicited Router Advertisement or MIB variables MAY be affected as needed.
次の未承諾ルーター広告やMIB変数までの時間など、その他の内部ルーター情報が必要に応じて影響を受ける可能性があります。
All configuration changes resulting from Router Renumbering SHOULD be saved to non-volatile storage where this facility exists. The problem of properly restoring prefix lifetimes from non-volatile storage exists independently of Router Renumbering and deserves careful attention, but is outside the scope of this document.
ルーターの変更に起因するすべての構成変更は、この施設が存在する不揮発性ストレージに保存する必要があります。非揮発性ストレージからプレフィックスの寿命を適切に復元するという問題は、ルーターの名前を変更することとは独立して存在し、慎重な注意に値しますが、このドキュメントの範囲外です。
It may prove necessary in practice to reset a router's Recorded Sequence Number. This is a safe operation only when all cryptographic keys previously used to authenticate RR Commands have expired or been revoked. For this reason, the Sequence Number Reset message is defined to accomplish both functions.
実際には、ルーターの記録されたシーケンス番号をリセットする必要があることが証明される場合があります。これは、RRコマンドの認証に以前に使用されていたすべての暗号化キーが期限切れまたは取り消された場合にのみ、安全な操作です。このため、シーケンス番号リセットメッセージは、両方の関数を達成するために定義されています。
When a Sequence Number Reset (SNR) has been authenticated and has passed the header check, the router MUST invalidate all keys which have been used to authenticate previous RR Commands, including the key which authenticated the SNR itself. Then it MUST discard any saved RR Result messages, clear the list of recorded SegmentNumbers and reset the Recorded Sequence Number to zero.
シーケンス番号リセット（SNR）が認証され、ヘッダーチェックに合格した場合、ルーターは、SNR自体を認証するキーを含む、以前のRRコマンドを認証するために使用されたすべてのキーを無効にする必要があります。次に、保存されたRR結果メッセージを破棄し、記録されたセグメント数のリストをクリアし、記録されたシーケンス番号をゼロにリセットする必要があります。
If the router has no other, unused authentication keys already available for Router Renumbering use it SHOULD establish one or more new valid keys. The details of this process will depend on whether manual keying or a key management protocol is used. In either case, if no keys are available, no new Commands can be processed.
ルーターに他の未使用の認証キーが既に使用可能である場合、使用可能なルーターの使用に既に利用可能な場合、1つ以上の新しい有効なキーが確立されるはずです。このプロセスの詳細は、手動キーイングまたはキー管理プロトコルが使用されるかどうかによって異なります。どちらの場合でも、キーが利用できない場合、新しいコマンドを処理することはできません。
A SNR message SHOULD contain no PCOs, since they will be ignored. If and only if the R flag is set in the SNR message, a router MUST respond with a Result Message containing no Match Reports. The header and transmission of the Result are as described in section 3.
SNRメッセージには無視されるため、PCOSを含める必要はありません。RフラグがSNRメッセージに設定されている場合にのみ、ルーターは一致しないレポートを含む結果メッセージで応答する必要があります。結果のヘッダーと送信は、セクション3で説明されています。
The invalidation of authentication keys caused by a valid SNR message will cause retransmitted copies of that message to be ignored.
有効なSNRメッセージによって引き起こされる認証キーの無効化により、そのメッセージの再送信コピーが無視されます。
Following the policies outlined in [IANACON], new values of the Code field in the Router Renumbering Header (section 3.1) and the OpCode field of the Match-Prefix Part (section 3.2.1.1) are to be allocated by IETF consensus only.
[ianacon]で概説されているポリシーに続いて、ルーターの名前を変更するルーターのコードフィールドの新しい値（セクション3.1）とマッチ-Prefixパーツ（セクション3.2.1.1）のオペコードフィールドは、IETFコンセンサスのみによってのみ割り当てられます。
The Router Renumbering mechanism proposed here is very powerful and prevention of spoofing it is important. Replay of old messages must, in general, be prevented (even though a narrow class of messages exists for which replay would be harmless). What constitutes a sufficiently strong authentication algorithm may change from time to time, but algorithms should be chosen which are strong against current key-recovery and forgery attacks.
ここで提案されているルーターの変更メカニズムは非常に強力であり、スプーフィングを防ぐことが重要です。一般的に、古いメッセージのリプレイを防ぐ必要があります（リプレイが無害になる狭いクラスのメッセージが存在していても）。十分に強力な認証アルゴリズムを構成するものは、随時変更される可能性がありますが、現在のキーリクアーおよび偽造攻撃に対して強力なアルゴリズムを選択する必要があります。
Authentication keys must be as well protected as any other access method that allows reconfiguration of a site's routers. Distribution of keys must not expose them or permit alteration, and key validity must be limited in terms of time and number of messages authenticated.
認証キーは、サイトのルーターの再構成を可能にする他のアクセス方法と同様に保護する必要があります。キーの配布は、それらを公開したり、変更を許可したりしてはなりません。また、主要な妥当性は、認証されたメッセージの時間と数の点で制限する必要があります。
Note that although a reset of the Recorded Sequence Number requires the cancellation of previously-used authentication keys, introduction of new keys and expiration of old keys does not require resetting the Recorded Sequence Number.
記録されたシーケンス番号のリセットには、以前に使用されている認証キーのキャンセルが必要ですが、新しいキーの導入と古いキーの有効期限は記録されたシーケンス番号をリセットする必要はありません。
The Security Policy Database (SPD) [IPSEC] of a router implementing this specification MUST cause incoming Router Renumbering Command packets to either be discarded or have IPsec applied. (The determination of "discard" or "apply" MAY be based on the source address.) The resulting Security Association Database (SAD) entries MUST ensure authentication and integrity of the destination address and the RR Header and Message Body, and the body length implied by the IPv6 length and intervening extension headers. These requirements are met by the use of the Authentication Header [AH] in transport or tunnel mode, or the Encapsulating Security Payload [ESP] in tunnel mode with non-NULL authentication. The mandatory-to-implement IPsec authentication algorithms (other than NULL) seem strong enough for Router Renumbering at the time of this writing.
この仕様を実装するルーターのセキュリティポリシーデータベース（SPD）[IPSEC]は、着信ルーターの名前を変更するコマンドパケットを破棄するか、IPSECを適用してもらう必要があります。（「廃棄」または「適用」の決定は、ソースアドレスに基づいている場合があります。）結果のセキュリティ協会データベース（SAD）エントリは、宛先アドレスとRRヘッダーとメッセージ本文の認証と整合性、および体の長さを確保する必要があります。IPv6の長さと介入拡張ヘッダーによって暗示されます。これらの要件は、輸送モードまたはトンネルモードで認証ヘッダー[AH]を使用するか、非ヌル認証を使用したトンネルモードのセキュリティペイロード[ESP]をカプセル化することにより満たされます。必須のIPSEC認証アルゴリズム（null以外）は、この執筆時点でルーターの名前を変更するのに十分な強さのようです。
Note that for the SPD to distinguish Router Renumbering from other ICMP packets requires the use of the ICMP Type field as a selector. This is consistent with, although not mentioned by, the Security Architecture specification [IPSEC].
SPDが他のICMPパケットと変更を変更するルーターを区別するには、ICMPタイプフィールドをセレクターとして使用する必要があることに注意してください。これは、セキュリティアーキテクチャの仕様[IPSEC]によって言及されていませんが、言及されていませんが、一致しています。
At the time of this writing, there exists no multicast key management protocol for IPsec and none is on the horizon. Manually configured Security Associations will therefore be common. The occurrence of "from traffic" in the table below would therefore more realistically be a wildcard or a fixed range. Use of a small set of shared keys per management station suffices, so long as key distribution and storage are sufficiently safeguarded.
この執筆時点では、IPSEC用のマルチキャストキー管理プロトコルは存在せず、地平線上にありません。したがって、手動で構成されたセキュリティ協会が一般的です。したがって、下の表に「トラフィックから」の発生は、より現実的にワイルドカードまたは固定範囲になります。主要な配布とストレージが十分に保護されている限り、管理ステーションごとに共有キーの小さなセットの使用で十分です。
A sufficient set of SPD entries for incoming traffic could select
着信トラフィック用のSPDエントリの十分なセットは選択できます
Field SPD Entry SAD Entry
------- --------- ---------
Source wildcard from traffic
Destination wildcard from SPD
Transport ICMPv6 from SPD
ICMP Type Rtr. Renum. from SPD
Action Apply IPsec
SA Spec AH/Transport Mode
or there might be an entry for each management station and/or for each of the router's unicast addresses and for each of the defined All-Routers multicast addresses, and a final wildcard entry to discard all other incoming RR messages.
または、各管理ステーションおよび/またはルーターの各ユニキャストアドレス、および定義された各ルーターマルチキャストアドレス、および他のすべての着信RRメッセージを破棄する最終的なワイルドカードエントリのエントリがある場合があります。
The SPD and SAD are conceptually per-interface databases. This fact may be exploited to permit shared management of a border router, for example, or to discard all Router Renumbering traffic arriving over tunnels.
SPDとSADは、概念的にインターフェイスごとのデータベースです。この事実は、たとえば、ボーダールーターの共有管理を許可したり、トンネルに到着するすべてのルーターの変更交通を廃棄するために活用される場合があります。
Users of Router Renumbering will want to be sure that every non-trivial message reaches every intended router. Well-considered exploitation of Router Renumbering's retransmission and response-directing features should make that goal achievable with high confidence even in a minimally reliable network.
ルーターの変更のユーザーは、すべての些細なメッセージが目的とするすべてのルーターに到達することを確認したいと思うでしょう。Router Renhumberingの再送信と対応指向性の機能のよく考慮された搾取は、最小限の信頼性のあるネットワークでも自信を持ってその目標を達成できるはずです。
In one set of cases, probably the majority, the network management station will know the complete set of routers under its control. Commands can be retransmitted, with the "R" (Reply-requested) flag set in the RR header, until Results have been collected from all routers. If unicast Security Associations (or the means for creating them) are available, the management station may switch from multicast to unicast transmission when the number of routers still unheard-from is suitably small.
おそらく多数派の1つのケースでは、ネットワーク管理ステーションは、その制御下のルーターの完全なセットを知るでしょう。コマンドは、すべてのルーターから結果が収集されるまで、RRヘッダーに「R」（REPLY-REQUESTED）フラグを設定して再送信できます。ユニキャストセキュリティ協会（またはそれらを作成するための手段）が利用可能な場合、管理ステーションは、マルチキャストからユニキャスト送信に切り替えることができます。
To maintain a list of managed routers, the management station can employ any of several automatic methods which may be more convenient than manual entry in a large network. Multicast RR "Test" commands can be sent periodically and the results archived, or the management station can use SNMP to "peek" into a link-state routing protocol such as OSPF [OSPFMIB]. (In the case of OSPF, roughly one router per area would need to be examined to build a complete list of routers.)
管理されたルーターのリストを維持するために、管理ステーションは、大規模なネットワークでの手動入力よりも便利ないくつかの自動方法のいずれかを使用できます。マルチキャストRR「テスト」コマンドを定期的に送信し、結果をアーカイブすることができます。または、管理ステーションはSNMPを使用してOSPF [OSPFMIB]などのリンク状態ルーティングプロトコルに「覗く」ことができます。（OSPFの場合、ルーターの完全なリストを作成するには、エリアごとに約1つのルーターを調べる必要があります。）
In a large dynamic network where the set of managed routers is not known but reliable execution is desired, a scalable method for achieving confidence in delivery is described here. Nothing in this section affects the format or content of Router Renumbering messages, nor their processing by routers.
管理されたルーターのセットが不明であるが信頼性の高い実行が望まれる大きな動的ネットワークでは、ここでは配信に信頼を達成するためのスケーラブルな方法について説明します。このセクションの何も、メッセージの変更メッセージの形式またはコンテンツ、またはルーターによる処理に影響するものはありません。
A management station implementing these reliability mechanisms MUST alert an operator who attempts to commence a set of Router Renumbering Commands when retransmission of a previous set is not yet completed, but SHOULD allow the operator to override the warning.
これらの信頼性メカニズムを実装する管理ステーションは、以前のセットの再送信がまだ完了していない場合に、ルーターの変更コマンドのセットを開始しようとするオペレーターに警告する必要がありますが、オペレーターが警告をオーバーライドできるようにする必要があります。
The set of routers being managed with Router Renumbering is considered as a set of populations, each population having a characteristic probability of successful round-trip delivery of a Command/Result pair. The goal is to estimate a lower bound, P, on the round-trip probability for the whole set. With this estimate and other data about the responses to retransmissions of the Command, a confidence level can be computed for hypothesis that all routers have been heard from.
ルーターの変更で管理されているルーターのセットは、集団のセットと見なされ、各集団はコマンド/結果ペアの往復配信を成功させる特徴的な確率を持っています。目標は、セット全体の往復確率で下限pを推定することです。コマンドの再送信に対する応答に関するこの推定およびその他のデータを使用すると、すべてのルーターが聞かれたという仮説のために信頼レベルを計算できます。
If the true probability of successful round-trip communication with a managed router were a constant, p, for all managed routers then an estimate P of p could be derived from either of these statistics:
管理されたルーターとの往復通信を成功させる真の確率が一定であった場合、すべての管理されたルーターに対してPの推定Pは、これらの統計のいずれかから導き出されます。
The expected ratio of the number of routers first heard from after transmission (N + 1) to the number first heard from after N is (1 - p).
n is（1 -p）の後から最初に聞かれる数との透過後（n 1）との最初に聞こえるルーターの数の予想比。
When N different routers have been heard from after M transmissions of a Command, the expected total number of Result messages received is pNM. If R is the number of Results actually received, then P = R/MN.
コマンドのm送信後に異なるルーターが聞こえた場合、受信した結果メッセージの予想される総数はPNMです。rが実際に受信した結果の数である場合、p = r/mn。
The two methods are not equivalent. The first suffers numerical problems when the number of routers still to be heard from gets small, so the P = R/MN estimate should be used.
2つの方法は同等ではありません。最初のものは、まだ聞こえているルーターの数が小さくなった場合に数値的な問題を抱えているため、p = r/mnの推定値を使用する必要があります。
Since the round-trip probability is not expected to be uniform in the real world, and the less-reliable units are more important to a lower-bound estimate but more likely to be missed in sampling, the sample from which P is computed is biased toward the less-reliable routers. After the Nth transmission interval, N > 2, neglect all routers heard from in intervals 1 through F from the reliability estimate, where F is the greatest integer less than one-half of N. For example, after five intervals, only routers first heard from in the third through fifth intervals will be counted.
往復確率は現実の世界では均一ではないため、信頼性の低いユニットは下部の推定よりも重要であるが、サンプリングで見逃される可能性が高いため、Pが計算されたサンプルはバイアスされています信頼性の低いルーターに向かって。n番目の伝送間隔n> 2の後、すべてのルーターが信頼性推定値から間隔1からFから聞いたすべてのルーターを無視します。ここで、FはNの半分未満の最大整数です。たとえば、5つの間隔の後、ルーターのみが最初に聞いた3番目から5番目の間隔からカウントされます。
A management station implementing the methods of this section should allow the user to specify the following parameters, and default them to the indicated values.
このセクションのメソッドを実装する管理ステーションでは、ユーザーが次のパラメーターを指定し、指定された値にデフォルトできるようにする必要があります。
Ct The target delivery confidence, default 0.999.
CTターゲット配信の信頼性、デフォルト0.999。
Pp A presumptive, pessimistic initial estimate of the lower bound of the round-trip probability, P, to prevent early termination. (See below.) Default 0.75.
PP早期終了を防ぐための往復確率の下限PETの推定、悲観的な初期推定。（以下を参照してください。）デフォルト0.75。
Ti The initial time between Command retransmissions. Default 4 seconds. MaxDelay milliseconds (see section 3.1) must be added to the retransmission timer. Knowledge of the routers' processing time for RR Commands may influence the setting of Ti. Ti+MaxDelay is also the minimum time the management station must wait for Results after each transmission before computing a new confidence level. The phrase "end of the Nth interval" means a time Ti+MaxDelay after the Nth transmission of a Command.
tiコマンド再送信間の初期時間。デフォルト4秒。Maxdelay Milliseconds（セクション3.1を参照）を再送信タイマーに追加する必要があります。RRコマンドのルーターの処理時間に関する知識は、TIの設定に影響を与える可能性があります。Ti Maxdelayは、新しい信頼レベルを計算する前に、送信後に管理ステーションが結果を待つ必要がある最小時間です。「n番目の間隔の終わり」というフレーズは、コマンドのn番目の伝送後のタイムti maxdelayを意味します。
Tu The upper bound on the period between Command retransmissions. Default 512 seconds.
コマンドの再送信間の期間の上限をtuします。デフォルト512秒。
The following variables, some a function of the retransmission counter N, are used in the next section.
次の変数、いくつかの再送信カウンターNの関数が次のセクションで使用されます。
T(N) The time between Command transmissions N and N+1 is V*T(N) + MaxDelay, where V is random and roughly uniform in the range [0.75, 1.0]. T(1) = Ti and for N > 1, T(N) = min(2*T(N-1), Tu).
t（n）コマンドトランスミッションnからn 1の間の時間はv*t（n）maxdelayであり、vはランダムで範囲内のほぼ均一です[0.75、1.0]。t（1）= tiおよびn> 1の場合、t（n）= min（2*t（n-1）、tu）。
M(N) The cumulative number of distinct routers from which replies have been received to any of the first N transmissions of the Command.
m（n）コマンドの最初のn送信のいずれかに対する応答が受信された異なるルーターの累積数。
F=F(N) FLOOR((N-1)/2). All routers from which responses were received in the first F intervals will be effectively omitted from the estimate of the round-trip probability computed at the Nth interval.
f = f（n）床（（n-1）/2）。最初のf間隔で応答が受信されたすべてのルーターは、n番目の間隔で計算された往復確率の推定から効果的に省略されます。
R(N,F) The total number of RR Result messages, including duplicates, received by the end of the Nth interval from those routers which were NOT heard from in any of the first F intervals.
r（n、f）最初のf間隔のいずれからも聞かれなかったルーターからn番目の間隔の最後までに受信された重複を含むRR結果メッセージの総数。
p(N) The estimate of the worst-case round-trip delivery probability.
p（n）最悪の往復配信確率の推定。
c(N) The computed confidence level.
c（n）計算された信頼レベル。
An asterisk (*) is used to denote multiplication and a caret (^) denotes exponentiation.
アスタリスク（*）は乗算を示すために使用され、caret（^）は指数を示します。
If the difference in reliability between the "good" and "bad" parts of a managed network is very great, early c(N) values will be too high. Retransmissions should continue for at least Nmin = log(1- Ct)/log(1-Pp) intervals, regardless of the current confidence estimate. (In fact, there's no need to compute p(N) and c(N) until after Nmin intervals.)
管理されたネットワークの「良い」部分と「悪い」部分の信頼性の違いが非常に大きい場合、初期のC（n）値が高すぎます。現在の信頼性の見積もりに関係なく、少なくともnmin = log（1- ct）/log（1-pp）間隔で再送信は継続する必要があります。（実際、NMIN間隔の後にP（N）およびC（N）を計算する必要はありません。）
Letting A = N*(M(N)-M(F))/R(N,F) for brevity, the estimate of the
round-trip delivery probability is p(N) = 1-Q, where Q is that root
of the equation
Q^N - A*Q + (A-1) = 0
which lies between 0 and 1. (Q = 1 is always a root. If N is odd there is also a negative root.) This may be solved numerically, for example with Newton's method (see any standard text, for example [ANM]). The first-order approximation
0から1の間にあります（q = 1は常にルートです。nが奇妙な場合は負のルートもあります。）これは、たとえば、ニュートンの方法で数値的に解決される場合があります（標準テキスト、たとえば[ANM]を参照してください。）。一次近似
Q1 = 1 - 1/A
may be used as a starting point for iteration. But Q1 should NOT be used as an approximate solution as it always underestimates Q, and hence overestimates p(N), which would cause an overestimate of the confidence level.
反復の出発点として使用できます。ただし、Q1は常にQを過小評価しているため、近似ソリューションとして使用しないでください。
If necessary, the spurious root Q = 1 can be divided out, leaving
必要に応じて、偽のルートq = 1を分割して、離れることができます
Q^(N-1) + Q^(N-2) + ... + Q - (A-1) = 0
as the equation to solve. Depending on the numerical method used, this could be desirable as it's just possible (but very unlikely) that A=N and so Q=1 was a double root of the earlier equation.
解決する方程式として。使用される数値方法に応じて、これはA = n、Q = 1が以前の方程式の二重根であるということが可能である（ただし非常にありそうもない）ため、望ましい場合があります。
After N > 2 (or N >= Nmin) intervals have been completed, Compute the lower-bound reliability estimate
n> 2（またはn> = nmin）間隔が完了したら、下部の信頼性の推定値を計算します
p(N) = R(N,F)/((N-F)*(M(N) - M(F))).
p（n）= r（n、f）/（（n -f）*（m（n）-m（f）））。
Compute the confidence estimate
信頼性の見積もりを計算します
c(N) = (1 - (1-p(N))^N)^(M(N) - M(F) + 1).
which is the Bayesian probability that M(N) is the number of routers present given the number of responses which were collected, as opposed to M(N)+1 or any greater number. It is assumed that the a priori probability of there being K routers was no greater than that of K-1 routers, for all K > M(N).
これは、m（n）がm（n）1またはより多くの数とは対照的に、収集された応答の数を考慮して存在するルーターの数であるというベイジアンの確率です。Kルーターがあるという先験的な確率は、すべてのk> m（n）に対してk-1ルーターのそれよりも大きくないと想定されています。
When c(N) >= Ct and N >= Nmin, retransmissions of the Command may cease. Otherwise another transmission should be scheduled at a time V*T(N) + MaxDelay after the previous (Nth) transmission, or V*T(N) after the conclusion of processing responses to the Nth transmission, whichever is later.
c（n）> = ctおよびn> = nminの場合、コマンドの再送信が停止する場合があります。それ以外の場合、別の伝送は、以前の（n番目の）伝送後の時刻V*t（n）maxdelay、またはn番目の伝送への応答の処理の終了後のv*t（n）でスケジュールする必要があります。
One corner case needs consideration. Divide-by-zero may occur when computing p. This can happen only when no new routers have been heard from in the last N-F intervals. Generally, the confidence estimate c(N) will be close to unity by then, but in a pathological case such as a large number of routers with reliable communication and a much smaller number with very poor communication, the confidence estimate may still be less than Ct when p's denominator vanishes. The implementation may continue, and should continue if the minimum number of transmissions given in the previous paragraph have not yet been made. If new routers are heard from, p(N) will again be non-singular.
1つのコーナーケースでは検討が必要です。p。これは、最後のn-f間隔で新しいルーターが聞かれていない場合にのみ発生する可能性があります。一般的に、信頼性推定C（n）はそれまでに統一に近づいていますが、信頼できる通信を備えた多数のルーターや、非常に不十分な通信を持つはるかに少ない数字などの病理学的ケースでは、信頼の推定値はまだ少ない場合があります。Pの分母が消滅するとCT。実装は継続される場合があり、前の段落に記載されている最小数の送信がまだ作成されていない場合は継続する必要があります。新しいルーターが聞こえると、p（n）は再びsingularになります。
Of course no limited retransmission scheme can fully address the possibility of long-term problems, such as a partitioned network. The network manager is expected to be aware of such conditions when they exist.
もちろん、分割されたネットワークなど、長期的な問題の可能性に完全に対処できる限定再送信スキームはありません。ネットワークマネージャーは、そのような条件が存在する場合に認識することが期待されています。
As a final means to detect routers which become reachable after missing renumbering commands during an extended network split, a management station MAY adopt the following strategy. When performing each new operation, increment the SequenceNumber by more than one.
拡張ネットワークスプリット中に名前を変更した後に到達可能になったルーターを検出する最終手段として、管理ステーションは次の戦略を採用する場合があります。新しい操作を実行するときは、シーケンセンサーを複数増やします。
After the operation is believed complete, periodically send some "no-op" RR Command with the R (Result Requested) flag set and a SequenceNumber one less than the highest used. Any responses to such a command can only come from router that missed the last operation. An example of a suitable "no-op" command would be an ADD operation with MatchLen = 0, MinLen = 0, MaxLen = 128, and no Use-Prefix Parts.
操作が完了した後、R（結果要求された）フラグセットと、使用されている最高の1つより少ないシーケンセンサーを使用して、定期的に「No-op」RRコマンドを定期的に送信します。そのようなコマンドへの応答は、最後の操作を逃したルーターからのみ届くことができます。適切な「no-op」コマンドの例は、matchlen = 0、minlen = 0、maxlen = 128を使用した追加操作であり、使用なしのパーツです。
If old authentication keys are saved by the management station, even the reappearance of routers which missed a Sequence Number Reset can be detected by the transmission of no-op commands with the invalid key and a SequenceNumber higher than any used before the key was invalidated. Since there is no other way for a management station to distinguish a router's failure to receive an entire sequence of repeated SNR messages from the loss of that router's single SNR Result Message, this is the RECOMMENDED way to test for universal reception of a SNR Command.
古い認証キーが管理ステーションによって保存されている場合、シーケンス番号のリセットを逃したルーターの再登場でさえ、無効なキーとキーが無効になる前の任意よりも高いシーケンセンサーを使用したNO-opコマンドの送信によって検出できます。管理ステーションが、ルーターの単一SNR結果メッセージの損失から繰り返されるSNRメッセージのすべてのシーケンスをルーターの失敗を区別する他の方法がないため、これはSNRコマンドのユニバーサル受信をテストするための推奨される方法です。
This section sketches some sample applications of Router Renumbering. Extension headers, including required IPsec headers, between the IPv6 header and the ICMPv6 header are not shown in the examples.
このセクションでは、ルーターの変更のいくつかのサンプルアプリケーションをスケッチします。IPv6ヘッダーとICMPV6ヘッダーの間に必要なIPSECヘッダーを含む拡張ヘッダーは、例には示されていません。
A simple use of the Router Renumbering mechanism, and one which is expected to to be common, is the maintenance of a set of global prefixes with a subnet structure that matches that of the site's site-local address assignments. In the steady state this would serve to keep the Preferred and Valid lifetimes set to their desired values. During a renumbering transition, similar Command messages can add new prefixes and/or delete old ones. An outline of a suitable Command message follows. Fields not listed are presumed set to suitable values. This Command assumes all router interfaces to be maintained already have site-local [AARCH] addresses.
ルーターの変更メカニズムを簡単に使用し、一般的であると予想されるメカニズムは、サイトのサイトローカルアドレスの割り当てと一致するサブネット構造を備えたグローバルプレフィックスのセットのメンテナンスです。定常状態では、これは好みの寿命を希望する値に設定するのに役立ちます。変更中の移行中、同様のコマンドメッセージは新しいプレフィックスを追加したり、古いプレフィックスを削除したりできます。適切なコマンドメッセージの概要が続きます。リストされていないフィールドは、適切な値に設定されていると推定されます。このコマンドは、維持されるすべてのルーターインターフェイスに既にサイトローカル[AARCH]アドレスがあることを想定しています。
IPv6 Header
Next Header = 58 (ICMPv6)
Source Address = (Management Station)
Destination Address = FF05::2 (All Routers, site-local scope)
ICMPv6/RR Header Type = 138 (Router Renumbering), Code = 0 (Command) Flags = 60 hex (R, A)
ICMPV6/RRヘッダータイプ= 138（ルーターの変更）、code = 0（コマンド）フラグ= 60ヘックス（r、a）
First (and only) PCO:
最初（およびのみ）PCO：
Match-Prefix Part
OpCode = 3 (SET-GLOBAL)
OpLength = 4 N + 3 (assuming N global prefixes)
Ordinal = 0 (arbitrary)
MatchLen = 10
MatchPrefix = FEC0::0
First Use-Prefix Part
UseLen = 48 (Length of TLA ID + RES + NLA ID [AARCH])
KeepLen = 16 (Length of SLA (subnet) ID [AARCH])
FlagMask, RAFlags, Lifetimes, V & P flags -- as desired
UsePrefix = First global /48 prefix
. . .
。。。
Nth Use-Prefix Part UseLen = 48 KeepLen = 16 FlagMask, RAFlags, Lifetimes, V & P flags -- as desired UsePrefix = Last global /48 prefix
nth use-prefix part uselen = 48 keeplen = 16フラグマスク、ラフラグ、寿命、V＆Pフラグ - 目的のようにuseprefix = last global /48 prefix
This will cause N global prefixes to be set (or updated) on each applicable interface. On each interface, the SLA ID (subnet) field of each global prefix will be copied from the existing site-local prefix.
これにより、該当する各インターフェイスでnグローバルプレフィックスが設定（または更新）されます。各インターフェイスでは、各グローバルプレフィックスのSLA ID（サブネット）フィールドが既存のサイトローカルプレフィックスからコピーされます。
A subnet can be gracefully renumbered by setting the valid and preferred timers on the old prefix to a short value and having them run down, while concurrently adding adding the new prefix. Later, the expired prefix is deleted. The first step is described by the following RR Command.
サブネットは、古いプレフィックス上の有効なタイマーと優先タイマーを短い値に設定し、それらを実行することで優雅に変更することができます。同時に新しいプレフィックスを追加します。その後、期限切れのプレフィックスが削除されます。最初のステップは、次のRRコマンドで説明されています。
IPv6 Header
Next Header = 58 (ICMPv6)
Source Address = (Management Station)
Destination Address = FF05::2 (All Routers, site-local scope)
ICMPv6/RR Header Type = 138 (Router Renumbering), Code = 0 (Command) Flags = 60 hex (R, A)
ICMPV6/RRヘッダータイプ= 138（ルーターの変更）、code = 0（コマンド）フラグ= 60ヘックス（r、a）
First (and only) PCO:
最初（およびのみ）PCO：
Match-Prefix Part OpCode = 2 (CHANGE) OpLength = 11 (reflects 2 Use-Prefix Parts) Ordinal = 0 (arbitrary) MatchLen = 64 MatchPrefix = Old /64 prefix
Match-Prefixパーツopcode = 2（change）oplength = 11（反映2の使用-prefixパーツを反映）
First Use-Prefix Part
UseLen = 0
KeepLen = 64 (this retains the old prefix value intact)
FlagMask = 0, RAFlags = 0
Valid Lifetime = 28800 seconds (8 hours)
Preferred Lifetime = 7200 seconds (2 hours)
V flag = 1, P flag = 1
UsePrefix = 0::0
Second Use-Prefix Part UseLen = 64 KeepLen = 0 FlagMask = 0, RAFlags = 0 Lifetimes, V & P flags -- as desired UsePrefix = New /64 prefix
Second use-prefix part uselen = 64 keeplen = 0 flagmask = 0、raflags = 0 lifetimes、v＆p flags-目的のuseprefix = new /64プレフィックス
The second step, deletion of the old prefix, can be done by an RR Command with the same Match-Prefix Part (except for an OpLength reduced from 11 to 3) and no Use-Prefix Parts. Any temptation to set KeepLen = 64 in the second Use-Prefix Part above should be resisted, as it would instruct the router to sidestep address configuration.
2番目のステップである古いプレフィックスの削除は、同じマッチプレフィックスパーツ（11から3に削減されたOplengthを除く）を除くRRコマンドで実行できます。上記の2番目の使用-Prefixパーツにkeeplen = 64を設定する誘惑は、ルーターにサイドステップアドレスの構成を指示するため、抵抗する必要があります。
This protocol was designed by Matt Crawford based on an idea of Robert Hinden and Geert Jan de Groot. Many members of the IPNG Working Group contributed useful comments, in particular members of the DIGITAL UNIX IPv6 team. Bill Sommerfeld provided helpful IPsec expertise. Relentless browbeating by various IESG members may have improved the final quality of this specification.
このプロトコルは、Robert HindenとGeert Jan de Grootのアイデアに基づいてMatt Crawfordによって設計されました。IPNGワーキンググループの多くのメンバーは、特にデジタルUNIX IPv6チームのメンバー、有用なコメントを提供しました。Bill Sommerfeldは、有用なIPSECの専門知識を提供しました。さまざまなIESGメンバーによる容赦ない眉をひそめた場合、この仕様の最終品質が向上した可能性があります。
[AARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[Aarch] Hinden、R。and S. Deering、「IPバージョン6アドレス指定アーキテクチャ」、RFC 2373、1998年7月。
[AH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[AH] Kent、S。およびR. Atkinson、「IP認証ヘッダー」、RFC 2402、1998年11月。
[ANM] Isaacson, E. and H. B. Keller, "Analysis of Numerical Methods", John Wiley & Sons, New York, 1966.
[ANM] Isaacson、E。およびH. B. Keller、「数値的方法の分析」、John Wiley＆Sons、ニューヨーク、1966年。
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[ESP] Kent、S。およびR. Atkinson、「IPカプセル化セキュリティペイロード（ESP）」、RFC 2406、1998年11月。
[IANACON] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[Ianacon] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[ICMPV6] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)", RFC 2463, December 1998.
[ICMPV6] Conta、A。およびS. Deering、「インターネットプロトコルバージョン6（IPv6）のインターネット制御メッセージプロトコル（ICMPV6）」、RFC 2463、1998年12月。
[IPSEC] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[IPSEC] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[IPv6] Deering、S。and R. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[IPV6MIB] Haskin, D. and S. Onishi, "Management Information Base for IP Version 6: Textual Conventions and General Group", RFC 2466, December 1998.
[IPv6mib] Haskin、D。and S. Onishi、「IPバージョン6の管理情報ベース：テキストコンベンションと一般グループ」、RFC 2466、1998年12月。
[KWORD] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[KWORD] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[ND] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[nd] Narten、T.、Nordmark、E。and W. Simpson、「IPバージョン6（IPv6）の近隣発見」、RFC 2461、1998年12月。
[OSPFMIB] Baker, F. and R. Coltun, "OSPF Version 2 Management Information Base", RFC 1850, November 1995.
[Ospfmib] Baker、F。and R. Coltun、「OSPFバージョン2管理情報ベース」、RFC 1850、1995年11月。
Matt Crawford Fermilab MS 368 PO Box 500 Batavia, IL 60510 USA
Matt Crawford Fermilab MS 368 PO Box 500バタビア、イリノイ60510 USA
Phone: +1 630 840 3461
EMail: crawdad@fnal.gov
Appendix -- Derivation of Reliability Estimates
付録 - 信頼性の推定値の導出
If a population S of size k is repeatedly sampled with an efficiency p, the expected number of members of S first discovered on the nth sampling is
サイズkの集団が効率Pで繰り返しサンプリングされている場合、n番目のサンプリングで最初に発見されたSのメンバーの予想数はです
m = [1 - (1-p)^n] * k
The expected total number of members of S found in samples, including duplicates, is
重複を含むサンプルで見つかったSのメンバーの予想総数は、
r = n * p * k
Taking the ratio of m to r cancels the unknown factor k and yields an equation
Mの比率をRとRを取ると、未知の係数kがキャンセルされ、方程式が生成されます
[1 - (1-p)^n] / p = nm/r
which may be solved for p, which is then an estimator of the sampling efficiency. (The statistical properties of the estimator will not be examined here.) Under the substitution p = 1-q, this becomes the first equation of Section 8.2.
これはPのために解決される場合があります。これは、サンプリング効率の推定器です。（ここでは、推定器の統計的特性を検討しません。）置換p = 1-Qでは、これがセクション8.2の最初の方程式になります。
With the estimator p in hand, and a count m of members of S discovered after n samplings, we can compute the a posteriori probability that the true size of S is m+j, for j >= 0. Let Hj denote the hypothesis that the true size of S is m+j, and let R denote the result that m members have been found in n samplings. Then
推定器Pを手にし、nサンプリング後に発見されたSのメンバーのカウントmを使用すると、sの真のサイズがm jであるという事後確率を計算できます。SのサイズはM jであり、rをnサンプリングでMメンバーが見つかった結果を示します。それから
P{R | Hj} = [(m+j)!/m!j!] * [1-(1-p)^n]^m * [(1-p)^n]^j
We are interested in P{H0 | R}, but to find it we need to assign a priori values to P{Hj}. Let the size of S be exponentially distributed
p {h0 |に興味がありますr}、しかしそれを見つけるには、pirryi値をp {hj}に割り当てる必要があります。Sのサイズを指数関数的に分布させます
P{Hj} / P{H0} = h^(-j)
for arbitrary h in (0, 1). The value of h will be eliminated from the result.
任意のhの場合（0、1）。Hの値は結果から排除されます。
The Bayesian method yields
ベイジアン法は生成します
P{Hj | R} / P{H0 | R} = [(m+j)!/m!j!] * [h*(1-p)^n]^j
The reciprocal of the sum over j >= 0 of these ratios is
これらの比率のj> = 0を超える合計の相互はです
P{H0 | R} = [1-h*(1-p)^n] ^ (m+1)
and the confidence estimate of Section 8.2 is the h -> 1 limit of this expression.
セクション8.2の信頼性推定値は、この式のh-> 1の制限です。
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。