[要約] RFC 5847は、Proxy Mobile IPv6におけるハートビートメカニズムについての規格です。その目的は、モバイルノードとホームエージェント間の接続状態を監視し、モバイルノードの移動やネットワークの変更に対応することです。
Internet Engineering Task Force (IETF) V. Devarapalli, Ed.
Request for Comments: 5847 WiChorus
Category: Standards Track R. Koodli, Ed.
ISSN: 2070-1721 Cisco Systems
H. Lim
N. Kant
Stoke
S. Krishnan
J. Laganier
Qualcomm Inc.
June 2010
Heartbeat Mechanism for Proxy Mobile IPv6
プロキシモバイルIPv6のハートビートメカニズム
Abstract
概要
Proxy Mobile IPv6 (PMIPv6) is a network-based mobility management protocol. The mobility entities involved in the Proxy Mobile IPv6 protocol, the mobile access gateway (MAG) and the local mobility anchor (LMA), set up tunnels dynamically to manage mobility for a mobile node within the Proxy Mobile IPv6 domain. This document describes a heartbeat mechanism between the MAG and the LMA to detect failures, quickly inform peers in the event of a recovery from node failures, and allow a peer to take appropriate action.
プロキシモバイルIPv6（PMIPv6）は、ネットワークベースのモビリティ管理プロトコルです。プロキシモバイルIPv6プロトコル、モバイルアクセスゲートウェイ（MAG）、ローカルモビリティアンカー（LMA）に関与するモビリティエンティティは、トンネルを動的にセットアップして、プロキシモバイルIPv6ドメイン内のモバイルノードのモビリティを管理します。このドキュメントでは、MAGとLMAの間のハートビートメカニズムが障害を検出し、ノード障害から回復した場合にピアに迅速に通知し、ピアが適切なアクションを実行できるようにします。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5847.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5847で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Heartbeat Mechanism . . . . . . . . . . . . . . . . . . . . . 3
3.1. Failure Detection . . . . . . . . . . . . . . . . . . . . 4
3.2. Restart Detection . . . . . . . . . . . . . . . . . . . . 5
3.3. Heartbeat Message . . . . . . . . . . . . . . . . . . . . 6
3.4. Restart Counter Mobility Option . . . . . . . . . . . . . 7
4. Exchanging Heartbeat Messages over an IPv4 Transport
Network . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Configuration Variables . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . . 10
Proxy Mobile IPv6 (PMIPv6) [RFC5213] enables network-based mobility for IPv6 hosts that do not implement any mobility protocols. The protocol is described in detail in [RFC5213]. In order to facilitate the network-based mobility, the PMIPv6 protocol defines a mobile access gateway (MAG), which acts as a proxy for the Mobile IPv6 [RFC3775] signaling, and the local mobility anchor (LMA), which acts similar to a home agent, anchoring a mobile node's sessions within a PMIPv6 domain. The LMA and the MAG establish a bidirectional tunnel for forwarding all data traffic belonging to the mobile nodes.
プロキシモバイルIPv6（PMIPV6）[RFC5213]は、モビリティプロトコルを実装していないIPv6ホストのネットワークベースのモビリティを可能にします。プロトコルは[RFC5213]で詳細に説明されています。ネットワークベースのモビリティを容易にするために、PMIPv6プロトコルは、モバイルIPv6 [RFC3775]シグナル伝達のプロキシとして機能するモバイルアクセスゲートウェイ（MAG）と、ローカルモビリティアンカー（LMA）として機能するモバイルアクセスゲートウェイ（MAG）を定義します。ホームエージェント、PMIPv6ドメイン内のモバイルノードのセッションを固定します。LMAとMAGは、モバイルノードに属するすべてのデータトラフィックを転送するための双方向トンネルを確立します。
In a distributed environment such as a PMIPv6 domain consisting of LMAs and MAGs, it is necessary for the nodes to 1) have a consistent state about each other's reachability, and 2) quickly inform peers in the event of recovery from node failures. So, when the LMA restarts after a failure, the MAG should (quickly) learn about the restart so that it can take appropriate actions (such as releasing any resources). When there are no failures, a MAG should know about the LMA's reachability (and vice versa) so that the path can be assumed to be functioning.
LMAとMAGSで構成されるPMIPv6ドメインなどの分散環境では、1）ノードが互いの到達可能性について一貫した状態を持つ必要があり、2）ノードの障害からの回復の場合にピアに迅速に通知します。したがって、障害後にLMAが再起動すると、雑誌は再起動について（迅速に）学習して、適切なアクション（リソースのリリースなど）を実行できるようにする必要があります。失敗がない場合、雑誌は、パスが機能していると想定できるように、LMAの到達可能性（および逆も同様です）について知っておく必要があります。
This document specifies a heartbeat mechanism between the MAG and the LMA to detect the status of reachability between them. This document also specifies a mechanism to indicate node restarts; the mechanism could be used to quickly inform peers of such restarts. The Heartbeat message is a Mobility Header message (protocol type 135) that is periodically exchanged at a configurable threshold of time or sent unsolicited soon after a node restart. This document does not specify the specific actions (such as releasing resources) that a node takes as a response to processing the Heartbeat messages.
このドキュメントは、MAGとLMAの間のハートビートメカニズムを指定して、それらの間の到達可能性の状態を検出します。このドキュメントは、ノードの再起動を示すメカニズムも指定しています。メカニズムを使用して、ピアにそのような再起動を迅速に通知できます。Heartbeatメッセージは、構成可能なしきい値で定期的に交換されるモビリティヘッダーメッセージ（プロトコルタイプ135）であるか、ノードの再起動後すぐに未承諾の送信されます。このドキュメントでは、ノードがハートビートメッセージの処理への応答として取る特定のアクション（リリースのリリースなど）を指定しません。
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]に記載されているように解釈される。
The MAG and the LMA exchange Heartbeat messages every HEARTBEAT_INTERVAL seconds to detect the current status of reachability between them. The MAG initiates the heartbeat exchange to test if the LMA is reachable by sending a Heartbeat Request message to the LMA. Each Heartbeat Request contains a sequence number that is incremented monotonically. The sequence number on the last Heartbeat Request message is always recorded by the MAG, and is used to match the corresponding Heartbeat Response. Similarly, the LMA also initiates a heartbeat exchange with the MAG, by sending a Heartbeat Request message, to check if the MAG is reachable. The format of the Heartbeat message is described in Section 3.3.
MAGとLMAは、Heartbeat_intervalのすべてのheartbeatメッセージを交換して、それらの間の到達可能性の現在の状態を検出します。MAGは、LMAにハートビートリクエストメッセージを送信することでLMAに到達できるかどうかをテストするために、ハートビート交換を開始します。各ハートビートリクエストには、単調に増加するシーケンス番号が含まれています。最後のハートビートリクエストメッセージのシーケンス番号は、常にMAGによって記録され、対応するハートビート応答と一致するために使用されます。同様に、LMAはまた、雑誌のリクエストメッセージを送信することにより、雑誌に到達可能かどうかを確認することにより、雑誌とのハートビート交換を開始します。ハートビートメッセージの形式については、セクション3.3で説明しています。
A Heartbeat Request message can be sent only if the MAG has at least one proxy Binding Cache entry at the LMA for a mobile node attached to the MAG. If there are no proxy Binding Cache entries at the LMA for any of the mobile nodes attached to the MAG, then the Heartbeat message SHOULD NOT be sent. Similarly, the LMA SHOULD NOT send a Heartbeat Request message to a MAG if there is no active Binding Cache entry created by the MAG. A PMIPv6 node MUST respond to a Heartbeat Request message with a Heartbeat Response message, irrespective of whether there is an active Binding Cache entry.
MAGにMAGに接続されたモバイルノードのLMAで少なくとも1つのプロキシバインドキャッシュエントリがある場合にのみ、ハートビートリクエストメッセージを送信できます。MAGに接続されたモバイルノードのいずれかについて、LMAにプロキシバインドキャッシュエントリがない場合は、ハートビートメッセージを送信しないでください。同様に、LMAは、雑誌によって作成されたアクティブなバインディングキャッシュエントリがない場合、MAGにハートビートリクエストメッセージを送信しないでください。PMIPV6ノードは、アクティブなバインディングキャッシュエントリがあるかどうかに関係なく、ハートビート応答メッセージを使用してハートビートリクエストメッセージに応答する必要があります。
The HEARTBEAT_INTERVAL SHOULD NOT be configured to a value less than 30 seconds. Deployments should be careful in setting the value for the HEARTBEAT_INTERVAL. Sending Heartbeat messages too often may become an overhead on the path between the MAG and the LMA. It could also create congestion in the network and negatively affect network performance. The HEARTBEAT_INTERVAL can be set to a much larger value on the MAG and the LMA, if required, to reduce the burden of sending periodic Heartbeat messages.
heartbeat_intervalは、30秒未満の値に構成されてはなりません。展開は、heartbeat_intervalの値を設定する際に注意する必要があります。ハートビートメッセージを送信しすぎると、MAGとLMAの間のパス上のオーバーヘッドになる可能性があります。また、ネットワークに混雑を引き起こし、ネットワークのパフォーマンスに悪影響を与える可能性があります。Heartbeat_intervalは、必要に応じて、必要に応じて、定期的なハートビートメッセージを送信する負担を軽減するために、MAGとLMAのはるかに大きな値に設定できます。
If the LMA or the MAG do not support the Heartbeat messages, they respond with a Binding Error message with status set to 2 (unrecognized mobility header (MH) type value) as described in [RFC3775]. When the Binding Error message with status set to 2 is received in response to a Heartbeat Request message, the initiating MAG or the LMA MUST NOT use Heartbeat messages with the other end again.
LMAまたはMAGがハートビートメッセージをサポートしていない場合、[RFC3775]に記載されているように、ステータスが2（認識されていないモビリティヘッダー（MH）タイプ値）に設定されたバインディングエラーメッセージで応答します。ステータスを2に設定したバインディングエラーメッセージがハートビートリクエストメッセージに応じて受信される場合、開始MAGまたはLMAはもう一方の端でハートビートメッセージを使用してはなりません。
If a PMIPv6 node has detected that a peer PMIPv6 node has failed or restarted without retaining the PMIPv6 session state, it should mark the corresponding binding update list or binding cache entries as invalid. The PMIPv6 node may also take other actions, which are outside the scope of this document.
PMIPv6ノードがPMIPv6セッション状態を保持せずにピアPMIPV6ノードが故障または再起動したことを検出した場合、対応するバインディング更新リストまたはバインディングキャッシュエントリを無効とマークする必要があります。PMIPv6ノードは、このドキュメントの範囲外の他のアクションを実行する場合があります。
The detection of failure and restart events may be signaled to network operators by using asynchronous notifications. Future work may define such notifications in a Structure of Management Information Version 2 (SMIv2) Management Information Base (MIB) module.
障害イベントと再起動イベントの検出は、非同期通知を使用してネットワーク演算子に合図する場合があります。将来の作業は、管理情報の構造バージョン2（SMIV2）管理情報ベース（MIB）モジュールの構造でそのような通知を定義する場合があります。
A PMIPv6 node (MAG or LMA) matches every received Heartbeat Response to the Heartbeat Request sent using the sequence number. Before sending the next Heartbeat Request, it increments a local variable MISSING_HEARTBEAT if it has not received a Heartbeat Response for the previous request. When this local variable MISSING_HEARTBEAT exceeds a configurable parameter MISSING_HEARTBEATS_ALLOWED, the PMIPv6 node concludes that the peer PMIPv6 node is not reachable. If a Heartbeat Response message is received, the MISSING_HEARTBEATS counter is reset.
PMIPV6ノード（MAGまたはLMA）は、シーケンス番号を使用して送信されたハートビートリクエストに対するすべての受信したハートビート応答と一致します。次のハートビートリクエストを送信する前に、以前のリクエストに対してハートビート応答を受け取っていない場合、ローカル変数Missing_HeartBeatが増加します。このローカル変数Missing_HeartBeatが構成可能なパラメーターMissing_HeartBeats_Allowedを超えると、PMIPv6ノードはPEER PMIPV6ノードに到達できないと結論付けます。ハートビート応答メッセージが受信された場合、Missing_HeartBeatsカウンターがリセットされます。
The section describes a mechanism for detecting failure recovery without session persistence. In the case that the LMA or the MAG crashes and reboots and loses all state with respect to the PMIPv6 sessions, it would be beneficial for the peer PMIPv6 node to discover the failure and the loss of session state and establish the sessions again.
このセクションでは、セッションの持続性なしに障害回復を検出するメカニズムについて説明します。LMAまたはMAGがPMIPv6セッションに関してすべての状態をクラッシュさせ、再起動し、失う場合、ピアPMIPV6ノードがセッション状態の障害と喪失を発見し、再びセッションを確立することが有益です。
Each PMIPv6 node (both the MAG and LMA) MUST maintain a monotonically increasing Restart Counter that is incremented every time the node reboots and loses PMIPv6 session state. The counter MUST NOT be incremented if the recovery happens without losing state for the PMIPv6 sessions active at the time of failure. This counter MUST be treated as state that is preserved across reboots. A PMIPv6 node includes a Restart Counter mobility option, described in Section 3.4, in a Heartbeat Response message to indicate the current value of the Restart Counter. Each PMIPv6 node MUST also store the Restart Counter for all the peer PMIPv6 nodes with which it currently has sessions. Stored Restart Counter values for peer PMIPv6 nodes do not need to be preserved across reboots.
各PMIPv6ノード（MAGとLMAの両方）は、ノードが再起動してPMIPV6セッション状態を失うたびに増加する単調に増加する再起動カウンターを維持する必要があります。障害時にアクティブなPMIPv6セッションの状態を失うことなく回復が発生した場合、カウンターを増分してはなりません。このカウンターは、再起動全体で保存されている状態として扱わなければなりません。PMIPV6ノードには、セクション3.4で説明されている再起動カウンターモビリティオプションが含まれており、再起動カウンターの現在の値を示すためのハートビート応答メッセージが含まれています。各PMIPv6ノードは、現在セッションがあるすべてのピアPMIPV6ノードの再起動カウンターも保存する必要があります。ピアPMIPv6ノードの保存された再起動カウンター値は、再起動全体で保存する必要はありません。
The PMIPv6 node that receives the Heartbeat Response message compares the Restart Counter value with the previously received value. If the value is different, the receiving node assumes that the peer PMIPv6 node had crashed and recovered. If the Restart Counter value changes or if there was no previously stored value, the new value is stored by the receiving PMIPv6 node.
ハートビート応答メッセージを受信するPMIPv6ノードは、再起動カウンター値を以前に受信した値と比較します。値が異なる場合、受信ノードは、ピアPMIPV6ノードがクラッシュして回復したと想定しています。再起動カウンター値が変更された場合、または以前に保存された値がなかった場合、新しい値は受信PMIPv6ノードによって保存されます。
If a PMIPv6 node restarts and loses PMIPv6 session state, it SHOULD send an unsolicited Heartbeat Response message with an incremented Restart Counter to all the PMIPv6 nodes that had previously established PMIPv6 sessions. Note that this is possible only when the PMIPv6 node is capable of storing information about the peers across reboots. The unsolicited Heartbeat Response message allows the peer PMIPv6 nodes to quickly discover the restart. The sequence number field in the unsolicited Heartbeat Response is ignored and no response is necessary; the nodes will synchronize during the next request and response exchange.
PMIPV6ノードがPMIPV6セッションの状態を再起動して失う場合、以前にPMIPv6セッションを確立したすべてのPMIPV6ノードにインクリメントされた再起動カウンターを使用して、未承諾のハートビート応答メッセージを送信する必要があります。これは、PMIPv6ノードが再起動全体にピアに関する情報を保存できる場合にのみ可能であることに注意してください。未承諾のハートビート応答メッセージにより、ピアPMIPv6ノードは再起動をすばやく発見できます。未承諾の心拍応答のシーケンス番号フィールドは無視され、応答は必要ありません。ノードは、次のリクエストと応答の交換中に同期します。
The Heartbeat message is based on the Mobility Header defined in Section 6.1 of [RFC3775]. The MH Type field in the Mobility Header indicates that it is a Heartbeat message. The value MUST be set to 13. This document does not make any other changes to the Mobility Header message. Please refer to [RFC3775] for a description of the fields in the Mobility Header message.
ハートビートメッセージは、[RFC3775]のセクション6.1で定義されているモビリティヘッダーに基づいています。モビリティヘッダーのMHタイプフィールドは、それがハートビートメッセージであることを示します。値は13に設定する必要があります。このドキュメントは、モビリティヘッダーメッセージに他の変更を加えません。モビリティヘッダーメッセージのフィールドの説明については、[RFC3775]を参照してください。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Proto | Header Len | MH Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
. .
. Message Data .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Mobility Header Message Format
図1：モビリティヘッダーメッセージフォーマット
The Heartbeat message follows the Checksum field in the above message. The following illustrates the message format for the Heartbeat Mobility Header message.
ハートビートメッセージは、上記のメッセージのチェックサムフィールドに従います。以下は、ハートビートモビリティヘッダーメッセージのメッセージ形式を示しています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |U|R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Heartbeat Message Format
図2：ハートビートメッセージ形式
Reserved
予約済み
Set to 0 and ignored by the receiver.
0に設定し、受信機によって無視されます。
'U'
「u」
Set to 1 in Unsolicited Heartbeat Response. Otherwise, set to 0.
未承諾のハートビート応答で1に設定します。それ以外の場合は、0に設定します。
'R'
'r'
A 1-bit flag that indicates whether the message is a request or a response. When the 'R' flag is set to 0, it indicates that the Heartbeat message is a request. When the 'R' flag is set to 1, it indicates that the Heartbeat message is a response.
メッセージがリクエストか応答かを示す1ビットフラグ。「r」フラグが0に設定されている場合、ハートビートメッセージがリクエストであることを示します。「r」フラグが1に設定されている場合、ハートビートメッセージが応答であることを示します。
Sequence Number
シーケンス番号
A 32-bit sequence number used for matching the request to the reply.
要求を返信に一致させるために使用される32ビットシーケンス番号。
Mobility Options
モビリティオプション
Variable-length field of such length that the complete Mobility Header is an integer that is a multiple of 8 octets long. This field contains zero or more TLV-encoded mobility options. The receiver MUST ignore and skip any options that it does not understand. At the time of writing this document, the Restart Counter mobility option, described in Section 3.4, is the only valid option in this message.
完全なモビリティヘッダーが長さ8オクターの倍数の整数であるような長さの可変長いフィールド。このフィールドには、ゼロ以上のTLVエンコードモビリティオプションが含まれています。レシーバーは、理解できないオプションを無視してスキップする必要があります。このドキュメントの作成時点では、セクション3.4で説明されている再起動カウンターモビリティオプションが、このメッセージの唯一の有効なオプションです。
The following shows the message format for a new mobility option for carrying the Restart Counter value in the Heartbeat message. The Restart Counter mobility option is only valid in a Heartbeat Response message. It has an alignment requirement of 4n+2.
以下は、ハートビートメッセージに再起動カウンター値を運ぶための新しいモビリティオプションのメッセージ形式を示しています。再起動カウンターモビリティオプションは、ハートビート応答メッセージでのみ有効です。4n 2のアライメント要件があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Restart Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Restart Counter Mobility Option
図3：カウンターモビリティオプションを再起動します
Type
タイプ
An 8-bit field that indicates that it is a Restart Counter mobility option. It MUST be set to 28.
再起動カウンターモビリティオプションであることを示す8ビットフィールド。28に設定する必要があります。
Length
長さ
An 8-bit field that indicates the length of the option in octets excluding the Type and Length fields. It is set to 4.
タイプと長さのフィールドを除くオクテットのオプションの長さを示す8ビットフィールド。4に設定されています。
Restart Counter
カウンターを再起動します
A 32-bit field that indicates the current Restart Counter value.
現在の再起動カウンター値を示す32ビットフィールド。
In some deployments, the network between the MAG and the LMA may be IPv4-only and not capable of routing IPv6 packets. In this case, the Mobility Header containing the Heartbeat message is carried as specified in Section 4 of [RFC5844], i.e., the Mobility Header is part of the UDP payload inside an IPv4 packet (IPv4-UDP-MH).
一部の展開では、MAGとLMAの間のネットワークはIPv4のみであり、IPv6パケットをルーティングできない場合があります。この場合、ハートビートメッセージを含むモビリティヘッダーは、[RFC5844]のセクション4で指定されているように運ばれます。つまり、モビリティヘッダーはIPv4パケット内のUDPペイロードの一部です（IPv4-UDP-MH）。
The LMA and the MAG must allow the following variables to be configurable.
LMAとMAGは、次の変数を構成可能にする必要があります。
HEARTBEAT_INTERVAL
heartbeat_interval
This variable is used to set the time interval in seconds between two consecutive Heartbeat Request messages. The default value is 60 seconds. It SHOULD NOT be set to less than 30 seconds or more than 3600 seconds.
この変数は、2つの連続したハートビートリクエストメッセージの間の数秒で時間間隔を設定するために使用されます。デフォルト値は60秒です。30秒未満または3600秒以上に設定しないでください。
MISSING_HEARTBEATS_ALLOWED
Missing_HeartBeats_Allowed
This variable indicates the maximum number of consecutive Heartbeat Request messages for which a PMIPv6 node did not receive a response before concluding that the peer PMIPv6 node is not reachable. The default value for this variable is 3.
この変数は、PMIPV6ノードがPMIPV6ノードに到達できないと結論付ける前に、PMIPV6ノードが応答を受信しなかった連続したハートビートリクエストメッセージの最大数を示します。この変数のデフォルト値は3です。
The Heartbeat messages are just used for checking reachability between the MAG and the LMA. They do not carry information that is useful for eavesdroppers on the path. Therefore, confidentiality protection is not required. Integrity protection using IPsec [RFC4301] for the Heartbeat messages MUST be supported on the MAG and the LMA. RFC 5213 [RFC5213] describes how to protect the Proxy Binding Update and Acknowledgement signaling messages with IPsec. The Heartbeat message defined in this specification is merely another subtype of the same Mobility Header protocol that is already being protected by IPsec. Therefore, protecting this additional message is possible using the mechanisms and security policy models from these RFCs. The security policy database entries should use the new MH Type, the Heartbeat message, for the MH Type selector.
ハートビートメッセージは、MAGとLMAの間の到達可能性をチェックするために使用されます。パス上の盗聴者に役立つ情報はありません。したがって、機密保護は必要ありません。IPSEC [RFC4301]を使用した整合性保護は、MAGおよびLMAでサポートする必要があります。RFC 5213 [RFC5213]は、IPSECを使用したプロキシバインディングの更新および確認信号メッセージを保護する方法について説明しています。この仕様で定義されているハートビートメッセージは、すでにIPSECによって保護されているのと同じモビリティヘッダープロトコルの別のサブタイプにすぎません。したがって、これらのRFCのメカニズムとセキュリティポリシーモデルを使用して、この追加のメッセージを保護することが可能です。セキュリティポリシーデータベースエントリは、MHタイプセレクターに新しいMHタイプのハートビートメッセージを使用する必要があります。
If dynamic key negotiation between the MAG and the LMA is required, Internet Key Exchange Protocol version 2 (IKEv2) [RFC4306] should be used.
MAGとLMAの間の動的なキー交渉が必要な場合は、インターネットキーエクスチェンジプロトコルバージョン2（IKEV2）[RFC4306]を使用する必要があります。
The Heartbeat message defined in Section 3.3 must have the type value allocated from the same space as the 'MH Type' name space in the Mobility Header defined in RFC 3775 [RFC3775].
セクション3.3で定義されているハートビートメッセージには、RFC 3775 [RFC3775]で定義されたモビリティヘッダーの「MHタイプ」名スペースと同じスペースからタイプ値を割り当てる必要があります。
The Restart Counter mobility option defined in Section 3.4 must have the type value allocated from the same name space as the mobility options defined in RFC 3775 [RFC3775].
セクション3.4で定義されている再起動カウンターモビリティオプションには、RFC 3775 [RFC3775]で定義されているモビリティオプションと同じ名前スペースから割り当てられたタイプ値が必要です。
A heartbeat mechanism for a network-based mobility management protocol was first described in [NETLMM]. The authors would like to thank the members of a NETLMM design team that produced that document. The mechanism described in this document also derives from the path management mechanism described in [GTP].
ネットワークベースのモビリティ管理プロトコルのハートビートメカニズムは、[NetLMM]で最初に説明されました。著者は、その文書を作成したNetLMMデザインチームのメンバーに感謝したいと思います。このドキュメントで説明されているメカニズムは、[GTP]で説明されているパス管理メカニズムにも由来します。
We would like to thank Alessio Casati for first suggesting a fault handling mechanism for Proxy Mobile IPv6.
プロキシモバイルIPv6の障害処理メカニズムを最初に提案してくれたAlessio Casatiに感謝します。
[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月。
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5213] Gundavelli、S.、Leung、K.、Devarapalli、V.、Chowdhury、K。、およびB. Patil、「Proxy Mobile IPv6」、RFC 5213、2008年8月。
[RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", RFC 5844, May 2010.
[RFC5844] Wakikawa、R。およびS. Gundavelli、「Proxy Mobile IPv6のIPv4サポート」、RFC 5844、2010年5月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. SEO、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306] Kaufman、C。、「Internet Key Exchange（IKEV2）プロトコル」、RFC 4306、2005年12月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775] Johnson、D.、Perkins、C。、およびJ. Arkko、「IPv6のモビリティサポート」、RFC 3775、2004年6月。
[NETLMM] Levkowetz, H., Ed., Giaretta, G., Leung, K., Liebsch, M., Roberts, P., Nishida, K., Yokota, H., and M. Parthasarathy, "The NetLMM Protocol", Work in Progress, October 2006.
[Netlmm] Levkowetz、H.、Ed。、Giaretta、G.、Leung、K.、Liebsch、M.、Roberts、P.、Nishida、K.、Yokota、H。、およびM. Parthasarathy、Netlmmプロトコル「、2006年10月、進行中の作業。
[GTP] 3rd Generation Partnership Project, "3GPP Technical Specification 29.060 V7.6.0: "Technical Specification Group Core Network and Terminals; General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP) across the Gn and Gp interface (Release 7)"", July 2007.
[GTP]第3世代パートナーシッププロジェクト、「3GPP技術仕様29.060 V7.6.0：「技術仕様グループコアネットワークおよび端末」。一般的なパケットラジオサービス（GPRS）;2007年7月、GNおよびGPインターフェイス（リリース7） ""を介したGPRSトンネルプロトコル（GTP）。
Authors' Addresses
著者のアドレス
Vijay Devarapalli (editor) WiChorus 3950 North First Street San Jose, CA 95134 USA
Vijay Devarapalli（編集者）Wichorus 3950 North First Street San Jose、CA 95134 USA
EMail: vijay@wichorus.com
Rajeev Koodli (editor) Cisco Systems USA
Rajeev Koodli（編集者）Cisco Systems USA
EMail: rkoodli@cisco.com
Heeseon Lim Stoke 5403 Betsy Ross Drive Santa Clara, CA 95054 USA
Heeseon Lim Stoke 5403 Betsy Ross Drive Santa Clara、CA 95054 USA
EMail: hlim@stoke.com
Nishi Kant
Stoke
5403 Betsy Ross Drive
Santa Clara, CA 95054
USA
EMail: nishi@stoke.com
Suresh Krishnan Ericsson 8400 Decarie Blvd. Town of Mount Royal, QC Canada
Suresh Krishnan Ericsson 8400 Decarie Blvd.QCカナダのマウントロイヤルの町
EMail: suresh.krishnan@ericsson.com
Julien Laganier Qualcomm Incorporated 5775 Morehouse Drive San Diego, CA 92121 USA
Julien Laganier Qualcomm Incorporated 5775 Morehouse Drive San Diego、CA 92121 USA
EMail: julienl@qualcomm.com