Network Working Group J. Arkko
Request for Comments: 5534 Ericsson
Category: Standards Track I. van Beijnum
IMDEA Networks
June 2009
Failure Detection and Locator Pair
Exploration Protocol for IPv6 Multihoming
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) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書（http://trustee.ietf.org/license-info）の発行日に有効なIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Abstract
抽象
This document specifies how the level 3 multihoming Shim6 protocol (Shim6) detects failures between two communicating nodes. It also specifies an exploration protocol for switching to another pair of interfaces and/or addresses between the same nodes if a failure occurs and an operational pair can be found.
この文書では、レベル3マルチホーミングSHIM6プロトコル（SHIM6）は2つの通信ノード間で障害を検出する方法を指定します。また、障害が発生し、動作ペアを見つけることができれば、同じノード間のインタフェース及び/又はアドレスの別のペアに切り替えるための探査プロトコルを指定します。
Table of Contents
目次
1. Introduction ....................................................3
2. Requirements Language ...........................................4
3. Definitions .....................................................4
3.1. Available Addresses ........................................4
3.2. Locally Operational Addresses ..............................5
3.3. Operational Address Pairs ..................................5
3.4. Primary Address Pair .......................................7
3.5. Current Address Pair .......................................7
4. Protocol Overview ...............................................8
4.1. Failure Detection ..........................................8
4.2. Full Reachability Exploration .............................10
4.3. Exploration Order .........................................11
5. Protocol Definition ............................................13
5.1. Keepalive Message .........................................13
5.2. Probe Message .............................................14
5.3. Keepalive Timeout Option Format ...........................18
6. Behavior .......................................................19
6.1. Incoming Payload Packet ...................................20
6.2. Outgoing Payload Packet ...................................21
6.3. Keepalive Timeout .........................................21
6.4. Send Timeout ..............................................22
6.5. Retransmission ............................................22
6.6. Reception of the Keepalive Message ........................22
6.7. Reception of the Probe Message State=Exploring ............23
6.8. Reception of the Probe Message State=InboundOk ............23
6.9. Reception of the Probe Message State=Operational ..........23
6.10. Graphical Representation of the State Machine ............24
7. Protocol Constants and Variables ...............................24
8. Security Considerations ........................................25
9. Operational Considerations .....................................27
10. References ....................................................28
10.1. Normative References .....................................28
10.2. Informative References ...................................29
Appendix A. Example Protocol Runs..................................30
Appendix B. Contributors...........................................35
Appendix C. Acknowledgements.......................................35
The Shim6 protocol [RFC5533] extends IPv6 to support multihoming. It is an IP-layer mechanism that hides multihoming from applications. A part of the Shim6 solution involves detecting when a currently used pair of addresses (or interfaces) between two communication nodes has failed and picking another pair when this occurs. We call the former "failure detection", and the latter, "locator pair exploration".
SHIM6プロトコル[RFC5533]はマルチホーミングをサポートするためのIPv6を拡張します。これは、アプリケーションからのマルチホーミングを隠しIP層のメカニズムです。 SHIM6溶液の一部は、アドレス（又はインタフェース）は、2つの通信ノード間の現在使用されている一対のに失敗した場合に検出し、これが発生したときに別のペアを選ぶことを含みます。私たちは、かつての「障害の検出」、後者、「ロケータペア探索」と呼びます。
This document specifies the mechanisms and protocol messages to achieve both failure detection and locator pair exploration. This part of the Shim6 protocol is called the REAchability Protocol (REAP).
この文書では、障害検出およびロケータペア探索の両方を達成するためのメカニズムとプロトコルメッセージを指定します。 SHIM6プロトコルのこの部分は、到達性プロトコル（REAP）と呼ばれています。
Failure detection is made as lightweight as possible. Payload data traffic in both directions is observed, and in the case where there is no traffic because the communication is idle, failure detection is also idle and doesn't generate any packets. When payload traffic is flowing in both directions, there is no need to send failure detection packets, either. Only when there is traffic in one direction does the failure detection mechanism generate keepalives in the other direction. As a result, whenever there is outgoing traffic and no incoming return traffic or keepalives, there must be failure, at which point the locator pair exploration is performed to find a working address pair for each direction.
障害検出は可能な限り軽量化されます。両方向のペイロード・データ・トラフィックが観察され、通信がアイドル状態であるので、トラフィックがない場合には、故障検出はまた、アイドルであり、任意のパケットを生成しません。ペイロードトラフィックが両方向に流れているときは、いずれか、障害検出パケットを送信する必要はありません。トラフィックが一方向に存在する場合にのみ障害検出メカニズムは、他の方向にキープアライブを生成しません。発信トラフィックなし着信リターントラフィックまたはキープアライブがあるときはいつでもその結果、ロケータペア探索は、各方向のために働いてアドレスペアを見つけるために行われた時点で故障がなければなりません。
This document is structured as follows: Section 3 defines a set of useful terms, Section 4 gives an overview of REAP, and Section 5 provides a detailed definition. Section 6 specifies behavior, and Section 7 discusses protocol constants. Section 8 discusses the security considerations of REAP.
第3節では、有用な用語のセットを定義し、セクション4はREAPの概要を示し、そして第5の詳細な定義を提供する：この文書は、以下のように構成されています。第6節は、動作を指定し、7章では、プロトコル定数について説明します。第8節はREAPのセキュリティ上の考慮事項について説明します。
In this specification, we consider an address to be synonymous with a locator. Other parts of the Shim6 protocol ensure that the different locators used by a node actually belong together. That is, REAP is not responsible for ensuring that said node ends up with a legitimate locator.
この仕様では、アドレスがロケータと同義であると考えています。 SHIM6プロトコルの他の部分は、ノードによって使用される異なるロケータは、実際に一緒に属していることを保証します。つまり、前記ノードを確保するための責任を負いません正当なロケータで終わりREAP。
REAP has been designed to be used with Shim6 and is therefore tailored to an environment where it typically runs on hosts, uses widely varying types of paths, and is unaware of application context. As a result, REAP attempts to be as self-configuring and unobtrusive as possible. In particular, it avoids sending any packets except where absolutely required and employs exponential back-off to avoid congestion. The downside is that it cannot offer the same granularity of detecting problems as mechanisms that have more application context and ability to negotiate or configure parameters.
REAP SHIM6で使用するように設計されており、従って、それは、典型的には、ホスト上で実行パスの広く様々なタイプを使用し、アプリケーション・コンテキストを認識しない環境に合わせて調整されます。結果として、自己構成およびできるだけ目立たないようにすることしようとする試みをREAP。特に、それは絶対に必要な場合を除いて、任意のパケットを送信しませんし、混雑を避けるために、指数バックオフを採用しています。欠点は、より多くのアプリケーションコンテキストと交渉するか、パラメータを設定する機能を持っているのメカニズムなどの問題を検出するのと同じ粒度を提供することができないということです。
Future versions of this specification may consider extensions with such capabilities, for instance, through inheriting some mechanisms from the Bidirectional Forwarding Detection (BFD) protocol [BFD].
この仕様の将来のバージョンでは、双方向フォワーディング検出（BFD）プロトコル[BFD]からいくつかのメカニズムを継承を介して、例えば、そのような機能を備えた拡張を考慮してもよいです。
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 [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
This section defines terms useful for discussing failure detection and locator pair exploration.
このセクションでは、障害検出およびロケータペア探索を議論するために有用な用語を定義します。
Shim6 nodes need to be aware of what addresses they themselves have. If a node loses the address it is currently using for communications, another address must replace it. And if a node loses an address that the node's peer knows about, the peer must be informed. Similarly, when a node acquires a new address it may generally wish the peer to know about it.
SHIM6ノードは、彼ら自身が持っているアドレスをどのように認識する必要があります。ノードが通信用として現在使用しているアドレスを失った場合、別のアドレスは、それを交換する必要があります。ノードは、ノードのピアが知っているアドレスを失った場合や、ピアに通知しなければなりません。ノードが新しいアドレスを取得する場合も同様に、それは一般的に、ピアはそれについて知りたいことがあります。
Definition. Available address - an address is said to be available if all the following conditions are fulfilled:
定義。利用可能なアドレス - 次のすべての条件が満たされた場合にはアドレスが利用可能であると言われています。
o The address has been assigned to an interface of the node.
Oアドレスは、ノードのインタフェースに割り当てられています。
o The valid lifetime of the prefix (Section 4.6.2 of RFC 4861 [RFC4861]) associated with the address has not expired.
oをアドレスに関連付けられたプレフィックス（RFC 4861のセクション4.6.2 [RFC4861]）の有効期間が満了していません。
o The address is not tentative in the sense of RFC 4862 [RFC4862]. In other words, the address assignment is complete so that communications can be started.
Oアドレスは、RFC 4862 [RFC4862]という意味で仮ありません。通信を開始できるように、言い換えれば、アドレスの割り当ては完了です。
Note that this explicitly allows an address to be optimistic in the sense of Optimistic Duplicate Address Detection (DAD) [RFC4429] even though implementations may prefer using other addresses as long as there is an alternative.
これは明示的実装があれば、代替が存在するように、他のアドレスを使用することを好む場合でも、[RFC4429]アドレスが楽観重複アドレス検出（DAD）の意味で楽観的にすることができることに留意されたいです。
o The address is a global unicast or unique local address [RFC4193]. That is, it is not an IPv6 site-local or link-local address.
Oアドレスがグローバルユニキャストまたは一意のローカルアドレス[RFC4193]はです。つまり、IPv6サイトローカルまたはリンクローカルアドレスではありません、です。
With link-local addresses, the nodes would be unable to determine on which link the given address is usable.
リンクローカルアドレスで、ノードは、指定されたアドレスが使用可能であるリンクれているかを決定することができません。
o The address and interface are acceptable for use according to a local policy.
アドレス及びインタフェースoをローカルポリシーに従って使用するのに許容可能です。
Available addresses are discovered and monitored through mechanisms outside the scope of Shim6. Shim6 implementations MUST be able to employ information provided by IPv6 Neighbor Discovery [RFC4861], Address Autoconfiguration [RFC4862], and DHCP [RFC3315] (when DHCP is implemented). This information includes the availability of a new address and status changes of existing addresses (such as when an address becomes invalid).
利用可能なアドレスはSHIM6の範囲外のメカニズムによって発見され、監視されています。 SHIM6実装は、IPv6近隣探索[RFC4861]、アドレス自動[RFC4862]、およびDHCP [RFC3315]（DHCPが実装される）によって提供される情報を使用できなければなりません。この情報は、（アドレスが無効になった場合など）は、既存のアドレスの新しいアドレスとステータスの変更の可用性が含まれています。
Two different granularity levels are needed for failure detection. The coarser granularity is for individual addresses.
二つの異なる粒度レベルが障害検出のために必要とされます。粗い粒度は、個々のアドレスのためです。
Definition. Locally operational address - an available address is said to be locally operational when its use is known to be possible locally. In other words, when the interface is up, a default router (if needed) suitable for this address is known to be reachable, and no other local information points to the address being unusable.
定義。ローカル運用アドレス - 使用可能なアドレスは、その使用が局部的に可能であることが知られているとき、ローカルに動作可能と言われています。インターフェイスがアップしているときに、他の言葉で、このアドレスに適したデフォルトのルータは（必要な場合）到達可能であることが知られていない、および使用不可能であるアドレスへの他のローカル情報ポイント。
Locally operational addresses are discovered and monitored through mechanisms outside the Shim6 protocol. Shim6 implementations MUST be able to employ information provided from Neighbor Unreachability Detection [RFC4861]. Implementations MAY also employ additional, link-layer-specific mechanisms.
ローカル運用のアドレスはSHIM6プロトコル外のメカニズムによって発見され、監視されています。 SHIM6実装は、近隣到達不能検出[RFC4861]から提供された情報を使用できなければなりません。また、実装は、追加、リンク層固有のメカニズムを使用することができます。
Note 1: A part of the problem in ensuring that an address is operational is making sure that after a change in link-layer connectivity, we are still connected to the same IP subnet. Mechanisms such as [DNA-SIM] can be used to ensure this.
注1：アドレスが動作可能であることを確保する上で問題の一部は、リンク層の接続性が変化した後、我々はまだ同じIPサブネットに接続されていることを確認しています。このような[DNA-SIM]のようなメカニズムはこれを確実にするために使用することができます。
Note 2: In theory, it would also be possible for nodes to learn about routing failures for a particular selected source prefix, if only suitable protocols for this purpose existed. Some proposals in this space have been made (see, for instance [ADD-SEL] and [MULTI6]), but none have been standardized to date.
注2：ノードは、特定の選択したソースのプレフィックスのルーティング障害について学ぶために、この目的のためにのみ適切なプロトコルが存在していれば理論的には、それはまた、可能です。この空間でのいくつかの提案は、（例えば、参照[-SELの追加]および[MULTI6]）行われているが、どれもこれまでに標準化されていません。
The existence of locally operational addresses are not, however, a guarantee that communications can be established with the peer. A failure in the routing infrastructure can prevent packets from reaching their destination. For this reason, we need the definition of a second level of granularity, which is used for pairs of addresses.
ローカル運用のアドレスの存在は、しかし、通信がピアと確立することができます保証するものではありません。ルーティングインフラストラクチャの障害は、その宛先に到達するパケットを防止することができます。このような理由から、我々はアドレスのペアのために使用されている粒度の第二のレベルの定義が必要です。
Definition. Bidirectionally operational address pair - a pair of locally operational addresses are said to be an operational address pair when bidirectional connectivity can be shown between the addresses. That is, a packet sent with one of the addresses in the Source field and the other in the Destination field reaches the destination, and vice versa.
定義。双方向動作アドレス対 - 局所演算アドレスの対は、双方向接続がアドレス間で示すことができる場合、動作アドレスペアであると言われています。つまり、ソースフィールド内のアドレスのいずれかで送信されたパケットであると、他の目的地でのフィールドには、目的地に到達し、そしてその逆。
Unfortunately, there are scenarios where bidirectionally operational address pairs do not exist. For instance, ingress filtering or network failures may result in one address pair being operational in one direction while another one is operational from the other direction. The following definition captures this general situation.
残念ながら、双方向操作アドレスのペアが存在しないシナリオがあります。もう一つは、他の方向から動作している間、例えば、イングレスフィルタリングまたはネットワーク障害が一つのアドレス・ペアが一方向に動作さをもたらすことができます。以下の定義は、この一般的な状況をキャプチャします。
Definition. Unidirectionally operational address pair - a pair of locally operational addresses are said to be a unidirectionally operational address pair when packets sent with the first address as the source and the second address as the destination reach the destination.
定義。一方向動作アドレス対 - 局所演算アドレスのペアは、パケットが送信元と宛先に到達先として第2のアドレスとして第1のアドレスに送信された一方向動作アドレスのペアであると言われています。
Shim6 implementations MUST support the discovery of operational address pairs through the use of explicit reachability tests and Forced Bidirectional Communication (FBD), described later in this specification. Future extensions of Shim6 may specify additional mechanisms. Some ideas of such mechanisms are listed below but are not fully specified in this document:
SHIM6実装は、この仕様書で後述する明示的な到達可能性テストや強制双方向通信（FBD）の使用を介して演算アドレスペアの発見を、サポートしなければなりません。 SHIM6の将来の拡張機能は、追加のメカニズムを指定することもできます。そのようなメカニズムのいくつかのアイデアを以下に示しますが、完全にこの文書で指定されていません。
o Positive feedback from upper-layer protocols. For instance, TCP can indicate to the IP layer that it is making progress. This is similar to how IPv6 Neighbor Unreachability Detection can, in some cases, be avoided when upper layers provide information about bidirectional connectivity [RFC4861].
上位層プロトコルからO正のフィードバック。たとえば、TCPは、それが進展していることをIP層に示すことができます。これは、上層は、双方向接続性[RFC4861]に関する情報を提供するときにIPv6近隣到達不能検出は、いくつかの場合には、回避することができる方法に類似しています。
In the case of unidirectional connectivity, the upper-layer protocol responses come back using another address pair, but show that the messages sent using the first address pair have been received.
一方向接続の場合には、上位層プロトコルの応答は、別のアドレス・ペアを使用して戻ってくるが、第1のアドレスのペアを使用して送信されたメッセージを受信したことを示しています。
o Negative feedback from upper-layer protocols. It is conceivable that upper-layer protocols give an indication of a problem to the multihoming layer. For instance, TCP could indicate that there's either congestion or lack of connectivity in the path because it is not getting ACKs.
上位層プロトコルからO負帰還。また、上位層プロトコルがマルチホーミング層に問題の指示を与えることが考えられます。たとえば、TCPは、ACKを取得されていないため、輻輳やパスにおける接続性の欠如のいずれかがあることを示している可能性があり。
o ICMP error messages. Given the ease of spoofing ICMP messages, one should be careful not to trust these blindly, however. One approach would be to use ICMP error messages only as a hint to perform an explicit reachability test or to move an address pair to a lower place in the list of address pairs to be probed, but not to use these messages as a reason to disrupt ongoing communications without other indications of problems. The situation may be different when certain verifications of the ICMP messages are being performed, as explained by Gont in [GONT]. These verifications can ensure that (practically) only on-path attackers can spoof the messages.
ICMPエラーメッセージO。なりすましICMPメッセージのしやすさを考えると、一つはしかし、やみくもにこれらを信用しないように注意する必要があります。一つのアプローチは、明示的な到達可能性テストを実行するか、精査されるアドレスのペアのリストの下位の場所にアドレスのペアを移動するためのヒントとしてICMPエラーメッセージを使用することですが、破壊する理由として、これらのメッセージを使用しません問題の他の徴候のない進行中の通信。 【GONT]でGontによって説明されるようにICMPメッセージの特定の検証が行われているときに状況が異なっていてもよいです。これらの検証は（事実上）のみで、パス攻撃者がメッセージを偽装できるようにすることができます。
The primary address pair consists of the addresses that upper-layer protocols use in their interaction with the Shim6 layer. Use of the primary address pair means that the communication is compatible with regular non-Shim6 communication and that no context tag needs to be present.
プライマリアドレスペアは、上位層プロトコルがSHIM6層との相互作用に使用するアドレスで構成されています。プライマリアドレス対の使用は、通信は、通常の非SHIM6通信におよびNOコンテキストタグが存在する必要がないこと互換性があることを意味します。
Shim6 needs to avoid sending packets that belong to the same transport connection concurrently over multiple paths. This is because congestion control in commonly used transport protocols is based upon a notion of a single path. While routing can introduce path changes as well and transport protocols have means to deal with this, frequent changes will cause problems. Effective congestion control over multiple paths is considered a research topic at the time of publication of this document. Shim6 does not attempt to employ multiple paths simultaneously.
SHIM6は、複数の経路を介して同時に同じトランスポート接続に属するパケットを送るのを避ける必要があります。一般的に使用されるトランスポートプロトコルにおける輻輳制御は、単一パスの概念に基づいているためです。パスを導入することができ、ルーティングするだけでなく変化し、トランスポートプロトコルは、これに対処するための手段を持っているが、頻繁に変更は、問題が発生します。複数のパスにわたって有効輻輳制御は、このドキュメントの発行時点での研究テーマと考えられています。 SHIM6は、同時に複数のパスを利用しようとしません。
Note: The Stream Control Transmission Protocol (SCTP) and future multipath transport protocols are likely to require interaction with Shim6, at least to ensure that they do not employ Shim6 unexpectedly.
注意：ストリーム制御伝送プロトコル（SCTP）と将来のマルチパストランスポートプロトコルは、少なくとも、彼らが予期せずSHIM6を使用しないことを確実にするために、SHIM6との相互作用を必要とする可能性があります。
For these reasons, it is necessary to choose a particular pair of addresses as the current address pair that will be used until problems occur, at least for the same session.
これらの理由から、問題が発生するまで、少なくとも同じセッションのために、使用される現在のアドレスペアとしてアドレスの特定の組を選択する必要があります。
It is theoretically possible to support multiple current address pairs for different transport sessions or Shim6 contexts. However, this is not supported in this version of the Shim6 protocol.
異なるトランスポートセッションまたはSHIM6コンテキストに対して複数の現在のアドレスのペアをサポートするために、理論的には可能です。しかし、これはSHIM6プロトコルのこのバージョンでサポートされていません。
A current address pair need not be operational at all times. If there is no traffic to send, we may not know if the current address pair is operational. Nevertheless, it makes sense to assume that the address pair that worked previously continues to be operational for new communications as well.
現在のアドレスのペアは常時稼動である必要はありません。送信するトラフィックがない場合は、現在のアドレスのペアが動作している場合、我々は知らないかもしれません。それにもかかわらず、それは以前に働いていたアドレスのペアは、同様に新しい通信のために運用を続けていると仮定することは理にかなって。
This section discusses the design of the reachability detection and full reachability exploration mechanisms, and gives an overview of the REAP protocol.
このセクションでは、到達可能性検出及び完全到達可能探査機構の設計について説明し、REAPプロトコルの概要を示します。
Exploring the full set of communication options between two nodes that both have two or more addresses is an expensive operation as the number of combinations to be explored increases very quickly with the number of addresses. For instance, with two addresses on both sides, there are four possible address pairs. Since we can't assume that reachability in one direction automatically means reachability for the complement pair in the other direction, the total number of two-way combinations is eight. (Combinations = nA * nB * 2.)
組み合わせの数は、アドレスの数と非常に迅速に増加を探求するように、両方の二つ以上のアドレスを持つ2つのノード間の通信オプションの完全なセットを探索することは高価な操作です。例えば、両側に二つのアドレスと、四つの可能なアドレスのペアがあります。我々は一つの方向にその到達可能性を想定することができないので、自動的に他の方向における補体対の到達可能性を意味し、双方向の組み合わせの総数は8です。 （組み合わせNA = * nBと* 2）
An important observation in multihoming is that failures are relatively infrequent, so an operational pair that worked a few seconds ago is very likely to still be operational. Thus, it makes sense to have a lightweight protocol that confirms existing reachability, and to only invoke heavier exploration mechanism when there is a suspected failure.
マルチホーミングにおける重要な観察は、障害は比較的まれであるということですので、数秒前に働いていた運用ペアはまだ動作可能性が高いです。したがって、それは既存の到達性を確認した軽量プロトコルを持っている、と疑われる障害が発生した場合にのみ重い探査メカニズムを起動するために理にかなっています。
Failure detection consists of three parts: tracking local information, tracking remote peer status, and finally verifying reachability. Tracking local information consists of using, for instance, reachability information about the local router as an input. Nodes SHOULD employ techniques listed in Sections 3.1 and 3.2 to track the local situation. It is also necessary to track remote address information from the peer. For instance, if the peer's address in the current address pair is no longer locally operational, a mechanism to relay that information is needed. The Update Request message in the Shim6 protocol is used for this purpose [RFC5533]. Finally, when the local and remote information indicates that communication should be possible and there are upper-layer packets to be sent, reachability verification is necessary to ensure that the peers actually have an operational address pair.
障害検出は、3つの部分から構成されています、地元の情報を追跡し、リモートピアのステータスを追跡し、そして最終的に到達可能性を検証します。ローカルな情報を追跡することは、入力として、ローカルルータについて、例えば、到達可能性情報を使用することからなります。ノードは、地元の状況を追跡するために、セクション3.1および3.2に記載されている技術を採用すべきです。ピアからリモートアドレス情報を追跡することも必要です。例えば、現在のアドレスのペアであればピアのアドレスは、もはや情報が必要であることを中継する仕組みローカルで動作していません。 SHIM6プロトコルにおける更新要求メッセージは、この目的の[RFC5533]のために使用されます。ローカルおよびリモートの情報通信が可能でなければならないことを示し、送信されるべき上位層パケットがある場合、最終的に、到達可能性の検証は、ピアが実際に運用アドレスのペアを持っていることを確認する必要があります。
A technique called Forced Bidirectional Detection (FBD) is employed for the reachability verification. Reachability for the currently used address pair in a Shim6 context is determined by making sure that whenever there is payload traffic in one direction, there is also traffic in the other direction. This can be data traffic as well, or it may be transport-layer acknowledgments or a REAP reachability keepalive if there is no other traffic. This way, it is no longer possible to have traffic in only one direction; so whenever there is payload traffic going out, but there are no return packets, there must be a failure, and the full exploration mechanism is started.
強制双方向検出（FBD）と呼ばれる技術は、到達可能性の検証のために使用されます。 SHIM6コンテキストで現在使用されるアドレスのペアの到達可能性は、ペイロードトラフィックが一方向にあるときはいつでも、トラフィックは他の方向にも存在することを確認することによって決定されます。これは、同様にデータトラフィックとすることができる、または他のトラフィックがない場合には、トランスポート層肯定応答又はREAP到達可能キープアライブであってもよいです。このように、一方向にのみトラフィックを持ってすることはできなくなりました。外出ペイロードトラフィックがありますが、ノーリターンパケットが存在しないので、いつでも、そこ故障でなければならない、との完全な探査メカニズムが開始されます。
A more detailed description of the current pair-reachability evaluation mechanism:
電流対到達可能性評価メカニズムのより詳細な説明：
1. To prevent the other side from concluding that there is a reachability failure, it's necessary for a node implementing the failure-detection mechanism to generate periodic keepalives when there is no other traffic.
1.到達性障害があると結論からもう一方の側を防止するために、それは他のトラフィックがない場合、周期的キープアライブを生成する障害検出メカニズムを実装するノードに必要です。
FBD works by generating REAP keepalives if the node is receiving
packets from its peer but not sending any of its own. The
keepalives are sent at certain intervals so that the other side
knows there is a reachability problem when it doesn't receive any
incoming packets for the duration of a Send Timeout period. The
node communicates its Send Timeout value to the peer as a
Keepalive Timeout Option (Section 5.3) in the I2, I2bis, R2, or
UPDATE messages. The peer then maps this value to its Keepalive
Timeout value.
The interval after which keepalives are sent is named the Keepalive Interval. The RECOMMENDED approach for the Keepalive Interval is to send keepalives at one-half to one-third of the Keepalive Timeout interval, so that multiple keepalives are generated and have time to reach the peer before it times out.
キープアライブが送信されるまでのインターバルは、キープアライブインターバルの名前が付けられています。キープアライブインターバルのための推奨されるアプローチは、複数のキープアライブが生成されるように、キープアライブタイムアウト間隔の1/3に半分にキープアライブを送信し、その前にタイムアウトするピアに到達する時間を持つことです。
2. Whenever outgoing payload packets are generated, a timer is started to reflect the requirement that the peer should generate return traffic from payload packets. The timeout value is set to the value of Send Timeout.
送信ペイロードパケットが生成されるたびに2、タイマーはピアがペイロードパケットからのリターントラフィックを生成する必要があります要件を反映するために開始されました。タイムアウト値は、送信タイムアウトの値に設定されています。
For the purposes of this specification, "payload packet" refers
to any packet that is part of a Shim6 context, including both
upper-layer protocol packets and Shim6 protocol messages, except
those defined in this specification. For the latter messages,
Section 6 specifies what happens to the timers when a message is
transmitted or received.
3. Whenever incoming payload packets are received, the timer associated with the return traffic from the peer is stopped, and another timer is started to reflect the requirement for this node to generate return traffic. This timeout value is set to the value of Keepalive Timeout.
着信ペイロードパケットが受信されるたびに3は、ピアからの戻りトラフィックに関連付けられたタイマを停止し、別のタイマがリターントラフィックを生成するために、このノードのための要件を反映するために開始されます。このタイムアウト値は、キープアライブタイムアウトの値に設定されています。
These two timers are mutually exclusive. In other words, either
the node is expecting to see traffic from the peer based on the
traffic that the node sent earlier or the node is expecting to
respond to the peer based on the traffic that the peer sent
earlier (otherwise, the node is in an idle state).
4. The reception of a REAP Keepalive message leads to stopping the timer associated with the return traffic from the peer.
4. REAPキープアライブメッセージの受信は、ピアからのリターントラフィックに関連したタイマを停止につながります。
5. Keepalive Interval seconds after the last payload packet has been received for a context, if no other packet has been sent within this context since the payload packet has been received, a REAP Keepalive message is generated for the context in question and transmitted to the peer. A node may send the keepalive sooner than Keepalive Interval seconds if implementation considerations warrant this, but should take care to avoid sending keepalives at an excessive rate. REAP Keepalive messages SHOULD continue to be sent at the Keepalive Interval until either a payload packet in the Shim6 context has been received from the peer or the Keepalive Timeout expires. Keepalives are not sent at all if one or more payload packets were sent within the Keepalive Interval.
他のパケットは、ペイロードパケットが受信されているので、この文脈の中で送信されていない場合は、最後のペイロード・パケットの後に5キープアライブ間隔秒、コンテキストのために受信された、キープアライブメッセージは、問題のコンテキストの生成とに伝達されるREAPピア。ノードは、実装上の考慮事項は、これを保証する場合はキープアライブ間隔秒よりも早くキープアライブを送ることができますが、過度な速度でキープアライブを送信しないように注意する必要があります。 REAPキープアライブメッセージはSHIM6コンテキストのペイロードパケットのいずれかがピアから受信されたか、またはキープアライブタイムアウトが満了するまで、キープアライブ間隔で送信することを継続すべきです。キープアライブは、一つ以上のペイロードパケットがキープアライブ間隔内に送信されたすべての場合では送信されません。
6. Send Timeout seconds after the transmission of a payload packet with no return traffic on this context, a full reachability exploration is started.
6.この文脈上ノーリターントラフィックがペイロードパケットの送信後にタイムアウト秒を送信し、完全な到達可能性探査が開始されます。
Section 7 provides some suggested defaults for these timeout values. The actual value SHOULD be randomized in order to prevent synchronization. Experience from the deployment of the Shim6 protocol is needed in order to determine what values are most suitable.
第7節は、これらのタイムアウト値のためのいくつかの提案のデフォルトを提供します。実際の値は、同期化を防止するために、ランダム化されてください。 SHIM6プロトコルの展開から、経験が最も適しているものを値を決定するために必要とされています。
As explained in previous sections, the currently used address pair may become invalid, either through one of the addresses becoming unavailable or nonoperational or through the pair itself being declared nonoperational. An exploration process attempts to find another operational pair so that communications can resume.
前のセクションで説明したように、現在使用されているアドレスのペアのいずれか使用できないか、動作不能またはそれ自体が動作不能と宣言されて対を介してなってアドレスの1つを介して、無効になることができます。探査プロセスは、通信が再開できるように、別の動作のペアを見つけようとします。
What makes this process hard is the requirement to support unidirectionally operational address pairs. It is insufficient to probe address pairs by a simple request-response protocol. Instead, the party that first detects the problem starts a process where it tries each of the different address pairs in turn by sending a message to its peer. These messages carry information about the state of connectivity between the peers, such as whether the sender has seen any traffic from the peer recently. When the peer receives a message that indicates a problem, it assists the process by starting its own parallel exploration to the other direction, again sending information about the recently received payload traffic or signaling messages.
何このプロセスは、ハードせるものは一方向操作アドレスのペアをサポートするための必要条件です。単純な要求 - 応答プロトコルによってアドレスのペアを調べるためには不十分です。代わりに、最初の問題を検出する当事者は、そのピアにメッセージを送信することによって、順番に異なるアドレスのペアのそれぞれを試みるプロセスを開始します。これらのメッセージは、送信者が最近、ピアからのすべてのトラフィックを見ているかどうかなど、ピア間の接続の状態に関する情報を運びます。ピアは、問題を示すメッセージを受信すると、それは再び、最近受信したペイロードトラフィックに関する情報を送信したり、シグナリングメッセージを、他の方向への独自の並列探索を開始することによって、プロセスを支援します。
Specifically, when A decides that it needs to explore for an alternative address pair to B, it will initiate a set of Probe messages, in sequence, until it gets a Probe message from B indicating that (a) B has received one of A's messages and, obviously, (b) that B's Probe message gets back to A. B uses the same algorithm, but starts the process from the reception of the first Probe message from A.
Aは、それがBに代替アドレスペアに対して探索する必要があると判断した場合、それは（a）のBはAのメッセージのいずれかを受信したことを示すBからプローブメッセージを取得するまで、具体的には、配列では、プローブ・メッセージのセットを開始しますそして、明らかに、（b）はBのProbeメッセージは、バックA. Bに同じアルゴリズムを使用するが、Aから最初のProbeメッセージを受信してから処理を開始されることを
Upon changing to a new address pair, the network path traversed most likely has changed, so the upper-layer protocol (ULP), SHOULD be informed. This can be a signal for the ULP to adapt, due to the change in path, so that for example, if the ULP is TCP, it could initiate a slow start procedure. However, it's likely that the circumstances that led to the selection of a new path already caused enough packet loss to trigger slow start.
新しいアドレス対に変化すると、最も可能性の高い横断ネットワークパスが変更されているので、上位層プロトコル（ULP）は、知らされるべきです。これは、ULPがTCPである場合、たとえば、それはスロースタート手順を開始することができるようにULPは、パスの変化による適応するための信号であってもよいです。しかし、それは新しいパスの選択につながった状況がすでにスロースタートをトリガするために十分なパケット損失を引き起こしている可能性があります。
REAP is designed to support failure recovery even in the case of having only unidirectionally operational address pairs. However, due to security concerns discussed in Section 8, the exploration process can typically be run only for a session that has already been established. Specifically, while REAP would in theory be capable of exploration even during connection establishment, its use within the Shim6 protocol does not allow this.
でも、一方向にのみ操作アドレスのペアを有する場合には、障害回復をサポートするように設計されてREAP。しかし、第8節で述べたセキュリティ上の懸念に、探査プロセスは、通常、すでに確立されたセッションのために実行することができます。理論的にも接続確立中に探査することができるであろうREAPしながら具体的には、SHIM6プロトコル内のその使用はこれを許可しません。
The exploration process assumes an ability to choose address pairs for testing. An overview of the choosing process used by REAP is as follows:
探査プロセスは、テスト用のアドレスのペアを選択する能力を前提としています。次のようREAPによって使用される選択プロセスの概要は以下のとおりです。
o As an input to start the process, the node has knowledge of its own addresses and has been told via Shim6 protocol messages what the addresses of the peer are. A list of possible pairs of addresses can be constructed by combining the two pieces of information.
プロセスを開始するための入力としてO、ノードは、それ自身のアドレスを知っているピアのアドレスが何であるかSHIM6・プロトコル・メッセージを介して言われています。アドレスの可能な対のリストは、2つの情報を組み合わせることによって構築することができます。
o By employing standard IPv6 address selection rules, the list is pruned by removing combinations that are inappropriate, such as attempting to use a link-local address when contacting a peer that uses a global unicast address.
O標準のIPv6アドレス選択規則を採用することにより、リストは、グローバルユニキャストアドレスを使用してピアを接触させるときに、リンクローカルアドレスを使用しようとして、不適切な組み合わせを除去することによってプルーニングされます。
o Similarly, standard IPv6 address selection rules provide a basic priority order for the pairs.
O同様に、標準のIPv6アドレス選択ルールは、ペアのための基本的な優先順位を与えます。
o Local preferences may be applied for some additional tuning of the order in the list. The mechanisms for local preference settings are not specified but can involve, for instance, configuration that sets the preference for using one interface over another.
Oローカル設定は、リスト内の順序のいくつかの追加調整のためにも適用することができます。ローカル環境設定のためのメカニズムが指定されず、例えば、別の上に一つのインタフェースを使用するためのプリファレンスを設定する設定を含むことができます。
o As a result, the node has a prioritized list of address pairs to try. However, the list may still be long, as there may be a combinatorial explosion when there are many addresses on both sides. REAP employs these pairs sequentially, however, and uses a back-off procedure to avoid a "signaling storm". This ensures that the exploration process is relatively conservative or "safe". The tradeoff is that finding a working path may take time if there are many addresses on both sides.
その結果、O、ノードがしようとするアドレスのペアの優先順位リストを持っています。両サイドに多くのアドレスがある組み合わせ爆発があるかもしれないしかし、リストはまだ、長いかもしれません。 REAPしかし、順次これらのペアを使用し、「シグナリングストーム」を回避するために、バックオフ手順を使用します。これは、探査プロセスは比較的保守や「安全」であることを保証します。トレードオフは、両側の多くのアドレスがある場合、作業パスを見つけるには時間がかかるかもしれないということです。
In more detail, the process is as follows. Nodes first consult the RFC 3484 default address selection rules [RFC3484] to determine what combinations of addresses are allowed from a local point of view, as this reduces the search space. RFC 3484 also provides a priority ordering among different address pairs, possibly making the search faster. (Additional mechanisms may be defined in the future for arriving at an initial ordering of address pairs before testing starts [PAIR].) Nodes may also use local information, such as known quality of service parameters or interface types, to determine what addresses are preferred over others, and try pairs containing such addresses first. The Shim6 protocol also carries preference information in its messages.
より詳細には、プロセスは以下の通りです。これは探索空間を減らすようノードはまず、ビューのローカルポイントから許可されているアドレスの組み合わせを決定するためにRFC 3484のデフォルトのアドレス選択規則[RFC3484]を参照してください。 RFC 3484はまた、おそらくより高速な検索を行うこと、異なるアドレスのペア間の優先順位付けを提供します。 （追加のメカニズムが[PAIR]開始をテストする前にアドレスのペアの最初の順序で到着するため、将来的に定義されてもよい。）ノードもアドレスが好ましいかを決定するために、そのようなサービスパラメータまたはインターフェイスタイプの既知の品質として、ローカル情報を使用することができます他の人の上に、そして最初のそのようなアドレスを含むペアを試してみてください。 SHIM6プロトコルは、そのメッセージ内の嗜好情報を運びます。
Out of the set of possible candidate address pairs, nodes SHOULD attempt to test through all of them until an operational pair is found, and retry the process as necessary. However, all nodes MUST perform this process sequentially and with exponential back-off. This sequential process is necessary in order to avoid a "signaling storm" when an outage occurs (particularly for a complete site). However, it also limits the number of addresses that can, in practice, be used for multihoming, considering that transport- and application-layer protocols will fail if the switch to a new address pair takes too long.
可能な候補アドレスのペアのセットのうち、ノードが動作ペアが発見されるまで、それらのすべてをテストすることを試みるべきであり、必要に応じてプロセスを再試行します。しかしながら、すべてのノードが順次指数バックオフを用いてこのプロセスを実行する必要があります。この一連の処理は、停止が（特に、完全なサイトの）が発生した場合、「シグナリングストーム」を回避するために必要です。しかし、それはまた、実際には、新しいアドレスのペアへのスイッチは時間がかかりすぎるtransport-とアプリケーション層のプロトコルが失敗することを考慮すると、マルチホーミングのために使用することができるアドレスの数を制限します。
Section 7 suggests default values for the timers associated with the exploration process. The value Initial Probe Timeout (0.5 seconds) specifies the interval between initial attempts to send probes; the Number of Initial Probes (4) specifies how many initial probes can be sent before the exponential back-off procedure needs to be employed. This process increases the time between every probe if there is no response. Typically, each increase doubles the time, but this specification does not mandate a particular increase.
第7節は、探査プロセスに関連付けられたタイマーのデフォルト値を示唆しています。値初期プローブタイムアウト（0.5秒）プローブを送信する最初の試行間隔を指定します。 （4）初期プローブの数は指数バックオフ手続きの前に送ら採用する必要がありますすることができますどのように多くの初期のプローブを指定します。応答がない場合は、このプロセスは、すべてのプローブ間の時間を増加します。一般的に、それぞれ増加が時間を倍増が、この仕様では、特定の増加を強制しません。
Note: The rationale for sending four packets at a fixed rate before the exponential back-off is employed is to avoid having to send these packets excessively fast. Without this, having 0.5 seconds between the third and fourth probe means that the time between the first and second probe would have to be 0.125 seconds, which gives very little time for a reply to the first packet to arrive. Also, this means that the first four packets are sent within 0.875 seconds rather than 2 seconds, increasing the potential for congestion if a large number of Shim6 contexts need to send probes at the same time after a failure.
注意：指数バックオフが使用される前に、一定の割合で4つのパケットを送信するための理論的根拠は、過度に速く、これらのパケットを送信することを避けるためです。このことなく、第三および第四のプローブの間に0.5秒を有する第一および第二のプローブとの間の時間が第1のパケットに応答が到着するのを非常に少ない時間を与える0.125秒でなければならないことを意味します。また、これは最初の4つのパケットがSHIM6コンテキストの多くは失敗した後、同時にプローブを送信する必要がある場合、輻輳の可能性を高め、0.875秒ではなく、2秒以内に送信されることを意味します。
Finally, Max Probe Timeout (60 seconds) specifies a limit beyond which the probe interval may not grow. If the exploration process reaches this interval, it will continue sending at this rate until a suitable response is triggered or the Shim6 context is garbage collected, because upper-layer protocols using the Shim6 context in question are no longer attempting to send packets. Reaching the Max Probe Timeout may also serve as a hint to the garbage collection process that the context is no longer usable.
最後に、マックス・プローブタイムアウト（60秒）は、プローブ間隔が成長しないことがあり、それを超える制限を指定します。探査プロセスは、この間隔に達した場合、適切な応答がトリガされるまで、それはこのレートで送信し続けるか疑問にSHIM6コンテキストを使用して上位層プロトコルは、もはやパケットを送信しようとしているので、SHIM6コンテキストは、ガベージコレクションではありません。マックスプローブタイムアウトに達することもコンテキストが使用できなくなっているガベージコレクションプロセスへのヒントとして機能することができます。
The format of the Keepalive message is as follows:
次のようにキープアライブメッセージの形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len |0| Type = 66 | Reserved1 |0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum |R| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Receiver Context Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Options +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header, Hdr Ext Len, 0, 0, Checksum These are as specified in Section 5.3 of the Shim6 protocol description [RFC5533].
次ヘッダ、HDR拡張レン、0、0、チェックサムは、これらのようにSHIM6プロトコル記述[RFC5533]のセクション5.3で指定されています。
Type This field identifies the Keepalive message and MUST be set to 66 (Keepalive).
このフィールドに入力キープアライブメッセージを識別し、66（キープアライブ）に設定しなければなりません。
Reserved1 This is a 7-bit field reserved for future use. It is set to zero on transmit and MUST be ignored on receipt.
Reserved1これは、今後の使用のために予約7ビットのフィールドです。これは、送信時にゼロに設定されて、領収書の上で無視しなければなりません。
R This is a 1-bit field reserved for future use. It is set to zero on transmit and MUST be ignored on receipt.
Rこれは、将来の使用のために予約1ビットのフィールドです。これは、送信時にゼロに設定されて、領収書の上で無視しなければなりません。
Receiver Context Tag This is a 47-bit field for the context tag that the receiver has allocated for the context.
レシーバコンテキストタグこれは、受信機は、コンテキストに割り当てられたコンテキストタグの47ビットのフィールドです。
Reserved2 This is a 32-bit field reserved for future use. It is set to zero on transmit and MUST be ignored on receipt.
Reserved2これは、将来の使用のために予約さ32ビットのフィールドです。これは、送信時にゼロに設定されて、領収書の上で無視しなければなりません。
Options This field MAY contain one or more Shim6 options. However, there are currently no defined options that are useful in a Keepalive message. The Options field is provided only for future extensibility reasons.
オプションこのフィールドには、一つ以上のSHIM6オプションを含むかもしれません。ただし、キープアライブメッセージに有用である何定義されたオプションは、現在存在しません。オプションフィールドは、将来の拡張の理由のために提供されます。
A valid message conforms to the format above, has a Receiver Context Tag that matches the context known by the receiver, is a valid Shim6 control message as defined in Section 12.3 of the Shim6 protocol description [RFC5533], and has a Shim6 context that is in state ESTABLISHED. The receiver processes a valid message by inspecting its options and executing any actions specified for such options.
有効なメッセージは、上記のフォーマットに準拠し、受信機によって知られている文脈に一致SHIM6プロトコル記述[RFC5533]のセクション12.3で定義されるように有効SHIM6制御メッセージであり、あるSHIM6コンテキストを有するレシーバコンテキストタグを持ちます状態で設立。受信機は、そのオプションを検査し、そのようなオプションに指定されたアクションを実行することにより、有効なメッセージを処理します。
The processing rules for this message are given in more detail in Section 6.
このメッセージの処理規則はセクション6でより詳細に示されています。
This message performs REAP exploration. Its format is as follows:
このメッセージは、探索をREAP行います。形式は以下の通りです：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len |0| Type = 67 | Reserved |0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum |R| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Receiver Context Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Precvd| Psent |Sta| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ First probe sent +
| |
+ Source address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ First probe sent +
| |
+ Destination address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| First Probe Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| First Probe Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
/ Nth probe sent /
| |
+ Source address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Nth probe sent +
| |
+ Destination address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nth Probe Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nth Probe Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ First probe received +
| |
+ Source address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ First probe received +
| |
+ Destination address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| First Probe Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| First Probe Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Nth probe received +
| |
+ Source address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Nth probe received +
| |
+ Destination address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nth Probe Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nth Probe Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Options //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header, Hdr Ext Len, 0, 0, Checksum These are as specified in Section 5.3 of the Shim6 protocol description [RFC5533].
次ヘッダ、HDR拡張レン、0、0、チェックサムは、これらのようにSHIM6プロトコル記述[RFC5533]のセクション5.3で指定されています。
Type This field identifies the Probe message and MUST be set to 67 (Probe).
このフィールドに入力Probeメッセージを識別し、67（プローブ）に設定しなければなりません。
Reserved This is a 7-bit field reserved for future use. It is set to zero on transmit and MUST be ignored on receipt.
予約済みこれは、今後の使用のために予約7ビットのフィールドです。これは、送信時にゼロに設定されて、領収書の上で無視しなければなりません。
R This is a 1-bit field reserved for future use. It is set to zero on transmit and MUST be ignored on receipt.
Rこれは、将来の使用のために予約1ビットのフィールドです。これは、送信時にゼロに設定されて、領収書の上で無視しなければなりません。
Receiver Context Tag This is a 47-bit field for the context tag that the receiver has allocated for the context.
レシーバコンテキストタグこれは、受信機は、コンテキストに割り当てられたコンテキストタグの47ビットのフィールドです。
Psent This is a 4-bit field that indicates the number of sent probes included in this Probe message. The first set of Probe fields pertains to the current message and MUST be present, so the minimum value for this field is 1. Additional sent Probe fields are copies of the same fields sent in (recent) earlier probes and may be included or omitted as per any logic employed by the implementation.
Psentこれは、送信されたプローブの数は、このプローブメッセージに含ま示す4ビットのフィールドです。プローブ・フィールドの最初のセットは、現在のメッセージに関連し、存在しなければならないので、このフィールドの最小値は1追加送信されるプローブフィールドは（最近の）以前のプローブで送信同じフィールドのコピーであり、含まれるかのように省略されてもよいです実装によって使用される任意の論理あたり。
Precvd This is a 4-bit field that indicates the number of received probes included in this Probe message. Received Probe fields are copies of the same fields in earlier received probes that arrived since the last transition to state Exploring. When a sender is in state InboundOk it MUST include copies of the fields of at least one of the inbound probes. A sender MAY include additional sets of these received Probe fields in any state as per any logic employed by the implementation.
Precvdこれは、このプローブ・メッセージに含まれる受信したプローブ数を示す4ビットのフィールドです。受信したプローブフィールドは、探索述べる最後の遷移以降に到着以前に受信されたプローブで同じフィールドのコピーです。送信者が状態にあるときには、インバウンドのプローブの少なくとも一つのフィールドのコピーを含まなければならないInboundOk。送信者は、実装によって使用される任意のロジックに従って、任意の状態で、これらの受信したプローブ・フィールドの追加セットを含むかもしれません。
The fields Probe Source, Probe Destination, Probe Nonce, and Probe Data may be repeated, depending on the value of Psent and Preceived.
フィールドプローブソース、プローブ先、プローブノンス、およびプローブデータがPsentとPreceivedの値に応じて、繰り返してもよいです。
Sta (State) This 2-bit State field is used to inform the peer about the state of the sender. It has three legal values:
STA（状態）この2ビットの状態フィールドは、送信者の状態についてのピアに通知するために使用されます。これは3つの有効な値があります。
0 (Operational) implies that the sender both (a) believes it has no problem communicating and (b) believes that the recipient also has no problem communicating.
（動作）0は、送信者は、（a）は、それが何の問題通信と、（b）受信者はまた、通信問題がないと考えているを持っていないと考えて両方ことを意味します。
1 (Exploring) implies that the sender has a problem communicating with the recipient, e.g., it has not seen any traffic from the recipient even when it expected some.
1（探索）送信者が受信者との通信に問題を有していることを意味し、例えば、それは、いくつかの予想される場合でも、受信者からのトラフィックを見ていません。
2 (InboundOk) implies that the sender believes it has no problem communicating, i.e., it at least sees packets from the recipient but that the recipient either has a problem or has not yet confirmed to the sender that the problem has been resolved.
2（InboundOk）送信者が、それが何の問題通信を有していないと考えていることを意味し、すなわち、それは、少なくとも、受信者からのパケットを見るが、受信者は、問題があるか、まだ問題が解決されたことを送信者に確認していないのいずれかです。
Reserved2 MUST be set to zero upon transmission and MUST be ignored upon reception.
Reserved2は、送信時にゼロに設定しなければならなくて、受信時に無視しなければなりません。
Probe Source This 128-bit field contains the source IPv6 address used to send the probe.
プローブソースこの128ビットのフィールドは、プローブを送信するために使用される送信元IPv6アドレスが含まれています。
Probe Destination This 128-bit field contains the destination IPv6 address used to send the probe.
プローブの先には、この128ビットのフィールドは、プローブを送信するために使用される宛先IPv6アドレスが含まれています。
Probe Nonce This is a 32-bit field that is initialized by the sender with a value that allows it to determine with which sent probes a received probe correlates. It is highly RECOMMENDED that the Nonce field be at least moderately hard to guess so that even on-path attackers can't deduce the next nonce value that will be used. This value SHOULD be generated using a random number generator that is known to have good randomness properties as outlined in RFC 4086 [RFC4086].
プローブノンスは、これは、受信したプローブは相関プローブを送信したと決定することを可能にする値で、送信者によって初期化される32ビットのフィールドです。非常にナンス分野でも上のパス攻撃者が使用される次の一回だけの値を推測することはできませんので、推測するには、少なくとも適度に硬くすることをお勧めします。この値は、RFC 4086 [RFC4086]に概説されるように、良好なランダム特性を有することが知られている乱数発生器を使用して生成されるべきです。
Probe Data This is a 32-bit field with no fixed meaning. The Probe Data field is copied back with no changes. Future flags may define a use for this field.
プローブデータは、これは固定されていない意味を持つ32ビットのフィールドです。プローブデータフィールドを変更せずにコピーバックされます。今後のフラグは、このフィールドの使用を定義することがあります。
Options For future extensions.
将来の拡張のためのオプション。
Either side of a Shim6 context can notify the peer of the value that it would prefer the peer to use as its Keepalive Timeout value. If the node is using a non-default Send Timeout value, it MUST communicate this value as a Keepalive Timeout value to the peer in the below option. This option MAY be sent in the I2, I2bis, R2, or UPDATE messages. The option SHOULD only need to be sent once in a given Shim6 association. If a node receives this option, it SHOULD update its Keepalive Timeout value for the peer.
SHIM6コンテキストのいずれかの側は、そのキープアライブタイムアウト値として使用するピアを好むであろう値のピアに通知することができます。ノードがデフォルト以外の送信タイムアウト値を使用している場合、それは以下のオプションでピアにキープアライブタイムアウト値としてこの値を通信する必要があります。このオプションは、I2、I2bis、R2、またはUPDATEメッセージで送信することができます。オプションは、与えられたSHIM6協会に一度送信される必要があるべきです。ノードは、このオプションを受信した場合、それはピアのためのキープアライブタイムアウト値を更新する必要があります。
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 = 10 |0| Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Reserved | Keepalive Timeout |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
フィールド：
Type This field identifies the option and MUST be set to 10 (Keepalive Timeout).
このフィールドを入力してオプションを識別し、10（キープアライブタイムアウト）に設定しなければなりません。
Length This field MUST be set as specified in Section 5.1 of the Shim6 protocol description [RFC5533] -- that is, set to 4.
SHIM6プロトコル記述[RFC5533]のセクション5.1で指定されるように長さこのフィールドは設定しなければならない - つまり、4に設定します。
Reserved A 16-bit field reserved for future use. It is set to zero upon transmit and MUST be ignored upon receipt.
将来の使用のために確保された16ビットのフィールドを予約。これは、送信時にゼロに設定され、受信時に無視しなければなりません。
Keepalive Timeout The value in seconds corresponding to the suggested Keepalive Timeout value for the peer.
キープアライブタイムアウトピアの提案キープアライブタイムアウト値に対応する秒単位の値。
The required behavior of REAP nodes is specified below in the form of a state machine. The externally observable behavior of an implementation MUST conform to this state machine, but there is no requirement that the implementation actually employ a state machine. Intermixed with the following description, we also provide a state machine description in tabular form. However, that form is only informational.
REAPノードの必要な動作は、ステートマシンの形で以下に指定されています。実装の外部から観察可能な挙動は、このステートマシンに従わなければなりませんが、実装は実際にステートマシンを利用する必要はありません。以下の説明で混ぜ、我々はまた、表形式でステートマシンの記述を提供します。しかし、そのフォームは情報提供のみです。
On a given context with a given peer, the node can be in one of three states: Operational, Exploring, or InboundOK. In the Operational state, the underlying address pairs are assumed to be operational. In the Exploring state, this node hasn't seen any traffic from the peer for more than a Send Timer period. Finally, in the InboundOK state, this node sees traffic from the peer, but the peer may not yet see any traffic from this node, so the exploration process needs to continue.
運用、探索、またはInboundOK：指定されたピアと特定のコンテキストでは、ノードは3つの状態のいずれであってもよいです。動作状態では、基本となるアドレスのペアは、演算であると想定されています。探索状態では、このノードが送信タイマ期間以上のピアからのトラフィックを見ていません。最後に、InboundOK状態で、このノードは、ピアからのトラフィックを見ているが、探査プロセスを継続する必要があるので、ピアはまだ、このノードからのすべてのトラフィックが表示されないことがあります。
The node also maintains the Send Timer (Send Timeout seconds) and Keepalive Timer (Keepalive Timeout seconds). The Send Timer reflects the requirement that when this node sends a payload packet, there should be some return traffic (either payload packets or Keepalive messages) within Send Timeout seconds. The Keepalive Timer reflects the requirement that when this node receives a payload packet, there should a similar response towards the peer. The Keepalive Timer is only used within the Operational state, and the Send Timer within the Operational and InboundOK states. No timer is running in the Exploring state. As explained in Section 4.1, the two timers are mutually exclusive. That is, either the Keepalive Timer or the Send Timer is running, or neither of them is running.
ノードは送信タイマー（タイムアウト秒を送信）し、キープアライブタイマー（アライブタイムアウト秒）を維持します。タイマーを送るこのノードがペイロードパケットを送信すると、送信タイムアウトの秒以内に、いくつかのリターントラフィック（ペイロードパケットまたはキープアライブメッセージのいずれか）が存在すべきであることを要件を反映しています。キープアライブタイマーは、このノードがペイロードパケットを受信すると、ピアに向かって同様の応答がなければならないことの要件を反映しています。キープアライブタイマーは動作状態の中で使用され、そして運用およびInboundOK状態の中にタイマーを送信します。いいえタイマーは探検の状態で実行されていません。 4.1節で説明したように、2つのタイマが相互に排他的です。つまり、キープアライブタイマーやタイマーが実行されている、またはそれらのいずれも実行されている送信のいずれかです。
Note that Appendix A gives some examples of typical protocol runs in order to illustrate the behavior.
付録Aは動作を説明するために、典型的なプロトコル実行のいくつかの例を与えることに留意されたいです。
Upon the reception of a payload packet in the Operational state, the node starts the Keepalive Timer if it was not yet running, and stops the Send Timer if it was running.
動作状態にペイロードパケットを受信すると、ノードは、それがまだ実行されていなかった場合にキープアライブタイマーを開始し、それが実行中であった場合は送信タイマを停止します。
If the node is in the Exploring state, it transitions to the InboundOK state, sends a Probe message, and starts the Send Timer. It fills the Psent and corresponding Probe Source Address, Probe Destination Address, Probe Nonce, and Probe Data fields with information about recent Probe messages that have not yet been reported as seen by the peer. It also fills the Precvd and corresponding Probe Source Address, Probe Destination Address, Probe Nonce, and Probe Data fields with information about recent Probe messages it has seen from the peer. When sending a Probe message, the State field MUST be set to a value that matches the conceptual state of the sender after sending the Probe. In this case, the node therefore sets the State field to 2 (InboundOk). The IP source and destination addresses for sending the Probe message are selected as discussed in Section 4.3.
ノードが探る状態にある場合、それはInboundOK状態に遷移し、Probeメッセージを送信し、送信タイマーを開始します。これは、ピアによって見られるように、まだ報告されていない最新のプローブメッセージに関する情報をPsentと対応するプローブ送信元アドレス、プローブの宛先アドレス、プローブノンス、およびプローブデータフィールドを埋めます。それはまた、ピアから見た最近のプローブメッセージに関する情報をPrecvdと対応するプローブ送信元アドレス、プローブの宛先アドレス、プローブノンス、およびプローブデータフィールドを埋めます。プローブメッセージを送信するとき、状態フィールドは、プローブを送信した後、送信者の概念的な状態に一致する値に設定しなければなりません。この場合、ノードは、従って、2（InboundOk）に状態フィールドを設定します。プローブメッセージを送信するためのIP送信元アドレスと宛先アドレスは、セクション4.3で議論するように選択されます。
In the InboundOK state, the node stops the Send Timer if it was running, but does not do anything else.
InboundOK状態では、ノードは、それが実行されていた場合は送信タイマーを停止しますが、他に何もしません。
The reception of Shim6 control messages other than the Keepalive and Probe messages are treated the same as the reception of payload packets.
キープアライブおよびプローブメッセージ以外SHIM6制御メッセージの受信は、ペイロードパケットの受信と同じように扱われます。
While the Keepalive Timer is running, the node SHOULD send Keepalive messages to the peer with an interval of Keepalive Interval seconds. Conceptually, a separate timer is used to distinguish between the interval between Keepalive messages and the overall Keepalive Timeout interval. However, this separate timer is not modelled in the tabular or graphical state machines. When sent, the Keepalive message is constructed as described in Section 5.1. It is sent using the current address pair.
キープアライブタイマーが実行されている間、ノードは、キープアライブ間隔秒の間隔でピアにキープアライブメッセージを送信すべきです。概念的には、独立したタイマーがキープアライブメッセージと全体的なキープアライブタイムアウトインターバルの間の間隔を区別するために使用されます。しかし、この独立したタイマーは、表形式またはグラフィカルステートマシンでモデル化されていません。送信された場合、セクション5.1で説明したように、キープアライブメッセージが構成されています。これは、現在のアドレスのペアを使用して送信されます。
In the below tables, "START", "RESTART", and "STOP" refer to starting, restarting, and stopping the Keepalive Timer or the Send Timer, respectively. "GOTO" refers to transitioning to another state. "SEND" refers to sending a message, and "-" refers to taking no action.
以下の表では、「START」、「RESTART」、およびそれぞれ、起動、再起動、およびキープアライブタイマーまたは送信タイマーを停止することを指し、「STOP」。 「GOTO」は別の状態への移行を意味します。 「 - 」何の行動も取らないを意味し、「SEND」メッセージを送信することをいい、。
Operational Exploring InboundOk
--------------------------------------------------------------------
STOP Send SEND Probe InboundOk STOP Send
START Keepalive START Send
GOTO InboundOk
Upon sending a payload packet in the Operational state, the node stops the Keepalive Timer if it was running and starts the Send Timer if it was not running. In the Exploring state there is no effect, and in the InboundOK state the node simply starts the Send Timer if it was not yet running. (The sending of Shim6 control messages is again treated the same.)
動作状態でペイロードパケットを送信すると、ノードは、それが実行されていた場合はキープアライブタイマーを停止し、それが実行されていなかった場合、送信タイマを開始します。探検状態では効果がない、そしてそれはまだ動作していなかった場合InboundOK状態でノードは、単に送信タイマーを開始します。 （SHIM6制御メッセージの送信は、再び同じに扱われます。）
Operational Exploring InboundOk
------------------------------------------------------------------
START Send - START Send
STOP Keepalive
Upon a timeout on the Keepalive Timer, the node sends one last Keepalive message. This can only happen in the Operational state.
キープアライブタイマーのタイムアウト時には、ノードは、1つの最後のキープアライブメッセージを送信します。これは、運用状態で発生する可能性があります。
The Keepalive message is constructed as described in Section 5.1. It is sent using the current address pair.
セクション5.1で説明したようにキープアライブメッセージが構成されています。これは、現在のアドレスのペアを使用して送信されます。
Operational Exploring InboundOk
------------------------------------------------------------------
SEND Keepalive - -
Upon a timeout on the Send Timer, the node enters the Exploring state and sends a Probe message. The Probe message is constructed as explained in Section 6.1, except that the State field is set to 1 (Exploring).
送信タイマのタイムアウト時に、ノードは探索状態に入り、プローブメッセージを送信します。状態フィールドが1（探索）に設定されていることを除いて、セクション6.1で説明したようにプローブメッセージが構成されています。
Operational Exploring InboundOk
------------------------------------------------------------------
SEND Probe Exploring - SEND Probe Exploring
GOTO Exploring GOTO Exploring
While in the Exploring state, the node keeps retransmitting its Probe messages to different (or the same) addresses as defined in Section 4.3. A similar process is employed in the InboundOk state, except that upon such retransmission, the Send Timer is started if it was not running already.
探索状態の間、ノードはセクション4.3で定義されるように、異なる（又は同一の）アドレスへのプローブメッセージを再送信し続けます。同様のプロセスは、このような再送時ことを除いて、InboundOk状態で採用されているがまだ実行されていなかった場合、送信タイマーが開始されます。
The Probe messages are constructed as explained in Section 6.1, except that the State field is set to 1 (Exploring) or 2 (InboundOk), depending on which state the sender is in.
状態フィールドは（探索）または2（InboundOk）、送信者がでている状態かに応じて1に設定されていることを除いて、セクション6.1で説明したようにプローブメッセージが構成されています。
Operational Exploring InboundOk
-----------------------------------------------------------------
- SEND Probe Exploring SEND Probe InboundOk
START Send
Upon the reception of a Keepalive message in the Operational state, the node stops the Send Timer if it was running. If the node is in the Exploring state, it transitions to the InboundOK state, sends a Probe message, and starts the Send Timer. The Probe message is constructed as explained in Section 6.1.
動作状態にキープアライブメッセージを受信すると、ノードは、それが実行中であった場合は送信タイマを停止します。ノードが探る状態にある場合、それはInboundOK状態に遷移し、Probeメッセージを送信し、送信タイマーを開始します。セクション6.1で説明したようにプローブメッセージが構成されています。
In the InboundOK state, the Send Timer is stopped if it was running.
それが実行されていた場合はInboundOK状態では、送信タイマーが停止しています。
Operational Exploring InboundOk
------------------------------------------------------------------
STOP Send SEND Probe InboundOk STOP Send
START Send
GOTO InboundOk
Upon receiving a Probe message with State set to Exploring, the node enters the InboundOK state, sends a Probe message as described in Section 6.1, stops the Keepalive Timer if it was running, and restarts the Send Timer.
探索に設定された状態とのProbeメッセージを受信すると、ノードはInboundOK状態に入る、セクション6.1で説明したようにプローブメッセージを送信し、それが実行中であった場合はキープアライブタイマーを停止し、送信タイマを再開する。
Operational Exploring InboundOk
------------------------------------------------------------------
SEND Probe InboundOk SEND Probe InboundOk SEND Probe InboundOk
STOP Keepalive START Send RESTART Send
RESTART Send GOTO InboundOk
GOTO InboundOk
Upon the reception of a Probe message with State set to InboundOk, the node sends a Probe message, restarts the Send Timer, stops the Keepalive Timer if it was running, and transitions to the Operational state. A new current address pair is chosen for the connection, based on the reports of received probes in the message that we just received. If no received probes have been reported, the current address pair is unchanged.
InboundOkに設定された状態とのProbeメッセージを受信すると、ノードは、プローブ・メッセージを送信する送信タイマを再起動し、それが実行中であった場合はキープアライブタイマーを停止し、動作状態に遷移します。新しい現在のアドレスのペアは、我々だけで、受信したメッセージに、受信したプローブの報告に基づいて、接続のために選択されています。何も受信したプローブが報告されていない場合は、現在のアドレスのペアは変更されません。
The Probe message is constructed as explained in Section 6.1, except that the State field is set to zero (Operational).
状態フィールドは（動作）がゼロに設定されていることを除いて、セクション6.1で説明したようにプローブメッセージが構成されています。
Operational Exploring InboundOk
--------------------------------------------------------------------
SEND Probe Operational SEND Probe Operational SEND Probe Operational
RESTART Send RESTART Send RESTART Send
STOP Keepalive GOTO Operational GOTO Operational
Upon the reception of a Probe message with State set to Operational, the node stops the Send Timer if it was running, starts the Keepalive Timer if it was not yet running, and transitions to the Operational state. The Probe message is constructed as explained in Section 6.1, except that the State field is set to zero (Operational).
操作に設定された状態とのProbeメッセージを受信すると、ノードは、それが実行中であった場合は送信タイマが停止し、それがまだ実行されていなかった場合にキープアライブタイマーを開始し、動作状態に遷移します。状態フィールドは（動作）がゼロに設定されていることを除いて、セクション6.1で説明したようにプローブメッセージが構成されています。
Note: This terminates the exploration process when both parties are happy and know that their peer is happy as well.
注意：これは、両当事者が満足していると、そのピアが同様に幸せであることを知っている探査処理を終了します。
Operational Exploring InboundOk
------------------------------------------------------------------
STOP Send STOP Send STOP Send
START Keepalive START Keepalive START Keepalive
GOTO Operational GOTO Operational
The reachability detection and exploration process has no effect on payload communications until a new operational address pair has actually been confirmed. Prior to that, the payload packets continue to be sent to the previously used addresses.
新しい業務アドレスのペアが実際に確認されるまで到達可能性の検出および探査プロセスは、ペイロード通信には影響を与えません。それ以前は、ペイロードパケットは、以前に使用されたアドレスに送信され続けています。
In the PDF version of this specification, an informational drawing illustrates the state machine. Where the text and the drawing differ, the text takes precedence.
この仕様のPDF版では、情報の描画は、ステートマシンを示しています。テキストと描画が異なる場合、テキストが優先されます。
The following protocol constants are defined:
以下のプロトコル定数が定義されています。
Initial Probe Timeout 0.5 seconds Number of Initial Probes 4 probes
初期プローブ4つのプローブの初期プローブタイムアウト0.5秒数
And these variables have the following default values:
そして、これらの変数は、次のデフォルト値を持っています：
Send Timeout 15 seconds Keepalive Timeout X seconds, where X is the peer's Send Timeout as communicated in the Keepalive Timeout Option 15 seconds if the peer didn't send a Keepalive Timeout option Keepalive Interval Y seconds, where Y is one-third to one-half of the Keepalive Timeout value (see Section 4.1)
Xは、キープアライブタイムアウトオプションで通信されるピアの送信タイムアウトがタイムアウト15秒キープアライブタイムアウトX秒を送る15秒あればYが1桁にする三分の一があるキープアライブインターバルのY秒をキープアライブタイムアウト]オプションを送信しませんでしたピア、キープアライブタイムアウト値の半分（4.1節を参照してください）
Alternate values of the Send Timeout may be selected by a node and communicated to the peer in the Keepalive Timeout Option. A very small value of the Send Timeout may affect the ability to exchange keepalives over a path that has a long roundtrip delay. Similarly, it may cause Shim6 to react to temporary failures more often than necessary. As a result, it is RECOMMENDED that an alternate Send Timeout value not be under 10 seconds. Choosing a higher value than the one recommended above is also possible, but there is a relationship between Send Timeout and the ability of REAP to discover and correct errors in the communication path. In any case, in order for Shim6 to be useful, it should detect and repair communication problems long before upper layers give up. For this reason, it is RECOMMENDED that Send Timeout be at most 100 seconds (default TCP R2 timeout [RFC1122]).
送信タイムアウトの代替値は、ノードによって選択され、キープアライブタイムアウトオプションでピアに通信されてもよいです。送信タイムアウトの非常に小さな値が長い往復遅延を持つパスを介してキープアライブを交換する能力に影響を与える可能性があります。同様に、それはSHIM6が必要以上に頻繁に一時的な障害に反応する可能性があります。その結果、別の送信タイムアウト値が10秒未満でないことをお勧めします。上記の推奨値よりも高い値を選択することも可能であるが、通信パスで送信タイムアウトと発見するREAPの能力と正確なエラーの間に関係があります。上位層は、あきらめる前に長いいずれの場合においても、SHIM6が有用であるために、それが通信の問題を検出し、修復しなければなりません。このような理由から、それはタイムアウトが最大で100秒で送ることをお勧めします（デフォルトTCP R2のタイムアウト[RFC1122]）。
Note: It is not expected that the Send Timeout or other values will be estimated based on experienced roundtrip times. Signaling exchanges are performed based on exponential back-off. The keepalive processes send packets only in the relatively rare condition that all traffic is unidirectional.
注意：送信タイムアウトまたは他の値は、経験豊富な往復時間に基づいて推定されることが期待されていません。シグナリング交換は、指数バックオフに基づいて行われます。キープアライブのプロセスは、すべてのトラフィックが一方向である比較的まれな状態でパケットを送信します。
Attackers may spoof various indications from lower layers and from the network in an effort to confuse the peers about which addresses are or are not operational. For example, attackers may spoof ICMP error messages in an effort to cause the parties to move their traffic elsewhere or even to disconnect. Attackers may also spoof information related to network attachments, Router Discovery, and address assignments in an effort to make the parties believe they have Internet connectivity when in reality they do not.
攻撃者は、アドレスがあるか、または動作していないであるかについてのピアを混乱させるための努力の下位層から、ネットワークからの各種指示を偽造することができます。例えば、攻撃者は、当事者が切断する他の場所、あるいはそのトラフィックを移動させるための努力のICMPエラーメッセージを偽装します。攻撃者はまた、関連のパロディー情報は、当事者が、現実にはそうではないとき、彼らはインターネット接続を持っていると信じて作るための努力の添付ファイル、ルータ検出、およびアドレス割り当てをネットワークすることがあります。
This may cause use of non-preferred addresses or even denial of service.
これは、非優先アドレスの使用やサービスのさえ拒否を引き起こす可能性があります。
This protocol does not provide any protection of its own for indications from other parts of the protocol stack. Unprotected indications SHOULD NOT be taken as a proof of connectivity problems. However, REAP has weak resistance against incorrect information even from unprotected indications in the sense that it performs its own tests prior to picking a new address pair. Denial-of-service vulnerabilities remain, however, as do vulnerabilities against on-path attackers.
このプロトコルは、プロトコル・スタックの他の部分からの適応症のために、独自の任意の保護を提供しません。保護されていない表示は、接続の問題の証拠として解釈されるべきではありません。しかし、それは新しいアドレスのペアを選ぶ前に、独自のテストを実行するという意味で保護されていない兆候から誤った情報に弱い抵抗性を有するREAP。上のパス攻撃に対する脆弱性がそうであるように、サービス拒否の脆弱性は、しかし、残っています。
Some aspects of these vulnerabilities can be mitigated through the use of techniques specific to the other parts of the stack, such as properly dealing with ICMP errors [GONT], link-layer security, or the use of SEND [RFC3971] to protect IPv6 Router and Neighbor Discovery.
これらの脆弱性のいくつかの局面は、適切にICMPエラー[GONT]、リンク層セキュリティ、またはIPv6ルータを保護するためのSENDの使用[RFC3971]に対処するように、特定のスタックの他の部分への技術の使用によって軽減することができますおよび近隣探索。
Other parts of the Shim6 protocol ensure that the set of addresses we are switching between actually belong together. REAP itself provides no such assurances. Similarly, REAP provides some protection against third-party flooding attacks [AURA02]; when REAP is run, its Probe Nonces can be used as a return routability check that the claimed address is indeed willing to receive traffic. However, this needs to be complemented with another mechanism to ensure that the claimed address is also the correct node. Shim6 does this by performing binding of all operations to context tags.
SHIM6プロトコルの他の部分は、私たちが実際の切り替えされているアドレスのセットが一緒に属していることを確認してください。自身がそのような保証を提供していませんREAP。同様に、REAP [AURA02]サードパーティのフラッディング攻撃に対する何らかの保護を提供します。 REAPが実行されると、そのプローブナンスは主張したアドレスが実際にトラフィックを受信する意思があることを、リターン・ルータビリティチェックとして使用することができます。ただし、これは特許請求のアドレスも正しいノードであることを確実にするために別の機構を補完する必要があります。 SHIM6は、コンテキストタグにすべての操作のバインディングを実行することでこれを行います。
The keepalive mechanism in this specification is vulnerable to spoofing. On-path attackers that can see a Shim6 context tag can send spoofed Keepalive messages once per Send Timeout interval in order to prevent two Shim6 nodes from sending Keepalives themselves. This vulnerability is only relevant to nodes involved in a one-way communication. The result of the attack is that the nodes enter the exploration phase needlessly, but they should be able to confirm connectivity unless, of course, the attacker is able to prevent the exploration phase from completing. Off-path attackers may not be able to generate spoofed results, given that the context tags are 47- bit random numbers.
本明細書におけるキープアライブ機構は、スプーフィングに対して脆弱です。キープアライブ自分自身を送信してから2つのSHIM6ノードを防止するために、タイムアウト間隔を送るごとに一度SHIM6コンテキストタグが偽装されたキープアライブメッセージを送信することができます見ることができます上のパス攻撃。この脆弱性は、一方向通信に関与するノードにのみ関係します。攻撃の結果は、ノードは不探査段階に入るということですが、彼らはもちろん、攻撃者が完了することから探鉱を防止することができる、しない限り、接続性を確認することができるはずです。オフ・パス攻撃者は、コンテキストタグが47-ビット乱数であることを考えると、スプーフィングされた結果を生成することができないかもしれません。
To protect against spoofed Keepalive messages, a node implementing both Shim6 and IPsec MAY ignore incoming REAP keepalives if it has good reason to assume that the other side will be sending IPsec-protected return traffic. In other words, if a node is sending TCP payload data, it can reasonably expect to receive TCP ACKs in return. If no IPsec-protected ACKs come back but unprotected keepalives do, this could be the result of an attacker trying to hide broken connectivity.
それは、他の側はIPsecで保護されたリターントラフィックを送信されると仮定する十分な理由がある場合は、偽装されたキープアライブメッセージから保護するために、SHIM6とIPsecの両方を実装するノードは、着信REAPキープアライブを無視してもよいです。ノードは、TCPペイロードデータを送信している言い換えれば、それは合理的にお返しにTCP ACKを受け取ることを期待することができます。何のIPsecで保護されたACKが戻ってきませんが、保護されていないキープアライブを行う場合、これは壊れた接続を隠そうと攻撃の結果である可能性があります。
The exploration phase is vulnerable to attackers that are on the path. Off-path attackers would find it hard to guess either the context tag or the correct probe identifiers. Given that IPsec operates above the Shim6 layer, it is not possible to protect the exploration phase against on-path attackers with IPsec. This is similar to the issues with protecting other Shim6 control exchanges. There are mechanisms in place to prevent the redirection of communications to wrong addresses, but on-path attackers can cause denial-of-service, move communications to less-preferred address pairs, and so on.
探査段階は、パス上にある攻撃に対して脆弱です。オフパス攻撃者は、それが難しい状況タグや正しいプローブ識別子のいずれかを推測するために見つけるだろう。 IPsecはSHIM6層の上に動作することを考えると、IPsecでのパス攻撃者に対して探鉱を保護することはできません。これは、他のSHIM6制御交換を保護するとの問題に似ています。そこ間違ったアドレスへの通信のリダイレクトを防止するための場所でのメカニズムがありますが、上のパス攻撃者がそうで、サービス拒否を引き起こすあまり好まアドレスのペアにコミュニケーションを移動し、することができます。
Finally, the exploration itself can cause a number of packets to be sent. As a result, it may be used as a tool for packet amplification in flooding attacks. It is required that the protocol employing REAP has built-in mechanisms to prevent this. For instance, Shim6 contexts are created only after a relatively large number of packets have been exchanged, a cost that reduces the attractiveness of using Shim6 and REAP for amplification attacks. However, such protections are typically not present at connection-establishment time. When exploration would be needed for connection establishment to succeed, its usage would result in an amplification vulnerability. As a result, Shim6 does not support the use of REAP in the connection-establishment stage.
最後に、探査自身が送信するパケットの数を引き起こす可能性があります。その結果、フラッディング攻撃のパケット増幅のためのツールとして使用することができます。 REAP用いるプロトコルが組み込まれていること、これを防止するためのメカニズムが必要です。例えば、SHIM6コンテキストは、パケットのみの比較的大きな数は、SHIM6を使用して、増幅攻撃のREAPの魅力を減少させ、コストを交換した後に作成されます。しかしながら、そのような保護は、典型的には、コネクション確立時には存在しません。探査が成功するために接続確立のために必要とされるであろうと、その使用方法は、増幅の脆弱性につながります。結果として、SHIM6は、接続確立段階でREAPの使用をサポートしていません。
When there are no failures, the failure-detection mechanism (and Shim6 in general) are lightweight: keepalives are not sent when a Shim6 context is idle or when there is traffic in both directions. So in normal TCP or TCP-like operations, there would only be one or two keepalives when a session transitions from active to idle.
いかなる障害、（一般的に及びSHIM6）障害検出メカニズムが存在しない場合に軽量である：SHIM6コンテキストがアイドル状態である場合、またはキープアライブが送信されないトラフィックが両方向に存在する場合。アクティブなセッションからの遷移がアイドル状態にするときだから、通常のTCPまたはTCPのような操作で、1つのまたは2つだけキープアライブがあるでしょう。
Only when there are failures is there significant failure-detection traffic, especially in the case where a link goes down that is shared by many active sessions and by multiple nodes. When this happens, one keepalive is sent and then a series of probes. This happens per active (traffic-generating) context, all of which will time out within 15 seconds after the failure. This makes the peak traffic that Shim6 generates after a failure around one packet per second per context. Presumably, the sessions that run over those contexts were sending at least that much traffic and most likely more, but if the backup path is significantly lower bandwidth than the failed path, this could lead to temporary congestion.
障害がある場合にのみ、特にリンクはそのダウンした場合の、そこに重大な故障検出トラフィックでは、多くのアクティブなセッションで、複数のノードによって共有されています。この場合、1つのキープアライブが送信され、その後、一連のプローブされます。これは、障害が発生した後、15秒以内にタイムアウトしますすべては、アクティブ（トラヒック発生）コンテキストごとに発生します。これはSHIM6は、コンテキストごとに毎秒1つのパケットの周りに障害が発生した後に発生ピーク時のトラフィックになります。おそらく、それらのコンテキスト上で実行したセッションは、少なくともそのくらいのトラフィックと最も可能性の高いより多くのを送ったが、バックアップパスが失敗したパスよりも大幅に低い帯域幅であれば、これは一時的な混雑につながる可能性があります。
However, note that in the case of multihoming using BGP, if the failover is fast enough that TCP doesn't go into slow start, the full payload data traffic that flows over the failed path is switched over to the backup path, and if this backup path is of a lower capacity, there will be even more congestion.
しかし、フェイルオーバーがTCPスロースタートに入らないことを十分に速い場合は、BGPを使用してマルチホーミングの場合には、障害が発生したパス上を流れるフルペイロードデータトラフィックをバックアップパスに切り替えていることに注意してください、この場合バックアップパスは、低容量のものであり、さらに多くの輻輳があるでしょう。
Although the failure detection probing does not perform congestion control as such, the exponential back-off makes sure that the number of packets sent quickly goes down and eventually reaches one per context per minute, which should be sufficiently conservative even on the lowest bandwidth links.
障害検出のような輻輳制御を行わないプロービングが、指数バックオフはすぐに送信されたパケットの数がダウンし、最終的にも最低帯域幅リンクで十分に保守的である必要があり、毎分、コンテキストごとに1つずつ、到達したことを確認します。
Section 7 specifies a number of protocol parameters. Possible tuning of these parameters and others that are not mandated in this specification may affect these properties. It is expected that further revisions of this specification provide additional information after sufficient deployment experience has been obtained from different environments.
第7節は、プロトコルパラメータの数を指定します。この仕様で義務付けされていない、これらのパラメータおよびその他の可能なチューニングは、これらの特性に影響を与える可能性があります。十分な展開の経験が異なる環境から取得された後、この仕様の更なる改正は、追加情報を提供することが期待されます。
Implementations may provide means to monitor their performance and send alarms about problems. Their standardization is, however, the subject of future specifications. In general, Shim6 is most applicable for small sites and nodes, and it is expected that monitoring requirements on such deployments are relatively modest. In any case, where the node is associated with a management system, it is RECOMMENDED that detected failures and failover events are reported via asynchronous notifications to the management system. Similarly, where logging mechanisms are available on the node, these events should be recorded in event logs.
実装は、彼らのパフォーマンスを監視し、問題についてアラームを送信する手段を提供することができます。彼らの標準化は、しかし、将来の仕様の対象です。一般的には、SHIM6は、小規模サイトやノードのための最も適用可能であり、このような展開の監視要件は比較的控えめであることを期待されています。ノードが管理システムに関連付けられている任意の場合において、障害を検出し、フェイルオーバー・イベントが管理システムへ非同期通知を介して報告されることが推奨されます。ロギングメカニズムがノード上で利用可能である場合、同様に、これらのイベントは、イベントログに記録されるべきです。
Shim6 uses the same header for both signaling and the encapsulation of payload packets after a rehoming event. This way, fate is shared between the two types of packets, so the situation where reachability probes or keepalives can be transmitted successfully but payload packets cannot, is largely avoided: either all Shim6 packets make it through, so Shim6 functions as intended, or none do, and no Shim6 state is negotiated. Even in the situation where some packets make it through and others do not, Shim6 will generally either work as intended or provide a service that is no worse than in the absence of Shim6, apart from the possible generation of a small amount of signaling traffic.
SHIM6は、シグナリング及びリホームイベントの後、ペイロードパケットのカプセル化の両方に同じヘッダを使用します。すべてSHIM6パケットがそれを通じ作るので、SHIM6意図したとおりに機能し、またはnoneのいずれか：状況到達可能性プローブまたはキープアライブが正常に送信できる場所が、ペイロードパケットは、大幅に回避されることができないので、この方法では、運命は、パケットの2種類の間で共有されていますやる、と何SHIM6状態が交渉されていません。でも、いくつかのパケットがそれを通じ作り、他の人がいない状況で、SHIM6は、一般的にどちらかの作業は意図したとおりに、または離れてシグナリングトラフィックの少量の可能な世代から、SHIM6の非存在下におけるよりも悪いことではないサービスを提供します。
Sometimes payload packets (and possibly payload packets encapsulated in the Shim6 header) do not make it through, but signaling and keepalives do. This situation can occur when there is a path MTU discovery black hole on one of the paths. If only large packets are sent at some point, then reachability exploration will be turned on and REAP will likely select another path, which may or may not be affected by the PMTUD black hole.
時々（おそらくとSHIM6ヘッダでカプセル化されたペイロードパケット）のペイロード・パケットがそれを介して行うが、シグナリングおよびキープアライブは行いません。パスの一方の経路MTU探索ブラックホールが存在する場合、このような状況が発生する可能性があります。唯一の大きなパケットをある時点で送信された場合、到達可能性探査がオンとREAPされる可能性が高いか、PMTUDブラックホールによって影響されなくてもよい別のパスを選択します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315] Droms、R.、バウンド、J.、フォルツ、B.、レモン、T.、パーキンス、C.、およびM.カーニー、 "IPv6のための動的ホスト構成プロトコル（DHCPv6）"、RFC 3315、2003年7月。
[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484] Draves、R.、RFC 3484 "インターネットプロトコルバージョン6（IPv6）のデフォルトのアドレス選択"、2003年2月。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]イーストレーク、D.、シラー、J.、およびS.クロッカー、 "セキュリティのためのランダム要件"、BCP 106、RFC 4086、2005年6月。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[RFC4193] HindenとR.とB.ハーバーマン、 "ユニークローカルIPv6ユニキャストアドレス"、RFC 4193、2005年10月。
[RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) for IPv6", RFC 4429, April 2006.
[RFC4429]ムーア、N.、 "IPv6の楽観重複アドレス検出（DAD）"、RFC 4429、2006年4月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861] Narten氏、T.、Nordmarkと、E.、シンプソン、W.、およびH.ソリマン、 "IPバージョン6（IPv6）のための近隣探索"、RFC 4861、2007年9月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862]トムソン、S.、Narten氏、T.、およびT.神明、 "IPv6のステートレスアドレス自動設定"、RFC 4862、2007年9月。
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", RFC 5533, June 2009.
[RFC5533] Nordmarkと、E.およびM. Bagnulo、 "SHIM6：IPv6のレベル3マルチホーミングシム・プロトコル"、RFC 5533、2009年6月。
[ADD-SEL] Bagnulo, M., "Address selection in multihomed environments", Work in Progress, October 2005.
[ADD-SEL] Bagnulo、M.、 "マルチホーム環境におけるアドレス選択"、進歩、2005年10月に作業。
[AURA02] Aura, T., Roe, M., and J. Arkko, "Security of Internet Location Management", Proceedings of the 18th Annual Computer Security Applications Conference, Las Vegas, Nevada, USA, December 2002.
[AURA02]オーラ、T.、卵、M.、およびJ. Arkko、「インターネットの場所の管理のセキュリティ」、第18回コンピュータセキュリティアプリケーションの会議の議事録、ラスベガス、ネバダ州、アメリカ、2002年12月。
[BFD] Katz, D. and D. Ward, "Bidirectional Forwarding Detection", Work in Progress, February 2009.
[BFD]カッツ、D.とD.ウォード、 "双方向フォワーディング検出"、進歩、2009年2月に作業。
[DNA-SIM] Krishnan, S. and G. Daley, "Simple procedures for Detecting Network Attachment in IPv6", Work in Progress, February 2009.
[DNA-SIM]クリシュナン、S.およびG.デイリー、「IPv6におけるネットワーク接続検出のための簡単な手順」、進歩、2009年2月に作業。
[GONT] Gont, F., "ICMP attacks against TCP", Work in Progress, October 2008.
[GONT] Gont、F.、 "TCPに対するICMP攻撃"、進歩、2008年10月の作業。
[MULTI6] Huitema, C., "Address selection in multihomed environments", Work in Progress, October 2004.
[MULTI6]のHuitema、C.、 "マルチホーム環境におけるアドレス選択"、進歩、2004年10月に作業。
[PAIR] Bagnulo, M., "Default Locator-pair selection algorithm for the Shim6 protocol", Work in Progress, October 2008.
[PAIR] Bagnulo、M.、 "SHIM6プロトコルのデフォルトロケータペア選択アルゴリズム"、進歩、2008年10月の作業。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]ブレーデン、R.、 "インターネットホストのための要件 - 通信層"、STD 3、RFC 1122、1989年10月。
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3971] Arkko、J.、ケンプ、J.、Zill、B.、およびP. Nikander、 "セキュア近隣探索（SEND）"、RFC 3971、2005年3月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]スチュワート、R.、 "ストリーム制御伝送プロトコル"、RFC 4960、2007年9月。
[RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End-Host Mobility and Multihoming with the Host Identity Protocol", RFC 5206, April 2008.
[RFC5206] Nikander、P.、ヘンダーソン、T.、フォークト、C.、およびJ. Arkko、 "ホストアイデンティティプロトコルとエンドホストモビリティとマルチホーミング"、RFC 5206、2008年4月。
Appendix A. Example Protocol Runs
付録A.例のプロトコルが実行されます
This appendix has examples of REAP protocol runs in typical scenarios. We start with the simplest scenario of two nodes, A and B, that have a Shim6 connection with each other but are not currently sending any payload data. As neither side sends anything, they also do not expect anything back, so there are no messages at all:
この付録では、典型的なシナリオでREAPプロトコルの実行の例があります。我々は、互いにSHIM6接続しているが、現在、任意のペイロード・データを送信していない2つのノードA及びBの最も単純なシナリオで始まります。どちらの側が何を送信したように、彼らはまた戻って何かを期待していないので、すべてのメッセージはありません。
EXAMPLE 1: No Communications
例1：いいえコミュニケーションズ
Peer A Peer B | | | | | | | | | | | | | | | |
ピアBピア| | | | | | | | | | | | | | | |
Our second example involves an active connection with bidirectional payload packet flows. Here, the reception of payload data from the peer is taken as an indication of reachability, so again there are no extra packets:
私たちの第二の例では、双方向のペイロードパケットフローとのアクティブな接続を含みます。ここで、ピアからのペイロードデータの受信は、余分なパケットが存在しないので、再度、到達可能性の指標としました。
EXAMPLE 2: Bidirectional Communications
例2：双方向コミュニケーション
Peer A Peer B
| |
| payload packet |
|-------------------------------------------->|
| |
| payload packet |
|<--------------------------------------------|
| |
| payload packet |
|-------------------------------------------->|
| |
| |
The third example is the first one that involves an actual REAP message. Here, the nodes communicate in just one direction, so REAP messages are needed to indicate to the peer that sends payload packets that its packets are getting through:
第3の例は、実際のREAPメッセージを含む最初のものです。ここでは、ノードは、ただ一つの方向に通信し、そのメッセージは、そのパケットが通過しているペイロードパケットを送信したピアに示すために必要とされているREAP：
EXAMPLE 3: Unidirectional Communications
例3：単方向通信
Peer A Peer B
| |
| payload packet |
|-------------------------------------------->|
| |
| payload packet |
|-------------------------------------------->|
| |
| payload packet |
|-------------------------------------------->|
| |
| Keepalive Nonce=p |
|<--------------------------------------------|
| |
| payload packet |
|-------------------------------------------->|
| |
| |
The next example involves a failure scenario. Here, A has address A, and B has addresses B1 and B2. The currently used address pairs are (A, B1) and (B1, A). All connections via B1 become broken, which leads to an exploration process:
次の例では、障害シナリオを必要とします。ここで、Aは、アドレスAを持ち、そしてBはB1とB2のアドレスを持っています。現在使用されているアドレスのペアは（A、B1）および（B1、A）です。 B1を介したすべての接続は、探査プロセスにつながる、壊れになります：
EXAMPLE 4: Failure Scenario
例4：障害シナリオ
Peer A Peer B
| |
State: | State:
Operational | Operational
| (A,B1) payload packet |
|-------------------------------------------->|
| |
| (B1,A) payload packet |
|<--------------------------------------------| At time T1
| | path A<->B1
| (A,B1) payload packet | becomes
|----------------------------------------/ | broken.
| |
| ( B1,A) payload packet |
| /-----------------------------------------|
| |
| (A,B1) payload packet |
|----------------------------------------/ |
| |
| (B1,A) payload packet |
| /-----------------------------------------|
| |
| (A,B1) payload packet |
|----------------------------------------/ |
| |
| | Send Timeout
| | seconds after
| | T1, B happens to
| | see the problem
| (B1,A) Probe Nonce=p, | first and sends a
| state=exploring | complaint that
| /-----------------------------------------| it is not
| | receiving
| | anything.
| | State:
| | Exploring
| |
| (B2,A) Probe Nonce=q, |
| state=exploring | But it's lost,
|<--------------------------------------------| retransmission
| | uses another pair
A realizes |
that it needs |
to start the |
exploration. |
It picks B2 as the | most likely candidate, |
as it appeared in the |
Probe. |
State: InboundOk |
| |
| (A, B2) Probe Nonce=r, |
| state=inboundok, |
| received probe q | This one gets
|-------------------------------------------->| through.
| | State:
| | Operational
| (B2,A) Probe Nonce=s, |
| state=operational, | B now knows
| received probe r | that A has no
|<--------------------------------------------| problem receiving
| | its packets.
State: Operational |
| |
| (A,B2) payload packet |
|-------------------------------------------->| Payload packets
| | flow again.
| (B2,A) payload packet |
|<--------------------------------------------|
The next example shows when the failure for the current locator pair is in the other direction only. A has addresses A1 and A2, and B has addresses B1 and B2. The current communication is between A1 and B1, but A's packets no longer reach B using this pair.
現在のロケータペアに障害が唯一の他の方向にある場合、次の例が示しています。 Aは、アドレスA1とA2があり、BはB1とB2のアドレスを持っています。現在の通信は、A1とB1との間にあるが、Aのパケットは、もはやこのペアを使用してBに到達していません。
EXAMPLE 5: One-Way Failure
【実施例5：ワンウェイ失敗
Peer A Peer B
| |
State: | State:
Operational | Operational
| |
| (A1,B1) payload packet |
|-------------------------------------------->|
| |
| (B1,A1) payload packet |
|<--------------------------------------------|
| |
| (A1,B1) payload packet | At time T1
|----------------------------------------/ | path A1->B1
| | becomes
| | broken.
| (B1,A1) payload packet |
|<--------------------------------------------|
| |
| (A1,B1) payload packet |
|----------------------------------------/ |
| |
| (B1,A1) payload packet |
|<--------------------------------------------|
| |
| (A1,B1) payload packet |
|----------------------------------------/ |
| |
| | Send Timeout
| | seconds after
| | T1, B notices
| | the problem and
| (B1,A1) Probe Nonce=p, | sends a
| state=exploring | complaint that
|<--------------------------------------------| it is not
| | receiving
| | anything.
A responds. | State: Exploring
State: InboundOk |
| |
| (A1, B1) Probe Nonce=q, |
| state=inboundok, |
| received probe p |
|----------------------------------------/ | A's response
| | is lost.
| (B2,A2) Probe Nonce=r, |
| state=exploring | Next, try a different
|<--------------------------------------------| locator pair.
| |
| (A2, B2) Probe Nonce=s, |
| state=inboundok, |
| received probes p, r | This one gets
|-------------------------------------------->| through.
| | State: Operational
| |
| | B now knows
| | that A has no
| (B2,A2) Probe Nonce=t, | problem receiving
| state=operational, | its packets and
| received probe s | that A's probe
|<--------------------------------------------| gets to B. It
| | sends a
State: Operational | confirmation to A.
| |
| (A2,B2) payload packet |
|-------------------------------------------->| Payload packets
| | flow again.
| (B1,A1) payload packet |
|<--------------------------------------------|
Appendix B. Contributors
付録B.協力者
This document attempts to summarize the thoughts and unpublished contributions of many people, including MULTI6 WG design team members Marcelo Bagnulo Braun, Erik Nordmark, Geoff Huston, Kurtis Lindqvist, Margaret Wasserman, and Jukka Ylitalo; MOBIKE WG contributors Pasi Eronen, Tero Kivinen, Francis Dupont, Spencer Dawkins, and James Kempf; and HIP WG contributors such as Pekka Nikander. This document is also in debt to work done in the context of SCTP [RFC4960] and the Host Identity Protocol (HIP) multihoming and mobility extension [RFC5206].
この文書では、思考やMULTI6 WG設計チームのメンバーマルセロBagnuloブラウン、エリックNordmarkと、ジェフ・ヒューストン、カーティスLindqvist、マーガレットワッサーマン、およびユッカYlitaloを含む多くの人々、の未発表の貢献を要約しようとします。 MOBIKE WGはパシEronen、TERO Kivinen、フランシスデュポン、スペンサードーキンスとジェームズケンプの貢献者。このようペッカNikanderなどとHIP WGの貢献者。この文書では、SCTP [RFC4960]とホスト識別プロトコル（HIP）マルチホーミングとモビリティ拡張[RFC5206]の文脈で行われた作業して借金でもあります。
Appendix C. Acknowledgements
付録C.謝辞
The authors would also like to thank Christian Huitema, Pekka Savola, John Loughney, Sam Xia, Hannes Tschofenig, Sebastien Barre, Thomas Henderson, Matthijs Mekking, Deguang Le, Eric Gray, Dan Romascanu, Stephen Kent, Alberto Garcia, Bernard Aboba, Lars Eggert, Dave Ward, and Tim Polk for interesting discussions in this problem space, and for review of this specification.
著者らはまた、クリスチャンのHuitema、ペッカSavola、ジョンLoughney、サム夏、ハンネスTschofenig、セバスチャン・バレ、トーマス・ヘンダーソン、Matthijs Mekking、Deguangル、エリックグレー、ダンRomascanu、スティーブン・ケント、アルベルト・ガルシア、バーナードAboba、ラースに感謝したいと思いますこの問題空間で興味深い議論のための、およびこの仕様の見直しのためエッゲルト、デイブ・ワード、およびティムポーク。
Authors' Addresses
著者のアドレス
Jari Arkko Ericsson Jorvas 02420 Finland
ヤリArkkoエリクソン02420 Jorvasフィンランド
EMail: jari.arkko@ericsson.com
メールアドレス：jari.arkko@ericsson.com
Iljitsch van Beijnum IMDEA Networks Avda. del Mar Mediterraneo, 22 Leganes, Madrid 28918 Spain
IljitschバンBeijnum IMDEA Networksの星Avda。デルマールメディテラネオ、22のレガネス、マドリード28918スペイン
EMail: iljitsch@muada.com
メールアドレス：iljitsch@muada.com