[要約] RFC 5534は、IPv6マルチホーミングのための障害検出とロケータペア探索プロトコルに関するものです。このRFCの目的は、マルチホームノードが障害を検出し、代替ロケータペアを探索するための手順を提供することです。
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
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) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの貢献からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得しないと、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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]は、Multihomingをサポートするために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プロトコルのこの部分は、Reachabilityプロトコル（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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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 [RFC4861]のセクション4.6.2）は期限切れではありません。
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.
これにより、楽観的な重複アドレス検出（DAD）[RFC4429]という意味で、アドレスが楽観的であることを明示的に許可することに注意してください。
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.
Link-Localアドレスでは、指定されたアドレスが使用可能であるリンクについてノードを決定できません。
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 Neighbor Discovery [RFC4861]によって提供される情報を採用し、Autoconfiguration [RFC4862]、およびDHCP [RFC3315]（DHCPが実装されている場合）を扱うことができなければなりません。この情報には、新しいアドレスの可用性と既存のアドレスのステータスの変更が含まれます（アドレスが無効になったときなど）。
Two different granularity levels are needed for failure detection. The coarser granularity is for individual addresses.
障害検出には2つの異なる粒度レベルが必要です。粗い粒度は、個々のアドレス用です。
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：理論的には、この目的に適したプロトコルのみが存在する場合、特定のソースプレフィックスのルーティング障害についてノードが学習することも可能です。この分野でいくつかの提案が行われています（たとえば[Add-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.
ただし、ローカルな運用アドレスの存在は、ピアとのコミュニケーションを確立できるという保証ではありません。ルーティングインフラストラクチャの障害により、パケットが目的地に到達するのを防ぐことができます。このため、アドレスのペアに使用される第2レベルの粒度の定義が必要です。
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.
意味。双方向的に運用上のアドレスペア - 局所的に動作するアドレスのペアは、アドレス間に双方向の接続性を表示できる場合、運用アドレスペアと言われています。つまり、ソースフィールドのアドレスの1つと宛先フィールドのもう1つが宛先に到達し、その逆のパケットが送信されます。
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.
残念ながら、双方向的に動作するアドレスペアが存在しないシナリオがあります。たとえば、イングレスフィルタリングまたはネットワークの障害により、1つのアドレスペアが1つの方向に動作し、別のアドレスが他の方向から動作します。次の定義は、この一般的な状況を捉えています。
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番目のアドレスが送信された場合、一方的に運用上のアドレスペアであると言われます。
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レイヤーに進行中であることを示すことができます。これは、上層層が双方向の接続性に関する情報を提供する場合、場合によっては、IPv6隣接の非到達性検出がどのように回避できるかに似ています[RFC4861]。
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.
単方向接続の場合、上層層プロトコル応答は別のアドレスペアを使用して戻ってきますが、最初のアドレスペアを使用して送信されたメッセージが受信されたことを示しています。
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は、Acksを取得していないため、パスに接続性が混雑または不足していることを示している可能性があります。
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.
o ICMPエラーメッセージ。スプーフィングICMPメッセージの容易さを考えると、これらを盲目的に信頼しないように注意する必要があります。1つのアプローチは、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通信と互換性があり、コンテキストタグを存在させる必要がないことを意味します。
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つ以上のアドレスを持つ2つのノード間の通信オプションの完全なセットを探索することは、調査対象の組み合わせの数がアドレスの数とともに非常に急速に増加するため、高価な操作です。たとえば、両側に2つのアドレスがあるため、4つの可能なアドレスペアがあります。一方向の到達可能性は、他の方向の補体ペアの到達可能性を自動的に意味すると仮定することはできないため、双方向の組み合わせの総数は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コンテキストで現在使用されているアドレスペアの到達可能性は、一方向にペイロードトラフィックがあるときはいつでも、他の方向にトラフィックがあることを確認することにより決定されます。これもデータトラフィックであるか、他のトラフィックがない場合、輸送層の謝辞または到達可能性の到達可能性を享受する可能性があります。このようにして、1つの方向のみにトラフィックを置くことはできなくなりました。したがって、ペイロードトラフィックが発生するが、返品パケットがない場合はいつでも、障害があり、完全な探索メカニズムが開始されます。
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.
FBDは、ノードがピアからパケットを受信しているが、独自のものを送信しない場合、Reap Keepalivesを生成することで機能します。キープライブは特定の間隔で送信されるため、送信タイムアウト期間中に着信パケットを受け取らない場合、反対側が到達可能性の問題があることがわかります。ノードは、i2、i2bis、R2、または更新メッセージのキープライブタイムアウトオプション（セクション5.3）としてピアに送信タイムアウト値を通知します。その後、ピアはこの値をキープライブのタイムアウト値にマッピングします。
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.
キープライブが送信されるその後の間隔には、KeepAlive間隔と呼ばれます。KeepAlive間隔の推奨されるアプローチは、キープライブの半分から3分の1にKeepalive Timeout間隔の3分の1を送信し、複数のKeepALivesが生成され、タイムがタイムアウトする前にピアに到達する時間があることです。
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.
この仕様の目的のために、「ペイロードパケット」とは、この仕様で定義されているものを除き、上層層プロトコルパケットとSHIM6プロトコルメッセージの両方を含む、SHIM6コンテキストの一部であるパケットを指します。後者のメッセージの場合、セクション6は、メッセージが送信または受信されたときにタイマーに何が起こるかを指定します。
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. 着信ペイロードパケットを受信するたびに、ピアからのリターントラフィックに関連付けられたタイマーが停止し、別のタイマーがこのノードがリターントラフィックを生成するための要件を反映して開始されます。このタイムアウト値は、KeepAlive Timeoutの値に設定されています。
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).
これらの2つのタイマーは相互に排他的です。言い換えれば、ノードは、ノードが以前に送信したトラフィックに基づいてピアからのトラフィックを見ることを期待しているか、ノードがピアが以前に送信したトラフィックに基づいてピアに応答することを期待しています（それ以外の場合、ノードはあります。アイドル状態）。
4. The reception of a REAP Keepalive message leads to stopping the timer associated with the return traffic from the peer.
4. Reap Keepaliveメッセージを受信すると、ピアからのリターントラフィックに関連するタイマーの停止につながります。
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. ペイロードパケットが受信されて以来、このコンテキスト内で他のパケットが送信されていない場合、コンテキストに対して最後のペイロードパケットが受信されてからkeepAliveインターバル秒後に、問題のコンテキストに対して刈り取りのキープライブメッセージが生成され、ピアに送信されます。ノードは、実装の考慮事項がこれを保証する場合、キープライブの秒よりも早くKeepAliveを送信する場合がありますが、Keepaliveを過度の速度で送信しないように注意する必要があります。刈り取りのkeepAliveメッセージは、SHIM6コンテキストのペイロードパケットがピアから受信されるか、キープライブタイムアウトの有効期限が切れるまで、keepAlive間隔で引き続き送信する必要があります。Keepaliveは、KeepAlive間隔内で1つ以上のペイロードパケットが送信された場合、まったく送信されません。
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.
前のセクションで説明したように、現在使用されているアドレスペアは、アドレスのいずれかが利用できないか、手術不能になるか、ペア自体が非運用と宣言されていることを介して無効になる可能性があります。探索プロセスは、コミュニケーションが再開できるように、別の運用ペアを見つけようとします。
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のメッセージの1つを受信したことを示すプローブメッセージを取得するまで、プローブメッセージのセットを順番に開始します。そして、明らかに、（b）BのプローブメッセージがAに戻るということは、同じアルゴリズムを使用しますが、Aからの最初のプローブメッセージの受信からプロセスを開始します。
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が適応するためのシグナルになる可能性があるため、たとえば、ULPがTCPの場合、遅い開始手順を開始する可能性があります。ただし、新しいパスの選択につながった状況により、すでにスタートスタートをトリガーするのに十分なパケット損失が発生した可能性があります。
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は、異なるアドレスペア間で優先順位を提供し、おそらく検索をより速くすることができます。（テストを開始する前にアドレスペアの初期順序に到達するために、追加のメカニズムが将来定義される可能性があります[ペア]。）ノードは、既知のサービスパラメーターやインターフェイスタイプなどのローカル情報を使用して、どのアドレスが好むかを決定することもできます。他の人よりも、最初にそのようなアドレスを含むペアを試してみてください。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.
可能な候補のアドレスペアのセットのうち、ノードは、動作ペアが見つかるまでそれらすべてをテストしようとする必要があり、必要に応じてプロセスを再試行します。ただし、すべてのノードは、このプロセスを順番に、指数関数的なバックオフで実行する必要があります。このシーケンシャルプロセスは、停止が発生したときに（特に完全なサイトで）「シグナリングストーム」を避けるために必要です。ただし、新しいアドレスペアへの切り替えが長すぎると輸送およびアプリケーション層プロトコルが故障することを考慮すると、実際にはマルチホームに使用できるアドレスの数も制限されます。
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）は、指数関数的なバックオフ手順を使用する前に送信できる初期プローブの数を指定します。このプロセスは、応答がない場合、すべてのプローブ間の時間を増やします。通常、それぞれの増加は時間を2倍にしますが、この仕様は特定の増加を義務付けません。
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つのパケットを固定レートで送信する根拠は、これらのパケットを過度に速く送信する必要がないことです。これがないと、3番目と4番目のプローブの間に0.5秒があるということは、最初のプローブと2番目のプローブの間の時間が0.125秒でなければならないため、最初のパケットへの返信が到着する時間はほとんどありません。また、これは、最初の4つのパケットが2秒ではなく0.875秒以内に送信されることを意味します。これは、障害後に多数のSHIM6コンテキストがプローブを同時に送信する必要がある場合、渋滞の可能性を高めます。
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.
最後に、Max Probe Timeout（60秒）は、プローブ間隔が成長しない可能性のある制限を指定します。探索プロセスがこの間隔に達した場合、適切な応答がトリガーされるか、SHIM6コンテキストが収集されるまでこのレートで送信され続けます。これは、問題のSHIM6コンテキストを使用して上層層プロトコルがパケットを送信しようとしないためです。Max Probe Timeoutに到達することは、コンテキストがもはや使用できなくなったゴミ収集プロセスのヒントとしても役立つ場合があります。
The format of the Keepalive message is as follows:
KeepAliveメッセージの形式は次のとおりです。
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 ext Len、0、0、チェックサムこれらは、SHIM6プロトコルの説明[RFC5533]のセクション5.3で指定されています。
Type This field identifies the Keepalive message and MUST be set to 66 (Keepalive).
このフィールドを入力して、KeepAliveメッセージを識別し、66（KeepAlive）に設定する必要があります。
Reserved1 This is a 7-bit field reserved for future use. It is set to zero on transmit and MUST be ignored on receipt.
予約1これは、将来の使用のために予約されている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.
予約2これは、将来の使用のために予約されている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.
オプションこのフィールドには、1つ以上の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].
Type This field identifies the Probe message and MUST be set to 67 (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ビットフィールドです。受信したプローブフィールドは、以前の受信プローブの同じフィールドのコピーであり、州の探索への最後の移行以降に到着したプローブです。送信者が州のインバウンドックにいる場合、少なくとも1つのインバウンドプローブのフィールドのコピーを含める必要があります。送信者には、実装で採用されているロジックに従って、これらの受信プローブフィールドの追加セットを任意の状態に含めることができます。
The fields Probe Source, Probe Destination, Probe Nonce, and Probe Data may be repeated, depending on the value of Psent and Preceived.
Psentの値に応じて、フィールドプローブソース、プローブ宛先、プローブノンセ、プローブデータは繰り返される場合があります。
Sta (State) This 2-bit State field is used to inform the peer about the state of the sender. It has three legal values: 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.
STA（州）この2ビット状態フィールドは、送信者の状態についてピアに通知するために使用されます。3つの法的価値があります。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.
予約2は、送信時にゼロに設定する必要があり、受信時に無視する必要があります。
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].
プローブnonceこれは、送信者が送信したプローブAプローブ相関を決定できる値で送信者によって初期化される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、または更新メッセージで送信される場合があります。オプションは、特定のSHIM6関連付けで1回だけ送信する必要があります。ノードがこのオプションを受信した場合、ピアのキープライブタイムアウト値を更新する必要があります。
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（Keepalive Timeout）に設定する必要があります。
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.
KeepAlive TimeAutピアの提案されているKeepAlive Timeout値に対応する数秒で値を数秒単位で行います。
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.
特定のピアを使用した特定のコンテキストでは、ノードは、運用、探索、またはインバウンドックの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.
ノードは、送信タイマー（タイムアウト秒送信）とKeepAlive Timer（KeepAlive Timeout秒）も維持します。送信タイマーは、このノードがペイロードパケットを送信する場合、Timeout秒を送信する以内にいくつかのリターントラフィック（ペイロードパケットまたはKeepAliveメッセージ）がある必要があるという要件を反映しています。KeepAliveタイマーは、このノードがペイロードパケットを受信した場合、ピアに対して同様の応答が必要な要件を反映しています。KeepAliveタイマーは、運用状態内でのみ使用され、運用状態およびInboundok状態内の送信タイマーが使用されます。探索状態ではタイマーが実行されていません。セクション4.1で説明したように、2つのタイマーは相互に排他的です。つまり、KeepAliveタイマーまたは送信タイマーが実行されているか、どちらも実行されていません。
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.
動作状態でペイロードパケットが受信されると、ノードはまだ実行されていない場合はKeepAliveタイマーを起動し、実行中の場合は送信タイマーを停止します。
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状態に移行し、プローブメッセージを送信し、送信タイマーを開始します。PSENTおよび対応するプローブソースアドレス、プローブ宛先アドレス、プローブNonCE、およびプローブデータフィールドに、ピアが見たようにまだ報告されていない最近のプローブメッセージに関する情報を入力します。また、PRECVDおよび対応するプローブソースアドレス、プローブ宛先アドレス、プローブNonCE、およびプローブデータフィールドに、ピアから見た最近のプローブメッセージに関する情報を入力します。プローブメッセージを送信する場合、プローブを送信した後、送信者の概念状態に一致する値に状態フィールドを設定する必要があります。この場合、ノードは状態フィールドを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.
KeepAliveおよびプローブメッセージ以外の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.
KeepAlive Timerが実行されている間、ノードはKeepAliveインターバル秒の間隔でKeepAliveメッセージをピアに送信する必要があります。概念的には、個別のタイマーを使用して、キープライブメッセージと全体的なキープライブタイムアウト間隔の間隔を区別します。ただし、この個別のタイマーは、表形式またはグラフィカルな状態マシンでモデル化されていません。送信されると、セクション5.1で説明されているように、KeepAliveメッセージが作成されます。現在のアドレスペアを使用して送信されます。
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.
以下のテーブルでは、「開始」、「再起動」、および「停止」では、それぞれKeepAliveタイマーまたは送信タイマーの開始、再起動、停止を参照してください。「goto」とは、別の状態への移行を指します。「送信」とは、メッセージの送信を指し、「 - 」とはアクションを実行しないことを指します。
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.
KeepAliveタイマーのタイムアウト時に、ノードは最後のキープライブメッセージを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).
送信タイマーのタイムアウト時に、ノードは探索状態に入り、プローブメッセージを送信します。プローブメッセージは、セクション6.1で説明されているように構築されますが、状態フィールドが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.
プローブメッセージは、セクション6.1で説明されているように構築されます。ただし、状態フィールドは、送信者がどの状態にあるかに応じて、1（探索）または2（inboundok）に設定されています。
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状態に移行し、プローブメッセージを送信し、送信タイマーを開始します。プローブメッセージは、セクション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.
調査に設定された状態でプローブメッセージを受信すると、ノードは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.
StateがInboundokに設定されたプローブメッセージが受信されると、ノードはプローブメッセージを送信し、送信タイマーを再起動し、実行中の場合はKeepAliveタイマーを停止し、運用状態に移行します。私たちが受け取ったメッセージの受信プローブのレポートに基づいて、接続のために新しい現在のアドレスペアが選択されます。受信プローブが報告されていない場合、現在のアドレスペアは変更されていません。
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).
Stateが動作するように設定されたプローブメッセージを受信すると、ノードは実行中の場合、送信タイマーが停止し、まだ実行されていない場合はKeepAliveタイマーを起動し、運用状態に移行します。プローブメッセージは、セクション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
初期プローブタイムアウト0.5秒初期プローブの数4プローブ
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)
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]).
送信タイムアウトの代替値は、ノードによって選択され、KeepAlive Timeoutオプションでピアに通信できます。送信タイムアウトの非常に小さな値は、長い丸いトリップの遅延があるパスでキープライブを交換する能力に影響を与える可能性があります。同様に、SHIM6が必要以上に頻繁に一時的な障害に反応する可能性があります。その結果、代替の送信タイムアウト値が10秒未満ではないことをお勧めします。上記のものよりも高い値を選択することも可能ですが、送信タイムアウトと、通信パスでエラーを発見して修正する刈り取り能力の間には関係があります。いずれにせよ、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.
注：送信タイムアウトまたはその他の値が、経験豊富な往復時間に基づいて推定されるとは予想されていません。信号交換は、指数関数的なバックオフに基づいて実行されます。KeepAliveプロセスは、すべてのトラフィックが単方向であるという比較的まれな状態でのみパケットを送信します。
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.
これらの脆弱性のいくつかの側面は、IPv6ルーターを保護するために、ICMPエラー[GONT]、リンク層セキュリティ、または送信[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が実行されると、そのプローブNoncesは、請求された住所が実際にトラフィックを受け取る意思があることを返す可能性チェックとして使用できます。ただし、これは、請求されたアドレスも正しいノードであることを確認するために、別のメカニズムで補完する必要があります。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.
この仕様のキープライブメカニズムは、スプーフィングに対して脆弱です。SHIM6コンテキストタグを見ることができるパスオンパス攻撃者は、2つのSHIM6ノードがKeepAlives自体を送信するのを防ぐために、Send Timeoutインターバルごとに1回スプーフィングされたKeepAliveメッセージを送信できます。この脆弱性は、一方向通信に関与するノードにのみ関連しています。攻撃の結果、ノードは探索フェーズに不必要に入力されますが、もちろん、攻撃者が探査段階の完了を防ぐことができない限り、接続性を確認できるはずです。コンテキストタグが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.
スプーフィングされたキープライブメッセージから保護するために、SHIM6とIPSECの両方を実装するノードは、反対側がIPSECで保護されたリターントラフィックを送信すると仮定する正当な理由がある場合、入ってくるREAP Keepalivesを無視する可能性があります。言い換えれば、ノードがTCPペイロードデータを送信している場合、見返りにTCP ACKを受信することを合理的に期待できます。IPSECで保護されたACKが戻ってきていないが、保護されていないKeepALivesが戻ってきた場合、これは攻撃者が壊れた接続性を隠そうとした結果である可能性があります。
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を使用して増幅攻撃に刈り取ることの魅力を削減するコストです。ただし、そのような保護は通常、接続確立の時点では存在しません。接続確立が成功するために探索が必要になる場合、その使用は増幅の脆弱性をもたらします。その結果、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つのKeepAliveが送信され、その後一連のプローブが送信されます。これは、アクティブな（トラフィック生成）コンテキストごとに発生します。これらはすべて、障害後15秒以内にタイムアウトします。これにより、コンテキストごとに1秒あたり1パケットほど故障した後にSHIM6が生成するピークトラフィックが生成されます。おそらく、これらのコンテキストを介して実行されるセッションは、少なくともそれほど多くのトラフィックとおそらくそれ以上の可能性が高いものを送信していましたが、バックアップパスが失敗したパスよりも帯域幅が大幅に低い場合、これは一時的な輻輳につながる可能性があります。
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.
ただし、BGPを使用してマルチホミングの場合、フェイルオーバーが十分に速くTCPがスロースタートにならない場合、失敗したパス上に流れる完全なペイロードデータトラフィックがバックアップパスに切り替えられ、これがバックアップパスは容量が少ないため、さらに混雑があります。
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分あたりのコンテキストごとに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は、再ホーミングイベントの後、シグナリングとペイロードパケットのカプセル化の両方に同じヘッダーを使用します。このように、運命は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ヘッダーにカプセル化されたペイロードパケット）が通過しない場合がありますが、シグナリングとKeepalivesは行います。この状況は、パスの1つにMTUディスカバリーブラックホールがあるパスがある場合に発生する可能性があります。ある時点で大規模なパケットのみが送信される場合、Reachability Explorationがオンになり、PMTUDブラックホールの影響を受ける場合と影響を受ける場合とそうでない場合がある別のパスを選択する可能性があります。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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.、Bound、J.、Volz、B.、Lemon、T.、Perkins、C。、およびM. Carney、「IPv6の動的ホスト構成プロトコル」、RFC 3315、2003年7月。
[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484] Draves、R。、「インターネットプロトコルバージョン6（IPv6）のデフォルトアドレス選択」、RFC 3484、2003年2月。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086] Eastlake、D.、Schiller、J。、およびS. Crocker、「セキュリティのランダム性要件」、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. Haberman、「ユニークなローカル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.、Simpson、W。、およびH. Soliman、「IPバージョン6（IPv6）の近隣発見」、RFC 4861、2007年9月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862] Thomson、S.、Narten、T。、およびT. Jinmei、「IPv6 Stateless Address Autoconfiguration」、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] Aura、T.、Roe、M。、およびJ. Arkko、「インターネットロケーション管理のセキュリティ」、2002年12月、ネバダ州ラスベガスの第18回年次コンピューターセキュリティアプリケーション会議の議事録。
[BFD] Katz, D. and D. Ward, "Bidirectional Forwarding Detection", Work in Progress, February 2009.
[BFD] Katz、D。およびD. Ward、「双方向転送検出」、2009年2月、進行中の作業。
[DNA-SIM] Krishnan, S. and G. Daley, "Simple procedures for Detecting Network Attachment in IPv6", Work in Progress, February 2009.
[DNA-SIM] Krishnan、S。and G. Daley、「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。、「Multihomed環境でのアドレス選択」、2004年10月、進行中の作業。
[PAIR] Bagnulo, M., "Default Locator-pair selection algorithm for the Shim6 protocol", Work in Progress, October 2008.
[ペア] Bagnulo、M。、「SHIM6プロトコルのデフォルトのロケーターペア選択アルゴリズム」、2008年10月、進行中の作業。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122] Braden、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.、Kempf、J.、Zill、B。、およびP. Nikander、「Secure Neighbor Discovery（Send）」、RFC 3971、2005年3月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960] Stewart、R。、「Stream Control Transmission Protocol」、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.、Henderson、T.、Vogt、C。、およびJ. Arkko、「ホストIDプロトコルによるエンドホストモビリティとマルチホミング」、RFC 5206、2008年4月。
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
| |
| |
| |
| |
| |
| |
| |
| |
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:
2番目の例には、双方向のペイロードパケットフローとの積極的な接続が含まれます。ここでは、ピアからのペイロードデータの受信は、到達可能性の兆候と見なされているため、追加のパケットはありません。
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メッセージを含む最初の例です。ここでは、ノードは一方向に通信するため、パケットが通過しているペイロードパケットを送信するピアに示すために、刈り取りメッセージが必要です。
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 |
|<--------------------------------------------|
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設計チームのメンバーであるMarcelo Bagnulo Braun、Erik Nordmark、Geoff Huston、Kurtis Lindqvist、Margaret Wasserman、Jukka Ylitaloなど、多くの人々の考えと未発表の貢献を要約しようとします。Mobike WGの貢献者Pasi Eronen、Tero Kivinen、Francis Dupont、Spencer Dawkins、James Kempf。Pekka NikanderなどのHIP WG貢献者。このドキュメントは、SCTP [RFC4960]およびホストIDプロトコル（HIP）マルチホームおよびモビリティ拡張[RFC5206]のコンテキストで行われた仕事にも負債があります。
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.
著者はまた、クリスチャン・フイテマ、ペッカ・サヴォラ、ジョン・ラウニー、サム・シア、ハネス・ツェフェニグ、セバスチャン・バレ、トーマス・ヘンダーソン、マティジス・メッキング、デグアン・ル、エリック・グレイ、ダン・ロマスカヌ、ステフェン・ケント、アルバルト・ガルシア、ベナード・アボバ、ラーサEggert、Dave Ward、およびTim Polkは、この問題の分野での興味深い議論、およびこの仕様のレビューについて。
Authors' Addresses
著者のアドレス
Jari Arkko Ericsson Jorvas 02420 Finland
Jari Arkko Ericsson Jorvas 02420フィンランド
EMail: jari.arkko@ericsson.com
Iljitsch van Beijnum IMDEA Networks Avda. del Mar Mediterraneo, 22 Leganes, Madrid 28918 Spain
Iljitsch van beijnum imdea Networks avda。Del Mar Mediterraneo、22 Leganes、Madrid 28918スペイン
EMail: iljitsch@muada.com